属性ごとに一つの真実の源

🌐 ほかに 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)

AI で生成した画像

このページはAIで翻訳されています。コミュニティによるレビューはまだ行われていません。 英語で読む

モジュール1／6：Data Architectコース第6章「マスターデータとID」。各モジュールは単独でも読めます。 次へ：データをマスター管理する4つの方法

このモジュールが答える問い：「信頼できる唯一の情報源」は本当は何を意味するのか？

いつも耳にする言葉があります。「信頼できる唯一の情報源が必要です」。 わかりました。何についての？　顧客？　それでは具体的ではありません。取引先を例にとりましょう。顧客の名前、請求先住所、与信限度額、担当の営業責任者、サポートの階層、マーケティングの好みは誰が所有しているのか？　その答えは同じシステムを指しません。ERPが正式名称、請求先住所、与信の状態を管理し、Salesforceが関係の責任者と営業の属性を、別のプラットフォームが同意を管理しているかもしれません。ですから誰かが私に「Salesforceが顧客についての私たちの唯一の情報源です」と言ったら、私の次の問いはこうです。どの真実ですか？

真実は属性に属する

マスターデータの第一の原則はこれです。権威はレコードごとではなく、属性ごとに割り当てられる。 取引先はSalesforceにありながら、Salesforceがそのすべての項目について権威を持っていないことがあります。一つのレコードに7つの項目、2つの権威。

属性	権威を持つシステム
正式名称、請求先住所、ERPの顧客ID、与信限度額	ERP
営業責任者、戦略的取引先のフラグ、サクセスの階層	Salesforce

一つのレコード。真実は分散しています。それは普通のことです。「記録システム = Salesforce」ではそれを記述できません。権威のモデルならできます。

どこで作成され、編集され、参照され、どれくらい速く変わるのか？

マスターデータを教えるとき、私は重要なデータのそれぞれについて、いつも同じ問いに立ち返ります。どこで作成され、どこで編集され、どこで参照され、変更の遅延はどれくらいか？ これらはアーキテクチャをすばやくあらわにします。（最初の3つは第4章で、データの種類を分けるときに出会いました。それが本当の仕事をするのはここです。）

納入商品を例にとりましょう。顧客が自転車を3台注文します。Salesforceには商談とその商品明細があり、注文はERPへ行きます。ERPがそれを処理し、そこで納入商品が作成されます。3台の自転車、3つのシリアル番号が、Salesforceに送り返されます。数か月後、顧客がそのうちの1台について電話をかけてきて、サポートはケースの中でその納入商品を参照します。さて、誰かがある属性を訂正する必要が出てきました。Salesforceが編集してよいのはどれで、それを作成したERPに属するのはどれでしょうか？　そしてERPがその一つを変えたとき、Salesforceはどれくらい早くそれを知る必要があるでしょうか？　一つの納入商品、4つの問い。そして答えはすべての項目で同じではありません。

正式名称がERPで作成され、Salesforceで参照されていて、営業担当者がそれが間違っていることに気づいたとします。Salesforceで直すべきでしょうか？　ERPがその項目を所有しているなら、コピーを変えても何も直りません。せいぜい次の同期で上書きされ、最悪の場合は2つのシステムが食い違い、どちらを信頼すべきか誰にもわからなくなります。ビジネスが営業担当者に訂正を始めてほしいのなら、話は違います。Salesforceが体験を提供し、ERPに依頼を送り、ERPが変更を行うか承認し、権威ある値が戻ってくる。それは、Salesforceに勝手にその項目を編集させるのとはまったく違うアーキテクチャです。

遅延も真実の一部です。ERPが午前10時にある顧客の与信の状態を変えます。Salesforceは毎晩同期します。午後3時に営業担当者がSalesforceを見ます。その値は間違っているのでしょうか？　古いのです。その値が年に一度しか変わらず、1日の遅れが何のコストにもならないなら、毎晩で十分です。今日100万ドルの注文を受けるかどうかを決めるなら、十分ではありません。権威は真実がどこから来るかを示し、遅延はほかのものがそれが変わったことをどれくらい速く知らなければならないかを示します。2つの別々の判断です。

記録、エンゲージメント、参照のシステム

ここでは第4章の用語が役に立ちます。記録システムは権威あるバージョンを維持します。エンゲージメントシステムは人がそれを使って仕事をする場所です。参照システムは、別のシステムが使うけれど所有はしないデータを提供します。Salesforceは顧客との関係についてのエンゲージメントシステムでありながら、ERPがその法的・財務的な属性についての記録システムであり続けることができます。それはアーキテクチャの弱点ではありません。それこそがアーキテクチャです。間違いは、図をシンプルに見せるために、一つのシステムがすべてを所有しなければならないふりをすることです。

ハイブリッドなゴールデンレコード

これで「ゴールデンレコード」の意味が変わります。第5章では、悪いデータを入れないという話の中でこの考えを紹介しました。ここでは、それが設計の中心です。人は、すべての項目が一か所でマスター管理された魔法のレコードを思い浮かべます。それが設計であることもあります。Salesforceでより頻繁に見かけるのはハイブリッドです。取引先の一部はほかの場所でマスター管理されてコピーされ（正式名称、ERPの顧客番号、請求先住所、与信の状態）、一部はSalesforceが必要とするからこそ存在します（営業責任者、商談の戦略、サクセスの階層、関係のメモ）。ERPの項目は、人が使えるように入ってきます。Salesforceの項目は戻りません。ERPはそれを気にしないからです。どちらがどちらかを全員が知っている限り、完全に筋の通ったことです。

権威を見えるようにする

だから私は、外部の権威をスキーマの中で明らかにします。SAPが項目を管理しているなら、接頭辞を付けます。sap_Customer_Number、sap_Credit_Status、sap_Legal_Name。第4章のerp_の接頭辞と同じ考え方です。その権威が特定的で安定しているならシステムの名前を、今日のベンダーより意味が重要なら汎用の接頭辞を使いましょう。大事なのは、半年後にモデルを読む人がこうわかることです。これはただのSalesforceの項目ではない。別のシステムがこの値を所有している。 連携をリバースエンジニアリングして、権威を再発見させるようなことはしないでください。

権威の地図を作る

重要なマスターデータについて、私は権威の地図がほしいのです。主要な属性ごとに、誰が作成し、誰がビジネス上の判断を所有し、どのシステムが権威を持ち、誰が、何がそれを変えてよいか。 4つの別々の問いです。

属性	作成する人	ビジネス上のオーナー	権威を持つシステム	変えてよいもの
正式名称	財務	財務	ERP	財務のプロセス
与信限度額	財務	財務	ERP	与信チーム
営業責任者	営業オペレーション	営業	Salesforce	営業の管理職
サポートの階層	サービスオペレーション	サービス	Salesforce	サービスの管理職
同意	顧客本人	プライバシー	同意管理のプラットフォーム	顧客本人、承認されたプロセス

ビジネス上のオーナーと権威を持つシステムは同じではないことに注目してください。システムはポリシーを所有しません。人が所有します。システムはその結果を保存し、強制します。また第5章です。オーナーがポリシーを決め、アーキテクトがそれを強制する。

Click to enlarge

一人の顧客。多くの属性。それぞれに一つの権威。

権威はライフサイクルを通じて変わる

営業担当者が、ERPが聞いたこともない見込み客に出会い、Salesforceで取引先を作ります。その時点では、Salesforceが名前、住所、取引先責任者、評価について権威を持っています。見込み客が顧客になり、ERPが正式な顧客を作り、顧客番号、正式名称、請求先住所、与信を割り当てます。権威が移動しました。以前のSalesforceが間違っていたのではありません。ライフサイクルが変わったのです。第5章の、仮から統制済みへのパターンです。変換の前はSalesforceが見込み客を所有し、変換の後はERPが統制された属性を所有し、Salesforceは自分の属性を所有し続けます。ですから「どのシステムが取引先を所有しているか？」は弱い問いです。こう問いましょう。ライフサイクルのこの時点で、どのシステムがこの属性を所有しているか？

コピーは権威ではない

人がいつも必要とするので、私たちはERPのデータをSalesforceにコピーします。それはSalesforceを便利な手元のコピーにするのであって、マスターにするのではありません。アーキテクチャもそれに従って振る舞うべきです。ユーザーには読み取り専用で、連携が更新し、出どころのラベルを付け、依頼を通じてだけ変更し、コピーがずれたら照合で確認する。コピーは役に立ちます。権威は動いていません。

信頼には値以上のものが必要

「請求先住所：123 Main Street」。これを信頼すべきでしょうか？　私は信頼の兆候がほしいのです。どこから来たのか、最後に確認されたのはいつか、どのシステムが提供したのか、そして最後に変えたのは誰か、何か。人か、連携か、エージェントか？　今度はERPが123 Main Street、Salesforceが125、パートナーのファイルが「123 Main St., Suite 200」と言っています。どれが正しいのでしょう？　「一番新しいものを使う」と答えないでください。そうかもしれません。でも「一番新しいもの」は、それ自体が、最後に変えた人が勝つべきだと前提にしたルールです。それは正しいかもしれないし、ひどいことかもしれません。モジュール3でこれを扱います。信頼は権威と出どころから生まれるのであって、値が入っている項目を見つけることから生まれるのではありません。

Steve Trucking：それは誰の真実か？

小売パートナーが配送を送ってきます。その一つのトランザクションに、いくつもの真実が隠れています。パートナーの注文番号はパートナーのものです。Steve Truckingは更新を照合するためにそれを持っていますが、そのマスターにはなりません。配送ステータス（到着、配送済み、設置済み、例外）はSteve Truckingのものです。パートナーはそれを受け取りますが、ステータスを受け取ったからといって、トラックの上で何が起きたかについてパートナーが権威を持つわけではありません。そして受取人はパートナーの顧客です。Steve Truckingが配送するのに必要なので、パートナーが名前、住所、電話番号、配送メモを提供します。だからといってSteve Truckingがその人の識別のマスターになるわけではなく、その区別がチェックポイントでの受取人の設計を決めます。

Click to enlarge

一つの配送、2つの権威。

データがどこにあるかと、その真実を誰が所有しているかは、別々の問いです。SalesforceはERPの顧客番号を所有せずに持つことができ、Snowflakeは配送ステータスの業務上のマスターにならずに持つことができ、顧客データプラットフォームはすべての属性を所有せずにIDを統合できます。エージェントは3つすべてを読めますが、それはエージェントがどれが真実かを決めてよいということには、決してなりません。

試験の先へ：AIが変えること。 エージェントは、属性ごとの権威を実行のルールに変えます。人は間違った請求先住所を見て、「それはSAPから来ている。ここで変えるべきではない」とわかります。「顧客の請求先住所を更新して」と言われたエージェントは、そう設計しておかない限りわかりません。エージェントにはアーキテクトと同じ権威の地図が必要です。ある項目にアクセスできることは、その項目が書き込むべき正しい場所であることを意味しません。

ここでアーキテクトが決めること

• レコード全体に一つのシステムではなく、重要な属性のそれぞれについて、どのシステムが権威を持つか。
• それぞれの属性がどこで作成され、編集され、参照され、その変更がどれくらい速く伝わらなければならないか。
• 誰がそれぞれの属性のポリシーを決め、どの人、連携、エージェントがそれを変えてよいか。
• 外部の権威がモデルにどう表れるか：命名の接頭辞、権限、連携の振る舞い。
• 見込み客がERPに統制された顧客になるときのように、権威がライフサイクルを通じてどう移るか。

信頼できる唯一の情報源とは、一つの組織、一つのERP、一つのMDMプラットフォーム、一つの巨大なレコードという意味ではありません。統制された情報のそれぞれについて、アーキテクチャが権威ある値がどこにあるかを言え、ほかのすべてのシステムがそれによってどう振る舞うべきかを知っている、という意味です。それは唯一の情報源ではありません。真実のアーキテクチャなのです。

さらに学ぶ

• Salesforce Architects、Data 360 Architecture (opens in a new tab)（英語）、2026-10-14確認。