ステップ 2。小規模から始めて、勢いをつけましょう。

このステップのゴールは、勢いをつけるために、最初の実行可能な最小限の製品 (MVP) を提供することです。このアプローチにより、早い段階から段階的に業績を上げることができます。

優先度ドライバーの検証

アプリケーションチームとモダナイゼーション作業を開始する前に、先に決定した優先度を検証することをお勧めします。以下の手順に従ってください。

1. 診断プレイブックから必要な情報をコンパイルします。

   • 優先アプリケーションのリストから、優先ドライバーと実現可能性評価を集めます。

   • アプリケーションの移行状態と目標状態の決定事項を収集します。

   • クラウドのモダナイゼーション計画におけるアプリケーション所有者、アーキテクト、利害関係者を特定します。

   • 依存関係やアプリケーションスイートの順序がわかっている場合は、その情報を求めます。

   • インベントリエントリが依存関係やアプリケーションスイートのグループとどのように関連しているかを判断します。アプリケーションには、他のコンポーネントと緊密に結合したり、他のコンポーネントに依存したりする個別のコンポーネントがあり、それらのコンポーネントをまとめてモダナイズしたい場合があります。

2. ステップ 1 の担当者との 1 時間または 2 時間のミーティングをスケジュールして、優先度の高いドライバーを検証します。

   • ソリューションエンジニアやアーキテクトごとに複数 (最大 3～4 個) のアプリケーションをグループ化し、アプリケーションの依存関係やアプリケーションスイートの情報に基づいて、1 回の会議で話し合うようにします。

   • 今度のミーティングにおける各チームメンバーの役割と期待を決めます。

3. ミーティングを実施します。

詳細の確定

前のセクションで説明したプロセスに従って優先順位を検証したら、詳細を収集してモダナイゼーションのアプローチとタイミングを決定できます。

このフェーズでは、コアチームはアプリケーションチームと連携して、2 日間の短いスプリントで AWS クラウド上のアプリケーションの将来の状態を設計します。アクティビティには、製品定義、製品発見、ストーリー作成、バリューストリームマッピング、CI/CD プロセスの設計などがあります。いくつかのアイデアを紹介しよう：

• アプリケーションの各コンポーネント (例えば、ネットワーク構成、ストレージ構成、データベース、サーバー、アプリケーションのサーバーへの配置方法) をモデル化します。

• コンテナやサーバーレステクノロジーなどのツールを使用して、そのモデルをさまざまな構成要素や構成に分解します。

• アプリケーションの機能を、基盤となるインフラストラクチャーへの依存関係とは切り離します。アプリケーションの機能を、ソースコードを変更せずに移動できるコンポーネントに抽象化します。

• CI/CD ツールとメカニズムを使用して DevOps と緊密に統合します。

基盤となるプラットフォーム・サービスを構築し、アプリケーションをモダナイズする

この 12 週間のフェーズでは、コアチームはフルスタックチームによってサポートされ、優先度の高いビジネスユースケースを実現します。この作業は複数のツーピザチームによって行われます。たとえば、基盤となるプラットフォームサービスを開発するためにプラットフォームエンジニアリングチームが結成され、新しいビジネス成果をもたらす製品チームが結成されます。

• プラットフォーム・エンジニアリング・チームは、クラウド基盤、開発者ワークフロー、データ分析機能をサポートする AWS サービスの設定、統合、カスタマイズします。大規模で複雑な企業では、これらの機能をそれぞれサポートする複数のチームがあるかもしれません。

• プロダクトチームは、事業開始段階で優先順位付けされたビジネス成果を実現するために、新しいサービスとエクスペリエンスを開発します。プロダクトチームは新しいサービスを開発すると同時に、中核となるビジネス機能のモダナイズも行います。

プラットフォーム・エンジニアリング・チームと製品チームは、あなたが評価できる最小限の実行可能製品 (MVP) を提供します。最初の MVP が成功したら、スプリットアンドシード方式を使用してモダナイゼーションプログラムを拡大できます。この方法では、新しいアプリケーションを特定し、最初のチームメンバーを分割して新しい製品チームを作成します。