演習 - クラウド導入計画をカスタマイズする

完了

この演習では、前の評価ステップからデータを取得して、テンプレート化されたクラウド導入計画を作成します。 そのデータドリブン プランは、新しい革新的なワークロードの移行とデプロイに関連する作業を管理するのに役立ちます。

クラウド導入計画をカスタマイズする

クラウドで必要とされるすべてのワークロードと資産を考慮した計画を作成したくなります。 チームに、十分に確立されたクラウド導入のプロセスと、選択したクラウド プロバイダーに関する広範な経験がない場合、そのような計画を作成すると、誤った認識が生まれ、不要なリスクが発生する可能性があります。

代わりに、適切に定義された少数のワークロードを使用して計画をカスタマイズおよびテストし、クラウド導入の最初のウェーブを作成します。 このユニットでは、Tailwind Traders が最初の導入計画を構築する方法について説明します。 この会社では、次の手順を使用します。

  1. ワークロードの最初のウェーブを追加する
  2. 依存アセットと各ワークロードを関連付ける
  3. ワークロードの優先度を付ける
  4. 移行タスクをチームとして評価する
  5. タスクを見積もり、推定時間内に完了することを試みる
  6. デプロイされたワークロードをテストする
  7. プロセスと見積もりを調整する
  8. より包括的な導入計画に初期学習を適用する

クラウド導入計画テンプレートを開く

このモジュールの最初のユニットでは、クラウド導入計画テンプレートを使用して、Azure DevOps でバックログを作成しました。 そのユニットの最後の手順では、そのプロジェクト計画のエピック階層ビューに URL を保存することをお勧めしました。 そのリンク (または最初のユニットの手順) を使用して、そのテンプレートによって作成されたバックログまたはプロジェクト計画を開きます。

ワークロードを追加する

ここで、プロジェクト計画にワークロードをいくつか追加します。 前のユニットの終わりに、Tailwind Traders のデジタル資産から一連のワークロードを特定しました。 実際の計画を作成するときは、最初の移行で 10 個のワークロードをターゲットにすることもできますが、簡潔にするために、前のユニットで特定した 6 つのワークロードのみを対象とします。

Note

仮想デスクトップとバックアップ ソリューションのワークロードは、ワークロードではなく、テクノロジ プラットフォームと見なされる場合があります。 しかし、移行の間に資産のコレクションをクラウドにデプロイする方法に関しては、そのような区別はほとんど意味がありません。

  • フォームを開いてワークロードを追加する:バックログで[クラウド移行] エピックを展開し、移行予定のすべてのワークロードを表示してください。 クラウド移行エピックの右側にある省略記号を選択して、メニューを表示してください。 ポップアップ メニューで、[リンクの追加] をポイントしてから、[新しい項目] を選択します。

    Screenshot that shows the menu options for adding a workload.

  • 計画に新しいワークロードを追加する: 最初のフォームでは、このワークロードを計画に追加するための基本的なデータが要求されます。 この質問は、ワークロードの用語ではなく、Azure DevOps の用語で行われます。 移行するすべてのワークロードを、クラウド移行 エピックの子要素としてバックログに追加します。 すべてのワークロードは機能として入力され、ワークロードをサポートするすべての依存資産を移行するために必要な作業量が設定されます。 ワークロード名を入力して、このフォームを完成させます。 この演習では、リンクの種類として [子] を選択し、作業項目の種類として [機能] を選択し、最初のワークロードのタイトルとして モバイル クーポン を入力し、フォームの下部にある [OK] を選択します。

    Screenshot that shows creating a new workload (feature).

  • ワークロードのデータを入力する: これらの最初の少数のワークロードでは、移行チームが運用環境への移行を完了するために必要と思われる最小限の量のデータに注目します。 ワークロードの名前は、前のフォームから引き継がれているはずです。 [説明] ボックスに、このワークロードに関連付けられるすべての資産にタグ付けする必要がある重要な情報を入力してください。これは、重要度、データの機密度、ワークロード タグ、ビジネス グループ、ワークロードの所有者、運用のコミットメント、ワークロードのライフサイクル全体にわたって保持する必要があるその他の情報などです。 最初からベスト プラクティスを確立するには、このワークロードの移行が成功したかどうかを検証するテスト要件の概要を説明することで、このフォームでの最初のディスカッションを始めます。 [保存して閉じる] を選択して、ワークロードの情報を保存します。

    Screenshot that shows the new feature form.

最初の移行ウェーブの各ワークロードについて、これらの手順を繰り返します。 この演習では、Tailwind Trader の 6 つの各ワークロード (モバイル クーポン、ビデオ シェルフ、リモート ストア POS、従業員スケジュール、仮想デスクトップ、バックアップ ソリューション) を表す機能を計画内に作成します。

資産を追加する

ワークロードをサポートするために必要なインベントリ内の各資産を、実際の作業を管理するために計画に追加する必要があります。 次のプロセスでは、対応するワークロードに各資産を追加する方法を示します。

Note

わかりやすくするため、各資産に名前ではなく、番号を付けます。 実際のプロジェクトでは、技術的な作業に役立つよう、名前とその他のメタデータの側面を記録します。

  • フォームを開いて新しい資産を追加する: バックログで [モバイル クーポン] 機能を展開します。 [モバイル クーポン] の右側にある省略記号を選択して、メニューを表示します。 ポップアップ メニューで、[リンクの追加] をポイントしてから、[新しい項目] を選択してください。

    Screenshot that shows the menu options for adding an asset.

  • 計画に新しい資産を追加する: 新しいワークロードの追加プロセスと同様に、最初のフォームでは、この資産を計画に追加するための基本的なデータが要求されます。 移行するすべての資産を、関連するワークロード機能の子要素として、バックログに追加する必要があります。 資産の移行は一連のタスクに基づく個別の測定可能な成果であるため、すべての資産はユーザー ストーリーとして入力されます。 資産名を入力して、このフォームを完成させます。 この演習では、リンクの種類として [子] を選択し、作業項目の種類として [ユーザー ストーリー] を選択し、最初の資産のタイトルとして「資産 #1」と入力します。 フォームの下部にある [OK] を選択します。

    Screenshot that shows creating a new asset.

  • 資産データを入力する:資産名は、前のフォームから引き継がれているはずです。 [説明] ボックスに、資産の種類 (VM、データ、アプリケーション)、現在のネットワーク セグメント化、既知の依存関係、資産固有のタグ、資産の移行に役立つその他の情報などの、この資産に関する重要な情報を入力します。 ベスト プラクティスを最初から確立するには、受け入れ基準についての検討から始めます。 [受け入れ基準] ボックスを使用して、クラウドへのデプロイ後に、この資産をテストする方法と担当者の詳細を入力します。 [保存して閉じる] を選び、資産の情報を保存してください。

Screenshot that shows the new user story form.

ワークロードの優先度を付ける

バックログのエピック階層ビューでは、一覧でワークロードを上下にドラッグして、優先順位を反映し、移行するワークロードのシーケンスの確立を始めることができます。

計画内のワークロードの数が増えるにつれて、このアプローチでは、必要な明確さを実現するのに十分な堅牢性が得られない可能性があります。 任意のワークロードを選択し、この初期ワークロードの追加に使用する作業項目編集フォームを開きます。 そのフォームの [計画] セクションで、優先順位、リスク、ビジネス価値、または時間の重要度のフィールドを使用して、より永続的な優先順位の値を示すことができます。

最も重要なことは、移行するワークロードのウェーブを定義することで、完了する作業の優先順位が設定されるということです。 同じフォームで、[イテレーション] ドロップダウン リストを使用して、各ワークロードのイテレーションを設定できます。

フォームを使って優先順位の値を設定する場合は、終了時に忘れずに [保存して閉じる] を選んでください。

Screenshot that shows different ways to record workload prioritization.

移行タスクをチームとして評価する

クラウド導入計画テンプレートを使用すると、移行に必要なさまざまな作業を示すために、サンプルのワークロード テンプレートがデプロイされます。 選択した移行方法によっては、必要なタスクが異なる場合があります。

資産の移行: すべての移行アプローチで中核になるのは、資産ごとに完了する必要がある単純な 2 ステップのプロセスです。つまり、互換性の評価と資産の移行です。 ほとんどのチームは、サイズの最適化、セキュリティと管理の設定の構成、その資産の構成の文書化などを行う基本的なプロセスも追加します。 これらのタスクは、デジタル資産のすべての資産に対して繰り返すことができます。 テンプレートには、各タスクを完了するための手順へのリンクが含まれています。

資産の移行は小規模で戦術的な取り組みでは問題ありませんが、Tailwind Traders が完了する必要があるような高度な移行や導入作業のニーズを満たす場合、そのアプローチはスケーリングされません。

ワークロードの移行: これらのプロセスを拡張するには、ワークロードの移行の方が有効である場合があります。 この方法では、テンプレートで各資産に関連付けられているタスクを無視できます。 資産は、Azure Migrate などのツールを使用して一括で移行されます。 評価、サイズ設定、依存関係、テスト、ドキュメント化も、ワークロードごとに 1 回行われるので、重複するタスクが減ります。 ワークロードが移行されると、既存の資産も使用停止になるので、使用されていない資産を廃止し、継続的なコストを削減できます。

ワークロードの移行は、はるかに効率的ですが、作業の対象が数千の VM になると、スケール ポイントに達する可能性もあります。

移行ファクトリ: この最も拡張性が高く、繰り返しやすいオプションでは、チームが経験を積んだ後、移行ファクトリを構築することができます。 クラウド導入フレームワークのプロセスの改善に関するセクションでは、考慮すべきプロセスが多数用意されています。

タスクの追加

プロセスをサポートするために必要なタスクをチームが実行できるようになったら、各ワークロードや資産にこれらのタスクを追加できます。

前述の手順と同様に、ワークロードまたは資産の横にある省略記号を選択してタスクを追加します。 唯一の違いは、[作業項目の種類] ボックスから [タスク] を選択して、このタスクに関連付けられている割り当てと作業を追跡するという点です。

Screenshot that shows adding tasks.

ワークロードにタスクを直接追加する場合は、ユーザー ストーリーを追加して、作業をグループ化し、割り当てに役立てることもできます。 テンプレートには、次の図に示すように、作業をグループ化するユーザー ストーリーの例を示しています。

Screenshot that shows group tasks in user stories.

タスクを見積もり、推定時間内に完了することを試みる

チームが含めることに合意したタスクごとに、作業を完了するために必要な時間を見積もります。 [最初の見積もり] テキスト ボックスに推定時間を入力し、[保存して閉じる] を選んでください。

最初のイテレーションの間に毎日チームでミーティングを行い、作業の進捗状況を把握します。 毎日のミーティングで、[残り][完了] の時間の値を更新してください。 こうすることで、チームは、各タスクの実行に伴う難しさを注視し、将来の見積もりを調整することができます。 最初の数回のイテレーションでは、得られた経験を保持できるよう、完了した作業について観察した内容を [ディスカッション] ボックスに記録してください。

Note

チームが作業を進めるにつれて、同意した作業の一部が不要に見えることがあります。 継続的な学習のために、すべてのタスクがイテレーションの間に完了するようにしてそれらの外観を検証し、それらを将来のイテレーションで調整します。 不要なタスクにより、ユーザー ストーリーまたは移行作業の実現が妨げられないようにします。

展開をテスト

各資産がデプロイされたら、テストを実行し、完了と、初期設計への準拠を検証します。

各ワークロードの最後の資産がデプロイされたら、アーキテクチャ、パフォーマンス、サイズを検証します。 最も重要なのは、可能な限り、実際のビジネス ユーザーでワークロードのテストを実行することです。

振り返ってプロセスと見積もりを調整する

最初のイテレーションの最後に、チームで集まって、作業したことと、しなかったことについて話し合います。 また、止めること、続けること、増やすことについてのチームの意向を確認します。

これらの簡単な考慮事項を、次のイテレーションに含めるタスクの一覧に適用します。 また、タスクに費やした時間を使用して、チームから新しい見積もりを通知することもできます。

より包括的な導入計画に初期学習を適用する

自分の最初の 3 つのイテレーションに、この記事の手順を繰り返して、プロセスの学習と再調整を続けます。 数回繰り返した後、チームは、必要なタスク、それらのタスクを必要とする時間、およびデジタル変換プログラム全体を成功に導く全体的なプロセスを理解するようになっているはずです。

各イテレーションの実行と並行して、プロジェクト マネージャーは前のユニットの評価データを使用し、より多くのワークロードと必要な資産が含まれる、いっそう充実した計画を作成する必要があります。

一般的な規則として、プロジェクト マネージャーは、最初の数回のイテレーションで、イテレーションごとに 10 個のワークロードを読み込む必要があります。 さらに振り返りを完了すると、2 週間のイテレーションでチームが完了できるワークロードの数が明らかになります。 一部の成熟したチームは、数百または数千もの資産を 2 週間のスプリントで移行できる場合もあります。 ただし、それらの資産がサポートするワークロードのテストと運用リリースには時間がかかります。

ほとんどの移行プロジェクトは、初回のイテレーション実行の最初の数週間で、読み込み、優先順位付け、イテレーションへの割り当て、および見積もりを行うことができるようになるはずです。 通常、3 番目のイテレーションが完了するまでに、プロジェクトの期間とタイムラインの精度は安定します。

デジタル資産を大規模に統合する

Microsoft Excel 用の Teams アドインを使用すると、ワークロード、資産、タスクなどをいっそうすばやく追加できます。 次のユニットの「次の手順」セクションには、最初のクラウド導入計画で提供されるワークロード テンプレートを使用して多数のワークロードと資産を読み込む方法を説明する一連の記事へのリンクが示されています。

パートナー エンゲージメント

クラウド導入フレームワークの承認されたオファーを提供する Microsoft パートナーは、移行の計画と実行を加速し、組織で必要になる定期的な作業の量を大幅に削減できます。 経験豊富なパートナーから提供されるオファーについては、クラウド導入フレームワーク パートナーのオファー サイトを参照してください。