Salesforceの組織戦略（Org Strategy）について考える～第三回目～

三回にわたっての投稿になりましたSalesforceの組織戦略も今回が最終回となりました。前回最後にお知らせしましたように、最終回は、単一組織、複数組織それぞれのケースで特に考慮すべき項目と考えられるソリューションについて、あくまで一例とはなりますが、書いてみたいと思います。

それでは先ず、単一組織を採用した場合に“特に”考慮すべきポイントとそれに対するソリューション例について幾つか挙げてみたいと思います。（注：複数組織でも考慮は必要）

単一組織で複数地域/国/ユーザ（顧客）層をカバーしようとすると必然的に各オブジェクトにおけるデータ件数増加に繋がります。そのためデータ検索等データ処理パフォーマンスに対する考慮が必要になります。LDVに対する解決策として外部ID、インデックス（Two-Colum-Indexも含め）を活用してクエリーの選択性を上げる、スキニーテーブルを検討する、Visualforce、ApexにおけるBuilt-in-PaginationであるStandard Set Controller、 Offset、Limitの活用はアプリケーションを開発する際に、Salesforce開発者の方には釈迦に説法となりますが検討必至と思います。また、アクセス対象となるデータ自体を減らすためには組織のオブジェクト（データ）を論理的に分割するディビジョンを設定することも有効なソリューションとなり得ます。但しディビジョンは一旦設定すると元に戻すことはできないので注意は必要です。因みにChatterはディビジョン対応していませんので要注意です。（そもそも組織全体でのコミュニケーション、コラボレーションの透明性を高め、促すのがChatterですので分割できない方が良いとは思います）

SandBoxは本番組織に紐付いて構成されますが、特にFull SandBoxやPartial SandBoxはUnlimited Editionでも一つずつしか付いてきませんので（追加する場合は別途費用が発生）、ほとんどのユーザさまにおいては一つで運用されていると思います。そのため、1組織でアプリケーションを多数運用すればするほど、業務やデータの状況の関係からFull Sandboxを一括でリフレッシュするタイミングが難しくなってきます。これは物理的な課題のため、前もってSandBoxを全体としてどう使うか、特にバージョンアップ時のプレリリース環境、新しく稼働させるアプリケーションのタイミング（テスト含め）等を開発ライフサイクルの計画にしっかり盛り込んで管理していくしかありません。Partial SandBoxがある場合はそれとうまく役割とタイミングを調整して進めるのが良いと思います。どうしても調整だけでは回らず、必要となった場合は、追加購入を検討することになります。

これは上記のSandBoxの運用、開発ライフサイクルの課題にも関連しますが、本番リリースにあたっては、必ずデプロイ時に全体のテストクラスが走るので1組織で多数のアプリケーションとデータ（オブジェクト）を保有している場合は、注意が必要です。テストクラスの作り方を毎回本番の大量データを作成・削除しないようにサイロ化して工夫するのはもちろん、Full SandBoxを使った事前テストで確認し、Quick Release等の方式も検討するのが良いと思います。

Salesforceはマルチテナントで稼働しているため各契約組織におけるガバナ制限は避けては通れない項目です。1組織あたり1時間あるいは24時間単位での制限があることは皆さまも周知のことだと思いますが、特にアプリケーションやデータ量、外部システムとの連携が増えてきた場合には、実際に利用している機能（Bulk API、Apex等々）の消費状況を随時確認しておく必要があります。

Salesforceにおけるロールは、実際の会社組織形態とイコールではなく、アプリケーション機能とシステムのセキュリティ・アクセスモデルを反映したものであることは言わずもがなですが、会社全体で様々なアプリケーションをSalesforceに載せていくとロールだけで表現できなかったり、公開グループや条件ベースの共有ルールを利用したりと、当初と比較してより複雑なセキュリティモデルにならざるをえません。但しこのモデルが膨らめば膨らむほど、データの追加・更新、共有モデルの再計算に時間がかかり、パフォーマンスにも影響してくるため、できるだけシンプルなモデルを考慮しつつ個別共有や、プロファイル/権限セットの権限系ともうまく組み合わせて実装していくしかないので、Salesforceのアーキテクトやsalesforce.comのサポート担当とも相談、場合によっては検証しながら進めていくことをお薦めします。

多数のアプリケーションを1組織で構築していてもほぼカスタムオブジェクトで対応してアプリケーション毎に縦割りで稼働している場合はまだよいのですが、標準オブジェクト含めアプリケーション横断で参照・更新するオブジェクトやリソースがある場合、特に外部ベンダーが入る（複数入る）場合においてはどのように共有/共通オブジェクトが使われており使うべきかを各プロジェクト当初に確認、検討しておく必要があると思います。

次に、複数組織を採用した場合に“特に”考慮すべきポイントとそれに対するソリューションについて幾つか列挙してみたいと思います。（注：単一組織でも考慮は必要）

複数の組織を管理していく上でシステム管理者の方、エンドユーザの方（管理している方や複数の組織にアクセスしているユーザの方）にとってユーザIDとパスワード管理は利用組織が増えれば増えるほど面倒な話であると思います。既に会社の基盤としてSSOを採用されている場合は、SalesforceでもSSOを使えるように設定するのが良いと思います。因みに多くの方がご存知なようにSalesforce自体がIdP (Identity Provider)にもSP (Service Provider)にもなることが可能です。

元々直接関連性の無い業務を別々のSalesforce組織で立ち上げている場合には問題はありませんが、データを何らかの形で共有するため連携処理が必要になったり、別組織のデータを集約して全社でまとめて見たりという要件が出てきた場合はデータのエキスポート/インポート、さらにはよりリアルタイムに近い形で連携処理を構築することになると思います。但し、Salesforceのコラボレーション機能であるChatterは複数組織仕様になっていないため、Chatter運用をどう扱うかは要検討項目です。より多くの社員/ユーザが利用する組織でもしくは運用組織を決めてChatterを利用するのも一案ですし、単一組織で列挙しました課題が解決できるのであればコラボレーション基盤としてのSalesforceのメリットを活かすため1組織運用を志向することも案だと思います。

複数の組織を同じシステム管理者の方、同じ開発者（会社）の方が担当している場合は、まだ問題は少ないかもしれませんが、組織によって担当者が異なる場合は設定や開発の標準化や規約が全く無い場合も想定されます。将来的なメンテナンスやライセンスの重複や機能の連携・統合の必要性から組織をマージするニーズが出てきた場合に余計なワークロードがかかるだけでなく、マージ自体が困難になることも考えられますので、そのような可能性が考えられる場合には、標準化・規約化は普通に必要になってくると思います。

組織が複数に渡り他/外部システムとの連携ポイントが多い場合（増えてきた場合）、似たような連携処理を複数組織に施さなければならなかったり、個々の組織（エンドポイント）に対して連携設定を構築しないといけなかったり、連携処理の開発・運用上非効率な状況になることも考えられます。ある程度大規模な組織運用をされている企業であればシステム間連携の基盤（仕組）としてETL/EAIを立てている所も少なくないかもしれませんが、連携の仕組みをより効率的に集約していく上でも必要なポイントになると思います。この場合でも1組織で課題対応できるのであれば連携の仕組みも逆に連携先が多岐に及ぶ場合にもSalesforceのエンドポイントはより少なくて済むため考慮しておいた方がよい項目です。

Single-Org vs. Multi-Orgsの議論は第一回目にも述べましたが、どちらかが絶対的に正しいとするトピックではありません。但し、導入当初に全く気にしないと、何年も運用してやはり1組織にまとめたい、逆に分割したいという要件が出てきた場合、ではどうすれば良いの？という改めてまっさらからの検討となることも少なくありません。今回双方のメリット/デメリット、考慮点、ソリューション案をあくまでいくつかの例として挙げさせて頂きましたが、今後もしこのトピックを考える場面に遭遇された皆さまの多少なりとも一助となりましたら幸いです。三回に渡っての購読ありがとうございました。