Amazon Web Services ブログ
CCOEを構築するときに避けるべき7つの落とし穴
Cloud Center of Excellence (CCOE)を設立することは、多くの場合、企業のクラウドへの移行を迅速に開始し、ベストプラクティスと長期的な適合性を考慮して移行をガイドするための優れた方法です。 そういった企業は、クラウドのベストプラクティスに関する専門家のチームを編成し、彼らのスキルとクラウドへの情熱を利用して、その企業の残りのクラウドトランスフォーメーションに緊急性を与えています。 AWSでは、CCOEを設立するときに組織がうまくいかない可能性のあるいくつかのやり方を特定しました。 このブログ投稿では、AWSのシニアパートナーソリューションアーキテクトであるNéstor GándaraとEric Linが、これらの落とし穴を回避し、CCOEの可能性を最大限に引き出す方法を示します。
―Mark
AWSシニアパートナーソリューションアーキテクトであるNéstor GándaraとEric Linによるゲスト投稿
企業は、スケーラビリティの向上、高可用性、コスト効率、俊敏性、イノベーションなどのメリットを活用するためにクラウドに移行しています。 しかし、既存の組織構造と方法論により、企業はこれらのメリットの多くを実現できなくなることがよくあります。 多くの企業は、クラウド活用を社内に宣伝し、クラウドトランスフォーメーションを推進し、クラウド上で全てのプロセスを再考するためにCloud Center of Excellence(CCOE)チームを設立します。 しかし、CCOEが正しく実装されていないと、企業はそのメリットを十分に実現できない場合があります。 CCOEを設立するときに避けるべき、7つの一般的な間違いを次に示します。
1. 経営幹部および主要な利害関係者の関与の欠如
よくある間違いは、クラウドトランスフォーメーションを推進するために経営幹部からのサポートを求めておらず、会社の多くの利害関係者を調整していないことです。 古くなった技術の単なる分解修理とは異なり、クラウド導入の影響はITグループのみに限定されていません。 たとえば、クラウドに必要なコストモデル、スキルセット、およびプロセスは、従来のオンプレミス環境に必要なものとは異なります。 クラウドのために効果的に変更を加えるには、さまざまなグループのさまざまなチームが関与する必要があります。 人事部門は、既存のキャリアパスを更新するだけでなく、新しいスキルセットの人材を採用する必要があるかもしれません。 財務部門は、予算編成と財務報告のプロセスを更新する必要があります。 サイバーセキュリティチームは、現在クラウドで稼働しているワークロードを効果的に保護する方法を学ぶ必要があります。 また、クラウドが提供できるスピードとイノベーションを活用するには、多くの内部プロセスを更新する必要があります。 こうした異なるグループを監督する経営幹部が、変化の方向性とアプローチにおいて協調していない場合、進捗が遅くなる可能性があります。
CCOEを設立する上で最も重要な最初のステップの1つは、すべての経営幹部(CxO)とコミュニケーションを取り、サポートを求めることです。そうすれば、それらのリーダーは適切な主要利害関係者を特定して連携するのを助けてくれます。 少なくとも、CCOEの利点と目標についてCスイートのリーダーと主要な利害関係者に伝えておく必要があります。 必要なサポートを確保し、全員が共通の目標に向かって進んでいることを確認するには、すべての事業部門およびその他の利害関係者にわたって「CCOEを設立する理由」を理解してもらう必要があります。
2. CCOEを設立する理由を理解していない
クラウドトランスフォーメーションには多くの未確定要素があります。 厳しいスケジュールの下でやるべきことがたくさんあるため、企業は組織を真に再構築するのではなく、単にチェックボックスにマークをつけるだけで突進してしまうことがあります。 そのような企業は、クラウドトランスフォーメーションを成功させるためにCCOEが重要であると聞いたためCCOEを設立しましたが、その理由を実際には理解していません。 他のすべてのアクションと同様に、CCOEの設立は特定のビジネス成果に結び付けられる必要があります。 特定のビジネス上の課題を解決するためのCCOE設立を意図していない場合、それが生み出すビジネス価値は大きなものにはならないでしょう。 クラウドにフォーカスしたチームをまとめてCCOEとしてラベル付けするだけでは、クラウドのすべてのメリットを自動的に得ることはできません。 CCOEは組織全体のさまざまなチームからクラウドにフォーカスしたリソースを1つのチームに集め、連帯感、協力、当事者意識を向上させる必要があります。そして、これらのリソースは、DevOpsとアジャイルの方法論を取り入れて、より速く、より効果的な変更を推進する必要があります。 CCOEを構築するときは、次の重要な点に注意してください。
- CCOEは組織の内部ニーズに焦点を合わせ、デリバリーチームがクラウドでより効果的に構築できるようにするソリューションを、目的から逆算して作成します。
- CCOEは、セキュリティ、コンプライアンス、およびサービス管理ポリシーに合わせてデプロイを標準化するメカニズムを作成します。
- CCOEは、運用管理のためのクラウドネイティブ・ツールと方法論を使用して、AWSプラットフォームの技術的な運用手順も標準化します。
- CCOEは、クラウドプラットフォームを継続的に最適化、改善、および標準化します。
3. コミュニケーションの欠如
クラウドトランスフォーメーションを成功させるには、コミュニケーションが不可欠です。 CCOEは、そのプロセス、活動、およびステータスに関する明確で透明性のある詳細情報を周知することにより、リーダーシップ、さまざまな事業部門、およびその他の利害関係者との連携を維持します。
組織の経営幹部の一部が自分の領域に影響を与える変更について知らされていない場合、費やした努力がすぐに無駄になってしまうことがよくあります。 これらのリーダーは、意思決定に含まれていなかったために変更に抵抗する可能性があり、意図的に検討の輪から除外されているという認識を深めてしまうことがありえます。彼らはまた、その重要性に気づいていないので、単に優先度の低いものとして扱うかもしれません。 多くの企業は、クラウドトランスフォーメーションの影響がどれほど広範囲に及ぶ可能性があるかを認識していません。財務計算方法の変更から、採用しなければならない要員タイプの変更まで、組織内のほぼすべての領域が影響を受けます。
以下は、組織全体のコミュニケーションを追跡および推進する方法の例です。 様々な対象者に、それぞれ異なる詳細情報を提供する必要があることに注意してください。
対象者 | 目的 | 重要メッセージ | 伝達経路 |
クラウド移行プログラムリーダー
|
|
|
|
部門リーダー
|
|
|
|
エンドユーザー(マネージャー)
|
|
|
|
エンドユーザー
|
|
|
|
プロジェクトチーム |
|
|
|
4. 従来の方法で実行し続けている
組織全体でDevOpsを採用しないことは、CCOEが価値を生み出すことができない、よくある理由です。 DevOpsは、カルチャー上の理念、実践、ツールを組み合わせたものであり、組織が高速でサービス提供および実行する能力を高めます。 DevOpsベースの組織は、従来の開発およびインフラストラクチャ管理プロセスを使用する組織よりも早く環境を進化させ、改善します。 このスピードにより、組織は顧客により良いサービスを提供し、市場でより効果的に競争することができます。
アジャイルは、CCOEの成功に貢献してきた、もう1つの方法論です。 しかし、組織は常にアジャイルを採用したり、アジャイルの本来の意図どおりに実装したりするわけではありません。アジャイルの背後にある重要なポイントの1つは、意図したビジネス価値のために実行することです。 実装によって期待されるビジネス価値が得られない場合、チームはアプローチを調整するか、作業をキャンセルする必要があります。組織やチームは、プロジェクトを時間どおりに予算内で完了することが最優先事項になると、容易に従来のウォーターフォール手法へと後退してしまいます。
企業は、クラウド関連のすべての決定をCCOE内で一元化する必要があると考える場合があります。 ただし、それはすぐにCCOEをボトルネックに変え、進行を遅らせます。 CCOEが実装し運営していく必要がある重要な概念の1つは、ガードレールの使用です。CCOEは、すべてのルールと制限を定義するのではなく、高いレベルのルールまたは「ガードレール」を確立するときに最も効果的です。 これらは、実装チームを軌道に乗せますが、実行するすべての動きを制御するわけではないため、ガードレールと呼ばれます。道路にはガードレールがあり、車両が崖から外れたり、反対の交通に向きを変えたりするのを防ぎます。 しかし、これらの車両のドライバーは、行きたい場所を自由に決めることができます。
AWSのMark Schwartzによる“Using a Cloud Center of Excellence (CCOE) to Transform the Entire Enterprise”ブログ投稿を参照することをお勧めします。 この投稿では、CCOEが、クラウド上でビジネスソリューションを運用管理する技術専門家の一元化されたチームにとどまらず、はるかに超えた存在になる方法について説明しています。
5. あまりにも多くのサービスを前もって学ぼうとしている
クラウドには、オンプレミス基盤との違いがあります。 従業員は、クラウドで効果的に作業するために、新しいスキルを習得し、新しいプロセスに従う必要があります。 さらに、AWSには現在(※オリジナルブログが公開された2021/7時点で)、175を超えるサービスがあり、サービスの数は成長し続けています。数十のサービスは言うまでもなく、いくつかのサービスを習得しようとするだけでも挑戦になり得ます。 企業はすぐに選択肢の多さに圧倒され、一度に多すぎる選択肢を理解するために多大な時間を費やす可能性があります。クラウドに慣れていない企業がクラウド活用を始める時の最も効果的な方法は、AWSパートナーまたはAWSプロフェッショナルサービスに支援を求めることです。これらのリソースは、企業がビジネス目標とワークロードに最も適したサービスをすばやく選択するのに役立ちます。それにより自社の従業員はまず、それらの特定のAWSサービスの採用に集中することができます。
6. レガシー環境の責任を負い続けている
多くの企業でよくある間違いは、以前のオンプレミスの責任から従業員を軽減することなく、従業員に新しいクラウドの責任を与えることです。レガシーオンプレミス環境はずっと長く存在しているため、多くの場合、レガシーの問題、非効率性、未解決のソフトウェアバグ、およびインフラストラクチャの老朽化が伴います。多くの場合、環境には複数のバグ修正レイヤーがあり、問題の特定と解決に時間がかかることがよくあります。これらのレガシー環境での障害は、通常、優先度の高い本番環境をサポートしているため、クラウド上での新規構築よりも優先されることがよくあります。そのため、既存のレガシー環境に対する責任を持っている従業員は、クラウドで何かを成し遂げることが非常に難しいと感じることがよくあります。 彼らは、継続的にオンプレミスのレガシー問題に引き戻されています。これは多くの場合、クラウド化の期限を守れなかったり、従業員を過剰労働させたり、全面的にフラストレーションを引き起こしたりします。
7. 完璧なCCOE組織を最初から作ろうとしている
クラウドトランスフォーメーションの大半のイニシアチブと同様に、小規模で早期に開始することにはメリットがあります。 一度に多くのことをやろうとし過ぎる企業は、しばしば行き詰まって落胆します。これは、CCOEを構築する場合にも当てはまります。 多くの場合、企業は当初、理想的なCCOEを構築するために必要なすべてのクラウドスキルを持っているわけではありません。一部の企業は、クラウドトランスフォーメーションを開始する前に、クラウドに熟練した人材を採用することを選択しています。 多数の新しいポジションの採用と現場受け入れのための初期教育を待つことで、企業はクラウドへの移行とクラウドでの構築に貴重な時間を失うことになります。クラウド上に高品質の環境とプロセスを実装できる、クラウドスキルのある個人のコアグループとしてCCOEを設立することが重要です。
この最小限のグループを作ることができたら、先に進むことができます。 そして、施策を強化するとともに、チームにさらに多くの人材を採用し続けることができます。企業はワークロードをより早くクラウドに取り込むことで、多くのメリットを得ることができます。 これらの初期の利点には、スケーラビリティ、パフォーマンス、信頼性、およびグローバル対応の向上が含まれるでしょう。次に、組織はこれらのワークロードをさらに最適化して、メリットを最大化できます。すべてが完璧に準備できてからCCOEを立ち上げようとすると、勢いを失ってしまい、企業のクラウドトランスフォーメーションが大幅に遅れることがよくあります。これに取り組む最善の方法は、小規模バージョンのCCOEで、できるだけ早く開始することです。 多くの企業は、この最初の小さなチームを「クラウドファンデーションチーム」と呼んでいます。 小規模で早期に開始し、必要に応じてチームに変更を加えて、チームがクラウドへの進捗を効果的に推進し続けるようにします。
まとめ
Cloud Center of Excellence(CCOE)の確立に成功した組織は、自組織のITに大きなカルチャー上の変化をもたらします。
それは、クラウドの採用とトランスフォーメーションを推進するためのベストプラクティスアプローチです。AWSからの推奨事項は、『車輪の再発明』(広く受け入れられ確立されている技術や解決法を知らずに、または意図的に無視して再び一から作ること)を行わず、以前の経験から学んだこれらの教訓を使用して、落とし穴を回避することです。よくある間違いを回避し、クラウドトランスフォーメーションのタイムラインを短縮し、各種プロセスの全体的な労力を削減してください。
ゲスト投稿者
Néstor Gándaraは、アマゾンウェブサービスのシニアパートナーソリューションアーキテクトです。 彼はスペイン人で、米国ニューヨーク市を拠点としています。 彼はAWSパートナーをサポートし、AWSクラウドプラットフォームを採用することによるお客様のデジタル化と革新を支援しています。
余暇には、サッカー、ゴルフ、IT書籍、食べ物(特にパエリア)、旅行、家族や友人との付き合いが大好きです。
Eric Linは、Amazon WebServicesのシニアパートナーソリューションアーキテクトです。 彼は、パートナーが優れたクラウドコンサルティング手法を構築および開発するのを支援しています。 彼はテクノロジー領域で20年以上の経験があります。 この役職に就く前はAWSプロフェッショナルサービスのシニアアドバイザリーコンサルタントであり、Cスイートのリーダーがクラウドトランスフォーメーションを推進するのを支援することに注力していました。
余暇には、旅行、スノーボード、スカイダイビング、バスケットボール、そして良い映画でリラックスすることを楽しんでいます。
この記事はアマゾンウェブサービスジャパンの大塚信男が翻訳を担当しました。(オリジナルはこちら)