ポスト
はじめに
皆さま、明けましておめでとうございます。山田です。今年も宜しくお願い致します。
前回の投稿が昨年5月でしたのでおよそ8か月ぶりの投稿になります。今回は、Salesforceの組織戦略いわゆるOrg Strategyについて考えてみたいと思います。「そんな！他社の組織戦略についてコメントするのですか！？」と思われる方もいらっしゃるかもしれませんが、ご安心下さい。間違ってもそんな高飛車のことは決してできません。Salesforceを利用する際に皆さんがログインするシステムスペースのことを組織（Org=Organizationの略）と呼んでいるのはご存知だと思いますが、その“組織”のことを指しています。その組織をどのように利用し運用していくかという話になります。
もう少し具体的に言いますと、通常、組織はユーザ毎に1組織で利用されているケースがほとんどだと思います（SandBoxやDeveloper組織を除いた本番組織を前提）。但し、過去からの導入の経緯やユーザ会社毎の事情により、複数組織で利用されているケースもそれなりにあると思います。色々な事情や志向も絡んできますので一概に1組織で運用するのが良いか複数組織で運用するのが良いかは意見することは難しく、正直白黒どちらが正解というものでありません。とはいえ、Salesforceを利用されているユーザさまはもちろん、導入を手掛けているパートナーさまの中でも、このようなケースはどう組織戦略を立てるのが良いのだろうとお考えの皆さまもいらっしゃると思い、今回いくつかの観点から私なりに考え、提示してみたいと思います。
少し長編になりますので、全体を以下の3回に分けての連載とさせて頂きます。
第一回目：
・単一組織vs.複数組織（Single-Org vs. Multi-Orgs） のメリット/デメリット
・組織利用のユースケース
第二回目：
・組織戦略を検討する上での幾つかのクライテリア
第三回目：
・単一組織で特に考慮すべき項目とソリューション例
・複数組織で特に考慮すべき項目とソリューション例
前回の投稿が昨年5月でしたのでおよそ8か月ぶりの投稿になります。今回は、Salesforceの組織戦略いわゆるOrg Strategyについて考えてみたいと思います。「そんな！他社の組織戦略についてコメントするのですか！？」と思われる方もいらっしゃるかもしれませんが、ご安心下さい。間違ってもそんな高飛車のことは決してできません。Salesforceを利用する際に皆さんがログインするシステムスペースのことを組織（Org=Organizationの略）と呼んでいるのはご存知だと思いますが、その“組織”のことを指しています。その組織をどのように利用し運用していくかという話になります。
もう少し具体的に言いますと、通常、組織はユーザ毎に1組織で利用されているケースがほとんどだと思います（SandBoxやDeveloper組織を除いた本番組織を前提）。但し、過去からの導入の経緯やユーザ会社毎の事情により、複数組織で利用されているケースもそれなりにあると思います。色々な事情や志向も絡んできますので一概に1組織で運用するのが良いか複数組織で運用するのが良いかは意見することは難しく、正直白黒どちらが正解というものでありません。とはいえ、Salesforceを利用されているユーザさまはもちろん、導入を手掛けているパートナーさまの中でも、このようなケースはどう組織戦略を立てるのが良いのだろうとお考えの皆さまもいらっしゃると思い、今回いくつかの観点から私なりに考え、提示してみたいと思います。
少し長編になりますので、全体を以下の3回に分けての連載とさせて頂きます。
第一回目：
・単一組織vs.複数組織（Single-Org vs. Multi-Orgs） のメリット/デメリット
・組織利用のユースケース
第二回目：
・組織戦略を検討する上での幾つかのクライテリア
第三回目：
・単一組織で特に考慮すべき項目とソリューション例
・複数組織で特に考慮すべき項目とソリューション例
単一組織vs.複数組織（Single-Org vs. Multi-Orgs） のメリット/デメリット
それでは先ず月並みですが、一般的に考えられるそれぞれの組織戦略におけるメリット/デメリットを列挙してみたいと思います。
他にもあるかとは思いますが、それぞれいくつか挙げてみました。メリット/デメリットは双方の組織において裏返し且つ相対的な観点の捉え方になっています。
言葉として出てくる、ユーザ、部門、データ、アプリケーション、業務プロセス、レポーティング、ガバナ制限、SSO、連携、Chatterそれぞれの数、規模、用途などによりどちらを採用するのが良いかも変わってくるであろうことが予測できます。また、それらの数、規模は時間と共に変動（多くの場合は増加）するので、最初は単一（あるいは複数）の方が良いと思ったが、長年運用していく中で複数（あるいは単一）に方針変更した方が良い場合も出てくることもあるだろうと想像できます。
こうなってくると、「やっぱり難しい！」となりますが、次にいくつかユースケースを作成して考えてみたいと思います。
言葉として出てくる、ユーザ、部門、データ、アプリケーション、業務プロセス、レポーティング、ガバナ制限、SSO、連携、Chatterそれぞれの数、規模、用途などによりどちらを採用するのが良いかも変わってくるであろうことが予測できます。また、それらの数、規模は時間と共に変動（多くの場合は増加）するので、最初は単一（あるいは複数）の方が良いと思ったが、長年運用していく中で複数（あるいは単一）に方針変更した方が良い場合も出てくることもあるだろうと想像できます。
こうなってくると、「やっぱり難しい！」となりますが、次にいくつかユースケースを作成して考えてみたいと思います。
組織利用のユースケース
ユースケースその1:利用用途がどんどん広がっていくケース
先ずは単一組織で、一部門、利用アプリケーションも一つか二つでSalesforceを活用してみようということで使っていたところ、評判が良く、他の部門や全社でも利用したいということでユーザもロールもプロファイルも増え、共有設定も複雑になっていくケースがあると思います。また、新しいアプリケーションを乗せたいという要望も多く出てくることにより5つ、6つさらには10を超えるアプリケーションを単一組織上に構築していくこともあると思います。この場合も上記の設定項目に加え、オブジェクトやアプリケーションの設定項目が増え、必要に応じVisualforceやApexでの開発も出てくるかもしれません。ユーザ部門からの要求に早期に応えるため、社内要員による開発だけでなく、外部の開発ベンダーに協力を依頼したり、さらに対応するアプリケーション毎に異なるベンダーに依頼したりする必要が出てくるかもしれません。
このケースでは、特に以下のような項目を検討しておく必要があると思います。
・アプリケーション、データ（オブジェクト）毎の共有設定と権限
・ロール構成
・プロファイル構成と権限セットの利用
・データ検索とレポーティング・分析のパフォーマンス
・設定・開発におけるガバナンス
・特に複数人数/ベンダーによる開発時の統制
・設定・開発時だけでなくリリース時、保守・運用時の統制
ユースケースその2:簡単に構築、稼働できるため気が付くと組織が増えしまったケース
Salesforceの特長且つ魅力のあるところとしてPaaSとしてもSaaSとしてもすぐに本格的な開発作業無しでも設定ベースでアプリケーションを構築できることがあります。利用地域、部門やアプリケーション自体が全く異なるため立上げ優先のため、組織を断続的に複数契約して進めているケースもあると思います。その後さらにそれら個々の組織自体も利用状況が拡張され、外部システムを含めた連携も発生してくると、個々バラバラに運用していた組織を今後どうしていくかという話が出てくる可能性があります。
このケースでは、特に以下のような項目を検討する必要があると思われます。
・Salesforce組織の管理者の扱い
・ユーザID、パスワードの管理
・特に複数組織に共通ユーザが存在する場合の管理
・Salesforce組織間におけるデータ共有、連携
・業務プロセスの流れ、関連性、効率性
・外部システム連携時に個々のSalesforce毎に連携をとるか等の方式
・各地域/部門における開発・運用体制
もちろん従来のオンプレミスシステムやIaaS、PaaSと比較するとSalesforceはまだ考えるべきことが少なく済むと思いますが、開発・運用していく上での悩みは使えば使うほど、大きくなればなるほど、増えれば増えるほど、出てくると思います（それ以上に効果、メリットも出ているのでそうなってしまうのかもしれません）。
先ずは単一組織で、一部門、利用アプリケーションも一つか二つでSalesforceを活用してみようということで使っていたところ、評判が良く、他の部門や全社でも利用したいということでユーザもロールもプロファイルも増え、共有設定も複雑になっていくケースがあると思います。また、新しいアプリケーションを乗せたいという要望も多く出てくることにより5つ、6つさらには10を超えるアプリケーションを単一組織上に構築していくこともあると思います。この場合も上記の設定項目に加え、オブジェクトやアプリケーションの設定項目が増え、必要に応じVisualforceやApexでの開発も出てくるかもしれません。ユーザ部門からの要求に早期に応えるため、社内要員による開発だけでなく、外部の開発ベンダーに協力を依頼したり、さらに対応するアプリケーション毎に異なるベンダーに依頼したりする必要が出てくるかもしれません。
このケースでは、特に以下のような項目を検討しておく必要があると思います。
・アプリケーション、データ（オブジェクト）毎の共有設定と権限
・ロール構成
・プロファイル構成と権限セットの利用
・データ検索とレポーティング・分析のパフォーマンス
・設定・開発におけるガバナンス
・特に複数人数/ベンダーによる開発時の統制
・設定・開発時だけでなくリリース時、保守・運用時の統制
ユースケースその2:簡単に構築、稼働できるため気が付くと組織が増えしまったケース
Salesforceの特長且つ魅力のあるところとしてPaaSとしてもSaaSとしてもすぐに本格的な開発作業無しでも設定ベースでアプリケーションを構築できることがあります。利用地域、部門やアプリケーション自体が全く異なるため立上げ優先のため、組織を断続的に複数契約して進めているケースもあると思います。その後さらにそれら個々の組織自体も利用状況が拡張され、外部システムを含めた連携も発生してくると、個々バラバラに運用していた組織を今後どうしていくかという話が出てくる可能性があります。
このケースでは、特に以下のような項目を検討する必要があると思われます。
・Salesforce組織の管理者の扱い
・ユーザID、パスワードの管理
・特に複数組織に共通ユーザが存在する場合の管理
・Salesforce組織間におけるデータ共有、連携
・業務プロセスの流れ、関連性、効率性
・外部システム連携時に個々のSalesforce毎に連携をとるか等の方式
・各地域/部門における開発・運用体制
もちろん従来のオンプレミスシステムやIaaS、PaaSと比較するとSalesforceはまだ考えるべきことが少なく済むと思いますが、開発・運用していく上での悩みは使えば使うほど、大きくなればなるほど、増えれば増えるほど、出てくると思います（それ以上に効果、メリットも出ているのでそうなってしまうのかもしれません）。
おわりに
Salesforceの組織戦略は、特に利用地域・国が跨っていたり、大規模であったり、多数のアプリケーションを構築する場合に特に検討事項に挙がると思います。次回はさらに踏み込んで、組織戦略を検討する上での幾つかのクライテリアについて考えてみたいと思います。
11 件
