システム移行前のデータ棚卸し：ERP・CRM移行で失敗しないための確認ポイント

ERP・CRM・基幹システムの移行プロジェクトでは、「移行後のデータ品質問題」が重要なリスクのひとつです。移行先でデータが正しく動かない・集計値が合わない・重複が大量発生する——こうした問題は、移行前のデータ棚卸しやマッピング設計、データクレンジング、移行テストなどが十分でない場合に発生しやすくなります。

本記事では、システム移行前に確認すべきデータ棚卸しの5つのポイントと、BFTが支援する移行前診断のアプローチを紹介します。

なぜ移行後にデータ品質問題が表面化するのか

旧システムでは「なんとか動いていた」データが、新システムへの移行を機に一気に問題化するのには理由があります。旧システムは長年の運用の中で、データの不整合を吸収する独自のロジックや「暗黙のルール」が積み重なっています。旧システムで許容されていたデータ形式や入力ルールが、新システムのデータモデル・必須項目・入力制約などと合わないことで、移行時に問題が顕在化することがあります。

また、移行プロジェクトはスケジュールが固定されていることが多く、データ品質の確認が後回しになりがちです。「移行してから直す」という判断が取られることもありますが、稼働後のデータ修正は業務への影響が大きく、追加の工数や手戻りが発生する可能性があります。

確認ポイント①　レコード数・重複の確認

移行対象データのレコード数を正確に把握し、重複レコードの数と割合を確認します。同一の顧客・商品・取引先が複数のレコードとして存在している場合、移行先でどちらを「正」とするかを決めておかないと、移行後に重複したまま運用が始まります。

重複の定義は業務的な判断が必要です。「コードが違っても同一顧客」のケースはシステムだけでは判断できず、業務担当者との確認が不可欠です。移行前にこの合意を取っておかないと、移行後に大量の手作業が発生します。

確認ポイント②　フィールドの充足率・フォーマット統一

新システムで必須項目として設定されているフィールドに、旧システムでNULL・空白・不正な値が入っていないかを確認します。例えば旧システムで任意入力だった「メールアドレス」が新システムでは必須になる場合、移行前に欠損を補完しておく必要があります。

日付・電話番号・郵便番号などのフォーマットも確認が必要です。旧システムで「2024/01/15」と「20240115」が混在していた場合、新システムの入力形式や移行ツールの仕様によっては、移行時のエラーや変換処理が必要になる可能性があります。そのため、移行前にフォーマットを確認し、必要に応じて正規化しておくことが重要です。

確認ポイント③　コードマッピング（新旧コード対応）

旧システムと新システムで区分コード・分類コードの体系が変わる場合、どの旧コードが新コードのどれに対応するかを網羅したマッピング表の作成が必要です。このマッピングが不完全なまま移行すると、コードが正しく対応付けられないレコードが発生し、集計結果やレポートの正確性に影響を与える可能性があります。

コードマッピングは技術担当者だけで完結しません。「この旧コードは廃止するのか・新コードに引き継ぐのか」という業務的な判断が必要なため、業務担当者・IT担当者・プロジェクト関係者でルールを確認し合意したうえで作業を進めることが重要です。

確認ポイント④　マスタデータの整合性

移行対象の中に顧客マスタ・商品マスタ・組織マスタ等が含まれる場合、マスタ間の参照整合性を確認します。例えば受注データが参照している顧客コードが、顧客マスタに存在しない——という「孤立レコード」が移行後に発覚すると、システム全体に影響が出ます。

参照整合性のチェックはSQLやデータ品質ツールなどを用いて技術的に確認できますが、「孤立レコードをどう扱うか」は業務判断です。削除・代替コードへの置換・マスタ追加・保留のいずれかを事前に決めておく必要があります。

確認ポイント⑤　移行対象外データの方針

「全データを新システムに移行する」のか「一定期間以前のデータは参照用に旧システムを残す」のかを明確にしておきます。移行対象を絞ることでコストと品質確認の工数を削減できますが、「どこまでを対象とするか」の基準が曖昧なままプロジェクトが進むと、後から「この期間のデータはどうする」という判断が追加で発生します。

移行前診断を進める際の体制と進め方

データ棚卸しと移行前診断を効率よく進めるには、IT担当者と業務担当者が連携した体制が不可欠です。技術的な確認（レコード数・NULL率・フォーマット）はIT担当者主導で実施できますが、「この重複はどちらを正とするか」「このデータは移行対象か」といった業務上の判断には、業務担当者やデータオーナーなど、対象データを所管する側の関与が必要です。役割を事前に整理せずに進めると、確認依頼のたびに業務サイドの意思決定が遅れ、移行スケジュール全体が詰まる原因になります。

推奨される進め方は、まず技術的な品質スキャンで「問題のあるデータの一覧」を作成し、問題ごとに「業務判断が必要か／技術的に自動修正できるか」を分類してから、業務担当者への確認をまとめて依頼する方式です。個別に都度確認するよりも、判断材料をまとめて提示するほうが意思決定が速く、抜け漏れも防ぎやすくなります。外部の視点を入れることで、社内では「当たり前」になっている問題の見落としを減らす効果もあります。

ERP移行でマスタに起きる4つの失敗パターン

ERP移行においてマスタデータに固有の失敗パターンが発生しやすい状況があります。移行前の棚卸しと並行してこれらのパターンを把握しておくことで、事前対策を講じやすくなります。

このうち「コード体系の不統一」は特に影響が大きく、旧ERPで複数部門が別々のコード体系を使っていた場合、新ERPへの統合時にコード体系の再設計や複雑なマッピングが必要になることがあります。

ERP移行後のデータ品質維持：移行前整備との連続性

ERP移行が完了した後も、マスタデータの品質維持は継続的な課題です。移行前に整備した品番体系・コードルール・マスタオーナー制度を、新ERP上での日常的な変更管理フローに組み込むことで、移行後もデータ品質を維持できます。移行前整備で定義したクレンジングルール・バリデーション条件を新ERPのシステム設定（入力規則・必須項目・コードマスタ）として実装することで、人による入力ミスを抑制し、一定の品質をシステム側でも担保できる仕組みが整います。移行後の品質モニタリングとして、稼働後の一定期間は、移行前と比較したデータ品質指標（NULL率・重複率・マスタ照合エラー率）を定期測定し、品質の劣化がないかを確認することが重要です。期間は業務特性や移行規模に応じて設定します。

ERP移行プロジェクトでは、新システムの機能要件・インターフェース設計・移行テストなど多くの作業が並行して走るため、マスタ整備が後回しになりがちです。しかし移行前に整備されたマスタデータが、新ERPにおける業務データの基盤となり、移行後の業務品質の土台になります。マスタデータの品質問題は、移行後の不具合や手作業修正につながる要因の一つです。移行前のマスタ整備に十分な時間と費用をかけることは、移行後の運用コスト削減に大きく貢献します。

まとめ：移行後の手戻りを防ぐために事前に確認すべき5点

• ①レコード数・重複：移行先での重複定義と統合方針を事前に合意する
• ②フィールド充足率・フォーマット：新システムの必須要件に合わせた補完・正規化を先行して行う
• ③コードマッピング：新旧コードの対応表を業務担当者との合意のもとで作成する
• ④マスタ整合性：孤立レコードを特定し、削除・置換・保留の方針を決める
• ⑤移行対象の範囲：どのデータを移行し、何を残すかを明確に定義する

システム移行のスケジュールが固定されているほど、データ棚卸しは早い段階から着手するのが原則です。移行直前に問題が発覚すると、プロジェクト全体を止めるか品質問題を抱えたまま稼働するかの二択になります。