次の方法で共有

クラウドのセンター オブ エクセレンス (CCoE) 機能

  • [アーティクル]

多くの IT 組織は、ビジネスとテクノロジの機敏性を達成するという主要な目的を共有しています。 クラウド センター オブ エクセレンス (CCoE) は、組織がこの目標を追求する際に、スピードと安定性のバランスを取るのに役立つ機能です。

機能の構造

CCoE モデルには、以下の各リソース間のコラボレーションが必要です。

  • クラウド導入 (ソリューション アーキテクト)
  • クラウド戦略 (プログラム マネージャーとプロジェクト マネージャー)
  • クラウド ガバナンス
  • クラウド プラットフォーム
  • クラウド自動化

効果

この機能が正しく構成およびサポートされている場合、参加者は、変更の全体的なコストを削減し、ビジネスの機敏性を向上させながら、イノベーションと移行の作業を加速できます。 正常に実装されている場合、この機能によって市場投入までの時間を顕著に短縮できます。 チームの訓練が成熟するにつれて、信頼性、パフォーマンス効率、セキュリティ、保守容易性、顧客満足度などの品質指標が向上します。 こうした効率性、機敏性、品質の向上は、企業が大規模なクラウド移行作業の実装を計画する場合、またはクラウドを使用して市場での差別化につながるイノベーションを推進したい場合に特に重要です。

成功すると、CCoE モデルによって IT に大きな変化が生み出されます。 CCoE のアプローチでは、IT 部門がビジネスに対するブローカー、パートナー、または担当者の役割を果たします。 このモデルは、ビジネスと IT 資産の間の操作ユニットまたは抽象化レイヤーとしての従来の IT の見方からのパラダイム シフトです。

次の図に、この変更の例を示します。 CCoE アプローチがないと、IT 部門はコントロールと一元的な責任の提供に重点を置き、交差点の信号のように振る舞う傾向があります。 CCoE が成功している場合、IT の役割は、自由度と委任された責任に焦点が当てられているという点で、環状交差点に似ています。

Diagram that shows an analogy for a C C o E paradigm shift.

どちらの方法も有効です。これらは、責任と管理の別の見方です。 事業単位が一連のガイドラインと確立された反復的なコントロールに従いつつ自身の決定を行えるセルフサービス モデルを確立することが望ましい場合は、CCoE モデルがテクノロジ戦略に適合する可能性があります。

主な責務

CCoE チームの主要な職務は、クラウドネイティブまたはハイブリッド ソリューションを通じてクラウド導入を加速することです。

CCoE の目的は次のとおりです。

  • アジャイル アプローチを使ってモダンな IT 組織を構築し、ビジネス要件を取り込んで実装することを支援します。
  • セキュリティ、コンプライアンス、管理の各ポリシーに合致する再利用可能な展開パッケージを使用します。
  • 操作手順に従って機能的な Azure プラットフォームを維持します。
  • クラウドネイティブ ツールの使用をレビューおよび承認します。
  • 一般的に必要なプラットフォーム コンポーネントとソリューションを徐々に標準化および自動化します。

ミーティングの頻度

有機的なコラボレーションに対応し、共通リポジトリまたはソリューション カタログを通じて成長を追跡することが重要です。 自然な対話は最大化しますが、会議は最小限に抑えます。 クラウド導入チームが主催するリリース会議などの定期的な会議により、データ入力を提供します。 ただし、この機能が成熟したら、専用の会議を制限するように試みます。 各リリース計画の共有後に会議を開催して、このチームとの最小限の接点が得られます。

ソリューションとコントロール

CCoE の各メンバーは、現在の IT コントロール セットにつながった必要な制約、リスク、保護を理解する必要があります。 CCoE は、その理解をクラウドネイティブ (またはハイブリッド) のソリューションまたはコントロールに変えることによって、セルフサービスのビジネス成果を実現します。 作成されたソリューションは、さまざまな作業に対するガードレールとして機能するコントロールまたは自動プロセスの形で他のチームと共有されます。 これらのガードレールは、チームの活動をガイドしたり、移行またはイノベーションの取り組みの参加者に責任を委任したりするのに役立ちます。

次の表では、この切り替えの例をいくつか示します。

シナリオ 事前 CCoE ソリューション 事後 CCoE ソリューション
運用環境で SQL Server インスタンスをプロビジョニングする ネットワーク、IT、データ プラットフォームの各チームは、数日または数週間にわたってコンポーネントをプロビジョニングします。 サーバーを必要とするチームは、Azure SQL Database のサービスとしてのプラットフォーム (PaaS) インスタンスをデプロイします。 または、サービスとしてのインフラストラクチャ (IaaS) 資産のすべてに対して事前に承認されたテンプレートを使用して、数時間でクラウドにデプロイできます。
開発環境のプロビジョニング ネットワーク、IT、開発、DevOps の各チームは、仕様に同意し、環境をデプロイします。 開発チームは、独自の仕様を定義し、割り当てられた予算に基づいて環境をデプロイします。
データ保護を向上させるためのセキュリティ要件の更新 ネットワーク、IT、セキュリティの各チームは、保護を追加するために複数の環境にわたってネットワーク デバイスと仮想マシン (VM) を更新します。 クラウド ガバナンス ツールを使用して、すべてのクラウド環境内のすべての資産にすぐに適用できるポリシーを更新します。

ネゴシエーション

CCoE 作業の根本には、継続的なネゴシエーション プロセスがあります。 CCoE チームは、既存の IT 部門とネゴシエートして一元管理を縮小します。 このネゴシエーションにおいて、ビジネスにとってのトレードオフは、自由、機敏性、スピードであり、既存の IT チームにとってのトレードオフの価値は、新しいソリューションとして提供されます。 新しいソリューションでは、次のメリットの 1 つ以上を既存の IT チームに提供します。

  • 一般的な問題を自動化する機能
  • 一貫性の向上 (日常的な不満の低減)
  • 新しい技術的なソリューションを学んでデプロイする機会
  • 重大度が高いインシデントの削減 (必要になるすばやい修正や深夜のポケットベルへの応答義務の削減)
  • 技術的なスコープを広げて、より広範なトピックに対処する機能
  • 上位レベルのビジネス ソリューションへの参加によるテクノロジの影響への対処
  • 単調なメンテナンス タスクの削減
  • テクノロジ戦略と自動化の向上

これらのメリットと引き換えに、既存の IT 機能を次の価値にトレードすることができます。

  • 手動の承認プロセスからのコントロール感
  • 変更制御からの安定感
  • 必要で反復的なタスクの完了からの職務的安心感
  • 既存の IT ソリューション ベンダーへの忠実性に由来する調和感

クラウドを検討している健全な企業では、このネゴシエーション プロセスは、ピアと提携 IT チーム間の動的な会話です。 技術的な詳細は複雑になる場合がありますが、IT 部門が目的を理解し、CCoE の取り組みに協力的であれば、管理可能です。 IT 部門が協力的ではない場合は、CCoE 成功の実現に関する次のセクションが、摩擦の克服に役立ちます。

CCoE の成功を有効にする

このモデルを使用して先に進む前に、成長志向に対する会社の許容度と一元的な責任の解放による IT 部門の快適度を検討します。 前述のように、CCoE はコントロールと引き換えに機敏性とスピードを得ます。

この種の変更は、時間、実験、ネゴシエーションを要します。 プロセス中にはつまずいたり後退することもあるでしょうが、チームが勤勉であり続け、実験をやめさせるような要因がないのであれば、機敏性、スピード、信頼性を高めることに成功する可能性が高くなります。 最大の成功要因の 1 つは、リーダーシップと主要利害関係者からのサポートです。

主要利害関係者

IT リーダーは、最初の最も明白な利害関係者です。 IT マネージャーは重要な役割を果たしますが、このモデルを実装するには、CIO やその他の経営幹部レベルの IT リーダーのサポートが必要です。

それほど明白でないのはビジネス利害関係者のニーズです。 ビジネスの機敏性と市場投入までの時間は、CCoE の構成に対する主要な動機です。 そのため、主要利害関係者は、これらの領域に強い関心を持っています。 ビジネス利害関係者の例として、基幹業務のリーダー、財務担当幹部、経営幹部、ビジネス製品所有者があります。

ビジネス利害関係者のサポート

ビジネス利害関係者からのサポートにより、CCoE の取り組みを加速できます。 CCoE 作業のフォーカスの大部分は、ビジネスの機敏性とスピードに対する長期的な改善を中心とします。 現在の運用モデルの影響と改善の価値の定義は、CCoE に関するガイドおよびネゴシエーション ツールとして役立ちます。 CCoE のサポートを得るために、次の項目をドキュメントで確立または明確に定義することをお勧めします。

  • 期待されるビジネス成果と目標。

  • 現在の IT プロセスの問題点 (スピード、機敏性、安定性、コストの課題など)。

  • これらの問題点のこれまでの影響 (失ったマーケット シェア、機能における競合他社の利益、質の悪いカスタマー エクスペリエンス、予算の増加など)。

  • 現在の問題点と運用モデルによって阻害されているビジネス改善の機会。

  • それらの機会に関連するタイムラインとメトリック。

これらのデータ ポイントは IT に対する攻撃ではありません。 そうではなく、CCoE チームが過去から学び、現実的なバックログを確立し、改善を計画するのに役立ちます。

利害関係者からの継続的なサポートとエンゲージメント

CCoE チームは、一部の領域ではすぐに効果を示すことができますが、ビジネスの機敏性や市場投入期間などの高レベルの目標は、はるかに長い時間がかかることがあります。 成熟期には、他の IT 作業に重点を置くために、CCoE チームが弱気になったり、メンバーが引き抜かれたりするリスクが高くなります。

CCoE の取り組みの最初の 6 から 9 か月は、ビジネス利害関係者が IT リーダーシップおよび CCoE と毎月会議を行うことをお勧めします。 このような会議に正式な儀礼はほとんど必要ありません。 CCoE メンバーとそのリーダーに、このプログラムの重要性を再認識させるだけで、CCoE の成功に大いに役立つ可能性があります。

また、ビジネス利害関係者に、進捗状況と CCoE チームが経験した障害となっている問題を常に知らせることもお勧めします。 これらの取り組みは技術的な細かいことのように見えるかもしれませんが、ビジネス利害関係者は、チームが活力を失ったときや他の優先事項に気を取られているときに関与できるように、計画の進行状況を理解する必要があります。

IT 利害関係者からのサポート

IT 利害関係者からのサポートには、次のアクティビティが含まれている必要があります。

  • ビジョンのサポート: CCoE の作業を成功させるには、既存の IT チーム メンバーとのネゴシエーションがかなり必要です。

    うまくいけば、すべての IT がソリューションに寄与し、変更に満足します。 時には、既存の IT チームの一部のメンバーが、制御メカニズムの保持を希望する場合があります。 このような状況が発生した場合、IT 利害関係者による CCoE のサポートが、CCoE の成功に不可欠です。 IT 利害関係者は、適切なネゴシエーションの阻害要因を解決するために、CCoE の全体的な目標の激励と強化を行う必要があります。 まれに、CCoE の進行を維持するために IT の利害関係者も介入し、膠着状態や賛否同数を打破することが必要な場合もあります。

  • フォーカスの維持: CCoE は、リソースに制約がある IT チームにとって重要なコミットメントとなる可能性があります。

    短期的なプロジェクトから強力なアーキテクトを排除し、長期的な利益に集中すると、CCoE に属していないチーム メンバーに困難が生じる可能性があります。 IT リーダーと IT 利害関係者は、CCoE の目標に集中し続ける必要があります。 IT リーダーと IT 利害関係者のサポートにより、日常業務の中断よりも、CCoE の職務を優先することができます。

  • バッファーの作成: CCoE チームは新しいアプローチを使用して実験します。

    新しいアプローチの一部は、既存の運用または技術上の制約とうまく整合しません。 実験が失敗した場合、CCoE チームは他のチームからのプレッシャーを受けたり、糾弾されたりする可能性があります。 "早い失敗" の学習機会の結果について CCoE チームを励まし、余裕を持たせることが重要です。 チームに成長志向に対する責任感を持たせ、これらの実験から学んでより優れたソリューションを見つけられるようにすることも同様に重要です。

次のステップ

CCoE モデルには、クラウド プラットフォーム機能とクラウド自動化機能が必要です。 次の手順は、複数のクラウド プラットフォーム機能を連携させることです。

クラウド プラットフォームの機能