データ移行テストの進め方｜移行事故を防ぐ検証設計

2026 8/10

2026年8月10日 2026年8月10日

システムのリプレースや基幹システムの入れ替え案件では、開発そのものよりも「データ移行」で事故が起きがちです。旧システムのデータを新システムへ移し替える工程は、画面や機能のテストとは別物であり、専用の検証設計が欠かせません。本記事では、受託開発のPMが移行案件で本番事故を防ぐための、データ移行テストの進め方を実務目線で整理します。

移行データの不備は、リリース直後の業務停止やデータ消失として表面化します。それはクライアントの信頼を一度で損なう性質のトラブルです。だからこそ、移行は「うまくいく前提」ではなく「事故が起きる前提」で検証を組み立てる必要があります。

なぜ移行案件ではデータ事故が起きやすいのか

移行で事故が多い最大の理由は、対象となる旧データが「これまでの運用の積み重ね」でできている点にあります。設計時には想定していなかった値、途中で仕様変更された項目、手作業で修正された例外レコードなどが混在しています。

新規開発なら、仕様に沿ってきれいなデータを作れます。しかし移行では、過去の汚れたデータをそのまま受け取らなければなりません。移行の難しさは「新しい仕組み」ではなく「古いデータの現実」にあるのです。

移行案件でデータ事故が起きやすい主な要因は、次のとおりです。

旧データの品質がばらばら: 長年の運用で、表記ゆれ・全角半角混在・空欄・重複が蓄積している
仕様書にない裏データ: 過去の暫定対応や手修正が、ドキュメントに残っていない
変換ルールの解釈違い: 「この項目はこう移す」という認識が、発注者と開発側でずれる
本番相当データが手に入りにくい: 個人情報を含むため、開発環境で本物に近いデータを使えない
やり直しがきかない: 移行は本番切替と同時に一度きりで行われ、後戻りの余地が小さい
移行当日の時間的制約: 業務停止時間（サービス断）を最小化するため、当日は分刻みで進む

たとえば、ある販売管理システムのリプレースを想像してください。旧システムには、退会済みなのにフラグが立っていない顧客や、手作業で桁を詰めた金額が紛れ込んでいます。開発チームは新システムをきれいに作り込みましたが、移行後に「退会者へ請求書が届く」「合計金額が合わない」といった問い合わせが噴出します。

原因は新システムのバグではなく、旧データの状態を検証しないまま移したことにあります。機能は完璧でも、流し込むデータが汚れていれば、業務はそのまま止まります。

受託開発では、この難しさがさらに増します。預かるのは自社ではなくクライアントのデータであり、失敗の影響は相手の業務に直接及びます。移行事故は「開発品質の問題」ではなく「預かったデータを守れなかった問題」として受け取られるため、信頼の回復には長い時間がかかります。

データの汚れ方には、いくつかの典型があります。あらかじめ知っておくと、棚卸しの精度が上がります。

表記ゆれ: 同じ会社名が「(株)」「株式会社」「カブシキガイシャ」で混在している
空欄・NULL: 必須のはずの項目が、過去データでは空のまま登録されている
重複レコード: 同一顧客が別IDで二重に存在している
範囲外の値: 想定より長い桁数や、あり得ない日付が入っている
暫定コード: 運用回避のために一時的に使ったコードが、正式扱いのまま残っている

こうした条件は、機能テストの延長では吸収できません。ソフトウェア開発の欠陥は定量的に管理すべきだという考え方は、IPAのソフトウェア開発分析データ集でも示されています。移行工程についても、勘や経験だけに頼らず、検証項目を明文化して積み上げる姿勢が欠かせません。

データ移行テストとは｜通常のテストと何が違うのか

移行テストとは、旧システムのデータが新システムへ「正しく・漏れなく・意味を保ったまま」移されたことを検証する活動です。機能テストが「画面や処理が仕様どおり動くか」を見るのに対し、移行テストは「データそのものの正しさ」を見ます。

両者は目的も合否基準も異なります。混同すると、機能テストは通ったのにデータが壊れている、という事態を招きます。JSTQBのシラバス・用語集が定義するテストレベルの考え方に照らしても、移行検証は独立した観点として計画すべき領域です。

データ移行は、大きく「抽出・変換・登録」の3工程に分けられます。旧システムからデータを取り出し（抽出）、新システムの形式に合わせて整え（変換）、新しいテーブルに書き込みます（登録）。移行検証は、この各工程で情報が欠けたり歪んだりしていないかを、工程の入口と出口で突き合わせて確認します。

つまり検証の本質は「入れたものと出てきたものが同じ意味か」を照合することです。機能が動くかどうかとは、見ている軸がまったく違います。だからこそ、機能テストの計画とは別に、移行専用の検証計画とスケジュールを用意する必要があります。

受託開発では、責任の分界点を契約段階で握っておくことも重要です。旧データの品質は誰が保証するのか、変換ルールは誰が決めるのか、移行判定は誰が下すのかを曖昧にすると、事故が起きたときに責任の押し付け合いになります。移行の役割分担は、開発着手前に発注者と文書で合意しておくと、後のトラブルを避けられます。

機能テストとの違いを整理すると、次のようになります。

観点	機能テスト	移行テスト
主な対象	画面・処理・業務ロジック	移行後のデータの中身
確認すること	仕様どおり動くか	件数・値・意味が保たれたか
合否の基準	テストケースの期待結果と一致	新旧データが照合ルールで一致
主なリスク	機能の不具合	データの欠落・変質・不整合
やり直し	修正して再テスト可能	本番移行後は切り戻しが必要

機能テストが通っても、データが正しく移っている保証にはならないという点が、移行案件で最も見落とされがちな前提です。移行は移行として、独立した検証計画を持たせてください。

データ移行テストの主な種類

移行検証は、単一の作業ではなく複数の検証の束です。どれか一つが欠けても、本番で別の形の事故になって表面化します。まずは全体像を押さえ、案件のリスクに応じて重みづけします。

代表的な検証の種類は、次のとおりです。

検証の種類	目的	主な確認内容	見逃した場合のNG例
件数・レコード照合	漏れなく移ったか	旧と新の件数一致、対象外の除外理由	一部の顧客データが移行されず消える
変換ルール検証	変換が正しいか	コード変換・区分値のマッピング	「1=有効」が新側で無効扱いになる
新旧突合（値の一致）	中身が保たれたか	金額・日付・氏名などの値の一致	残高が旧システムと一致しない
文字化け・エンコード	文字が壊れないか	文字コード変換、外字・機種依存文字	氏名の一部が「?」や空白になる
型・桁あふれ	器に収まるか	桁数・小数・日付範囲の上限下限	長い住所が途中で切れて欠落する
NULL・整合性	関係が壊れないか	必須項目の欠落、参照先の不整合	注文はあるのに顧客が存在しない
性能（移行時間）	時間内に終わるか	全件移行の所要時間、断時間の見積り	移行が制限時間内に終わらない
移行リハーサル	本番手順が回るか	手順・時間・切り戻しの通し確認	当日に手順ミスで作業が止まる

それぞれの検証には、実務ならではの勘どころがあります。順に補足します。

件数・レコード照合は最も基本的ですが、落とし穴もあります。単純な総件数だけでなく、ステータス別・年度別といった区分ごとの件数まで一致させないと、特定の区分だけ抜け落ちても総数では気づけません。対象外にしたデータは、なぜ対象外なのかを記録し、発注者と合意しておきます。

新旧突合は、旧システムと新システムの同じレコードを並べ、項目ごとに値が一致するかを確認します。金額や残高など業務に直結する項目は全件、その他はサンプルを層別に抽出して確認するのが現実的です。突合結果は「一致・不一致・許容差分」に分類し、不一致は一件ずつ原因を追います。

文字化け・エンコードの検証では、外字（システム固有の特殊文字）や機種依存文字が要注意です。旧システムでしか使えなかった文字が、新システムで空白や「?」に化けることがあります。氏名・住所・商品名など、人が読む項目を中心に、実データでの目視確認を組み合わせます。

性能検証は見落とされがちですが、本番移行の成否を左右します。全件を移すのにかかる時間が、業務を止められる時間（許容ダウンタイム）を超えれば、その移行計画は成立しません。リハーサルで実測し、時間が足りなければ並列処理や事前移行などの手を打ちます。

検証の観点を漏らさないために、データ品質を4つの軸で押さえておくと便利です。

完全性: 移すべきデータが漏れなく移ったか（件数・必須項目）
正確性: 値そのものが正しく保たれたか（金額・日付・氏名）
整合性: レコード間の関係が壊れていないか（参照先の存在）
一貫性: 表記や区分値のルールが統一されているか（コード変換）

このうち「型・桁あふれ」の検証では、境界の値に欠陥が集中しやすい点に注意します。リー・コープランド『はじめて学ぶソフトウェアのテスト技法』は、境界には多くの欠陥が潜むと指摘しています。桁数や日付範囲の上限・下限、そのすぐ上下の値を狙って確認すると、変換の取りこぼしを効率よく見つけられます。

件数が合っていても、値・文字・型のどれかが壊れていれば移行は失敗です。件数照合だけで安心せず、複数の観点を組み合わせてください。テストの観点そのものを洗い出す手順は、テスト観点を体系的に洗い出す方法も参考になります。

データ移行テストの進め方｜計画から本番移行まで

移行テストの進め方は、行き当たりばったりでは破綻します。計画・準備・リハーサル・本番という段階を、あらかじめ設計しておきます。ここでは実務で回しやすい6ステップに分けて示します。

STEP1 移行計画とデータの棚卸し

最初に、移行対象のテーブル・項目を一覧化し、対象外にするデータとその理由を明文化します。あわせて、業務停止できる時間（許容ダウンタイム）と、判定・切り戻しのタイミングを決めます。

棚卸しでは、テーブル数・レコード件数・項目の型と桁を洗い出し、どこにリスクが集中するかを見立てます。過去の運用担当者へのヒアリングで、仕様書に残っていない裏データや例外運用を拾えると、後の事故を大きく減らせます。移行計画は通常のテスト計画と地続きなので、テスト計画書の作り方と計画の立て方の考え方をベースに組み立てると抜けが減ります。

STEP2 変換ルールの定義とマッピング表

旧項目と新項目の対応、コード変換、初期値の入れ方を「マッピング表」に落とします。ここが曖昧だと、後工程のすべてがぶれます。発注者とマッピング表をレビューし、解釈のずれをこの段階で潰しておきます。

マッピング表には、最低でも次の情報を持たせます。旧項目名・新項目名・変換ルール・初期値・対象外条件です。文章で書くと解釈がぶれるため、次のように表で一意に定めます。

旧項目	新項目	変換ルール	初期値
会員区分(1/2)	member_type	1→normal、2→premium	normal
生年月日(和暦)	birth_date	和暦を西暦に変換	該当なし
電話番号(ハイフン無)	phone	3-4-4桁でハイフン付与	空文字

このマッピング表が、後工程の突合ルールとテストデータ設計の土台になります。曖昧な変換ルールを一つ残すと、そこが本番事故の起点になると考えてください。

STEP3 本番相当のテストデータ準備

開発用のきれいなデータではなく、本番の傾向を写したデータで検証します。個人情報はマスキングしつつ、外字・空欄・極端に長い値などの「困ったデータ」を意図的に残すのがコツです。きれいなデータだけで検証すると、本番の汚れたデータで初めて事故が出るため、現実のばらつきを再現してください。

STEP4 移行リハーサル（予行演習）

本番と同じ手順・同じ環境規模で、全件移行を通しで実施します。ここで所要時間を計測し、許容ダウンタイムに収まるかを確認します。リハーサルは最低でも2回、できれば手順書だけで別の担当者が再現できるかまで確かめます。

1回目のリハーサルで見つかった不備を手順書に反映し、2回目でその修正が効いているかを確認します。理想は、当日を担当しない人が手順書だけで移行を再現できる状態です。属人的な手順は、担当者が当日に休むだけで移行を止めるリスクになります。

STEP5 検証と判定

移行後のデータに対し、件数照合・新旧突合・整合性チェックを実行します。判定基準に照らして合否を出し、残った差分は「許容できる差分か」を一件ずつ判断します。システムテスト全体の流れの中での位置づけは、システムテストの進め方と実行手順も合わせて確認すると整理しやすくなります。

STEP6 本番移行と移行後確認

本番移行を実行し、直後に「移行後の点検リスト」で主要データを再確認します。業務開始前に、代表的な取引・残高・帳票が正しく表示されるかまで見て、初めて完了です。

点検リストには、件数の最終確認、主要顧客の残高、直近の取引、帳票の出力といった「業務が回る最小限の確認項目」を並べます。移行が終わった安心感から点検を省くと、業務開始後に初めて不備が露見し、対応が後手に回ります。

移行の各段階でやることを、チェックリストにまとめておくと引き継ぎが楽になります。

移行対象と対象外を一覧化し、理由まで記録したか
マッピング表を発注者とレビューし、合意したか
本番相当データ（困ったデータ込み）を用意したか
リハーサルで所要時間と手順を検証したか
判定基準と切り戻し手順を事前に決めたか
移行後の点検リストを用意したか

> 移行当日に中止か続行かで迷わないために、社内で切り戻し方針と判断基準を事前に固めておきましょう。判断の拠り所があるだけで、当日の意思決定は大きく安定します。

判定基準と切り戻しをどう設計するか

移行の成否は「なんとなく大丈夫そう」では決められません。事前に判定基準（go/no-go）を数値と条件で定義し、当日はそれに従って機械的に判断します。単一の基準だけに頼るのは危険です。

テストの終了判定について、ボリス・ベイザーは「単一の、正当かつ合理的な判断基準は存在しない」と警告しています（リー・コープランド『はじめて学ぶソフトウェアのテスト技法』が引用）。移行判定も同じで、件数・突合・整合性・時間の複数条件を組み合わせて判断すべきです。

判定基準は、数値と条件で「誰が見ても同じ結論になる」形にするのが要点です。「おおむね問題ない」といった主観的な表現は、当日の判断をぶれさせます。件数・突合・整合性・時間の各項目について、合格ラインをあらかじめ言語化しておきます。

判定基準の例（試算例）を挙げます。数値は案件ごとに調整してください。

判定項目	基準の例	判定
件数一致	対象件数が旧と新で完全一致	不一致なら中止
新旧突合	主要項目の突合エラー0件	1件でも要調査
参照整合性	孤立レコード0件	0件でなければ中止
移行時間	許容ダウンタイム内に完了	超過なら切り戻し
残差分	許容と合意した差分のみ	未合意の差分は中止

判定は、担当者一人の感覚ではなく、判定会議で複数人が基準に照らして下します。移行当日は時間に追われるため、事前に「この条件を割ったら中止する」という線を引いておくことが重要です。線引きが曖昧だと、現場の空気に流されて不十分なまま本番を進めてしまいます。

判定会議には、開発・検証だけでなく、業務側の責任者も加えます。データの差分が業務上どこまで許容できるかは、システム側だけでは判断できないためです。誰が最終的にgo/no-goを宣言するのかを、事前に決めておきます。

そして最も軽視されがちなのが、切り戻し（ロールバック）の設計です。切り戻し手順を用意していない移行は、事故が起きた瞬間に打つ手がなくなるため、必ず事前に定義します。

切り戻し設計で決めておく項目は、次のとおりです。

切り戻しを判断する条件（どの基準を割ったら戻すか）
切り戻しにかかる時間と、その間の業務影響
旧システムを再稼働させる手順と担当
切り戻し後の再移行スケジュール

切り戻しは、決めておくだけでなく、リハーサルで実際に試すことが理想です。いざというときに切り戻し手順が動かなければ、計画は絵に描いた餅になります。切り戻しにかかる時間も実測し、その間の業務影響を発注者と共有しておきます。

判定と切り戻しを事前に握っておけば、当日に慌てて品質を妥協する事態を避けられます。リリース直後のトラブルを減らす体制づくりは、リリース後のバグを減らすテスト体制の作り方も参考にしてください。

よくある失敗パターンと対策

移行事故には、案件が変わっても繰り返される「型」があります。先回りして対策を仕込んでおけば、多くは未然に防げます。代表的な失敗と対策を整理します。

失敗パターン	起きる原因	対策
件数だけ見て合格にする	件数照合を唯一の基準にした	値・文字・整合性の突合を必須にする
サンプル1件だけ確認	全件突合を工数理由で省いた	主要項目は全件、その他は層別抽出
少ないデータでリハ	本番規模のデータを用意できず	全件規模で所要時間を計測する
文字化けの見落とし	文字コード変換を軽視した	外字・機種依存文字を専用に検証
切り戻し未定義	うまくいく前提で計画した	切り戻し条件と手順を事前に用意
リハと本番で手順が違う	手順書を更新せず口頭で運用	手順書だけで別担当が再現できるか確認

いくつかの失敗は、もう少し掘り下げておく価値があります。

「サンプル1件だけ確認」は、工数を惜しんだ結果として起こりがちです。1件が正しくても、別のパターンのデータで変換が失敗していれば見逃します。サンプルは無作為ではなく、区分・桁数・特殊文字などのパターンを網羅するよう層別に選ぶのが鉄則です。

「少ないデータでリハ」も頻出します。開発環境の小さなデータでは、本番規模で初めて現れる性能問題やメモリ不足を検出できません。移行時間の見積りは、必ず本番相当の件数で実測してください。

「リハと本番で手順が違う」も根が深い問題です。手順書を更新せず口頭で運用すると、当日だけ手順が変わり、想定外のミスを招きます。手順書を唯一の正とし、変更があれば必ず反映するルールを徹底します。

これらの多くは、優先順位付けの不足から生まれます。テスト項目を並べるだけでなく、重要度・リスク・確認のしやすさで順位をつけるところまでが移行検証の設計です。全件を完璧にではなく、リスクの高いデータから確実に検証する発想が、限られた工数では現実的です。

なお、どの失敗も「本番の汚れたデータ」と「一度きりの本番移行」という移行特有の性質から来ています。次の章では、自社だけで抱えきれない場合の外部活用を扱います。

第三者検証・外注をどう使うか

移行検証は、開発した本人がやると「移せたつもり」の思い込みが入りやすい領域です。作った側は変換ルールを知っているぶん、期待どおりの結果に見えてしまいます。ここに第三者の目を入れる価値があります。

ただし外注には固有の注意点があります。ある案件の振り返りでは、テスト代行の担当者がアプリの全体像を把握しないまま作業を始め、無駄な操作が増えて時間を浪費したという反省が共有されました。内製と違い、外部には開発の経緯や裏仕様が自然には伝わりません。情報格差を埋めるフェーズを意図的に設計しないと、表面的な確認しかできないのです。

第三者検証・外注が向くのは、次のようなケースです。