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

完了

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

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

クラウドで必要なすべてのワークロードとすべての資産を考慮した計画を立てることもできます。 クラウド導入のプロセスが十分に確立されておらず、選択したクラウド プロバイダーとの豊富な経験がない場合、そのような計画によって誤った認識が生じ、不要なリスクが生じる可能性があります。

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

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

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

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

ワークロードを追加する

次に、いくつかのワークロードをプロジェクト計画に追加します。 Tailwind Traders のデジタル資産には、モバイル クーポン、ビデオ 棚、リモート ストア POS、従業員スケジュール、仮想デスクトップ、バックアップ ソリューションの 6 つのワークロードがあります。 実際の計画を作成するときは、最初の移行に 10 個のワークロードをターゲットにすることもできますが、簡潔にするために、これらの 6 つのワークロードのみを対象とします。

手記

仮想デスクトップおよびバックアップ ソリューションのワークロードは、ワークロードではなくテクノロジ プラットフォームと見なされる場合があります。 ただし、移行中、この違いは、資産のコレクションをクラウドにデプロイする方法にほとんど影響を及ぼさはありません。

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

    ワークロードを追加するためのメニュー オプションを示すスクリーンショット。

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

    新しいワークロード (機能) の作成を示すスクリーンショット。

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

    新しい機能フォームを示すスクリーンショット。

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

アセットを追加する

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

手記

わかりやすくするために、各資産に名前を付けるのではなく、番号を付けます。 実際のプロジェクトでは、名前やその他のメタデータの側面を記録して、技術的な取り組みをガイドします。

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

    アセットを追加するためのメニュー オプションを示すスクリーンショット。

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

    新しいアセットの作成を示すスクリーンショット。

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

新しいユーザー ストーリー フォームを示すスクリーンショット。

ワークロードに優先順位を付ける

バックログのエピック階層ビューでは、一覧のワークロードを上下にドラッグして線形優先度を反映し、移行する一連のワークロードの確立を開始できます。

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

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

フォームを使用して優先度の値を設定する場合は、完了したら必ず [保存] & [閉じる] を選択してください。

ワークロードの優先順位付けを記録するさまざまな方法を示すスクリーンショット。

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

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

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

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

ワークロード移行 : これらのプロセスをスケーリングするには、ワークロードの移行がはるかに役立ちます。 この方法では、テンプレート内の各資産に関連付けられているタスクを無視できます。 資産は、Azure Migrate などのツールを使用して一括で移行されます。 ワークロードごとに評価、サイズ設定、依存関係、テスト、およびドキュメントを 1 回完了し、冗長なタスクを削減します。 ワークロードが移行されると、既存の資産も使用停止になり、未使用の資産が廃止され、継続的なコストが削減されます。

ワークロードの移行ははるかに効率的ですが、何千もの VM に集中し始めるとスケール ポイントに達する可能性もあります。

移行ファクトリの: 最も大規模で繰り返し可能なオプションの場合は、自分とチームが追加のエクスペリエンスを得るように移行ファクトリを構築できます。 クラウド導入フレームワークの プロセスの改善に関するセクション、考慮すべきプロセスが多数用意されています。

タスクの追加

チームがプロセスをサポートするために必要なタスクを調整したら、それらのタスクを各ワークロードや資産に追加し始めることができます。

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

タスクの追加を示すスクリーンショット。

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

ユーザー ストーリーのグループ タスクを示すスクリーンショット。

タスクを見積もり、見積もり時間に完了を試みる

チームが含めるに同意するタスクごとに、作業を完了するために必要な時間の見積もりを考え出します。 [元の見積もり] テキスト ボックスに推定時間を入力し、[保存] & [閉じる] 選択します。

毎日、最初のイテレーション中にチームと会い、作業の進行状況を把握します。 残りの 時間と 完了 時刻の値を毎日更新します。 これにより、チームは各タスクを完了することの難しさに細心の注意を払い、将来の見積もりを調整するのに役立ちます。 最初のいくつかのイテレーションでは、ディスカッション ボックスで完了した作業に関する観察を記録して、学習した教訓を保持します。

手記

チームが進むにつれて、合意した作業の一部が不要に見える場合があります。 継続的な学習のために、イテレーション中にすべてのタスクが完了していることを確認し、それらの外観を検証してから、将来のイテレーションで調整します。 不要なタスクが、ユーザー ストーリーや移行作業の提供の阻害要因にならないようにします。

デプロイをテストする

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

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

プロセスと見積もりを絞り込むための振り返り

最初のイテレーションの最後に、チームとして集まり、何が機能し、何がうまくいかなかったかについて話し合います。 また、チームがやりたいこと、やり続ける、またはもっとやりたいことを見てください。

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

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

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

各イテレーションの完了と並行して、プロジェクト マネージャーは前のユニットの評価データを使用して、必要なワークロードと資産の数が多いなど、より豊富なプランを設定する必要があります。

一般的なルールとして、プロジェクト マネージャーは、最初の数回のイテレーションでイテレーションごとに 10 個のワークロードを読み込もうとします。 より多くの振り返りを完了すると、2 週間のイテレーションでチームが完了できるワークロードの数が明確になります。 成熟したチームによっては、2 週間のスプリントで数百または数千の資産を移行できます。 ただし、これらの資産がサポートするワークロードのテストと運用環境のリリースには、より多くの時間がかかります。

最初のイテレーション実行の最初の数週間の間に、移行プロジェクトの大部分を読み込み、優先順位付けし、イテレーションに割り当て、見積もることができる必要があります。 通常、プロジェクトの期間とタイムラインの精度は、3 番目のイテレーションが完了するまでに安定します。

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

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

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

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