Salesforceの物理モデルを設計する
ほかに 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)
モジュール10／10：Data Architectコース第3章「Salesforceのデータアーキテクチャ」。各モジュールは単独でも読めます。 前へ：データの一貫性を保つ · 次へ：章の学習ガイド、その後で次の章、企業のデータを理解する
このモジュールが答える問い： 論理モデルをSalesforceのアーキテクチャにするにはどうすればよいか？
この章は全体を通じて、プラットフォームには形があるという一つの長い議論でした。標準オブジェクトとカスタムオブジェクト、データを置ける場所、データ型、リレーション、所有、ライセンス、一貫性のルール、ストレージ、規模。そのどれもが、第2章の論理モデルの作られ方を変え得ます。では、Steve Truckingの一部分でそれをまとめてみましょう。
会社全体ではなく、一部分です。アーキテクトがよくやる間違いの一つは、企業全体を一枚の図で解こうとすることです。私がほしいのは、筋道立てて考えられるものです。小売パートナーが積荷目録を送り、Steve Truckingがそこに載っているものを配送し、配送ごとに必要なものを保持する。そして物理的な判断を一つずつ下していきます。全体の設計は第1部のチェックポイントです。
すでにわかっていることから始める
Section titled “すでにわかっていることから始める ”第2章で概念の作業は済ませました。小売パートナー、受取人、積荷目録、配送、配送品目、停車地の種類、クルー、トラック、物流センター、写真。関係に名前を付け、それが何を意味するかを問いました。それは繰り返しません。今の問いは、それらの概念がSalesforceの上でどう存在するかです。概要資料の中の一つの事実がすぐに重要になります。Steve Truckingはすでに、予約、クルー、モバイルアプリのためにField Serviceを使っています。
小売パートナー：取引先を発明しない
Section titled “小売パートナー：取引先を発明しない ”小売パートナーは、Steve Truckingが仕事を請け負っている会社です。Salesforceには会社のために設計されたオブジェクトがすでにあります。取引先です。きれいに合います。ですから、ビジネスが「パートナー」と言うからといってRetail_Partner__cは作りません。ほかの組織と区別するためのRetail Partnerレコードタイプを持つ取引先であり、それとともに契約、ケース、物流センターの責任者のための取引先責任者、そしてその取引先責任者のためのポータルアクセスがついてきます。簡単な判断です。すべてがそうではありません。
パートナーの注文番号は私たちの識別ではない
Section titled “パートナーの注文番号は私たちの識別ではない ”小売パートナーはそれぞれ独自の参照番号を送ってきます。あるパートナーの注文は8843119のような形、別のパートナーのはA-984732のような形です。その番号は重要ですが、誰のものでしょう？ パートナーのものです。Salesforceには独自のレコードIDがあり、パートナーには私たちとやりとりするときに使う参照番号があります。両方が存在できます。第2章の「一つのもの、複数の識別子」です。
ですからパートナーの参照番号は、連携が更新を照合するために使う外部IDになります。そして2つのパートナーが同じ番号を使う可能性があるので、識別は参照番号だけではなくパートナーと参照番号の組み合わせです。最初に届いたからといってパートナーの番号を配送の普遍的な識別にしないでください。そして連携がレコードを見つける必要があるたびに、テキスト項目を検索させないでください。
配送：母船を見よ
Section titled “配送：母船を見よ ”ここでDelivery__cを作りたくなります。ビジネスが「配送」と言ったので、配送オブジェクトが必要だ、と。それこそ、最初にしてほしくないことです。モジュール2でそうしたように、母船を見よ。ある場所で行われ、ライフサイクルがあり、品目があり、スケジュールがあり、現場にクルーがいる作業について、Salesforceにはすでに何があるでしょう？ Field Serviceの作業指示（Work Order）です。Salesforceはそれを、顧客のために行われるフィールドサービスの作業だと説明しています（WorkOrder (opens in a new tab)、英語）。予定された訪問とその時間帯はサービス予定（Service Appointment）で、それが配車でスケジュールされ、クルーのアプリに表示されるものです。
ですから配送 → 作業指示です。言葉が合っているからではありません。合っていません。振る舞いが、すでにお金を払っていて使うつもりのプラットフォームの機能と合っているからです。標準オブジェクトがビジネスの語彙を共有している必要はありません。概念を正しく表していればよいのです。
ステップ1／4：母船。各カードはビジネス概念で、その下にSalesforceのオブジェクトがあります。
ただし標準オブジェクトには荷物がついてくる
Section titled “ただし標準オブジェクトには荷物がついてくる ”もう半分の話です。作業指示は無料ではありません。Field Serviceのライセンス、独自のリレーション、セキュリティの振る舞い、必須項目、自動化、ライフサイクルを持ち込み、プラットフォームのほかの部分はそれが特定の振る舞いをすることを期待しています。私たちがそれを選ぶのは、きれいに合い、かつその周りに作られたものを使っているからです。Steve TruckingがField Serviceを何も使いたくなく、モデルがことあるごとにプロセスに逆らうなら、考え直します。アーキテクチャはラベルではなく、合っているかどうかです。
配送品目：モデルに従う
Section titled “配送品目：モデルに従う ”配送が作業指示になったら、何かを発明する前に、そのモデルの残りの部分を見ましょう。作業指示品目（Work Order Line Item）は作業指示のサブタスクです（WorkOrderLineItem (opens in a new tab)、英語）。冷蔵庫、設置、引き取り。ですから配送品目 → 作業指示品目です。最初の判断が2つ目を形づくったことに注目してください。エンティティごとにばらばらにオブジェクトを選んでいるのではありません。一つのモデルを採用し、その周りにカスタムの構造を作る前に、その残りの部分を理解するのです。
これはどんな種類の停車地か？
Section titled “これはどんな種類の停車地か？ ”Steve Truckingでは、停車地は配送のみ、設置付き配送、引き取り付き配送のいずれかで、種類ごとに所要時間、クルーのスキル、設置チェックリストがあります。第2章で、それはラベルではなくエンティティだと判断しました。Field Serviceにはすでにそれがあります。作業種別（Work Type）、作業指示や作業指示品目に適用できる作業の種類のテンプレートです（WorkType (opens in a new tab)、英語）。ですから停車地の種類 → 作業種別です。ここでも、作業種別という名前のものが存在するからではなく、概念と振る舞いが一致するからです。
ステップ2／4：モデルに従う。品目と作業種別は作業指示についてきます。
積荷目録：ここでカスタムオブジェクトがほしい
Section titled “積荷目録：ここでカスタムオブジェクトがほしい ”「フェニックス物流センターの火曜日分のパートナーのリスト」を表す標準オブジェクトはあるでしょうか？ 実質的にありません。標準にとどまったと言うためだけに、無関係なオブジェクトに押し込むことはしません。積荷目録 → Manifest__c。 それは受け取りの単位です。どこから来たか（ファイル、APIのバッチ）、いつか、ステータスと合計、そしてパートナーが当日に再送したときに何を比較するか。積荷目録の各行は、それにリンクした作業指示になります。
カスタムは失敗ではありません。 概念にきれいに合う標準の居場所がないときに、プラットフォームが与えてくれるものです。間違いはカスタムオブジェクトを作ることではなく、プラットフォームにすでにその概念があるかを確かめずに作ることです。
ステップ3／4：標準オブジェクトが合わないところに置く、唯一のカスタムオブジェクト。
写真：Salesforceに保存できるからといって、そうすべきとは限らない
Section titled “写真：Salesforceに保存できるからといって、そうすべきとは限らない ”「配送写真をSalesforceに入れる必要があります」。「Salesforceに」とはどういう意味でしょう？ ユーザーはSalesforceから写真を見る必要があります。それはそうです。では、画像ファイルがコアのストレージになければならないということでしょうか？ 必ずしもそうではありません。ゼロを数えましょう。配送1件につき約4枚、設置があればもっと多く、年100万件の配送で、年400万〜500万枚の写真です。しかも配送は年30%で成長しています。
ですから私の出発点は、ユーザーが写真にアクセスする必要があるからといって、コアの組織を巨大な写真の保管庫にしないことです。ファイルはそのボリュームのために作られたコアの外のストレージに置き、Salesforceにはそれを見つけて表示するのに必要なものだけを持たせます。参照、件数、あるいは写真ごとの小さなインデックスレコード、そして必須の設置写真がそろっていることを示すフラグです。データへのアクセスと、データが物理的にどこにあるかは別々の問いです。モジュール4が戻ってきました。
項目：意味を見えるようにする
Section titled “項目：意味を見えるようにする ”作業指示には項目が必要です。パートナーの参照番号、配送の時間帯、実際の配送時刻、ステータス、「門の暗証番号」や「庭に犬がいる」といったメモ。ここで項目のカタログを作ることはしません。それはモジュール6でやりました。それぞれに問いを当てはめましょう。何を意味するか、誰が所有するか、変わるか、識別子か、管理された語彙か、保存か導出か、機密か。パートナーの参照番号は外部IDなので、その一意性はただのチェックボックスではなく連携の契約の一部です。実際の配送時刻は瞬間なので日付/時間型。ステータスは振る舞いを動かすので、自由記述ではなく管理されたリスト。そして人の家についての配送メモは個人データなので、分類します。どの項目も意味までさかのぼれます。
リレーション：ただ箱をつなぐだけではない
Section titled “リレーション：ただ箱をつなぐだけではない ”取引先から作業指示へ、作業指示からその品目へ、積荷目録から作業指示へ、そして停車地を記述する作業種別。次に、それぞれの線にモジュール7の問いを当てはめます。子は単独で存在できるか、誰が所有するか、アクセスは引き継がれるか、移動できるか、削除されたら何が起きるか、子はいくつまで積み上がり得るか？ すべての作業指示がほんの数社の小売パートナーの取引先の下にあれば、親1つあたり何十万件もの子になります。第2部で答えるスキューの問いです。そして標準のField Serviceのリレーションについては、私たちが設計したであろうものと一致すると決めつけず、Salesforceがすでにどう作っているかを確認しましょう。標準のモデルを採用するとき、その中でSalesforceが下した判断も採用することになります。その上に作る前に、それを理解しましょう。
所有と受取人：デフォルトに決めさせない
Section titled “所有と受取人：デフォルトに決めさせない ”デフォルトが喜んで代わりに下してしまう判断が2つあります。
配送は誰が所有するのか？ これにはモジュール8で答えました。そしてその答えはそのまま作業指示に引き継がれます。ここでは所有は誰のアクセスも決めていないので、連携ユーザーが、自分が作る作業指示を所有します。 配車担当者は自分の物流センターのものを、クルーは自分のルートのものを、各小売パートナーはポータルを通じて自分のものを見ます。すべて所有ではなく共有を通じてです。連携ユーザーはロールを持たず、共有ルールが使う公開グループにも入りません。1日3,300件なら3日で1万件を超えるからです。そして、そのユーザーが置き換えられたら何が起きるかを書き留めておきます。
受取人とは何か？ 取引先責任者？ 個人取引先？ 配送の上にだけ保持する何か？ それは、Steve Truckingがそもそもこの人たちと関係を持っているのか（彼らは小売パートナーの顧客です）、あるパートナーが別のパートナーの受取人を見ることがあり得るのか、個人データをどれくらい保持してよいのか、そして規模、つまり年間約100万人の新しい受取人によって決まります。まだそのすべてはそろっていませんが、それでかまいません。正しい答えがまだ十分にわかっていないであることもあります。問いを書き留めて、情報を取りに行きましょう。不確かさをカスタムオブジェクトの中に埋めないでください。第4章から第6章で企業とマスターデータの全体像を得たあと、第1部のチェックポイントでこれに答えます。
一貫性：正しい層でモデルを守る
Section titled “一貫性：正しい層でモデルを守る ”モジュール9のはしごが当てはまります。パートナーの参照番号は一意の外部IDなので、再送された積荷目録は重複ではなくupsertになります。ステータスは制限付きのリスト。実際の配送時刻は、ステータスが配送済みになって初めて必須。設置の停車地は、チェックリストと写真なしには閉じられない。巨大なフロー一つではありません。それぞれのルールが自分の段にあります。
それぞれのデータはどこに住むか
Section titled “それぞれのデータはどこに住むか ”この一部分を、モジュール4の問いでもう一度見直しましょう。それぞれのデータはどこに住むのか？ 私のクラスの資料ではスライド1枚で、論理と物理を対比させます。第2章の論理エンティティと、それぞれが物理的にどこに着地するか。コア上ならsObject（カスタムなら__c）かBig Object（__b）、コアの外なら外部オブジェクト（__x）か、そもそもSalesforceに入ってこないデータです。
- コア上で、毎日の業務に使う： 取引先、作業指示とその品目、サービス予定、作業種別、
Manifest__c。 - コア上で、アーカイブ済み： 3年より古い配送は、Big Objectである配送履歴（Delivery History）に移ります。クレームのためにまだそこにあり、裏の物置に置かれています。
- 参照： 小売パートナー自身の注文の詳細は、パートナーのシステムに残ります。私たちはパートナーの参照番号を外部IDとして保持し、残りは誰かが必要としたときに、外部オブジェクトか連携を通じて取りに行きます。
- コアの外： 写真は、何百万枚もの画像のために作られたストレージに置き、作業指示からリンクします。
それが物理モデルです。どのオブジェクトかだけでなく、どの住まいかです。
一部分の全体を見る
Section titled “一部分の全体を見る ”- 小売パートナー → Retail Partnerレコードタイプの取引先。物流センターの責任者は取引先責任者。
- 配送 → Field Serviceの作業指示。サービス予定でスケジュールする。
- 配送品目 → 作業指示品目。
- 停車地の種類 → 作業種別。
- 積荷目録 → カスタムの
Manifest__c。 - パートナーの参照番号 → 作業指示の外部ID。パートナーごとに一意。
- 写真 → コアの外に保存。Salesforceは参照とそろっているかのフラグを持つ。
- 配送履歴 → 3年後にBig Objectへアーカイブ。
- 所有 → 連携ユーザー、アクセスは共有を通じて（モジュール8）。
- 受取人 → 第1部のチェックポイントのために未決。
ステップ4／4：一部分の全体。コア上、アーカイブ、コアの外。すべての線は参照関係です。SalesforceはField Serviceを参照関係の上に作っており、私たちはその判断も一緒に採用します。
図はアーキテクチャではない
Section titled “図はアーキテクチャではない ”その図をお渡しすることはできますが、それだけでは不十分です。アーキテクチャとは、その背後にある考えた筋道です。 なぜ取引先なのか？ きれいに合う会社だから。なぜDelivery__cではなく作業指示なのか？ 配送はフィールドワークのように振る舞い、Field Serviceはすでに導入されているから。なぜカスタムの積荷目録なのか？ きれいに合う標準の居場所がないから。なぜ写真はただのファイルではないのか？ ボリュームとストレージの経済性のため。なぜ外部IDなのか？ 別のシステムが境界をまたいで安定した識別を必要とするから。なぜ連携ユーザーが作業指示を所有するのか？ ここでは所有がアクセスを決めておらず、そうすれば監査証跡が正直に保たれるから。なぜ受取人はまだ未決なのか？ まだ十分な問いに答えていないから。線は出力であり、それを生んだのは判断です。
ですから、第3章を終えるときに身につけていてほしい習慣はこれです。物理モデルのどこでも指さして、**なぜ？**と問うこと。なぜこのオブジェクト、このデータ型、このリレーション、この所有者、この場所、このルールなのか？ その答えを、設定から物理モデルへ、論理モデルへ、ビジネス要件へとさかのぼれるべきです。できないなら、誰かが設定画面から設計したのです。
そして、まだ十分に計算していない数字があることに気づいたでしょう。パートナーごとの配送数、品目、写真、保持、アーカイブ。それでいいのです。設計を固める前に、ゼロの数を尋ねましょう。5万件のレコードで見事に動くモデルが、5億件ではまったく違う振る舞いをすることがあります。それが第2部です。
試験の先へ：AIが変えること。 AIにSteve Truckingの概要資料を渡せば、数秒でスキーマを作ってくれます。取引先、作業指示、カスタムオブジェクト、項目、デプロイ用のメタデータまで。すばらしい加速装置であり、そしてレビューではありません。アーキテクトの仕事は、対応づけとその結果を確認することへと移ります。合っているか、ライセンス、所有、ライフサイクル、規模、識別、セキュリティ、そして何をプラットフォームの外に置くか。AIはロケットブースターです。正しい方向を向いているかどうかは教えてくれません。
ここでアーキテクトが決めること
Section titled “ここでアーキテクトが決めること ”- それぞれのビジネス概念がSalesforceにどう対応するか：標準オブジェクト、カスタムオブジェクト、あるいはコアの外にある何か。
- どの識別子、項目、リレーションが、ビジネス上の意味を知らないうちに変えることなく実装するか。
- 採用する標準モデルに、どんなプラットフォームの振る舞いとライセンスがついてくるか。
- 設計が完成する前に、どの所有、ライフサイクル、一貫性、ストレージ、規模の判断を下さなければならないか。
- 恣意的な実装上の選択の陰に隠すのではなく、どの問いを明示的に未決のままにするか。
この章の始めに、モデルがSalesforceの上でどう存在すべきかを問いました。それがSalesforceのデータアーキテクチャです。オブジェクトを作ることでも、設定画面を暗記することでも、きれいな箱を描くことでもなく、ビジネスのモデルをプラットフォームの形に意図的に合わせることです。すべての構造は約束である。 説明できる約束をしましょう。
さらに学ぶ
Section titled “さらに学ぶ ”- Salesforce Developers、Object Reference：WorkOrder (opens in a new tab)、WorkOrderLineItem (opens in a new tab)、WorkType (opens in a new tab)（英語）、2026-10-02確認。
- Steve Truckingの概要資料（英語）。