はじめる前に確認したい3つのこと

DataSangoを導入する前に、最低限整理しておきたいポイントは3つあります。

1. 「正」とするデータ構造とキー項目を決める

重複排除だけは、基本的に全データを対象にする必要があります。

その前提で重要になるのは、「どこまでを1レコードとみなし、何をキーとして同一判定するか」というデータ構造とキー設計です。

たとえば、次のような論点をあらかじめ決めておきます。

• 1社を「本社単位」で見るのか、「支店・拠点単位」で分けて扱うのか
• 関連会社やグループ会社を、どこまで別企業として扱うか
• 会社の同一判定で、必ず見るべきキー項目👉️例: ドメイン / 法人番号 / 電話番号 / 住所 の組み合わせなど
• 担当者の同一判定で、必ず見るべきキー項目👉️例: メールアドレス / 氏名＋所属会社 など

DataSango側では全レコードを対象に重複候補を拾いに行きますが、

「何をもって同一とみなすのか」が決まっていないと、ルールがぶれてしまいます。

ここで決めるのは「どのセグメントからやるか」ではなく、

「自社では何を1件と見なすか／どのキーを最重要視するか」です。

この設計が決まっていれば、全データを対象に重複排除をかけても、

後から「そもそも1件の定義が人によって違う」という事故を防ぎやすくなります。

2. 何を優先的に改善したいか

「データをきれいにしたい」だけでは範囲が広すぎて、ルール設計も効果検証もぼやけます。

DataSangoを使って、まずどの種類の問題を優先的に解消したいのかを1〜3個に絞ることが重要です。

たとえば、次のようなテーマが考えられます。

• 会社データの重複を減らしたい
• • 同じ企業が複数レコードに分かれていて、活動履歴や案件情報が分散している
  • レポート件数が膨らみ、実態が見えづらくなっている
• 担当者データの表記ゆれ・不整合をなくしたい
• • 氏名や会社名、メールアドレス、電話番号などの揺れで検索性が悪くなっている
  • 同じ担当者が別人として扱われてしまうことがある
• 同期後の品質管理を仕組み化したい
• • 外部システムとの連携やインポート後のチェックが属人的になっている
  • 新規データが入るたびに手作業で修正しており、運用負荷が高い

ここで決めた「何を改善したいか」は、後からKPI（重複率・欠損率・統一率など）や、最初の成功条件にもなります。

初期フェーズでは、テーマを欲張らず「これは確実に良くする」を少数に絞る方が、結果として前進速度が上がります。

3. 誰が判断し、誰が運用するか 

データ整備プロジェクトが止まりやすいのは、機能の問題ではなく意思決定の問題です。

たとえば、次のような判断は必ずどこかで発生します。

• 会社名は「登記上の正式名称」に寄せるのか、「営業上の呼び名」に寄せるのか
• 支店や子会社を、1つの企業としてまとめるのか、分けて扱うのか
• 複数のソースがある項目で、どのシステム・どの値を優先するのか
• 誤統合や誤クレンジングが疑われるとき、誰が最終判断を下すのか

ここが曖昧なまま進めると、「システムとしては処理されているが、現場は納得していない」という状態になり、運用が定着しません。

そのため、事前に次の役割をはっきりさせておくことを推奨します。

• データ運用責任者
• • 最終的なルール・方針を決める
  • 「自社としての正しい状態」を定義する
• 現場代表（営業 / マーケ / CS など）
• • 実際の運用や例外パターンを共有する
  • ルールが現実的かどうかをレビューする
• オペレーション担当（RevOps / 情シスなど）
• • DataSango上でルールを設定・変更し、実行結果をモニタリングする
  • 定期実行やエラー対応の窓口となる

この3者が事前に決まっていれば、

「全データを対象にした重複排除」→「ルール調整」→「定期運用」

というサイクルを、止まらずに回しやすくなります。

更新日 22/03/2026