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)
モジュール1／6：Data Architectコース第4章「企業のデータを理解する」。各モジュールは単独でも読めます。 次へ：企業データの種類
このモジュールが答える問い： データアーキテクトはなぜ、組織を設計する前に、組織を取り巻くものを描くのか？
CTAの候補者を教えるとき、初日の後の宿題はいつも同じです。シナリオを読む。真っ白なキャンバスからシステム全体像を描き始める。そのあとで初めて、データモデルに挑戦する。オブジェクトでも、連携の詳細でもなく、全体像です。何がSalesforceの中に属するかを決める前に、何がSalesforceを取り巻いているかを見たいのです。
多くのSalesforceの専門家にとって、これは視点の転換です。管理者や開発者としてキャリアを積んできたなら、Salesforceは自然とあなたの世界の中心です。設定画面を開き、オブジェクトを作り、フローを作り、Apexを書き、ほかのシステムをSalesforceに連携させます。すべてが組織から始まるように見えます。アーキテクトはカメラを引かなければなりません。企業の中ではSalesforceは多くのシステムの一つであり、データを所有しているのがSalesforceではないこともよくあるからです。
まず全体像を描く
Section titled “まず全体像を描く ”第2章で論理モデルを作り、第3章でそれがSalesforceの上でどう存在するかを問いました。ここで問題を大きくします。Salesforceが何を所有すべきかを決める前に、それを取り巻く企業を理解したいのです。どんなシステムがすでにあるか？ 顧客はどこで作られ、製品はどこで定義され、注文はどこで始まり、請求書はどこで生成されるか？ IDはどこにあるか？ 分析はどこで行われ、文書はどこに保管され、履歴はどこにあるか？ どのシステムがSalesforceのデータを必要とし、Salesforceはどのシステムに依存しているか？
これらの問いがアーキテクチャを変えます。だから私は真っ白なキャンバスから始め、Salesforceを中央に置き、その周りのすべてを描きます。具体的にどうレイアウトするかはモジュール4で示します。今の教訓はシンプルです。組織が生きていかなければならない世界を理解する前に、組織を設計しない。
Salesforceが記録システムでないことは多い
Section titled “Salesforceが記録システムでないことは多い ”ごく一般的な企業を考えてみましょう。Salesforceに加えて、財務、製品、在庫、購買、出荷を動かすERP（統合基幹業務システム、SAPやOracleなど）があります。そこでシンプルな問いを立てます。顧客はどこにいるのか？
Salesforceかもしれないし、ERPかもしれないし、両方かもしれません。そこから面白くなります。営業担当者はSalesforceで見込み客を取引先として扱い、有料顧客になった時点でERPが正式な顧客番号を発行するかもしれません。製品と価格は？ おそらくERP。在庫は？ Salesforceであることはまずありません。注文はSalesforceで受けてERPで出荷するかもしれず、請求書はERPから出て、サービスはSalesforceにあり、分析はSalesforceのレポートとウェアハウスに分かれています。突然、私たちのすてきなSalesforceのデータモデルは、企業のデータモデルではなくなります。その一部なのです。
何度も目にする連携
Section titled “何度も目にする連携 ”私が最もよく目にする連携はこうです。顧客、製品、価格がERPからSalesforceに流れ込み、注文が流れ出る。 SAPでもOracleでも、ほかのどのERPに置き換えても、形は同じです。ERPが顧客と製品のゴールデンレコードを所有しているので、それらの流れは右側からSalesforceに入ってきます。営業はSalesforceで商談を成立させるので、注文はそこで始まり、出荷し、請求し、会計処理するためにERPへ戻っていきます。
これらの流れは単なる連携ではありません。企業が真実はどこにあると考えているかを教えてくれるのです。
一方向の矢印は私を不安にさせる
Section titled “一方向の矢印は私を不安にさせる ”一方向の流れしかない連携を見ると、私は心配になり始めます。大まかなレベルでは、誰かが1本の矢印を描きます。SalesforceからERPへの注文。いいでしょう。では、もっと深く見てみましょう。ERPの顧客、製品、価格を知らずに、どうやってERPに注文を送れるでしょうか？ 注文はERPがすでに持っている顧客にひも付いていなければならず、すべての明細はERPがすでに販売しているSKUでなければなりません。向こう側に存在しない製品の明細を送ることはできないのです。ですから、その注文の矢印が機能する前に、逆向きに流れる戻りの流れが存在していなければなりません。
それが、私がすべての矢印に投げかける問いです。この流れは何に依存しているのか？ 目に見えている大まかな矢印は、たいてい、まだ描いていない戻りの流れを必要としています。
さらに深く見ると、帰り道が見つかります。SalesforceがERPに注文を送ります。それから？ 受け付けられたのか、拒否されたのか？ 出荷されたのか、一部だけ出荷されたのか、キャンセルされたのか？ 請求されたのか？ Salesforceの誰かがそれを知る必要があるのか？ 必要ないのかもしれません。でも、誰かが問うべきでした。何も返ってこないなら、それでかまいません。理由を教えてください。
企業は一度にできあがったわけではない
Section titled “企業は一度にできあがったわけではない ”全体像が複雑になる理由の一つは、誰もそれを一度に作ったわけではないことです。データは波のようにやって来ました。最初はファイル。固定長のレコード、次にCSVのような区切り文字のファイル。次に業務データのためのリレーショナルデータベース。次に、それを分析のためにまとめるデータウェアハウス。次に、表にきれいに収まらないドキュメント、キーと値のペア、グラフのためのNoSQLデータベース。次に、大量の生データや半構造化データのためのデータレイク、そしてその二つを組み合わせたレイクハウス。KafkaやSalesforceのイベントバスのようなイベントストリームは、夜間のバッチではなく、起きたその時にデータを動かします。そして今はフェデレーション、つまり別のプラットフォームが使う前にデータを一か所にコピーする必要がない仕組みです。
まだテクノロジーは本題ではありません。本題はこれです。新しい波が古い波を消し去ることはめったにない。 大企業に入れば、それらすべてが同時に見つかります。リレーショナルデータベース、ERP、Salesforce、ウェアハウス、レイク、SFTPでのファイル受け渡し、API、イベントストリーム、誰かが今も毎週金曜日にメールで送っているスプレッドシート、そして作った人が6年前に退職したので誰も触れたがらないシステム。あなたが設計しているのはその企業であって、製品パンフレットの中の企業ではありません。
システムはそれぞれ違う理由で存在する
Section titled “システムはそれぞれ違う理由で存在する ”だから私は、「どうやってすべてのデータをSalesforceに入れるか？」から始めることは決してありません。なぜそこにすべてを置きたいのでしょう？ Salesforceは、営業やサービスの人たちが顧客と仕事をするのに最適な場所かもしれません。だからといって、財務システムでも、企業のウェアハウスでも、テレメトリのストアでも、文書のアーカイブでも、会社がこれまでに生み出したすべてのクリック、GPSの読み取り値、過去のトランザクションの置き場所でもありません。
第3章では、一つの組織について**このデータはどこに置くべきか？**を問いました。企業レベルでは、同じ問いが大きくなります。Salesforceがデータを所有することもあれば、コピーを持つこともあれば、参照だけを持つこともあれば、そもそも持つべきでないこともあります。
コア、コアの外、そしてHyperforce
Section titled “コア、コアの外、そしてHyperforce ”理解しておくべき境界がもう一つあります。「Salesforce」でさえ、一つのランタイムと一つのデータベースではありません。第3章では、コア上とはデータが置かれている場所、つまりあなたの机の上、組織自身のオブジェクトの中を意味していました。ここでは同じ言葉が、製品がどこで動くかを表します。アーキテクトはどちらの意味でも使うのを耳にするでしょう。
歴史的には、Coreランタイムがプラットフォームの大半を動かしてきました。今日Salesforceは、プラットフォームを何百もの独立したメタデータ駆動のサービスからなるものと説明しており、Coreはアプリケーションのメタデータについての唯一の記録システムであり続けています（The Salesforce Platform: Transformed for Tomorrow (opens in a new tab)、英語）。だから、アーキテクトがある機能をコアで動く、あるいはコアの外で動くと言うのを耳にするのです。
これは、プラットフォームがサービスに分かれるずっと前から重要でした。クラスで、なぜSalesforceは見積のためにApttusではなくSteelBrickを買ったのかと聞くとき、私が求めている答えはシンプルです。SteelBrickは100%コアの上に作られていたからです。フローとトリガーはコアにあるので、そこで作られた製品はプラットフォームのメタデータ、カスタマイズ、自動化をそのまま手に入れます。その見積製品はその後Revenue Cloudに道を譲りましたが、教訓は変わっていません。そしてニアコアがあります。私が例に使うのはData 360です。Data 360はコアではありません。そのテナントはコアの外にあります。データとそれを処理する仕組みは独自のレイクハウスで動き、組織のリレーショナルデータベースの中ではなく、その隣にあります（The Salesforce Platform: Transformed for Tomorrow (opens in a new tab)、英語）。しかし、それを設定し制御するための画面は、コアの上、組織の中に表示されます。ですから私が言える最も正確な言い方はこうです。コアで管理し、コアの外でホストする。 データも処理も、実際にはCoreでは動いていません。Core上のUIが、コアの外のテナントを制御しているのです。そしてもちろん、そもそもSalesforceではないために、コアの外にあるすべてのものがあります。
今年どの製品がどこで動くかを暗記することは、変わってしまうのであまり気にしていません。大切なのは習慣です。境界は、データの移動、遅延、ID、連携、データの所在地に影響し得ます。ですから、ある製品にSalesforceと書いてあるからといって、そのデータがあなたの取引先レコードのすぐ隣にあると決めつけないでください。実際のアーキテクチャを見ましょう。
そしてHyperforceがあります。従来の自社データセンターではなく、パブリッククラウドのために作られ、コードとして定義されたSalesforceのインフラであり、データをどこに置くかについて顧客により多くの選択肢を与えます（Salesforce Hyperforce: General Information and FAQ (opens in a new tab)、英語）。それは重要で、モジュール5で改めて取り上げます。しかしインフラのアーキテクチャは、企業のデータアーキテクチャではありません。組織をパブリッククラウドに移しても、誰が顧客を所有しているか、在庫がどこにあるか、分析がどこで動くか、どのデータが国境を越えてよいかはわかりません。Hyperforceはそうした判断の一部、特にデータの所在地を形づくることがあります。全体像を知ることの代わりにはなりません。
箱より先に全体像
Section titled “箱より先に全体像 ”ですから習慣はこうです。誰かがシナリオを渡してきます。Salesforceのソリューションを作り始めないでください。まずシステムを見つけます。ERP、IDプロバイダー、ウェアハウス、連携プラットフォーム、パートナーのシステム、顧客チャネル、文書ストア。次に、その間を動くデータを見つけます。顧客、製品、注文、請求書、文書、イベント、ID。次に、それぞれを誰が所有しているかを問います。そのあとで初めて、何がSalesforceに属するかを決めます。そうでなければ、何につながるのかも知らずに箱を設計していることになります。
ステップ1／3：私たちが設計する組織、それだけ。ここから見ると、それが世界のすべてのように見えます。
ステップ2／3：引いて見ます。Salesforceは多くのシステムの一つです（このレイアウトはモジュール4で学びます）。
ステップ3／3：最初の矢印。顧客、製品、価格はERPから入り、注文は出ていく。これらの矢印は、真実がどこにあると企業が考えているかを示します。
全体像がデータモデルを変える
Section titled “全体像がデータモデルを変える ”これがデータアーキテクトにとって重要な理由です。第2章は、顧客が重要なエンティティだと言います。結構です。次に全体像が、ERPが顧客について権威を持っていると言います。それが物理モデルを変えます。人々が毎日使うので、Salesforceは手元に取引先を持ち続けるかもしれませんが、今度はERPの識別子を外部IDとして持つ必要があります。Salesforceがどの項目を変えてよいのか（モジュール3で見るように、私はERPの項目にerp_の接頭辞を付けます）、ERPの変更がどれくらいの速さで届くのか、ERPが知る前にSalesforceが顧客を作れるのか、二つが食い違ったら何が起きるのかを知る必要があります。これらは後回しにする連携の問いではありません。データアーキテクチャの問いであり、全体像がそれをあらわにしたのです。
そのうちの一つがどう効いてくるかを見てみましょう。営業担当者が大手飲料メーカーのリードを変換して取引先を作り、商談を成立させ、その顧客がERPに渡ります。しかし会社はその飲料メーカーと何年も取引しており、ERPにはすでにその顧客がいます。これで2件になりました。そもそも営業担当者がその取引先を作れるべきだったのでしょうか？ 第5章と第6章でこの問題に戻ってきます。それが来るのが見えるのは、全体像の上なのです。
ここでアーキテクトが決めること
Section titled “ここでアーキテクトが決めること ”- どのシステムがSalesforceを取り巻いているか、そしてそれぞれがどんな役割を果たしているか。
- どのシステムが重要な種類のデータを所有しているか。Salesforceがそのどれだけを持つかを決める前に。
- 何がSalesforceに流れ込み、何が流れ出て、何が返ってくるか。
- Salesforceがどのデータを所有し、コピーし、参照し、フェデレーションし、アーカイブし、あるいはそのままにしておくべきか。
- Salesforceという名前の付いたものはすべて一か所にあると決めつけるのではなく、どのプラットフォームとインフラの境界が重要か。
開発者からアーキテクトへの転換は、多くの場合、機能をもう一つ覚えることではありません。いつSalesforceを見るのをやめるべきかを学ぶことです。カメラを引き、データを追い、誰が真実を所有しているかを見つけ、それから戻ってきてSalesforceの役割が何であるべきかを決めるのです。
さらに学ぶ
Section titled “さらに学ぶ ”- Salesforce Architects、The Salesforce Platform: Transformed for Tomorrow (opens in a new tab)（英語）、2026-10-14確認。
- Salesforceヘルプ、Salesforce Hyperforce: General Information, FAQ, Migration Guide, and Security Overview (opens in a new tab)（英語）、2026-10-14確認。