炎上しないCRM移行の教科書：データ移行でハマる「重複・マッピング・運用変更」を90日で乗り越える

CRMを入れ替える――言葉にすると簡単ですが、現場では「数字が合わない」「顧客が二重に増えた」「入力が面倒で誰も使わない」といった“移行後の失速”が起きがちです。特にPMや管理職の立場では、CRM移行が一度こじれると、営業・マーケ・CSの間で責任の押し付け合いが起き、意思決定が遅れ、パイプラインの信頼性まで落ちてしまいます。

この記事では、CRM移行で多発する3つの落とし穴――①重複（名寄せの崩壊）、②マッピング（項目定義のズレ）、③運用変更（現場摩擦）――を「実務の手順」と「成果が出る状態」から逆算して解説します。単なる設定論ではなく、データ移行の前後で何を決め、誰が責任を持ち、どこでテストし、どのKPIで“成功”を判定するかまで落とし込みます。

1. なぜCRM移行は“失敗しやすい”のか：データ移行×運用変更×組織の同時改修

CRM移行が難しい最大の理由は、データ移行と運用変更が同時に走る点にあります。旧CRMやExcelでは、多少の矛盾や抜けがあっても、ベテランが暗黙知で埋めていました。しかし新CRMでは、入力規則・必須項目・権限・レポートが“ルールとして固定化”されるため、曖昧だった部分が一気に露出します。結果として、移行そのものよりも「移行後の運用が回らない」ことが炎上の本質になります。

また、CRMは部署横断の基盤です。営業は受注に直結する情報を素早く入れたい、マーケは流入経路やスコアリングを正確に取りたい、CSは契約後の履歴を追いたい。目的が違うのに同じ顧客データを共有するため、CRM移行は“要求の衝突が起こる前提”で設計する必要があります。ここで重要なのは、稼働をゴールにしないことです。ゴールは「意思決定に使える状態」、つまり数字が再現でき、検索で迷子にならず、担当交代しても追客が止まらない状態です。

PMとして最初に定義したいのは、移行直後に落としてはいけないKPIです。たとえば「新規リードの初回対応までの時間」「商談ステージ更新の遅延」「週次パイプラインの数字の再現性」など、データ移行と運用変更の影響が直撃する指標を、移行前後で比較できる形で決めておきます。これがないと、CRM移行が“設定は終わったのに成果が落ちた”状態で迷走します。

2. 重複データ地獄を止める：名寄せ設計と“増え続ける重複”のガバナンス

CRM移行で最初に崩れるのが重複です。データ移行の段階で重複を放置すると、移行直後に「同じ会社が3つある」「担当者が分散して履歴が追えない」といった状態になり、現場は検索に時間を溶かします。重複は単にレコードが増えるだけでなく、レポートの母数が壊れ、マーケの施策評価や営業会議の数字が信用されなくなるのが致命傷です。

重複が起きる原因は大きく3つあります。第一に表記ゆれ（株式会社/㈱/英字/スペース）です。第二に識別子の不統一（個人メールと法人ドメイン、携帯と代表番号、部署変更）です。第三に登録経路の多重化（フォーム、展示会、名刺、手入力、CSV）です。これらを“現場の善意”で解決するのは不可能なので、名寄せは仕組みとして設計します。

実務では、名寄せの一致キーを「確度の高い順」に複数用意します。会社であれば「法人番号」「ドメイン＋住所」「会社名＋電話」など、個人であれば「メール」「電話」「氏名＋会社」などです。重要なのは、100%一致しない場合の扱いです。確度が低い一致は“候補”として提示し、人が確定する運用にしておくと、誤マージ（別会社を統合してしまう事故）を防げます。CRM移行では、誤マージのほうが復旧が難しいため、最初は保守的に設計するのが安全です。

さらに、重複は移行後も増え続けます。だからこそ、名寄せを一回の作業で終わらせず、ガバナンスとして回します。具体的には、(1)登録時に類似候補を出す、(2)週次で重複スキャンして修正する、(3)修正権限と手順を決める、(4)重複率をKPIとして監視する、という流れです。データ移行の品質を維持する仕組みがないと、半年後にまた同じ問題が再発します。

3. マッピング事故を防ぐ：データ辞書・変換ロジック・履歴の割り切り

データ移行のマッピングは「列対応表」ではなく“意味の翻訳”です。CRM移行では、同じ項目名でも部署ごとに意味が違うことが多く、ここを放置すると移行後のレポートが壊れます。たとえば「リード」が問い合わせを指すのか名刺を指すのか、「商談ステージ」が案件の状態なのか社内稟議の状態なのか。定義が曖昧なままマッピングすると、入力者が迷い、結果としてデータが汚れます。

実務で効くのはデータ辞書を作ることです。データ辞書には、項目名だけでなく、定義、入力者、入力タイミング、必須/任意、選択肢、レポートでの利用目的まで書きます。これにより、CRM移行の議論が“好み”から“目的”に切り替わります。特に選択肢（業種、流入チャネル、ステータス）は統合・分割・変換が必要になりやすいので、変換ロジック（旧→新）を明文化し、データ移行のテストで必ず検証します。

もう一つの落とし穴が履歴です。活動ログ、メール、メモ、添付を「全部持っていく」と、コストと期間が跳ね上がります。一方で「捨てる」と現場が困ります。おすすめは、意思決定に必要な期間を決めて割り切ることです。例として、直近2年の活動履歴はCRMに移し、それ以前はアーカイブとして参照できる場所（ファイルストレージやDWH）に置く、という方針です。CRM移行の目的が「意思決定」なら、無制限に過去を運ぶ必要はありません。

マッピング表を作るときは、後工程を想像してください。現場は結局「検索」「セグメント」「レポート」で困ります。だから、データ移行の設計は“欲しいレポートと検索”から逆算し、どの項目が必要かを決めるのが最短です。ここで名寄せキー（会社ドメイン等）と、ステージ定義（何をもって前進とするか）を同時に固めると、移行後の混乱が大幅に減ります。

4. 切替当日に失敗しない：WBS・テスト設計・凍結期間・ロールバック

CRM移行は、切替当日よりも「切替前のリハーサル」で勝負が決まります。データ移行を一度だけ本番で実行するのは危険で、最低でもサンプル移行→差分検証→改善→再移行のサイクルを回す必要があります。ここでPMが握るべきは、WBSに“検証の時間”を必ず入れることです。移行はやり直しが前提です。やり直せない計画が炎上します。

テストは「取り込めたか」ではなく「使えるか」で判定します。具体的には、(1)代表的な顧客を検索して履歴が追えるか、(2)商談がステージ別に集計できるか、(3)権限で見えるべき人に見えているか、(4)フォームや外部連携が意図通りに流れるか、を確認します。特に名寄せはテストで落ちやすいので、重複候補がどれだけ出るか、誤マージが起きていないかをチェックします。これはデータ移行の品質テストそのものです。

切替では凍結期間を設けるのが現実的です。旧CRMへの入力を止める時間を定義し、その間に最終のデータ移行を実行します。並行稼働を選ぶ場合は「どちらが正か」を明確にしないと、二重入力と重複が増えます。ロールバック条件（戻す判断基準）も事前に決めます。たとえば「主要レポートが再現できない」「フォームからの新規リードが欠損する」「権限が崩れて営業が活動できない」など、事業影響が大きい条件を定義し、判断の迷いを減らします。

5. 移行後90日が本番：運用変更を定着させ、成果を落とさない設計

CRM移行は“Go-Liveがスタート”です。移行直後は現場が新しい画面に慣れておらず、入力が遅くなり、データ移行のミスや重複が見つかり、問い合わせが集中します。ここで「入力しろ」と号令をかけても逆効果になりやすいです。重要なのは、現場が“得をする”設計にすることです。たとえば、入力したら自分の案件が整理され、次のToDoが見え、会議資料が自動でできる。こうした見返りを作ると、運用変更が自然に定着します。

入力負荷は徹底的に下げます。フォーム登録、名刺取り込み、メール/カレンダー連携、通話ログ連携、iPaaSによる自動同期など、可能な限り自動化し、手入力を減らします。手入力が必要な項目は「意思決定に必要な最小限」に絞ります。ここでデータ辞書が効いてきます。入力規約を文章で配るのではなく、画面の導線とテンプレ（商談メモの型、失注理由の書き方）で示すと、運用変更が現場に伝わります。

移行後90日の運用では、週次でデータ品質をレビューします。重複率、欠損率、ステージ更新遅延、初回対応時間など、CRM移行の副作用が出やすい指標を追い、改善タスクに落とします。ここで名寄せの定期実行（重複候補の確認・確定）を習慣化すると、半年後のデータ崩壊を防げます。データ移行は一度終わっても、品質管理は続きます。

6. 実務テンプレ集：CRM移行をやり切るための成果物とチェックポイント

最後に、PMが揃えておくと強い成果物をまとめます。CRM移行は関係者が多く、議論が拡散しやすいので、成果物で論点を固定します。まず必要なのが「現状棚卸表」です。データ源（旧CRM、Excel、フォーム、MA、会計、サポート）、連携（API、CSV、手作業）、帳票（会議で使う数字）を一覧にし、データ移行の対象と優先順位を決めます。

次に「名寄せ設計書」です。一致キー、優先順位、例外時の扱い（候補提示・人手確定）、修正権限、定期スキャン頻度を明文化します。これがあると、重複が出たときに“誰がどう直すか”で揉めません。続いて「マッピング表＋データ辞書」です。変換ロジック、選択肢統合、データ型、必須項目、入力タイミングを一体で管理し、データ移行テストの観点（何を確認するか）も紐づけます。

そして「テスト設計書（合格基準付き）」です。代表顧客の検索、主要レポートの再現、権限検証、フォーム連携など、現場が困りやすいシナリオをテストケースにします。最後に「運用定着パック」です。入力ガイド（画面遷移ベース）、テンプレ、FAQ、問い合わせ窓口、変更管理（項目追加やステージ変更の審議）をセットにし、運用変更を継続改善できる形にします。ここまで揃うと、CRM移行は“移行しただけ”で終わらず、成果に接続します。

まとめ

CRM移行は、ツールの入替ではなく、データ移行と運用変更を同時に成功させるプロジェクトです。重複が増えるのは設計が悪いというより、名寄せの責任範囲とルールが決まっていないことが原因になりがちです。マッピングは列対応ではなく意味の翻訳であり、データ辞書と合格基準がないと数字が壊れます。さらに移行後90日で、入力負荷の最小化と“使われる仕組み”を作れなければ、どんなCRMでも定着しません。

本記事で紹介したように、名寄せ設計、マッピング設計、データ移行テスト、切替計画、運用定着の順に、成果物で論点を固定しながら進めると、CRM移行は炎上しにくくなります。まずは現状棚卸と、移行後に落としてはいけないKPIの定義から始めてみてください。