データをマスター管理する4つの方法
ほかに 28 言語で読めます
English · Español · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
モジュール2／6：Data Architectコース第6章「マスターデータとID」。各モジュールは単独でも読めます。 前へ：属性ごとに一つの真実の源 · 次へ：照合、マージ、サバイバーシップ
このモジュールが答える問い： 組織はデータをどうマスター管理していて、どのスタイルが合うのか？
モジュール1で、権威は属性ごとに割り当てられると言いました。では、その属性が同時に複数のシステムにあるときはどうするのでしょう？ 顧客の情報がSalesforce、ERP、請求、サポート、もしかするとData 360、もしかするとウェアハウスにあり、それぞれが独自のバージョンを持っている。それが**マスターデータ管理（MDM）**が解こうとしている問題であり、MDMは一つのアーキテクチャではありません。4つのパターンを耳にするでしょう。レジストリ型、コンソリデーション型、共存型、集中型。 これらは製品の設定ではありません。一つの問いへの4つの答えです。マスター管理の層は、どれだけの権威を持つのか？
製品ではなく問題から始める
Section titled “製品ではなく問題から始める ”人はMDMと聞くと、MDMの製品を買いに行きます。私なら問題から始めます。複数のレコードが同じ顧客だとわかればいいだけなのか？ 分析のために一つにまとめた見方が必要なのか？ どの値が権威を持つのかを決めて、それをほかのシステムに送り返す必要があるのか？ それとも一つの中央のシステムに全員のためのマスターデータを作らせたいのか？ まったく違う要件、まったく違うアーキテクチャです。
レジストリ型：誰が誰なのかを教えて
Section titled “レジストリ型：誰が誰なのかを教えて ”最も軽いパターンです。レジストリはソースを置き換えません。ERPは自分の顧客を、Salesforceは自分の取引先を、請求は自分の顧客を持ち続け、レジストリはこれらのレコードが同じエンティティを表していることを突き止めます。Salesforceの取引先001…、ERPの顧客SAP-43821、請求の顧客BILL-9127は一つの顧客に属する、と。ソースはその場にとどまり、上書きされません。これで「この顧客について知っていることをすべて見せて」に答えがあります。
しかし、レジストリが答えないことに注目してください。Salesforceは123 Main Street、ERPは125、請求は「123 Main St., Suite 200」と言っています。レジストリはそれらが一緒であることを知っています。どれを変えるべきかは決めません。つなぐことはマスター管理ではありません。
私の経験では、Salesforceのプロジェクトではレジストリ型が普通で、 次にコンソリデーション型と共存型が来て、純粋な集中型MDMはまれです。レジストリ型が一般的なのは、侵襲的でないからです。価値を得る前にすべての業務システムを設計し直す必要がありません。Salesforceは自分のすることを続け、ERPも自分のすることを続け、IDの層を一つ加えるだけです。すべてのシステムに「あなたはもう顧客データを管理していない。この新しい中央のシステムが管理する」と告げるよりずっと小さな変化です。
レジストリ型が答えるのは、どのレコードが同じ実体に属するか、です。
コンソリデーション型：データを一つにまとめる
Section titled “コンソリデーション型：データを一つにまとめる ”コンソリデーションは、複数のソースからデータを取り、レポート、分析、セグメンテーション、顧客インテリジェンスのために、中央の表現にまとめます。おなじみの例はウェアハウスです。Salesforceが顧客を、ERPが財務を、請求が支払いを送り、ビジネスはようやくシステムをまたいで顧客を分析できます。ソースは存在し続け、権威を持ち続けているかもしれません。向きが重要です。データはまとめられたシステムへ流れ込み、そのシステムはたいていマスター管理した変更を送り返しません。顧客のよりよい姿を手にしても、その業務上の権威にはならないのです。
レジストリ型とコンソリデーション型は混同しやすいものです。違いは何が集中化されるかです。レジストリ型は識別を集中化し（「これらは一緒だ」）、コンソリデーション型はより多くのデータを集中化します（「使えるように属性をまとめよう」）。どちらも「この中央のシステムが今やマスターであり、すべてのアプリケーションはその値を受け入れなければならない」とは言いません。
コンソリデーション型は、ソースから所有権を奪わずにデータを一か所に集めます。
共存型：決めて、送り返す
Section titled “共存型：決めて、送り返す ”共存型では、マスター管理の層が本物の権威を手にします。データは依然として複数の業務システムにありますが、MDMのプロセスがマスター管理された値を決め、それを公開し直します。Salesforce、ERP、請求がそれぞれ違う正式名称を持っていれば、MDMのプロセスが統制された正式名称を決め、それを3つすべてに配布します。システムは共存していますが、マスター管理された値に収束していきます。
それはずっと強い形のMDMです。「これらは一緒だ」と言っているのではなく、**「この属性について、企業が使うのはこの値だ」**と言っています。それには照合以上のものが必要です。ビジネスルール、所有、サバイバーシップ、双方向の連携、エラー処理、ガバナンス。誰かが、なぜある値が勝つのかを決めなければならないからです。
共存型は、レコードをつなぐだけではありません。マスター管理された値を決め、それを送り返します。
集中型：マスターが真実を作る
Section titled “集中型：マスターが真実を作る ”最も強いパターンです。集中型MDMでは、統制されたマスターデータは中央のマスターで作成・維持され、ほかのすべてに配布されます。それぞれのシステムが独自の顧客を作り、MDMが後でそれを調整するのではなく、マスターで統制された顧客を作り、それからSalesforce、ERP、請求に送ります。非常に強いガバナンスであり、非常に大きな変化です。既存のプロセスは独自の顧客を作り、ユーザーには自分たちのワークフローがあり、連携は手元での作成を前提にし、事業部門は顧客とは何かについてさえ合意していないかもしれません。だから私が目にするSalesforceの環境では、まれなのです。正しいこともあり得ます。道具を導入するよりずっと大きな判断です。
集中型MDMは、作成と権威をマスターに移します。
4つを並べて
Section titled “4つを並べて ”| スタイル | 何が集中化されるか | ソースは残るか？ | 統制された値を送り返すか？ |
|---|---|---|---|
| レジストリ型 | 識別とつながり | はい | たいていいいえ |
| コンソリデーション型 | 識別とまとめたデータ | はい | たいていいいえ |
| 共存型 | 識別、データ、マスター管理の判断 | はい | はい |
| 集中型 | 作成と権威 | はい、利用者として | はい |
表を下に行くほど、マスター管理の層はより多くの権威を手にし、組織はたいていより多く変わらなければなりません。
試験に出やすい知識。 4つのMDMの実装スタイルを知っておきましょう。レジストリ型（IDをつなぐ。ソースは自分のデータを持ち続ける）、コンソリデーション型（データを一か所に集める。たいていは分析のため）、共存型（マスター管理された値を決め、ソースに配信し戻す）、集中型（マスターがデータを作成し、ソースはそれを使う）。
ですから「集中型が最も成熟しているので、全員がそこを目指すべきだ」ということはありません。問題を解決する最も軽いパターンを選びましょう。 レコードが一緒であることがわかればいい？ レジストリ型を考えましょう。分析のためのまとめた見方？ コンソリデーション型。統制された値を複数の業務システムに同期し戻す？ 共存型。一つのプロセスが全員のためにマスターデータを作り、管理する？ 集中型。
Data 360はどこに当てはまるか？
Section titled “Data 360はどこに当てはまるか？ ”Data 360は多くのソースをまたいで統合プロファイルを作ります。MDMによく似て聞こえますし、実際に問題の一部を解きます。そのID解決は、ソースのプロファイルを統合されたIDに照合し、ソースレコードへのつながりを保持します（Data 360 Architecture (opens in a new tab)、英語）。それはレジストリ型に最も近いものです。統合プロファイルの上に調整された値を表示することもできます。しかしそれで、ソースを書き換える集中型のゴールデンレコードのシステムになるわけではありません。統合された見方は、自動的にマスター管理された企業のレコードではありません。 モジュール4はまるごとその違いについてです。
共通のモデルは共通の真実ではない
Section titled “共通のモデルは共通の真実ではない ”標準データモデル（canonical data model）という言葉も耳にするでしょう。Salesforceの取引先、ERPのビジネスパートナー、請求の顧客がすべて、合意された識別子と属性を持つ一つの合意された企業の概念、顧客に対応づけられ、すべての連携がほかのすべてのシステムの形を理解しなくて済むようにするものです。Data 360のデータモデルは、ソースを共通の概念に調和させる例です。しかし標準モデルが答えるのは、**これをどう一貫して表現するか？**です。MDMが答えるのは、**システムをまたいで、これをどう識別し、統制し、マスター管理するか？**です。3つのシステムを完璧に一つの顧客の形に対応づけても、Salesforceはやはり123 Main Streetと言い、ERPは125と言います。構造は解決しましたが、権威は解決していません。調和させることとマスター管理することは、入れ替えられません。
一つのビジネス、複数のパターン
Section titled “一つのビジネス、複数のパターン ”ですから「Steve TruckingにはMDMが必要だ」は要件ではありません。何についての？ 小売パートナー、物流センター、クルー、トラック、受取人は、違う権威を持つ違う領域です。小売パートナーはSalesforceと財務ERPで統制され、トラックの識別はFleetLinkから来て、受取人はそれぞれの配送ごとにパートナーから提供されます。違う領域には違うパターンが当てはまり得ますし、一つの領域の中でも属性によって権威が違うことがあります。ですから図の真ん中にMDMとラベルを付けた箱を描いて、解決したことにしないでください。その箱が何をするのかを問いましょう。
スタイルは連携も変えます。レジストリ型にはIDのつながりが、コンソリデーション型には信頼できる受信の流れが、共存型には両方向のデータが、集中型にはマスターからの配布と、ほかのシステムが競合する真実を作るのを止める管理策が必要です。権威が大きくなるほど、調整も大きくなり、失敗の扱いも大きくなります。MDMが正式名称を変え、ERPがそれを拒否したらどうなるのか？ だから共存型と集中型は「機能を増やしたレジストリ型」ではないのです。違う運用上の責任を伴います。
MDMはビジネスの判断である
Section titled “MDMはビジネスの判断である ”最も大切なポイントです。MDMは本質的にテクノロジーの判断ではありません。権威についての判断です。誰が顧客を作るのか、誰が変えてよいのか、誰がどの値が勝つかを決めるのか、どのシステムがそれを受け入れなければならないのか、食い違ったら何が起きるのか。道具はそうした判断を実装できますが、組織にそれに合意させることはできません。だからMDMのプロジェクトは、テクノロジーが優れていても失敗することがあるのです。技術チームは照合を解決し、ビジネスは所有を決して解決しなかったのです。
私が痛い目にあって学んだ一般的な教訓です。複数のシステムが同じデータをマスター管理しているとき、それらが合意していないことをSalesforceが調整することはできません。2つのERPを動かしている会社には、私はそれらをどうやって同期させているのかを尋ねます。会社にできないのなら、Salesforceにもできません。モジュール5でその話をします（1人の顧客、2つのERP）。
ここでアーキテクトが決めること
Section titled “ここでアーキテクトが決めること ”- 問題が必要としているのは、IDのつながりか、まとめたデータか、送り返されるマスター管理された値か、中央での作成か。
- 企業全体に一つのパターンではなく、それぞれのデータ領域にどのパターンが合うか。
- マスター管理の層がどれだけの権威を持ち、どのシステムがその判断を受け入れなければならないか。
- 調和を権威と混同することなく、標準モデルが必要かどうか。
- 選んだパターンが、連携の向き、所有、失敗の扱いをどう変えるか。
誰かが図にMDMの箱を置いたら、それが何をするのかを問いましょう。どのレコードが一緒かを知っているのか？ そのデータをまとめるのか？ どの値が勝つかを決めるのか？ その判断を送り返すのか？ そもそもデータを作るのか？ その答えが、本当に手にしているのがどのアーキテクチャで、権威がどこにあるのかを教えてくれます。
さらに学ぶ
Section titled “さらに学ぶ ”- Salesforce Architects、Data 360 Architecture (opens in a new tab)（英語）、2026-10-14確認。