組織戦略は全体像の判断である
ほかに 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)
モジュール5／6：Data Architectコース第4章「企業のデータを理解する」。各モジュールは単独でも読めます。 前へ：システム全体像を描く · 次へ：Steve Truckingの全体像
このモジュールが答える問い： 組織は一つか複数か。そしてどこで動かすのか？
CTAの候補者を教えるとき、シナリオで最も大きな判断は最初の5分か10分でやって来る、と伝えています。いくつのSalesforce組織を扱うのか？ 一つの大きな組織？ 北米、EMEA、APACの地域ごとの組織？ 事業部門ごとの別々の組織？ 独自のルールを持つ国のための特別な組織？ そしてそれに直結するのが、**その組織はどこで動くのか？**です。
これらは管理上の細部ではありません。データの置き場所、連携、レポート、ID、そして世界中の人々がシステムにどうたどり着くかを変えます。だから私は組織戦略を全体像の判断として扱い、最初に決めるのです。
一つの組織から始める
Section titled “一つの組織から始める ”私の出発点はシンプルです。一つの組織から始める。 一つの組織がいつも正しいからではなく、もう一つ追加するには理由が必要だからです。一つの組織なら、共有の顧客データの置き場所が一つ、セキュリティモデルが一つ、デプロイ先が一つ、連携が一組、レポートの場所が一つになります。そして一つの組織でも、さまざまな事業部門、国、プロセス、レコードタイプ、アプリ、共有モデル、体験を支えられます。
ですから、ヨーロッパのやり方が少し違うから、ある事業部に独自の営業プロセスがあるから、事業部門同士の仲が悪いからといって、組織を追加はしません。それらは要件であって、組織の境界ではありません。問いは、**もう一つの組織を正当化するほど強い力は何か？**です。
複数の組織にはコストがある
Section titled “複数の組織にはコストがある ”一つの組織を3つ（北米、ヨーロッパ、アジア太平洋）に分けると、きれいな箱を3つ描いたことにはなりません。新しい問いを生んだのです。グローバルな顧客はどこにいるのか？ 2つの地域で事業をしていたら、コピーが2つになり、どちらが所有するのか？ グローバルなレポートはどうするのか？ ERPは3つすべてと連携するのか、ウェアハウスには3つのフィードが来るのか、IDプロバイダーは3つすべてに接続するのか？ 同じ機能を3回デプロイし、3つのデータモデルをそろえ続けるのか？ エージェントが顧客のグローバルな姿を必要としたら、どの組織に尋ねるのか？
モジュール4の全体像に戻ってください。一つのSalesforceの箱が3つになり、すべての矢印が描き直されます。マルチ組織が間違っているのではありません。決して無料ではないのです。
本当の境界を探す
Section titled “本当の境界を探す ”何がもう一つの組織を正当化できるでしょうか？ アーキテクチャを形づくるほど本物の境界です。データの所在地、規制、法的な分離、本当に異なる事業モデル、まだ統合されていない買収、地域のホスティングの制約、大きく異なるガバナンス、ときには規模や隔離。このリストはすべてではありません。大事なのは、**「この集団たちは違う」と「この集団たちにはアーキテクチャ上の境界が必要だ」**を見分けることです。後者のハードルはずっと高いのです。
地理が自動的に組織戦略になるわけではない
Section titled “地理が自動的に組織戦略になるわけではない ”「30か国で事業をしているので、30の組織が必要です」。違います。地理が重要になるのは、アーキテクチャ上の要件をもたらすときです。一つの会社が、一つの共通アーキテクチャの上に世界中のユーザーを持つことはできます。ですから私は国の数を数えるのではなく、それに何がついてくるかを問います。データはどこに保存してよいのか？ どこで処理してよいのか？ 個人データを国境を越えて動かすことに制限はあるか？ データの所在地についての契約上の約束は？ ある地域には別のSalesforceのサービスやホストが必要か？ 「ドイツにオフィスがある」だけでは足りません。
ホスティングも図の一部
Section titled “ホスティングも図の一部 ”ここで現代のプラットフォームが全体像をより面白くします。Hyperforceは世界中の地域のパブリッククラウドインフラでSalesforceを動かし、データをどこに置くかについて、顧客により多くの選択肢と管理を与えます（Salesforce Hyperforce: General Information and FAQ (opens in a new tab)、英語）。ですから箱に「Salesforce、ヨーロッパ」とラベルを付けるとき、その場所が重要になり得ます。
しかし正確にいきましょう。組織をどこに置くかを選ぶことは、すべてのサービスのすべてのバイトがそこにとどまるという約束ではありません。Salesforceは顧客に、購入するサービスの追加の再委託先も含め、Hyperforceについての信頼とコンプライアンスのドキュメントを確認するよう伝えています（同じ情報源）。ですから「X国のHyperforceにいるから、すべてがX国にとどまる」と言わないでください。実際にどのサービスを使っているのか、どの要件を満たしているのかを知っておきましょう。そして、何を選んでいるのかに注意してください。選ぶのは地域であって、その下のクラウドではありません。HyperforceはAWSの上で動き、2026年後半からはGoogle Cloudも加わります。組織がどのプロバイダーに置かれるかを決めるのはSalesforceです。一方のプロバイダーを避ける規制上の理由が文書化されている顧客は、担当のアカウントチームに相談します（同じ情報源）。
弁護士を演じない
Section titled “弁護士を演じない ”ここはまた、アーキテクトが自分の役割を知るべきところでもあります。誰かが「ヨーロッパのプライバシー法が別の組織を求めている」と言ったら、私はそれを鵜呑みにはしません。かといって、自分を会社の弁護士に任命して、そんなことはないと宣言することもしません。こう尋ねます。どの具体的な要件を満たそうとしているのか？ データをどこに保存するか、どこで処理するか、国境を越える移転、サポートのために誰がアクセスできるか、契約、社内ポリシー？ そしてプライバシー、セキュリティ、コンプライアンス、法務の人たちと一緒に、その要件をアーキテクチャに翻訳します。法的要件をでっち上げないでください。無視もしないでください。翻訳するのです。
ヨーロッパが独自の組織を持つとき
Section titled “ヨーロッパが独自の組織を持つとき ”実際のシナリオで目にする境界を一つ紹介しましょう。ある会社は、米国でも欧州でも大きな存在感を持っています。2つの大きな顧客基盤、2つの営業・サービスの組織、そしてGDPRを中心に組み立てられた欧州のプライバシープログラム。GDPRは「別のSalesforce組織が必要だ」とは言っていません。個人データについてのルールを定めているのであり、そこにはEUの外へいつ移転してよいかも含まれます（GDPR, Chapter V (opens in a new tab)、英語）。しかしこの会社は、プライバシーと法務のチームと協力して、欧州の顧客の個人データは、欧州でホストされ、欧州のチームが運用し、欧州のガバナンスのもとにある組織に置くべきだと判断します。それは本物の要件であり、私のものではなく彼らのものです。
これで「一つの大きなグローバル組織」はもはや好みの問題ではありません。全体像にはSalesforce AMERとSalesforce EMEAという境界があり、私はそれを描かなければなりません。そして2つ目の組織は、決して箱が一つ増えるだけでは済みません。
AMERとEMEAの2つの組織。琥珀色は2つ目の組織が加えるものです。箱が一つ増えるのではなく、すべての矢印がもう一度必要になります。
もう一度矢印をたどる
Section titled “もう一度矢印をたどる ”組織が複数になったら、全体像をもう一度たどりましょう。ERPはすべての組織に製品を送るのか？ それぞれが注文を送り返すのか？ 顧客はどこでマスター管理され、そのデータは地域をまたいでよいのか？ 連携層はグローバルか地域ごとか？ どのIDプロバイダーがどのユーザーをサインインさせるのか？ 分析データはどこへ行くのか？
コストが最も早く現れるのは3つの場所です。
レポート。 CEOがグローバルなパイプラインを見たいと言います。一つの組織ならそれはSalesforceのレポートです。3つなら、企業のレポートの問題になります。複製するか、ウェアハウスに送るか、フェデレーションするか？ どれくらい新しくなければならず、そもそも各組織は「パイプライン」を同じように定義しているのか？ 分析の置き場所はデータの置き場所に従います。 業務データを意図的に分けたなら、インサイトがどう再び一つにまとまるかを設計しなければなりません。
マスターデータ。 あるグローバルな顧客が、米国、ドイツ、日本で購入します。組織が3つなので、おそらく取引先も3つです。それが同じ会社だとどうやってわかるのか？ グローバルな識別子は何で、誰が所有しているのか？ ある地域が住所を変えたら、それは広がるべきか？ どの属性がグローバルで、どれが地域ごとか？ 組織戦略は識別の問題を解決しません。識別の問題を変えるのです。それが第6章です。
連携。 一つの組織なら：Salesforce、連携層、ERP。3つの組織なら：連携層への3つの接続、そのうち一つは独自のホストと接続性を持つかもしれず、一部の流れは共有、一部は地域ごと、一部のデータは越えてよく、一部はいけない。ネットワークさえ変わることがあります。企業がHyperforceへの専用のプライベート接続を必要とするなら（AWS上では、SalesforceはAWS Direct Connectを推奨しています。同じHyperforceのFAQ）、図の上の組織とホストの一つひとつが、計画すべきもう一つの接続になります。組織がどこで動くかが、企業のほかの部分がそこにどうたどり着くかを変えることがあるのです。
組織を一つにするか複数にするかは、今、最初に、全体像の上で下す判断です。 その後、組織同士がどうデータを共有するか（組織間のSalesforce Connect、組織間の連携、Data 360）は仕組みの話であり、第14章の組織は一つか、複数か？ *(coming soon)*で扱います。
データモデル全体と連携アーキテクチャを設計した後で、「ところで、これは3つの組織でなければなりません」と聞かされたら、それは小さな調整ではありません。アーキテクチャを変えたのです。だからこの判断は最初に来るのです。
箱を小さくするためだけに分けない
Section titled “箱を小さくするためだけに分けない ”大きな組織は複雑に感じられます。たくさんの部門、オブジェクト、ユーザー、連携。誰かが「みんなが自分の組織を持てば、すっきりするのでは？」と言います。図はすっきりするかもしれません。企業はそうならないかもしれません。内部の複雑さを、分散した複雑さと交換したのです。同期、重複データ、組織をまたぐ識別、グローバルなレポート、いくつものリリースパイプライン、重複した連携と自動化、そしてそのすべてを統べるガバナンス。それでもそれが正しい交換であることもあります。しかし、分かれていることはシンプルであることと同じではありません。
そして一つの組織も無料ではありません。共有のガバナンスがより重要になり、チーム同士が影響し合い、セキュリティの境界は慎重な設計が必要で、データモデルは多くの集団に仕えなければならず、リリースには調整が必要で、地域のルールが全員を縛ることもあります。ですから「スティーブはいつも一つの組織と言う」ではありません。私の出発点は一つの組織への傾きであり、そこから私を動かすほど強い要件を探すのです。
判断を見えるようにする
Section titled “判断を見えるようにする ”組織戦略が重要なら、汎用のSalesforceの雲を描かないでください。組織を描いてラベルを付け（AMER、EMEAなど、現実にあるもの）、それぞれの背後にあるホスティングやデータの所在地の要件を書き添え、接続をたどりましょう。別のアーキテクトが、それぞれの境界がなぜ存在するのかを見てわかるようにすべきです。なぜSalesforceの箱が3つあるのかを説明できないなら、判断はまだ終わっていません。
Steve Truckingは米国で一つの組織を使っていて、概要資料にはもう一つを求めるものは何もありません。しかし、このモジュールは最終課題のために覚えておいてください。独自の組織を持ったまま加わる買収は、まさにこうした問いを試す種類の境界です。
試験の先へ：AIが変えること。 エージェントは、組織の境界をユーザーから見えなくすることができます。その下では、エージェントがどの組織やシステムに尋ねてよいのか、どのデータが地域をまたいでよいのか、どの答えが権威あるものなのかを、やはりアーキテクチャが決めなければなりません。AIは体験の中で複雑さを隠せますが、ガバナンスや境界をなくしはしません。
ここでアーキテクトが決めること
Section titled “ここでアーキテクトが決めること ”- 一つの組織の中で違いを解決するのではなく、複数の組織にする本物のアーキテクチャ上の理由があるか。
- それぞれの組織がどこで動き、どのデータの所在地、規制、契約、ビジネスの要件がそこに置かせているのか。
- どのデータが組織や地域の境界を越えてよいか、マスターデータはどこで権威を持つか、グローバルな識別はどう機能するか。
- 一つのSalesforceの箱が複数になったとき、連携、ID、分析、レポートがどう変わるか。
- 分離の利点が、それが生む分散アーキテクチャに見合うか。
シナリオを読むとき、私はまずこの判断を探します。組織は一つか複数か、どこでホストし、何がそれを強いているのか？ それに答えれば、全体像の残りが形をとり始めます。
さらに学ぶ
Section titled “さらに学ぶ ”- Salesforceヘルプ、Salesforce Hyperforce: General Information, FAQ, Migration Guide, and Security Overview (opens in a new tab)（英語）、2026-10-14確認。
- EUR-Lex、Regulation (EU) 2016/679, the General Data Protection Regulation (opens in a new tab)（英語）、第5章（第三国への個人データの移転）、2026-10-14確認。