翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# タスク: コミュニケーションプランの作成
ガバナンスモデルの重要な要素は、アプリケーション所有者との通信を担当するユーザーと、アプリケーション所有者が応答しない場合にエスカレーションする方法を特定することです。このタスクでは、コミュニケーションの責任者を定義し、定期的なコミュニケーションと会議の内容を決定し、標準のコミュニケーションテンプレートを作成し、問題をエスカレーションする必要がある場合にどうなるかを決定します。
このタスクでは、以下を実行します。
+ [ステップ 1: コミュニケーションチームを作成する](#step-communications-team)
+ [ステップ 2: エスカレーション計画を確立する](#step-escalation-plan)
+ [ステップ 3: 会議とその頻度を定義する](#step-define-meetings)
+ [ステップ 4: 会議プレゼンテーションを準備する](#step-prepare-presentations)
+ [ステップ 5: ステージ 1 の定期的な会議をスケジュールする](#step-schedule-meetings-stage1)
+ [ステップ 6: 変更管理プロセスを理解する](#step-change-management)
## ステップ 1: コミュニケーションチームを作成する
コミュニケーションチームは、プロジェクトガバナンスワークストリームの一部です。このチームは、主要な移行マイルストーンにおけるプロジェクトのステークホルダーとのコミュニケーション、会議のスケジュール、フィードバックの調整、必要な会議の参加者の出席の確認を担当します。コミュニケーションチームのアクティビティは通常、 で定義したコミュニケーションゲートによって管理されます[タスク: 通信ゲートとスケジュールの定義](task-create-communication-gates.md)。
以下の操作を実行します。
1. このチームの適切なメンバーを特定します。
1. *コミュニケーションリード*を指定します。この個人は、移行期間中、ゲートミーティングのスケジューリング、他のワークストリームからの質問やフィードバックの調整、必要な参加者との会議出席の確認について、単一の連絡窓口として機能します。
## ステップ 2: エスカレーション計画を確立する
移行で問題が発生した場合は、迅速に解決できる必要があります。移行の開始前にエスカレーション計画を定義することで、チームに明確なアクションプランを事前に提供できるため、遅延、フラストレーション、驚きを防ぐことができます。ビジネスユニットごとにシングルスレッドリーダーを指定することをお勧めします。アプリケーション所有者が関与または応答していない場合は、その個人にエスカレーションできます。
通常、このステップはプロジェクトマネージャーとプロジェクトスポンサーによって完了します。エスカレーション計画を確立するときは、問題のタイプ、問題をエスカレーションする状況 (*トリガー*と呼ばれる) を定義し、エスカレーションの階層を定義する必要があります。推奨階層は 3 つまでです。階層ごとに、*対象者*または*応答所有者*、および対象者が応答する必要がある時間を特定する必要があります。たとえば、最初のエスカレーション対象者が 24 時間以内に問題を解決しない場合は 、問題を別の対象者である 2 番目の階層にエスカレーションします。エスカレーションのたびに、以前の階層の対象者を CC します。
以下の操作を実行します。
1. エスカレーション計画を作成します。Jira や Confluence などの専用のプロジェクト管理ツールを使用するか、Microsoft Excel でリストを作成できます。以下を文書化することをお勧めします。
+ 予想される問題または経験した問題の簡単な説明
+ トリガー
+ エスカレーション階層と対象者
+ 各階層が問題に応答する必要がある時間
1. ワークストリームリードとプロジェクトスポンサーとミーティングを行い、エスカレーション計画を確認します。
1. エスカレーション計画をプロジェクトチーム全体と共有し、すべてのメンバーがエスカレーションプロセスに精通していることを確認します。
1. エスカレーション計画を共有リポジトリに保存し、すべてのプロジェクトチームメンバーがアクセスできることを確認します。
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/large-migration-governance-playbook/task-communication-plan.html)
## ステップ 3: 会議とその頻度を定義する
このステップでは、移行プロジェクトの定期的な会議を特定し、会議の頻度または*頻度*を設定します。会議とその頻度を文書化すると、プロジェクトの透明性が向上します。問題が発生した場合、チームメンバーは適切な会議をすばやく特定して対処できます。会議の名前、頻度、主要目標、所有者と参加者を特定する必要があります。移行の進行に伴ってこのドキュメントを更新し、新しい会議参加者を特定する必要がある場合があります。
大規模な移行プロジェクトでは、以下の定期的な会議が一般的です。
1. **運営委員会会議** – これらの会議は通常、月に 2 回開催され、プロジェクトのステータスを共有し、経営幹部の関与を必要とする問題を解決することが目的です。この会議の参加者には、通常、プロジェクトスポンサー、経営幹部、プロジェクト管理オフィスの担当者が含まれます。
1. **プロジェクトステータスレビュー会議** – これらの会議は通常、週に 1 回開催されます。目的は、ワークストリームレベルでプロジェクトのステータスを確認し、リソースまたは対象分野のエキスパートの必要性を評価することです。この会議の参加者には、プロジェクトマネージャー、プロジェクトステークホルダー、ワークストリーム所有者、移行リーダーが含まれます。
1. **毎日のスタンドアップ –** 1 日に 1 回開催される非常に短い会議です。会議は参加者が椅子を必要としないほど短くする必要があるため、スタンドアップと呼ばれます。目的は、計画されたタスクと最近完了したタスクを確認し、問題を明らかにすることです。毎日のスタンドアップでは、通常、 で決定する Kanban ボードやガントチャートなどのビジュアルタスク管理ツールを使用します[ステップ 1: プロジェクト管理ツールを選択する](task-project-management.md#step-pm-tool)。
1. **インフラストラクチャと運用のチェックポイント会議** – これらの会議は通常、週に 2 回開催されます。目的は、移行の進行状況の確認、アクティブな問題の確認、エスカレーションが必要かどうかの判断、ワークストリーム間のコラボレーション、次のスプリントのためのリソースの計画です。この会議の参加者には、RACI が定義した移行アクティビティを所有する技術チームメンバーが含まれます。
1. **移行営業時間** – 今回は、アプリケーション所有者がサポートやガイダンスを求めるためのオープンミーティングとして予約されています。営業時間は週に 3 回保持することをお勧めします。
[プロジェクトガバナンスプレイブック](samples/project-governance-playbook-templates.zip)*テンプレートで利用可能な会議計画*テンプレート (Microsoft Excel 形式) から開始することをお勧めします。このテンプレートにはデフォルトの例が含まれており、プロジェクトに合わせてカスタマイズできます。
## ステップ 4: 会議プレゼンテーションを準備する
で定義されているように[ステップ 3: 会議とその頻度を定義する](#step-define-meetings)、大規模な移行では、ワークストリームを調整し、問題に対処し、移行がスケジュールどおりであることを確認するために頻繁な会議が必要です。これらの会議の標準形式とプレゼンテーションを定義すると、参加者は会議に対する一貫した期待を確立できます。また、各会議の準備にかかる時間を短縮するのに役立ちます。このステップでは、定期的に予定されている会議用のプレゼンテーションテンプレートを作成します。
[プロジェクトガバナンスプレイブックテンプレートに含まれている次のテンプレート](samples/project-governance-playbook-templates.zip)から始めることをお勧めします。
+ *ステータスレポートテンプレート (Microsoft PowerPoint 形式)*
+ *ステアリング委員会会議テンプレート* (Microsoft PowerPoint 形式)
+ *ウェーブワークショップテンプレート* (Microsoft PowerPoint 形式)
+ *カットオーバー準備状況評価テンプレート* (Microsoft Excel 形式)
以下の操作を実行します。
1. プロジェクトの*運営委員会会議テンプレート*をカスタマイズします。
1. プロジェクト*のステータスレポートテンプレート*をカスタマイズします。このプレゼンテーションは、通常毎週開催されるプロジェクトステータスレビュー会議で使用されます。このテンプレートは、前のステップで作成したエグゼクティブレベルの概要のより堅牢なバージョンです。
1. プロジェクトの *Wave ワークショップテンプレート*をカスタマイズします。このプレゼンテーションは、T-28 および T-14 コミット会議で使用されます。T-28 コミット会議では、アプリケーション所有者はウェーブにコミットし、T-14 コミット会議ではカットオーバー日に再コミットします。
1. プロジェクトの*カットオーバー準備状況評価テンプレート*をカスタマイズします。このプレゼンテーションは、インフラストラクチャと運用のチェックポイント会議で、移行アクティビティの現在の進行状況を確認するために使用されます。プレゼンテーションの目的は、進行状況ゲートが満たされ、アプリケーションがカットオーバーの準備が整ったことをチームが確認できるようにすることです。
1. これらのプレゼンテーションテンプレートは、会議所有者がアクセスできる共有リポジトリに保存します。
1. 会議の種類ごとに、会議の所有者がプレゼンテーションを保存できる共有リポジトリを定義します。各会議の後、会議の所有者は、会議の参加者とプロジェクトチームがこの情報を参照できるように、プレゼンテーションのバージョンとその他の会議アーティファクトをこのリポジトリに保存する必要があります。たとえば、プロジェクトステータスレビュー会議のリポジトリには、各会議で提示されたステータスレポートのコピーが含まれます。
## ステップ 5: ステージ 1 の定期的な会議をスケジュールする
動員フェーズを完了した場合は、このステップでいくつかの会議を既に確立している可能性があります。まだスケジュールしていない会議については、このステップを完了します。で作成した会議計画に従って[ステップ 3: 会議とその頻度を定義する](#step-define-meetings)、会議所有者は次の定期的な会議をスケジュールする必要があります。
+ 各ワークストリームの毎日のスタンドアップ
+ 財務報告会議
+ 運営委員会会議
+ プロジェクトのステータスレビュー
+ インフラストラクチャと運用のチェックポイントミーティング
これらの会議は、移行が完了するまで続行されます。
## ステップ 6: 変更管理プロセスを理解する
大規模な移行プロジェクトを成功させるには、組織の変更管理プロセスを理解することが不可欠です。変更管理プロセスは、移行のスケジュールと期限に影響します。各ワークロードに必要な情報と承認を理解する必要があります。以下を理解していることを確認してください。
+ ウェーブプラン内のアプリケーションとサーバーのリストを送信する期限
+ 予定日にワークロードを移動するための承認を取得するために必要な基準と情報
+ 完了する必要がある正式なプロセスドキュメント
+ ファイアウォールまたはドメインの変更を送信するプロセス
すべての移行リードは、検出アクティビティの前に変更管理プロセスを理解する必要があります。一部の移行関連のタスクでは承認が必要であり、チームメンバーは変更管理プロセスにおける各自の責任を理解する必要があります。トレーニングの詳細については、[「大規模な移行のための Foundation プレイブック」の「大規模な移行に必要なトレーニングとスキル](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-foundation-playbook/training-skills.html)*」を参照してください。 AWS *
## タスク終了条件
このタスクは、以下を実行すると完了します。
+ コミュニケーションチームを作成しました。
+ すべての会議に参加者を定義しました。
+ エスカレーション計画を確立し、承認した。
+ 会議計画で定義されているように、ステージ 1 で始まる定期的な会議がスケジュールされている。
+ 各会議で使用する標準プレゼンテーションを定義しました。
+ 会議ごとに、すべてのプレゼンテーション、アクティビティ、アーティファクトをキャプチャするための共有リポジトリを定義しました。
+ すべての変更管理プロセスを理解し、文書化します。