営業、マーケティング、受注、請求、サポートに顧客データが分散すると、「同じ会社なのに別顧客」「担当者は退職済み」「親会社単位の取引額が分からない」といった問題が起きます。そこで顧客360度ビューが注目されますが、複数データを一画面に集めるだけでは、正しい顧客像にはなりません。誰を同一顧客とみなすか、どの値を採用するか、誰が訂正するか、利用目的と同意に沿って何を見せるかを決める必要があります。本記事では、CRM顧客マスタと統合プロファイルを分け、DMBOKとEAの観点から持続可能な顧客360度ビューを設計する方法を解説します。
情報を一画面に集める前に、顧客を識別し、正本を定め、利用目的と統制を設計します。
この記事でわかること
- 顧客360度ビュー、統合プロファイル、顧客マスタの違い
- B2Bで企業・拠点・人物・関係をモデル化する方法
- 重複排除、名寄せ、ID統合、正本選択の設計手順
- データ品質、同意、権限、責任者を運用へ組み込む方法
- EAとDMBOKでCRM・MA・ERP・DWHの役割を整理する方法
顧客360度ビューは「一つの巨大マスタ」とは限らない
顧客360度ビューとは、顧客の基本属性、関係者、接点、商談、購買、契約、請求、利用、問い合わせなどを、利用目的に応じて関連づけたビューです。Salesforceの公式文書は、ID解決による統合プロファイルについて、複数ソースを照合・統合する一方、ゴールデンレコードを作るMDMそのものではないと明記しています。この違いは重要です。
| 仕組み | 主な目的 | データの扱い | 注意点 |
|---|---|---|---|
| CRM顧客マスタ | 営業・サービス業務で顧客を登録・更新する | 業務上の正本候補と現在の状態を管理 | 他システムの顧客と一対一とは限らない |
| MDM | 企業全体の顧客識別子・標準・正本を統制する | 重複排除、階層、配信、訂正ワークフローを管理 | 業務責任と各ソースへの反映が必要 |
| 統合プロファイル | 複数ソースを名寄せし、分析・施策に利用する | ソース値と統合IDを保持し、用途別に統合 | マッチ・分割でIDが変化する場合がある |
| 顧客360度ビュー | 役割別に必要な顧客情報と行動を提示する | マスタ、取引、活動、指標を関連づけて表示 | 全利用者に全データを見せることではない |
目的が営業担当者のアカウント計画なのか、マーケティングのセグメントなのか、与信・請求の統制なのかで、必要な正確性、鮮度、属性、権限は異なります。最初にユースケースを選び、ビューとマスタの責任境界を決めます。
ステップ1:自社にとっての「顧客」を定義する
B2Cでは個人、世帯、契約者、利用者、支払者が異なる場合があります。B2Bでは法人、企業グループ、支店・拠点、部署、担当者、パートナー、代理店を区別します。単一の顧客(Account)テーブルにすべてを押し込むと、階層や関係、権限が複雑になります。
| 概念 | 表すもの | 主な識別子 | 主な責任部門 |
|---|---|---|---|
| Party | 個人または組織という取引主体 | 企業共通顧客ID | データガバナンス/MDM |
| Organization | 法人、事業所、グループ | 法人番号、社内企業コード等 | 営業企画・審査・マスタ管理 |
| Person | 担当者、利用者、契約者 | 人物ID。メールだけに依存しない | 営業・サービス・プライバシー |
| Relationship | 親子、勤務、担当、代理、購買関係 | 関係IDと有効期間 | 関係を利用する業務部門 |
| Contact Point | メール、電話、住所、チャネル | 接点ID、検証状態 | 各収集部門とデータ管理担当者(データスチュワード) |
| 取引先(Account) | 販売・契約・請求など、業務上管理する顧客単位 | CRM、ERP等の業務ID | 各業務システムの責任者 |
| Consent/Preference | 目的・チャネル別の同意、拒否、希望 | 主体、目的、時点、証跡 | 法務・プライバシー・マーケティング |
| Activity/Transaction | 接点、商談、受注、請求、問い合わせ | 各イベントIDと発生時点 | イベントを生成する業務部門 |
識別子、属性、関係、イベントを分けると、企業名変更、転職、組織再編、複数拠点を履歴として扱いやすくなります。顧客定義はSFA・CRM要件定義の最上流で合意してください。
ステップ2:ソースと正本の役割を決める
属性ごとに、作成元、更新権限、正本、配信先、更新期限を整理します。契約上の法人名は契約・ERP、営業上の表示名はCRM、メール同意は同意管理基盤など、同じ顧客でも属性の正本は異なり得ます。「最新の値を採用」だけでは、誤更新が正本になるおそれがあります。
| 属性例 | 正本候補 | 採用・併存ルール | 履歴・証跡 |
|---|---|---|---|
| 法人正式名 | 審査済み企業マスタ/ERP | 検証済みソースを優先 | 変更日、根拠、承認者 |
| 営業表示名 | CRM | 正式名と別属性で保持 | 更新者、更新日時 |
| 請求先住所 | 契約・請求システム | 契約単位で管理 | 有効期間、契約ID |
| 担当者メール | 本人確認済み接点 | 複数値と検証状態を保持 | 取得元、検証・失効日時 |
| マーケティング同意 | 同意管理の記録 | 目的・チャネル・地域別に判定 | 同意文面、時点、撤回証跡 |
| 顧客セグメント | 分析・営業ルール | 用途別値と算定基準を明示 | モデル/ルール版、算定日 |
ステップ3:標準化・重複排除・名寄せを分ける
Microsoftの公式ガイドでは、顧客統合を、対象データ選択、ソース内重複排除、ソース間マッチング、統合ビューという段階で説明しています。実務でも処理を分け、各段階の件数・品質・例外を計測します。
標準化
文字種、空白、法人種別、住所、電話番号、メールの大文字小文字など、比較用の表記を整えます。元の値を上書きせず、標準化値と原文を保持します。
重複排除
同一ソース内に重複登録された、同じ顧客の候補レコードをまとめます。登録経路や業務上の理由で複数アカウントが必要な場合もあるため、自動削除せず、業務キーと目的を確認します。
名寄せ・ID解決
ソース間のレコードを同一Partyへ関連づけます。法人番号や会員IDなど信頼できる決定的キーを優先し、名称・住所・電話の類似照合は限定して使います。Microsoft Learnも、曖昧一致を戦略的に用い、絞り込みに完全一致条件を組み合わせ、結果をテストすることを推奨しています。
| 判定結果 | 意味 | 業務リスク | 管理方法 |
|---|---|---|---|
| 正しい一致 | 同一顧客を統合 | 低い | ルール別の一致数を監視 |
| 誤一致 | 別顧客を同一と判定 | 情報漏えい、誤与信、誤施策 | 高リスク属性は自動統合を制限し、レビュー |
| 見逃し | 同一顧客を別顧客のまま保持 | 重複接触、取引額分断、分析誤差 | 未一致候補を品質バックログへ |
| 不確定 | 証拠が足りず判断不能 | 誤一致と見逃しの両方 | 候補リンクとして保持し、追加情報を収集 |
統合後にルールやソースが変わると、プロファイルが結合・分割される場合があります。旧IDと新IDの対応、下流システムへの通知、履歴レポートの再計算方針を決めておきます。
ステップ4:統合値の採用ルールを透明にする
候補を同一顧客と判断した後、属性ごとにどの値を表示・配信するかを決めます。信頼度の高いソースを優先、検証済み優先、最新優先、最も完全な値、複数値併存などを使い分けます。「採用する値を持つレコード」だけを残すと、判断根拠や有効な別接点を失うため、ソースレコードと統合値のリネージュを保持します。
営業には最新の有効連絡先、請求には契約時点の住所、分析には当時のセグメントが必要かもしれません。単一の値を全用途に強制せず、用途別ビューと共通マスタを分離します。
ステップ5:DMBOKに沿って品質と責任を運用する
DMBOKの観点では、顧客360度ビューはReference & Master Data、Data Quality、Metadata、Integration、Security、Governanceが交差する領域です。顧客ドメインのデータ責任者は、定義、品質基準、例外、共有範囲を意思決定し、データ管理担当者は重複候補、未入力、ルール変更、利用部門との調整を日常運営します。
- 個人・法人・拠点・担当者・関係・アカウントを区別している
- 企業共通IDと各ソースIDの対応を履歴付きで保持している
- 重要属性ごとに正本、更新者、採用ルール、鮮度を定義している
- 重複排除とソース間名寄せを別工程として測定している
- 誤一致・見逃しのサンプルを業務担当者が評価している
- 統合値からソースとルール版まで追跡できる
- 同意、利用目的、機密区分、行・属性単位の権限を実装している
- 訂正、統合、分割、削除要求を下流へ反映できる
- 品質指標と例外バックログを定例レビューしている
既存データの重複・欠損・移行はCRMデータ移行と品質保証で詳しく解説しています。
EAで顧客データの配置と連携を決める
EAでは、顧客を理解し、適切な施策を実行する業務能力を起点に、情報、アプリケーション、技術を設計します。CRMは営業接点、MAは施策、ERPは受注・請求、サービスシステムは問い合わせ、DWHは履歴分析など、それぞれの責任を明確にします。統合基盤やMDMを追加する場合も、既存システムを無条件に置き換えるのではなく、現行から目標への移行単位を定めます。
連携方式は用途に応じてAPI、イベント、バッチを使い分け、顧客ID、更新順序、エラー再送、削除・同意変更の伝播を設計します。ポイント・ツー・ポイント連携を増やすと、正本変更やID分割の影響が追えません。詳しくはCRM・MA・ERP・DWH連携をご覧ください。
小さく始める導入ロードマップ
- 営業、マーケティング、サービスなど優先ユースケースを一つ選ぶ
- 対象顧客、必要属性、意思決定、期待アクションを定義する
- ソース、ID、品質、同意、更新責任を棚卸しする
- 顧客概念モデルと正本・採用ルールを合意する
- 代表データで名寄せルールを試し、誤一致と見逃しを評価する
- 限定部門でビューを公開し、業務成果と品質を測る
- 訂正・変更・監視の運用を整えて対象を段階的に広げる
営業組織改革・SFA・CRM導入の記事一覧
- 営業組織改革の全体フレーム
- SFA・CRM導入の要件定義
- 営業プロセス標準化
- 営業KPI設計の実務
- 営業パイプライン管理と売上予測
- 顧客360度ビューの設計
- SFA定着とチェンジマネジメント
- CRMデータ移行と品質保証
- CRM・MA・ERP・DWH連携
- SFA・CRM刷新ロードマップ
まとめ
顧客360度ビューの価値は、情報量ではなく、正しい顧客を識別し、適切な利用者が根拠を理解して行動できることにあります。統合プロファイルと顧客マスタの役割を分け、顧客概念、ID、正本、品質、同意、責任を設計してください。名寄せツールの導入より先に、誤一致を許容できる範囲と、訂正を継続できる運用を決めることが成功の条件です。
高度設計:顧客360度を「一枚の顧客表」にしない
顧客360度は、全項目を一つの巨大レコードへ詰め込むことではありません。識別、属性、関係、同意、接点、取引を分離し、利用目的に応じて再構成できる再利用可能な顧客情報基盤として設計します。個人と法人、契約主体と利用者、世帯と拠点を同じ「顧客ID」に統合すると、営業集計は簡単でも権限、履歴、同意、企業グループ分析が破綻します。
| エンティティ | 主なキー・属性 | 設計判断 | 履歴 |
|---|---|---|---|
| Party | 永続ID、種別、状態 | 人・組織を共通の当事者として扱う | 統合・分割を別イベントで保持 |
| Identifier | 発行元、値、信頼度 | メール等を永続IDにしない | 有効開始・終了を保持 |
| Relationship | 主体、相手、役割 | 勤務先、親子会社、契約関係を表現 | 時点別に再現 |
| Consent | 目的、チャネル、根拠 | 顧客属性から分離し利用制約を持つ | 取得・撤回を追記 |
| Interaction | 時刻、接点、対象、結果 | 要約と原イベントの所在を分ける | 原則追記型 |
同一人物・組織かを証拠とルールで判定し、統合・分割を監査可能にします。
用途別の属性、関係、集計値を品質と鮮度付きで提供します。
同意、権限、利用目的を確認してCRM・MA・分析へ安全に配信します。
属性単位の正本・採用ルールと統制
「CRMを正本」とシステム単位で決めず、属性ごとに信頼できる正本データの提供元、優先順位、更新方向、手動訂正、期限切れを定めます。自動名寄せの閾値は一つに固定せず、誤統合の損失が大きい法人・同意情報は保守的にし、候補キューをデータ管理担当者が裁定します。
| 対象 | 信頼できる正本データの提供元 | 採用ルール | 統制・SLO |
|---|---|---|---|
| 法人名・法人番号 | 審査済みマスタ | 検証日が新しい承認値 | 変更根拠と承認者を記録 |
| 営業担当区分 | CRM | 有効日の最新組織割当 | 翌営業日までに反映 |
| 請求先 | ERP | 有効な契約・請求情報を優先 | 未反映を受注前に警告 |
| 配信同意 | 同意管理基盤 | 目的別の最新の有効な同意状態 | 撤回を規定時間内に伝播 |
| 推定関心 | 分析基盤 | モデル版・算出時刻付き | 期限切れと説明可能性を表示 |
非機能要件には、照合の再現性、ルール版、元の値保持、処理遅延、再実行、統合解除、アクセス制御、削除・保持、系譜を含めます。精度だけでなく誤統合率、未統合率、要確認滞留、配信遅延を監視し、閾値変更はサンプル再評価後に承認します。
顧客マスタ運営のRACIと成熟度
| 段階 | 状態 | A/R | 次の到達条件 |
|---|---|---|---|
| 1 個別照合 | 部門別名寄せ、手修正が中心 | A:各部門長/R:担当者 | 共通IDと品質基準 |
| 2 統制マスタ | 属性別正本、照合ルール、例外キューを運営 | A:データ責任者/R:データ管理担当者 | 系譜・同意・SLOを接続 |
| 3 情報プロダクト | 用途別ビューとデータ契約を提供 | A:プロダクト責任者/R:データチーム | 利用成果と誤判定を継続評価 |
| 4 適応型 | 事業再編や新チャネルへモデルとルールを迅速に適応させる | A:データ評議会/R:ドメイン責任者 | 学習を標準へ反映 |
成果物テンプレートと段階導入
| 段階 | 必須成果物 | 完了ゲート |
|---|---|---|
| 定義 | 概念モデル、用語集、利用目的、責任表 | 顧客・契約主体・利用者の違いを説明できる |
| 試作 | 照合データセット、閾値比較、誤判定台帳 | 業務代表が統合・分割を検証 |
| 限定配信 | 属性別正本表、同意ルール、データ契約、SLO | 一つの用途で再実行と訂正を確認 |
| 拡張 | 品質ダッシュボード、変更審査、廃止計画 | 下流影響と成果を定例レビュー |
- Identity Resolution
- 複数レコードが同一主体かを証拠と規則で判定すること。
- Survivorship
- 競合する属性値から代表値を選ぶ規則。
- False Merge
- 別主体を誤って一つへ統合すること。
- Golden Record
- 出典と規則に基づく代表ビュー。原データそのものの置換ではない。
設計の参考にした公式資料
顧客データの構想・マスタ設計をご支援します
Version株式会社では、EAとDMBOKをベースに、顧客概念モデル、CRM顧客マスタ、ID統合、品質・ガバナンス、CRM・MA・ERP・DWH連携を一貫して設計します。現状データの診断からご相談いただけます。
参考資料
営業改革・SFA・CRMテーマクラスター:営業組織改革の全体像 / SFA・CRM要件定義 / 営業プロセス標準化 / 営業KPI設計 / パイプライン・売上予測 / 顧客360・マスタデータ / SFA定着 / CRMデータ移行 / CRM・MA・ERP・DWH連携 / SFA・CRM刷新
関連するBI/DWHナレッジ:意思決定から逆算するBI要件定義 / セマンティックレイヤー / データ不一致とリネージュ
コメント