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

分散クラウドを活用してビジネスを加速させるためには4つのチームが必要だ。それぞれの役割を把握して今後に生かそう。

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

　本連載は分散クラウドの要素や活用パターンを、クラウドシフトやアーキテクチャ、組織構成の観点から紹介している。前回（第2回）は分散クラウドの活用領域について、アーキテクチャのパターンを整理しながら解説した。

　第3回となる本稿は、分散クラウドで稼働するアプリケーションの開発や運用を効果的に実施するための組織体制について解説する。分散クラウドに限った話ではないが、新たな技術を導入しても、活用する組織体制がなければメリットは享受できない。

この連載について

　本連載は、企業が抱えているクラウドシフトに関する課題を解決するために、エッジコンピュータを活用した新たな手法がなぜ効果的なのかを解説します。

筆者紹介：株式会社日立ソリューションズ　酒井勇輔

技術革新本部 生産技術部 Cloud CoE 技師

アプリケーション共通基盤の設計・運用や、基盤上でのアプリケーション開発支援に従事。近年は、アプリとインフラの横断領域（いわゆる DevOps／SRE）に関する組織設計・プロセス設計が主な関心領域。

分散クラウドにおけるセルフサービス型の共通基盤モデル

　組織体制を解説する前に、「分散クラウドは組織の共通基盤として扱われることが多い」点を説明しておきたい。

　連載第2回で、分散クラウドの構成要素の一つに「単一のコントロールポイント」があると説明した。アプリケーションの実行環境がさまざまな拠点に分散していても、それらを単一のコントロールポイントから集中的に参照や操作できることが分散クラウドの特徴だ。これによって、アプリケーションが稼働する各拠点はパブリッククラウドでいうリージョンのように扱える。

　この特徴を生かすには、分散クラウドを組織の共通基盤として扱い、複数のアプリケーション開発・運用部門（以下、アプリケーションチーム）が基盤の利用者として共用する形態が必要だ。分散したアプリケーションに対し、異なる拠点ごとに基盤の提供部門（以下、プラットフォームチーム）が存在するのでは従来のオンプレミスと変わらなくなってしまうためだ（図1）。

図1　共通基盤としての分散クラウド（筆者作成）

　分散クラウドを組織の共通基盤にするには「インフラリソースの調達や変更といった手続きをパブリッククラウドと同等に近づけること」「セルフサービス型の社内サービスとして各アプリケーションチームに提供されること」が望ましい。この思想はプラットフォーム・エンジニアリングとして注目を集めている。

　このようなセルフサービス型の共通基盤を組織内に構築すると、以下のメリットを得られる。

• アプリケーションを集約することで、インフラリソースの維持コストを低減
• インフラリソースを調達するリードタイムが短くなり、アジリティが向上
• 企業固有のセキュリティコンプライアンス要件を組み込むことで、準拠漏れのリスクや要件対応の手間を低減

セルフサービス型の共通基盤モデル採用時に発生する課題

　セルフサービス型の共通基盤を運用する場合は以下のような課題も発生し得る。

• アプリケーションの個別要件への対応が困難
• アプリケーションチームとプラットフォームチームの間の責任分界点が曖昧（あいまい）になりやすい
• セルフサービス化できない部分や、セキュリティコンプライアンス統制のためのコミュニケーションコストがボトルネックになりやすい

　これらの課題は基盤で稼働するアプリケーションが増えると顕在化しやすい。運用初期は基盤で稼働するアプリケーションが少なく、アプリケーションチームとプラットフォームチームは密にコミュニケーションをとれるためだ。

　アプリケーションチームの数が増えると、各チームからプラットフォームチームに対する異なる要望が増え、プラットフォームチームはどの要望に優先的に応えるべきか判断できなくなる。加えて、アプリケーションで生じた不具合について、原因切り分けのためのコミュニケーションに忙殺されるようになる。また、セルフサービス型の機能提供ができていない部分の申請や、セキュリティコンプライアンス要件の適応についても負担が増え、アジリティというメリットが失われる（図2）。

図2　コミュニケーションコストに起因する共通基盤の課題（筆者作成）