分散クラウドの開発・運用を推進する“組織体制の在り方”：分散クラウドのアーキテクチャと開発・運用体制の考え方（2/2 ページ）

[酒井勇輔，株式会社日立ソリューションズ]

共通基盤の活用を促進する組織体制

　これらの課題に対応するには、アプリケーションチームとプラットフォームチームの間を取り持つ「イネ―ブリングチーム」と「コンサルティングチーム」を置くと良い。

　イネーブリングチームは、一定期間アプリケーションチームに加わり、チームが自立して共通基盤を活用できるように支援する。アプリケーションチームの困りごとに耳を傾け、個別の課題解決を支援する「執事」のような役割だ。イネーブリングは「可能にする」という意を持っており、「共通基盤を活用可能にする」と解釈できる（注1）。

　コンサルティングチームは共通基盤を有効に活用するためのナレッジを集約・蓄積し、組織全体に周知する。全てのチームが知るべきナレッジを周知する「広報」的な役割だ。

　これらのチームはどちらも、共通基盤を活用するための支援を提供するため、区別されずに「サポートチーム」という一つのチームとして扱われることも多い。一つのチームとして同一視しても問題はないが、支援対象のアプリケーションチームが増えるにつれて課題が生じる。サポートチームの認知負荷が高まり、「執事と広報」の両立が困難になるからだ。

　イネーブリングチームがアプリケーションチームを支援しつつ、そこで出た課題や要望をプラットフォームチームにフィードバックすることで、プラットフォームチームは本質的に改善すべき課題にフォーカスできる。

　コンサルティングチームが基盤の活用ノウハウを周知することで、アプリケーションチームの数がより増加してもプラットフォームチームとイネーブリングチームの負荷が高まるのを抑止できる（図3）。

　このように各チームが補完関係を築き、アプリケーションチームがビジネス価値の創出に注力できる状況を生み出すことが重要だ。

図3　役割分担によるコミュニケーションコストの低減（筆者作成）

チーム間の相互理解とコラボレーション

　4つのチームの違いを整理したものが図4だ。ここで示した各チームの名称は企業によって異なる場合も多い。例えばイネーブリングチームは「SRE」（Site Reliability Engineering）と呼ばれたり、コンサルティングチームは「CoE」（Center of Excellence）と呼ばれたりする。

　また、一つの部門が複数の役割を兼務するケースもある。組織名称や部門構成ではなく、各チームが担うミッションや提供価値、価値のつながりを明確にすることが重要だ。

　4つのチームは異なるミッションを持っているが、チームの目的だけに集中してはチーム間のコラボレーションが生まれない。各チームが強みや弱みを持つが、コラボレーションがない場合は強みよりも弱みが目立ちやすい。互いのチームのミッションや強み、弱みをよく知る必要がある。

図4　共通基盤を取り巻く4つのチーム（筆者作成）

　企業の利益に直接的に関わる機能に関して、前述のような役割分担の考え方は既に体系化している企業が多い。営業機能におけるインサイドセールスやカスタマーサクセスなどの役割分担がその例だ。

　これが組織内の共通基盤の話になると、コストセンターとして捉えられてしまうこともあり、整理がおざなりになるケースも多いと筆者は考える。分散クラウドのような先進的なプラットフォーム技術は、単なるコスト削減の手段ではなく、企業のDX（デジタルトランスフォーメーション）推進の基盤になるため、推進体制の明確化が重要だ。

まとめ

　本稿で解説したものはあくまで“現時点”で考え得るものであり、今後の技術トレンドによっては望ましい組織体制や各チームが備えるべきスキルセットが変化する可能性がある。

　生成系AI（人工知能）に対する注目が高まっている状況を鑑みると、プラットフォームチームが汎用的なAIモデルを基盤に組み込み、APIとして機能提供し、アプリケーションチームはそのAPIを活用する体制になっていくことは想像に難くない。プラットフォームチームはAIに関する基本的なスキルを備える必要があるが、そのような人材を集めることは容易ではない。

　新たな技術を備えた人材を獲得するためにも、組織のリーダーは各チームの役割や提供価値を言語化し、その組織で働くことの動機付けを行うことが重要になる。本記事で述べた組織体制の整理が、その一助となれば幸いだ。

　分散クラウドについて、第2回の記事を執筆した日立ソリューションズの工藤がクラウド運用技術者向けイベント「Cloud Operator Days Tokyo 2023」で「オンプレミスとクラウドの架け橋！〜分散クラウドのアーキテクチャを探る〜」と題して講演を予定している。こちらも合わせて聴講頂ければ幸いだ。

注1：参考「Team Topologies」