企業の顧客情報の整備を目的としたシステム検討において、MDM(Master Data Management：マスターデータマネジメント、マスターデータ管理)と、CDP(Customer Data Platform：カスタマーデータプラットフォーム、顧客データプラットフォーム)は、いずれも「社内に散在する顧客データを統合する仕組み」として同じ検討テーブルに載せられることが少なくありません。しかしながら、両者は、RFP(Request For Proposal：提案依頼書)や要件定義書に書き込むべき内容が根本的に異なります。同じ書式のまま提案を依頼した結果、評価軸が噛み合わないまま比較検討に入り、導入後にギャップが顕在化するといった悩みを、顧客データの整備・活用を支援する立場のユーソナーも、しばしばうかがうことがありあます。
本記事では、顧客データ基盤の要件定義を「MDM型」「CDP型」の2つのアプローチに体系化します。その上で、いずれの分類にも収まらない新たな考え方である「統合要件定義」について解説します。
顧客データ基盤の整備における「MDM型の要件定義アプローチ」
一般的に「MDM型の要件定義」とは、全社で共通参照される基準データについて、正しい状態の定義そのものを取り決めていく進め方を指します。顧客、取引先、商品、組織といったマスターデータを対象に、「何をもって同一とみなすか」「どの値を正とするか」を先に確定させる点に特徴があります。
顧客データ基盤の整備においてMDM型の思考でRFPを作成することは、SSOT(Single Source of Truth)の確立に強みがあると言われています。データの正確性が基幹業務や監査対応に直結するため、事前の合意形成に重心を置く進め方が合理的とされています。MDM型のRFPに書き込まれる項目としては、以下のような要素が挙げられます。
- 管理対象ドメインとスコープの定義
顧客、取引先、商品、組織のうち、どのドメインを最初の対象とするかを明示します。ビジネスインパクトの大きい領域から段階的に広げる方針と、対象外の範囲を併記しておくことで、提案の粒度が揃いやすくなります。
- 標準項目とゴールデンレコードの定義
統合後に「正」とみなすレコード、いわゆる「ゴールデンレコード」をどのような項目構成で保持するかを定義します。法人名、法人番号、所在地、業種、資本金といった項目ごとに、桁数や表記形式、必須／任意の別まで踏み込む必要があります。
- 名寄せ・マッチングルールと生存ルール
複数システムのレコードを同一と判定する基準と、値が競合した際にどのソースを優先するかの生存ルールを定めます。表記ゆれや旧社名、本支店の扱いをどこまで吸収するかによって、必要となる製品の性格が変わります。
- データガバナンスと承認ワークフロー
データオーナー、データスチュワードといった役割分担と、変更申請から承認までのワークフロー、権限設計、監査証跡の保持要件を記載します。運用ルールが属人化しない仕組みを、要件として明文化することが重要です。
- 既存基幹システムへの配信方式
レジストリ型、集中管理型、共存型のいずれのアーキテクチャを想定するかにより、ERP(Enterprise Resource Planning：統合基幹業務システム)やSFA(Sales Force Automation：営業支援システム)への反映方式が変わります。同期の方向とタイミングを示すことで、実装工数の見積り精度が高まります。
顧客データ基盤の整備における「CDP型の要件定義アプローチ」
一般的に「CDP型の要件定義」とは、実行したい施策から逆算して必要なデータと機能を規定していく進め方を指します。行動履歴や接点データのように時系列で蓄積される動的なデータを扱うため、正しさの定義よりも「どの施策に、どの鮮度で使えるか」が主要な論点となります。
顧客データ基盤の整備においてCDP型の思考でRFPを作成することで、施策の立ち上がりを早め、仮説検証のサイクルを短く回すことが可能となります。要件を固め切らずに着手し、運用しながら精度を高めていく前提に立つ点が、MDM型との大きな違いです。CDP型のRFPに書き込まれる項目としては、以下のような要素が挙げられます。
- ユースケースと成果指標の定義
どの部門が、どのセグメントに対して、どのチャネルで何を実行するのかをユースケース単位で記述します。あわせて成果指標を定義することで、提案が機能一覧の羅列に流れることを防げます。
- データソースとイベント設計
Webの閲覧履歴、フォーム入力、商談履歴、購買データなど、取り込む対象を列挙します。どのイベントをどの粒度で保持するかが、後続のセグメント精度とコストの双方に影響します。
- リアルタイム性の要求水準
すべてのデータに秒単位の即時性が必要となるわけではありません。日次バッチで足りる領域と、即時反映が必要な領域を切り分けて記載することが、過剰投資の回避に繋がります。
- アクティベーション先と連携方式
MA（マーケティングオートメーション）、CRM(Customer Relationship Management：顧客関係管理)、SFA、広告配信基盤など、統合結果を渡す先と、その連携がAPIによる双方向か一方向かを明記します。結果を書き戻せるかどうかが、効果測定の可否を左右します。
- 同意管理とプライバシー対応
取得経路ごとの同意状態をどう保持し、削除要求にどう応答するかを要件化します。個人情報保護法についてはいわゆる3年ごと見直しに基づく制度改正が進められているため（個人情報保護委員会の公表資料より）、将来の運用変更に追随できる設計が求められます。
データ活用の高度化において重要となる第三のロジック「統合要件定義」
「統合要件定義」とは、MDM型とCDP型を別々の検討として並走させるのではなく、一つの土台の上で接続して定義する考え方を指します。「どのデータをどの粒度で一意化し、その結果をどの施策がどの鮮度で参照するか」を同一のドキュメントに書き切ることを目的としています。
MDMで整備された信頼性の高いマスターデータをCDPへ供給することで、セグメンテーションやパーソナライズの精度が高まるという関係性は広く指摘されています。統合要件定義は、この関係性を後付けの連携作業ではなく、RFPの段階から前提として織り込む考え方です。具体的には、以下のようなプロセスを経て進められるとされています。
- 観察：現状のデータフローの可視化
どのシステムに、どの項目が、どの更新頻度で存在するかを棚卸しします。重複状況や表記ゆれの実態を、感覚ではなく件数で把握することが出発点です。
- 仮説生成：統合キーの粒度の設定
施策側が必要とする単位から逆算し、どの粒度で一意化すべきかの仮説を立てます。B2B領域では法人単位を基本としつつ、拠点別の与信管理や配送管理が必要な場合には事業所単位をあわせて保持する設計が検討されます。ここで定めた粒度が、後続の名寄せルールと連携要件の双方を規定します。
- 評価：要求水準の数値化
統合率、重複率、更新のタイムラグといった指標について、許容できる水準を数値で定義します。定性的な表現に留めると、提案の比較ができなくなります。
- 選択：役割分担の確定
一意化はMDM側で担うのか、CDP側の統合機能で担うのか、あるいは外部データの参照で解決するのかを決定します。ここまでを決めた上でRFPを配布することが推奨されます。
統合要件定義は、正しさと速さのどちらかを捨てるのではなく、要求水準を領域ごとに切り分けて設計するための実務的なメソッドと言えます。
データを活用した「統合要件定義」とは
「統合要件定義」は、社内データと外部データの双方を前提とした要件設計に適用することができます。B2B企業の顧客データ基盤においては、以下のような活用が期待できます。
統合要件定義の具体例
- 名寄せ要件の数値化
「名寄せができること」という記述では、提案内容を横並びで比較することができません。自社データの重複率を事前に測定した上で、統合率や誤って同一と判定した割合の目標値をRFPに明記することで、ベンダー側の検証条件が揃います。あわせて、判定ロジックを説明できるかも評価対象に含めることが有効です。
- 外部データ要件の明文化
自社が保有する情報だけでは、法人格の変更、本支店の関係、系列といった構造を正確に維持することは困難です。外部の企業データベースを参照する前提であれば、必要な項目、更新頻度、カバー範囲を要件として書き込みます。これにより、統合の責任範囲を社内と社外で切り分けられます。
- 部門横断のKPI(Key Performance Indicator：重要業績評価指標)と責任分界点の設計
情報システム部門が管理するデータ品質指標と、事業部門が追う成果指標を同じドキュメントに並べます。どの数値が悪化したときに誰が対応するのかを定義しておくことで、運用の形骸化を防げます。
- PoC(Proof of Concept：概念実証)シナリオの事前設計
検証すべきユースケースを2〜3件に絞り、使用するデータ量と合否ラインを事前に確定させます。本番相当のデータで検証する前提を要件に含めることで、デモ環境では見えない課題を早期に把握できます。
統合要件定義を用いることで、MDMとCDPのどちらを先に導入すべきかという議論は、目的に照らした構造的な判断へと置き換わります。ただし、これはあくまで仮説に基づく設計です。鮮度と網羅性を備えた企業情報データベースなどの事実データと突き合わせて検証することで、判断の確度が高まると考えられます。
おわりに
本記事のポイントを3点にまとめます。
①MDM型は正しさを、CDP型は使い方を定義する要件定義
②同じ書式でRFPを書くと評価軸が噛み合わず提案の比較が難しくなる
③統合要件定義により両者の要求水準を一つの土台の上で設計できる
です。
本記事でご紹介したアプローチはいずれも有用です。MDM型のアプローチは、全社統制と監査対応に強みがある一方で、要件確定に時間を要し、施策側の成果が見えにくくなりやすい傾向があります。CDP型のアプローチは、施策の立ち上がりが早い一方で、統合キーの品質が担保されないまま拡張すると、後から手戻りが生じやすくなります。両方のアプローチを状況に応じて使い分け、時には組み合わせることで、戦略的な意思決定を行うことが重要です。
弊社が提供する顧客データ統合ソリューション「ユーソナー」では、「LBC(Linkage Business Code)」という独自のコード体系を採用した企業データベースを提供しています。法人格や本支店、系列といった企業の構造を踏まえた顧客情報を、一元的に管理することが可能です。加えて、独自に収集した企業データを活用頂くことで、鮮度の高い外部情報を継続的に取得頂けます。要件定義の段階から、外部データと自社データの責任範囲を切り分けることに繋がります。
詳細についてはぜひこちらのページから、お気軽にお問い合わせください。
