翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# タスク: 通信ゲートの完了
このタスクでは、 で定義した通信ゲートと T-minus スケジュールを使用して[タスク: 通信ゲートとスケジュールの定義](task-create-communication-gates.md)、移行ワークストリームとポートフォリオワークストリームを通過する各ウェーブのステータスを伝達します。
これらのゲートを個別に移動したり、複数のウェーブが同じスケジュールにある場合は、グループ内のゲートを移動したりできます。移行ワークストリームでは波が重複するため、移行のどの時点でも、異なるゲートに複数の波または波のグループがあるのが一般的です。次の表は、移行ワークストリームでウェーブがどのように重複し、各ウェーブが 1 週間間隔でスケジュールされているかを示しています。この例では、移行ワークストリームでいつでも 6～7 個のウェーブがアクティブであり、各ウェーブは異なるゲートにあります。
****
| Gate | ウェーブ 1 | ウェーブ 2 | ウェーブ 3 | ウェーブ 4 | ウェーブ 5 |
| --- | --- | --- | --- | --- | --- |
| ゲート 1: T マイナススケジュール | 3 月 13 日 | 3 月 20 日 | 3 月 27 日 | 4 月 3 日 | 4 月 10 日 |
| ゲート 2: T-28 会議 | 3 月 20 日 | 3 月 27 日 | 4 月 3 日 | 4 月 10 日 | 4 月 17 日 |
| ゲート 3: T-21 通信 | 3 月 27 日 | 4 月 3 日 | 4 月 10 日 | 4 月 17 日 | 4 月 24 日 |
| ゲート 4: T-14 ミーティング | 4 月 3 日 | 4 月 10 日 | 4 月 17 日 | 4 月 24 日 | 5 月 1 日 |
| ゲート 5: T-7 通信 | 4 月 10 日 | 4 月 17 日 | 4 月 24 日 | 5 月 1 日 | 5 月 8 日 |
| ゲート 6: T-1 go または no-go ミーティング | 4 月 16 日 | 4 月 23 日 | 4 月 30 日 | 5 月 7 日 | 5 月 14 日 |
| ゲート 7: カットオーバー会議 | 4 月 17 日 | 4 月 24 日 | 5 月 1 日 | 5 月 8 日 | 5 月 15 日 |
| ゲート 8: ハイパーケア期間の開始 | 4 月 18 日 | 4 月 25 日 | 5 月 2 日 | 5 月 9 日 | 5 月 16 日 |
| ゲート 9: ハイパーケア期間の終了 | 4 月 22 日 | 4 月 29 日 | 5 月 6 日 | 5 月 13 日 | 5 月 20 日 |
このタスクは、次の通信ゲートで構成されます。
+ [ゲート 1: ウェーブの T マイナススケジュールを作成する](#gate-tminus-schedule)
+ [ゲート 2: T-28 コミット会議](#gate-t28)
+ [ゲート 3: T-21 通信](#gate-t21)
+ [ゲート 4: T-14 チェックポイント会議](#gate-t14)
+ [ゲート 5: T-7 通信](#gate-t7)
+ [ゲート 6: T-1 go または no-go ミーティング](#gate-t1)
+ [ゲート 7: T-0 カットオーバー会議](#gate-t0)
+ [ゲート 8: ハイパーケア期間の開始](#gate-hypercare-start)
+ [ゲート 9: ハイパーケア期間の終了](#gate-hypercare-end)
## ゲート 1: ウェーブの T マイナススケジュールを作成する
この通信ゲートで次の操作を行います。
1. このウェーブのドキュメントを保存する単一の共有リポジトリを作成します。
1. で作成した T-minus スケジュールテンプレートを使用して[ステップ 2: T-minus スケジュールテンプレートを作成する](task-create-communication-gates.md#step-create-tminus-schedule)、このウェーブに固有の日付を入力し、T-minus スケジュールを共有リポジトリに保存します。
1. [AWS 大規模な移行用の移行プレイブックで作成した移行](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-migration-playbook/)タスクリストのコピーを作成し、共有リポジトリに保存します。このタスクリストは、ゲートを進める際にチェックリストとして使用します。
1. 適切な参加者と T-28 コミット会議をスケジュールします。この会議の詳細については、「」を参照してください[ステップ 3: 会議とその頻度を定義する](task-communication-plan.md#step-define-meetings)。
### ゲート終了条件
次のプロジェクトガバナンスアクティビティが完了したら、次のゲートに進みます。
+ ウェーブの共有リポジトリを確立しました。
+ ウェーブの T マイナススケジュールを作成しました。
+ ウェーブの移行タスクリストを作成しました。
+ T-28 コミット会議をスケジュールしました。
次の移行アクティビティと、移行ランブックで定義されているその他のタスクが完了したら、次のゲートに進みます。
+ ポートフォリオチームがウェーブプランを完了しました。
+ ポートフォリオチームがウェーブの移行メタデータを収集しました。
## ゲート 2: T-28 コミット会議
このゲートでは、移行チームがアプリケーション所有者とウェーブプランを確認し、ウェーブプランとカットオーバー日へのコミットをアプリケーション所有者に依頼します。この通信ゲートで次の操作を行います。
1. で作成したウェー*ブワークショッププレゼンテーション*を使用して[ステップ 4: 会議プレゼンテーションを準備する](task-communication-plan.md#step-prepare-presentations)、ウェーブ用にこのプレゼンテーションをカスタマイズし、そのプレゼンテーションを共有リポジトリに保存します。このプレゼンテーションは、このゲートと で使用します[ゲート 4: T-14 チェックポイント会議](#gate-t14)。
1. T-28 コミット会議を実施し、プレゼンテーションを使用して以下を確認します。
+ ウェーブプランと移行プロセスの概要を説明します。
+ アプリケーション所有者の今後のアクション項目の詳細を提供します。
+ アプリケーション所有者がこのウェーブの各アプリケーションを移行する準備ができていることを確認します。
+ アプリケーション所有者が、アプリケーションのテストプランを提供する必要があることを理解していることを確認します。*テストプラン*では、カットオーバーが成功したことを検証する方法について説明します。テストはカットオーバーの直後に行われるため、問題が発生した場合、移行チームはビジネスユーザーやアプリケーションユーザーへの影響を最小限に抑えながらアプリケーションを元の環境にロールバックできます。
+ ステークホルダーが波全体でどのように協力し、コミュニケーションを取ることが期待されているかを確認します。利害関係者がこのウェーブに関連するドキュメントを見つけることができる共有リポジトリの場所を指定します。
+ で作成したエスカレーション計画を確認します[ステップ 2: エスカレーション計画を確立する](task-communication-plan.md#step-escalation-plan)。
+ 質問と回答の機会を提供します。
1. T-28 コミットミーティングの後、 で作成した *T-28 通信 E* メールを送信します[ステップ 3: ゲートごとに標準の E メールテンプレートを作成する](task-create-communication-gates.md#step-email-templates)。ウェーブ情報と受信者の E メールをカスタマイズし、このウェーブにすべてのアプリケーションとサーバーを追加します。
1. T-28 コミットミーティングの後、適切な参加者と次のミーティングをスケジュールします。
+ T-14 チェックポイント会議
+ T-1 go または no-go 会議
+ T-0 カットオーバー会議
### ゲート終了条件
次のプロジェクトガバナンスアクティビティが完了したら、次のゲートに進みます。
+ T-28 コミット会議を実施しました。
+ ウェーブドキュメントにアクセスするために、共有リポジトリについてすべての主要な利害関係者に通知し、すべての利害関係者がアクセスできます。
+ に従って、移行営業時間の保持を開始しました[タスク: ステージ 2 の定期的な会議をスケジュールする](task-schedule-meetings-stage2.md)。
+ アプリケーション所有者は、ウェーブプラン内のアプリケーションを移行できることを確認しました。
+ すべての利害関係者はコミュニケーションアプローチを理解し、どの会議に出席する必要があるかを理解しています。
+ アプリケーション所有者は、担当する特定のアクション項目を理解します。
+ *T-28 通信 E* メールをすべての利害関係者に送信しました。
+ すべての利害関係者がアクセスできるように、会議のプレゼンテーションと会議メモを共有リポジトリに保存しました。
+ T-14 コミット会議をスケジュールしました。
+ T-1 go または no-go 会議をスケジュールしました。
+ T-0 カットオーバー会議をスケジュールしました。
次の移行アクティビティと、移行ランブックで定義されているその他のタスクが完了したら、次のゲートに進みます。
+ T-28 コミット会議中に行われた変更でウェーブプランを更新しました。
+ ウェーブ内のアプリケーションとサーバーの変更リクエスト (RFC) が送信され、変更ウィンドウがスケジュールされます。
+ 変更管理プロセスを理解して特定します。
+ 転送、ルーティング、プロキシサービスなどの新しいインフラストラクチャ要件について RFCs を送信しました。
+ 移行タスクリストを更新しました。
## ゲート 3: T-21 通信
コミュニケーションチームは、アプリケーション所有者およびビジネスユニットの担当者との連絡を継続します。これらの利害関係者は、質問の機会を提供するために、移行営業時間に招待されます。
1. で作成した *T-21 通信 E* メールを送信します[ステップ 3: ゲートごとに標準の E メールテンプレートを作成する](task-create-communication-gates.md#step-email-templates)。ウェーブ情報と受信者の E メールをカスタマイズし、このウェーブにすべてのアプリケーションとサーバーを追加します。
1. 正しいアプリケーション所有者とスケジュールされた T-14 チェックポイント会議を更新します。必要な参加者が出席できない場合は、エスカレーション計画に従って代替担当者が出席できることを確認します。
### ゲート終了条件
次のプロジェクトガバナンスアクティビティが完了したら、次のゲートに進みます。
+ *T-21 通信 E* メールをすべての利害関係者に送信しました。
次の移行アクティビティと、移行ランブックで定義されているその他のタスクが完了したら、次のゲートに進みます。
+ ソースサーバーがレプリケーションの最小要件を満たしていることを確認します。
+ ウェーブでアプリケーションとサーバーのレプリケーションを開始しました。
+ 移行タスクリストを更新しました。
## ゲート 4: T-14 チェックポイント会議
このゲートでは、アプリケーション所有者との T-14 チェックポイントミーティングを実施し、チームがスケジュールどおりにカットオーバーする予定があるかどうかを評価します。この通信ゲートで次の操作を行います。
1. で準備した*ウェーブワークショップのプレゼンテーション*を使用して[ゲート 2: T-28 コミット会議](#gate-t28)、T-14 チェックポイント会議のプレゼンテーションを更新します。
1. T-14 チェックポイントミーティングを実施し、以下を確認します。
+ このウェーブで移行されるアプリケーションとサーバーを確認します。
+ 残りのタスクとスケジュールを確認して、参加者がプロセスの残りのステップを理解していることを確認します。
+ すべてのアプリケーション所有者 (またはその代理人) がカットオーバー会議に参加できることを確認します。
+ カットオーバーが完了したら、テストプランの準備が整っていることを確認します。
1. T-14 チェックポイント会議後、 で作成した *T-14 通信 E* メールを送信します[ステップ 3: ゲートごとに標準の E メールテンプレートを作成する](task-create-communication-gates.md#step-email-templates)。ウェーブ情報と受信者の E メールをカスタマイズし、このウェーブにすべてのアプリケーションとサーバーを追加します。
1. T-1 go または no-go 会議と T-0 カットオーバー会議への招待を更新し、アプリケーション所有者が指定した代替担当者など、参加者に変更を加えます。
1. 移行タスクリストを更新します。
### ゲート終了条件
次のプロジェクトガバナンスアクティビティが完了したら、次のゲートに進みます。
+ T-14 チェックポイント会議を実施しました。すべてのアプリケーション所有者または指定された担当者が参加しました。アプリケーション所有者が出席せず、応答しない場合は、エスカレーション計画に従って出席不足をエスカレーションします。
+ その週の移行営業時間を設定しました。
+ *T-14 通信 E* メールをすべての利害関係者に送信しました。
+ すべての利害関係者がアクセスできるように、会議のプレゼンテーションと会議メモを共有リポジトリに保存しました。
+ 移行前、移行、移行後のすべてのタスクのチェックリストを作成し、完了したタスクをすべて閉じ、チェックリストを共有リポジトリに保存しました。
次の移行アクティビティと、移行ランブックで定義されているその他のタスクが完了したら、次のゲートに進みます。
+ レプリケートされたアプリケーションとサーバーの状態とステータスを検証しました。問題のトラブルシューティング中であるか、トラブルシューティングを完了している。
+ アプリケーション所有者は、移行チームにテストプランを提供しています。
+ 移行タスクリストを更新しました。
## ゲート 5: T-7 通信
このゲートでは、コミュニケーションチームはアプリケーション所有者やビジネスユニットの担当者との連絡を継続します。また、カットオーバーアクティビティと会議の準備も行います。
1. で作成した *T-7 通信 E* メールを送信します[ステップ 3: ゲートごとに標準の E メールテンプレートを作成する](task-create-communication-gates.md#step-email-templates)。ウェーブ情報と受信者の E メールをカスタマイズし、このウェーブにすべてのアプリケーションとサーバーを追加します。
1. 必要な参加者が T-1 go または no-go 会議と T-0 カットオーバー会議に参加できることを確認します。必要に応じて会議の招待を更新し、代替代理人を含めます。
### ゲート終了条件
次のプロジェクトガバナンスアクティビティが完了したら、次のゲートに進みます。
+ *T-7 通信 E* メールをすべての利害関係者に送信しました。
+ T-1 go または no-go 会議と T-0 カットオーバー会議への出席が確認されました。すべての参加者が会議を承諾したか、代替代理人が特定されました。
次の移行アクティビティと、移行ランブックで定義されているその他のタスクが完了したら、次のゲートに進みます。
+ このウェーブの変更リクエストはすべて承認されました。
+ ターゲットインフラストラクチャがカットオーバーの準備が整っていることを検証しました。
+ インフラストラクチャを検証するために作成したテストインスタンスをシャットダウンしました。
+ カットオーバータスクリストを検証しました。
+ 移行タスクリストを更新しました。
## ゲート 6: T-1 go または no-go ミーティング
このゲートでは、RACI マトリックスのすべてのチームメンバーと移行前アクティビティのチェックリストを確認して、ウェーブ内のアプリケーションとサーバーがカットオーバーの準備ができていることを確認します。このゲートは、スケジュールされたカットオーバーの 24～48 時間前に発生します。
1. T-1 go または no-go ミーティングで、RACI マトリックスのすべてのチームメンバーとチェックリストを確認して、ウェーブ内のアプリケーションとサーバーがカットオーバーの準備が整っていることを確認します。
1. 必要なすべての参加者が T-0 カットオーバー会議に参加できることを確認します。
1. ウェーブの移行 (go) を続行する場合は、 で作成した *T-1 通信 E* メールを送信します[ステップ 3: ゲートごとに標準の E メールテンプレートを作成する](task-create-communication-gates.md#step-email-templates)。ウェーブ情報と受信者の E メールをカスタマイズし、このウェーブにすべてのアプリケーションとサーバーを追加します。
1. ウェーブまたは特定のアプリケーションやサーバー (no-go) の移行を続行しない場合は、すべての利害関係者に決定を通知する E メールを送信し、次のステップやスケジュールの変更に関する利用可能な情報を提供します。
### ゲート終了条件
次のプロジェクトガバナンスアクティビティが完了したら、次のゲートに進みます。
+ T-0 カットオーバー会議でリソースが利用可能であり、必要なすべての参加者が参加できることを確認しました。
+ すべての利害関係者がアクセスできるように、会議のプレゼンテーションと会議メモを共有リポジトリに保存しました。
+ *T-1 通信 E* メールをすべての利害関係者に送信しました。
次の移行アクティビティと、移行ランブックで定義されているその他のタスクが完了したら、次のゲートに進みます。
+ 移行タスクリストで、すべての移行タスクが完了したことを確認しました。
## ゲート 7: T-0 カットオーバー会議
このゲートでは、カットオーバー会議中にウェーブ内のすべてのサーバーとアプリケーションを移行し、すぐにアプリケーション所有者が移行したアプリケーションをテストして、期待どおりに動作していることを確認します。アプリケーション所有者は、会議全体に参加するか、アプリケーションに必要な場合にのみ参加できます。
1. カットオーバー会議の前に、 で作成した *T-0 通信 E* メールを送信します[ステップ 3: ゲートごとに標準の E メールテンプレートを作成する](task-create-communication-gates.md#step-email-templates)。ウェーブ情報と受信者の E メールをカスタマイズし、このウェーブにすべてのアプリケーションとサーバーを追加します。
1. T-0 カットオーバーミーティングでは、[AWS 大規模な移行の移行プレイブックの指示に従って開発した移行ランブックの指示に従って、ウェーブ内のサーバーとアプリケーションを移行します](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-migration-playbook/)。
1. アプリケーションまたはサーバーが移行されたら、アプリケーション所有者が作成したテストプランを使用して、アプリケーションが次のように機能していることを確認します。
+ アプリケーションまたはサーバーが想定どおりに機能している場合、または軽微な問題しかない場合は、 AWS 環境内に残して問題を修正します。
+ アプリケーションまたはサーバーが機能していない場合、または重大な問題がある場合は、ロールバックします。
1. 移行タスクリストのカットオーバーアクティビティを完了したら、タスクリストを更新します。
1. で作成した*カットオーバー完了通信 E* メールを送信します[ステップ 3: ゲートごとに標準の E メールテンプレートを作成する](task-create-communication-gates.md#step-email-templates)。ウェーブ情報と受信者の E メールをカスタマイズし、このウェーブにすべてのアプリケーションとサーバーを追加します。
### ゲート終了条件
次のプロジェクトガバナンスアクティビティが完了したら、次のゲートに進みます。
+ ウェーブ内のすべてのアプリケーションまたはサーバーが正常に移行されたことを検証したか、ロールバックしました。
+ ロールバックしたアプリケーションまたはサーバーを書き留めました。これらのアプリケーションまたはサーバーでは、移行パターンを更新するか、ターゲット状態を再定義して、カットオーバー中に発生した問題に対処する必要があります。これらのアプリケーションまたはサーバーは、将来のウェーブプランに含めます。
+ *カットオーバー完了のコミュニケーション E* メールをすべての利害関係者に送信しました。
次のカットオーバーアクティビティが完了したら、次のゲートに進みます。
+ 移行*タスクリストの「カットオーバー*タスク」セクションのすべてのステップを完了しました。
## ゲート 8: ハイパーケア期間の開始
このゲートでは、次の操作を行います。
1. プロジェクトの関係者に、クラウド内の移行されたアプリケーションとサーバーを確認するよう依頼します。問題が特定された場合は、移行チームに送信する必要があります。
1. カットオーバー中またはハイパーケア期間中に特定された問題に対処します。
1. クラウド運用チームがワークロードを受け入れる準備ができていることを確認します。
1. すべてのプロジェクト管理ツールとリポジトリを更新して、ウェーブのステータスを反映します。
### ゲート終了条件
次のプロジェクトガバナンスアクティビティが完了したら、次のゲートに進みます。
+ すべての利害関係者は、移行されたアプリケーションとサーバーを確認しました。
+ 移行チームは、カットオーバー中またはハイパーケア期間中に特定されたアプリケーションまたはサーバーの問題に対処しました。
+ クラウド運用チームは、移行されたアプリケーションとサーバーを受け入れる準備ができていることを確認しました。
+ ウェーブステータスを反映するために、すべてのプロジェクト管理ツールとリポジトリを更新しました。
## ゲート 9: ハイパーケア期間の終了
ハイパーケア期間は通常 1～4 日間続き、移行チームが移行されたアプリケーションまたはサーバーに関する問題を解決すると終了します。ハイパーケア期間の終了時に、移行チームはクラウド運用 (Cloud Ops) チームと協力して、移行されたアプリケーションとサーバーを確認します。このゲートでは、移行チームは移行されたワークロードの継続的なサポートを Cloud Ops チームに転送します。Cloud Ops チームは、ハイパーケア期間が完了したこと、および問題が発生した場合の連絡窓口になったことをアプリケーション所有者に通知します。必要に応じて、このコミュニケーションにアンケートを含め、アプリケーション所有者を招待して、移行とカットオーバーのプロセスに関するフィードバックを提供できます。
1. 移行したアプリケーションとサーバーをクラウド運用チームの設定管理データベース (CMDB) に組み込みます。
1. ServiceNow などの Cloud Ops 技術管理サポートツールにアプリケーション情報を組み込みます。
1. 各ゲート[ステップ 3: ゲートごとに標準の E メールテンプレートを作成する](task-create-communication-gates.md#step-email-templates)用に で作成した*ハイパーケア完全通信 E* メールを送信します。ウェーブ情報の E メールをカスタマイズし、クラウド運用チームに連絡する方法の手順を含めます。
1. 移行をインフラストラクチャサポートチームに通知し、ソースサーバーとサポートインフラストラクチャの廃止プロセスを開始します。通常、このステップは Cloud Ops チームまたはプロジェクトマネージャーによって実行されます。
### ゲート終了条件
このゲートは、次のプロジェクトガバナンスアクティビティを実行すると完了します。
+ Cloud Ops は、すべてのワークロード関連情報を CMDB に組み込みました。
+ Cloud Ops は、すべてのアプリケーション情報を技術管理サポートツールに組み込みました。
+ *ハイパーケアの完全なコミュニケーション E* メールをすべての利害関係者に送信しました。
+ インフラストラクチャチームは、不要になったサポートインフラストラクチャの廃止を開始しました。