ERP・CRM・基幹システムの移行プロジェクトにおいて、最も頻繁に発生するトラブルのひとつが「移行後のデータ品質問題」です。移行先でデータが正しく動かない・集計値が合わない・重複が大量発生する——こうした問題の多くは、移行前のデータ棚卸しやマッピング設計、移行テストが十分でなかったことに起因します。
本記事では、システム移行前に確認すべきデータ棚卸しの5つのポイントと、BFTが支援する移行前診断のアプローチを紹介します。
なぜ移行後にデータ品質問題が表面化するのか
旧システムでは「なんとか動いていた」データが、新システムへの移行を機に一気に問題化するのには理由があります。旧システムは長年の運用の中で、データの不整合を吸収する独自のロジックや「暗黙のルール」が積み重なっています。新システムにはそのロジックがないため、旧システムでは運用や独自ロジックによって表面化していなかった問題が、新システムへの移行で顕在化します。
また、移行プロジェクトはスケジュールが固定されていることが多く、データ品質の確認が後回しになりがちです。「移行してから直す」という判断が取られることもありますが、稼働後のデータ修正は業務への影響が大きく、コストも工数もはるかに大きくなります。
確認ポイント① レコード数・重複の確認
移行対象データのレコード数を正確に把握し、重複レコードの数と割合を確認します。同一の顧客・商品・取引先が複数のレコードとして存在している場合、移行先でどちらを「正」とするかを決めておかないと、移行後に重複したまま運用が始まります。
重複の定義は業務的な判断が必要です。「コードが違っても同一顧客」のケースはシステムだけでは判断できず、業務担当者との確認が不可欠です。移行前にこの合意を取っておかないと、移行後に大量の手作業が発生します。
確認ポイント② フィールドの充足率・フォーマット統一
新システムで必須項目として設定されているフィールドに、旧システムでNULL・空白・不正な値が入っていないかを確認します。例えば旧システムで任意入力だった「メールアドレス」が新システムでは必須になる場合、移行前に欠損を補完しておく必要があります。
日付・電話番号・郵便番号などのフォーマットも確認が必要です。旧システムで「2024/01/15」と「20240115」が混在していた場合、新システムの入力形式に合わせた正規化を事前に行わないと、移行バッチでエラーとなったり、一部データが取り込まれなかったりする可能性があります。
確認ポイント③ コードマッピング（新旧コード対応）
旧システムと新システムで区分コード・分類コードの体系が変わる場合、どの旧コードが新コードのどれに対応するかを網羅したマッピング表の作成が必要です。このマッピングが不完全なまま移行すると、コードが正しく対応付けられないレコードが発生し、集計結果やレポートの正確性に影響を与える可能性があります。
コードマッピングは技術担当者だけで完結しません。「この旧コードは廃止するのか・新コードに引き継ぐのか」という業務的な判断が必要であり、業務担当者・IT担当者・プロジェクト管理者の三者が合意した状態で作業を進める必要があります。
確認ポイント④ マスタデータの整合性
移行対象の中に顧客マスタ・商品マスタ・組織マスタ等が含まれる場合、マスタ間の参照整合性を確認します。例えば受注データが参照している顧客コードが、顧客マスタに存在しない——という「孤立レコード」が移行後に発覚すると、システム全体に影響が出ます。
参照整合性のチェックはSQLやデータ品質ツールなどを用いて技術的に確認できますが、「孤立レコードをどう扱うか」は業務判断です。削除・代替コードへの置換・マスタ追加・保留のいずれかを事前に決めておく必要があります。
確認ポイント⑤ 移行対象外データの方針
「全データを新システムに移行する」のか「一定期間以前のデータは参照用に旧システムを残す」のかを明確にしておきます。移行対象を絞ることでコストと品質確認の工数を削減できますが、「どこまでを対象とするか」の基準が曖昧なままプロジェクトが進むと、後から「この期間のデータはどうする」という判断が追加で発生します。
移行前診断で「動かせるデータ」と「直すべきデータ」を分ける
BFT Insightの移行前データ品質診断では、上記5つのポイントを体系的に確認し、「このまま移行できるデータ」「移行前に修正が必要なデータ」「移行対象から外すべきデータ」の3分類で整理します。移行スケジュールを守りながら品質問題を最小化するための優先順位付けもご支援します。
移行前データ棚卸し——5つの確認ポイント
まとめ：移行後の手戻りを防ぐために事前に確認すべき5点
- ①レコード数・重複：移行先での重複定義と統合方針を事前に合意する
- ②フィールド充足率・フォーマット：新システムの必須要件に合わせた補完・正規化を先行して行う
- ③コードマッピング：新旧コードの対応表を業務担当者との合意のもとで作成する
- ④マスタ整合性：孤立レコードを特定し、削除・置換・保留の方針を決める
- ⑤移行対象の範囲：どのデータを移行し、何を残すかを明確に定義する
システム移行のスケジュールが固定されているほど、データ棚卸しは早い段階から着手するのが原則です。移行直前に問題が発覚すると、プロジェクト全体を止めるか品質問題を抱えたまま稼働するかの二択になります。
よくある質問
データ棚卸しにはどのくらいの期間が必要ですか？
データ量や複雑さにもよりますが、一般的には移行プロジェクト開始後のできるだけ早い段階（数週間〜数カ月前）から着手することが望まれます。棚卸しで問題が発覚した場合の修正工数も必要なため、「移行の1カ月前から始める」では間に合わないケースも少なくありません。
旧システムのデータ品質が悪いと移行はできませんか？
品質が悪くても移行自体は技術的には実行できますが、移行後に業務が正しく動かないリスクが高くなります。重要なのは「どの問題は移行前に直すべきか」「どの問題は移行後に対処できるか」を判断し、優先順位をつけて対応することです。全部を完璧にしてから移行しようとすると、移行プロジェクト自体が前に進まなくなります。
データ棚卸しは社内のIT担当者だけで実施できますか？
技術的な確認（レコード数・NULL率・フォーマットチェック）はIT担当者だけでも実施できます。ただし「この重複はどちらが正しいか」「このコードはどう引き継ぐか」という業務的な判断は必ず業務担当者との確認が必要です。IT担当者だけで進めると技術的には整合が取れていても業務的に使えないデータになるケースがあります。