ERP移行プロジェクトにおいて、「データ移行テストで何を確認すればいいのか分からない」「本番移行で想定外のトラブルが起きないか不安だ」という声は少なくありません。
旧システムから新ERPへデータを移す作業は、単なるコピー＆ペーストではなく、形式の変換やコード体系の組み替え、業務ルールの再設計を伴う複雑な工程です。
結論として、ERP移行テストは「サンプル移行（ロジック検証）」「全件移行（性能検証）」「移行リハーサル（手順検証）」という3段階で段階的にリスクを低減していく戦略が基本となります。
各段階で扱うデータ量や検証観点を明確に分け、早期に論理的な誤りを洗い出し、次に大量データでの性能を確かめ、最後に本番と同じ手順で実地訓練を行うことで、本番移行の成功率を高めることができます。
本記事では、ERP移行テストの全体像から各段階の具体的な検証項目、データ整合性の確認手法、業務部門を巻き込んだユーザー受け入れテスト（UAT）の進め方、本番移行失敗時の切り戻し判断基準、そして自動化ツールの活用方法まで、実務に即した手順とチェックリストを網羅的に解説します。
ERP移行テストの全体構造と3段階テストの位置づけ
ERP移行プロジェクトにおいて、テスト工程は品質を最終的に作り込む重要な局面です。IPAの「ソフトウェア開発データ白書」によると、総合テストで1KSLOC（1000ソースライン）あたり中央値0.32件のバグが検出されており、この段階での適切な検証がプロジェクトの成否を分けます。
移行テストでは、データの論理的正確性、処理性能、実行手順の妥当性という3つの軸を段階的に確認していく必要があります。具体的には、以下の3段階で移行テストを行います。
- サンプル移行｜少量データを用いてマッピングルールの妥当性を検証
- 全件移行｜本番同等の大量データによる性能とデータ整合性を確認
- 移行リハーサル｜本番環境を使った実地訓練を行います。
この3段階のアプローチにより、早期に論理的な誤りを修正し、大量データ特有の問題を洗い出し、関係者全員が本番移行の手順を理解した状態で当日を迎えることができます。
1-1. サンプル移行テストの目的とスコープ
サンプル移行テストは、移行プロジェクトの初期段階で実施する検証です。数百から数千件程度の代表的なデータを抽出し、新旧システム間の項目マッピングが論理的に正しいかを早期に確認します。この段階では処理速度よりも、データ変換ロジックの正確性に焦点を当てます。
対象データの選定では、通常の取引パターンに加えて、境界値や例外的なケースを意図的に含めることが重要です。たとえば、金額がゼロの取引、マイナス値を持つ在庫調整、コード体系の変換が複雑な旧マスタデータなど、移行ロジックが正しく動作するか不安な箇所を優先的に選びます。
サンプル移行で発見された不具合を修正することで、後続の全件移行やリハーサルでの手戻りを大幅に減らすことができます。
1-2. 全件移行テストの目的とスコープ
全件移行テストでは、本番と同等の全データを用いて移行処理を実行し、パフォーマンスとデータ整合性の両面を検証します。サンプル移行で論理的な正しさを確認した後、実際の運用データ量で処理が完了するかを確かめる段階です。
大量データを処理することで、システム負荷やタイムアウト、メモリ不足といったリスクが顕在化します。本番移行時にはシステム停止可能な時間枠が限られているため、全件移行テストで計測した所要時間が許容範囲内に収まるかを確認し、必要に応じてバッチ処理の並列化やインデックス最適化などのチューニングを行います。
また、移行後のデータ件数や金額合計が旧システムと一致しているかを全件突合し、データ欠損や重複登録がないことを検証します。
1-3. 移行リハーサルの目的とスコープ
移行リハーサルは、本番環境を使用し、実際の移行手順書に基づいてタイムテーブルの正確性を検証する実地訓練です。サンプル移行と全件移行がデータの正しさと処理性能に焦点を当てるのに対し、リハーサルは「誰が・いつ・何を」行うかという手順の精度と、関係者間のコミュニケーションフローを確認します。
本番環境特有の制約やネットワーク環境に起因する問題を発見し、移行手順書の精度を最終確認します。たとえば、テスト環境では問題なく動作していた処理が、本番環境のファイアウォール設定やアクセス権限の違いによって失敗するケースがあります。
また、作業の依存関係や並行実施可能なタスクを整理し、想定外の遅延が発生した場合のリカバリープランや中断判断のタイミングを関係者全員で確認します。リハーサルを通じて発見された軽微な手順漏れや時間乖離を修正し、全ての懸念事項を解消した状態で本番移行に臨むことができます。
①サンプル移行テストの具体的な検証項目
サンプル移行テストでは、新旧システムの項目対応表に基づき、必須項目の欠損やデータ型の不一致を網羅的にチェックすることが手戻り防止に直結します。マスタデータとトランザクションデータそれぞれについて、具体的な検証項目を整理し、SQL等を用いた確認手法を適用します。
- マスタデータの項目対応確認
- コード変換ロジックの正確性検証
- 関連データの整合性チェック
①-1. マスタデータの項目対応確認
顧客マスタ、商品マスタ、勘定科目マスタなど、業務の基盤となるマスタデータの項目マッピング確認は、移行テストの最優先事項です。旧システムの項目が新ERPのどのフィールドに格納されるかを定義した対応表をもとに、データが欠落なく正しく移行されているかを検証します。
ExcelのVLOOKUP関数やSQLの結合（JOIN）を用いて、移行元のレコード数と移行先のレコード数を比較し、差異がある場合は原因を特定します。また、NULL値の許容性や文字コードの影響など、技術的な確認ポイントも重要です。
たとえば、旧システムで全角カタカナとして登録されていた顧客名が、新ERPで半角カタカナに変換される仕様の場合、変換ルールが正しく適用されているかを確認します。必須項目が空欄になっていないか、データ型が数値型のフィールドに文字列が混入していないかなど、基本的なデータ品質チェックを徹底します。
①-2. コード変換ロジックの正確性検証
旧システムと新ERPでコード体系が異なる場合、変換テーブルの正当性確認が不可欠です。たとえば、旧システムの部門コードが3桁の数字で管理されていたものを、新ERPでは5桁の英数字に変換する場合、変換ルールが正しく定義され、全てのコードが漏れなく変換されているかを確認します。
旧コードと新コードの関係には、1対1（単純置換）、N対1（複数の旧コードを1つの新コードに統合）、1対N（1つの旧コードを複数の新コードに分割）など、様々なパターンが存在します。それぞれのパターンごとにテストケースを設計し、変換漏れや重複登録がないかを検証します。
また、変換対象外のデータ（廃止された旧コードや、移行対象期間外の取引に紐づくコード）が適切にハンドリングされているかも確認します。変換テーブルに存在しない旧コードが入力された場合のエラーメッセージや、デフォルト値の設定が妥当かを確認し、業務部門と合意を得ます。
①-3. 関連データの整合性チェック
マスタとトランザクション、あるいは親子関係にあるデータの参照整合性を確認します。たとえば、受注データに記録された顧客コードが顧客マスタに存在するか、受注日と出荷日の前後関係が論理的に矛盾していないかなど、業務ロジックに基づく整合性を検証します。
SQLを用いて、トランザクションテーブルから参照される全てのマスタコードが実際にマスタテーブルに登録されているかを確認します。孤立レコード（マスタに存在しないコードを参照しているトランザクション）が発見された場合、旧システムのデータ不備か移行ロジックの誤りかを切り分け、修正します。
また、日付の論理矛盾（受注日より前の出荷日、開始日より前の終了日など）や、金額の不整合（明細行の合計と伝票ヘッダーの金額が一致しない）など、業務的な整合性チェックも実施します。これらの検証を通じて、移行後のERPで業務処理がエラーなく実行できる状態を担保します。
②全件移行テストにおける検証ポイント
全件移行テストでは、単なるデータ確認だけでなく、インデックス再構築や統計情報更新を含む実稼働に近い環境での性能評価が必須です。
大量データ移行時に発生するパフォーマンス低下やシステムリソースの枯渇問題に焦点を当て、処理時間の計測・分析手法とボトルネック特定後のチューニングポイントを整理します。
- 移行所要時間の計測と分析
- システムリソースの監視とチューニング
- 大量データ特有のエラーと対策
②-1. 移行所要時間の計測と分析
抽出（Extract）、変換（Transform）、ロード（Load）の各工程ごとに所要時間を記録し、本番移行のタイムスケジュールとの乖離を分析します。各工程の処理時間を可視化することで、並列処理の導入やバッチサイズの最適化が必要な箇所を特定します。
たとえば、旧システムからのデータ抽出に2時間、コード変換や項目マッピングなどの変換処理に3時間、新ERPへのロードに4時間かかった場合、合計9時間の移行時間が本番の停止可能時間（たとえば週末の8時間）に収まらないことが判明します。
この場合、抽出処理を事前に実施して変換とロードのみを本番時間内に行う、あるいは複数テーブルを並列処理することで時間短縮を図ります。各工程の開始時刻と終了時刻をログに記録し、ボトルネックとなっている処理を特定することが、現実的な移行スケジュールを策定する第一歩です。
②-2. システムリソースの監視とチューニング
移行中のCPU使用率、メモリ使用量、ディスクI/Oを監視し、リソース不足に陥った際の対処法を事前に準備します。リソース監視ツールを用いてボトルネックを特定し、メモリ割り当ての拡張やディスク競合の解消を図ります。
たとえば、大量のデータを一度にメモリに読み込もうとしてメモリ不足エラーが発生する場合、バッチサイズを小さくして複数回に分けて処理する設定に変更します。また、ディスクI/Oが高負荷になっている場合は、一時ファイルの保存先を高速なSSDに変更する、あるいはデータベースの設定を調整して書き込みバッファを増やすなどの対策を講じます。
移行処理中にシステムが停止してしまうと、再実行に時間がかかり本番移行のスケジュールに影響するため、リソース監視と事前のチューニングは不可欠です。
②-3. 大量データ特有のエラーと対策
トランザクションログの肥大化やタイムアウトなど、大量データ移行特有のエラー事例とその回避策を整理します。ログファイルの容量制限や長時間トランザクションによるロック待機など、大量データ移行特有の停止リスクを事前に排除します。
たとえば、データベースのトランザクションログが上限に達してしまい、移行処理が途中で停止するケースがあります。この場合、移行処理を複数のトランザクションに分割し、定期的にコミットすることでログの肥大化を防ぎます。
また、移行処理中に他のユーザーやバッチ処理がデータベースにアクセスしてロック競合が発生しないよう、移行専用の時間帯を設けて排他的に実行します。バックアップ戦略との整合性も重要で、移行処理の前後で確実にバックアップを取得し、万が一の失敗時に迅速に復旧できる体制を整えます。
③移行リハーサル（本番想定テスト）の実施手順と時間計測
移行リハーサルを通じて「誰が・いつ・何を」行うかを分単位で検証し、不測の事態に備えたバッファの妥当性を評価します。本番移行当日と同じ手順・体制で実施するリハーサルは、タイムテーブルの精度向上と関係者間のコミュニケーションフローの確認に不可欠です。
- 本番移行手順書の作成とレビュー
- タイムテーブルの作成と時間計測
- リハーサル後の振り返りと改善
③-1. 本番移行手順書の作成とレビュー
作業項目、担当者、判定基準を網羅した手順書を作成し、作業の依存関係を整理して並行実施可能なタスクを洗い出します。手順書には正常系だけでなく、各工程の完了判定基準と異常時のエスカレーション先を明記することが不可欠です。
たとえば、「旧システムのデータベースからデータを抽出する」という作業項目に対して、担当者名（情報システム部のAさん）、開始予定時刻（土曜日22時）、完了判定基準（抽出ファイルのレコード数が事前確認値と一致すること）、異常時の連絡先（プロジェクトマネージャーのBさん）を明記します。
また、抽出作業が完了しないと次の変換作業に進めないという依存関係を図示し、並行実施できる作業（たとえば、マスタデータの移行とトランザクションデータの移行を別々のサーバーで同時実行）を特定します。手順書を関係者全員でレビューし、曖昧な表現や判断基準の不明確な箇所を修正します。
③-2. タイムテーブルの作成と時間計測
実績時間を記録するためのタイムテーブルを運用し、遅延が発生した場合のリカバリープランと中断判断のタイミングを明確にします。リハーサルでの実測値に基づき、想定外の遅延を吸収できる現実的なバッファを含めた最終スケジュールを確定します。
タイムテーブルには、各作業の開始予定時刻、終了予定時刻、実績時刻を記録する欄を設けます。リハーサルを実施しながら、実際にかかった時間を記録し、予定との乖離を分析します。たとえば、データ抽出作業が予定の2時間に対して3時間かかった場合、1時間の遅延が発生します。この遅延を後続の作業でどう吸収するか、あるいは全体スケジュールを見直すかを判断します。
また、一定時間内に作業が完了しない場合は移行を中断し、旧システムに切り戻す判断基準（デッドライン）を事前に設定します。たとえば、日曜日の朝6時までに全ての移行作業が完了しない場合は、切り戻しを実施して月曜日の業務開始に備えるといった基準を定めます。
③-3. リハーサル後の振り返りと改善
リハーサルで露呈した課題を整理し、手順書や体制をブラッシュアップします。発見された軽微な手順漏れや時間乖離を修正し、全ての懸念事項を解消した状態で本番移行に臨みます。
リハーサル終了後、関係者全員で振り返り会議を開催し、発生した問題点と改善策を議論します。たとえば、「ネットワークの接続手順が手順書に記載されておらず、担当者が迷った」「データ検証用のSQLスクリプトにバグがあり、結果が正しく表示されなかった」といった問題が発見された場合、手順書を修正し、スクリプトを修正して再テストします。
また、想定よりも時間がかかった作業については、原因を分析して対策を講じます。リハーサルを複数回実施し、毎回改善を積み重ねることで、本番移行の成功確率を高めます。
データ整合性検証のポイント
移行テスト後は、その正確性を客観的に証明するため、件数・金額・属性の3軸で突合を行います。特に会計データは円単位での一致を検証することがERP移行の最低条件となります。
ここからは、テーブル単位の件数比較から、財務諸表に影響する金額の一致確認、期首残高の検証まで、実務的なアプローチを整理します。
5-1. 件数突合の実施
移行対象データの総件数および条件別件数の比較を行います。テーブルごとのCOUNT関数実行だけでなく、ステータス別や期間別の内訳突合により、移行漏れの有無を精査します。
たとえば、顧客マスタの総件数が旧システムで10,000件、新ERPで9,950件だった場合、50件の差異が発生しています。この差異の原因を特定するため、削除済みフラグが立っている顧客や、移行対象期間外の顧客が含まれているかを確認します。
また、受注データについて、ステータス別（受注中、出荷済、キャンセル）の件数を旧システムと新ERPで比較し、特定のステータスで件数が一致しない場合は、そのステータスの移行ロジックに問題がないかを調査します。条件別の内訳突合を行うことで、単純な総件数比較では見逃される移行漏れを発見できます。
5-2. 金額突合の実施
売掛金・買掛金残高や在庫金額などの合計値を比較します。財務諸表の整合性を担保するため、旧システムの試算表と新システムの残高データを突き合わせ、1円の差異も許容せずに調査します。
たとえば、旧システムの売掛金残高が50,000,000円、新ERPの売掛金残高が49,999,850円だった場合、150円の差異が発生しています。この差異は端数処理（丸め誤差）によるものか、データ移行の不備によるものかを判断します。
端数処理の許容範囲を事前に定義し、その範囲を超える差異が発生した場合は、明細レベルで追跡して原因を特定します。会計データは財務諸表に直結するため、1円でも差異があると監査で指摘される可能性があります。金額突合では妥協せず、全ての差異を解明して修正します。
5-3. マスタ参照整合性チェック
トランザクションデータが参照するマスタコードの存在確認を行います。外部キー制約に相当する整合性をSQLで検証し、マスタ未登録によるエラーで業務が停止する事態を未然に防ぎます。
たとえば、受注データに記録された商品コードが商品マスタに存在しない場合、新ERPで受注処理を実行しようとするとエラーが発生します。このような孤立レコードを事前に検出するため、SQLを用いてトランザクションテーブルとマスタテーブルを外部結合し、マスタに存在しないコードを抽出します。
発見された孤立レコードについては、旧システムのデータ不備（廃止された商品コードが削除されずに残っている）か、移行ロジックの誤り（商品マスタの移行漏れ）かを判断し、修正します。マスタ参照整合性チェックを徹底することで、本番稼働後に業務が停止するリスクを大幅に低減できます。
業務部門によるユーザー受け入れテストの設計と実施も重要
ERP移行の最終判断は、実際の業務が新システム上で遂行可能であることを業務部門が確認するUATの結果に委ねられます。
IT部門の検証ではカバーしきれない、実業務シナリオに基づく検証の進め方を整理し、キーユーザーの巻き込み方からテスト結果の承認プロセスまで、業務部門との協働ポイントを明確にします。
6-1. 業務シナリオテストの設計
「受注から入金」といったエンドツーエンドの業務フローを用いたテストケースを作成します。
定型業務だけでなく、返品や一部キャンセルなどのイレギュラーな業務パターンが正しく処理できるかを検証します。
たとえば、通常の受注処理（商品を選択し、数量と単価を入力して受注登録）だけでなく、受注後に顧客から一部キャンセルの連絡があった場合の処理（受注数量を減らし、在庫を戻す）や、納品後に不良品が発見されて返品が発生した場合の処理（返品伝票を起票し、売掛金を減額する）など、実務で発生する様々なパターンをテストケースに含めます。
また、月次締めや決算など、頻度の低い重要処理についても、実際のデータを用いてテストを実施し、新ERPで正しく処理できることを確認します。業務シナリオテストを通じて、移行後のERPが実務で使えるかを総合的に評価します。
6-2. 業務部門への依頼と実施支援
業務部門の負担を軽減するためのサポート体制と、テストマニュアルの提供方法を整理します。
IT部門が横並びでサポートし、業務部門がテストそのものに集中できる環境を整えることがUAT完遂の鍵です。
業務部門の担当者は通常業務と並行してUATに参加するため、テスト期間や作業量を現実的に設定します。テストマニュアルには、操作手順だけでなく、期待される結果や判定基準を明記し、業務部門の担当者が迷わずにテストを実行できるようにします。
また、テスト中に不明点や問題が発生した場合、IT部門の担当者がすぐにサポートできる体制（たとえば、テスト実施中は専用のチャットルームでリアルタイムに質問対応する）を整えます。不具合を発見した場合の報告フローを明確にし、優先順位を付けて対応します。業務部門がテストに集中できる環境を提供することで、UATの品質を高めます。
6-3. UAT結果の評価と承認
テスト結果を集計し、本番移行の可否を判断する基準を整理します。致命的な不具合がゼロであることを前提とし、残存課題については稼働後の対応計画を合意した上で承認を得ます。
UATで発見された不具合を重要度別に分類し、致命的（業務が継続できない）、重大（回避策があるが業務に支障がある）、軽微（業務に影響がない）などのレベルを設定します。致命的な不具合が残存している場合は、本番移行を延期して修正します。
重大な不具合については、稼働後に即時修正する計画を立てた上で、業務部門と合意します。軽微な不具合は、稼働後の改善項目として記録し、優先順位を付けて対応します。テスト結果を業務責任者に報告し、正式な承認を得ることで、本番移行に対する組織全体の合意を形成します。
移行テストの精度向上と工数削減を実現するツール活用方針
移行テストの精度向上と工数削減を両立させるためのツール活用術を解説します。ETLツールによる変換自動化や、テスト自動化ツールによる検証の高速化手法を提示します。
7-1. ETLツールによるデータ変換の自動化
ETLツールを使用すると、データの抽出、変換、ロードの各工程を視覚的に設計し、自動実行できます。
たとえば、旧システムのデータベースから特定の条件でデータを抽出し、コード変換テーブルを参照して新コードに変換し、新ERPのデータベースにロードする一連の処理をツール上で定義します。
一度定義した処理は繰り返し実行できるため、テストのたびに手作業でデータを加工する手間が省けます。また、変換エラーが発生した場合のログ出力や、エラーデータの自動抽出機能を活用することで、問題箇所の特定が容易になります。ETLツールの導入により、移行テストの効率と品質を同時に向上させることができます。
7-2. テスト自動化ツールの活用
テスト自動化ツールを使用すると、画面操作やデータ入力を記録し、自動的に再実行できます。たとえば、受注登録画面で商品コードと数量を入力して登録ボタンを押す操作を記録し、異なる商品コードで繰り返し実行することで、大量のテストケースを短時間で消化できます。
しかし、移行テストにおいては「膨大な本番データのパターンを網羅するテストシナリオの作成」自体が大きな工数負担となることが課題です。
この課題を根本から解決するのが、現新比較自動検証ツール「PerfecTwin（パーフェクツイン）」です。
- 本番トランザクションをそのまま再現
- テストシナリオ作成工数をゼロに
- 定量的な現新比較と不具合検知
バルテスでは、PerfecTwinを活用した高度な現新比較検証から、日本語ノーコードツールによる業務部門向けの自動化支援まで、3,000件以上の実績に基づいた最適なソリューションを提供しています。これにより、移行リスクを最小限に抑えながら、劇的な工数削減と品質向上を両立させることができます。
7-3. SQL検証スクリプトの活用
SQL検証スクリプトの例として、「旧システムと新ERPのテーブルごとの件数を比較し、差異があるテーブルをリストアップする」「トランザクションデータが参照するマスタコードの存在確認を行い、孤立レコードを抽出する」「金額フィールドの合計値を旧システムと新ERPで比較し、差異を計算する」などがあります。
これらのスクリプトを事前に作成しておき、移行テストのたびに実行することで、手作業による確認ミスを防ぎ、検証結果を迅速に取得できます。検証結果をCSVファイルやExcelファイルに出力し、レポートとして関係者に共有することも容易です。SQL検証スクリプトは、移行テストの効率化に大きく貢献します。
ERP移行テストの進め方まとめ
ERP移行テストは、サンプル移行・全件移行・移行リハーサルという3段階で段階的にリスクを低減し、データの論理的正確性、処理性能、実行手順の妥当性を確認していく戦略が基本です。各段階で適切な検証項目を設定し、マスタデータとトランザクションデータの整合性を徹底的にチェックすることで、本番移行の成功率を高めることができます。
業務部門を巻き込んだユーザー受け入れテスト（UAT）を通じて、実業務シナリオに基づく検証を行い、IT部門の検証ではカバーしきれない業務の実行可能性を確認します。また、本番移行失敗時の切り戻し判断基準と手順を事前に明確化し、デッドラインを設定することで、万が一の事態にも迅速に対応できる体制を整えます。
バルテスのソフトウェアテスト・品質向上サービスは、国内トップクラスの4,000件以上の検証実績を持ち、日本語サポートの充実度やノーコードによる導入のしやすさが特長です。客観的な品質保証を求める場合、こうした第三者検証サービスの活用がプロジェクトリスクの低減に極めて有効です。
