レガシーシステムリアーキテクチャの発注/外注/依頼/委託方法について

「ドキュメントがほぼ存在しないCOBOLシステムをどうやって発注すればいいのか」「契約後に追加費用が雪だるま式に膨らんで困っている」——レガシーシステムのリアーキテクチャ（再設計・モダナイゼーション）を発注しようとした際に、このような壁にぶつかる担当者・経営者は少なくありません。通常のシステム開発案件とは異なり、レガシーシステムのリアーキテクチャは「そもそも現状が把握しきれていない」という根本的な難しさがあります。

経済産業省の「DXレポート2.0」でも指摘されているように、国内企業の基幹システムの約6割は2025年時点で21年以上前に構築されたレガシーシステムであり、その多くが仕様書の不備・属人化・技術者の高齢化という三重の課題を抱えています。こうした状況下での外注・発注は、適切な進め方を知らないと、プロジェクト炎上・追加費用の青天井・社内知識の喪失という最悪のシナリオに陥るリスクがあります。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・レガシーシステムリアーキテクチャの完全ガイド

本記事では、COBOL・メインフレーム・古いJavaシステムなどのレガシーシステムリアーキテクチャを外注・発注する際の方法論を、発注前の準備から契約形態の選択・プロジェクト体制・よくあるトラブルとその回避策まで、実務レベルで詳しく解説します。

レガシーシステムリアーキテクチャ発注前の準備（仕様書なし状態への対処含む）

レガシーシステムのリアーキテクチャ発注において、最初にして最大の壁となるのが「発注前の準備」です。通常の新規開発案件であれば要件定義書を用意すれば足りますが、レガシーシステムの場合はその前段階として「現状把握（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ドキュメント）を受け取った後で、別ベンダーに本格発注の競合見積もりを取ることも可能になります。

レガシーシステムを長年保守してきた社内エンジニアやベテラン担当者は、「暗黙知」を大量に抱えています。コードには書かれていない業務ルール・例外処理の理由・過去のバグ修正の経緯などです。これらの知識は、リアーキテクチャを成功させるうえで欠かせない情報であり、発注前に「知識移転プラン（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ヶ月という規模感が一般的です。なお、準委任型でも成果物（マイルストーン成果・ドキュメント・動作確認済みコード）の定義と品質基準を契約に明記しておくことで、「作業したが成果がない」というリスクを回避できます。

近年、「Migration as a Service（MaaS）」と呼ばれるサブスクリプション型の契約モデルが、特に大手SIerや専門ベンダーの間で普及しはじめています。MaaSは月額固定料金でリアーキテクチャの実行・運用・継続的改善までを包括的に提供するモデルで、クラウドベンダー（AWS・Azure・GCP）がパートナー企業と連携して提供するケースも増えています。

MaaSの主なメリットは、①初期費用の平準化（月額30万〜300万円程度）、②ベンダーが継続的に改善責任を持つため品質インセンティブが働く点、③内製エンジニアを持たない企業でも運用まで任せられる点です。一方、デメリットとしては、長期契約（3〜5年）が前提のためベンダーロックインリスクがあること、自社のシステム要件が特殊な場合に対応できないことがあります。MaaSを選択すべきケースは、「自社にIT運用リソースがなく、外部に継続的に任せたい」「段階的なモダナイゼーションを長期的に進めたい」「初期投資を抑えてROIを確認しながら進めたい」という状況です。なお、MaaSを選ぶ際は「中途解約条件」「データのポータビリティ（持ち出し可能か）」「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ヶ月。このように分割することで、①各フェーズで費用対効果を検証してから次フェーズを判断できる、②フェーズ完了時に別ベンダーへの切り替えが可能になる（競争原理の維持）、③予算承認を経営陣に段階的に求めやすくなる——というメリットがあります。フェーズ分割契約においては、各フェーズの「成果物定義」「完了判定基準」「次フェーズへの前提条件」を契約書に明記することが重要です。

発注から完了までのプロジェクト体制

レガシーシステムのリアーキテクチャは、通常の新規開発とは異なるプロジェクト体制が求められます。特に発注者側の関与度が成否を左右する要因として、業界全体で認識されています。ここでは、発注者側・ベンダー側それぞれに必要な役割と、過渡期における責任分界点の考え方を解説します。

レガシーシステムリアーキテクチャにおいて、発注者側が最低限用意すべき役割は以下の通りです。①プロジェクトオーナー（経営層）：予算承認権限を持ち、フェーズ継続判断・組織内の優先度調整を担います。週1回程度の状況報告受領と意思決定が主な役割です。②プロジェクトマネージャー（社内PM）：ベンダーとの窓口となり、週次の進捗確認・変更管理・リスク管理を担います。システム開発の経験があることが望ましく、ない場合は外部PMO（プロジェクトマネジメントオフィス）の活用も検討してください。③業務有識者（ドメインエキスパート）：現行システムの業務ルール・例外処理・業務上の制約を知っている人材です。週10〜20時間程度の関与が求められます。④社内技術有識者（COBOL担当者など）：現行システムの技術的な詳細を理解している人材です。Phase 0では特に集中的な関与が必要になります。

なお、社内にプロジェクトマネジメントの経験者がいない場合、外部PMO会社（月額100万〜300万円程度）を活用してベンダーのPMと並走させる「バイモーダルPM体制」が、大規模レガシーリアーキテクチャの現場で採用されています。発注者側PMOの役割は「ベンダーの管理」ではなく「ビジネス要件の継続的なインプット」と「組織内調整」であり、この点を明確にしておくことがトラブル防止につながります。

レガシーシステムのリアーキテクチャで特に難しいのが、新旧システムの「並行稼働期間」における責任分界点の管理です。この期間は、旧システムと新システムが同時に本番稼働するため、データの整合性・バグ発生時の原因究明・ユーザー対応の責任範囲が曖昧になりがちです。

責任分界点の明確化には、以下の事項を契約書またはプロジェクト計画書に明記することが必須です。①新旧システム間のデータ一致確認の方法と頻度（例：日次でデータ比較バッチを実行し、差異が0.1%以内を合格基準とする）、②本番環境での不具合発生時のエスカレーションフローと対応責任者（旧システム起因か新システム起因かの判別フロー含む）、③カットオーバー（切り替え）判断基準（例：新システムで30日間連続稼働・エラー率0.05%以下・レスポンスタイム旧比120%以内）、④旧システムの廃止スケジュールとデータ保管義務期間——これらを事前に合意することで、「何か問題が起きたときにどちらが対応するか」という水掛け論を防ぐことができます。過渡期の並行稼働は、コスト（旧システムの維持費が継続発生）とリスクの両面から、できる限り短期間（3〜6ヶ月以内）で完了させることが望ましいです。

レガシーシステムのリアーキテクチャを発注するベンダー選定では、通常の新規開発とは異なる評価基準が必要です。重視すべき評価項目を以下に挙げます。①レガシーシステム移行実績：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つのチェックポイントを以下にまとめます。①発注前にAS-IS整理を実施したか（コード量・業務フロー・外部連携の棚卸し）——これがないと見積もり精度が大幅に低下します。②仕様書が不完全な場合はPhase 0（現状調査フェーズ）を独立して発注したか——Phase 0なしの一括発注はリスクが高すぎます。③知識移転プランを策定したか（社内COBOL有識者の関与スケジュール含む）——暗黙知の消失はプロジェクト失敗の原因になります。④契約形態を現状の不確実性に合わせて選択したか（一括請負・準委任・MaaSの適切な選択）——フェーズ分割契約を積極的に活用してください。⑤スコープバウンダリー文書と変更管理プロセスを確立したか——スコープクリープの防止なしに成功はありません。⑥過渡期の責任分界点（新旧並行稼働時の対応フロー）を契約書に明記したか——曖昧なまま進めると水掛け論になります。⑦コンティンジェンシー予算（当初予算の15〜25%）を確保しているか——想定外の発見事項は必ず出ると考えて備えることが重要です。

レガシーシステムリアーキテクチャの発注を進めるにあたって、あわせて確認しておきたいリソースをご紹介します。費用相場については「システムリアーキテクチャの費用相場」の記事で詳しく解説しています。Phase 0から本格移行までの全体像については「システムリアーキテクチャ完全ガイド」をご参照ください。ベンダー選定の際は、実績のある会社3〜5社に声をかけ、Phase 0の見積もり（小規模なPoC提案）を依頼することから始めることをお勧めします。レガシーシステムのリアーキテクチャは、発注者が主体的に関与し、適切なプロセスで進めることで、DXの根幹となる取り組みを成功させることができます。本記事がそのための第一歩として参考になれば幸いです。

▶ 詳細はこちら：システムリアーキテクチャ完全ガイド【要件定義〜移行完了まで徹底解説】

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・レガシーシステムリアーキテクチャの完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。