役割と責任を一致させる
Azure 移行の成功には、組織の文化とデータセンターの管理を理解することが不可欠です。 明確な役割を持つ一元化された IT チームはプロセスを容易にしますが、大規模な企業やコンプライアンスに対応している企業は、進歩を妨げる可能性のある微妙な課題に直面しています。
Azure クラウド導入フレームワークは、移行における組織の連携の役割を強調し、部門間コラボレーションを推進して主要な機能を果たします。
この記事では、次の内容について説明します。
- クラウド戦略とクラウド導入機能に合わせた移行固有のロール。
- ランディング ゾーン アーキテクトやワークロード アーキテクトなど、移行プロセス中に他の機能に必要になる可能性のあるサポート ロール。
- 移行プロジェクトのロールに関連する専門家または所有者を特定する方法。
- 移行プロジェクトのどの部分に責任があるかを理解するのに役立つ責任マトリックス。
ヒント
メンションされる役割は、特定の役職と一致しない場合や、専用のチーム メンバーが必要な場合があります。 多くの場合、1 人のユーザーが複数の役割を担当することも、複数のチーム メンバーが責任を共有することもできます。 この一覧では、一般的な責任の概要を説明していますが、スタッフガイドではありません。 重要なのは、組織内でこれらの責任が確実に満たされるようにすることです。
クラウド戦略機能の役割
移行プロジェクトに必要なコミットメントと組織があることを確認するには、クラウド戦略機能に次のロールが必要です。 次の表では、クラウド戦略関数の役割とその責任について説明します。
| ロール | 責任 |
|---|---|
| プロジェクト スポンサー | 移行のスコープを定義して、移動するリソースと各リソースを移動する利点を決定します。 移行ツールの購入、全体的なワークロード アーキテクチャ、およびリリース アクティビティの意思決定所有権を提供します。 |
| プロジェクト マネージャー | 移行スコープのプロジェクト計画を推進します。 テスト プロセスを駆動します。 関係者に対する状態の更新を整理します。 |
| 組織の変更マネージャー | プロジェクト チームが変更を組織に伝えるのに役立ちます。 さまざまな機能を使用して、適切なチーム メンバーが関与し、移行をサポートするために正しい組織の変更が行われることを確認します。 |
| ライセンス スペシャリスト | プロジェクトが適切にライセンスされ、既存のライセンスリソースを使用していることを確認するためのライセンス分析情報と財務運用管理を提供します。 |
| ワークロード経営者 | ワークロードの評価、アーキテクチャ、および移行プロセスの意思決定所有権を提供します。 Azure のワークロードのビジネス価値の所有者として機能します。 |
クラウド導入機能の役割
Azure への移行中、クラウド導入機能は技術的な実行の大部分を実行します。 この関数では、次の表に示す役割を用意することを計画します。
| ロール | 責任 |
|---|---|
| 移行アーキテクト | 移行ウェーブ計画やすべての移行プロセスなど、ワークロードの技術的な意思決定を監督します。 |
| 移行エンジニア | プロジェクトの一部として識別されるタスクを実行します。 |
他の関数のサポート ロール
次の表では、他の関数に必要になる可能性があるサポート ロールについて説明します。
| ロール | 責任 |
|---|---|
| ランディング ゾーン アーキテクト | ワークロードをランディング ゾーンに移行するためのサポートを提供します。 ランディング ゾーンのプラットフォーム サービスに関する問題を修復するのに役立ちます。 詳細については、「クラウド プラットフォーム機能」を参照してください。 |
| Cloud Operations Manager | ワークロードを移行するときに適切な管理が行われるように、管理プラットフォームへのワークロードの移行をオンボードするためのサポートを提供します。 詳細については、「クラウド 操作機能」を参照してください。 |
| ワークロード アーキテクト | 移行ワークロードの設計に関するアーキテクチャ ガイダンスと意思決定を提供します。 ワークロードごとに、このロールの複数のインスタンスを満たすために、特定の主題の専門家が必要になる場合があります。 詳細については、「中央 IT 機能」を参照してください。 |
| ユーザー受け入れテスター | 個々のワークロードのテスト ユーザー受け入れテスト (UAT) のフィードバックを提供するために、ワークロードごとにこのロールのインスタンスが複数ある場合があります。 詳細については、「中央 IT 機能」を参照してください。 |
役割の専門家または所有者を特定する
ワークロード アーキテクトやワークロード ビジネス所有者など、これらの役割の一部の適切なリソースを特定することが困難な場合があります。 ワークロードが長期間メンテナンスされ、頻繁に変更が行われない場合、機能をサポートするための所有権情報や技術的専門知識が限られている可能性があります。 たとえば、デジタル資産計画では、サーバーが特定のワークロードにマップされていない場合があるため、所有者が不明な場合があります。
役割を特定するための推奨事項をいくつか示します。
- 履歴データ: 構成管理データベースまたはチケット システムを使用して、メインテナントを要求したユーザー、またはサーバーまたはワークロードについて通信するユーザーを示す履歴項目を特定します。
- サインイン ログ: ワークロード内のサーバーに最近ログインしたユーザーを探します。 この方法では所有者を識別できない場合がありますが、最近のユーザーはサーバーのコンテキストを提供できます。
- 依存関係分析: 依存関係分析ツールを使用して、サーバーでホストされている関数に最も頻繁に接続するユーザーを特定します。 これらのツールは、ビジネス部門を特定するのに役立ちます。これにより、所有者を特定するのに役立ちます。
- 関連するアプリケーション所有者: 同様のビジネス部門または機能にサービスを提供するアプリケーションの所有者に問い合わせてください。 入力する必要があるロールを特定できるように依頼します。 組織内の役割の専門家がいない場合でも、移行プロセス中に役割を入力する必要があります。 ビジネス チームと IT チームは、少なくとも中間メンバーを特定し、移行後にワークロードを長期的にサポートするための所有権の計画を作成する必要があります。
大規模な移行イニシアチブの役割をスケーリングする
移行するワークロードのサイズと数によっては、各役割に複数のチーム メンバーを割り当てる必要がある場合があります。 よいアプローチは、この記事で説明するスケールを、2 週間のスプリントごとに中程度のサイズと複雑さのワークロードを最大 5 つに対して使用することです。
ただし、ワークロードのサイズ設定と複雑さは判断するのが難しい場合があります。 初期の移行ウェーブでは、コア チームから始めますが、必要に応じてスケールアウトします。
スケールアウトする必要がある場合は、次の表に示す役割も計画する必要があります。
| ロール | 責任 |
|---|---|
| プログラム マネージャー | 複数のプロジェクト スコープにわたってプロジェクト マネジメント アクティビティを整理します。 |
| 移行のアーキテクチャ リード | 複数の移行アーキテクト スコープにわたって技術的な卓越性を促進します。 |
責任マトリックスの例
次の表では、この凡例を使用して、移行プロジェクトのステージに対する役割ごとの責任のカテゴリを示します。
- D = ドライバー: 目的の単一のドライバーである組織内の個人。
- = 承認者: 組織内で最も多くの決定を行い、目的が満たされていない場合に責任を負う 1 人以上の個人。
- C = 共同作成者: 目的をサポートするタスクの実行を担当する組織内の個人。
- I = 告知済み: プロジェクトが影響を受け、意思決定とプロジェクトの状態について定期的に通知される組織内の個人。
移行プロジェクトの基礎として、次の責任マトリックスを使用できます。 組織のニーズに応じて、より多くの役割を特定したり、責任をシフトしたりする必要がある場合があります。
| ロール | デジタル資産の検出 | 移行のスコープ | プロジェクト計画 | 移行ツール | ワークロードの検出 | ワークロード評価 | ワークロード アーキテクチャ | ウェーブ計画 | ワークロードのテスト移行 | ワークロードの移行 UAT: | ワークロードの移行: | ワークロードのリリース UAT | 組織の変更管理 | 操作への移行 | ワークロード ライセンス |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 移行アーキテクト | D | D | A | D | A | A | D | A | A | A | A | A | I | D | I |
| 移行エンジニア | C | I | C | C | D | D | C | D | D | C | D | C | I | C | C |
| プロジェクト マネージャー | I | I | D | I | I | I | I | I | I | D | I | D | I | C | I |
| プロジェクト スポンサー | A | A | A | A | I | I | A | I | I | I | A | I | A | A | A |
| ユーザー受け入れテスター | I | I | I | I | I | I | I | I | I | C | I | C | I | C | I |
| ワークロード アーキテクト | I | I | C | C | C | C | C | C | C | C | C | C | C | C | I |
| ワークロード経営者 | I | I | C | I | A | A | A | A | A | A | A | A | C | C | A |
| 組織の変更マネージャー | I | I | C | I | I | I | I | I | I | C | I | C | D | C | I |
| ライセンス スペシャリスト | I | I | C | C | I | C | C | C | I | I | I | I | I | C | D |
| Cloud Operations Manager | C | C | C | I | I | I | I | C | I | I | I | I | C | A | I |
| ランディング ゾーン アーキテクト | I | I | C | C | I | I | C | C | I | I | I | I | I | I | I |