コンテンツにスキップ
SteveTechArcSteveTechArc Courses

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)

An empty concert stage before rehearsal, each chair with its instrument in its section, the conductor's podium and stand empty.
AI で生成した画像

モジュール3／6：Data Architectコース第4章「企業のデータを理解する」。各モジュールは単独でも読めます。 前へ：企業データの種類 · 次へ：システム全体像を描く

このモジュールが答える問い： 何がSalesforceを取り巻いていて、それぞれのシステムはどんな役割を果たしているのか？

前のモジュールでデータを分類しました。今度はそれをどこかに置きたいのですが、ここでSalesforceのアーキテクトは困ったことになります。私たちはSalesforceを知っているので、顧客データなら取引先、注文データなら注文、文書ならファイル、分析ならレポートとなります。しかし企業は、持っているほかのすべてを置き換えるためにSalesforceを買ったのではありません。財務と出荷を動かすERP、何年分もの履歴を持つウェアハウス、連携プラットフォーム、IDプロバイダー、パートナーのシステム、イベントプラットフォーム、MDMプラットフォーム、そしてそのいくつかをつなぐData 360があるかもしれません。仕事はテクノロジーを暗記することではありません。それぞれのシステムがどんな仕事を担っているかを理解することです。

製品名から始めない

Section titled “製品名から始めない ”

「SAPがあります」では十分な情報になりません。Snowflake、MuleSoft、Tableau、Data 360も同じです。知りたいのは、そのシステムがこのアーキテクチャの中で何をしているかです。どんなデータを所有し、何を読み、何を変え、誰が使い、何がそれに依存し、それが止まったら何が起きるか。まったく同じ製品を持つ2つの会社が、まったく違うアーキテクチャを持っていることもあります。

ですから私は、システムに役割のラベルを付けます。ほとんどは4つの役割でカバーできます。

  • 記録システム（system of record）： 何かの権威あるバージョンが維持されている場所。
  • エンゲージメントシステム（system of engagement）： 人が仕事をする場所。
  • 参照システム（system of reference）： あるシステムが、必要だが所有していない情報を取りに行く場所。
  • インサイトシステム（system of insight）： データが集まり、測定、分析、予測が行われる場所。

一つのプラットフォームが複数の役割を果たすことがあり、役割はデータによって違います。Salesforceは、ケースについては記録システム、サービスエージェントにとってはエンゲージメントシステム、そしてERPが所有する製品データの利用者かもしれません。ですから誰かが「Salesforceが私たちの記録システムです」と言ったら、その文を完成させましょう。何についての記録システムなのか？

ERP：バックオフィスには重力がある

Section titled “ERP：バックオフィスには重力がある ”

ERPは、Salesforceの隣で最もよく見かけるシステムです。財務、在庫、購買、出荷、請求を動かしています。モジュール1のパターン（顧客と製品が入り、注文が出ていく）では、ERPが製品を所有していますが、営業担当者はそれでもSalesforceで製品を必要とします。結構です。取り込みましょう。しかしデータをコピーしても、所有は移りません。コピーは権威ではありません。

私の立場は、ERPが所有するデータは、手元で読み、管理のもとで書くことです。Salesforceのユーザーは仕事をする場所でデータを手にしますが、ERPが所有するものをSalesforceが変えることはできません。そして私はそれをスキーマで見えるようにします。ERPの項目にはerp_Product_Number__cのようにerp_の接頭辞を付けるので、オブジェクトを読む人は誰でも、どの項目を誰が所有していて、変えるときには注意が必要だとわかります。接頭辞は何も強制しません。強制するのは権限、入力規則、連携のパターンです。接頭辞が伝えるのは意図であり、それは権威の地図を目に見えるようにしたものです。

ウェアハウス、レイク、レイクハウス

Section titled “ウェアハウス、レイク、レイクハウス ”

業務システムはビジネスを動かし、分析システムはビジネスを理解する助けになります。「私の未完了の商談を見せて」はSalesforceのレポートです。「すべてのチャネルにわたる5年分の売上、出荷、返品、ケース、在庫、財務を見せて」は別の問題です。

分析のストアには3種類あります。データウェアハウスは、分析のために準備された構造化データを保持します。データレイクは、ずっと多くのデータをより多くの形で、しばしば生のまま保持します。レイクハウスはその二つを組み合わせたもので、レイクのような保存とウェアハウスのような分析を備えています。全体像に登場するので、知っておきましょう。しかし私の経験では、レイクハウスやデータメッシュは、Salesforceのプロジェクトではまだニッチです。 典型的な全体像は、CRM、ERP、ウェアハウス、連携層であり、ほかのプラットフォームはビジネスが本当に必要とするところにあります。アーキテクチャを学び、用語を追いかけないようにしましょう。

分析はデータのある場所にある

Section titled “分析はデータのある場所にある ”

これは私の最も強い立場の一つです。分析の置き場所は、データの置き場所に従う。 レポートに必要なのが取引先、商談、営業担当者だけなら、すべてがコア上にあります。標準のレポートとダッシュボードです。次にビジネスは、ERPの請求書を加えたいと言います。次に製品原価を。次にウェアハウスから5年分の注文を。次にWebサイトの行動を。ある時点で、レポートのためだけにそれらすべてを業務用のCRMに引きずり込むことは筋が通らなくなります。ほかのデータストアが関わるようになれば、分析プラットフォームが必要になります。Tableau（Data 360の上に作られたTableau Nextを含む）、あるいはすでに使っているならCRM Analyticsです。Salesforceのデータをウェアハウスと統合するなら欠かせません。要件がただ複雑になったのではありません。全体像が、その問いに答えるべき場所を変えたのです。ですから私は「どの分析ツール？」からは決して始めません。**データはどこにあるのか？**から始めます。

CTA候補者にも同じことを聞きます。「私の図のうち、どれがこれを見事に解決するでしょう？　全体像です。」すべてがコア上にあるなら、レポートを使いましょう。ほかのリポジトリにデータがあるなら、分析プラットフォームを見たいところです。誰かがレポートビルダーを開く前に、全体像がレポートの問いに答えてくれます。（製品名は変わります。Salesforceの分析が今日どうなっているかは、Data 360の章で扱います。）

MDM：この顧客は本当は誰なのか？

Section titled “MDM：この顧客は本当は誰なのか？ ”

では、顧客情報がSalesforce、ERP、Eコマース、ロイヤルティプラットフォーム、パートナーのシステムにあり、それぞれが顧客が誰かを知っていると思っているとしましょう。そこでマスターデータ管理の出番です。システムをまたいで、重要なデータの権威ある識別を確立し、統制すること。しかしMDMは「マスターの顧客データベース」ではありません。難しい問いは、どのシステムが顧客を作ってよいのか、それぞれのシステムがどの属性を所有するのか、重複をどう見つけるのか、どの識別子が残るのか、システムが食い違ったら何が起きるのか、です。第6章はそのすべてについてです。ここでは役割に気づいてください。MDMプラットフォームが存在するなら、それはSalesforceと企業のほかの部分との間の重要な権威かもしれません。

連携層とイベント

Section titled “連携層とイベント ”

すべてのシステムをほかのすべてのシステムと直接つなぐと、全体像はすぐにスパゲッティになります。だから企業には連携層があります。ESB（エンタープライズサービスバス）やiPaaS（サービスとしての連携プラットフォーム）です。Salesforceの全体像で最もよく出会うのはMuleSoftです。それが仲介するので、各アプリケーションがほかのすべてのアプリケーションを理解する必要はありません。

しかし、中央にMuleSoftの箱があるからといって、連携がよいものになるわけではありません。それでも私は、何がそこを通り何が通らないのか、誰がデータを変換するのか、誰が契約を所有するのか、送り先が止まっていたら何が起きるのか、同期か非同期か、メッセージが成功したことをどうやって知るのかを知りたいのです。Integration Architectのコースで深く扱います。ここでは、それがそれ自体の役割であることに気づいてください。

そして、すべての連携がシステムAがシステムBを呼び出すものではありません。何かが起き（注文が作られる、配送のステータスが変わる、トラックがある地域に入る）、イベントが発行され、関心のあるものが応答することもあります。動いているイベントにもインフラがあります。Salesforce自身のイベント機能、企業のイベントバス、そのほかのメッセージング。データベースだけでなく、データを運ぶ仕組みを描きましょう。

開発者が忘れるシステム：ID

Section titled “開発者が忘れるシステム：ID ”

全体像にいつも置いておきたいのに、開発者がめったに考えない箱が一つあります。IDプロバイダーです。開発者はユーザー名とパスワードでサンドボックスに直接ログインするので、構築中はIDが見えません。そしてUATや本番がやって来ると、突然、従業員向けの会社のシングルサインオン、もしかするとパートナー向けの2つ目のプロバイダー、顧客向けのソーシャルサインオンが現れます。IDはずっとアーキテクチャの一部でした。開発者にはまだ見えていなかっただけです。

IDプロバイダー（IdP）とは、ユーザーを認証し、Salesforceが信頼する識別を確立するシステムです。リリースパイプラインの後のほうで設定されるとしても、初日から全体像に置くべきものです。誰が入れるかが、誰がデータにたどり着けるかを決めるからです。

実務上の落とし穴もあります。IDの設定はデプロイできますが、完全にではありません。 SAMLシングルサインオンの設定と認証プロバイダーはメタデータAPIの型なので、パイプラインに乗って移動します（SamlSsoConfig (opens in a new tab)、英語）。しかし、認証プロバイダーのコンシューマーシークレットはメタデータAPIの応答にもう含まれず（Metadata API Responses No Longer Include Authentication Provider Consumer Secrets (opens in a new tab)、英語）、証明書はたいてい環境ごとに違います。移動する部分と移動しない部分を計画しておきましょう。

全体像を役割として読む モジュール4のシステム全体像を、役割として読んだもの。中央のSalesforceはエンゲージメントシステムで、人が仕事をする場所。右側に社内システム：製品、注文、請求書の記録システムであるERP。財務。注文管理。インサイトシステムであるウェアハウスまたはレイクハウスと分析プラットフォーム。顧客が誰かについての権威であるMDM。そして動いているイベントのためのイベントバス。上ではIDプロバイダーが誰が入れるかを決め、下には顧客チャネル、右下にはデータの入出力があり、顧客について独自の見方を持つパートナーのシステムもそこに含まれる。Data 360は連携層の下、ニアコアに置かれている。2つの流れが連携層を通る：製品はERPから入り、注文はERPへ出ていく。それぞれの矢印は接続を開くシステムから始まる。 上：ID、APPEXCHANGE、WEB 人 右：社内システム 下：顧客チャネル 右下：データの出入り 社内ユーザー 営業、サービス、オペレーション パートナーユーザー 顧客 公開Webサイト 従業員用IdP シングルサインオン パートナー用IdP シングルサインオン AppExchangeアプリ 電子署名 パートナーコミュニティ 顧客コミュニティ Data 360 ニアコア：コアで管理し、コ アの外でホストする 連携層（ESB） ERP 記録：製品、注文、請求書 財務 支払い 注文管理 ウェアハウスまたはレイクハ ウス インサイト：履歴、すべてのソース 分析プラットフォーム インサイト：データストアをまたぐ MDM 権威：顧客が誰か イベントバス 動いているイベント メール メール-to-ケース Webフォーム Web-to-リード 電話 コンタクトセンター メッセージング SMS、チャット アーカイブ 古いケース データロード 移行 外部データ コピーせず参照 パートナーのシステム 顧客についての独自の見方 Salesforce エンゲージメント：人が仕事をする場所 出ていく注文 入ってくる製品 出ていく注文 入ってくる製品 Salesforce コミュニティ 人 ID、アプリ、Web 社内システム 顧客チャネル データの出入り 統合レイヤー 破線：まだ稼働していない、または参照のみ 接続を開くシステムから始まる。ラベルは何が動くかを示す © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

全体像をロゴではなく役割として読みます。それぞれのシステムが何を所有し、何を読み、何を決めるのか。

Data 360はどこに置くか？

Section titled “Data 360はどこに置くか？ ”

Data 360は、描き方についてのよい問いを投げかけてくれます。私はそれを右側の、ESBやMuleSoftの下に置きます。理由はその接続です。ユーザーが直接それに接続することはありませんが、それは多くのバックエンドシステムに直接接続します。ですから、ユーザーの側ではなく、それらの線が短くて済むデータの配管と一緒に置くべきものです。人がログインする別の画面のように描けば、間違った話を伝えることになります。

管理者やデータチームはData 360の画面を開きますが、その画面は組織の中、コアの上にあります。仕事をしているテナント、つまりそのデータと処理は、コアの外で動いています。だから私はそれをニアコア：コアで管理し、コアの外でホストすると呼ぶのです（用語はモジュール1で説明しています）。図はテナントに従います。配管と一緒に置き、それを管理する組織へ1本の線を戻します。

Salesforceの言葉を借りれば、それがすることにはゼロコピーが含まれます。企業がデータをコピーせずにアクセスし、クエリできるようにするデータフェデレーションの技術です（Zero Copy (opens in a new tab)、英語）。機能とコネクタはすぐに変わるので、このモジュールを製品ツアーにするのではなく、Data 360の章できちんと扱います。

全体像を責任として読む

Section titled “全体像を責任として読む ”

全体像を見るときは、ロゴではなく責任を読みましょう。ERP：何を所有しているか？　ウェアハウス：どんな問いに答えるか？　連携プラットフォーム：何を動かすか？　IdP：誰を認証するか？　MDM：どんな識別を統制するか？　Data 360：何を、何のためにつなぐか？　Salesforce：実際には何に責任を持っているか？　それに答えられれば、箱は意味を持ち、その間の矢印はずっと興味深くなります。次は、それらを意図的に描きます。

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

Section titled “ここでアーキテクトが決めること ”
  • 製品名を超えて、それぞれのシステムがどんな役割を果たしているか。
  • 重要なデータセットのそれぞれについて、どのシステムが権威を持ち、どこでSalesforceが手元のコピーだけを持つのか。
  • ERPが所有するデータが、書き込みを管理した上でSalesforceで利用できるか、そしてその所有がスキーマにどう表れているか。
  • データのある場所に基づいて、分析がどこに属するか。
  • ID、連携、イベント、マスターデータの権威が、全体像のどこにあるか。

10個の長方形がある全体像は、アーキテクチャではなく一覧表です。アーキテクチャが始まるのは、すべての長方形を指して、なぜそれがそこにあるのか、何を所有しているのか、誰が使うのか、Salesforceがそこから何を必要としているのか、そしてその役割を誤解したら何が壊れるのかを言えるようになったときです。

さらに学ぶ

Section titled “さらに学ぶ ”