役割と責任を一致させる

[アーティクル]
04/15/2024

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

次のステップ

移行のためのスキルの準備