はじめに
皆さん、こんにちは。今回でテックブログ3回目登場の山田です。皆さんはCOEってご存知でしょうか？初めて聞いた、言葉は聞いたことがある、もちろん知っている等々、様々な反応があるかもしれません。今日はそんなトピックについて少し書いてみたいと思います。
COEとは
既にご存知の方には繰り返し、釈迦に説法、になるかもしれませんが、COEはCenter Of Excellenceの略です。この言葉の由来は1940～50年代にまで遡り、米国カリフォルニア州のスタンフォード大学で当時多くの優秀な学生が東海岸へ流出してしまうことを防ぐため、全米から著名な教授・スタッフを呼寄せ、学究拠点の中心とする施策から来ているようです。その後、様々な大学や研究機関での施策・拠点として発展、企業においても優秀・有識なリソースを集約し組織運営を向上化・効率化するという形で適用され、ITの分野でも使われるようになったと理解しています。要は、会社の中でシステム化を進めていく際に多くのプロジェクト、タスクが走ると思いますが、その中で専門性を持った人材を組織横断的に配置し、ベストプラクティスを集約、適用、運用することにより、成功裡、効率的にシステム導入していくための仕組み・組織、と言うとわかり易いかもしれません。
また、COEのモデルにもいくつかタイプがあるようですが、ここでは、それぞれにつき解説するのは割愛させて頂き、その主な役割と重要性をSalesforceの導入の中でどう位置づけられるかにつきフォーカスしたいと思います。
COEの役割と重要性
さて、それではSalesforce（ここをAWSや他のサービスに置き換えてもある程度同様に論じられるとは思います）導入におけるCOEにはどんな役割が求められるのでしょうか。またそれが重要であると考えられるのは何故でしょうか。当然一つの定義、回答には留まりませんが、あくまで私自身が今までSalesforceのプロジェクトを通して経験したこと、感じたことを踏まえて書くとこうなります。
COEの組織における役割（サンプルイメージ図）
プランニングのところとリリース以降も入っているのは少し広義かもしれませんが、プランフェーズでビジネスプロセス、フローを検討したり、システムのアーキテクチャーの青写真を描く必要性があること、またリリース以降の運用・サポートへのフォローアップ、アプリケーション/システムの整合性を保った上で新規プロジェクト、アプリケーションをインプリすることもあると思いますのでスコープに入れています。
ここで強調しておきたいのはCOEというのは１個人で構成するのではなく、複数のリソースで構成するグループ、組織になるということです。また、当然Salesforceを扱うベンダー/コンサルティング/インテグレータからの技術者がそのプラットフォーム、ソリューション、技術を一番良く知っているという観点から重要な役割を担いますが、組織の中心はお客様サイドにある（あるべき）という考えです。これは単にシステムの設計・開発からテスト、リリースという観点だけではなく、ビジネス・業務そのもののプロセス、フロー設計が絡んでくる、トレーニングや運用・保守も絡んでくる、中長期の複数のシステム構築・戦略に絡んでくることからユーザ主導であるべきと考えるからです。
さらにCOEは個々の"プロジェクトチーム"に属するのではなく、プロジェクトを横断・包括的に見る"プログラムチーム"になるということです。業務、システムの設計・開発、全体もしくはシステム間連携のアーキテクチャー、テスト、リリース、トレーニング、サポート・・・一連のプロジェクトにおける要素を個々ばらばらに遂行するのでは無く、複数のプロジェクト/アプリケーション間の整合性、標準化・共通化、ベストプラクティスの蓄積と展開・適用を担うことになります。これには各要素に精通した要員（スペシャリスト）を選出、集約しないと実現できないでしょう。
原点が欧米にある概念ですので、やはり外資系企業ではCOEを実際に置いているケースが多いと思います。導入時に、既にお客様内でCOEチームとして数人配置され、全体のシステムアーキテクチャーやビジネスプロセスを見ているというケースもありました。また全社でSalesforceをこれからプラットフォームとして利用するのでこれを機会にCOEを編成して準備するというお客様もありました。Salesforceの技術者は、まさにこういうCOEチームの一員となって個々のプロジェクトを実施するチームをさらに横串で見てガバナンスとベストプラクティス提供を支援する役割を期待されると思います。
ここまでの説明で、COEが何故重要なのかはご理解頂けるのではと思いますが、その重要性をもう少し技術視点から説明します。
Salesforceを会社のシステム/アプリケーションプラットフォームとして利用する時、システム/アプリケーション規模・数は大きくなっていくと思います。このような環境の中、各プロジェクトチーム毎にプロジェクトマネージャー、プロジェクトチーム、ユーザが個々好きなように開発していったらどうなるでしょうか。各プロジェクトチームで最適なアプリケーションを開発したとしても特に同一プラットフォーム上で複数のアプリケーションが稼働する場合、アプリ間で不整合が発生したり、重複するような機能を開発してしまうかもしれません。またどこかで経験した問題への対処方法を他のプロジェクトに活かせないかもしれません。さらにSalesforceはクラウドサービスとしてのメリット非常に大きいとはいえマルチテナント型であるが故に、インスタンス、組織で大量のトランザクションを同時並行的に処理するためにガバナ制限も設けられています。ガバナ制限を複数アプリケーションが稼働する中で意識し、設計・運用する、べからず集を徹底する、ベストプラクティスをプロジェクト横断で共有・適用することが、安定したシステム開発・運用に繋がることになります。
どんな時に必要？
ここで再度まとめると、以下のケースに該当する場合はCOEを検討した方が良いと考えます。
- Salesforceを全社のプラットフォームとして導入、利用する
- 複数（多数）のアプリケーションを開発、導入する
- 継続的にアプリケーションを増やしていく、更新していく
- プロジェクト及びプロジェクトチームが複数走る
まだあるかもしれませんが、この辺りで留めるとしても、結果として
- 標準化・共通化、プロジェクト/開発/技術ガイドライン、ガバナンスの策定が求められる
- 課題解決の蓄積とベストプラクティスの提供が求められる
- 複雑な技術要素に対する対応が求められる
ということからの必然性です。
考慮点
COEに専門性が求められるのはもちろんですが、COEが必要になるケースが必然的にシステム/アプリケーション規模、ユーザ規模、タスクボリュームが大きくなることから、併せて専任制も求められると思います。人がいないからパートタイムでということになると、回らない可能性が高くなると思います。また、上記の必要ケースに将来なる（する）と最初からわかっている（予定している）場合は、できるだけ初期のタイミングで組織するのが良いと考えます。あとからアプリケーションに不整合や制限が顕在化してから作り直す・改修する方がコストもかかってしまうケースも往々にしてあり得ると思います。
おわりに
今やクラウドシステム/サービスが会社の中での主要なシステムとして採用、活用されるケースが加速度的に増えてきていると思います。このような環境の中、単なるスモールスタートとしてのSalesforceの導入ではなく、また単にCRM領域のSalesforceの導入だけでもなく、様々なアプリケーション領域をカバーするアプリケーション基盤としてSalesforceを導入・開発していく際に、システム/サービスの特性を理解し、より効率的、長期的な視点で全体の技術、アーキテクチャー、仕組みを束ねるCOEの必要性がさらに高まっていくと思います。COEとして、プロジェクト横断で、ある種お目付け役/スペシャリストとしてお客様を支援あるいはお客様と共に動く"アーキテクト"への要求・需要もさらに高まっていくのではないでしょうか。
