レガシーシステムのモダナイゼーションの発注/外注/依頼/委託方法について

レガシーシステムのモダナイゼーションを外部に発注する流れは、現状分析から移行管理までの5段階で進みます。依存関係と成果物を先に見える形にし、段階を追って検証していくことが、成功の土台になります。

# レガシーシステムのモダナイゼーションの発注/外注/依頼/委託方法について

「古いシステムをどうにかしなければ」と感じながら、どこに相談すればよいか分からず、プロジェクトが進まないまま時間だけが過ぎていく。こうした状況に悩む情報システム担当者やIT責任者は少なくありません。

レガシーシステムのモダナイゼーションは、企業の競争力そのものを左右する重大な投資です。経済産業省の「DXレポート」では、レガシーシステムを温存し続けた場合、2025年以降に最大12兆円／年もの経済損失が生じると試算されています。そのため、この課題は業界全体で喫緊の対応を求められています。

1. 現行システムと課題の可視化
2. 更改の目的と対象範囲の決定
3. 候補先の実績と提案の比較
4. 契約条件と責任範囲の確認
5. 移行と運用の段階的な管理

モダナイゼーションの全体像は、レガシーシステムのモダナイゼーションの完全ガイドで確認できます。

レガシーシステム刷新を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。

レガシーシステムのモダナイゼーション外注の全体像

レガシーシステムのモダナイゼーションを外注する際は、まず「何を外部に任せ、何を社内で管理するか」を明確にすることが欠かせません。

発注側の企業が要件定義や意思決定に主体的に関わり続けることが、プロジェクト成功の前提になります。開発をまるごと任せれば済むわけではありません。

経済産業省の調査では、大企業の74%にレガシーシステムが残存していると報告されています。そのため、モダナイゼーションの外注需要は急速に高まっています。

外注できる範囲と発注の種類

外注の範囲は、プロジェクトの性質や社内のリソースによって大きく変わります。構想策定から保守・運用までの5フェーズがあり、それぞれを一括で委託するか、要件定義・設計のようにフェーズ別に分けて発注するかを選べます。

一括発注は、責任の所在が明確になる一方で、ベンダーへの依存度が高まります。フェーズ分割発注では、コストを柔軟に調整できる反面、複数のベンダー間の連携管理を発注側が担う必要があります。

発注の性質には、特定の成果物を定義して発注するプロジェクト型と、月額固定で継続的に支援を受けるサービス型があります。初期フェーズでは、現行システムの調査や要件定義にプロジェクト型を使い、開発・運用の段階でサービス型に切り替える組み合わせが、実務では多く採用されています。

発注先の種類と特徴

発注先は、自社のプロジェクト規模や予算、求めるスピードに合わせて選びます。候補は大きく4種類で、大手SIer（システムインテグレーター）は大規模案件の実績が豊富な一方、費用が高額になりやすく、担当者が入れ替わるリスクもあります。

中堅・独立系SIerは、特定の業界や技術領域に強く、大手よりコストパフォーマンスに優れる場合が多いです。担当者との距離が近いのも特徴です。「ITコンサルティングファーム」は、上流工程に強く、経営課題とシステム課題を一体で解決したい場合に適しています。

ただし、ITコンサルティングファームは実装フェーズまで一貫して担うケースが少なく、別途開発ベンダーへの発注が必要になることもあります。「DX支援専門会社」は、クラウドネイティブ化やDevOps導入など最新技術に特化し、スタートアップ的なスピード感で進められる反面、大規模案件の実績が少ない場合もあります。

発注前の準備と現状調査

モダナイゼーションの外注で失敗する最大の原因のひとつが、発注側の準備不足です。ベンダーはシステム開発の専門家ですが、発注側の業務やシステムの内情を最初から理解しているわけではありません。

発注前に社内で情報を整理し、ベンダーが適切な提案をできる材料をそろえることが、プロジェクト成功の出発点になります。

現行システムのAS-IS分析と課題の可視化

発注前の最初のステップは、現行システムの全体像を正確に把握することです。具体的には、アーキテクチャ構成図と、使用している言語・フレームワーク・ミドルウェアの一覧を文書化します。加えて、データベース構成と主要テーブルの関係図、外部システムとのインターフェース一覧、業務フローとの対応関係も、まとめておきます。

こうした「現状（AS-IS）」のドキュメント化を「リドキュメント」と呼びます。長年の改修が重なり属人化したレガシーシステムでは、特に重要な作業です。

AS-IS分析では、技術的な構成を把握するだけでなく、業務の視点で課題を整理することも必須です。たとえば、「現行システムのどこがボトルネックになっているか」「どの部分がビジネスの成長を阻んでいるか」を見ます。さらに、開発・保守コストの内訳を過去3〜5年分集計すると、維持コストが膨らんでいる箇所を特定でき、優先順位付けに活用できます。

TO-BE像の定義とモダナイゼーション目標の設定

AS-ISの分析が終わったら、次は「あるべき姿（TO-BE）」を定義します。TO-BEは技術目標にとどまらず、ビジネス上の成果と結び付けて定めます。モダナイゼーションの手法には、リホスト、リファクタリング、リプラットフォームのほか、リライトやリプレースがあり、その選択もこのTO-BEを起点に判断します。

たとえば、「新機能のリリースサイクルを現在の半年から1か月以内に短縮する」「システム障害によるダウンタイムを年間10時間未満に抑える」といった目標を立てます。「クラウドへの移行によりインフラコストを30%削減する」のように、測定可能な指標（KPI）と合わせて定めます。

すべてを一気に刷新する全量リプレースは、コストと期間が膨大になるリスクがあります。そのため、多くのケースでは、優先度の高い業務から段階的にモダナイズする「ストラングラーフィグパターン」が推奨されています。TO-BEが曖昧なまま発注を進めると、途中での方向転換が頻発し、コスト超過や納期遅延の原因になります。

RFP（提案依頼書）の作成と発注ドキュメントの整備

複数のベンダーから横並びで提案を受け、公平に比べるには、RFP（Request for Proposal＝提案依頼書）が欠かせません。RFPに①から⑥の要素を盛り込むと、ベンダー各社が同じ条件で提案できる環境が整います。

①プロジェクトの背景と目的（現状の課題・解決したいビジネス課題）。
②対象システムの概要（規模・技術スタック・ユーザー数・トランザクション量）。
③希望するモダナイゼーション手法の方向性（あれば）。
④スケジュール要件（希望する完了時期・マイルストーン）。
⑤予算の大枠（記載できる場合）。
⑥評価基準と提案の提出形式を明記します。

RFPを送る前に「RFI（Request for Information＝情報提供依頼書）」を使うと、ベンダーの初期的な考え方や得意領域、参考事例を集められます。こうして集めた情報は、RFPの送付先の絞り込みと評価基準の精度向上に役立ちます。RFI → RFP → 提案評価という段階的なプロセスを踏むと、最終的な発注先の選定精度が大きく高まります。

発注先の選び方と評価のポイント

RFPへの回答（提案書）がそろったら、いよいよ発注先の選定評価に入ります。ここで見るのは、提案書の内容が豪華かどうかより、自社の課題を正確に理解し、現実的な解決策を示しているかという点です。

評価を数字で比べるために、スコアリングシートを作り、複数の評価軸で各社を採点することを推奨します。

技術力と実績の確認方法

モダナイゼーション案件の技術力は、「得意技術」を聞くだけでなく、同種のシステム（業種・規模・技術スタック）で類似案件を完遂した実績があるかを重点的に見ます。特に重要なのは、「どのようなアーキテクチャに刷新したか」「移行時のリスクをどう管理したか」「ゼロダウンタイム移行や段階的リリースの経験があるか」といった具体的な内容です。

提案書に載った事例は、実際の担当者（プロジェクトマネージャーやアーキテクト）と面談し、プロジェクトの詳細を直接ヒアリングすると確かめられます。また、候補先の顧客（リファレンス）に問い合わせられるかを確認すると、ベンダーの信頼性を多面的に評価できます。

クラウドサービス（AWS・Azure・Google Cloud）のパートナー認定や、特定技術領域での資格保有状況も、技術力を客観的に示す指標になります。

プロジェクト管理体制とコミュニケーションの確認

技術力と並んで見るべきなのが、プロジェクト管理体制です。モダナイゼーションのプロジェクトは期間が長く、要件変更やリスク対応が頻繁に起きます。そのため、プロジェクトマネジメントの質が成否を大きく左右します。

確認するのは、専任のプロジェクトマネージャーが配置されるか、週次・月次の定例報告の仕組みが整っているか、課題とリスクの管理プロセスが明確かといった点です。特に注意したいのは、提案時の担当者と、実際に開発を担当するメンバーが異なるケースです。

こうした問題は、外注でよく見られるトラブルです。そのため、契約前に、実際の開発チームの体制（プロジェクトマネージャー・アーキテクト・主要開発者の紹介）を確認しておく必要があります。また、発注側のIT担当者との連絡方法（ツールや頻度）や、変更要求の受け付けの流れも、事前に合意しておきましょう。

ベンダーロックインリスクと長期運用コストの評価

発注先を選ぶ際に見落としがちなのが、長期的なベンダーロックインのリスクです。特定のベンダー独自のフレームワークや、クラウドのプロプライエタリなサービスに過度に依存すると、将来のベンダー変更や内製化が著しく難しくなります。

選定時には、移行完了後に自社のエンジニアが保守・運用できる構成になっているかを確かめます。また、ドキュメントや設計情報の社内への引き継ぎが契約に含まれているかも見ておく必要があります。さらに、初期開発費用だけでなく、完了後の保守・運用費用（ランニングコスト）も含めた総所有コスト（TCO）で比べることを強く推奨します。

初期費用が安くても保守費用が高騰するケースや、追加開発のたびに高額な見積もりが出てくるケースは珍しくありません。そのため、長期のパートナーとして付き合えるかを、財務面と関係構築面の両側から総合的に判断しましょう。

発注から契約締結までの流れ

発注先が決まったら、次は契約締結の段階に進みます。大規模で長期にわたるモダナイゼーションでは、契約形態の選択と契約書の内容確認が、後のトラブルを防ぐうえで重要な役割を果たします。

契約形態の選択：請負契約 vs 準委任契約

システム開発の外注で使われる契約形態は、主に「請負契約」と「準委任契約」の2種類です。請負契約は、特定の成果物（システム）を完成させることを約束する契約で、仕様を明確に定義できる場合に向いています。

一方、準委任契約は、一定の業務を誠実に遂行することを約束する契約です。要件が流動的な案件や、アジャイル開発のように仕様を反復的に詰めていく開発に適しています。また、近年は、スプリントごとに成果物を定めながら準委任で進める、ハイブリッドな方法も増えています。

モダナイゼーションのプロジェクトでは、フェーズによって適した契約形態が異なります。要件定義・調査は仕様が未確定なため準委任が一般的で、設計・開発は、スコープが明確になった段階で請負（または機能単位の請負）に切り替えることが多くなっています。自社のプロジェクトの性質に合わせて、フェーズごとに契約形態を選びましょう。

契約書に必ず盛り込むべきポイント

モダナイゼーションの契約書には、通常のシステム開発契約に加えて、特有の条項を盛り込む必要があります。まず「成果物の定義と検収基準」では、何をもって納品・完了とするかを明確にします。特に移行フェーズでは、データ移行が完全かどうかを確かめる基準や、性能要件を満たしたかの確認方法を、具体的に決めておきます。

次に「知的財産権の帰属」では、開発したソースコード、設計ドキュメント、ノウハウの権利が発注側に帰属するかを確認します。ベンダーが独自ライブラリを使う場合は、その利用条件と、将来の保守の継続性も確かめる必要があります。

さらに「情報セキュリティと機密保持」では、現行システムの設計情報や業務データをベンダーに渡すことになるため、機密保持契約（NDA）の締結と、データの取り扱いルールを明確にします。その他、プロジェクトの中断・解約の条件、不具合発生時の対応責任の範囲、SLA（サービスレベルアグリーメント）なども重要な条項です。

発注後のプロジェクト推進と失敗しないためのポイント

契約後にプロジェクトが動き出すと、発注側の関わり方が成否を大きく左右します。「発注したらベンダーに任せればよい」という姿勢では、モダナイゼーションのプロジェクトは高い確率で失敗します。

発注側も一定のリソースを投入し、ベンダーとの連携体制を築き続けることが求められます。

発注側のガバナンス体制の整備

発注側がプロジェクトに関わるためには、社内のガバナンス体制を整える必要があります。具体的には、経営層のプロジェクトオーナーやPMO（プロジェクト管理事務局）を含めて、業務部門とIT部門の担当者の役割と権限を明確にした組織図を作ります。

特にモダナイゼーションは業務部門への影響が大きいため、IT部門だけでなく、実際にシステムを使う業務部門の主要な担当者を、早い段階からプロジェクトメンバーに加えることが不可欠です。また、意思決定の流れは事前に設計しておく必要があります。

要件変更、設計変更、スコープ変更が起きたときに、誰がどのレベルで承認するかを決めておかないと、ベンダーへの回答が遅れ、プロジェクトが停滞するおそれがあります。週次の進捗報告会に加えて、月次でステアリングコミッティ（経営レベルでの状況確認）を設けると、プロジェクトの方向性がぶれにくくなります。

典型的な失敗パターンとリスク対策

モダナイゼーションの外注プロジェクトでよく起きる失敗には、いくつかの典型例があります。まず「スコープクリープ」と呼ばれる現象は、プロジェクトの途中で機能追加の要求が際限なく増え続け、コストと期間が当初の2〜3倍に膨らむケースです。

これを防ぐには、契約時にスコープを明確に定義し、変更管理プロセス（変更要求の受け付け・影響評価・承認・計画変更）を厳格に運用することが必要です。次に「データ移行の失敗」は、既存データの品質問題（重複・不整合・欠損）や、本番環境での移行テストの不足により、本番稼働後にデータの不整合が発覚するケースが非常に多く見られます。

データ移行は技術作業であると同時に、業務の意味でのデータ整合性を確かめる作業であるため、業務部門と連携した移行検証計画を必ず策定してください。また「移行後のサポート体制の空白」も、典型的なリスクです。本番稼働直後は不具合や操作の問い合わせが集中するため、稼働後の一定期間（最低3か月）は、ベンダーの集中サポート体制を契約に盛り込むことを強く推奨します。

内製化・知識移転への取り組み

モダナイゼーションを外注する際に将来を見据えて欠かせないのが、内製化と知識移転の計画です。プロジェクト完了後に社内エンジニアが新しいシステムを自律的に保守・改修できる状態を目指すことが、ベンダー依存からの脱却と長期的なコスト削減につながります。

そのためには、ドキュメント（設計書、コメント付きソースコード、インフラ構成図）の整備と、社内エンジニアへの技術移転プログラムを、契約のスコープに含めることが欠かせません。また、完了後も一定期間は保守・運用をベンダーに委託しながら、社内エンジニアをプロジェクトに参加させ、OJT形式で技術を習得させる方法が、実務では効果的です。

経済産業省の調査によると、IT人材の需給ギャップは拡大傾向にあります。社内のIT人材の育成と確保は、企業の中長期的な競争力に直結するテーマとして位置付けられています。

モダナイゼーション外注の費用相場と見積もりのポイント

モダナイゼーションの費用は、対象システムの規模や複雑さ、採用する手法、発注先の種類によって大きく変わります。相場観を持ったうえで見積もりを取ると、提案内容の妥当性を判断できるようになります。

規模別・手法別の費用目安

リホスト（クラウドリフト）のように既存アプリケーションをほぼそのままクラウドに移す手法は、比較的費用を抑えられます。小〜中規模のシステムであれば、500万円〜2,000万円程度が一般的な相場感です。

リライト（新技術でのコードの書き直し）やリアーキテクト（マイクロサービス化など、構造の刷新）を伴うプロジェクトでは、中規模で2,000万円〜8,000万円、大規模になると1億円以上になるケースも珍しくありません。

コンサルティングフェーズ（現状調査・AS-IS/TO-BE分析・モダナイゼーション戦略策定）を別途発注する場合は、500万円〜2,000万円程度が目安です。本番稼働後の保守・運用費用は、初期開発費用の15〜20%程度を年間コストとして見込むのが一般的です。これらはあくまで参考値で、正確な費用はシステムの詳細を踏まえた見積もりで確かめる必要があります。

適正な見積もりを得るためのポイント

適正な見積もりを得るには、まず複数社（3〜5社）から相見積もりを取ることが基本です。1社しか見ない場合は、相場がわからず、高い見積もりに気づけないおそれがあります。また、「費用の内訳を工程別・作業別に提示してほしい」と依頼すると、各社の作業量の前提を比べられます。

見積もりが大きく食い違う場合は、安いほうを選ぶ前に、前提条件や作業範囲の違いを詳しく確かめます。たとえば、1社が2,000万円、別の1社が8,000万円といった差が出ることもあります。なお、安すぎる見積もりには、後から追加費用が発生する「追加見積もり商法」や、品質・スケジュールの問題が潜んでいる可能性があります。

見積もりの妥当性を判断する社内のIT人材が不足している場合は、独立したITコンサルタントに第三者評価（ITデューデリジェンス）を依頼する方法も有効です。

まとめ：モダナイゼーション発注の成功に向けた要点

レガシーシステムのモダナイゼーションを外注・委託で成功させるには、まず発注前の準備が出発点になります。現行システムのAS-IS分析とTO-BE定義を徹底して行い、RFPを作成してから複数社に提案を依頼します。

発注先の選定では、技術力と実績だけでなく、プロジェクト管理体制、コミュニケーションの質、長期的なコストを総合的に評価することが大切です。契約形態はフェーズに応じて請負と準委任を使い分け、契約書には知的財産権の帰属、データの取り扱い、移行後のサポート体制などの重要条項を盛り込みましょう。

発注後は、社内のガバナンス体制を整えて、プロジェクトに主体的に関わり続けることが成功の鍵です。丸投げでは、失敗のリスクが高まります。

スコープクリープ、データ移行の失敗、内製化の後回しといった典型的な失敗パターンを事前に認識し、対策を契約や計画に織り込んでおくことで、リスクを大きく下げられます。

モダナイゼーションは一朝一夕に完了しない長期のプロジェクトです。それでも、適切なパートナーと協力体制を築けば、企業のDXと競争力強化を着実に前へ進めることができます。

RFP作成前に、レガシーシステム刷新の完全ガイドブックと【2026年最新版】AI駆動開発の完全ガイドブックをご覧ください。

会社紹介