レガシーシステムのリプレイスは、現状分析からゴール設定、ベンダー選定、要件定義を経て、開発・データ移行・テストを行い、本番に切り替える流れで進みます。
経済産業省は2018年に「DXレポート」を公表し、レガシーシステムの放置が2025年から2030年にかけて年間最大12兆円の経済損失をもたらすと警鐘を鳴らしました。
- 現状分析とリプレイス計画
- RFP・要件定義・ベンダー選定
- 移行方式と切り戻し基準
- チェンジマネジメントと成功事例
レガシーシステム刷新の工程ごとの進め方と注意点については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
レガシーシステムリプレイスの全体像
レガシーシステムとは、古い技術・アーキテクチャで構築され、現代のビジネス要件や技術トレンドに対応しにくくなったシステムの総称です。
代表例は、メインフレームや独自言語で書かれた基幹システム、導入から20年以上が経過した業務パッケージなどです。
リプレイスとは、そうしたシステムを新しいシステムやパッケージに置き換えることを指します。既存のシステムを別のサーバー環境に移す「マイグレーション（リホスト）」とは区別されます。
リプレイスでは業務プロセスの見直しも伴うことが多く、そのぶん、単なるシステム移行よりビジネスへの影響が大きくなります。
リプレイスの2つの目的：守りの投資と攻めの投資
レガシーシステムのリプレイスには、大きく分けて「守りの投資」と「攻めの投資」という2つの目的があります。守りの投資は、老朽化によるリスクを取り除くための対応です。具体例には、サポート終了したOSやミドルウェアのセキュリティリスクへの対処、保守費用の増大抑制、属人化・ブラックボックス化の解消などが挙げられます。
一方、攻めの投資は、新システムの導入をきっかけにDXを推進し、競争優位を獲得することを目指すものです。その代表例は、クラウド活用によるスケーラビリティの確保、AIや分析ツールとのデータ連携、業務プロセスの抜本的な効率化などです。
プロジェクトの目的を、この2つのどちらにどの程度重きを置くかで、スコープ・予算・期間の方向性が大きく変わります。
リプレイスを検討すべき5つのサイン
自社のシステムがリプレイスの時期を迎えているかは、次のようなサインで判断できます。①ベンダーやOSのサポートが終了している、または間近に迫っている。②システムの仕様書がなく、改修や変更を加えられる担当者が社内に1〜2名しかいない（属人化）。
③保守・運用費用が年々増加しており、新機能の追加が非常に困難になっている。④業務の変化にシステムが追いつかず、ExcelやAccessでの「つなぎ運用」が常態化している。⑤セキュリティの脆弱性が放置され、コンプライアンスリスクが顕在化している。
こうしたサインが1つでも当てはまれば、リプレイスの検討を先送りにするコストは毎年確実に積み上がります。特に「担当者が退職したら誰も触れない」というブラックボックス化は、企業にとって最も危険なリスクのひとつです。
レガシーシステムリプレイスの進め方 7ステップ
レガシーシステムのリプレイスは、通常1〜3年にわたる長期プロジェクトです。
大きな失敗の多くは、上流工程を飛ばしたことから生まれます。「いきなり要件定義に入ってしまった」「ゴールの定義が曖昧なままベンダーを決めた」といったケースです。
この7ステップを順に踏むことで、プロジェクトの成功確率を大きく高められます。
Step1：現状分析・課題の棚卸し
リプレイスの出発点は「現行システムの棚卸し」です。現在動いているシステムが何を処理し、どのシステムと連携し、誰が保守しているのかを文書にまとめます。
ただ、レガシーシステムでは、この作業そのものが難しいことがあります。「仕様書がない」「開発会社がすでに存在しない」「担当者しか知らないロジックがある」といった状況も、珍しくありません。一人情シスや兼任担当者しかいない中小企業では、外部コンサルタントに作業を依頼するのも現実的な選択肢のひとつです。
この段階で作っておきたいのは、次の3点です。①システムマップ（全体の構成図・連携図）、②業務フローとシステムの対応表、③技術的負債のリスト（サポート切れOS、属人化している処理、ドキュメントのない仕様）。特に、この棚卸しには2〜3ヶ月かかることも珍しくありません。
Step2：目的・ゴールの明確化とROI算出
現状分析を踏まえ、「このリプレイスで何を達成するのか」を明文化します。ゴールは、「システムを新しくすること」ではなく「業務成果」で定義します。具体的な指標は、「月次決算を現在の3週間から1週間に短縮する」「保守費用を年間500万円削減する」「担当者不在でも保守が継続できる体制をつくる」といった形で設定します。
ROI（投資対効果）の算出も、この段階で行っておくと、経営層への稟議が進めやすくなります。人件費の削減効果を試算する際は、表面上の給与だけでなく、社会保険料などの管理コストも含めた「基本給の約2倍」を人的コストとして計算するのが、現場の実態に即した方法です。
たとえば、月給40万円のスタッフが毎月20時間の手作業から解放される場合、月40万円×2倍÷160時間×20時間＝10万円/月の削減効果として計上できます。
Step3：RFP作成とベンダー選定
ゴールと現状分析が揃ったら、RFP（提案依頼書）を作成して、ベンダーに提案を依頼します。RFPには、プロジェクトの背景と目的、現行システムの構成、実現したい機能・非機能要件を盛り込みます。加えて、スケジュール、予算感、評価基準も示します。
レガシーシステムのリプレイスでは、特に「現行機能の現状踏襲をどこまで求めるか」を明確にしておく必要があります。「現行と同じことができればよい」とだけ伝えると、ベンダーは機能を過剰に盛り込みがちで、見積もりが膨らむ原因になります。
複数のベンダーから提案を受けるなら、3〜5社程度に絞り込み、同じ条件で比べられるよう評価シートを事前に用意しておくと、判断が容易になります。
Step4：要件定義（現行踏襲の罠を避ける）
ベンダーを選定したら、要件定義フェーズに入ります。レガシーシステムのリプレイスで最も陥りやすい罠が「現行踏襲」です。「今やっていることを全部新システムでもできるようにしてほしい」という要求は、一見合理的に聞こえます。
現行システムには、「誰も理由を知らないが変えると怖いから残している処理」や「本来はExcelで管理すべきだが誰かがシステムに組み込んだ例外処理」が含まれていることが多くあります。これを全部新システムに移そうとすると、カスタマイズが膨らみ、コストと工期が大幅に超過します。推奨されるのは、「Fit to Standard（業務をシステムの標準機能に合わせる）」の考え方です。
この考え方では、パッケージの標準機能で業務を組み直し、カスタマイズはどうしても必要なものだけに絞ります。この判断を現場担当者だけに任せると、「うちはこの処理がないと困る」という反論が相次ぎがちです。そのため、プロジェクトオーナー（経営層・CIO）が「カスタマイズの承認ゲート」を設けることが欠かせません。
Step5：設計・開発
要件定義が承認されたら、設計・開発フェーズに進みます。この段階で大切なのは、発注側が受け身にならないことです。設計書のレビューに現場キーマンを加えず、ベンダーが作ったものを承認するだけの体制では、後から「こんな動きになるとは思わなかった」という認識のずれが生まれます。
追加要件や仕様変更が出たら、変更管理台帳に記録し、工数・コスト・スケジュールへの影響をその都度確認します。「追加費用はかかりません」という口頭の合意は、後でトラブルになりがちです。そのため、軽微な変更でも書面やメールで残してください。
工程別の費用配分は、一般的に、開発・実装が全体の50〜60%を占めます。要件定義は10〜15%、設計は10〜25%、テストは5〜10%程度です。
Step6：データ移行・クレンジングとテスト3段階
レガシーシステムのリプレイスで最も工数がかかり、成否を左右するのが「データ移行」です。長年使われたシステムには、表記の揺れ（同一顧客が「山田商事」「ヤマダ商事」などと複数存在する）や未使用・重複データ、システム間の不整合など、大量の「汚れ」が蓄積しています。
商社E社（従業員200名規模）の事例では、20年分の顧客データが3システムに分散していたため、統合とクレンジングだけで4ヶ月を要しました。この隠れコストを見落とすと、予算が大きく圧迫されます。将来の監査に備えて、売掛金・買掛金の残高は「1円の差異も許容しない」姿勢で検証します。150円の差異が出ても、端数処理ミスかデータ移行不備かを明細で追跡し、1円単位で原因を特定する必要があります。
テストは3段階で行うことが推奨されます。まず「サンプル移行テスト」で代表的なデータパターンを使って動作を確認し、次に「全件移行テスト」で実データ全量を移行して件数・金額・処理結果を突合します。最後に「移行リハーサル」で、本番と同じ手順・同じ時間帯でカットオーバー作業を一通り演習します。
Step7：本番切り替えと定着化支援
いよいよ本番カットオーバーです。カットオーバー前に、「カットオーバー後にどのような問題が発生したら旧システムに戻すか」という切り戻し基準を明文化し、発注側とベンダー双方で合意しておく必要があります。
ある食品メーカーの事例では、この切り戻し基準の合意がないまま本番稼働に突入した結果、新旧データの在庫数量に不整合が生じ、受発注・出荷・製造が長期停止するという深刻な事態に陥りました。この失敗の本質は、「何があれば切り戻すか」という意思決定のプロセスを省略したことにあります。
本番稼働後の定着化支援も欠かせないフェーズです。操作マニュアルの整備と全社員向けのトレーニングを実施し、新システムへの移行後も一定期間はサポート窓口を設けることで、現場の混乱を最小化できます。
移行方式の比較と選び方
レガシーシステムのリプレイスでは、新旧システムをどう切り替えるかという「移行方式」の選択が、リスクとコストに大きく影響します。主な移行方式は、切り替えの範囲と時期によって異なります。
一括移行・段階移行・並行移行・パイロット移行の特徴
「一括移行（ビッグバン）」は、特定の日付に旧システムを停止し、新システムに一気に切り替える方式です。移行期間が短くコストも抑えられる一方で、問題が起きると影響が全社に及ぶため、リスクは4方式の中で最大です。
十分なテストとリハーサルを経ないまま一括で切り替えると、前述した食品メーカーのような深刻な事態を招く可能性があります。「段階移行」は、機能モジュールや部門・拠点ごとに順番に新システムへ移す方式です。問題が起きても影響を限定できるため安全性が高く、レガシーシステムのリプレイスで最もよく採用されます。
「並行稼働」は、一定期間、新旧システムを同時に稼働させてデータを突合・比較しながら移行する方式です。安全性は最も高いものの、二重運用によるコストと現場の負担が増大します。「パイロット移行」は、特定の部門や拠点を先行して移行し、そこで得た知見を本格展開に活かす方式で、大規模組織のリプレイスで有効です。
自社に合った移行方式の選び方
移行方式の選択は、「リスク許容度」と「コスト」のトレードオフです。24時間365日稼働が求められる製造・物流・金融系のシステムでは、一括移行のリスクが非常に高いため、段階移行や並行稼働が原則になります。
一方で、比較的業務の切れ目を作りやすい年度替わりや期末・期首のある業種では、一括移行を選ぶケースもあります。中小企業や一人情シス体制では、二重運用の負担が大きい並行稼働より、リスクを小さなモジュール単位に分割した段階移行が現実的です。
移行方式は、ベンダーに任せきりにせず、発注側がリスク感度を持って選ぶことが大切です。
失敗しないための5つのポイント
ガートナーの調査によると、ITプロジェクトの75%が進行中に何らかの失敗を経験しているとされています。レガシーシステムのリプレイスは規模が大きいぶん、失敗の影響も甚大です。
ここで挙げるポイントを押さえると、プロジェクトの成功確率を大きく高められます。
チェンジマネジメント：現場の抵抗を克服する方法
レガシーシステムのリプレイスで最大の障壁の一つが、現場の「変化への抵抗」です。「慣れていないから今のままがいい」「Excelの方が使いやすい」「自分の仕事が奪われるのでは」という心理的抵抗は、長年同じシステムを使い続けてきた組織で特に顕著に現れます。これを「会社が決めたことだから使え」と強制で押さえ込むのは、逆効果になりがちです。
まず、「なぜリプレイスが必要か」を全員に丁寧に伝える説明会を開き、不安を受け止めます。次に、現場の意見をシステムに反映するため、現場キーマンをプロジェクトメンバーに加えます。そして、反対派でも発言力のある人を「アーリーアダプター」として取り込み、「実際に使ってみたら便利だった」と発言できる状況を意図的に作ります。
定着化は、カットオーバー後も続きます。稼働後3〜6ヶ月は、継続的なサポートと改善が必要です。
ベンダーコントロール：選定後の進行管理
ベンダーを選んだ後に、発注側が「後はお任せします」とプロジェクトから離れてしまうのは、多くの失敗プロジェクトに共通するパターンです。そこで、週次の定例会議を設け、「今週の進捗」「課題・リスク」「次週のアクション」を必ず議題に入れます。これにより、遅延を早期に見つけて対処しやすくなります。
特に注意が必要なのは、「仕様外です（追加費用が発生します）」という主張への対応です。仕様の曖昧さから、「これは仕様の範囲内か、追加か」という議論が頻繁に起きます。そこで、要件定義の時点で仕様書の精度を高め、「仕様外と言われた際の合意プロセス」を契約書やプロジェクト計画書に明記しておくのが有効です。
フェーズの移行判断にも、明確な基準を設けることを推奨します。たとえば、ILUO評価フレームワークを活用し、検証担当者が「U（理解・実行可能）」レベルに到達していることをフェーズ移行の条件にします。これにより、「テスト完了とはいえ現場が使えていない」という問題を未然に防げます。
契約・法務の落とし穴（責任分解・下請法）
システム開発の契約には、「請負契約」と「準委任契約」の2種類があります。請負契約では、ベンダーが成果物の完成を約束し、要件どおりのシステムが納品されなければ契約不適合責任（瑕疵担保責任）が問われます。一方、準委任契約は作業の遂行を約束するもので、成果物の保証はありません。
レガシーシステムのリプレイスのように仕様が複雑で変化しやすい場合は、要件定義を準委任、開発を請負とする「ハイブリッド契約」を採用するケースが増えています。また、発注規模によっては下請法（下請代金支払遅延等防止法）が適用され、代金を受領後60日以内に支払う義務が生じる場合があります。
ベンダーへの支払いサイクルを社内の通常フローのまま設定すると、法令違反になるリスクがあります。そのため、契約締結の前に確認しておくことが欠かせません。
切り戻し基準の設定と「1円の差異も許容しない」検証
カットオーバー前に「切り戻し判断基準」を文書にしておくことは、リプレイスでは欠かせません。切り戻し基準には、「どのような障害が発生したら旧システムへ戻すか」「判断はいつ・誰が行うか」「旧システムへの切り戻し手順と所要時間」を明記します。
前述の食品メーカーAの事例は、まさにこの基準がなかったために起きた事故でした。新旧データの照合観点（件数・金額・計算ロジック・締め処理）の定義が不足したまま本番稼働に踏み切り、受発注・在庫の不整合が連鎖して、出荷・製造が長期停止する重大な事態に発展しました。
会計データの突合では、「1円の差異も許容しない」姿勢で臨むことが求められます。わずかな差異でも放置すると、数ヶ月後の監査で発覚し、差異の追跡に膨大な工数がかかります。差異が出たら、端数処理ミスかデータ移行不備かを明細レベルで特定する習慣を徹底してください。
見積もり変動は「構造的」：発注側が持つべき正しい理解
「最初の見積もりから大幅に費用が増えた」というトラブルは、レガシーシステムのリプレイスで頻繁に起きます。ただ、必ずしもベンダーの悪意や怠慢ではなく、「構造的な変動」が原因のケースがほとんどです。プロジェクトの初期段階では要件が固まっておらず、ベンダーは「超概算」で費用を提示するしかありません。
要件定義が進み、非機能要件（処理速度・セキュリティ・可用性）や外部連携の詳細が明らかになるたびに、見積もりは「概算」から「確定見積もり」へと精度が上がり、金額も変わります。そのため、発注側はこの構造を理解したうえで、「確定見積もりはいつ出るか」「どの時点で追加費用が確定するか」をプロジェクト計画書に明記しておくことが大切です。
また、レガシーシステムのリプレイスで特に費用が膨らみやすい要因は、「カスタマイズの積み重ね」です。ある製造業では、標準パッケージに70%ものカスタマイズを施した結果、費用が当初予算の2.5倍にまで膨らみました。カスタマイズの承認ゲートを設けることの重要性は、こうした事例からも明らかです。
成功事例・失敗事例から学ぶ
理論や手順だけでなく、実際のプロジェクトの成功・失敗事例から学ぶことで、最も実践的な知識が得られます。ここで取り上げる事例は、抽象的なリスクを具体的な教訓として理解する参考になります。
失敗事例：切り戻し基準の欠如と性能見積もりの甘さ
食品メーカーAの事例は、並行稼働設計の不備が引き起こした失敗の典型例です。新旧データの照合観点（件数・金額・計算ロジック・締め処理）の定義が不足し、切り戻し基準も合意されないままカットオーバーを迎えた結果、受発注・在庫の不整合が連鎖して、出荷・製造が長期停止しました。
この事例で特に教訓となるのは、「問題が起きてから基準を決めようとした」という意思決定の遅れです。危機的状況では冷静な判断が難しく、「もう少し待てば直るかもしれない」という期待から、旧システムへの切り戻しのタイミングを逃してしまいます。
別の失敗事例の建築業B社では、大容量データや連携バッチの性能見積もりが甘く、稼働後に深刻なレスポンス問題が起きました。設計段階で机上比較に偏り、PoC（概念実証）が不足していたことが原因で、工期延伸と大幅な予算超過を招いています。性能要件は、「それほど速くなくてよい」といった曖昧な定義では不十分で、処理件数・応答時間・ピーク時の負荷を数値で決める必要があります。
成功事例：段階移行と明確なKPIが生んだ成果
製造業A社（従業員100名規模）では、レガシーな会計・販売管理システムのリプレイスを段階移行で実施した結果、月次決算の所要日数が3週間から1週間に短縮されました。成功の要因は、「月次決算3週間→1週間」という具体的なKPIを開始時に設定し、すべての意思決定をそのゴールに照らして行ったことです。
「現行踏襲か標準機能か」の議論になるたびに、「このカスタマイズは決算短縮に寄与するか」と問い直したことで、不要なカスタマイズを抑えられました。別の例として、ゼネラルリンクでは、複数システムに分散していた情報の手作業集計をリプレイスで廃止し、月次決算を約3営業日短縮しました。
大企業の事例では、鹿島建設がERPで文書管理を一か所に集め、年間100万枚以上の紙書類を削減し、現場と本社のリアルタイム情報共有を実現しました。これらの成功事例に共通するのは、「具体的な数値目標の設定」「段階的なアプローチ」「現場の巻き込み」の3つです。
まとめ
レガシーシステムのリプレイスは、属人化・ブラックボックス化・保守費用の増大・2025年の崖という4つの固有課題に直面する企業にとって、避けては通れない経営課題です。
本記事で解説した進め方は、「現状分析→ゴール設定→RFP作成→要件定義→設計開発→データ移行・テスト→カットオーバー」という7ステップを、一つずつ丁寧に踏むことが成功の鍵です。
特に、上流工程（現状分析・ゴール設定）への投資と、切り戻し基準の明文化が欠かせません。食品メーカーAの失敗事例が示すとおり、「後で決めればよい」という先送りが、プロジェクトを致命的な危機に追い込みます。
チェンジマネジメントに代表される「人」への対応、ベンダーとの契約・コントロールの実務知識、データ移行での「1円の差異も許容しない」検証姿勢は、技術面だけでは解決しにくい課題です。この記事でも、こうした課題を取り上げました。
一人情シスや兼任担当者しかいない中小企業でも、「現状分析→ゴール設定→段階移行」という基本の流れを守れば、大企業と同じ原則で安全にリプレイスを進められます。
リソースが限られる場合は、外部コンサルタントを上流工程の支援に活用し、自社の意思決定の質を高めることが、コスト以上の価値をもたらします。
全体ガイドの記事として、レガシーシステムリプレイスの完全ガイドをご覧ください。
開発を相談する前に読みたい無料ホワイトペーパーをご覧ください。
・レガシーシステム刷新の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
刷新計画の検討にご活用ください。
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。