チーム構造を成熟させる
あらゆるクラウド導入の取り組み中、クラウドのすべての役割に誰かが任命されます。 これらの割り当てとチーム構造は、有機的に発展できます。または、組織は定義されたチーム構造に合わせて意図的に設計することもできます。
クラウド実装チームにとって、現在のチーム構造がどのようなものであるか、および最終的にどのような構造にしたいかを理解することが重要です。 繰り返しになりますが、この種の変更は、時間、実験、ネゴシエーションを要する取り組みです。
このビデオでは、組織の成熟度のさまざまな段階における一般的なチーム構造の概要を確認できます。
組織構造は、次の一般的な成熟度モデルのように変化する傾向があります。
次の図は、これらの構造の概要を一般的な成熟段階に基づいて示したものです。 ここに示す例から、運用上のニーズに最も即した組織構造がわかります。
ほとんどの企業は、"クラウド導入チーム" 程度の規模からスタートします。 ただし、MVP のベスト プラクティスにより近い組織構造を確立することをお勧めします。
クラウド導入チームのみ
クラウド導入のあらゆる取り組みの中核となるのがクラウド導入チームです。 このチームは、導入を可能にする技術的な変更を推進します。 導入作業の目的に応じて、このチームは、技術および業務に関する幅広いタスクを処理するスキルを持っている場合があります。
小規模または早期の導入作業の場合、このチームはメンバーが 1 人だけのこともあります。 大規模な作業または後半のステージの作業では、6 人程度のエンジニアで構成されるクラウド導入チームが複数存在することも一般的です。 規模やタスクに関係なく、どのようなクラウド導入チームも、ソリューションをクラウドにもたらします。
組織によっては、このチームは十分な組織構造である可能性があります。 チームの構造、構成、機能の詳細については、クラウド導入チームに関する記事を参照してください。
警告
クラウド導入チーム (1 つまたは複数) だけで活動することは、アンチパターンと見なされるので避ける必要があります。 少なくとも、MVP のベスト プラクティスを検討してください。
MVP のベスト プラクティス
クラウド導入の取り組み全体のバランスを取るために、2 つのチームを用意することをお勧めします。
- クラウド導入チーム: 技術的なソリューション、ビジネスの整合性、プロジェクト管理、導入されるソリューションの運用について責任を負います。
- クラウド ガバナンス チーム: プラットフォームの成熟、プラットフォームの運用、ガバナンス、自動化について責任を負います。 このチームは、採用されたソリューションの卓越性を確保することに専念しています。
この実証されたアプローチは、持続可能でない場合があるため、MVP と見なされます。 各チームは、RACI (Responsible、Accountable、Consulted、Informed (実行責任者、説明責任者、協業先、報告先)) チャートで説明されているように、何役もこなします。
次のセクションでは、完全にスタッフが配置された実証済みの組織構造について説明します。 また、適切な構造を組織に合わせる方法についても説明します。
中央 IT チーム
導入規模が拡大するにつれて、クラウド ガバナンスチームで複数のクラウド導入チームからのイノベーションの流れのペースを維持することが困難になる可能性があります。 これが特に当てはまるのは、コンプライアンス、運用、またはセキュリティの要件が厳しい環境です。
この段階で、企業がクラウドの責任を既存の中央 IT チームにシフトすることは一般的です。 そのチームがツール、プロセス、人を再評価して大規模なクラウド導入をよりよくサポートできる場合、大きな価値を生み出すことができます。 運用、自動化、セキュリティ、管理の分野の専門家が効果的な運用のイノベーションを推進し、中央 IT チームを最新化することができます。
残念ながら、中央 IT チームは、組織の成熟度で最もリスクの高いフェーズの 1 つになる可能性があります。 中央 IT チームは、成長に対する強い考えを持つ必要があります。 クラウドを成長と適応の機会と見なす場合、プロセス全体で大きな価値を提供できます。 クラウド導入を既存のモデルへの脅威と見なす場合、クラウド導入チームと、それがサポートするビジネス目標の障害になる可能性があります。
中央の IT チームの中には、クラウドをオンプレミスのアプローチに強制的に適合させようとして数か月、または数年さえも費やして、マイナスの結果しか得られないチームもあります。 クラウドに移行するために中央 IT チーム内のすべてを変更する必要はありませんが、大きな変更が必要になります。 中央 IT チームが変化することに抵抗を示す場合、この成熟期はすぐに文化的なアンチパターンになる可能性があります。
サービスとしてのプラットフォーム (PaaS)、DevOps、または運用のサポートが少なくて済む他のソリューションに重点を置いているクラウド導入計画では、成熟のこの段階で価値を見い出せる可能性は低くなります。 このような種類のソリューションは、IT を一元化しようとするときに妨害またはブロックされる可能性が最も高くなります。
CCoE のように、成熟度が高いほど、このような変革の取り組みに対して肯定的な結果が得られる可能性が高くなります。 クラウドと CCoE での中央 IT チームの違いを理解するには、「クラウドのセンター オブ エクセレンス」を参照してください。
戦略的連携
クラウド導入への投資が拡大し、組織がビジネス価値を見出し始めるにつれて、多くの場合、ビジネス関係者はより積極的に関与するようになります。 定義されたクラウド戦略チームは、クラウド導入への投資を最大にするため、これらのビジネス利害関係者を調整します。
IT 主導のクラウド導入の取り組みの結果として有機的な成熟が起きたとき、ガバナンスまたは中央 IT チームは戦略的な整合より優先されます。 クラウド導入作業がビジネスによってリードされるときは、運用モデルと組織に先に焦点が当てられる傾向があります。 可能な限り、プロセスの早い段階でビジネス成果とクラウド戦略チームを定義してください。
運用での連携
クラウド導入作業からのビジネス価値を実現するには、安定した運用が必要です。 クラウドでの運用には、新しいツール、プロセス、スキルが必要になる場合があります。 ビジネス成果を達成するために安定した IT 運用が必要な場合は、定義されたクラウド運用チームを追加することが重要です。
IT 運用の既存のロールによって、クラウド運用を提供できます。 ただし、クラウド運用は、IT 運用外の関係者に委任される場合があります。 管理されたサービス プロバイダー、DevOps チーム、およびビジネス ユニットの IT では、クラウド運用に関連する責任について、IT 運用により提供されるサポートとガードレールがあると想定されることがよくあります。 この構造は、DevOps または PaaS のデプロイに重点を置くクラウド導入作業でますます一般的になっています。
クラウドのセンター オブ エクセレンス
最も成熟度の高い状態では、CCoE によって、最新のクラウドファースト運用モデルを中心にチームが調整されます。 このアプローチでは、ガバナンス、セキュリティ、プラットフォーム、自動化などの中央 IT 機能が提供されます。
この構造と中央 IT チーム構造の主な違いは、セルフサービスと民主化に大きな重点が置かれることです。 この構造のチームは、可能な限りコントロールを委任することを目的として編成されます。
クラウド ネイティブ ソリューションに対してガバナンスとコンプライアンスのプラクティスを連携させることで、ガードレールと保護のメカニズムが作成されます。 中央 IT チームのモデルとは異なり、クラウドネイティブ アプローチでは、イノベーションが最大化され、運用上のオーバーヘッドが最小化されます。 このモデルを採用するには、IT プロセスを最新化するために、ビジネスと IT リーダーシップの間で相互に合意する必要があります。 このモデルが有機的に発生する可能性は低く、多くの場合、経営陣によるサポートが必要です。