この記事の要点
データ移行テストとは、旧システムのデータが新システムへ「漏れなく・正しく・業務で使える状態で」移ったかを確かめるテストです。件数の一致だけでは不十分で、値の正確性、参照整合性、業務上の計算結果、移行時間、切り戻しまで確認する必要があります。本記事では、確認すべき7つの観点、5ステップの進め方、突合による検証方法とチェックリストを解説します。
データ移行テストとは、旧システムから新システムへ移したデータが、漏れなく（完全性）、正しく（正確性）、業務で使える状態で（整合性）移ったかを確かめるテストです。
システム移行では、プログラムが正しく動いても、データが1件ずれていれば業務は止まります。顧客の残高が合わない、取引履歴が欠けている、外字が文字化けしている、といった問題は、本番切り替え後に発覚すると影響が非常に大きくなります。だからこそ、データ移行テストは「件数を数えて終わり」ではなく、観点を決めて計画的に行う必要があります。
本記事は、マイグレーションテストの進め方を解説した記事のクラスター記事です。ここでは、その中でも「データ」に焦点を当てて掘り下げます。
1. データ移行テストとは？
まずは、データ移行テストの目的と、よく似た「移行テスト」「移行リハーサル」との違いを整理しましょう。
1-1. データ移行テストの目的：完全性・正確性・整合性
データ移行テストで確かめるべきことは、大きく3つです。
- 完全性：移行すべきデータが、欠けることなくすべて移っているか
- 正確性：値が変換ルールどおりに、正しく変換されているか
- 整合性：データ同士の関係や業務上の計算結果が、新システムでも成り立つか
この3つがそろって初めて、「データ移行が成功した」といえます。
1-2. 移行テスト・移行リハーサルとの違い
「移行テスト」は、データ移行テストに加えて、プログラムやインフラ、運用の切り替えまで含めた広い概念です。「移行リハーサル」は、本番と同じ手順・時間で移行作業を通しで実施し、手順と所要時間、切り戻しを確かめる工程を指します。
| 用語 | 主な対象 | 確認すること |
|---|---|---|
| データ移行テスト | データ | 完全性・正確性・整合性 |
| 移行テスト | データ＋プログラム＋インフラ＋運用 | 切り替え全体が問題なく行えるか |
| 移行リハーサル | 本番移行の手順 | 手順・所要時間・切り戻しの妥当性 |
1-3. データ移行で起きやすいトラブル
データ移行テストが不十分だと、次のようなトラブルが起きがちです。
- 文字コード変換で外字や機種依存文字が文字化けする
- 桁数や型の違いで、金額や日付が切り捨てられる
- 親データのない子データ（孤立レコード）が発生し、画面でエラーになる
- 移行に想定以上の時間がかかり、切り替え時間内に終わらない
文字コードや数値の扱いの違いは、COBOL移行で業務ロジックを守る方法でも詳しく取り上げています。
2. データ移行テストで確認すべき7つの観点
では、データ移行テストでは具体的に何を確認すればよいのでしょうか。HBLABでは、次の7つの観点でテストを設計しています。
① 件数：漏れなく移っているか
テーブルごとに、移行元と移行先の件数を比較します。移行対象外として除外したデータがある場合は、「移行元件数＝移行先件数＋除外件数」になっているかを確認します。
② 値の正確性：変換ルールどおりか
項目ごとの変換ルール（コード値の読み替え、日付形式の変換、項目の分割・結合など）が正しく適用されているかを確認します。
③ データ型・桁数・文字コード
桁あふれや切り捨て、全角・半角の扱い、外字の変換結果を確認します。特にShift_JISやEBCDICからUnicodeへの変換では、機種依存文字や外字の対応表が正しいかが重要です。
④ 参照整合性：データ同士の関係が保たれているか
親子関係、コード値マスタとの対応、一意制約などが、新システムでも成り立っているかを確認します。孤立レコードや重複キーは、ここで見つけます。
⑤ 業務上の計算結果：残高・集計が一致するか
口座残高、在庫数、売上の月次集計など、業務上の重要な数値が新旧で一致するかを確認します。件数が合っていても、集計値がずれていれば業務では使えません。業務ロジックの検証は、移行後の業務ロジック検証もあわせてご覧ください。
⑥ 移行時間・性能：切り替え時間内に終わるか
本番と同じデータ量で移行処理を行い、決められた切り替え時間内に終わるかを確認します。時間が足りない場合は、事前移行と差分移行の組み合わせなどを検討します。
⑦ 切り戻し・再実行：失敗したときに戻せるか
移行途中で問題が起きた場合に、旧システムへ戻せるか、移行処理を安全にやり直せるかを確認します。切り戻し手順は、テストしていなければ本番では使えません。
| 観点 | 確認内容 | 主な検証方法 |
|---|---|---|
| ① 件数 | 移行元＝移行先＋除外 | 件数比較 |
| ② 値の正確性 | 変換ルールの適用 | 項目単位の突合、サンプル確認 |
| ③ 型・桁・文字コード | 桁あふれ、外字、全角半角 | 境界値データ、文字変換表との照合 |
| ④ 参照整合性 | 親子関係、コード値、一意性 | 整合性チェックSQL |
| ⑤ 業務上の計算結果 | 残高・在庫・集計の一致 | 集計値比較、業務シナリオテスト |
| ⑥ 移行時間・性能 | 切り替え時間内の完了 | 本番相当量での計測 |
| ⑦ 切り戻し・再実行 | 失敗時の復旧 | 移行リハーサルでの実地確認 |
3. データ移行テストの進め方：5ステップ
7つの観点を効率よく確認するには、テストの順序が重要です。ここでは、HBLABが実際の移行案件で用いている5ステップを紹介します。
Step1. 移行仕様（マッピング定義）を確定し、テスト観点を設計する
移行元と移行先の項目の対応、変換ルール、移行対象外の条件を「マッピング定義」として確定します。そのうえで、7つの観点ごとに、何をどう確認するかを設計します。
設計ができたら、次は移行元データそのものの状態を確かめます。
Step2. データプロファイリングで現行データの品質を把握する
現行データの件数、NULLの割合、値の分布、重複、桁数の最大値などを調べます。長年運用されたシステムには、仕様上ありえない値や不整合データが必ず含まれています。テストの前に把握しておくことで、「移行で壊れた」のか「もともと壊れていた」のかを切り分けられます。データの依存関係は、現行システムの依存関係調査で整理しておくとスムーズです。
Step3. 移行プログラムを単体でテストする
移行プログラム（またはツールの設定）を、少量のテストデータで検証します。境界値、異常値、外字を含むデータを意図的に用意し、変換ルールどおりに動くかを確認します。
Step4. 全件データで突合する
本番相当の全件データで移行を行い、件数・項目値・集計値を新旧で突合します。突合はスクリプトで自動化し、何度でも繰り返し実行できるようにしておくのがポイントです。
Step5. 移行リハーサルで時間・手順・切り戻しを検証する
本番と同じ手順・体制・時間帯で移行を通しで実施し、所要時間、作業手順、切り戻しの可否を確認します。リハーサルは最低2回行い、1回目の課題を2回目で解消できたかを確かめるのが理想です。移行全体の進め方は、マイグレーションの進め方：アセスメント・AI移行・テストの3段階も参考になります。
データ移行テスト、どこまで計画できていますか？
HBLABは、マッピング定義の整理からデータプロファイリング、自動突合、移行リハーサルまで、データ移行テストを一貫して支援します。「何を、どこまで確認すれば安全か」からご相談いただけます。
4. データ移行テストの検証方法
7つの観点を確かめる方法は1つではありません。目的に応じて、次の検証方法を組み合わせます。
| 検証方法 | 何を確認するか | 向いている場面 |
|---|---|---|
| 件数比較 | テーブル単位の件数 | すべての移行で必須 |
| 集計値比較 | 金額・数量の合計、残高 | 金額・在庫など重要な数値 |
| ハッシュ・チェックサム比較 | レコード内容の完全一致 | 変換のない項目の大量比較 |
| 項目単位の突合 | 変換ルールの適用結果 | コード値・形式の変換がある項目 |
| サンプル目視確認 | 文字化け、表示の違和感 | 外字・帳票・画面表示 |
| 業務シナリオテスト | 新システムで業務が回るか | 移行データを使った最終確認 |
機械的な突合で「数字の一致」を確かめ、業務シナリオテストで「業務で使えるか」を確かめる、という2段構えが基本です。クラウドのデータベース移行サービスにも、移行元と移行先のデータを比較する検証機能が用意されています（例：AWS Database Migration Service「データ検証」）。
5. データ移行テストを効率化する3つのポイント
データ移行テストは、移行リハーサルのたびに繰り返し行います。効率化の工夫が、品質とスケジュールの両方を左右します。
5-1. 突合を自動化し、何度でも実行できるようにする
件数・集計値・ハッシュの比較をスクリプト化し、ボタン1つで結果レポートが出る状態にします。手作業の突合は、回数を重ねるほど見落としが増えます。
5-2. ゴールデンデータを用意する
業務上重要なパターンを網羅した、少量の「ゴールデンデータ」を用意しておくと、変換ルールの修正後もすぐに確認できます。ゴールデンデータの考え方は、マイグレーションテストの4つの品質軸で解説しています。
5-3. AIで変換ルールの確認とテストデータ作成を支援する
生成AIは、マッピング定義と移行プログラムの突き合わせや、境界値・異常値を含むテストデータ案の作成に活用できます。ただし、最終的な確認は必ず人が行います。AI活用の考え方は、マイグレーションのAI活用をご覧ください。
6. データ移行テストのチェックリスト
データ移行テストの完了前に、次の12項目を確認しましょう。
- マッピング定義（項目対応・変換ルール・除外条件）が確定している
- 7つの観点ごとのテスト項目が設計されている
- データプロファイリングで現行データの品質を把握した
- 不整合データの扱い（修正・除外・そのまま移行）を業務部門と合意した
- 境界値・異常値・外字を含むテストデータで単体テストを行った
- 全件で件数比較を行い、差異の理由を説明できる
- 重要な数値の集計値比較を行った
- 参照整合性チェックで孤立レコード・重複がない
- 文字化け・桁あふれのサンプル確認を行った
- 業務シナリオテストで新システムの業務が回ることを確認した
- 移行リハーサルで所要時間が切り替え時間内に収まった
- 切り戻し手順を実際に試し、復旧できることを確認した
7. HBLABのデータ移行・テスト支援
HBLABは、マイグレーションのテスト・品質保証を強みとし、データ移行テストを計画から本番移行後の検証まで支援しています。
アセスメントの段階でデータの依存関係と品質を把握し、移行設計、自動突合の仕組みづくり、移行リハーサルまでを一貫して担います。現行システムの解析にはHBLABのAI Assessment Toolを活用し、テストの設計と判断はQA・BAの専門家が担う体制です。
サービスの詳細は、HBLABのマイグレーションサービスをご覧ください。
データ移行の品質に不安はありませんか？
「件数は合っているが、本当に正しいか分からない」「リハーサルの計画が立てられない」といったお悩みに、HBLABがデータ移行テストの設計と実行でお応えします。
8. データ移行テストに関するよくある質問
移行テストと移行リハーサルの違いは何ですか？
移行テストは、データやプログラム、インフラの切り替えが正しく行えるかを確かめるテストの総称です。移行リハーサルは、その中でも本番と同じ手順・時間で移行作業を通しで行い、手順・所要時間・切り戻しを確認する工程です。
全件で検証する必要はありますか？
件数・集計値・参照整合性の確認は、全件で行うのが原則です。スクリプトで自動化すれば、全件でも現実的な時間で実施できます。一方、文字化けや表示の確認など人の目が必要なものは、リスクの高いデータを中心にサンプルで確認します。
データ移行テストにはどのくらいの期間が必要ですか？
データ量、移行対象のテーブル数、変換ルールの複雑さによって大きく変わります。移行リハーサルを複数回行う前提で、余裕をもった計画を立てることが重要です。
まとめ
データ移行テストでは、件数、値の正確性、型・桁・文字コード、参照整合性、業務上の計算結果、移行時間、切り戻しの7つの観点を、マッピング定義の確定から移行リハーサルまでの5ステップで確認します。突合を自動化し、業務シナリオで最終確認しましょう。HBLABは、安全なデータ移行テストを支援します。
