はじめに
みなさん、こんにちは。昨年はSOSにフォーカスしてサービスクラウドのソリューションを書きましたが、今年はまた、より自分の得意分野？のガバナンス系に戻って書いてみたいと思います。
最近はもう言わずもがなになってきましたがSalesforceはCRM、SaaSの枠組みをはるかに飛び越え、顧客自身がアプリケーションを作成・開発できるPaaSとしての位置づけを確固たるものとしています。
お客様の中には単に一部のアプリケーションあるいは一部の部門でSalesforceを活用するだけでなく、ほぼ全社におけるアプリケーション基盤として利用されている、利用されようとしているケースもかなり増えてきてのではないかと思います。
今回は特に、今後Salesforceを"全社におけるアプリケーションを開発する基盤"として活用しようとされているお客様向けに書いてみようと思います。もちろん既にSalesforceを導入済みのお客様や、Salesforceを導入・開発するベンダーサイドの方々にとっても何らかのヒントやリマインダーになれば大変幸いです。
全社基盤として導入するということの定義
先ず全社基盤として、Salesforceを導入するということの定義について書いておこうと思います。
必ずしも会社の全てのシステム、アプリケーションをSalesforceで行うということを意味したものではありません。もちろん会社規模がまだ小さく、例えば経理システム以外は全部Salesforceで！と、全てをクラウドシステムで賄うお客様もいらっしゃるかもしれませんが、大抵の場合、
・過去からの歴史の中でERPをはじめとする基幹業務パッケージ
・自社独特の業務仕様を実現するために自社開発したシステム
・システム間連携を実現する連携基盤
・ユーザ/ID管理基盤
・ミッションクリティカルな業務をカバーするためのシステム
・部門毎に利用している独自・分散型のシステム 等々
非常に複雑な状態のお客様が大多数ではと思います。
実際こういった仕組みの全てをSalesforceに置き換えることは困難且つ不可能に近いですし、敢えてその必要も無いと思います。そこで全社導入として導入することをここでは以下の形で（緩く）定義しておきます。
色々なご意見はあるかとは思いますがご容赦下さい。
- できるだけ数多くのアプリケーションをSalesforce上に構築したいと考えている（数個というより2桁以上のイメージ）
- 少なくとも一つのアプリケーションはほぼ全社のユーザで使うことを想定しているもしくは同一のアプリケーションでなくてもほぼ全社ユーザが何らかのアプリケーションをSalesforceを通じて利用することを想定している
- 社内における開発基盤の一つとしてForce.com（Apex、Visualforce、各種API含め）を位置づけようとしている
- Salesforce単体でなく既存含めた他のシステム（基幹システム、ERP等）とも連携して使うことを考えている
考慮すべきアプローチとは？
それでは上記のような導入ケースの場合にどういった点を考慮するのが良いでしょうか。
個別のプロジェクトやアプリケーションの導入に際してというより、全体的な仕組み・体制・進め方という観点で見てみたいと思います。また、ここでは社内におけるクラウド導入を説得しなければならないというより政治的・事前調整的なアプローチは割愛させて頂き、導入前提の直前もしくは初期のフェーズのシステム的な観点のアプローチに絞らせて頂きます。
自分自身の経験と考察に基づいて以下の4点は少なくとも導入に際して考慮し策定しておくべきだと考えます。
- アプリケーションのセールスフォース適合性判定と優先度、ロードマップ
- システム/データ連携のアーキテクチャー
- 開発及び運用・サポート体制と教育計画
- 開発・運用における標準/共通化、ガイドライン
※私が一昨年投稿させて頂いた「COEってご存知ですか？」で書きました、COE (Center of Excellence)もこのようなSalesforceを全社アプリケーション基盤の一つとして導入する際に、上記4つのアプローチを策定・実行していくにあたって必要となる要員体制・仕組みになると思います。
それではそれぞれの項目について見ていきたいと思います。
1. アプリケーションのセールスフォース適合性判定と優先度、ロードマップ
SalesforceのDNAとも言えるCRM関連のアプリケーションであれば、特に特別な検証をせずともSalesforceでやろう！ということに落ち着くと思いますが、いわゆるPaaS上に今まで別の仕組みやシステムで構築していたアプリケーションをSalesforceに乗せたい、新たな業務をSalesforceでやりたいという場合は、果たしてそのアプリケーションがSalesforceに向いているかどうか（正確にはどの程度向いているか）を見極めて、開発の優先順位と導入のロードマップを決めていく必要があると思います。
PaaSなのだから何でもかんでもSalesforce上に乗せたい！という気持ちもわかりますが、向き不向きと難易度、ビジネス上の優先度を冷静に見極めた上で進めることが、結果的にトラブルを回避する上で得策であり、より多くのアプリケーションをSalesforceで実現したいというゴールに対して近道になることをご理解頂きたいと思います。
Salesforceに向いているアプリケーションかどうかの適合性判定には経験的にも手法がありますが、ビジネスインパクトや開発の難易度等を軸としてマトリクス分析する方法があります。
さらに開発の難易度を判定するために、該当アプリケーションのUI/UX、ロジック、データモデル、連携等の各要素の複雑度を計数化して表して評価を行うこともできます。分析の結果として、Salesforceの標準機能を活かして、設定カスタマイズだけでアプリケーション要件を満たせるものがあればそれに越したことはありません。
また、ユーザの操作性向上のためにどうしても画面開発が必要、データの2重入力を避けるため他システムと連携も必要なので開発工数もかなりかかってしまうが、実現した場合の効果が非常に大きい場合は導入した方が良いということもあるかもしれません。
これらはあくまで、分析・適合性判定における一例ですが、Salesforce導入前/初期のタイミングではお客様だけで判定することは難しいと思いますので、セールスフォース社やSalesforceを手掛けるベンダーに協力を仰ぐのが近道だと思います。
手前味噌で恐縮ですが、弊社テラスカイのコンサルティングメニューの一つとしてクラウド・オリエンテッド・アプローチ（COA）というサービスもありますので是非ご検討下さい。
（アウトプットの一例）
システム・アーキテクチャーの観点だけでなくマネジメントや業務プロセスの観点からも検討していく手法もあります。
適合性判定のプロセスで大まかな開発工数と技術要素を洗い出すことができればベストです。これにより3.の開発及び運用・サポート体制と教育計画と併せてロードマップを作成することができます。
2. システム/データ連携のアーキテクチャー
Salesforceを単体でユーザ/業務部門主導で導入する場合はともかく、全社規模で導入する場合は、必ずと言ってよいほど、既存システムとの連携が課題になります。よくあるケースはCRMでSalesforceを使う場合も基幹システムとの間で顧客データなどのマスター系DB連携、商談成約から受発注のためのデータ連携などが挙げられます。
機器構成等をSalesforceで見積作成する場合は、製品マスターなども連携対象になるかもしれません。また連携がバッチ的な仕組みだけでなくリアルタイムな仕組みで必要になるかもしれません。より簡易で連携数も少ない場合は個別にJava等でAPIを利用し連携プログラムを開発、連携することも一つの方法ですが、将来アプリケーション数も増え、連携対象のアプリケーション・処理も増えていくことが予測されている場合には、連携用のサーバー/基盤を利用することを検討した方が良いと考えます。
既に社内にSalesforceをはじめとするクラウドシステムに対して、連携可能なアダプターを持つETLやEAIがある場合はそれを利用することも一手段ですし、社内で標準の連携基盤が無い場合は新たに導入することも検討すべきと思います。
これもまた手前味噌で恐縮ですが、サーバー導入型であればData Spider/DC Spider、クラウド型であればSky On Demand/Data Spider Cloudが実際の連携事例も多数ありお薦めできます。
実際には1.のアプリケーションのSalesforce適合性判定と優先度、ロードマップで検討するアプリケーション群をベースにして、どのようなタイミング・方向・件数・方式、で連携が必要かを見極めて適切なETL/EAIツールを選択することが必要です。
重要なことは具体的な連携方式をパターン化して連携アーキテクチャーを標準化しアプリケーション、連携インターフェースが増える度に個別新規に連携開発するのではなく、策定した標準パターンを適用しながら連携ジョブ、プロセスを効率的に開発・実行できる状態にすること、また将来の保守工数の低減にも寄与できるような状態にすることです。
そのためには連携のアーキテクチャー設計時に知見のあるエンジニアの支援も必要になってくると思います。
また、連携のアーキテクチャーを考える上では、ユーザ情報管理、認証方式についても考慮することが必要です。
既にActive Directory (AD)などの仕組みを利用してシングルサインオンを実現されているケースもあると思います。この場合に、Salesforceにログインする際にSAMLなどの仕組みを通じてシングルサインオンの仕組みを実装するかどうかも、連携のアーキテクチャー全般を検討する上で必要な要素となります。
また、ユーザ情報の登録・更新・管理を2重、3重にシステム毎に実施する手間を最小化するためにも、ユーザ情報自体を連携対象にしてADからSalesforceに自動連携することが必要かどうかについても検討しておく必要があると思います。
3. 開発及び運用・サポート体制と教育計画
複数/多数のアプリケーションをSalesforce上に構築する場合、それらを並行して開発するのか、或いはどこまで並行して開発するのか、優先順位を元に、順次開発していくかについて、1. アプリケーションのSalesforce適合性判定と優先度、ロードマップで述べたマスタースケジュールに盛り込みます。
とはいえ、これはそれらのアプリケーションを開発するリソースの手当があってこそ実現できる内容です。当然のことながらアプリケーションを検討・分析する際に各アプリケーション開発に必要な業務/技術スキル要素、ボリューム・難易度から見た工数等を、自社もしくは外部の開発ベンダーのリソース状況を勘案してロードマップと重ね合わせて調整していく必要があります。
また近々は難しいとしても、将来的に可能な限り社内のリソースを活用していきたいと考えられている場合は、ロードマップに沿って要員・体制と必要な研修計画と研修受講・スキル習得状況のモニタリング方法も検討しておきたいところです。
また、一旦アプリケーションが稼働しそれがどんどん増えてくると、それに対して利用ユーザからの問合せや改修要望も必ず発生しますので保守・改修のプランと併せてそれに対応するための体制・窓口として専任の窓口を設けること、またエンドユーザ－社内開発/保守チーム－外部開発ベンダーとの間やセールスフォース社も含めたコミュニケーションプランを決めておく必要があると思います。
まだアプリケーションが動く前からプランするのは大変かもしれませんが、アプリケーションが増え、規模も大きくなってくると社内でも専任体制をとることも必要になってくると思いますので早いタイミイグから検討頂きたい内容です。
4. 開発・運用における標準/共通化、ガイドライン
SalesforceがSaaS、PaaSとしていかに開発者、システム管理者に優しく容易なシステムだとしても開発を拡げていく場合は、設定/開発規約、UI規定、プロジェクト規約等最低限定めておくべきかと思います。
開発作業を、一人や非常に少人数なチームで未来永劫継続できることも無いと思いますし、状況により外部のベンダー企業（1社だけに限定できるとも限らない）もSalesforceの組織に入り、作業を実施されることもあると思いますので、少なくとも後から見た際にも一貫したわかり易いものにしておきたいものです。
全社で複数/多数のアプリケーションを開発する場合は特にあてはまると思います。また利用ユーザが多い、同時利用数も多い、扱うデータ量も多くパフォーマンスにも注意が必要、処理が複雑、バッチ的な動きや連携も実施する、という要素が増えれば増える程、Salesforceのガバナ制限や大規模・大量データ利用時のベストプラクティスを意識しておく必要があります。
ここは前述しました「COEってご存知ですか？」や、Salesforceのエキスパート/アーキテクトの支援も活用しながら、社内でのガイドラインやべからず集などをまとめていくことが有用だと思います。
また、仮にアプリケーションの多くがSalesforceの標準機能をドラック＆ドロップだけでカスタマイズするだけで済んだとしても、ユーザ規模もアプリケーション規模も大きくなる場合、いわゆるセキィリティモデルの設計とガイドラインは最初のタイミングでしっかり決めておきたいところです。
ロール、公開グループ、プロファイル、権限セット、共有ルールを後から変更することは規模が大きくなる程大変ですし、パフォーマンスへの影響や組織変更時の影響も事前に意識して設計しておかないと、予期しない対応に大きなワークロードを割くことにもなりかねません。
さらにこれも言わずもがなかもしれませんが、開発を行う場合に利用する環境やSalesforceにコードをリリースする際のツール、手順も個々ばらばらでなく、
Eclipseを使うのか、Antを使うのか、変更セットを使うのか等、開発～テスト～本番リリースに至るライフサイクルの中で、SandBoxをどう使うのかという取り決めも、併せてガイドラインを策定しておき後追いで問題をフォローする手間を減らすことも重要です。
以上の点（アプローチ）を個々別々に進めていくのではなく、導入当初に分類・タスク化して整理しておき、計画的に進めていくことをお薦めします。
おわりに
今回はSalesforceを全社の開発・アプリケーション基盤として導入する際に考慮しておいた方が良いと思われるいくつかのポイントにつき主にシステムサイドの観点から書いてみました。
実際の状況では、一度に全てを策定して進めることは難しいと思いますし、最初から社内のリソースだけで対応するのは難しいかもしれません。しかし、外部のベンダー企業からの支援を仰いだとしても、一旦アプリケーションの適合性判定基準、連携方式・アーキテクチャーの定義、開発～運用・サポート体制の構築、開発・運用についての標準化・ガイドライン策定等々のベースを作っておければ、策定した基準・方針をユーザ企業様内でメンテナンス、拡張していくことも決して無理な話では無いと思います。
チャレンジも多いと思いますが、私共もクラウドインテグレーターとして少しでもご支援できる所があればと考えておりますので、その際は是非お声掛け下さい。
