LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

基幹システムのリプレースやクラウド移行を計画する際、多くの企業が直面するのが「システム移行・データ移行をどう外注するか」という問いです。移行プロジェクトは一般的な開発案件と異なり、現行システムのデータを正確に引き継ぎながら業務を止めないという難しさがあります。

この記事では、移行方式の選定基準、データ移行の進め方、外注契約の設計、リスク低減策の順で解説します。費用相場については別記事をご参照ください。

システム移行・データ移行を外注する際の全体像

システム移行・データ移行の外注とは、老朽化した基幹システムや業務アプリケーションを新環境へ切り替える際に、現行データの引き継ぎ・変換・検証を含む移行作業を専門ベンダーに委託する取り組みです。クラウド移行はもちろん、オンプレミス間の刷新やERPリプレースでも同様の外注形態がとられます。

IPA（独立行政法人情報処理推進機構）が2025年6月に公表した「DX動向2025」では、日本企業においてレガシーシステムの刷新が依然として重要なDX課題として位置づけられています。移行プロジェクトを外注する主な理由は、社内に移行ノウハウが蓄積されていないこと、限られた期間内に確実な品質を確保したいこと、の2点に集約されます。

移行プロジェクトの主要4工程 — 要件定義・設計・データ移行・本番切替

システム移行プロジェクトは大きく4工程で進みます。第1工程の「要件定義」では、現行システムの機能・データ・インターフェースを棚卸しし、新環境への移行範囲と除外範囲を確定します。

第2工程の「移行設計」では、移行方式の確定・データマッピング・テスト計画を策定します。この段階でロールバック手順も定義しておくことが大切です。

第3工程の「データ移行実施」は、後述する棚卸し・クレンジング・変換・検証の4フェーズで構成されます。第4工程の「本番切替・移行後検証」では、切替当日のオペレーション計画と移行後の業務確認期間を設けます。

外注と内製の役割分担 — 責任範囲を契約前に決める

外注移行で問題が起きやすいのは、「どこまでが外注範囲か」が不明確なケースです。一般的な役割分担の目安として、現行システムの業務仕様把握・テストデータ準備・業務受入れ確認は発注者側が担い、移行ツール開発・データ変換処理・テスト実施は受託側が担います。

ただし、現行システムの仕様書が不完全な場合、受託側が現行調査（リバースエンジニアリング）を行うことになり、工数が大幅に増加します。RFP（提案依頼書）作成前に現行仕様の整備状況を確認し、現行調査の範囲も見積もりに含めることが重要です。

移行方式の選定 — ビッグバン・段階的・並行稼働の判断基準

移行方式の選定は、システム規模・業務の停止許容時間・予算・移行リスクの4軸で判断します。方式を誤ると、移行後の業務停止やデータ不整合につながるため、プロジェクト初期に確定することが肝要です。

ビッグバン移行 — 短期集中・リスク高・小規模システムに適する

ビッグバン移行とは、ある時点で旧システムから新システムへ一括して切り替える方式です。移行期間が短く、新旧システムを並行稼働させずに済むためコストを抑えやすい反面、切替当日に問題が発生した場合の影響範囲が全システムに及びます。

この方式が適するのは、システム規模が小さく業務への影響が限定的なケース、または移行データ量が少なくテストで品質を担保しやすいケースです。切替後の即時ロールバック手順と、切替前後の業務停止時間の合意が前提条件となります。

段階的移行 — 部門・機能ごとの順次切替でリスクを分散

段階的移行は、部門単位または機能モジュール単位で順次切り替える方式です。一度に影響する範囲が限られるため、問題が発生した際の切り戻しが容易で、移行ノウハウを蓄積しながら進められます。

注意点は、移行過渡期に旧システムと新システムが混在するため、データ同期の仕組みを整備することです。ERPのような全社横断システムでは、会計データと在庫データの整合を保つための連携設計が複雑になります。外注先にこの過渡期のデータ連携設計まで含めた提案を求めることが大切です。

並行稼働（パラレル移行）— 新旧同時稼働でデータ整合を検証

並行稼働は、新旧システムを一定期間同時に稼働させ、出力結果を照合しながら確認を進める方式です。データ不整合が発見しやすく、業務継続性が最も高い反面、二重運用によるコストと工数が増加します。

基幹系（会計・生産管理・人事給与）など、データ誤りが経営に直結するシステムに適します。並行稼働期間の目安は1〜3ヶ月程度が一般的ですが、システムの複雑性や業務量によって変動します。外注する場合は、照合作業の自動化ツールの提供も含めて検討してください。

データ移行4フェーズ — 棚卸し・クレンジング・変換・検証の進め方

データ移行はシステム移行全体の中でも工数・リスクが集中する工程です。IPA「DX白書2023」（IPA、2023年）でも、レガシーシステムのデータ品質確保が移行プロジェクトの重要課題として取り上げられています。4フェーズに分けて進めることでリスクを管理しやすくなります。

フェーズ1: データ棚卸しと現行調査 — 対象範囲・件数・精度を把握

最初に行うのは、移行対象データの全量把握です。テーブル数・レコード数・データ形式（文字コード・日付形式・NULL値の扱い）を一覧化します。現行システムのデータ品質は、実際に調査するまでわからないことが多く、想定外の問題が後から発覚するリスクを抑えるためにも、この棚卸し工程に十分な工数を確保してください。

外注先に依頼する際は、棚卸し結果の「データ品質レポート」を納品物として明記することが重要です。これが後続のクレンジング・変換工程の基礎資料になります。

フェーズ2: データクレンジング — 欠損・重複・形式不一致の解消

棚卸しで判明した問題データを修正するのがクレンジング工程です。代表的な問題として、必須項目の欠損・顧客コードの重複登録・旧システム固有の形式（半角カナ・特殊文字）・異なる部門で使われてきた意味的な不整合（同一商品コードで別商品が登録されているケースなど）が挙げられます。

クレンジングはルールを定めて自動処理する部分と、業務担当者が判断する部分に分かれます。後者は外注先だけでは対応できないため、発注者側が業務部門を巻き込む体制を整えることが求められます。

フェーズ3: データ変換（ETL）— 移行先スキーマへのマッピング

ETL（Extract（抽出）・Transform（変換）・Load（格納））とは、現行システムからデータを抽出し、新システムのスキーマ（データベース構造）に合わせて変換・格納する処理です。コード体系の変換（商品コード体系の統一）や、旧システム固有フィールドを新システムの複数フィールドに分割するケースが代表例です。

ETLツールやスクリプトの設計は外注先が担いますが、変換ルールの定義には発注者側の業務知識が不可欠です。変換ロジックを「移行仕様書」として文書化し、発注者が承認するプロセスを挟むことで、後から「仕様と違う」となる問題を防げます。

フェーズ4: テスト・検証 — 移行件数照合・業務検証・差し戻し手順

移行後の検証では、まず「件数照合」を行います。現行システムのレコード数と新システムのレコード数が一致しているか、金額合計や残高が一致しているかを確認します。件数照合を通過したら、業務担当者による「業務検証」を行い、実際の業務フローで新システムを操作して問題がないかを確かめます。

検証で問題が発見された場合の差し戻し手順（どのフェーズまで戻るか・誰が判断するか）を事前に決めておくことが大切です。本番直前に問題が発覚した場合に備え、ロールバック判断の権限者と判断基準も明文化してください。

外注先への依頼と契約形態の選び方

システム移行の外注では、契約形態の選択がプロジェクトリスクに直結します。移行の性質上、作業開始前に全要件を確定しにくいケースが多いため、契約形態は慎重に設計することが求められます。

請負契約と準委任契約 — システム移行外注での使い分け

請負契約は「成果物の完成」に対して報酬が発生し、受託者が完成責任を負います。移行ツール・ETLスクリプト・移行仕様書など、明確に定義できる成果物に適します。

準委任契約は「作業の遂行」に対して報酬が発生し、発注者が業務指示に関わります。現行調査やクレンジングルールの検討など、作業を進める中で仕様が変化する工程に適します。移行プロジェクトでは、両契約を工程に応じて組み合わせる方法が一般的です。

RFP（提案依頼書）に盛り込む必須項目

移行プロジェクトのRFP（Request for Proposal）には、一般的なシステム開発案件のRFPに加えて、以下の項目を漏れなく盛り込んでください。

• 現行システムの概要（テーブル数・レコード件数の規模感・接続先システム）
• 移行対象データの一覧（棚卸し済みの範囲）と既知のデータ品質問題
• 業務停止の許容時間と切替スケジュールの制約条件
• 移行リハーサルの実施回数と合否判定基準
• 本番切替後のサポート期間と体制
• ロールバック手順の提案を含めること（必須）

RFPに曖昧な記載があると、受託側の見積もりが保守的になり、実際の作業工数との乖離が生じます。発注者側でできる限り現状を整理してからRFPを発行することが、適正な見積もりを得る近道です。

見積もり評価と選定時の確認ポイント

複数社からの提案を比較する際、単純に費用の安さだけで判断することは避けてください。移行プロジェクトの品質は、受託側のデータ移行経験・同規模システムの実績・テスト設計の深さに大きく依存します。

提案評価のチェックポイントとして、過去の同種プロジェクト実績の確認（業種・規模・使用技術）、移行リスクの提示とその低減策の具体性、テストケース設計の方針（自動照合ツールの活用有無）、移行後のサポート範囲が含まれているかを確認してください。

元請（プライムベンダー）として受託する形態かどうかも重要です。複数の下請けを束ねるような構造では、責任の所在が曖昧になりがちです。プロジェクト全体の責任を一社が担う元請形態で受託できるベンダーを選ぶことで、発注者の管理負担を軽減できます。

移行プロジェクトで発生しやすいリスクと低減策

システム移行・データ移行の外注プロジェクトには、固有のリスクがあります。事前に想定しておくことで、リスクが顕在化した際の対応を迅速化できます。

移行データの欠損・不整合 — 発生原因と検証ゲートの設計

データ移行後に欠損や不整合が発覚する原因の大半は、事前のデータ品質調査が不十分なことと、変換ルールの定義漏れです。対策として、移行を本番実施する前に「移行リハーサル」を最低1回（できれば2〜3回）実施し、件数照合と業務確認を本番と同じ条件で行います。

リハーサルごとに「移行検証報告書」を作成し、問題件数とその解消方法を記録することが大切です。本番切替の合否判定基準を事前に定め、基準を満たさない場合は切替を延期できる体制を確保してください。

切替後の業務停止リスク — ロールバック計画の必須化

本番切替後に重大な不具合が発見された場合、旧システムへの切り戻し（ロールバック）を行えるかどうかがリスク管理の要です。ロールバックが可能な時間的制約（旧システムのデータが最新状態を保てる期間）を把握し、ロールバック手順を文書化してください。

ビッグバン移行ではロールバック可能期間が短いため、切替作業を業務閑散時間帯（夜間・週末）に設定し、問題発見から判断・切り戻し完了までのタイムラインをあらかじめ定めておくことが重要です。

外注依存によるブラックボックス化 — 議事録・成果物管理で防ぐ

移行完了後に「何をどうやって移行したか」が受託側にしか分からない状態になると、移行後のシステム保守・改修が困難になります。外注依存によるブラックボックス化は、移行後に内製化や別ベンダーへの切り替えを検討する際の障壁になります。

防止策として、移行仕様書・ETL変換ロジック・テスト結果報告書をすべて契約の納品物として定義し、発注者が受領・保管する体制を整えてください。また、移行プロジェクト中は週次の進捗会議を設け、議事録を発注者側で管理することが重要です。

まとめ — 外注移行プロジェクトを成功に導く3つの判断軸

本稿では、システム移行・データ移行を外注する際の全体像から、移行方式の選定・データ移行4フェーズ・契約設計・リスク低減策までを整理しました。要点を3つに集約すると次の通りです。

第一に、移行方式の選定はシステム規模と業務停止許容時間で決まります。ビッグバンは小規模・短期向き、段階的移行は中〜大規模向き、並行稼働は基幹系ミッションクリティカルシステムに適します。方式を誤ると後からの変更が困難なため、プロジェクト初期に確定してください。

第二に、データ移行の品質は事前の棚卸しとリハーサルで決まります。データ品質問題は現行調査なしには発見できず、移行リハーサルの回数が本番品質に直結します。外注先に棚卸しとリハーサルを含む提案を求めることが重要です。

第三に、契約形態と納品物の定義がリスクコントロールの基盤です。工程に応じた請負・準委任の使い分け、ロールバック手順の文書化、移行仕様書の発注者受領が、外注依存によるリスクを抑えます。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：IPA（独立行政法人情報処理推進機構）「DX動向2025」（2025年6月）
2. *2　出典：IPA（独立行政法人情報処理推進機構）「DX白書2023」（2023年）

Tweet