システム移行の発注/外注/依頼/委託方法について

システム移行を外部へ発注するには、発注前の準備からRFPの作成、契約、移行リハーサルまでを順に進めます。

データ移行は成否を大きく左右するため、移行の目的と対象範囲、契約条件、データ移行の役割分担を前もって明確にしておくと、各社の見積もりを同じ条件で比べられ、移行時のトラブルも抑えやすくなります。

▼全体ガイドの記事
・システム移行の完全ガイド

システム移行を発注する前の準備

発注前の準備として、現状の可視化、移行の目的、対象範囲を並べたチェックリスト。
三つの確認項目を先にそろえると、見積もりの前提を合わせやすくなります。

システム移行を外部へ発注する際は、発注前の準備が最も大切です。準備が不十分なまま見積もりを依頼すると、ベンダーごとに前提条件がずれてしまい、各社の提案を正確に比べられません。そこで、まずは自社の現状を把握し、移行の目的と範囲を整理することから始めます。

現状の可視化とアセスメント

発注前にまず取り組むべきは、現行システムの現状を可視化することです。長年運用してきた業務システムや基幹システムは、機能やデータ構造がブラックボックス化していることが少なくありません。

ブラックボックス化したままでは、移行の難易度も費用も見えてきません。そこで、どのようなデータが、どこに、どれだけ存在しているのかを、自社の担当者が先に確かめておきます。

  • データの洗い出し:データ量やテーブル構造を一覧にする
  • 連携確認:外部システムやピーク時の負荷を調べる

アセスメントの段階でこれらを固めておくと、後の見積もりや依頼内容の前提がそろいます。

とくにデータ移行を伴う案件では、文字コードの違いや外字、過去データの不整合といった課題が、後から表面化しやすくなります。こうした実態を早い段階でつかんでおかないまま発注すると、後工程で追加費用や納期遅延の原因になります。

また、IPAの調査では、自社のレガシーシステムを放置すると、サプライチェーン上の調達元や提供先にも悪い影響が及ぶと指摘されています。そのため、現状の可視化は、技術的な確認にとどまらず、取引先を含めた事業継続への投資と位置づけられます。

移行の目的とスコープの明確化

次に明確にしたいのは、移行の目的とスコープ(範囲)です。なぜシステムを移行するのかが曖昧なままだと、ベンダーへの依頼内容もぶれてしまいます。

目的によって、最適な手法も発注先も変わってきます。たとえば、クラウドへの基盤移行でコストを削減したいのか、老朽化したサーバーから脱却して保守性を高めたいのかで、選ぶべき方法は大きく違います。

  • 移行目的:解決したい課題と期待する効果
  • 対象範囲:移行する機能・データと、廃止する対象

スコープを整理する際は、移行する機能とデータの範囲に線を引くことが欠かせません。その線引きで意識したいのが、「勇気ある廃止(リタイア)」という考え方です。

長年の運用で使われなくなった機能や不要なデータを、そのまま移行すると、移行コストも維持費も膨らみます。そこで、不要なものは思い切って廃止し、その予算をコア機能の刷新に回せば、全体のコストを抑えながら効果を最大化できます。

また、発注側は移行後の運用体制もこの段階で検討しておきます。すべてをベンダーに任せきりにするのか、一部を内製化していくのかによって、契約内容や引き継ぎの設計が変わります。

目的とスコープを文書にしておけば、後述するRFPの作成もスムーズに進みます。

ポイント

発注前に現状を把握し、目的と対象範囲を決めておくと、各社の見積もりを同じ前提で比べられます。前提がそろっていないと感じたら、依頼前に目的と範囲を見直してください。

システム移行を外注する際の進め方

外注時に発注内容へ含めるRFP、データ移行、移行リハーサル、並行稼働を4枚のパネルで示した図。
提案依頼から本番前の確認までを、発注範囲として見渡せます。

発注前の準備が整ったら、いよいよベンダーへの外注に入ります。

システム移行の外注は、RFPを作成して提案を評価し、契約を結んだうえで、移行リハーサルへと進みます。各段階の条件を明確にしておくと、移行時のリスクを抑えられます。

RFP(提案依頼書)の作成

外注を成功させるうえで中核となるのが、RFP(提案依頼書)です。RFPは、自社が求める移行要件や前提条件をまとめ、ベンダーに提案を依頼するための文書です。

RFPの精度が低いと、各社の提案がばらばらになり、後の比較検討が難しくなります。

  • 前提条件:対象データ、方式、日程、予算
  • 切替条件:並行稼働の有無と、許容ダウンタイム

RFPには、移行の目的と背景、対象システムの概要、移行対象データの種類と量も盛り込みます。

とくにデータ・基盤移行を伴う案件では、切り替えの条件が曖昧だと、ベンダーは安全側に見積もりを膨らませるか、逆にリスクを過小評価した甘い提案を出してしまいます。

また、RFPの段階で「Fit to Standard」の方針を示しておくのも有効です。これは、自社の業務を標準的な仕組みに合わせていく考え方です。

既存のやり方をすべて再現しようとすると、カスタマイズが膨らんで開発が肥大化し、プロジェクトが頓挫するリスクが高まります。そのため、どこまで標準に寄せられるかをあらかじめ整理しておくと、現実的な提案を引き出せます。

データ移行と移行リハーサルの依頼

システム移行の成否を最も大きく左右するのが、データ移行です。発注時には、データ移行の作業範囲と責任分担を明確にしておく必要があります。

データのクレンジングやマッピングを誰が担うのか、移行ツールの開発はどちらが責任を負うのかを、契約前に詰めておく必要があります。詰めないまま進めると、後で押し付け合いになりかねません。

  • 責任分担:データ整備と移行ツールの担当
  • リハーサル:所要時間とデータ整合性を本番前に確かめる

とくに重要なのが、移行リハーサルの実施です。本番のデータを使った移行を本番前に複数回シミュレーションすると、想定外のエラーやデータ不整合を事前に洗い出せます。

リハーサルでは、ダウンタイムが許容範囲に収まるかも検証します。この移行リハーサルを発注内容に明確に含めておくことが、当日のトラブルを防ぐ最大の保険になります。

あわせて検討したいのが、並行稼働の設計です。旧システムと新システムをしばらく同時に動かすことで、切り替えのリスクを下げられます。

並行稼働では二重に運用コストがかかるため、期間設定とコスト負担をベンダーと事前に合意しておくことが欠かせません。

発注時は、一気に切り替えるビッグバン方式を避け、段階的に移行する設計を依頼すると、万一の際の切り戻しも容易になります。

ポイント

RFPに条件をどこまで書くかは、後の比較のしやすさと、ベンダーがリスクを正しく見積もれるかで決めると考えやすくなります。データ移行の責任分担と並行稼働の要否は、契約前に確かめておくとよいでしょう。

システム移行の委託で押さえる契約形態

準委任契約は要件が固まるまで、請負契約は仕様が確定してからという使い分けを左右で対比した図。
契約形態の切り替え時期は、要件や仕様の確定度が目安になります。

システム移行を委託する際は、契約形態の選び方がプロジェクトのリスクを大きく左右します。

契約の種類を理解しないまま進めると、トラブル時の責任が曖昧になり、追加費用をめぐる紛争につながることがあります。そのため、契約形態の使い分けと、ベンダーロックインを防ぐ条件を事前に確かめておく必要があります。

準委任契約と請負契約の使い分け

システム移行の委託で中心となる契約形態は、準委任契約と請負契約の2つです。準委任契約は、特定の業務の遂行そのものを委託する契約で、成果物の完成責任までは負いません。

一方の請負契約は、成果物の完成を約束し、その対価を支払う契約です。両者を適切に使い分けることが、リスクを抑える基本になります。

  • 準委任:要件が固まるまでの段階
  • 請負:仕様が確定してからの段階

実務でおすすめなのは、フェーズごとに契約形態を切り替える方法です。たとえば、アセスメントや要件定義の工程は、この切り替えの前半にあたります。

発注側は、開発や移行の実装で、成果物の完成責任を伴う請負契約に切り替えるとよいでしょう。

準委任から請負へと段階的に移行すれば、不確実性の高い初期段階のリスクを抑えつつ、開発段階では完成を担保できます。

あわせて、SLA(サービス品質保証)と責任分界点を契約書に明記しておく必要があります。どこまでがベンダーの責任で、どこからが発注側の責任かを線引きしておくと、トラブル発生時の混乱を避けられます。

とくにデータ移行では、移行元データの正確性は発注側の責任、移行処理の正確性はベンダーの責任と、切り分けを文書にしておくとよいでしょう。

ベンダーロックインを防ぐ契約の工夫

システム移行を外注するうえで見落とされがちなのが、ベンダーロックインへの対策です。

ベンダーロックインとは、特定のベンダーに依存しすぎて、後から他社へ乗り換えたり内製化したりすることが難しくなる状態を指します。

せっかく古いシステムから脱却しても、新たなロックインに陥っては元も子もありません。

  • 権利と成果物:コードの権利と設計書の納品
  • 運用権限:運用に必要な権限を発注側に残す

これを防ぐには、契約段階での工夫が欠かせません。具体的には、開発したソースコードの著作権を発注側に帰属させるか、共有とする取り決めを盛り込みます。

発注側は、設計書や運用手順書などのドキュメント一式も成果物として納品させておきます。権利や権限の取り決めが曖昧なままだと、保守や改修のたびに同じベンダーへ依頼せざるを得なくなります。

また、特定ベンダー独自の技術や製品に過度に依存しない設計を依頼するのも有効です。標準的な技術や汎用的なクラウドサービスを基盤に据えておけば、将来、運用を引き継ぐ際の選択肢が広がります。

契約は、自社の主導権を確保するための経営判断として捉えておきたいところです。

ポイント

準委任と請負のどちらにするかは、要件や仕様が固まっているかどうかで判断できます。要件が固まるまでは準委任、仕様が確定したら請負へと切り替えると考えやすくなります。

システム移行の費用相場と発注先の選び方

システム移行を発注する際、多くの担当者が最も気にするのが費用です。費用相場の全体感をつかんでおくと、ベンダーの見積もりが妥当かどうかを判断しやすくなります。

費用の内訳と隠れコスト

システム移行の費用は、プロジェクトの規模や手法によって大きく変わります。小規模な基盤移行であれば数百万円程度から、業務全体に関わる大規模な刷新では1億円から2億円規模に達することもあります。

費用の内訳には、並行稼働の運用費や、移行後の運用保守費も含まれます。

  • 初期費用:現状調査、設計・開発、データ移行の費用
  • 追加費用:データ整備、教育、ライセンスの費用

見積もりに現れにくい隠れコストにも注意が必要です。代表的なのが、データクレンジングの費用です。

長年蓄積されたデータには、重複や表記ゆれ、不整合が含まれており、その整理に想定以上の工数がかかります。

さらに、新しい仕組みに合わせた社員教育や、クラウド基盤の新規ライセンス費も、見落とされがちです。これらを初期段階で見込んでおかないと、後から予算が膨らみます。

経営層への稟議では、初期コストの比較に加えて、移行後の運用コスト低減シミュレーションを示すと効果的です。

たとえば、保守費やインフラ費がどれだけ下がるかを数字で見せると、投資対効果が伝わりやすくなります。判断は目先の費用より中長期の総コストで行うと、説得力のある提案につながります。

失敗しない発注先の選定基準

発注先は、価格の安さだけで選ばないのが鉄則です。重視したいのは、技術力に加えて、自社の業務をどれだけ理解してくれるかという点です。

システム移行は業務の流れと密接に結びついているため、業務理解の浅いベンダーに任せると、現場が使いにくい仕組みになってしまいます。

  • 実績:同規模・同業種の移行経験
  • 体制:データ移行とプロジェクト管理の体制

発注側は、データ移行のノウハウを持っているかと、契約姿勢が誠実かも確かめます。

とくに、前述のベンダーロックイン回避に協力的かどうかは、長期的な関係を見据えるうえで大切な判断材料です。複数社から提案を取り、同じRFPをもとに横並びで比べると、各社の実力が見えてきます。

背景には、IT人材の不足も発注先選びに影響します。IPAの調査では、2030年に最大で79万人のIT人材が不足すると予測されています。

優秀な技術者を抱えるベンダーには需要が集中するため、早めに動いて信頼できるパートナーを確保すると、結果的にプロジェクトの安定につながります。

同じ調査では、CDOやCIOといった責任者を設置している企業ほど社内の情報共有が円滑で、可視化や内製化が進む傾向も示されています。こうした企業では、モダナイゼーションも順調に進むという相関が見られます。

発注を成功させるには、社内の推進体制づくりも並行して進めることが望まれます。

ポイント

見積もりに出にくいデータクレンジングや教育、ライセンスの費用が入っているかで、見積もりの妥当性を見極めます。発注先は、価格より業務理解を重視して比べます。

まとめ

システム移行を外部へ発注・委託する際は、発注前の準備が成否を大きく左右します。

現状を可視化して実態を把握し、移行の目的とスコープを明確にしたうえで、不要な機能やデータを思い切って廃止します。これが、コストを抑える第一歩になります。

発注前の準備が整って初めて、正確な見積もりと精度の高い提案を引き出せます。

外注の進め方では、RFPの作成を起点に、データ移行と移行リハーサル、並行稼働の設計までを発注内容に明確に含めます。この備えが、当日のトラブルを防ぐうえで役立ちます。

契約面では、準委任契約と請負契約を工程に応じて使い分けます。ソースコードの権利とドキュメントの納品条件を定めて、ベンダーロックインを避けることが、自社の主導権を守るうえで欠かせません。

費用では、見積もりに現れにくいデータクレンジングや教育、ライセンスの費用も見込んでおきます。さらに、移行後の運用コスト低減を試算して投資対効果を示すと、経営層の説得につながります。

発注先は、価格だけで決めず、技術力や業務理解を中心に、実績と契約姿勢も見て選びます。本記事の内容を参考に、自社にとって最適なパートナーへ、システム移行を依頼していただければ幸いです。

▼全体ガイドの記事
・システム移行の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。