はじめに
Salesforceは、世界のあらゆる地域や国で利用され、マルチ言語対応されたシステムであることはご承知のことかと思いますが、今日は、既に他国で利用されてる自社の組織に対して日本側のビジネス要件をインプリする場合の注意点などを書きたいと思います。
なお言語対応については、既にこちらで、横山が執筆しておりますので、御覧ください。
ビジネス要件
グローバルで「業務標準化」ができれば、一番ベストなんですが、各国の商習慣や文化的な理由で、なかなか難しいと聞きます。 標準化が実現できれば、アプリケーションは基本そのままで、あとは共有ルールやロールを使ってデータのアクセス権のコントロールが作業のメインになってくると思います。 項目やページレイアウトに独自性が必要であれば、プロファイルごとに項目レベルセキリティやページレイアウト割り当てなどを使って、実装するといいでしょう。 どうしてもグローバル側のアプリケーションに業務が合わない場合、新規のオブジェクト作成やVisualforceやApexトリガーを使ったカスタマイズということになってきますが、その際に十分に検討しなければならないことがあります。 それは、 「日本の導入にあたりグローバルで統一したい点（KPI、プロセス等）が本当にないのか？」 という点です。 例えば、顧客情報、商談情報、問い合わせ情報、製品情報などグローバルで串刺してレポートで集計するような要件がないのかなどです。 新規のカスタムオブジェクトを使えば、グローバル側に影響させずにアプリケーションを作ることは、比較的容易ですが、安易に実装してしまうと、後からこのような集計要件を満たすことが困難になってきまので、アプリケーション構築のゴールを再確認しましょう。
インプリメンテーションとデータロード
AppExchangeを活用
日本のビジネス要件を実現するために新規のオブジェクト作成やVisualforceなどの開発を実施する前に、AppExchangeで要件をみたすようなアプリケーションが存在しないか確認することもお薦めです。AppExchangeのアプリケーションは、セキュリティレビューも通っており、他のアプリケーションに影響を及ぼすような安易な作りになっていないので、問題を軽減できます。
既存オブジェクトへの影響
取引先や商談など既存オブジェクトに独自の入力規則やワークロルール、Apexトリガーを実装する時は、特に注意せねばなりません。レコードタイプなどを条件にして、日本側の操作時にしか動かないように工夫しましょう。
データ移行
データ移行も、特に注意せねばなりません。旧システムなどで使っていたデータをそのまま移行するのではなく、本当に必要な最低限のデータのみが移行されるようきれいに整理してから移行することをおすすめします。 不要なデータを含めた大量件数のデータが既存オブジェクトに格納されることで、そのオブジェクトを参照している既存のレポートやビューやSOQLのパフォーマンスが著しく落ちる可能性があります。LDV（大量データ）の扱いに関しましては、別記事を参照ください。
・「Force.com マルチテナントアーキテクチャ」を理解して、スキニーテーブルを使ってみよう
ディビジョン
複雑な共有ルールやロール階層を使っての共有モデルは、これもパフォーマンスに影響するので注意しましょう。 必要に応じてディビジョンを使って地域ごとにデータのパーティショニングを実装することも考慮すべきかと思います。 ディビジョンとは、クエリやレポート、およびリストビューで返されるレコード数を削減するために、パーティションで区分する手段です。たとえば、日本ディビジョンだけの商談を表示するレポートを作成することにより、日本営業チームの営業数値を正確に把握できます。ディビジョンは、データ量が極めて多い組織に有用です。
リリース・保守
機能の追加、修正をどのようなプロセスで実施するのか、リリース管理は誰がどのようなプロセスで実施するのかを明確にする必要がございます。日本の開発用に開発Sandboxを使えたとして、グローバル側のアプリケーションの影響テストができるステージング環境など完全版Sandboxが用意されているかどうかも確認しなければならないポイントです。 リリース後も修正などを加える場合、だれがどういった手順で実施できるのかも運用開始前に確認しておきましょう。
終わりに
他国の既存組織に新しい要件を入れるのは、コミュニケーションも含めてなかなか大変です。 互いの組織を把握して、時には妥協し、時には説得しなければならない場面もでてきます。 問題がでた時は、ゴールを明確にして、代替案などを提案できる力が大事になってくるでしょう。
