チーム構造を成熟させる

あらゆるクラウド導入の取り組み中、クラウドのすべての役割に誰かが任命されます。 こうした役割分担やチーム構造は有機的に発展する場合もあれば、定義されたチーム構造に合わせて意図的に設計される場合もあります。

導入のニーズが拡大すると、バランスと構造に対するニーズも高まります。 組織のさまざまな成熟段階での一般的なチーム構造の概要を確認するには、このビデオをご覧ください。

次の図は、これらの構造の概要を一般的な成熟段階に基づいて示したものです。 ここに示す例から、運用上のニーズに最も即した組織構造がわかります。

組織構造は通常、次に示す一般的な成熟モデルを進んでいきます。

1. クラウド導入チームのみ
2. MVP のベスト プラクティス
3. 中央 IT チーム
4. 戦略的連携
5. 運用での連携
6. クラウドのセンター オブ エクセレンス (CCoE)

ほとんどの企業は、"クラウド導入チーム" 程度の規模からスタートします。 しかし、MVP のベスト プラクティス構造により近い組織構造を確立する方法をお勧めします。

クラウド導入チームのみ

クラウド導入のあらゆる取り組みの中核となるのがクラウド導入チームです。 このチームは、導入を可能にする技術的な変更を推進します。 このチームには、導入作業の目標に応じて、技術的なタスクやビジネス タスクに幅広く対応する多様なチーム メンバーが集められます。

小規模または早期の導入作業の場合、このチームはメンバーが 1 人だけのこともあります。 大規模な作業または後半のステージの作業では、6 人程度のエンジニアで構成されるクラウド導入チームが複数存在することも一般的です。 規模やタスクにかかわらず、どのクラウド導入チームにも共通しているのは、クラウドにソリューションをオンボードするための手段を提供するということです。 組織によっては、この組織構造で十分という場合もあります。 クラウド導入チームに関する記事では、クラウド導入チームの構造、構成、役割について、さらに深い分析情報を得ることができます。

警告

クラウド導入チーム (1 つまたは複数) だけで活動することは、アンチパターンと見なされるので避ける必要があります。 少なくとも、MVP のベスト プラクティスを検討してください。

ベスト プラクティス: 実用最小限の製品 (MVP)

2 つのチームを設けて、クラウド導入作業のバランスを取ることをお勧めします。 この 2 つのチームは、導入作業全体を通してさまざまな機能を担当します。

• クラウド導入チーム: このチームは、技術的なソリューション、ビジネスの整合性、プロジェクト管理、導入されるソリューションの運用について責任を負います。
• クラウド ガバナンス チーム: クラウド ガバナンス チームは、クラウド導入チームのバランスを取るために、導入されるソリューションの卓越性を確保することに専念します。 クラウド ガバナンス チームが、プラットフォームの成熟と運用、ガバナンス、および自動化について責任を負います。

この実証されたアプローチは、持続可能でない場合があるため、MVP と見なされます。 "実行責任、説明責任、助言、通知" (RACI) チャートで示されるように、各チームが多くの役割を担います。

以下の各セクションでは、すべてのチームに人員が配置された、実証された組織構造と、組織に適した構造にするためのアプローチについて説明します。

中央 IT チーム

導入規模が拡大するにつれて、クラウド ガバナンスチームで複数のクラウド導入チームからのイノベーションの流れのペースを維持することが困難になる可能性があります。 これが特に当てはまるのは、コンプライアンス、運用、またはセキュリティの要件が厳しい環境です。 この段階で、企業がクラウドの責任を既存の中央 IT チームにシフトすることは一般的です。 大規模なクラウド導入をサポートするために、そのチームがツール、プロセス、担当者を再評価できる場合は、中央 IT チームを含めることで、大きく価値を高めることができます。 中央 IT チームを最新化するための運用、自動化、セキュリティ、管理の分野の専門家は、運用に関する効果的イノベーションを推進できます。

残念ながら、中央 IT チーム フェーズは、組織成熟度の中で最もリスクの高いフェーズの 1 つになる場合があります。 中央 IT チームは、成長に関して強い決意を持って参加する必要があります。 チームがクラウドを成長と適応の機会として見た場合、プロセス全体を通して高い価値を提供できます。 それに対し、中央 IT チームがクラウドの導入を主に既存モデルに対する脅威として見た場合、中央 IT チームは、サポートすべきクラウド導入チームと事業目標に対する障害になります。 中央 IT チームによっては、何か月どころか何年にもわたってクラウドをむりやりオンプレミスのアプローチに合わせようとして、結局悪い結果しか得られなかったこともあります。 クラウドではすべての変更を中央 IT チーム内で行う必要はありませんが、重要な変更を行うことは必要です。 変更に対する抵抗が中央 IT チーム内に蔓延している場合、成熟度のこのフェーズはすぐに文化的なアンチパターンになります。

サービスとしてのプラットフォーム (PaaS)、DevOps、または他の運用サポートをあまり必要としないソリューションに大きな重点が置かれているクラウド導入計画では、この成熟度のフェーズの間に価値が見いだされる可能性は低くなります。 逆に、この種のソリューションでは、IT を集中化する試みによって阻害またはブロックされる可能性が最も高くなります。 クラウドのセンター オブ エクセレンス (CCoE) のように高度に成熟している場合は、その種の変革作業に対して肯定的な結果が得られる可能性が高くなります。 クラウドと CCoE での中央 IT チームの違いを理解するには、「クラウドのセンター オブ エクセレンス」を参照してください。

戦略的連携

クラウド導入への投資が拡大し、ビジネス価値が実現するにつれて、ビジネス上の利害関係者の関わりがいっそう深くなっていくのが普通です。 定義されたクラウド戦略チームは、クラウド導入投資によって実現される価値が最大になるように、それらのビジネス上の利害関係者を調整します。

成熟が有機的に起こる場合は、IT 主導のクラウド導入作業の結果として、戦略的調整よりもガバナンスや中央 IT チームが先行します。 クラウド導入作業がビジネスによってリードされるときは、運用モデルと組織に先に焦点が当てられる傾向があります。 可能な限り、プロセスの早い段階でビジネス成果とクラウド戦略チームを定義してください。

運用での連携

クラウド導入作業からのビジネス価値を実現するには、安定した運用が必要です。 クラウドでの運用には、新しいツール、プロセス、スキルが必要になる場合があります。 ビジネスの成果を達成するために IT を安定して運用する必要がある場合は、次の図に示すように定義済みのクラウド運用チームを加えることが重要です。

クラウドの運用は、既存の IT 運用の役割から提供できます。 ただし、クラウド運用が IT 運用の外部に委託されることは珍しくありません。 管理されたサービス プロバイダー、DevOps チーム、およびビジネス ユニットの IT では、クラウド運用に関連する責任について、IT 運用により提供されるサポートとガードレールがあると想定されることがよくあります。 これは、DevOps または PaaS のデプロイに重点を置いたクラウド導入の作業において、ますます一般的になっています。

クラウドのセンター オブ エクセレンス

成熟度が最も高い状態では、クラウドのセンター オブ エクセレンスにより、最新のクラウド優先の運用モデルを中心にチームが配置されます。 このアプローチでは、ガバナンス、セキュリティ、プラットフォーム、自動化などの中央 IT 機能が提供されます。

この構造と中央 IT チームの構造の主な違いは、セルフサービスと民主化に重点が置かれている点です。 この構造のチームは、可能な限りコントロールを委任することを目的として編成されます。 クラウド ネイティブ ソリューションに対してガバナンスとコンプライアンスのプラクティスを連携させることで、ガードレールと保護のメカニズムが作成されます。 中央 IT チームのモデルとは異なり、クラウドネイティブ アプローチでは、イノベーションが最大化され、運用上のオーバーヘッドが最小化されます。 このモデルを導入するには、ビジネスと IT 双方のリーダーシップによる、IT プロセス最新化に対する合意が必要になります。 このモデルは有機的に発生することは少なく、多くの場合、経営陣によるサポートが必要です。

次のステップ

特定の組織構造の成熟ステージに合わせた調整が完了したら、RACI チャートを使用して各チームで説明責任と実行責任を調整します。

適切な RACI チャートの調整