業務システム移行の外注は、移行範囲と条件を先に整理し、工程に合う契約と委託先を選んで進めます。
データ移行や基盤の切り替えには専門知識と部門間の調整が要るため、外部へ任せる範囲が成否を左右します。経済産業省の「2025年の崖」が迫る今、判断の先送りは保守コストの肥大化と事業機会の損失に直結します。
▼全体ガイドの記事
・業務システム移行の完全ガイド
レガシーシステム刷新を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
業務システム移行の発注前に整理する事項
業務システム移行の発注で失敗する企業の多くは、自社の現状を十分に整理しないまま見積依頼に進んでしまっています。発注前の準備が曖昧なままだと、ベンダーは過大なバッファを積んだ見積を出さざるを得ません。その結果、コストが膨らみ、プロジェクトの途中で認識の食い違いも増えます。
そこで、まずは何を移行し何を捨てるのかという範囲を、発注側の社内で固めることが外注成功の出発点です。
現状の可視化とアセスメント
発注準備の第一歩は、現行システムの現状可視化（アセスメント）です。長年使い続けた業務システムは、機能やデータがブラックボックス化し、誰も全体像を把握できなくなっているケースが珍しくありません。そのため、どの機能が今も使われ、どのデータを移行対象にするのかを洗い出さなければ、移行の範囲も費用も見積もれません。
- 利用状況：使われている機能と、停止できる機能の区別
- 移行対象：必要なデータと、その保存期間
- 連携先：会計・在庫・CRMとの接続箇所
発注側は、このアセスメントで業務フローとデータの流れを図にまとめ、外部システムとの連携点を押さえます。周辺システムとの接続を見落とすと、移行後に業務が止まるおそれがあります。よって、現状把握の精度が、その後の見積精度と移行リスクを直接左右します。
IPAの調査は約4,000社を対象に行われ、799社が回答しました。CDOやCIOなどのCxOを設置した企業ほど、社内の情報共有や現状の可視化、内製化が進む傾向が示されています。その結果、モダナイゼーションも順調に進む傾向が見て取れます。
このため、発注前の現状把握を社内任せにせず、経営層を巻き込んだ体制で臨むことが望ましいといえます。
RFP（提案依頼書）の作成と要件の明確化
現状把握が済んだら、その内容をRFP（提案依頼書）に落とし込みます。要件が曖昧なままだと、各社の提案が前提から食い違い、横並びで比べられません。その結果、適正な発注先を選ぶことも難しくなります。
- 目的・範囲：移行の目的と対象システム
- データ・条件：件数、文字コード、外字や特殊コードの有無、許容できるダウンタイム
- 提案条件：予算感、希望日程、体制をそろえる
特に業務システム移行では、データ移行の要件をどこまで具体化できるかが鍵になります。条件が明確であれば、ベンダーは現実的な移行方式を提案しやすくなり、見積精度も上がります。
また、移行にあたっては「勇気ある廃止（リタイア）」の方針も検討しておくとよいでしょう。長年の運用で増えた不要な機能や使われていないデータをそのまま移すと、移行コストも維持費も膨らみます。発注前に捨てるものを見極め、その分の予算をコア機能の刷新に振り向けることで、費用対効果を大きく高められます。
委託の進め方と移行プロジェクトのステップ
業務システム移行を外注する場合でも、丸投げは禁物です。発注側と受注側が役割分担を決め、フェーズごとに成果物と判断の基準を定めながら進めることが、品質とコストの管理につながります。
移行プロジェクトは、いきなり全システムを切り替える「ビッグバン方式」を避け、段階的に進めるのが基本です。
移行手法（7R）の選定と委託範囲の決定
移行手法によって、作業範囲や費用、期間は変わります。代表的な考え方には「7R」や「5類型」があり、発注側は、リホスト（基盤だけ載せ替え）やリプラットフォームなどの中から目的に合う方法を選びます。
7Rには、リファクタリングやリライト（書き直し）、リビルド・リアーキテクチャ（再構築）のほか、不要なものを廃止するリタイアも含まれます。
- 基盤を移す：リホストやリプラットフォームを検討
- 構造を見直す：再設計や再構築が必要かどうかの判断
- 不要分を除く：廃止する機能やデータの決定
たとえばリホストは、比較的短期間かつ低コストで移行できます。一方で、古いデータモデルがそのまま残るため、移行後の拡張性や変更速度の改善は限られます。
コードだけを刷新しても、データモデルが古いままでは業務の俊敏性は上がりません。そのため、「手段の目的化」を避け、移行の目的に照らして手法を選び、その判断をベンダーと共有することが重要です。
委託範囲を決める際は、アセスメントから運用までのどこを外注するかを、発注側が工程ごとに切り分けます。すべてを一社に任せる一括委託は、管理がしやすい一方で、ベンダーへの依存度が高まります。
逆に、工程ごとに発注先を分けると、ロックインは避けやすくなります。ただし、全体を統制する難しさが増す点には注意が必要です。
データ移行・基盤移行とダウンタイム管理
業務システム移行の山場は、データ移行と基盤移行です。長年蓄積したデータには、文字コードの差異や外字、システム間で構造が合わないデータが混在しています。そのため、単純なコピーでは移行できないことがほとんどです。
データクレンジングとマッピングの工数を軽視すると、それが「隠れコスト」となって、後から予算を圧迫します。
- データ整備：クレンジングとマッピングの工数
- 切替条件：許容できる停止時間と切り替え手順
- 復旧手順：リハーサルと切り戻しの条件
移行当日に業務を止められる時間（ダウンタイム）には限りがあります。そのため、ダウンタイムをいかに最小化するかが、委託における重要なテーマになります。基幹業務であれば、夜間や休日の短い時間で切り替えを終えなければならず、そのための移行方式や手順をベンダーと詰めておく必要があります。
ダウンタイムを抑える代表的な手段が、新旧システムを一定期間同時に動かす「並行稼働」です。並行稼働を挟むと、新システムの動作を本番データで検証しながら段階的に移行でき、万一の際は旧システムに戻せます。ただし、二つのシステムを同時に維持する「二重コスト」が生じるため、並行稼働の期間と費用は発注前に見込んでおく必要があります。
そして、移行を成功させる決め手は、本番さながらに移行作業を試す「移行リハーサル」です。事前にリハーサルを繰り返せば、データ変換の不具合や想定外のダウンタイム超過を洗い出せ、本番での失敗確率を大きく下げられます。このため、リハーサルの実施回数と範囲は、委託契約に明記しておくことを強くおすすめします。
Fit to Standardと現場の巻き込み
移行を外注する際に陥りやすい失敗は、現行業務の例外ルールをすべてカスタマイズで新システムに再現しようとすることです。こうした進め方を続けると、開発が肥大化し、コストも期間も膨らみ、最悪の場合はプロジェクトが頓挫します。そのため、標準機能に業務を合わせる「Fit to Standard」の考え方を、発注側が先に持つことが移行成功の前提になります。
- 標準機能：標準に合わせられる業務の見極め
- 例外業務：残す例外と廃止する例外の仕分け
- 現場参加：変更理由の説明と、利用部門の巻き込み
あわせて、新しいシステムに対する現場の抵抗に向き合う、チェンジマネジメントも欠かせません。「前のシステムではできた」という声には、標準に合わせる理由を相手の立場に立って伝える必要があります。とりわけ、ここは外注先に任せきれない、発注側の役割です。
契約形態の使い分けとベンダーロックインの回避
業務システム移行の外注では、契約形態の選び方がリスク管理の要になります。契約形態を誤ると、想定外の追加費用が発生したり、成果物の品質を問えなくなったりします。そこで、工程の性質に応じて契約形態を使い分けることが、発注側のリスクを大きく抑えます。
準委任契約と請負契約の使い分け
移行プロジェクトでは、工程によって適した契約形態が異なります。要件がまだ固まりきっていない段階で完成を約束させると、かえって双方の柔軟性を奪ってしまいます。そのため、アセスメントや要件定義では、作業時間に対して対価を支払う「準委任契約」が適しています。
- 要件定義：不確実な工程では準委任が候補
- 開発・移行：仕様が確定してから請負が候補
- 運用：サービス品質の基準と責任の範囲
一方、要件と仕様が確定した設計・開発・データ移行のフェーズでは、成果物の完成責任をベンダーが負う「請負契約」が向いています。アセスメントは準委任、開発以降は請負という形で段階的に契約を切り替えることで、不確実性の高い前半のリスクと、成果物の責任を問いたい後半の要請を両立できます。
運用フェーズでは、SLA（サービス品質保証）に稼働率や障害対応時間などの基準を定め、発注側と受注側のどこまでを誰が受け持つかを明確にします。責任の所在が曖昧なまま運用に入ると、トラブル時の対応が遅れ、業務への影響が長期化します。
ベンダーロックインを防ぐ契約の工夫
特定のベンダーに過度に依存し、他社への切り替えが事実上できなくなる「ベンダーロックイン」は、移行発注における大きなリスクです。ロックインに陥ると、保守費用の交渉力を失い、次の刷新でも同じベンダーに頼らざるを得なくなります。これを防ぐには、契約段階での工夫が欠かせません。
- 権利・成果物：ソースコードの権利と納品条件
- 引き継ぎ：設計書や運用手順書の納品
- 運用権限：発注側が必要な権限を持てる状態
これらの条件は、契約書に具体的な文言として書き込みます。ソースコードやドキュメントが手元になければ、別のベンダーへ引き継ぐことすらできず、ロックインは避けられません。
加えて、特定ベンダー固有の技術や製品に過度に依存しないアーキテクチャを選ぶことも有効です。クラウドや標準的な技術を採用して将来の乗り換えの余地を残すと、長期的な選択の自由を確保できます。発注時点での少しの配慮が、数年後の交渉力を左右します。
費用相場と発注前に見込むべきコストの内訳
業務システム移行の費用は、対象システムの規模や採用する手法によって大きく変わります。一般的には数百万円規模からで、大規模な基幹システムの再構築では2億円規模に達することもあります。判断の際に大切なのは、見積に表れる初期費用だけでなく、運用フェーズまで含めた総コストで見ることです。
費用の内訳と隠れコスト
移行費用は、アセスメントから運用・保守までの段階ごとに分けて見ます。このうち発注側が見落としがちなのは、データ移行と並行稼働にかかる費用です。データクレンジングの工数や、新旧システムを同時に維持する負担は、当初の想定を超えやすい領域です。
- 調査・設計：アセスメントと設計の費用
- 移行作業：開発、データ整備、切り替えの費用
- 運用・保守：二重運用、ライセンス、教育費
さらに、新しい技術基盤を採用する場合は、クラウドやコンテナ運用の費用も「隠れコスト」として発生します。これらは初期の開発見積に含まれにくく、運用が始まってから表面化します。そのため、発注前にランニングコストまで含めた総額で予算を組むことが、後の予算超過を防ぎます。
経営層への稟議では、初期コストを比べるより、移行後の運用コストがどれだけ下がるかをシミュレーションで示すほうが効果的です。レガシー環境の保守費用や属人化のリスクを数字にし、移行で何年後に投資を回収できるかを明らかにすることで、投資判断を前に進めやすくなります。
コストを抑える発注の工夫
費用を抑える有効な手段は、前述の「勇気ある廃止」です。移行の対象を絞れば、データ移行とテストの工数を減らせ、その分の予算をコア機能の刷新に集中させられます。なお、何を捨てるかの判断は、総コストを大きく左右します。
- 対象を絞る：不要な機能やデータの除外
- 段階的に移す：移行範囲を区切って進める
また、ビッグバン方式を避けて段階的に移行する進め方も、リスクとコストの両面で有効です。一度に全システムを切り替えると、失敗時の影響が甚大で、やり直しのコストも膨大になります。各段階で得た知見を次に活かせるため、手戻りを減らせます。
発注先・委託先の選定基準
移行の成否は、最終的に発注先のベンダー選定で決まります。価格の安さだけで選ぶと、移行のノウハウやデータ移行の経験が足りず、かえって高くつくことも少なくありません。そこで、同じRFPをもとに複数社を比べ、実務面の力量を見極めることが大切です。
移行実績とデータ移行の経験
選定でまず確認すべきは、移行の実績と、データ移行の具体的な経験です。新規開発の実績が豊富でも、稼働中のシステムを止めずに移す経験は別物です。
- 移行実績：同規模・同業種の事例の有無
- 技術経験：文字コード変換や切り替えの経験
- 業務理解：自社業務を踏まえた提案かどうか
そのうえで、移行の実績は件数よりも、どの局面でどう対処したかを事例で聞くことが欠かせません。あわせて、自社の業務をどこまで理解しているかも、重要な評価軸です。業務の理解が浅いベンダーは、表面的な機能移行で終わり、Fit to Standardの判断や例外業務の整理まで手が回りません。
提案書を並べて読むと、各社の業務への踏み込みの差が見えてきます。見るべきは、現行の業務フローや例外業務まで触れた提案になっているか、つまり自社業務を踏まえた中身かどうかです。
体制と契約姿勢の確認
プロジェクトを支える体制と、契約への姿勢も見逃せません。体制は、移行の山場で誰がどう動くかを具体的に聞いて確かめます。体制が手薄なベンダーは、想定外の事態に対応しきれず、移行が長期化するおそれがあります。
- 責任者：PMの経験と意思決定体制
- 実行体制：リハーサルや並行稼働の人員
- 緊急対応：トラブル時の対応手順
契約への姿勢では、ソースコードやドキュメントの納品や、ロックイン回避への協力を渋らないかを見ます。これらを渋るベンダーは、長期的な囲い込みを意図している可能性があるため、注意が必要です。
IPAは、2030年に最大79万人のIT人材不足を見込んでいます。そのため、人海戦術に頼らず、内製化や継続的な保守を見据えたパートナーシップを築けるかも、選定の判断材料になります。
まとめ
業務システム移行の発注・外注・委託を成功させるには、発注前の現状可視化とRFP作成で範囲を固め、移行手法と委託範囲を見極めることが出発点になります。データ移行と基盤移行では、ダウンタイム、並行稼働、移行リハーサルの条件を、発注前に決めておきます。
二重コストやデータクレンジングなどの隠れコストは、発注前に見込んでおく必要があります。契約面では、アセスメントは準委任、開発以降は請負と使い分けてリスクを抑えます。また、ソースコードやドキュメントの帰属を明記して、ベンダーロックインを回避します。
費用は、初期コストだけでなく運用コストの低減をシミュレーションして判断します。発注先は、移行実績や業務理解、体制などの観点で、複数社を比べます。
「2025年の崖」と2030年のIT人材不足が迫るなか、実務とPMの視点を備えた発注で、移行を確実にやり遂げていただきたいと考えます。
▼全体ガイドの記事
・業務システム移行の完全ガイド
RFP作成前に読みたい無料ホワイトペーパーは次の2点です。
「レガシーシステム刷新の完全ガイドブック」と「【2026年最新版】AI駆動開発の完全ガイドブック」を発注準備にご活用ください。
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。