CRMデータ移行の進め方――名寄せ・重複・履歴を品質保証する

CRMデータ移行は、旧システムから新システムへレコードをコピーする作業ではありません。同じ企業が表記違いで複数登録され、担当者が退職者の個人のメールアドレスにひもづき、商談と活動履歴の関係が切れていれば、件数が一致しても営業は使えません。移行を機に重複を消しても、どの値を正としたか、過去の履歴をどう残したか説明できなければ、顧客対応や監査のリスクになります。

品質保証の鍵は、移行前に顧客・取引・活動の業務上の意味、正となる情報源、統合ルール、保持方針、受入基準を合意することです。本記事では、ベンダーに依存しないCRMデータ移行の実務を、EAとDMBOKの観点から整理します。

移行目的とデータの利用シナリオを先に決める

「旧CRMの全データを移す」という要求は明確に見えて、実際には判断を先送りしています。新CRMで営業担当者が何を参照し、管理職が何を判断し、マーケティングやサービスが何を連携するかを定義し、それに必要な期間・粒度・品質のデータを選びます。法令・契約・監査上の保持と、日常業務でオンライン参照する必要も分けます。

対象決定には、画面の項目一覧だけでなく、アクセスログ、レポート、API、バッチ、帳票、外部連携を確認します。未使用に見える列が下流DWHでKPI計算に使われることもあるため、CRM・MA・ERP・DWH連携の影響まで追跡します。

移行台帳で意味・責任・変換を一つに管理する

ソースとターゲットの項目マッピングだけでは不十分です。移行台帳には、業務定義、データ責任者、ソース、ターゲット、変換規則、コード対応、NULLの扱い、品質ルール、保持期間、機密区分、照合方法を記録します。旧システムのIDは外部IDとして保持し、親子関係の再構成、差分調査、再実行の鍵にします。

名寄せは「似ている」だけで自動統合しない

名寄せは、表記標準化、候補抽出、同一性判定、採用する値の決定、関係統合の順で行います。会社名の法人格・空白・全半角、住所、電話、メール、ドメインを標準化し、完全一致とあいまい一致を組み合わせて候補を作ります。Salesforceの公式資料でも、一致ルールと重複ルールを分け、完全一致やあいまい一致から候補を特定し、警告または登録制御を行う考え方が示されています。

ただし、一致スコアが高いことと同一顧客であることは同義ではありません。同姓同名、共有メール、持株会社と子会社、合併前後など、業務判断が必要な境界があります。高確度は自動統合、中間はデータ管理担当者（データスチュワード）確認、低確度は別レコード維持という閾値と責任を決めます。

統合では「採用したレコード」だけでなく、旧IDの対応表、統合元、判定根拠、実行日時を残します。商談や活動、問い合わせ、同意が消えないよう、子レコードを統合先へ付け替える順序と検証を設計します。顧客360度ビューとマスタデータの記事も参照してください。

履歴は業務利用・監査・分析の3つの目的で設計する

すべての履歴を新CRMの画面へ移せばよいわけではありません。営業が日常参照する履歴、監査・紛争対応で保存する履歴、傾向分析に使う履歴を分け、CRM、アーカイブ、DWHの配置を決めます。作成日・更新日、担当者、商談ステージ、金額、同意の変更は、時点を再現できるかが重要です。

本番前に少なくとも三回の模擬移行を行う

一回目は技術疎通とマッピング、二回目は全量・性能・照合、三回目は本番と同じ人員・手順・時間枠での切替リハーサルです。毎回、抽出条件、コード版、入力ファイル、エラー、所要時間、修正を記録し、再実行して同じ結果になることを確認します。Salesforceの公式移行ガイダンスも、対象と項目を棚卸しし、依存順序を考慮し、少数レコードから検証し、件数・サンプル・例外レポートで妥当性を確認する手順を示しています。

1. 移行対象と保持・廃止を承認する
2. ソースをプロファイリングし、欠損・分布・重複の基準値を取る
3. 標準化、名寄せ、変換を原本から分離した作業領域で実施する
4. 親レコード、子レコード、活動・添付の依存順で投入する
5. エラーを原因別に分類し、修正・除外・例外承認を記録する
6. 件数、ハッシュ、統制合計、業務ルール、サンプルで照合する
7. 業務利用者が実シナリオで検索、更新、引継ぎ、レポートを確認する

件数一致を超える受入テスト

Microsoft Learnは、移行後のUATとデータ中心の回帰テストを、実運用に近い統合環境で業務利用者が行う重要性を説明しています。重大障害の定義、未解決件数、回避策、再テスト結果をGo／No-Go基準に含め、業務データ責任者が最終受入を承認します。

EAとDMBOKで移行後も品質を維持する

EAでは、顧客・商談データがどの業務能力を支え、どのアプリケーションと連携し、どこで分析されるかを可視化します。現行、目標、移行期のデータフローを分けると、新旧併存中の更新責任や影響範囲を説明できます。SFA・CRM刷新ロードマップと移行計画を同じ意思決定の下で管理してください。

DAMA-DMBOKの観点では、移行はデータ品質の一時作業ではなく、ガバナンス、マスタ・参照データ、メタデータ、統合、セキュリティを改善する機会です。名寄せルール、データ辞書、責任者、リネージュ、品質指標を本番運用へ引き継ぎ、重複や欠損が再発する入口を修正します。

実務チェックリスト

• 移行対象・保持・アーカイブ・廃止を業務利用シナリオから決めた
• データ責任者とデータ管理担当者が各データ群に割り当てられている
• 旧IDと新IDの対応を再実行可能な形で保持する
• 名寄せの一致条件、閾値、手動判定者、採用値ルールがある
• 商談、活動、同意、監査の履歴保持方針を合意した
• 親子関係と投入順序を移行台帳に記録した
• 本番同等の全量・性能・切替リハーサルを完了した
• 件数以外に値、関係、履歴、業務ルールを照合した
• 重大度別の受入基準と最終承認者を決めた
• 移行後の重複防止・品質監視・問題是正を運用へ引き継いだ

まとめ

CRMデータ移行の品質は、移行した件数ではなく、顧客の同一性、商談・活動との関係、履歴の意味を保ち、利用者が信頼して業務を継続できるかで判断します。移行台帳と模擬移行で判断根拠を記録するし、名寄せ・品質ルールを移行後のガバナンスへ残すことが成功条件です。

参考資料

• Salesforce Help「Salesforce Data Migration Best Practices」
• Salesforce Help「Data Quality」
• Salesforce Trailhead「Improve Data Quality in Salesforce」
• Microsoft Learn「Guidance for user acceptance test after data migration」
• ISO「ISO/IEC 25012:2008 Data quality model」
• DAMA International「What is Data Management?」

営業改革・SFA・CRMテーマクラスター：営業組織改革の全体像 ／ SFA・CRM要件定義 ／ 営業プロセス標準化 ／ 営業KPI設計 ／ パイプライン・売上予測 ／ 顧客360・マスタデータ ／ SFA定着 ／ CRMデータ移行 ／ CRM・MA・ERP・DWH連携 ／ SFA・CRM刷新

関連するBI／DWHナレッジ：意思決定から逆算するBI要件定義 ／ セマンティックレイヤー ／ データ不一致とリネージュ