Amazon Web Services ブログ

クラウド移行にアプリケーションチームを巻き込む方法

本記事は、2024 年 7 ⽉ 14 ⽇に公開された “How to engage application teams during a cloud migration” を翻訳したものです。

アプリケーションチームとの効果的な連携は、クラウド移行の取り組みを拡大していくうえでの鍵となります。
一部のアプリケーションチームは、移行プロセスへの関与を最小限にしたいと考えています。一方、エンジニアの能力を伸ばし、実践的な学習機会だと捉えているチームもあります。このブログでは、アプリケーションチームとの連携モデルを3つ紹介し、それぞれのメリット・デメリットと適用条件について説明します。

  • デリバリー (代行モード) : 移行のコアとなるチーム (以後、移行チームと表記する) が、アプリケーションチームに代わって移行作業の大部分を実行する。
  • アシスト (協働モード) : 移行チームが、アプリケーションチームと協働し、OJT を提供する。
  • セルフサービス (自立モード) : 移行チームが提供する移行ツールやソリューションを活用し、アプリケーションチーム自身が、移行作業を行う。

これらのモデルは、アプリケーションチームに委ねられる自律性の度合いが異なります。アプリケーションチームの自律性が高いほど、移行チームの役割はイネーブラーやソリューション提供者へと移っていきます。ただし、これらの連携モデルを早期に導入しすぎると、特にアプリケーションチームの自律性や嗜好に合わない場合、アプリケーションチームにとってマイナスな経験につながる可能性があるため、注意が必要です。

連携モデル

大規模な移行プログラムを設計する際、見過ごされがちな重要な側面の一つは、移行チームがどのようにアプリケーションチームと連携すべきかということです。AWS での Cloud Migration Factory を使用した中央集権的な移行チームでも、アプリケーションチームから、十分な要求やタスク内容を得られていないことがあります。アプリケーションチームが、自分たちでクラウド移行を進めるにあたり、移行チームからのイネーブルメントをどの程度必要とするかは、様々なケースがあります。

アプリケーションチームに移行の責任をどの程度委ねるかは、その能力、スキル、経験、運用モデル、アプリケーションの種類、全体的な優先事項に依存します。さまざまなユースケースに対応し、最大の効果を上げるためには、これら 3 つのモデルを組み合わせて活用することを推奨します。

一般的に、組織はまず、初期の移行をエンドツーエンドで実施するクラウド移行を統括的に推進する移行チームを立ち上げることから始めます (代行モード) 。これにより、迅速に経験を積み、初期の標準を確立することができます。特に、アプリケーションエンジニアが、インフラストラクチャへの管理者権限を持たない、従来の責任分担体制の組織に適しています。時間の経過とともに、移行チームはアプリケーションエンジニアをアプリケーション移行を支援するためにオンボーディングしていくことができ (協働モード) 、移行ツールをセルフサービス型のツールとして提供できるようになります (自立モード) 。図 1 に、これら 3 つのモデルの概要を示します。

図 1 クラウドに移行するアプリケーションチームをサポートする連携モデル

ユースケースの例 (図1)

A) アプリケーションチームは、厳格な期限内にデリバリーするための能力と経験が不足しているため、移行チームが移行作業の大部分を実施する。

B) アプリケーションチームは、移行をサポートする能力はあるものの自立していないため、経験豊富なエンジニアとともに現場で学ぶ。

C) 自立したアプリケーションチームが、組織の移行プログラムのもとにオンボーディングされ、チーム間の依存関係や厳格なスケジュールを管理する。

D) 自立したアプリケーションチームが自身のペースで移行を進め、移行チームが提供するツールやソリューションを活用して労力を軽減し、コンプライアンスを確保する。

モデル 1 : デリバリー (代行)

このモデルでは、移行チームを中心とした経験のベースラインを構築します。これにより、組織内の学習と標準的な移行プロセスやツールの開発が促進されます。移行チームは、移行の責任と作業を一元的に引き受け、アプリケーションチームとの連携を可能な限り効率的に行うことに注力します。

このモデルは、システムインテグレーターなどの外部の専門家のノウハウを取り入れ、組織全体に展開しやすい利点があります。一方で、移行チームを一元化することの問題点は、クラウド移行に対して画一的で標準的なアプローチになりがちなことです。例えば、移行チームには、カスタマイズされたシステムアーキテクチャのような特別な要求に対応する能力や柔軟性がない場合があります。

モデル 2 : アシスト (協働)

このモデルでは、移行作業をアプリケーションエンジニアと共有しながら、移行の進捗を管理します。移行チームは、公式なトレーニングと実践的な学習を通じて、知識の共有、オンボーディング、スキルアップのための成熟したプロセスを確立することに注力します。組織の移行プログラムへのアプリケーションエンジニアのオンボーディングは、責任の増加に応じて段階的に行われます。例えば、アプリケーションエンジニアは、移行エンジニアがアプリケーションの開発環境をどのように構築するか見て学ぶシャドーイングから始めます。続いて、統合テスト環境の移行を移行エンジニアに見てもらいながら実行し、その後に本番環境の移行を完全に引き受けるようになります。

このモデルは、移行を自己研鑽の機会と捉え、移行チームとアプリケーションチーム間の引き継ぎを避けたいチームに適しています。通常、このモデルを成功させるには、専任のアプリケーションエンジニアが不可欠です。サードパーティの商業的または法的な取り決めにより、アプリケーションチームがエンジニアを研修や能力向上機会へ派遣できない場合があるため、注意が必要です。そのような場合は、セルフサービスモデルが代替手段となります。

モデル 3 : セルフサービス (自立)

組織の成熟度が高まり、知識がチーム間に広がるに従って、クラウドへのアプリケーション移行は日常業務になっていきます。これにより、ロードバランサー、仮想マシン、コンテナサービス、リレーショナルデータベースを使用する 2 層または 3 層システムを移行するなどの一般的なユースケースについて、移行チームの関与を減らす機会が生まれます。移行チームの役割は、セルフサービス型の移行ツールの提供へと移っていきます。さらに、セルフサービスでの移行により、移行チームのキャパシティが解放され、より付加価値の高いユースケースへの支援を強化することができます。

このモデルは、自分達自身が移行能力を持つ大規模な開発組織や、ベンダーが複数いることにより責任が分散している連合された IT 組織に特に適しています。セルフサービスでの移行により、アプリケーションチームは自らのペースで移行を進められます。移行チームは、移行の進捗への関与は限られているため、プラットフォームを使用して移行サービスを提供し、実際の進捗状況を常に把握できるようにしています。

例えば、AWS Migration Hub や Backstage などの社内開発者プラットフォームを使用するなどです。

比較

3 つのモデルは、以下の観点で異なります (表 1) 。

  • ガバナンスレベル – 移行チームの管理・支援の範囲
  • アプリケーションエンジニアの役割 – 責任分担と自律性の度合い
  • ユースケース – それぞれのモデルが適用される場合

表 1. 連携モデルの比較

最良の成果を得るには、各モデルをガバナンスメカニズムで補完してください。詳細は「 AWS 大規模な移行のためのプロジェクトガバナンスプレイブック」を参照してください。ガバナンスのレベルと範囲は、タスクの調整からソリューションの提供、導入状況の追跡まで、さまざまです。

ベネフィット

これら 3 つのモデルは、さまざまなユースケースやアプリケーションチームの体制に合わせて組み合わせて使用できます。アプリケーションチームとの関わりを深める組織は、以下のようなベネフィットを得られます。

  • 一律ではなく、個別最適化された移行の経験が得られます。
  • 移行チームの基準に合わないカスタマイズされた要求に対して柔軟に対応できます。
  • アプリケーションチームの能動的な参加を促すことで、予算の増加や外部委託の追加を必要とせず、より大きな移行の成果をあげられます。

結論

このブログでは、クラウド移行中にアプリケーションチームを巻き込む方法について、 3 つの一般的なモデルを説明しました。これらの 3 つのモデルを組み合わせて活用することで、さまざまなユースケースに対応し、組織全体への影響を最大化することができます。どの程度の責任をアプリケーションチームへ移譲するかは、組織の成熟度に応じて判断する必要があります。

関連ブログ

本記事はカスタマーソリューションマネージャーの宮本雅勝が翻訳を担当しました。