階層と双方向のデータ
ほかに 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)
モジュール5／6：Data Architectコース第6章「マスターデータとID」。各モジュールは単独でも読めます。 前へ：地図は判断ではない · 次へ：チェックポイント1：Steve Trucking
このモジュールが答える問い： 複数のシステムが維持しているデータをどう管理するのか？
簡単なアーキテクチャ：ERPが顧客を所有し、Salesforceがコピーを受け取り、終わり。現実の企業はそれほどきれいではありません。ERPが法的な顧客を、Salesforceが営業上の関係を所有し、ある事業部はSAPに、買収した別の事業部は違うERPにいて、見込み客はSalesforceにしか存在しない。そして誰かがSalesforceのユーザーにERPが管理している項目を更新させたいと言い出し、矢印が両方向を指し始めます。これを教えるときに言うように、「一番難しいのは双方向の連携だ」。 両方向にデータを送ることが技術的に難しいからではなく、両方のシステムが変更に関わり始めた瞬間、権威について極めて正確でなければならなくなるからです。
双方向のデータは2つのマスターを意味しない
Section titled “双方向のデータは2つのマスターを意味しない ”ERPが請求先住所を所有し、それがSalesforceにコピーされています。営業担当者が顧客から住所が変わったと聞き、ビジネスはSalesforceを離れずに更新してほしいと考えます。もっともです。これでデータはERP → SalesforceとSalesforce → ERPの両方に流れます。Salesforceが請求先住所の共同所有者になったのでしょうか？ いいえ。連携の向きは権威を決めません。 営業担当者はSalesforceのコピーを変えているのではありません。アーキテクチャの上では、権威ある値を変えるよう依頼しているのです。ERPの項目を変えているのではなく、変えてほしいと頼んでいるのです。Salesforceはインターフェースであり、ERPはやはりマスターです。
それが設計を変えます。Salesforceがその項目を所有していたなら、保存して終わりです。ERPが所有しているなら、「保存」とは、Salesforceが提案された住所を送り、ERPがそれを検証して受け付け、自分のマスターを更新し、権威ある値を送り返すことを意味します。そうなって初めて、統制された値が変わったことになります。依頼 → 検証 → 受け付け → 公開であって、「両方のシステムを更新して、同期が保たれることを願う」ではありません。
双方向の連携は、双方向の権威を作らない。
マスターが「ノー」と言ったとき
Section titled “マスターが「ノー」と言ったとき ”ERPが変更を拒否します。顧客が無効になっている、住所がERPのルールに違反している、ユーザーに法的な住所を変える権限がない、ERPが止まっている、あるいはその間に誰かが顧客を変えた。Salesforceがすでに新しい住所を表示していたら、真実が2つあることになり、どちらが勝つかはモジュール1がすでに教えてくれています。ERPです。ですからアーキテクチャには、依頼済みだがまだ受け付けられていないという状態が必要です。別の提案値、「変更保留中」のフラグ、あるいは表示する前に確認を待つこと。仕組みはユースケースによります。ルールは変わりません。拒否された依頼を、競合する真実にしてはいけない。
ループと衝突
Section titled “ループと衝突 ”典型的なものがあります。ERPがSalesforceを更新します。Salesforceの連携が変更を見て、それをERPに送ります。ERPが更新を見て、それを送り返します。とても高くつくループを作ってしまいました。よい双方向の設計は、変更がどこで始まったのか、マスターがそれを受け付けたのか、そしてそれが新しいビジネス上の変更なのか、すでに処理されたものの反響にすぎないのかを知っています。ソースの識別子、タイムスタンプ、連携のメタデータ、冪等な処理。連携の章で深く扱います。マスターデータの原則はシンプルです。変更を生み出しているのか、反映しているのかを知る。
次は衝突です。第5章で一つ見ました。営業担当者がSteve’s Plumbing LLCを依頼する一方で、ERPの誰かがSteve’s Plumbing L.L.C.と入力します（統制されたレコードを守る）。もう一つあります。Salesforceが125 Main Streetを提案し、ほぼ同時にERPのユーザーがそれを130に変えます。どちらが勝つのでしょう？ 普遍的な技術的答えはありません。ERPがその項目を所有しているので常に勝つのかもしれません。Salesforceの依頼はレビューのキューに行くのかもしれません。後に受け付けられた変更が勝つのかもしれません。ERPが、出発点の値が変わっている更新はすべて拒否するのかもしれません。それは並行性の問題ですが、その下には権威の判断があり、誰が権威ある変更をしてよいかを誰も決めていないなら、どんな連携パターンもあなたを救えません。
そして一つの項目だけなら簡単なケースです。住所は番地、市区町村、郵便番号からなります。Salesforceが新しい番地を送る一方で、ERPはちょうど市区町村を変えたところです。番地だけを通しますか？ それとも住所を一つのトランザクションとして扱い、項目がすべて一緒に通るか一つも通らないかにして、変更全体を拒否しますか？ どの項目をひとまとまりで送るかは、最初の衝突の前に決めましょう。後ではなく。
双方向の連携を見るたびに、私は問います。両側が同じデータを変えたら何が起きるのか？ 答えが「たぶんそんなことは起きない」なら、まだ終わっていません。どちらが勝つのか、拒否するのか、キューに入れるのか、バージョンを比べるのか、レビューするのか？ そもそもその項目は両方の場所で編集できるべきなのか？ 最良の双方向の設計が、ある属性について一方向を取り除くことであることもあります。Salesforceは依頼でき、受け付けられた値を公開するのはERPだけ。データはやはり両方向に動きますが、その項目をマスター管理するのは一つのシステムだけです。その違いがすべてです。
階層もマスターデータである
Section titled “階層もマスターデータである ”関係もマスターデータになり得ます。北米とヨーロッパの地域を持ち、それぞれに国ごとの子会社があるグローバルな親会社。階層そのものが意味を持っています。親会社はどれか？ どの子会社がどの法人の下にあるのか？ どの取引先がグローバルな顧客に集約されるのか？ それがレポート、テリトリー、価格、契約、与信のエクスポージャー、サービス、データへのアクセス、分析を動かします。階層は、その中のレコードと同じくらい重要なことがあり、同じガバナンスが必要です。（試験は階層の管理に触れています。忘れやすいところです。）
Salesforceでは、取引先の階層は親取引先（Parent Account）項目で作ります。Lightningの階層ビューは最大2,000件の取引先を、ユーザーが見てよいものだけ表示します。個人取引先は階層に対応していません。そして取引先 部署名（Account Site）が会社の拠点を区別します（Considerations for Using Account Hierarchy (opens in a new tab)、英語）。しかし親取引先の項目は、アーキテクチャの問いに答えてくれません。誰が階層を所有しているのか？
試験に出やすい知識。 取引先の階層の基本を知っておきましょう。親取引先で作ること、Lightningのビューは最大2,000件の取引先を、ユーザーが見られるものだけ表示すること、個人取引先は対応していないこと、そして取引先 部署名（Account Site）が会社の拠点を区別することです。
一つの階層、複数のマスター
Section titled “一つの階層、複数のマスター ”私の経験では、階層は複数のマスターを持ちます。 北米の法人はSAPから、ヨーロッパの法人は別のERPから来て、新しい見込み客はSalesforceで作られ、買収した子会社はまだ移行していません。誰が階層を所有しているのでしょう？ 枝によります。 それぞれのERPが自分の枝を管理し、Salesforceは見込み客が変換されるまでその関係を管理します。境界がどこにあるかを全員が知っている限り、それは正当なアーキテクチャです。枝ごとに決めましょう。
階層の権威は枝ごとに割り当てられる。
ですから親取引先の項目に権威を隠させないでください。ユーザーがSalesforceで子会社の親を付け替えます。技術的には些細なことです。アーキテクチャの上では、その人は会社の法的な構造を変えたのでしょうか？ ERPがその枝をマスター管理しているなら、おそらく違います。ですからSalesforceはそれをブロックするか、変更依頼にすべきです。あるいはSalesforceが正当に商取引上の階層を持ち、ERPが法的な階層を持っているのかもしれません。それなら、それらはそもそも同じ関係であるべきではないのかもしれません。
一つの会社が、法的、請求、営業、サービス、地理的といった、複数の正当な階層を持つことがあります。グローバルな親会社が契約に署名し、地域ごとに個別にサービスを受け、請求は共有の財務法人を通り、営業は地域ごとに管理する。どれが本当の階層でしょう？ すべてです。それぞれが違う問いに答えています。間違いは、一つでなければならないと思い込むことです。関係の種類ごとにはっきりした権威があるべきです。モジュール1の属性の原則を、関係に当てはめたものです。
そして、すべての親子関係がマスターデータなわけではありません。今日の配送を一つのルートにまとめることは関係ですが、それはトランザクション、業務上の出来事です。顧客の階層は、長続きするビジネス上の関係を記述します。どちらもモデルの上では親子に見えますが、ライフサイクルは共有していません。その関係が何を意味し、その意味がどれくらい長く続くのかを問いましょう。
1人の顧客、2つのERP
Section titled “1人の顧客、2つのERP ”これを教えるとき、私は会場に問いかけます。Salesforceが一つでERPが複数あるクライアントと仕事をしたことがある人は？ 毎回手が挙がります。理由を尋ねると、ERPは地域ごと（北米に一つ、ヨーロッパに一つ）、機能ごと（配管の会社が電気工事の会社を買収し、それぞれが自分のERPを持ち続ける）、あるいは単に歴史的な経緯で分かれていることがわかります。事業が買収され、まだ誰も移行していないのです。
Steve’s Plumbingを顧客としましょう。北米で事業をしているので、北米のERPにはその顧客レコードがあります。そこへミュンヘンに事務所を開き、ヨーロッパのERPが独自の顧客番号で独自の顧客レコードを作ります。同じ会社、2つのレコード、2つのID。それを一つのSalesforce組織でどう表現するのでしょう？ 私は3つの方法を見てきました。
取引先の階層。 Steve’s Plumbingを親とし、Steve’s Plumbing North AmericaとSteve’s Plumbing Europeを子の取引先として、それぞれの子が一つのERPのレコードを表します。落とし穴は、子はもう本当の意味でSteve’s Plumbingではないことです。ある地域で事業をしているSteve’s Plumbingなのです。そして今見たように、階層は意味を持っています。
対等な取引先。 2つの取引先を並べ、それぞれにどのERPに属するかを示す項目、つまり会社コードや地域を持たせます。何も隠れていません。コストはレポートに現れます。世界全体のSteve’s Plumbingを見るには、この2つの取引先が同じ会社だと示す何かが必要です。
一つの取引先と、ERPごとの子。 Steve’s Plumbingは一つで、子オブジェクトにERPごとのレコードがあり、そのERPの顧客IDを持ちます。ERPが2つでも10でも構いません。営業担当者には一つの顧客が見え、一つの注文を出します。裏側では、フローが各明細をどのERPに送るかを決めます。電気工事は電気のERPへ、配管は配管のERPへ。しかし今度は、名前や住所のような共有の値についてどのERPが主なのか、そして顧客が一方のERPにいて他方にいないときに何が起きるのかを決めなければなりません。
1人の顧客、2つのERP：Salesforceで表す3つの方法。
ERP同士をどう同期させているかを尋ねる
Section titled “ERP同士をどう同期させているかを尋ねる ”では、どれにするか？ まず、ERPの構造をどれだけ営業担当者に見せるべきか？ どちらかのERPにログインするので、北米とヨーロッパが別の事業だと彼らがずっと知っているなら、それを隠さないでください。その構造を対等な取引先としてSalesforceに持ち込みましょう。ビジネスが営業の前に一つのSteve’s Plumbingを見せたいなら、ERPごとの子を持つ一つの取引先になります。
それから本当に決め手となる問いがあり、それはSalesforceの中では決まりません。私はクライアントに尋ねます。その2つのレコードを、ERP同士でどうやって同期させていますか？ 残高のように、それぞれのERPに固有のものではありません。それはトランザクションデータです。私が言っているのはマスターデータ、つまり正式名称や住所です。2つのERPを同期させているチームがあるなら、一つの取引先としてまとめられます。自分たちのERPの中で同期させられないなら、Salesforceの中で私たちが同期させられるとどうして期待できるでしょう？ その場合は対等な取引先か、階層です。
ERPとは何かを思い出しましょう。導入に何年もかかる巨大なシステムで、マスターデータを管理する独自のやり方を持っています。Salesforceがそれを動かすことはありません。私たちはERPをコントロールできません。コントロールできるのは、それをSalesforceでどう表現するかです。
真ん中のMDM
Section titled “真ん中のMDM ”私たちが来る前に、すでにこれを解決しているクライアントもいます。大企業で、長年事業を続け、ERPがいくつもある。Salesforceよりずっと前にこの問題にぶつかり、ERPの間を仲介する専用のMDM製品を真ん中に置いたのです。それがモジュール2の共存型や集中型のMDMです。こうなるとSalesforceはすべてのERPに配線しません。一か所、MDMハブを指し、顧客の一つの表現を受け取ります。ただし、頻繁に出会うとは思わないでください。それ自体が大きな導入プロジェクトで、私の長年の経験でも関わったのは2、3回だけです。そしてハブがあっても、それぞれの注文がどのERPに行くかがわかるように、あの子オブジェクトはやはり必要かもしれません。
真ん中のMDM：Salesforceは一か所を指す。
Steve Trucking：誰の階層か？
Section titled “Steve Trucking：誰の階層か？ ”小売パートナーには独自の構造があります。本社、地域の事業部、物流センター、店舗。Steve Truckingはその階層を所有しているでしょうか？ いいえ。パートナーが自分の組織についての権威です。しかしSteve Truckingは、契約、取引先の管理、サービス、レポートのために、同じ拠点について独自の商取引上の見方を必要とするかもしれません。もしかすると、パートナーの下に物流センターごとの子取引先を置く形で。2つの正当な階層、2つの権威。名前を付けましょう。そして一本の木がすべての関係を表しているふりをしないでください。
境界を見えるようにする
Section titled “境界を見えるようにする ”権威が分かれているときはいつでも、その境界を見えるようにしたいのです。項目の命名、レコードのメタデータ、ソースシステムの識別子、権限、連携の振る舞い、ドキュメント。私が避けたいのは、開発者が5つの連携を読んでようやく「この親取引先の値はSAPから来ている。ただし見込み客は除く。ただしヨーロッパは除く」と知ることです。それは保守できる権威のモデルではありません。階層が複数のマスターを持つなら、その分け方を記録しましょう。権威が変換で変わるなら、その変化を記録しましょう。Salesforceが変更を依頼できるけれど行えないなら、それを体験の中で明らかにしましょう。
Salesforceでは、それは一つの項目から始まります。これはマスターデータだとはっきり示す項目が必要です。ERPのキー、あるいは「マスターデータである」というフラグです。項目の編集可否はレコードタイプではなく、その項目で決めましょう。動的フォーム（Dynamic Forms）があれば、ERPの項目を参照のみで表示するためにレコードタイプはもう要りません（第5章、流れごとのレコードタイプ）。マスターの外でレコードを作ることは許しても構いませんが、編集には目を光らせましょう。
試験の先へ：AIが変えること。 顧客がエージェントに「請求先住所を125 Main Streetに変えて」と言います。その項目はSalesforceのすぐそこにあります。エージェントはそれを更新すべきでしょうか？ ERPが所有しているなら、すべきではありません。エージェントに必要なのは項目へのアクセスだけでなく、書き込みの権威です。そのアクションは承認された経路を組み込むべきです。変更依頼を送り、「請求先住所を更新しました」と偽って報告するのではなく、「変更を処理するよう依頼しました」と伝えるのです。
ここでアーキテクトが決めること
Section titled “ここでアーキテクトが決めること ”- Salesforceでの編集が権威あるデータを変えるのか、それを所有するシステムに変更を依頼するのか。
- 双方向の流れが、生み出された変更を反響とどう区別し、拒否、衝突、遅延、失敗をどう扱うか。
- 必要なら枝ごとに、誰がそれぞれの階層を所有するか。
- 複数のERPにある一つの顧客について、階層、対等な取引先、ERPごとの子を持つ一つの取引先のどれにするか。クライアントがERP同士をどれだけ同期させているかで決める。
- 競合する階層が、実は法的、請求、営業、サービスといった違う正当な関係なのかどうか。
- 権威の境界と承認された書き込みの経路を、ユーザー、連携、開発者、エージェントにどう見えるようにするか。
共有された権威が問題なのではありません。曖昧な権威が問題なのです。複数のERPが違う枝をマスター管理し、Salesforceがある属性をマスター管理してほかの属性の変更を依頼し、複数の階層が一つの企業を記述することはあり得ます。重要な属性と関係のそれぞれについて、誰が所有し、誰が変えてよく、権威ある変更がどこで行われ、システムが食い違ったら何が起きるのかを言える限り、そのすべてはうまくいきます。言えないなら、図にもう一本双方向の矢印を足しても直りません。
さらに学ぶ
Section titled “さらに学ぶ ”- Salesforceヘルプ、Considerations for Using Account Hierarchy (opens in a new tab)（英語）、2026-10-14確認。