チームの編成と構成 - AWS 規範ガイダンス

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

チームの編成と構成

このセクションでは、次のトピックについて説明します。

チームの組織と構成のベストプラクティス

大規模な移行におけるチーム構成は、組織やプロジェクトの過程での変更によって異なります。以下は、すべての大規模な移行プロジェクトに共通するベストプラクティスです。

  • プロジェクトレベルでシングルスレッドのテクニカルリーダーを特定し、サイロにならないようにする — 大規模な移行プロジェクトには、複数のワークストリームとチームがあり、各チームには異なるタスクと期待される成果があります。プロジェクトレベルでシングルスレッドのリーダーが重要になるのは、このリーダーがすべてのワークストリームが連携し、接続を維持するようにするためです。これにより、サイロや境界を防ぐことができます。例えば、ポートフォリオワークストリームは、移行アクティビティをサポートするために、移行メタデータを移行ワークストリームに継続的に送信する必要があります。必要な移行メタデータを完全に理解しないと、ポートフォリオワークストリームの出力が移行ワークストリームの入力として機能しない可能性があります。シングルスレッドリーダーを使用すると、各ワークストリームの入力と出力を調整して、移行を効率的に実行できます。

  • すべてのワークストリームレベルの成果をプロジェクトレベルのビジネス成果に合わせる — プロジェクトレベルのビジネス成果は、移行を開始する前に、すべてのワークストリームリーダーに伝える必要があります。各ワークストリームリーダーは、ワークストリームの役割を理解し、プロジェクトレベルのビジネス成果をサポートするようにプロセスを設計する必要があります。例えば、プロジェクトレベルのビジネス成果が今後 12 か月以内にデータセンターを離れ、スピードが最も重要な要因である場合、ワークストリームリーダーは次のことを行う必要があります。

    • すべてのワークストリームは、リホスト移行を優先し、手動タスクの数を減らし、速度を向上させるための自動化を追加する必要があります。

    • ポートフォリオワークストリームは、ターゲット環境の設計に必要な時間を短縮するために、標準化されたパターンを定義し、カスタマイズ可能なパターンを制限する必要があります。

  • プロジェクトの範囲とステージに基づいてワークストリームを設計する — すべての移行プロジェクトが異なり、1 つのサイズがすべてに収まるわけではありません。大規模な移行プロジェクトには、移行ワークストリーム、ポートフォリオワークストリーム、プロジェクトガバナンスワークストリーム、基盤ワークストリームの 4 つのコアワークストリームを用意することをお勧めします。ユースケースに応じて、サポートするワークストリームを追加で作成することもできます。ワークストリームの詳細については、「大規模な移行におけるワークストリーム」を参照してください。例えば、準備段階でセキュリティガードレールをまだ設計していない場合は、移行を開始する前にセキュリティとコンプライアンスの要件を定義できるセキュリティとコンプライアンスのワークストリームを作成する必要があります。準備段階でのセキュリティガードレールの構築の詳細については、「組織の準備を行って大規模な移行を加速する」の「セキュリティ、リスク、コンプライアンス」を参照してください。

  • 移行前にアプリケーションチームを関与させる — 大規模な移行は IT インフラストラクチャプロジェクトにすぎず、ビジネスの運用モデルが変わります。大規模な移行プロジェクトを成功させるには、アプリケーションチームを早期に関与させ、アプリケーション所有者を大規模な移行ワークストリームに埋め込むことが重要です。例えば、ポートフォリオ評価中に、アプリケーションの所有者と早期に会議をスケジュールし、詳細な調査に参加して、 でのアプリケーションの目標状態を設計できるようにしますAWS。

  • ワークストリームとビジネス成果に基づいてチームサイズを決定する — 期待されるビジネス成果と移行戦略によって、ポッドと呼ばれる小さなユニットで構成される各チームのサイズが決まります。ワークストリームごとに、移行戦略ごとにチームを定義し、それらのチームをポッドに分割します。例えば、リホストが主要な移行戦略である場合は、3~5 人のポッドで構成されるリホスト移行チームが必要です。ピーク速度で運用する場合、移行チームの 4~5 人のポッドは、通常、1 週間あたり最大 50 台のサーバーをリホストできます。これは、1 か月あたり約 200 サーバー、つまり 1 年あたり約 2,500 サーバーです。ターゲットが 1 週間あたり 100 台のサーバーをリホストする場合は、リホスト移行チーム内に 4~5 人のポッドを 2 つ作成する必要があります。1 週間あたり 50 未満をターゲットにしている場合は、移行ポッドのサイズを 3 人に減らすことができます。リプラットフォーム移行には通常、リホストよりもコストがかかり、同じサイズのポッドは 1 週間あたり最大 20 台のサーバーを移行できます。ポートフォリオワークストリームは通常、移行ワークストリームの半分のサイズです。各移行戦略をサポートするために、各ワークストリームに追加のチームやポッドを作成します。これらの推奨事項は、移行リソースに十分な知識があり、大規模なトレーニングを必要としないことを前提としています。次の表は、移行とポートフォリオのワークストリームを、リホストとリプラットフォームの移行戦略のためにチームやポッドに分割する方法の例です。次の例では、1 週間あたり 120 台のサーバー (100 リホスト + 20 リプラットフォーム) または 1 年あたり 6,000 台のサーバーを移行する必要があることを前提としています。この例は最大速度です。遅延を防ぐため、追加のリソースを計画することをお勧めします。

    ワークストリーム Team ポッド リソース

    移行ワークストリーム

    移行チームのリホスト

    移行ポッド 1 のリホスト

    4~5 人

    移行ポッド 2 のリホスト

    4~5 人

    移行チームを再プラットフォームする

    移行ポッドのリプラットフォーム

    4~5 人

    ポートフォリオワークストリーム

    ポートフォリオチーム

    ポートフォリオポッド 1

    3~4 人

    ポートフォリオポッド 1

    3~4 人

  • 初期段階でガバナンスモデルを構築する — 大規模な移行には、通常、自社、サードパーティのソフトウェアベンダー、システムインテグレーター、外部コンサルタントなど、多くの人が関与します。プロジェクトにはAWS、アカウントチーム、サポートエンジニア、 AWS プロフェッショナルサービスのエキスパートなど、 の担当者が含まれる場合があります。配信モデルは、プロジェクトの範囲と、プロジェクトを配信するために作業するユーザーによって異なります。例えば、プロジェクトに AWSまたは システムインテグレーターが含まれている場合もあれば、両方が含まれている場合もあります。ガバナンスモデルを早期に構築し、役割と責任を明確に定義する RACI マトリックスを作成することが重要です。推奨事項として、Cloud Center of Excellence とも呼ばれる Cloud Enablement Engine (CEE) を組織内に作成し、すべての関係者からの表現を含めることをお勧めします。CEE の主な目的は、組織をオンプレミスの運用モデルからクラウド運用モデルに変換することです。この集中型チームは、関係を管理し、重要な決定を行い、プロジェクト全体のエスカレーションを処理するため、大規模な移行を成功させる上で不可欠です。CEE については、このガイドの後半で詳しく説明します。

RACI 行列の作成

大規模な移行プロジェクトは通常、多くの人が関与するため、ガバナンスモデルの構築はプロジェクトを管理する上で重要です。ガバナンスモデルの主なコンポーネントの 1 つは RACI マトリックス で、大規模な移行に関係するすべての関係者の役割と責任を定義するために使用されます。RACI マトリックスという名前は、マトリックスで定義されている 4 つの責任タイプから導出されます。

  • 責任 (R) – この役割では、タスクを完了するための作業を実行する責任があります。

  • 説明責任 (A) – この役割には、タスクを確実に完了させる責任があります。この役割は、前提条件が満たされていることを確認し、責任者にタスクを委任する責任もあります。

  • 協議(C) – タスクに関する意見や専門知識については、この職種に相談する必要があります。タスクによっては、この責任タイプは必要ない場合もあります。

  • 情報提供(I) – この役割にはタスクの進捗状況を常に了解し、タスクが完了したら通知を受信する必要があります。

大規模な移行は複雑であるため、大規模な移行のすべてのタスクを文書化するために 1 つの RACI マトリックスを使用することはお勧めしません。マルチレイヤー RACI マトリックスは、はるかにアクセス可能なアプローチです。まず、高レベルの RACI マトリックスを構築し、次に各セクションに詳細を追加して詳細なマトリックスを作成します。詳細な RACI マトリックスの構築は 1 回限りのアプローチではありません。ポートフォリオを進めるにつれて新しい行列を構築するか、既存の行列に詳細を追加し、移行戦略とパターンをさらに発見する必要があります。

基盤プレイブックテンプレート では、RACI テンプレート (Microsoft Excel 形式) を独自の高レベルおよび詳細な RACI マトリックスを構築するための出発点として使用できます。このテンプレートには、リホスト移行用とリプラットフォーム移行用の 2 つの詳細な RACI 行列の例が含まれています。これらの例のタスクはサンプル目的でのみ含まれているため、ユースケースに基づいてこれらの例をカスタマイズする必要があります。

高レベルの RACI マトリックスを構築する

高レベルの RACI マトリックスの構築を開始する前に、次の情報を準備しておく必要があります。

  • この移行に関与する高レベルの関係者は誰ですか? AWSプロフェッショナルサービスやシステムインテグレーターなど、このプロジェクトに関与するパートナーやコンサルタントを特定します。現在の IT インフラストラクチャの一部が外部パートナーによって管理されているかどうかを検討します。以下は、高レベルの関係者の例です。

    • 組織

    • AWS プロフェッショナルサービス

    • システムインテグレーター

  • 移行のワークストリームは何ですか? 詳細については、「大規模な移行におけるワークストリーム」を参照してください。少なくとも、4 つのコアワークストリームが必要で、プロジェクトに必要なサポートワークストリームを追加できます。

  • 移行における大まかなタスクは何ですか? 移行の高レベルタスクのリストを作成します。以下は、高レベルのタスクの例です。

    • AWS ランディングゾーンを構築する

    • ポートフォリオ評価を実行し、移行メタデータを収集する

    • リホスト、リプラットフォーム、または再配置の移行を実行する

    • アプリケーションのテストとカットオーバーを実行する

    • プロジェクト管理とガバナンスのタスクを実行する

高レベルの RACI マトリックスを構築するには、以下を実行します。

  1. 基盤プレイブックテンプレート で、RACI テンプレート (Microsoft Excel 形式) を開きます。

  2. 高レベルの RACI タブの最初の行に、組織名と特定したパートナーを入力します。

  3. 最初の列に、特定した高レベルのタスクとワークストリームを入力します。

  4. マトリックスで、次のように各タスクを担当する当事者を決定します。

    • タスクを完了する責任が当事者にある場合は、R を入力します。

    • 関係者がタスクを担当している場合は、「」と入力します。

    • タスクについて当事者に相談する必要がある場合は、C を入力します。

    • タスクについて当事者に通知する必要がある場合は、I を入力します。

次の表は、高レベルの RACI マトリックスの例です。

タスク 組織 パートナー A パートナー B パートナー C

AWS ランディングゾーンを構築する

R/C

A

I

I

ポートフォリオ評価とウェーブプランニングを実行する

R/C

A

I

I

リホスト移行アクティビティを実行する

C

C

R/A

I

リプラットフォーム移行アクティビティを実行する

C

C

I

R/A

プロジェクト管理とガバナンス

R/C

A

I

I

アプリケーションの変更とテスト

C

R/A

C

C

クラウドオペレーション

I

C

R/A

I

詳細な RACI 行列を構築する

高レベルの RACI マトリックスを作成したら、次に高レベルのタスクごとに詳細な RACI を作成し、タスク、関係者、所有権をさらに絞り込みます。詳細な行列の構築を開始する前に、次の情報を準備しておく必要があります。

  • 移行の詳細なタスクは何ですか? 大規模な移行プロジェクトのランブックとタスクリストを準備したら、これらのランブックのプロセスと詳細が RACI マトリックスの詳細なレイヤーを形成します。例えば、リホスト移行の場合、詳細なタスクには、レプリケーションエージェントのインストール、レプリケーションの検証、起動テスト用のテストインスタンスの起動などがあります。まだ作成していない場合は、次のプレイブックの指示に従ってこれらのドキュメントを作成します。

  • 各ワークストリームと各高レベルのパーティーを構成する小規模なチーム 例えば、組織内のチームには、アプリケーションチーム、インフラストラクチャチーム、運用チーム、ネットワークチーム、プロジェクト管理オフィスなどがあります。

詳細な RACI マトリックスを構築するには、以下を実行します。

  1. 高レベルの RACI マトリックスを開きます。

  2. 詳細な RACI (テンプレート) スプレッドシートのコピーを作成します。

  3. 「」で特定した高レベルのタスクのコピーされたスプレッドシートに名前を付けます高レベルの RACI マトリックスを構築する

  4. 最初の行に、この高レベルのタスクに関係するチームの名前を入力します。

  5. 最初の列に、この高レベルタスクで特定した詳細なタスクを入力します。詳細なタスクを論理的なシーケンシャルグループにグループ化して、読者がマトリックス内を移動するのに役立ちます。

  6. マトリックスで、次のように各タスクを担当するチームを決定します。

    • チームがタスクを完了する責任がある場合はR を入力します。

    • チームがタスクを完了する責任がある場合は「」と入力します。

    • タスクについてチームに相談する必要がある場合は、C を入力します。

    • タスクについてチームに通知する必要がある場合は、I を入力します。

  7. 詳細なタスクごとに、1 つのチームだけが責任を持ち、1 つのチームだけが責任があることを確認します。複数のチームが責任または説明責任を果たしている場合、タスクが明確に定義されていないか、明確な所有権がないことを示している可能性があります。

  8. 詳細な RACI マトリックスを特定済みのチームと共有し、すべてのチームがそれぞれの役割と責任に精通していることを確認します。

  9. で特定した高レベルのタスクごとに、このプロセスを繰り返します高レベルの RACI マトリックスを構築する

詳細な RACI 行列の例については、基盤プレイブックの添付ファイル にある RACI テンプレート の RACI リホスト および RACI スプレッドシートの再プラットフォーム を参照してください。

クラウド有効化エンジン (CEE)

CEE を使用するためのベストプラクティス

CEE の目的は、IT 組織をオンプレミスの運用モデルからクラウド運用モデルに変換することです。また、組織や文化の変化を通じて組織を組織を組織的に示す責任があります。ベストプラクティスとして、大規模な移行には CEE を設定することをお勧めします。CEE の明確に定義された基本的なプロセスとガードレールは、大規模な移行に必要な規模と速度を実現するのに役立ちます。CEE の設定については、「クラウド有効化エンジン: 実践ガイド」を参照してください。以下は、大規模な移行プロジェクトの CEE を確立するための追加の推奨事項とベストプラクティスです。

  • CEE チームは、以下の品質を持つ部門横断的なリーダーで構成される必要があります。

    • 深い知識がある

    • 強力な、長期的な内部関係を持つ

    • 大規模な移行の進行状況と成功に関心がある

    • 興味があり、学習したい

    • 主に、または移行のみに集中している

  • CEE チームは、以前に協力した人と、新しいインサイトを提供できる新しいコメンダーを混在させる必要があります。

  • CEE チームは、移行目標に対する強力なエグゼクティブサポートと調整が必要です。

  • CEE チームの目標が大規模な移行に固有であることを確認します。

  • 質問や回答の機会を提供し、クラウドサービスとアーキテクチャを実証し、移行の成功やその他の成功に関する最新情報を共有する定期的なオープンな会議を実施してください。

  • CEE チームは、大規模な移行プロジェクトに関する重要な決定を行う権限を与える必要があります。

大規模な移行における一般的な CEE の役割と責任

次の表は、大規模な移行 CEE チームの役割と、各役割の一般的なタスクと責任を示しています。チームの実際の構成とその責任は、ユースケース、範囲、ビジネス目標によって異なる場合があります。

ロール タスクと責任

エグゼクティブスポンサー

  • エスカレーションの管理

  • 移行の目的と重要性について組織を緊密に調整する。

  • 権限の声としての行動

エンタープライズアーキテクトまたはプロジェクトレベルのテクニカルリード

  • 既知のワークロードタイプのリファレンスアーキテクチャの特定と文書化

  • すべてのワークストリームにわたるプロジェクト全体の移行プロセスの設計と構築

  • すべてのワークストリームがコラボレーションし、同じビジネスレベルの目標を達成するために作業していることを確認する、シングルスレッドのテクニカルリーダーとして行動する

  • 主要なアプリケーションと一般的なアーキテクチャに関する強力な知識

プロジェクト管理オフィスリーダー

  • タイムライン、オンボーディング、トレーニング、ドキュメント、レポート、コミュニケーション、リソースガバナンスの管理

  • リソースとトレーニングの管理

  • 移行関連のオペレーティングシステムの管理

移行リード

  • 移行プロセスとツールの設計

  • 移行戦略と自動化の設計

  • 移行のカットオーバーを監視し、目標速度を達成する

ポートフォリオリード

  • ポートフォリオ評価とウェーブ計画のプロセスとツールの設計

  • ポートフォリオの検出とデータ収集プロセスの設計

  • 移行メタデータとウェーブプランの継続的な提供を監視する

クラウドオペレーションリード

  • でワークロードを実行するための運用モデルの設計 AWS

  • モニタリング、インシデント対応、タグ付け、ビジネス継続性、ディザスタリカバリ戦略のための戦略の設計

アプリケーションチームリーダー

  • 個々のアプリケーション所有者との関係の管理

  • アプリケーションの移行計画とカットオーバーの管理

  • アプリケーションの変更、テスト、承認の管理

ネットワークとインフラストラクチャのリード

  • ターゲットアカウントのAWSランディングゾーンの設計

  • ネットワーク接続とインフラストラクチャの設計

  • セキュリティグループの設計とデプロイ

  • 大規模な移行をサポートするインフラストラクチャとネットワークの変更の管理

ライセンスリード

  • すべての商用 off-the-shelf (COTS) およびエンタープライズアプリケーションを特定し、移行チームやアプリケーションチームと協力してライセンスに関する移行戦略を計画する

セキュリティおよびコンプライアンスリーダー

  • Active Directory、シングルサインオン、IAM ポリシーなど、大規模な移行のための認証と承認の設計

  • オンプレミスのファイアウォールを含むネットワークセキュリティの設計と脆弱性の管理

  • 対象範囲内のワークロードのコンプライアンス要件の設計