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