クラウド移行を成功させるための設計：5つの落とし穴と停滞の防ぎ方

クラウド移行の停滞は、クラウド採用のビジネス価値を損なう可能性があります。したがって、早期警告サインに注意を払い、タイムリーに修正アクションを取ることが重要です。このブログ記事では、すべてのクラウド移行リーダーが認識しておくべき 5 つの大きな落とし穴について紹介します。これらの問題を早期に発見すれば、停滞を回避することができます。

落とし穴 #1: ステークホルダーの合意の欠如

進捗が順調でない兆候の 1 つは、移行の対象となる業務アプリケーションのリストが変わり続けていることです。一部のアプリケーションオーナー達は、自身のアプリケーションが移行の対象であることを十分に認識していない可能性があります。そのため、彼らは移行作業を保留にして、移行のタイミングを疑問視したり、追加の準備作業を要求したりします。こうした状況が積み重なり、プロジェクトスポンサーから進捗不足についてエスカレーションされた問い合わせが行われることがよくあります。この問題の根本的な原因は、通常、アプリケーションとビジネスチームからの賛同と合意形成の欠如にあります。明確なトップダウンの方針指示なしに、クラウド移行イニシアチブへの投資を行おうとしているためです。

これに対処するには、ビジネスによるスポンサーシップを優先し、プロジェクトのコミットメントを行う際は、アプリケーションおよびビジネスチームからの賛同を得ることが必要です。これを後回しにすると、解決するのがさらに困難になるでしょう。ビジネス成果を達成するためのクラウド採用メリットを強調することにより、ビジネスチーム内でのコンセンサスを構築してください。また、クラウド移行するチームにインセンティブを提供することを検討してください。早期に移行するチームに対しては、最初の 6 ヶ月間のクラウドコストの配賦を免除する、といった方法があります。移行プロジェクトのスポンサーとなる上級役職者のリストを作成し、チームのサポートをコミットし、彼らがそれぞれの事業部門におけるプロジェクト完遂の責任を負っていることを明確にしましょう。

落とし穴 #2: 移行ウェーブの計画が常に変動している

クラウド移行が停滞するもう 1 つの兆候は、移行ウェーブ (訳註：一つのグループとしてまとめて移行するサーバー群またはアプリケーション群) の計画が変わり続けている時です。適切に定義されたウェーブ計画は、アプリケーション間の依存関係に基づいて、各フェーズまたはウェーブで移行されるものを優先順位付けします。多数のアプリケーショングループによって使用される共有アプリケーションやサービスがある場合、ウェーブの範囲が大きくなり過ぎて一度にすべてを移行できなくなります。このような依存関係を後になって発見したチームは、通常、関連するすべてのアプリケーションを移行ウェーブから削除し、再計画のためにバックログに追加してしまいます。その結果、移行チームは効果的に利用されず、遅延とコスト超過を招きます。プロジェクトスポンサーは、移行ウェーブの範囲縮小に疑問を抱き、過度に保守的なアプローチであるとみなして、移行速度を上げるようクラウド移行リーダーに圧力をかけます。この問題のよくある根本原因は、移行ウェーブの計画時にアプリケーションポートフォリオに関する十分なインベントリデータがないことです。

これを緩和するには、移行の開始時に、優先度の高いアプリケーションのチームとの設計レビューを実施します。 AWS Migration Hub を介する AWS ディスカバリツール (訳註：アプリケーションおよびサーバー情報の収集ツール) のような、ツールベースのアプリケーションディスカバリプロセスを移行ウェーブ計画の前に実施してください。アプリケーションディスカバリの結果に基づいて、文書化され正式に拘束力のあるプロジェクトベースラインを確立します。変更を管理および監視し、ベースラインからの逸脱について早期にエスカレーションできるよう、正式な変更管理プロセスを実装します。

落とし穴 #3: 移行アプローチがアプリケーションによって異なる

移行プロセスにおける重要な懸念事項は、移行アプローチがアプリケーションごとに大きく異なる場合です。これにより移行方法論に一貫性がなくなり、チームが延々と議論を続けたり、設計上の決定を後から見直したり、決定済みの移行範囲を都合よく改変してしまったりすることになります。この落とし穴は、規模の経済や一貫した成果の達成を阻害するため、移行プロジェクトに重大な悪影響を及ぼします。クラウドへの移行に伴って技術的な最適化に過度に重点を置くと、移行の全体的な進行が遅くなります。また、元のビジネスケースで予測された価値を実現することも難しくなります。

この課題を克服するには、事前の対策が不可欠です。標準的な移行アプローチとターゲットアーキテクチャパターンを定義して移行方法論を標準化し、スケールする基盤を構築します。また、合理化プロセスの一環として、共通の移行戦略に基づいてアプリケーションをグループ化します。メインフレームアプリケーションのリファクタリングのような、かなりの変更を必要とするワークロードに対しては、ツールによる自動化を標準的に利用し、カスタマイズした移行作業をできるだけ減らします。停滞を避けるため、一貫した設計決定アプローチをクラウド移行の初期フェーズで確立してください。

落とし穴 #4: 効果の無いエスカレーション

移行が計画通りに進んでいない場合は、可視性とリーダーシップの支持を得るためのエスカレーションプロセスを用意することが不可欠です。プログラムマネジメント会議は、多くの場合、リーダーシップの助けを必要とするリスクや課題について話し合い、対処する場です。共有サービスチーム (訳注：認証機能やログ収集機能など、多くの業務アプリケーションが共通して利用するサービスの担当チーム) のリーダーなどの適切なステークホルダーがこれらの重要な会議に参加しないと、移行イニシアチブの進捗に悪影響を及ぼします。

したがって、プロジェクトのキックオフ前に包括的なコミュニケーション計画とガバナンス構造を確立する必要があります。これにより、課題に十分な注意が払われ、障害を取り除くことができる適切な人物が会議に参加することを確実にできます。共有サービスチームと、緊急解決時間の定義や、ファイアウォール更新のような標準的なリクエストの受付担当者のアサインを交渉することも検討して下さい。これにより、移行チームはアジャイルスプリントでの作業を続けることができ、停滞を防ぐことができます。

落とし穴 #5: 移行に関する問題認識の遅れ

移行プロセスにおける問題表出の遅れは、懸念すべきことです。これはいくつかの症状から明らかになります。移行の進捗状況に関する極めて重要なアップデートが、プロジェクトリーダーに積極的に伝えられていない場合があります。実際に遅延が発生して初めて、問題に気づくということがよく起きているかもしれません。すると、プロジェクトスポンサーは、プロジェクトチームがクラウド移行を管理できているという信頼を失い始めます。問題が素早く対処されないため、ビジネス成果が達成できないリスクがあります。

これに対処するには、クラウド移行開始時の移行統制メカニズムに対する合意が重要です。これらのメカニズムは通常、効果的な設計決定アプローチと移行プロセスやツールの確立、ベースライン計画の作成、移行チームの技術リーダーの任命、効果的なエスカレーションパスの構築を含みます。移行統制メカニズムは、監督の強化、課題の早期発見、移行の円滑化に役立ちます。

まとめ

このブログ記事では、クラウド移行リーダーが注意すべき 5 つの重要な落とし穴に焦点を当てています。これらは、移行プロセスとビジネス成果の実現を妨げる可能性があります。クラウド移行のジャーニーを成功させるには、これらの落とし穴を早期に認識して対処することが不可欠です。よりスムーズな移行体験への道を開くための重要なポイントは次のとおりです。

移行プロジェクトのキックオフ前に、テクノロジーチームおよびビジネスチームと、移行に対するトップダウンの方針指示内容を確認する。
移行範囲のベースラインを作成し、プロジェクトの変更管理を正式化する。
移行に対するトップダウンの目標と技術戦略の整合性を取る。
プロジェクトの初日から効果的なエスカレーションパスを構築する。
移行を円滑に進めるための主要なプロジェクト管理メカニズムについて合意する。

さらなる学習リソース

著者について

この記事はアマゾンウェブサービスジャパンの大塚信男が翻訳を担当しました。（オリジナルはこちら）

Amazon Web Services ブログ