ロードマップの実装

ロードマップを確立したら、それを実装する必要があります。お客様が次の課題に直面するのはここであることがわかりました。つまり、考えることに時間を費やしてきたお客様が、今度は実行することに移行する必要があります。戦略を実装に結び付けるために、次のステップを推奨しています。

開始する場所と方法を決定する

これは簡単に聞こえますが、達成すべきことが非常に多いため、開始点を見つけることはしばしば困難であり、議論の対象となる問題です。クラウドに移行中の組織には注力すべきことが多数あるため、そのイニシアチブがコンテキストの中で適切に位置付けられていない場合、手に負えないものになる可能性があります。長年にわたって顧客のトレンドは進化してきましたが、一貫した開始点はトランスフォーメーションのリーダーシップです。トップダウンで指針と戦略を推進し、ミッションステートメント、理念、および PR-FAQ を作成することで、中間管理職や個人が自律的に意思決定を行い、明確性を向上させ、クラウドトランスフォーメーションからビジネス価値を生み出すことが可能になります。この取り組みまたは類似のものを実施していない場合、それを最初のタスクとして行うことを推奨します。

この取り組みでは、他のテクノロジートランスフォーメーションとは異なり、クラウドトランスフォーメーションはテクノロジーをビジネスに近づけるものであるということを認識する必要があります。技術は、俊敏性、安定性、コスト最適化、および類似の成果を実現することで、ビジネスがより広範な目標を達成するために使用するレバーです。お客様は、このトランスフォーメーションをテクノロジー部門およびビジネス部門と連携して計画する必要があります。その際、組織の 3～5 年の戦略から逆算しながらその過程で目標を特定し、必要に応じて方向転換することを恐れないようにしてください。

成功に向けて組織化する

組織が成熟するにつれて、クラウド移行、導入、トランスフォーメーションの目標を達成するための組織の構造は変化します。これを理解し、準備し、意図を持って取り組むことが、成功を確実にするために重要です。

一般的に、ジャーニーの開始時点では、最大規模のチームがオンプレミス環境で作業します。その後、クラウド導入が進むにつれて、これらのチームはクラウドプラットフォームの構築、成熟化、運用、最適化へと移行し、組織はこれらの各ステージにおいて新しい作業方法に適応する必要があります。組織がワークロードの 5～10 パーセントをクラウドに移行したときに (開始フェーズからスケールフェーズへ移行するタイミング)、困難ではあるが重要な変化が生じることが確認されています。この時点では、移行の規模がフルタイムの変更を正当化するほど大きくないため、組織はオンプレミスのチームを使用してクラウドリソースを運用します。その結果、これらのチームは既存の責任と新しい責任のバランスを取る必要が生じます。同時に、クラウドサービスの運用を求められているオンプレミスのチームには、急激な学習曲線を伴う新しいスキルが必要となります。

組織を理解し、これらの変化を可能にするための計画を策定するために、IT 組織全体にわたるチームのトポロジを確認することを推奨しています。IT 組織内における機能の配置と相互連結を理解するために、顧客とともにこの方法を使用します。これは多くの場合、組織構造とは異なります。その後、トランスフォーメーションのステージやマイルストーンに対して成果を提供するためにどのように組織化すべきかについてのガイダンスとして、AWS COM フレームワークを使用します。組織構造に対して必要となる可能性のある変更については、この取り組みを通じて示されます。

当社が顧客とともに使用してきたトポロジには、分散型、集中型、およびフェデレーション型のモデルなどがあります。これらは、AWS Well-Architected フレームワークのオペレーショナルエクセレンスの柱で説明されている運用モデルの 2 x 2 表示を拡張したものです。

分散型

さまざまな地域や業種セグメントにまたがって事業を展開する大規模なグローバル企業では、次の図に示すような分散型モデルが使用されることが多くあります。これらの企業では、個々のビジネスユニットが独自の IT 提供体制を持っており、それが他の地域やビジネスユニットと重複することがあります。しかし、これは多くの場合、その地域内で自律性と専門性を提供するための方法として理解され、受け入れられています。

分散型アプローチを使用することは、各地域またはビジネスユニットが、その地域またはビジネスユニットのニーズに合わせて調整された独自のクラウド運用モデルを持つことを意味します。

一元化

集中型の IT 機能は、最も頻繁に目にするモデルです。このモデルが導入されている場合、顧客はクラウド運用モデルを確立する際に、同じトポロジを維持しようとします。これについては、以下の図で示されています。

このモデルでは、中央チームが厳選されたプラットフォームを提供します。このプラットフォームは、独自のクラウド運用モデルを持つワークロードチームが使用できます。このアプローチにより、ワークロードチームは、使用しているプラットフォームのサービス、運用、セキュリティについて心配することなく、エンドカスタマーに提供する価値に注力できます。このモデルは、小規模な企業により適しています。しかし、大規模なグローバル組織では、ワークロードチームの数は数百あるいは数千になる可能性があります。中央プラットフォームの利点を失うことなくこのスケールで管理するために、組織は頻繁にフェデレーション型モデルに移行します。このモデルについては次のセクションで概説します。

Federated

多くの組織がフェデレーション型 IT モデルを採用します。なぜなら、このモデルではクラウドプラットフォームに対して責任を持つ中央機能が提供される一方で、ワークロードレベルでさまざまな運用モデルが可能になるためです。これは、中央チームが、最低限の基準に合わせて作業するという制約なしに、組織に対して可能な限り最善のプラットフォームを提供することに集中できることを意味します。次の図は、フェデレーション型モデルを示しています。

大規模な組織において、フェデレーション型モデルはエンジニアリングチームに必要となる自律性を提供する一方で、中央チームがすべてのワークロードに共通するプラットフォームおよび差別化されない重労働を提供することを確実にします。このモデルでは、中央チームはエンジニアリングチームと同じ製品中心の方法で作業する必要がありますが、彼らの製品はプラットフォームです。

ジャーニーに合わせたトポロジの変更

選択するトポロジは会社の規模に応じて変わるだけでなく、クラウドジャーニーのステージに合わせた調整も行われます。部門やチームの編成は静的ではなく、クラウド導入の各ステージに応じて変化します。これは、環境が変化するにつれて、さまざまなトポロジを設計、議論、および拡張する可能性があることを意味します。影響要因の例としては、次のものがあります。

変化を推進するメカニズムを確立する

Amazon 内では、メカニズムは次のように定義されています: インプットをアウトプットに変換する完全なプロセスであり、組織レバーから組み立てられます。プロセスをサポートし、成果が確実に満たされるようにするために、データとフィードバックを使用します。各組織は異なるため、クラウド運用モデルのジャーニーもそれぞれ異なりますが、それらはすべて変化を推進するためのメカニズムを必要とします。

クラウド運用モデルの実装に必要な変化に合わせて、メカニズムを理解し、開発することに時間を費やすことをお勧めします。一般的なアプローチは、アジャイルの原則を採用することです。アジャイルのメカニズムは、サイロ化されたチーム間の組織的な障壁やプロセスに基づく障壁を取り除き、フィードバックループを作成することにより、組織が最大のビジネス価値を生み出す最も影響力のあるアクティビティのイノベーションに時間を費やせるようにします。

成熟度の段階的な向上

クラウド運用モデルのコンテキストにおける成熟度とは、お客様のケイパビリティがクラウドファーストの働き方にどの程度近いかを示します。例えば、プロセスはどの程度自律的であるか、イノベーション (会社の変革) と比較して、通常業務 (会社の運用) を管理するためにどの程度の人間の関与が必要となるか、などです。アクティビティが後者 (イノベーション) により重点を置いている場合、(クラウドの) 成熟度は低く、前者 (通常業務) に重点を置いている場合、成熟度は高くなります。成熟度スケールが低いことは否定的なことではありません。これは、ジャーニーのどの段階にいるかを反映しているだけです。目的は、自分がどこにいて、どこに到達する必要があるかを理解することです。当社が AWS の顧客と連携する際には、AWS COM フレームワーク内の成熟度スケールを使用して、ジャーニーに沿ったステップを提供します。

AWS COM フレームワークのケイパビリティ全体にわたって成熟度を段階的に高めるために、メカニズムを使用することを推奨しています。このように当社が顧客と連携してきた例として、成熟度レビューと優先順位付け (インプット) を成熟度の向上 (アウトプット) に変換し、その後、結果を検証し必要に応じて調整するために、ゲームデーのような経験に基づくイベント (フィードバックループ) を実施することなどが挙げられます。これらのメカニズムを顧客とともに確立することで、この組織的な強みが構築されたときには、目前のマイルストーンを達成できるだけでなく、ジャーニーの初期段階を超えて持続する段階的な改善が可能になることがわかりました。

組織のケイパビリティを成熟させることに注意を払い、ロードマップの特定の時点で特定のケイパビリティに必要な変化を段階的に構築することは、戦略と実装を結び付けます。これは、それまでの成果の上に構築することで得られる規模の経済を活用することにも役立ちます。