Steve Trucking、私ならこう設計する
ほかに 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)
モジュール6／6：Data Architectコース第6章「マスターデータとID」、そして第1部の締めくくり。 前へ：権威が共有されるとき · 次へ：第2部は大規模に向けた設計 *(coming soon)*から始まります
このチェックポイントが答える問い： 現実のシナリオで、第1部を一つにまとめられるか？
まず課題に取り組んでください。 これはチェックポイント1の課題についての私の解説です。まだ自分の設計を描いていないなら、読み進める前に描きましょう。価値は答えを読むことではなく、自分の考えた筋道を私のものと比べることにあります。
これは「私ならこう設計する」です。唯一の答えではなく実現可能な解決策の一例であり、トレードオフを名指しし、私の立場をはっきりさせています。大規模データボリューム、クエリの設計、連携のパターン、移行、トランザクションはまだ扱っていません。それは意図的です。アーキテクチャは、学ぶほどに育っていくものです。しかし第1部で、骨格を据えるには十分なものがそろっています。
数字から始める
Section titled “数字から始める ”概要資料から：営業日1日あたり約3,300件、年100万件の配送で、年30%の成長。配送1件あたり約1.6品目（年160万件）。配送1件あたり約8回のステータス変更（年800万件）。年400万〜500万枚の写真。1日約20万件のGPSの読み取り値。年約18万件のケース。3つの違う方法で積荷目録を送ってくる3社の小売パートナー。9つの物流センター。2人1組のクルーが乗る330台のトラック。そしてSteve Truckingはすでに、Service Cloud、Field Service、パートナーポータルを持つSalesforce組織を一つ使っています。箱を一つ描く前にゼロを数えましょう。それが以下のいくつかのことを決めます。
配送の中核：母船を見よ
Section titled “配送の中核：母船を見よ ”配送がその中心であり、Field Serviceはすでに配車をしています。ですから第3章の一部分と同じように、Field Serviceの標準モデルから始めます。
| ビジネス概念 | Salesforceオブジェクト | 理由 |
|---|---|---|
| 小売パートナー | Account（Retail Partnerレコードタイプ） | Steve Truckingが契約している事業者。契約、ケース、ポータルアクセスを持つ |
| パートナーのスタッフ（物流センターの責任者、店舗のスタッフ） | Contact | ポータルのユーザーは取引先責任者でなければならない |
| 一つの配送：一人の受取人、一つの住所、一つのパートナーの注文、一日 | Work Order | Field Serviceの作業の単位。スケジュール、モバイルアプリ、サービスレポートがここにぶら下がる |
| それぞれの品目やサービス：冷蔵庫、設置、引き取り | Work Order Line Item | 作業を分け、チェックリストと請求を動かす |
| 停車地の種類：配送のみ、設置付き、引き取り付き | Work Type | 所要時間、スキル、設置チェックリストを決める |
| 予定された訪問とその時間帯 | Service Appointment | Field Serviceがスケジュールし、クルーのアプリに表示されるもの |
| クルーとトラック、物流センターの配車エリア | Service Resource、Service Crew、Service Territory | Field Serviceはクルーを一つのリソースとしてスケジュールする |
| 受取人の問い合わせ、パートナーのクレーム | Case | サービスコンソール、エンタイトルメント、メールtoケース |
| フェニックス物流センターの火曜日分のパートナーのリスト | Manifest__c（カスタム） | 受け取り、照合、再処理の単位を表す標準のものがない |
それ以外はすべて標準のままです。カスタムオブジェクトを増やすのに抵抗するのは意図的です。第1章の問いは、アーキテクトがいつもう一つのオブジェクトに抵抗すべきかでしたが、ここでの答えは「ほとんどいつも」です。たとえばパートナーの注文明細は新しいオブジェクトではありません。パートナーの参照番号で識別される作業指示です。
第3章の締めくくり（Salesforceの物理モデルを設計する）から育ったものです。同じオブジェクトが同じ場所にあり、クルー、配車エリア、ケース、そしてチェックポイント1がコアの外に置くものが加わっています。
パートナーの注文を配送に照合するキー
Section titled “パートナーの注文を配送に照合するキー ”積荷目録の各行は、その積荷目録にリンクした一つの作業指示（Work Order）になります。キーは私が最も答えてほしい問いです。パートナーからのこの行がその配送だと、どうやってわかるのか？ 私の答えはこうです。小売パートナーと、パートナー自身の注文・配送の参照番号から作る、作業指示の外部ID（たとえばKEYSTONE-PHX-8843119-1のようなもの）で、一意に設定します。ソースごとに一つの項目、1対1。それは私たちのではなくパートナーの識別子です。第2章の「一つのものに複数の識別子」であり、モジュール1の「パートナーは自分の注文番号を所有している」です。
なぜ重要か：積荷目録は1、2日前に届き、当日に修正されます。そのキーがあれば、再送されたり修正されたりした積荷目録は、重複を作る代わりにupsertされます。修正は作業指示を更新し、項目がそれを記録し、すでにルートが組まれた配送への変更はコーディネーターに知らせます。パートナーの変更は適用されますが、配車が確認するまではフラグが付いたままです。これは第4章の絵から変わるところでもあります。今日はすべての積荷目録がRouteDeskに届き、コーディネーターがルートをSalesforceに打ち直し、完了した停車地をRouteDeskに打ち戻しています。この設計では、積荷目録はパートナーのキーでupsertされて直接Salesforceに入ります。RouteDeskは引退し、打ち直しはなくなります。3つの受信の形式は連携の章で設計します。データの判断はキーです。
受取人：個人取引先か、取引先責任者か、どちらでもないか？
Section titled “受取人：個人取引先か、取引先責任者か、どちらでもないか？ ”これは第1部で最も興味深いデータの判断なので、選択肢を並べてから私の選択を示します。
選択肢A：個人取引先。 受取人一人ひとりが個人取引先になり、すべての配送にリンクされます。賛成： 標準であり、Service Cloud、メッセージング、コンソールと自然に動き、繰り返し受け取る人を認識できる。反対： 年に約100万人の新しい受取人がいて、それぞれが法人取引先の約2倍のストレージを使う個人取引先になり（Estimated Record Size by Object Type (opens in a new tab)、英語）、2年もすれば組織で最大級のオブジェクトの一つになる。そして受取人はSteve Truckingの顧客ではありません。それぞれの小売パートナーの顧客であり、Steve Truckingはあるパートナーの顧客を別のパートナーの顧客と決して混ぜ合わせてはなりません（S2）。
選択肢B：小売パートナーの取引先の下の取引先責任者。 反対： 3つか4つの取引先の下に100万人の取引先責任者を置くのは、巨大な規模の親子データスキューであり、親1つあたり約1万件の子というSalesforceのガイダンスをはるかに超えています（Considerations for Object Relationships (opens in a new tab)、Parent-Child Data Skew (opens in a new tab)、英語）。これは示した上で、却下する選択肢です。
選択肢C：受取人は配送の上にいる。 受取人の名前、電話番号、メールアドレス、住所、配送メモは、積荷目録から取り込む作業指示の項目です（住所の項目はそこにすでに標準であります）。賛成： 新しい大きなオブジェクトがない。データは配送が必要とする間だけ存在する。削除は配送ごとに、パートナーのスケジュールで行われる。そしてそれぞれの配送が一つのパートナーに属するので、パートナーの分離がただで手に入る。反対： 繰り返し受け取る人が、同じ人として認識されない。
それが取るべきバランスです。いくつもの配送を、同じ場所の同じ人として認識する必要が今後あるでしょうか？ その人にログインを与える必要は？ それが、自分のレコードを必要とする受取人と、単に配送についてのデータである受取人の詳細との境目です。そして中間の道があります。小売パートナー自身の顧客IDを、配送の項目、小売パートナー顧客ID（Retail Partner Customer ID）として持つのです。受取人のレコードは作りませんが、パートナーが同じ顧客のために送る配送を結びつけます。それはより統合された顧客体験への第一歩であり、その顧客が本当にいる小売パートナーのシステムへと真っすぐさかのぼれます。パートナーの識別子なので、パートナーと組み合わせて初めて意味を持ちます。あるパートナーの顧客4417は、別のパートナーの顧客とは何の関係もありません。
私の専門家としての意見では、 選択肢Cが正しい選択です。認識されない点は許容できますし、むしろ望ましいことです。Steve Truckingはこの人たちと、配送以上の関係を持っていません。またモジュール1です。受取人はパートナーの顧客であり、その人が誰かについての権威はパートナーにあります。そして第5章です。一か所に着地し、一つの配送に結びついた個人データは、守るのも、保持するのも、削除するのもはるかに簡単です。そして第2章の正規形にも耐えます。受取人の詳細は配送と1対1なので、配送に属します。受取人の子オブジェクトを別に作れば、繰り返される値をいくつか節約できますが、その代わりにオブジェクトがもう一つ、リレーションがもう一つ増え、その負担もかかります。それ以上を節約できる唯一の方法は、小売パートナーをまたいで同じ人を一人として扱うことですが、私たちはそれをしません。ですから配送が受取人を持ち、小売パートナー顧客IDがパートナー自身のシステムへさかのぼる道になります。
パートナーをまたいで受取人を統合するか？
Section titled “パートナーをまたいで受取人を統合するか？ ”John Smith、123 Main StreetがRedrockの積荷目録にもBrightwaveの積荷目録にも現れます。おそらく同じ人です。Steve Truckingはその人を統合すべきでしょうか？ いいえ、意図的にしません。 小売パートナーをまたいで受取人を統合すればS2に違反します。あるパートナーが別のパートナーの受取人を見ることは決してあってはならず、統合されたIDはまさに漏れが通る橋になるからです。この章の立場を当てはめたものです。混ぜ合わせると高くつくところでは照合を控えめにする。 そしてここでは、混ぜ合わせることはとても高くつきます。
後になってある小売パートナーが、自分の配送の中で繰り返し受け取る人を認識したいと言うなら、それはそのパートナーに限定した、Data 360のようなID解決のツールの仕事です。個人取引先ではなくレジストリ型の地図であり、決してパートナーをまたぎません。誰が誰かの地図は所有を与えませんし、アクセスも与えません。
組織に残すもの、残さないもの
Section titled “組織に残すもの、残さないもの ”第3章で、データをどこに置くべきかを問いました。ここではゼロがそれに答えます。
- 現在のステータスはサービス予定と作業指示にあります。年に約800万件で増え続けるステータス変更の履歴は、コアの組織にある必要はありません。それぞれの変更はイベントとして発行され、ウェアハウスであるSnowflakeに保持されます。組織は現在の状態を保ち、履歴はサービス、オペレーション、分析のためにやはり利用でき、ただ業務データベースにはないだけです。
- 写真（年400万〜500万枚で、人や家の中が写っているものもある）は、そのボリュームのために作られたストレージに、コアの外に置き、クルーのアプリから直接アップロードします。組織は必要なものだけを持ちます。写真ごとの小さなインデックスレコード、あるいは件数と「必須の設置写真がそろっている」フラグだけ。私の好みはより軽い選択肢です。組織を身軽に保ち、写真のストアにそのインデックスと保持を所有させます。
- GPSの読み取り値（1日20万件）はFleetLinkにとどまり、Snowflakeに行きます。組織に必要なのは、追跡ページと配車担当者の地図のための最新の位置だけです。
- RouteDeskの8年分の履歴（約500万件の配送）はウェアハウスかアーカイブに行き、クレームのためにアクセスできるようにします。何かを組織に取り込むとしたら何かは、第2部での移行の判断です。
チェックポイント1：私ならこう設計する。第4章の全体像（Steve Truckingの全体像）と同じ配置で、打ち直しとスプレッドシートがなくなっています。
誰が何を見て、誰にライセンスが必要か
Section titled “誰が何を見て、誰にライセンスが必要か ”- 小売パートナーは自分の配送だけを見る（S2）。すべての作業指示は自分の小売パートナーを持ち、ポータルのユーザーは自分のパートナーの配送を、物流センターの責任者は自分の物流センターの配送だけを見ます。
- パートナーのユーザーには、共有ルールとロールに対応するポータルのライセンスが必要です。 Customer Community PlusかPartner Communityです。第3章のスタジアムの座席です。最も安い席では、この設計が必要とする共有が手に入りません。どちらのライセンスでも外部ユーザーにロールが必要で、Salesforceはロールが増えると組織が遅くなると警告しています（Experience Cloud User Licenses (opens in a new tab)、英語）。パートナーごと、物流センターごとのロールなら問題ありません。店舗ごとのロールはだめです。
試験に出やすい知識。 どの外部ライセンスが標準の共有を持つかを知っておきましょう。Customer Community PlusとPartner Community（外部ユーザーのロールを伴う）であり、共有セットを使うCustomer Communityではありません。
- 受取人にはライセンスは要りません。 追跡ページは、ログインではなく、期限切れになるトークン付きのリンク（S3）を通じて一つの配送を表示します。
- スキューに注意する。 年に何十万件もの作業指示が3つか4つのパートナーの取引先を指すのは、取引先のデータスキューです。一つの選択肢は、それぞれのパートナーの下に物流センターごとの子取引先を置くことで、子を9つ以上に分散させます。クレームの期間が過ぎた完了済みの配送をアーカイブすれば、親あたりの有効な子の数を低く保てます。第2部でそれを扱います。
私がしないこと
Section titled “私がしないこと ”受取人が個人だからといって、受取人ごとに個人取引先を作ることはしません。3つの取引先に100万人の取引先責任者をぶら下げることはしません。Field Serviceの作業指示の横に、カスタムの配送オブジェクトを作ることはしません。パートナーをまたいで受取人を統合することはしません。何百万枚もの写真やGPSの読み取り値を、コアのストレージに置くことはしません。そして、実際にマスター管理の判断を下していない限り、統合された受取人をゴールデンレコードと呼ぶことはしません。
まだ開いていること
Section titled “まだ開いていること ”第1部で骨格を据え、第2部でそれを試します。3年目のLDVの物差し（作業指示、サービス予定、品目はすべて2、3年で大規模ボリュームの領域に入る）、パートナーに限定したリストビューのためのクエリの設計、3つの受信の連携と3つのステータスのフィード、RouteDeskの移行、当日のトランザクション、そしてポータルの背後にあるセキュリティの設計。Steve Truckingも変わっていきます。この設計を手元に置いておきましょう。また戻ってくることになります。
ここでアーキテクトが決めること
Section titled “ここでアーキテクトが決めること ”- どの標準オブジェクトが中核を担い（ここではField Serviceのもの）、どのカスタムオブジェクトが本当に正当化されるか（ここでは一つ）。
- それぞれのパートナーの注文明細を配送に照合するキーと、それがなぜパートナーに属するのか。
- Steve Truckingが受取人と実際に持っている関係に基づいて、受取人とは何か。
- IDを統合するかどうか、そして混ぜ合わせるのが高くつきすぎてリスクを取れないのはどこか。
- 何を組織に残し、何をコアの外に置き、設計がどのライセンスに依存するか。
さらに学ぶ
Section titled “さらに学ぶ ”- Steve Truckingの概要資料と課題（D1、D3、DC1、英語）。
- Salesforceヘルプ、Salesforce Data Storage: Estimated Record Size by Object Type (opens in a new tab)、Considerations for Object Relationships (opens in a new tab)とExperience Cloud User Licenses (opens in a new tab)（英語）、2026-10-14確認。
- Salesforce Developers、Parent-Child Data Skew (opens in a new tab)（英語）、第3章で引用したもの。