次の方法で共有


チーム構造を成熟させる

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

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

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

組織の成熟度サイクルを示す図。

組織構造は、ここで説明する一般的な成熟度モデルを通過する傾向があります。

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

ほとんどの企業は、 クラウド導入チームから始まります。 ただし、 MVP のベスト プラクティス 構造によく似た組織構造を確立することをお勧めします。

クラウド導入チームのみ

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

クラウド導入チームのみを示す図。

小規模または早期の導入作業の場合、このチームはメンバーが 1 人だけのこともあります。 大規模な作業または後半のステージの作業では、6 人程度のエンジニアで構成されるクラウド導入チームが複数存在することも一般的です。 サイズやタスクに関係なく、クラウド導入チームの一貫した側面は、ソリューションをクラウドにオンボードする手段を提供することです。 一部の組織では、これは十分な組織構造である可能性があります。 クラウド導入チームの記事では、クラウド導入チームの構造、構成、機能に関するより多くの分析情報を提供します。

警告

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

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

ベスト プラクティスを示す図: バランスを作成するための導入チームとガバナンス チームの実行可能な最小限の製品組織。

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

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

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

次のセクションでは、完全にスタッフが配置された実証済みの組織構造と、組織に適切な構造を調整するアプローチについて説明します。

中央 IT チーム

中央の 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 のデプロイに重点を置くクラウド導入作業でますます一般的になっています。

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

クラウドのセンター オブ エクセレンス (C C o E) を示す図。

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

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

次のステップ

組織構造の成熟度の特定の段階に合わせた後、 RACI チャート を使用して、各チーム全体でアカウンタビリティと責任を調整できます。