レガシーシステムのリアーキテクチャは、発注前の準備、契約形態の選択、発注側の体制づくりの順に進めるのが基本です。
国内企業の基幹システムの約6割は、2025年時点で21年以上前に構築されたレガシーシステムで、その多くが仕様書の不備・属人化・技術者の高齢化という三重の課題を抱えています（経済産業省「DXレポート2.0」）。進め方を誤ると、プロジェクトの炎上や追加費用の膨張、社内知識の喪失を招きかねません。
▼全体ガイドの記事
・レガシーシステムリアーキテクチャの完全ガイド
▼ システムリアーキテクチャの総合情報はこちら
レガシーシステム刷新を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
レガシーシステムリアーキテクチャ発注前の準備（仕様書なし状態への対処含む）
レガシーシステムのリアーキテクチャ発注で、最初にして最大の壁となるのが発注前の準備です。通常の新規開発であれば要件定義書を用意すれば足りますが、レガシーシステムでは、その前段階として現状把握（AS-IS整理）が欠かせません。現状把握を怠ると、発注後に想定外の発見事項が次々と出てきて、追加費用が膨らむ原因になります。
現状アーキテクチャの棚卸し：把握すべき項目
発注前に最低限実施したいAS-IS整理として、次の項目を棚卸しすることが推奨されます。まず、システム構成図（ハードウェア、ソフトウェア、ネットワーク構成）と、バッチ処理・オンライン処理の一覧および処理フローを整理します。次に、データベーステーブルの一覧とおおよそのデータ量、外部システムとのインターフェース（EDI、API、ファイル連携など）を洗い出します。
さらに、業務機能の一覧と利用ユーザー数・頻度の目安も押さえます。これらは、社内の有識者やCOBOL担当者から可能な限りヒアリングして文書化します。特にCOBOLシステムでは、コード行数（KLOC）を把握しておくことが見積もりの精度向上に直結します。
業界の目安では、COBOL 10万行相当のリアーキテクチャに6〜18ヶ月・数千万〜1億円超の費用がかかるとされ、コード量はベンダーが規模感をつかむ指標です。静的解析ツール（CobWeb・Micro Focusのツールなど）でCOBOLのソースを解析し、依存関係・複雑度・使用プログラム数を洗い出せば、発注の精度が格段に上がります。
仕様書が存在しない・不完全な場合の対処法
レガシーシステムの現場では、「仕様書が存在しない」「あるにはあるが、20年前のもので実際の動作とまったく一致しない」という状況がよく見られます。この場合、完全なドキュメントを作成してから発注しようとすると、それだけで半年〜1年以上かかってしまいます。そこで効果的なのが、「ドキュメント化を発注スコープに含める」アプローチです。
具体的には、Phase 0（フェーズ0）として「現状調査・AS-ISドキュメント作成フェーズ」を独立して発注する形態が主流になっています。このフェーズでは、ベンダーのエンジニアが社内のCOBOL有識者や業務担当者にヒアリングし、既存コードを解析してドキュメントを作成します。中規模システムの費用の目安は500万〜2,000万円程度、期間は3〜6ヶ月程度です。
Phase 0を経ることで、その後の本格的なリアーキテクチャの見積もり精度が大幅に向上し、「契約後の青天井追加費用」という最大のリスクを回避できます。さらに、Phase 0の成果物（AS-ISドキュメント）を受け取ったあとで、別のベンダーに本格発注の競合見積もりを取ることも可能になります。
社内COBOL知識保有者との知識移転プランの策定
レガシーシステムを長年保守してきた社内エンジニアやベテラン担当者は、コードには書かれていない「暗黙知」を大量に抱えています。業務ルール、例外処理の理由、過去のバグ修正の経緯などがそれにあたります。この知識はリアーキテクチャを成功させるうえで欠かせないため、発注前に「知識移転プラン（Knowledge Transfer Plan）」を策定しておく必要があります。
知識移転プランには、次の要素を含めることが推奨されます。まず、社内COBOL技術者、業務担当者、元担当者など、知識保有者をリストアップします。次に、週1〜2時間のヒアリングを3〜6ヶ月続ける形を目安に、スケジュールを組みます。さらに、ヒアリング内容はConfluenceなどのナレッジ管理ツールへ格納し、知識保有者の関与期間と役割を明確にします。
特に定年退職が近い技術者がいる場合は、リアーキテクチャプロジェクトへの参画を優先して確保することが、プロジェクトの成否を左右します。そのため、人材確保のための社内調整は発注前に完了させておくことが、発注後のトラブル防止に直結します。
契約モデルの比較（一括請負 vs 準委任 vs MaaS）
レガシーシステムのリアーキテクチャでは、契約形態の選択が発注後のリスク管理に直接影響します。新規開発では一括請負が主流ですが、レガシーシステム特有の不確実性の高さから、準委任契約やMaaS型を選ぶ例も増えています。それぞれの特徴と選択基準を理解しておくことが大切です。
一括請負型：メリット・デメリットと適切なユースケース
一括請負型（固定価格契約）は、成果物の完成を約束し、それに対して報酬を支払う契約形態です。発注者にとっては「予算が確定する」という最大のメリットがあります。一方で、レガシーシステムのリアーキテクチャにそのまま適用すると、重大な問題が起きやすくなります。
レガシーシステムでは、現状分析を進めるにつれて「隠れた業務ルール」「想定外のデータ異常」「文書化されていない外部連携」が次々と見つかります。一括請負では、当初スコープに含まれていない発見事項への対応がすべて追加費用の交渉になるため、プロジェクト後半に「追加変更管理（Change Control）」が膨大になるリスクがあります。
Standish Groupのレポートによると、大規模ITプロジェクトの56%が当初予算を30%以上超過しており、その多くがこのパターンです。そのため、一括請負型は、Phase 0（現状調査）が完了してAS-ISが明確になった後のフェーズか、比較的シンプルなリフト＆シフト移行（機能変更なしのクラウド移行）に限定して適用するのが賢明です。
準委任型：不確実性が高いレガシー案件に適した理由
準委任型（タイム＆マテリアル型）は、作業の実施そのものに対して報酬を支払う契約形態で、月額の人月単価×工数で費用が決まります。発注者にとっては「費用が確定しない」という不安がありますが、レガシーシステムのリアーキテクチャでは、最も現実的な選択肢のひとつです。
準委任型には、発見事項が増えても追加費用の交渉なしに対応できる柔軟性があります。スコープを段階的に決めながら進められる機動性や、発注者がプロジェクトの進め方に直接関わりやすい点もメリットです。なお、成果物（マイルストーン成果、ドキュメント、動作確認済みのコード）の定義と品質基準を契約に明記しておけば、「作業したが成果がない」という事態を避けられます。
費用の管理では、月次・四半期ごとに予算上限（キャップ）を設け、上限に達した時点で双方が合意のうえで継続を判断する「キャップ付き準委任」も、実務で活用されています。中規模レガシーシステムの場合、エンジニア3〜5名、月額300万〜600万円、期間12〜24ヶ月という規模感が一般的です。
MaaS（サブスクリプション型）：新興の契約モデルと選択基準
近年は、「Migration as a Service（MaaS）」と呼ばれるサブスクリプション型の契約モデルが、大手SIerや専門ベンダーの間で普及しはじめています。MaaSは、月額固定料金でリアーキテクチャの実行・運用・継続的な改善までを包括的に提供するモデルです。クラウドベンダー（AWS・Azure・GCP）がパートナー企業と連携して提供するケースも増えています。
MaaSの主なメリットは、初期費用を月額30万〜300万円程度に平準化できる点です。また、ベンダーが継続的な改善の責任を持つため品質へのインセンティブが働き、内製エンジニアがいない企業でも運用まで任せられます。一方で、長期契約（3〜5年）が前提のため、ベンダーロックインのリスクがあります。
自社のシステム要件が特殊な場合は、対応できないこともあります。MaaSは、IT運用の人材がおらず継続的に任せたい、段階的なモダナイゼーションを長期的に進めたい、初期投資を抑えてROIを確認しながら進めたいといった状況に適しています。なお、契約書では、中途解約条件、データのポータビリティ（持ち出し可能か）、SLA（稼働率・応答時間保証）を必ず明確にしてください。
フェーズ分割契約のメリット：リスクを段階的に分散する方法
レガシーシステムのリアーキテクチャで最も効果的なリスク管理手法が、「フェーズ分割契約」です。プロジェクト全体をまとめて発注する代わりに、フェーズごとに契約を結び、各フェーズの完了後に次へ進むかどうかを判断する方式です。
典型的な分割例は、Phase 0（現状調査・PoC）が500万〜2,000万円・3〜6ヶ月、Phase 1（コアシステムのリアーキテクチャ）が3,000万〜1億円・6〜12ヶ月です。残りは、Phase 2（周辺システム・連携機能の移行）が2,000万〜8,000万円・6〜12ヶ月、Phase 3（旧システム廃止・最適化）が1,000万〜3,000万円・3〜6ヶ月という構成です。
このように分割すると、費用対効果を確かめてから次フェーズを判断でき、完了時に別のベンダーへ切り替えることも可能になります。さらに、予算承認を経営陣に段階的に求めやすくなります。なお、各フェーズの成果物定義、完了判定基準、次フェーズへの前提条件は、契約書に明記しておくことが欠かせません。
発注から完了までのプロジェクト体制
レガシーシステムのリアーキテクチャでは、通常の新規開発とは異なるプロジェクト体制が求められます。特に、発注者側の関与の度合いが成否を左右する要因として、業界全体で認識されています。
発注者側に必要な役割とスキルセット
発注者側で最低限用意すべき役割は、予算の判断、ベンダーとの窓口、業務の知識、技術の知識で、いずれも社内の誰かが担う必要があります。
- プロジェクトオーナー（経営層）：予算の承認権限を持ち、フェーズごとの継続判断と組織内の優先度調整を担います。
- プロジェクトマネージャー（社内PM）：ベンダーとの窓口です。システム開発の経験があることが望ましく、週次の進捗確認、変更管理、リスク管理を担います。
- 業務有識者（ドメインエキスパート）：業務ルール、例外処理、業務上の制約を知る人材で、週10〜20時間程度の関与が求められます。
- 社内技術有識者（COBOL担当者など）：技術の詳細を理解している人材で、Phase 0では特に集中的な関与が必要です。
プロジェクトオーナーの主な役割は、週1回程度の状況報告を受けて意思決定することです。
なお、社内にプロジェクトマネジメントの経験者がいない場合は、外部PMO（プロジェクトマネジメントオフィス）会社（月額100万〜300万円程度）を活用できます。その形として、ベンダーのPMと並走させる「バイモーダルPM体制」も、大規模レガシーリアーキテクチャの現場で採用されています。
発注者側PMOの役割は「ビジネス要件の継続的なインプット」と「組織内調整」で、ベンダーの管理とは区別して明確にしておくと、トラブル防止につながります。
過渡期の責任分界点の明確化：新旧システム並行稼働時のリスク管理
新旧システムが同時に本番稼働する並行稼働期間は、旧システムの維持費がかかり続けるため、コストとリスクの両面から3〜6ヶ月以内に終えるのが望ましいです。一方で、責任分界点の管理が特に難しく、データの整合性、バグ発生時の原因究明、ユーザー対応の責任範囲が曖昧になりがちです。そのため、次の事項を契約書またはプロジェクト計画書に明記しておくことが必須です。
まず、新旧システム間のデータ一致確認の方法と頻度を決めます。例えば、日次でデータ比較バッチを実行し、差異が0.1%以内であれば合格とします。次に、本番環境での不具合発生時のエスカレーションフローと対応責任者を定めます。その際、旧システム起因か新システム起因かを判別するフローも含めます。
カットオーバー（切り替え）の判断基準は、例えば新システムで30日間連続稼働し、エラー率0.05%以下、レスポンスタイムが旧比120%以内であるといった形で示します。旧システムの廃止スケジュールとデータ保管義務期間も、あわせて合意しておきます。これらを事前に合意しておけば、問題が起きたときにどちらが対応するかという水掛け論を防げます。
発注先ベンダー選定のポイント：レガシー特有の評価基準
レガシーシステムのリアーキテクチャを発注するベンダー選定では、通常の新規開発とは異なる評価基準が必要です。重視すべき評価項目は4つです。まず、レガシーシステムの移行実績を確認します。COBOLからJavaへの移行、メインフレームからクラウドへの移行など、類似した技術スタックの実績件数と規模感を見ます。実績が3件以上あることを最低条件とするのが現実的です。
次に、ドキュメントがない状態からコード解析でAS-ISを復元できる、リバースエンジニアリング能力を確認します。自動変換ツールの活用実績（例：Raincode・Heirloom Computing・TSRI・BlueFocusなど）も評価ポイントです。
さらに、スコープクリープ（想定外の発見事項による範囲拡大）が発生した際の変更管理プロセスを持っているかを確認します。「変更管理委員会（CCB）」の仕組みがあるかどうかが目安になります。最後に、長期保守能力として、担当エンジニアの固定、ドキュメント整備、SLAといった保守対応力を確認します。移行完了後5年間の保守実績があるベンダーが理想的です。
よくあるトラブルと回避策
レガシーシステムのリアーキテクチャ発注では、通常の開発案件よりも多くのトラブルパターンが存在します。事前に知っておけば、プロジェクトの成功確率を大幅に高められます。
スコープクリープの防止策：レガシー特有の発見事項対策
最も頻繁に発生するトラブルは、当初スコープの際限なき拡大（スコープクリープ）です。現状調査を進めるほど、「このモジュールも移行が必要」「この連携も考慮しないといけない」といった発見が続き、期間と費用が青天井になりがちです。IPA（情報処理推進機構）の調査では、レガシーマイグレーション案件の約45%が、当初計画より工期を50%以上延長しており、その主因がスコープクリープです。
対策として、まず、移行対象に含めるものと含めないものを列挙した「スコープバウンダリー文書」を発注前に作り、契約の添付資料として位置づけます。次に、発見事項が生じるたびに「変更管理ログ（Change Log）」へ記録し、当月・当四半期の変更件数と累積の影響を可視化します。
さらに、各フェーズに「スコープ凍結日（Scope Freeze Date）」を設け、それ以降の追加要件は次フェーズ以降で対応すると決めます。移行対象外や後回しの機能は「バックログ」として管理し、優先度をつけて次フェーズに組み込みます。これらの仕組みを契約時点から合意しておけば、「追加になってもしかたない」という雰囲気での拡大を防げます。
データ移行・データ品質問題のトラブルと対処法
長年運用されてきたデータの品質問題は、プロジェクト後半に表面化しがちです。「コード値が定義されていないのに実データに存在する」「文字コードが混在していてUTF-8に変換できないレコードがある」「本来NULLのはずの項目に意味不明な固定値が入っている」といった問題があります。こうした問題は移行テストで初めて発覚し、大幅な手戻りを引き起こします。
回避策として最も効果的なのは、「データプロファイリング」を早期に実施することです。Phase 0の段階で、対象データベースの全テーブルをTalend Data Quality、Informatica Data Quality、AWS Glue DataBrewなどのツールで分析します。そのうえで、NULL率、値の分布、文字コード、重複率、ユニーク値の一覧を洗い出します。
その結果をもとに、問題の件数と対処コストを早く見積もれば、本格移行での手戻りを減らせます。「データ変換ルール文書」は発注者とベンダーの双方で作成・合意し、各フィールドの変換ロジック、例外処理、欠損値の扱いを明記します。本番カットオーバーの3〜6ヶ月前から、移行リハーサル（ドライラン）を複数回行い、手順・所要時間・ロールバック手順を確かめることが成功のカギです。
追加費用の青天井化を防ぐ契約上の工夫
レガシーシステムのリアーキテクチャで「契約後に追加費用が雪だるま式に膨らんだ」という経験を持つ発注者は、少なくありません。その原因の多くは、スコープの定義が曖昧で「発見事項はすべて追加」という状態になっていることです。さらに、変更管理が機能せず「とりあえず進める」文化になっていることや、発注者側の承認が遅れて手戻りが増えることも挙げられます。
追加費用の青天井化を防ぐための契約上の工夫として、まず、当初予算の15〜25%を不確実性対応の予算（コンティンジェンシー予算）として確保します。変更管理委員会の承認なしにはこの予算を使わないというルールを設けます。次に、1件の変更につきXX万円以下は担当者が承認し、それ以上は経営承認とする承認フローを契約書に記載します。
また、月次で費用上限を設け、超過した場合は追加作業を自動停止してスコープの優先度を再協議する「上限付き準委任」も活用できます。さらに、フェーズの完了条件を定義し、完了確認後に支払いが発生する「マイルストーン払い」を採用すると、成果物の品質を担保しながら費用を段階的に管理できます。
まとめ：レガシーシステムリアーキテクチャ発注の成功に向けた要点
COBOLやメインフレーム、古いJavaシステムなどのレガシーシステムリアーキテクチャを外注・発注する方法は、4つの観点から整理できます。
発注成功のための7つのチェックポイント
確認すべき点は、次の7つです。①発注前のAS-IS整理（コード量、業務フロー、外部連携の棚卸し）を済ませているか。これがないと、見積もり精度が大幅に低下します。②仕様書が不完全な場合に、Phase 0（現状調査フェーズ）を独立して発注しているか。Phase 0なしの一括発注は、リスクが高すぎます。
③知識移転プランを策定し、社内COBOL有識者の関与スケジュールを含めているか。暗黙知の消失は、プロジェクト失敗の原因になります。④契約形態が現状の不確実性に合っているか（一括請負・準委任・MaaSの適切な選択）。フェーズ分割契約の活用も積極的に検討してください。
⑤スコープバウンダリー文書と変更管理プロセスを確立しているか。スコープクリープの防止なしに、成功はありません。⑥過渡期の責任分界点を契約書に明記しているか。曖昧なままだと水掛け論になります。⑦コンティンジェンシー予算（当初予算の15〜25%）を確保しているか。想定外の発見事項は必ず出ると考えて、備えておく必要があります。
次のステップ：発注前に確認すべきリソース
レガシーシステムリアーキテクチャの発注を進めるうえで、あわせて確認しておきたいリソースを紹介します。費用相場については「システムリアーキテクチャの費用相場」の記事で詳しく解説しています。Phase 0から本格移行までの全体像や詳細な手順は、システムリアーキテクチャ完全ガイド【要件定義〜移行完了まで徹底解説】をご参照ください。
ベンダー選定の際は、実績のある会社3〜5社に声をかけ、Phase 0の見積もり（小規模なPoC提案）を依頼することから始めるのがお勧めです。レガシーシステムのリアーキテクチャは、発注者が主体的に関わり、適切なプロセスで進めることで、DXの根幹となる取り組みを成功させられます。本記事が、その第一歩として参考になれば幸いです。
開発を相談する前に、次の無料ホワイトペーパーもご活用ください。
レガシーシステム刷新の完全ガイドブックと、【2026年最新版】AI駆動開発の完全ガイドブックをご覧いただけます。
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。