名寄せツール導入の手順と期間——5ステップと標準2ヶ月の進め方
名寄せツールの導入は、契約したその日から動くものではありません。「何をもって同じ顧客とみなすか」の合意づくりと、初回マージまでの安全な段取りが本体で、標準的な期間は約2ヶ月です。この記事では、導入の全体像を5つのステップに分け、週次の期間目安、必要な体制、そして先人がつまずいてきたポイントまで解説します。
導入の全体像——5つのステップ
ツールが変わっても、名寄せ導入の骨格はほぼ共通です。次の5ステップで進みます。
ステップ1. 接続・現状診断
対象システム(Salesforce・kintone・データベースなど)を接続し、まず現状を数字にします。総レコード数、重複候補の件数と割合、表記揺れの傾向、欠損の多い項目。ここで出た診断結果が、以降のすべての判断の土台になり、経営層への説明資料にもなります。
診断で見るべき数字の目安も持っておきましょう。放置された顧客データの重複率は1〜2割にのぼることが珍しくなく、「思ったよりきれいだった」というケースはまれです。「重複率15%・約4,500組」のような具体的な数字が出ると、プロジェクトの優先度は社内で一気に上がります。逆にこの診断を飛ばして条件設計から入ると、後続の判断がすべて感覚頼みになります。
接続の実務では、いきなり書き込み可能な状態にせず、参照のみの権限で読み取るところから始めます。診断の段階で必要なのは読み取りだけで、書き込み権限が要るのは初回マージの直前からです。権限を段階的に広げる段取りにしておくと、情報システム部門のセキュリティ承認も通しやすくなります。
ステップ2. 重複条件の設計
導入の成否を分ける最重要工程です。「会社名と電話番号が一致したら同じ」「メールドメインが同じでも支店が違えば別」——こうした判定ルールを、実データを見ながら業務部門と合意します。あわせて、揺れを吸収する辞書(略号・旧社名・通称)の整備もここで行います。
よくある失敗は、この工程を会議室の抽象論で進めてしまうことです。「厳しめの条件でいきましょう」といった方針論からは、実行できるルールは出てきません。実務の進め方は逆で、実データから「この2件は同じか?」というケースを20〜30組持ち込み、1組ずつ判定してもらいながらルールを言語化していきます。営業と経理で判定が割れたケースこそ、ルールとして書き残す価値のあるケースです。
ステップ3. プレビュー・全件シミュレーション
設計した条件を、いきなり本番データに適用してはいけません。まず全件に対して「もし実行したら何と何が統合されるか」をシミュレーションし、結果のサンプルを目視で検品します。ここで誤判定のパターンを見つけて条件に反映する、というループを数回まわします。
検品のサンプル数は、確信度の高い帯・判断が割れそうな帯・低い帯からそれぞれ数十組ずつ、合計100組前後を見るのが目安です。全件を見る必要はありませんが、高確信度の帯に誤りがないことだけは重点的に確認します。ここが汚れていると、自動マージに回せるものがなくなり、以降の運用がすべて手動承認になってしまうためです。
ステップ4. 承認・初回マージ
シミュレーション結果を確信度で分類し、確実なものから承認して統合を実行します。判断が割れるものは承認キューで人が1件ずつ確定します。初回マージは件数が最も多く、リスクも最も高い実行なので、必ず戻せる状態(スナップショット取得済み)で行います。
実行のタイミングは業務への影響が小さい時間帯を選び、直後に件数の検算——統合前の総件数から統合組数を引いた値が統合後の総件数と一致するか——で結果を確かめます。承認キューに残った判断待ちを初回に全部さばこうとしないのもコツです。残りは日々の運用の中で消化する計画にしたほうが、確実に定着します。
ステップ5. 運用定着
データは日々の入力とインポートで汚れ続けるため、初回マージは終わりではなく始まりです。定期実行のスケジュール、新しく検出された候補を誰がいつ承認するかの運用ルール、辞書のメンテナンス手順を決めて、担当者に引き渡します。定期実行の頻度は、データの汚れる速さで決めます。日々インポートが走る環境なら週次、手入力が中心なら月次が出発点です。
期間の目安——標準は2ヶ月
5ステップを週次に落とすと、標準的なスケジュールは次のようになります。
| 期間 | やること | マイルストーン |
|---|---|---|
| WEEK 1-2 | 接続・現状診断。重複の件数・傾向を数字にする | 診断結果の共有 |
| WEEK 3-4 | 重複条件の設計。実データを見ながら業務部門と合意、辞書の整備 | 重複条件ルールの確定 |
| WEEK 5-6 | 全件シミュレーションとプレビュー確認。誤判定を条件に反映するループ | 初回マージのGO判断 |
| WEEK 7-8 | 承認・初回マージの実行、運用ルールの整備と引き渡し | 運用開始 |
これはナヨセルの標準的な導入支援(2ヶ月)と同じ構成です。期間が延びる典型要因は、対象システムが多い(接続と診断が増える)、関係部署が多い(条件の合意に時間がかかる)、データ量が特に大きい、の3つです。逆に、対象がCRM1つで数万件規模なら、これより短く終わることもあります。
スケジュールが崩れるとき、崩れるのはほぼWEEK 3-4です。重複条件の合意に業務部門を巻き込めず、IT部門だけで仮決めして先に進んだ結果、WEEK 5-6のプレビューで「この統合は困る」が噴出して設計に戻る——という手戻りが典型パターンです。だからこそ、キックオフの時点でデータオーナー(次章)のWEEK 3-4の予定を押さえておくことが、期間どおりに終わらせる最大のコツになります。
逆に短縮を狙う場合、削ってよいのは「待ち時間」だけです。診断結果が出てから会議を設定するのではなく、WEEK 1の接続と同時に、WEEK 3の条件設計ワークショップまで関係者の予定を確定させてしまう。予定が先に押さえてあれば、2ヶ月の中の「誰も作業していない期間」はほとんど消せます。一方、工程そのもの——特にシミュレーションの検品ループ——を省くのは、初回マージの品質に直結するのでおすすめしません。
必要な体制——3つの役割
名寄せはIT部門だけでは完結しません。最小構成は次の3役です(兼務可)。
| 役割 | 担当すること | 工数の目安 |
|---|---|---|
| データオーナー(業務部門) | 「同じ顧客」の定義を決める。判定に迷うケースの最終判断。導入後の辞書メンテ | WEEK 3-6に週2〜3時間 |
| 承認者 | シミュレーション結果の検品、承認キューの処理、初回マージのGO判断 | WEEK 5-8に週2〜3時間 |
| IT担当 | 対象システムの接続(管理者権限・API利用可否の確認)、アカウント管理 | WEEK 1-2に数時間+随時 |
ポイントは、データオーナーと承認者を「決めてから」始めることです。ツールの操作はベンダーが支援できますが、「この2社は同じか」の判断は社内にしかできません。この役割が空席のままだと、後述のつまずきポイント1に直行します。
兼務にする場合の注意はひとつだけ——承認者の時間を「予定として」確保することです。承認キューの処理は1件ずつなら数十秒でも、まとまると腰の重い作業で、「手が空いたらやる」運用では確実に滞留します。週2〜3時間をカレンダーに固定で入れる。それだけで定着の成否が大きく変わります。
IT担当の作業で忘れられがちなのが、API利用枠の確認です。CRMによってはAPIコール数に日次の上限があり、全件シミュレーションや書き戻しは、既存のシステム連携と同じ枠を消費します。既に他の連携が上限近くで動いている環境なら、実行の時間帯をずらす調整をWEEK 1-2のうちに済ませておくと、後工程で止まりません。
つまずきポイント5つ
導入プロジェクトが停滞・失敗する原因は、おおむね次の5つに集約されます。
1. 重複条件の合意が取れない
営業は「支店ごとに別扱いしたい」、経理は「請求先単位でまとめたい」——部門によって「同じ顧客」の定義が違うのは正常で、これを曖昧なまま進めると必ず後戻りします。対策は、ステップ1の診断結果(実データの実例)を材料に、ケース単位で決めていくことです。抽象論で議論しないのがコツです。
たとえば「同じ会社の支店」をどう扱うか。営業は担当が違うから別にしたい、経理は請求先が同じだからまとめたい——どちらも業務上は正しいのです。正しさ同士がぶつかるからこそ、「この項目の用途ではこう扱う」と実例ベースで決めるしかありません。
2. 関連レコードの放置
取引先だけ統合して、商談・対応履歴・請求情報の付け替えを後回しにすると、「統合したら過去の商談が見えなくなった」という事故になります。関連レコードの付け替えがツールの標準機能か、別途開発かは、契約前に確認すべき項目です。規模の感覚として、取引先1件に商談や履歴が平均10件ぶら下がっていれば、数百組の統合で付け替え対象は数千件になります。ここが手作業だと、初回マージの当日ではなく「その後の数週間」が埋まります。
3. 戻せない事故
初回マージで誤統合が起き、しかもロールバック手段がない——最悪のパターンです。実行前スナップショットの取得と復元手順の確認を、初回マージのGO条件に必ず入れてください。復元の「手順があること」と「試したことがあること」は別物なので、小さな範囲で一度リハーサルしておくと安心です。
4. 辞書不足
略号や旧社名の辞書をゼロから自社で作る前提にすると、WEEK 3-4が終わりません。標準辞書が同梱されているツールを選び、自社固有の揺れ(業界特有の通称など)だけを追加する形にすると、条件設計が軽くなります。自社で足すべき語は、実際には数十〜数百語に収まることがほとんどです。
5. 運用が続かない
初回マージの達成感で終わってしまい、数ヶ月後にはまた重複だらけ——というのは最も多い「静かな失敗」です。新規レコードは日々流れ込んでくるので、承認を止めれば重複は初回前と同じペースで再蓄積します。定期実行のスケジュールと承認の当番を、引き渡し前に運用手順書として固めておくことが対策です。
続けるコツは、当番の粒度を小さくすることです。「月末にまとめて全部処理する」ではなく「毎週金曜の朝に15分、承認キューを上から順に見る」——この粒度なら通常業務の中に収まり、滞留も起きません。承認キューの残件数を週次で記録しておくと、運用が回っているかどうかがひと目で分かる健全性の指標にもなります。
- 導入前に準備しておくもの:対象システムの一覧と総レコード数の概算
- 「同じ顧客とは何か」の定義のたたき台(部門間で割れそうな論点のリスト)
- データオーナー・承認者の指名(兼務可。ただし空席にしない)
- 対象システムの管理者権限とAPI利用可否の確認
- 初回マージの対象範囲(全件か、まず1システム・1部門か)
ナヨセルの導入支援——伴走型の2ヶ月
当社が提供するAI名寄せ・顧客データ統合クラウド「ナヨセル」では、この記事で述べた5ステップを、導入支援サービス(2ヶ月・50万円〜)としてご用意しています(選択制オプション)。条件設計と初回マージの伴走が名寄せの定着を左右することを、350社以上のデータ連携(Passwork)の経験から知っているためです。
2ヶ月の伴走で、次の3点を成果物としてお渡しします。
- 重複診断レポート——貴社データの重複件数・表記揺れの傾向・欠損状況を数字にしたもの。社内説明にそのまま使えます
- 重複条件ルール一式——業務部門と合意した判定ルールと辞書。編集できる透明なルールとしてナヨセル上に残り、属人化しません
- 運用手順書——定期実行・承認・辞書メンテの手順。担当者が変わっても運用が続く状態で引き渡します
進め方はこの記事の週次スケジュールそのままで、週1回の定例でマイルストーンを確認しながら進みます。貴社側にお願いする工数も本文の体制表のとおり——データオーナーと承認者あわせて週2〜3時間ずつが目安で、それ以外の作業は当社側で巻き取ります。
つまずきポイントへの備えも標準機能です。全件シミュレーション(582万件を90秒で突合した実測があります)、実行前スナップショットからの1クリックロールバック、確信度で自動マージ・承認待ち・対象外に分類する承認キュー、そして商談など関連レコードの付け替え込みの書き戻し(ファーストリリースはSalesforce・RDBMS対応)。料金は名寄せ対象のレコード数だけで決まります。詳細は料金プランのページと料金相場の記事をご覧ください。内製や代行と迷っている段階の方は開発費用の3年総額比較もあわせてどうぞ。
料金プランと導入支援の内容がわかる
資料をご用意しています
サービス概要から料金プラン、2ヶ月の導入支援の進め方まで
まとめた資料を無料でダウンロードいただけます。