長年使い続けてきたレガシーシステムをそのまま放置すると、保守コストの肥大化やブラックボックス化、技術者不足といった問題が年々深刻になっていきます。経済産業省が示した「2025年の崖」では、レガシーシステムを刷新できないまま放置した場合、2025年以降に最大で年間12兆円もの経済損失が生じる可能性が指摘されており、移行は多くの企業にとって待ったなしの経営課題となっています。とはいえ、自社だけでデータ移行や基盤刷新を完遂するのは現実的に難しく、外部のベンダーへ発注・外注・委託して進めるケースが大半です。
本記事では、レガシーシステム移行を外部に発注・委託する際の具体的な進め方を、発注前の準備から契約形態の使い分け、ベンダーロックインを防ぐ工夫、データ移行ならではの落とし穴、費用相場までを一気通貫で解説します。とくに移行プロジェクトで失敗の引き金になりやすい「ダウンタイム」「並行稼働」「移行リハーサル」の管理を実務・プロジェクトマネジメントの視点から掘り下げます。発注を検討している担当者の方が、社内稟議やベンダー選定でそのまま使える具体策を持ち帰っていただける内容です。
▼全体ガイドの記事
・レガシーシステム移行の完全ガイド
レガシーシステム移行を外部に発注する全体像
レガシーシステム移行を外部へ発注すると言っても、その範囲や進め方は一様ではありません。何を自社で担い、どこからをベンダーに委託するのかを最初に整理しておくことが、後の費用や責任分界点を左右します。まずは発注の対象となる作業領域と、移行という言葉が指す具体的な意味を押さえておきましょう。
発注できる作業範囲と移行が指すもの
レガシーシステム移行で外部に発注できる作業は、現状調査（アセスメント）、移行方式の設計、新基盤の構築、データ移行、テスト、本番切替、運用保守と多岐にわたります。移行と一口に言っても、サーバーやクラウドへの基盤移行を指す場合もあれば、データベースのデータ移行、アプリケーションそのものの作り替えを含む場合もあります。発注前にどこまでを含むのかを明確にしないと、後から「それは見積もりに入っていない」というトラブルが起こりがちです。
とくにレガシーからの移行では、既存システムの仕様書が失われていたり、属人化したまま稼働していたりするケースが珍しくありません。そのため、いきなり開発を発注するのではなく、まずは現状を可視化するアセスメントから委託するのが定石です。アセスメントの結果をもとに、どの手法でどこまで移行するかを判断していきます。
移行手法（7R・5類型）と発注範囲の関係
移行の手法は一般に7R、あるいは5類型として整理されます。代表的なものは、基盤だけを載せ替えるリホスト、一部を最適化するリプラットフォーム、コードを書き直すリライト、内部構造を整理するリファクタリング、ゼロから作り直すリビルドやリアーキテクチャです。さらに、別の市販製品へ置き換えるリプレース、不要な機能を思い切って廃止するリタイアも選択肢に入ります。
どの手法を選ぶかで、発注する作業範囲も費用も大きく変わります。たとえばリホストは比較的低コストで短期間に基盤移行できますが、技術的負債は残ったままになります。一方でリビルドは抜本的に刷新できる反面、要件定義から開発まで広範な発注が必要となり、費用も期間も大きくなります。ベンダーに丸投げで決めるのではなく、自社の目的と予算に照らして手法を選び、その上で発注範囲を確定させることが重要です。
発注前に社内で準備すべきこと
移行プロジェクトの成否は、ベンダーへ発注する前の社内準備で半分が決まると言っても過言ではありません。準備が不十分なまま発注すると、要件の手戻りや見積もりのブレが生じ、結果として費用も期間も膨らみます。発注前に固めておくべき要素を順に確認していきましょう。
現状の可視化と移行範囲の棚卸し
まず取り組むべきは、現行システムの現状可視化です。どの機能がどれだけ使われているか、どのデータがどこに格納され、どのシステムと連携しているかを棚卸しします。この作業を怠ると、移行後に「使っていたはずの機能が動かない」「連携先のデータが欠ける」といった事故につながります。
可視化の過程では、実は使われていない機能や重複したデータが見つかることもよくあります。ここで「勇気ある廃止」を判断し、不要な機能を移行対象から外せば、移行コストと将来の維持費を同時に削減できます。削減できた予算をコア業務の刷新に回すという発想が、限られた投資を有効に使う鍵になります。
RFP（提案依頼書）の作成と要件の言語化
発注先を比較検討するうえで欠かせないのがRFP（提案依頼書）です。RFPには、移行の目的、対象範囲、現行システムの概要、移行で実現したい状態、想定スケジュール、予算感、評価基準などを記載します。これがあることで、各ベンダーから同じ土俵での提案と見積もりを引き出せます。
とくにデータ移行を伴う案件では、移行対象データの種類と量、許容できるダウンタイム、並行稼働の有無といった条件をRFPに明記しておくことが大切です。これらの前提が曖昧だと、ベンダーごとに想定が異なり、見積もりが比較できなくなります。要件を言語化しきれない場合は、前段のアセスメントを準委任契約で先に委託し、その成果物をRFPの土台にする進め方も有効です。
推進体制づくりと経営層の合意形成
移行は情報システム部門だけで完結するものではなく、現場部門や経営層を巻き込んだ全社的な取り組みになります。発注前に、社内の推進責任者と各部門の窓口を決め、誰が意思決定するのかを明確にしておきましょう。IPAの調査では、CDOやCIOといったCxOを設置している企業ほど情報共有が円滑で、可視化や内製化が進み、モダナイゼーションが順調に進む傾向が示されています。
経営層の合意を得る際は、初期コストの大きさだけを訴えても理解が得られにくいものです。移行後に運用コストがどれだけ下がるかを試算した「運用コスト低減シミュレーション」を示すと、投資対効果を具体的に伝えられます。レガシーを放置した場合のリスクと、移行後に得られる効果を数字で並べることが、稟議を通すうえでの説得材料になります。
委託の進め方と契約形態の使い分け
外部委託で見落とされがちなのが、契約形態の選び方です。フェーズごとに適した契約を使い分けることで、発注側のリスクを抑えながらプロジェクトを進められます。ここでは準委任契約と請負契約の違いと、ロックインを避けるための契約上の工夫を解説します。
準委任契約と請負契約の使い分け
移行プロジェクトは、要件が固まりにくいアセスメント・要件定義フェーズと、成果物が明確な開発・移行フェーズに分かれます。要件が流動的な前半は、作業の遂行そのものを対価とする準委任契約が向いています。準委任なら、調査の結果に応じて柔軟に方針を見直せます。
一方、仕様が固まった後の開発・データ移行フェーズは、完成した成果物に責任を負う請負契約が適しています。請負にすることで、納品物の品質や完成義務をベンダーに課せます。アセスメントは準委任、開発は請負という形でフェーズごとに契約を切り替えると、発注側が抱えるリスクをコントロールしやすくなります。最初から全工程を一括の請負で契約すると、要件変更のたびに高額な追加費用が発生しがちなので注意が必要です。
ベンダーロックインを防ぐ契約の工夫
特定のベンダーに依存しすぎると、その後の改修や乗り換えのたびに足元を見られ、コストや交渉力で不利になります。これがベンダーロックインの問題です。これを防ぐには、契約の段階で対策を盛り込んでおく必要があります。
具体的には、ソースコードの著作権の帰属、設計書や運用手順書などのドキュメント納品、運用に必要な権限の引き渡しを契約条項として明記します。また、SLA（サービス品質保証）や責任分界点を定義し、どこまでがベンダーの責任で、どこからが自社の責任なのかを線引きしておくことも重要です。特定の独自技術への過度な依存を避け、標準的な技術を採用してもらうことも、将来の選択肢を残すうえで効果的です。
データ・基盤移行の落とし穴と発注時の確認点
レガシーシステム移行で最もトラブルが起きやすいのが、データと基盤の移行です。とくにダウンタイムの管理、並行稼働の設計、移行リハーサルの実施は、発注時にベンダーへ確認しておくべき重要ポイントになります。ここを軽視すると、本番切替の当日に業務が止まるという最悪の事態を招きます。
ダウンタイム最小化と並行稼働の設計
業務を止められる時間（ダウンタイム）には限りがあります。週末や夜間の限られた時間で切り替えるのか、それとも一定期間は新旧システムを並行稼働させながら段階的に移すのかを、発注前に方針として決めておく必要があります。一気に切り替えるビッグバン方式はリスクが高く、可能であれば段階的な移行が推奨されます。
並行稼働を選ぶ場合は、新旧両方のシステムを同時に動かすため、サーバーやライセンスの費用が二重にかかります。この「二重コスト」は見積もりから抜け落ちやすい隠れコストの代表格です。並行稼働の期間をどう設定し、その間のデータ整合性をどう担保するかを、ベンダーとあらかじめすり合わせておきましょう。
移行リハーサルとデータクレンジング
本番のデータ移行を一発勝負で行うのは極めて危険です。実際のデータを使って移行手順を通しで試す「移行リハーサル」を複数回実施し、所要時間や発生する問題を事前に洗い出すことが欠かせません。リハーサルを通じて、当日のタイムスケジュールや切り戻し（ロールバック）の手順を確立しておきます。発注時には、リハーサルの実施回数が提案に含まれているかを必ず確認しましょう。
また、古いシステムのデータには、文字コードの違いや外字、表記の揺れ、重複といった問題が潜んでいます。これらを整える「データクレンジング」は想定以上に工数がかかり、隠れコストになりやすい領域です。さらに、コードだけを刷新してもデータモデルが古いままでは、拡張性や変更速度は改善しません。データ構造そのものを見直すかどうかも、発注範囲を決める際の論点になります。
発注時の費用相場と見積もりの内訳
発注を検討するうえで気になるのが費用です。レガシーシステム移行の費用は、手法や規模によって大きく変動しますが、おおよその相場感と内訳を理解しておくことで、見積もりの妥当性を判断できるようになります。ここでは費用相場と、見落とされやすい隠れコストを解説します。
費用相場と見積もりの構成要素
レガシーシステム移行の費用は、小規模なものでおよそ500万円程度から、大規模な基幹刷新になると2億円を超えることもあります。費用の大半はエンジニアの人件費、すなわち工数（人月）で決まります。アセスメント、設計、新基盤の構築、データ移行、テスト、本番切替といった各フェーズに、それぞれ工数が積み上がっていきます。
見積もりを受け取ったら、各フェーズの工数と単価が妥当かを確認しましょう。データ移行やテストの工数が極端に少ない見積もりは、後から追加費用が発生する危険信号です。複数社から相見積もりを取り、内訳の粒度や前提条件を比較することで、適正な価格を見極められます。
見落としやすい隠れコスト
初期の開発費用だけに目を奪われると、後から想定外の出費に苦しむことになります。代表的な隠れコストには、新旧並行稼働による二重のインフラ・ライセンス費用、データクレンジングの工数、新基盤を運用する社内メンバーへの教育費、クラウドやコンテナといった新技術のランニングコストがあります。
これらは初期費用の見積もりには現れにくいものの、トータルで見ると無視できない金額になります。発注時には、移行後の運用フェーズも含めたライフサイクル全体のコストで比較することが大切です。コストを抑えたい場合は、前述の「勇気ある廃止」で移行対象を絞り込むこと、ビッグバンを避けて段階的に移行することが有効な手立てになります。
失敗しない発注先の選定基準
同じ移行案件でも、発注先のベンダーによって成否は大きく分かれます。技術力だけでなく、自社の業務をどれだけ理解してくれるか、プロジェクトをやり遂げる体制があるかといった観点で見極める必要があります。ここでは選定の具体的な基準を解説します。
移行実績と業務理解度の確認
まず確認したいのは、同種・同規模の移行実績です。とくにレガシーからの移行や大量データの移行経験があるかは重要な判断材料になります。実績を尋ねる際は、成功事例だけでなく、どんな課題にどう対処したかを具体的に聞くと、対応力が見えてきます。
あわせて、自社の業務や業界への理解度も確認しましょう。業務を理解しているベンダーは、現場の例外的な運用やデータの特性を踏まえた提案ができます。逆に技術だけが得意なベンダーは、現場に合わない標準機能を押し付けたり、Fit to Standard（標準機能への業務適合）の判断を誤ったりするリスクがあります。
プロジェクト体制と契約姿勢の見極め
移行プロジェクトは長期にわたるため、安定した推進体制を持つベンダーを選ぶことが重要です。プロジェクトマネージャーの経験、要員の確保状況、トラブル時のサポート体制を確認しましょう。IPAは2030年に最大で約79万人のIT人材が不足すると予測しており、人材確保が安定しているかは年々重みを増す観点です。
契約姿勢も見極めのポイントです。ソースコードやドキュメントの納品、運用権限の引き渡しといったロックイン回避の要望に誠実に応じてくれるか、責任分界点やSLAの明確化に前向きかを確認します。これらに渋るベンダーは、発注後に主導権を握られる懸念があります。コンサルティングから開発、運用までを一気通貫で支援できるパートナーであれば、フェーズ間の引き継ぎロスが少なく、プロジェクト全体を安定して進められます。
まとめ
レガシーシステム移行を外部に発注する際は、何を委託するかの範囲設定から始まり、現状可視化やRFP作成といった社内準備、フェーズに応じた準委任契約と請負契約の使い分け、ベンダーロックインを防ぐ契約上の工夫までを押さえることが成功の前提になります。とくにデータ・基盤移行では、ダウンタイムの最小化、並行稼働の設計、複数回の移行リハーサル、データクレンジングといった実務的な論点が、プロジェクトの安全性を大きく左右します。
費用は500万円から2億円超まで規模で変動し、並行稼働の二重コストや教育費といった隠れコストを含めたライフサイクル全体で比較することが重要です。発注先は、移行実績と業務理解度、安定した推進体制、ロックイン回避に応じる契約姿勢で見極めましょう。IPAの調査が示すとおり、経営層を巻き込み、運用コスト低減シミュレーションで投資対効果を示しながら進めることが、移行を確実にやり遂げる鍵となります。本記事を発注準備の指針として活用していただければ幸いです。
▼全体ガイドの記事
・レガシーシステム移行の完全ガイド
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、弊社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。