組織より先に全体像を描く

🌐 ほかに 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で翻訳されています。コミュニティによるレビューはまだ行われていません。 英語で読む

Data Architectコース第4章、第1部：データアーキテクトになる。前へ：Salesforceのデータアーキテクチャ。

CTA（認定テクニカルアーキテクト）の候補者を教えるとき、初日の後の宿題はいつも同じです。シナリオを読む。真っ白なキャンバスからシステム全体像を描き始める。そして、そのあとで初めて、データモデルに挑戦する。

この順番に驚く人がいます。私たちはデータアーキテクトなのだから、データモデルから始めるべきでは？　私がそうしない理由はこうです。データモデルを先に描けば、何がSalesforceに属するかをもう決めてしまっています。全体像を先に描けば、その判断を形づくるべきものがすべて見えます。顧客と製品を所有するERP、5年分の問いに答えるウェアハウス、誰を入れるかを決めるIDプロバイダー、毎日午後にファイルを送ってくるパートナー、みんなが引退予定だと言っている従来システム。

第2章と第3章では組織を設計しました。モデルがどうあるべきか、そしてそれがSalesforceの上でどう存在するか。この章ではカメラを引いて、組織を設計する前に、組織を取り巻くものを描きます。Salesforceは多くのシステムの一つであり、データを所有しているのがSalesforceではないこともよくあります。

画像はAIで生成しました。

この章の考え方

• 全体像が先。 システムを見つけ、次にその間を動くデータを、次にそれぞれを誰が所有しているかを見つける。そのあとで初めて、Salesforceの役割を決める。
• 矢印はほかの矢印に依存する。 ERPへ出ていく注文には、先に顧客、製品、価格が入っている必要があります。一方向の流れしかない連携を見ると、私は心配になり始めます。
• データには種類があり、ワークロードがある。 マスター、参照、トランザクション、メタデータ、分析、非構造化データは、変わり方も、増え方も、使われ方も違います。そして業務（OLTP）、分析（OLAP）、ストリーミングのワークロードは、それぞれ違う置き場所を求めます。組織はビジネスを動かし、ウェアハウスやレイクはビジネスを分析します。
• システムにはロゴだけでなく役割がある。 記録、エンゲージメント、参照、インサイト。「Salesforceが私たちの記録システムです」。何についての？
• 分析の置き場所は、データの置き場所に従う。 すべてがコア上にあるなら標準のレポート。データがほかのストアにあるなら分析プラットフォーム。そしてSalesforceのデータをウェアハウスと統合するならウェアハウス。
• Data 360はニアコアである： コアで管理し、コアの外でホストする。ユーザーが接続することはないので、配管と一緒に置く。
• ERPが所有するデータは、手元で読み、管理のもとで書く。 erp_の接頭辞を付けて、どの項目を誰が所有しているかがスキーマでわかるようにする。
• 全体像では、矢印は接続を開くシステムから始まる。 そしてラベルが、何がどちら向きに動くかを示す。2つの流れは2本の矢印。両方向の矢印はコネクタにだけ使う。
• すべての矢印にはクライアントとサーバーがあり、 それぞれが自分の半分を所有する。全体像には何も描かないが、すべての矢印にそれがある。
• 矢印を描く前に数える。 ゼロの数は一覧表に書き、それが仕組みを選ぶ：バッチ、同期、あるいはイベント。
• 組織戦略は全体像の判断である。 最初の数分で決める：組織は一つか複数か、そしてどこで動かすか。
• 現状は何がまずいかを示す。 悪いプロセスは赤、手作業は破線、欠けているものは赤い点。

スティーブの全体像レイアウト

システム全体像の描き方はたくさんあります。これは私のやり方で、長年かけて磨いてきたもので、一つの文のように読めます。左の人々が中央のSalesforceにアクセスし、上のシステムを通じて信頼され、下のチャネルを通じてサービスを受け、右のバックオフィスとつながる。

位置	そこに置くもの
左	人々。上から順に：社内ユーザー、パートナー、顧客
中央	Salesforce。一つのシンプルな箱で、その下にコミュニティが接している
上	Salesforceの上にIDプロバイダー。AppExchangeは右に寄せる。公開Webサイトは左上
右	連携層、その先に社内システム：ERP、財務、ウェアハウス
連携層の下	Data 360。ニアコアで、配管と一緒に
下	顧客チャネル：メール、Webフォーム、電話、メッセージング
右下	データの出入り：アーカイブ、データロード、外部ソース、パートナー

システムは、ラベルの付いた薄いゾーンの中のカードで、それぞれにアイコンがあり、凡例がすべての意味を説明します。絵の背後には一覧表があります。データセットや流れごとに、所有者、ボリューム、仕組みとタイミング、認証、そしてコピーするか、参照するか、フェデレーションするか。

Click to enlarge

モジュール4の全体像と、その矢印。

この章の道筋

6つのモジュールがあり、それぞれ単独でも読めます。

1. Salesforceは多くのシステムの一つ。 箱より先に全体像が来る理由、何度も目にする連携とそれが依存する逆向きの流れ、波のようにやって来たデータ、そしてコア、ニアコア、Hyperforce。
2. 企業データの種類。 6つの種類。作成、編集、参照。OLTPとOLAP。リアルタイム、ニアリアルタイム、バッチ。そして分類の背後にある4つの問い。
3. Salesforceを取り巻くシステム。 システムの役割。ERP、ウェアハウス、レイクハウス。分析はデータに従う。MDM。連携とイベント。開発者が忘れがちなIDプロバイダー。そしてData 360の位置。
4. システム全体像を描く。 真っ白なキャンバスから組み立てる私のレイアウト。矢印より先にゼロの数。接続を始める側から始まる矢印。すべての矢印の背後にある、両方向のクライアントとサーバー。会話のためのスイムレーン。そして絵の背後にある一覧表。
5. 組織戦略は全体像の判断である。 まずは一つの組織から。もう一つを正当化するもの。プロバイダーではなくリージョン。GDPRを理由にしたAMERとEMEAへの分割。そして2つ目の組織が何を増やすのか。
6. Steve Truckingの全体像。 きちんとした導入の前の今日の姿に印を付けたもの：RouteDeskに届く積荷目録、手作業でSalesforceへ打ち直され、また戻されるルート、孤立したGPSデータ、財務を支えるスプレッドシート、そして年10万8,000件の「荷物はどこ？」の電話。

読み終えたら、章の学習ガイドで理解度を確認しましょう。試験のためのチェックリスト、試験の先にある習慣、覚えておきたい用語、そしていくつかの問いがあります。

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

• どのシステムがSalesforceを取り巻いているか。 そしてそれぞれがどんな役割を果たしているか。
• どのシステムが重要な種類のデータを所有しているか。 Salesforceがそのどれだけを持つかを決める前に。
• すべての接続がどう動くか： 何が、どの方向に、どう認証して、どれくらいの速さで動き、何が返ってくるか。
• 組織はいくつで、どこで動かすか。 最初に決める。全体像のほかのすべてがそれに依存するから。
• 現状が、目指す姿を設計できるほど十分に理解されているか。

試験の先へ： 全体像はエージェントの地図になりつつあります。エージェントが「荷物はどこ？」に答えられるようになる前に、誰かが、それぞれの事実についてどのシステムが権威を持ち、それがどれくらい新しく、エージェントがそこにどうアクセスしてよいかを知っていなければなりません。各モジュールの最後で、絵のその部分についてAIが何を変えるかを扱います。

さらに学ぶ

• Salesforce Architects、The Salesforce Platform: Transformed for Tomorrow (opens in a new tab)（英語）、2026-10-14確認。
• CTA候補者のためのさらなる読み物：Salesforce Architectsは独自の図の描き方のガイダンス、How to Build Salesforce Diagrams (opens in a new tab)（英語）を公開しています。

次へ： データの品質とガバナンス