翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
タスク 3: アプリケーションの優先順位付けプロセスを定義する
アプリケーションの優先順位付けは、アプリケーションをクラウドに移行する順序を決定するプロセスです。優先度は、アプリケーションをクラウドに移行する複雑さと定義したルールに基づいて評価します。アプリケーションの優先順位付けについて議論する場合、優先度が高いと必ずしもビジネスにとってのアプリケーションの重要性と相関するとは限りません。実際、ビジネスクリティカルなアプリケーションはリスクが高いため、移行の優先順位は通常低くなります。大規模な移行では、ビジネスクリティカルではない低複雑さのアプリケーションを優先し、各ウェーブでは、ますます複雑またはビジネスクリティカルなアプリケーションを移行します。
何百ものアプリケーションが移行用に並んでいる大規模な移行では、すべてのアプリケーションを一度に優先順位付けして計画することはお勧めしません。これは、大規模な移行プロジェクトにとってアプリケーションの優先順位付けプロセスを定義することが重要な理由の 1 つです。アジャイルな方法で移行にアプローチするには、最も優先度の高いアプリケーション (3～10 個のアプリケーション) を選択するか、3～5 個のウェーブに十分なアプリケーションを選択できます。次に、選択したアプリケーションのみのアプリケーション検出とウェーブプランニングを完了します。このアプローチは、大規模な移行の過程でアプリケーションの優先度と波が変化することが多いため、かなりの時間を節約できます。
アプリケーションの優先度に関する一般的な誤解の 1 つは、最も優先度の高いアプリケーションが第 1 ウェーブにあることです。ウェーブプランニングを実行する場合、優先順位が最も高い 10 のアプリケーションのうち、準備が整っていないアプリケーションが最初のウェーブにあるのはわずかである可能性が高いです。これは、依存関係、ビジネス上の制約、リソースの可用性など、さまざまな有効な理由が考えられます。アプリケーションの優先度はウェーブプランニングの重要な要素ですが、考慮すべき唯一の要素であってはなりません。
このタスクでは、アプリケーションの優先順位付けプロセスとルールを定義します。このタスクは、次のステップで構成されます。
次のセクションでは、複雑さのスコアリングについて説明します。このプレイブックには、アプリケーションの優先順位付け方法に関する 3 つのプロセスオプションと、3 つのオプションのうちの 2 つが複雑なスコアリングを使用します。プロセスオプションの詳細については、「」を参照してくださいステップ 1: アプリケーションの優先順位付けプロセスを定義する。アプリケーションの指名プロセスを使用する予定の場合は、複雑なスコアリング基準を定義する必要はなく、 に直接進む必要がありますステップ 1: アプリケーションの優先順位付けプロセスを定義する。
複雑なスコアリング基準について
複雑さスコアリングは、アプリケーションを移行することの難しさを評価するために使用されるプロセスです。これは、アプリケーションを優先順位付けする際の重要な要素です。複雑さのスコアリングには、定義したのと同じ一連のビジネス基準と技術基準に照らしてすべてのアプリケーションを評価する必要があります。アプリケーションを評価するときは、各基準にスコアを割り当てます。ビジネス基準と技術基準のスコアを合計すると、そのアプリケーションの移行の全体的な複雑さを反映する複雑さスコアが得られます。その後、アプリケーションの優先順位付けやウェーブの計画時に複雑さスコアを使用できます。
複雑さスコアリング基準には 2 つのカテゴリがあります。
-
ビジネス基準 – このカテゴリの基準は、アプリケーションが使用できなくなった場合のリスク、セキュリティとコンプライアンスに関する考慮事項、リソースの可用性など、アプリケーションの移行に伴うビジネスの複雑さに関連しています。
-
技術的基準 – このカテゴリの基準は、オペレーティングシステムとそのバージョン、サーバーとユーザーの数、移行戦略など、アプリケーションの移行の技術的複雑さに関連しています。
ユースケースに適したスコアリング基準を決定する必要があります。アプリケーションの複雑さを手動でスコアリングする場合は、ポートフォリオプレイブックテンプレートで、アプリケーションの複雑さのスコアシートテンプレート (Microsoft Excel 形式) に基準とスコア値の標準セットが含まれています。これらの値から始めて、ユースケースに合わせてカスタマイズできます。アプリケーションの優先順位付けに検出ツールを使用している場合、これらのツールには通常標準の条件セットが含まれており、条件を追加、削除、または変更でき、必要に応じて重み付けできます。基準を確立するときは、次の 2 つのセクションの質問を使用して基準を絞り込みます。
ビジネス基準
以下は、複雑なスコアリングで一般的に使用されるビジネス基準です。
| ビジネス基準 | 説明 |
|---|---|
ビジネスへの影響 |
このアプリケーションが使用できなくなった場合のビジネスへの影響を評価します。
|
スタッフの可用性 |
移行中に、アプリケーション所有者、対象分野のエキスパート (SME)、ネットワークまたはインフラストラクチャ管理者、テスター、開発者からのサポートが必要になる場合があります。移行中に役立つこれらのリソースの可用性を評価します。
|
ビジネスの複雑さ |
相互依存および相互接続されたステークホルダー、情報技術システム、組織構造が多数あると、ビジネスの複雑さが増す可能性があります。ビジネスの複雑さを次のように評価します。
|
準備状況 |
アプリケーションを移行する準備ができているかどうかを次のように評価します。
|
セキュリティ |
アプリケーションのセキュリティ要件とセキュリティポリシーの複雑さを次のように評価します。
|
コンプライアンス |
コンプライアンス要件は、州、業界、または企業ポリシーによって提供される法律、規制、ガイドラインなど、アプリケーションに適用される場合があります。アプリケーションのコンプライアンス要件の複雑さを次のように評価します。
|
アプリケーションの知識 |
アプリケーション所有者などの組織内の誰かが、問題を維持、統合、トラブルシューティング、修正するための知識、スキル、経験を持っていますか? また、ビジネス需要に合わせてアプリケーションを拡張できますか? |
移行スキル |
組織のスタッフには、ワークロードをターゲット環境に移行するスキルがありますか? |
技術基準
以下は、複雑なスコアリングで一般的に使用される技術基準です。
| 技術基準 | 説明 |
|---|---|
Storage |
アプリケーションの現在のストレージを次のように評価します。
|
ユーザー数 |
このアプリケーションには何人のユーザーがいますか? 実際のログまたは見積りを使用できます。 |
サーバー数 |
アプリケーションスタックにはサーバーがいくつありますか? |
接続 |
このアプリケーションが組織内の他のユーザーにどのように接続されているかを次のように評価します。
|
アプリケーション OS とバージョン |
次のように、オペレーティングシステム (OS) とアプリケーションのサーバーのバージョンを評価します。
|
アプリケーション依存関係 |
このアプリケーションが環境内の他のリソースにどのように依存しているかを評価します。
|
データ移行 |
このアプリケーションのデータまたはファイルを移行する必要があるかどうかを評価します。
|
移行戦略 |
選択した移行戦略の複雑さを評価します。移行戦略の詳細については、AWS 「大規模な移行用ガイド」を参照してください。 |
COTS またはカスタム |
アプリケーションがカスタム作成か商用off-the-shelf (COTS) かを次のように評価します。
|
ステップ 1: アプリケーションの優先順位付けプロセスを定義する
このプレイブックには、アプリケーションを優先順位付けするための 3 つのプロセスオプションが含まれています。オプションのいずれかを選択するか、2 つ以上を組み合わせてカスタムプロセスを構築できます。ユースケースを評価し、環境に最適なものを以下の中から判断します。
-
オプション 1: 手動の複雑さスコアリング – これは、個人またはワークショップ形式のセッションで完了できる手動の優先順位付けプロセスです。このプロセスでは、複雑なスコアリング基準を使用して、各アプリケーションの移行の難しさを評価します。これは、アプリケーションの優先順位付けにおける重要な要素です。この手動プロセスは、大規模なアプリケーションポートフォリオに優先順位を付けるための一貫した定量的アプローチを提供するため、大規模な移行に適しています。ただし、定義された一連の基準に照らして各アプリケーションを評価すると、他の 2 つのオプションと比較してプロセスが遅くなる可能性があります。
-
オプション 2: アプリケーションのノミネーション – これは、通常ワークショップ形式のセッションを完了する手動の優先順位付けプロセスです。このプロセスでは、アプリケーション所有者が移行するアプリケーションを指名します。このプロセスを成功させるには、アプリケーション所有者がそれぞれのアプリケーションについて包括的な知識を持っている必要があります。このプロセスは、時間が要因であり、アプリケーションの迅速な優先順位付けが必要な場合に推奨されます。
-
オプション 3: 検出ツール – これは自動優先順位付けプロセスです。環境内の検出ツールにアプリケーションの複雑さの自動スコアリングまたは優先順位付けのための自動機能がある場合、この機能を使用すると、時間を節約し、アプリケーションの優先順位付けプロセスを高速化できます。このプロセスでは、通常、検出ツールのパラメータ内で基準を定義し、ツールがアプリケーションを分析し、最終的な複雑さスコアを提供します。このオプションを選択する前に、検出ツールで使用できる機能を調べ、ユースケースのニーズに合わせてカスタマイズできることを確認します。
オプション 1: 手動の複雑さスコアリング
この手動アプリケーションの優先順位付けプロセスでは、ワークシートを使用して、定義された一連の複雑なスコアリング基準に照らしてアプリケーションを評価します。ワークショップ形式のセッションでワークシートを完了するか、利害関係者と協力してワークシートを完了することをお勧めします。次に、最終的な複雑さスコアとアプリケーションの優先順位付けルールを使用して、アプリケーションの優先度を決定します。手動プロセスのうち、アプリケーションの複雑さを判断し、その情報を使用してアプリケーションの優先順位を付けるための最も一貫性のある定量的アプローチを提供します。
このプロセスの複雑なスコアリングステップでは、ポートフォリオプレイブックテンプレートで利用可能なアプリケーションの複雑さ (Excel 形式) にスコアシートテンプレートを使用することをお勧めします。 samples/portfolio-playbook-templates.zipこのテンプレートには、事前定義されたビジネス基準と技術基準が含まれています。これらの基準を追加、削除、または変更したり、スコアリング値を調整したりできます。たとえば、1～5 ではなく 1～10 のスコア範囲を優先できます。提供されたテンプレートについては、次の点に注意してください。
-
各基準にカーソルを合わせると、その説明が表示されます。
-
テンプレートに慣れたら、例を削除する必要があります。これらはデモンストレーションのみを目的としています。
移行の初期化と実装の段階で、複雑さスコアシートを最新の状態に保ちます。ポートフォリオ評価を進めるにつれてスコアが変わる場合があります。アプリケーションの詳細調査は、チームが各アプリケーションについて詳しく調べる際に、スコアシートを更新する一般的な機会です。アプリケーションの移行を妨げる未発見の依存関係や制限などの問題が発生した場合は、移行中にアプリケーションの優先度を変更することもできます。移行全体を通してスコアシートを維持することで、より正確にアプリケーションに優先順位を付けることができます。
アプリケーションの優先順位付けプロセスを次のように文書化します。
-
ポートフォリオプレイブックテンプレートで、アプリケーションの複雑さに合わせてスコアシートテンプレートを開きます。
-
アプリケーションシートで、移行に適した条件を追加、変更、または削除します。条件を変更するときは、次の操作を行います。
-
このプレイブックの 複雑なスコアリング基準についてセクションのガイダンスを確認してください。
-
各基準が移行の期間、リソース、コストに与える影響を考慮してください。
-
信頼できる複雑さスコアを得るには、組織内のさまざまなレベルの移行の複雑さを表す基準を含めます。
-
-
スコアリングガイドシートで、ユースケースに応じてデフォルト値と基準を更新します。
-
スコアシートを保存します。
-
アプリケーションの優先順位付けランブックを開きます。
-
アプリケーションの複雑さのスコアリング基準セクションで、スコアシートの場所を反映するようにセクションを更新します。
-
アプリケーションの優先順位付けプロセスセクションで、次の操作を行います。
-
オプション 1 を保持する: 手動の複雑さスコアリングを行い、他のオプションを削除します。
-
ユースケースに応じてプロセスを変更します。
-
Option という単語を含むこのセクションの見出しをすべて削除します。ランブックにこれらを残しておくと、ユーザーがプロセスがオプションであるか、複数のオプションが利用可能であると考えることに混乱する可能性があります。
-
アプリケーションの優先順位付けランブックを保存します。
-
オプション 2: アプリケーションのノミネーション
この手動アプリケーションの優先順位付けプロセスは、アプリケーションの優先順位付けのための最も簡単で迅速なアプローチです。このプロセスでは、アプリケーション所有者に、クラウドに簡単に移行できるアプリケーションを指名するよう依頼します。その後、ユーザーとアプリケーション所有者は、指定されたアプリケーションに関する深い知識をすでに持っているため、アプリケーションに迅速に優先順位を付けることができます。ワークショップ形式のセッションでステークホルダーと協力することをお勧めしますが、E メール、共有ドキュメント、その他のコミュニケーションプラットフォームでコラボレーションすることもできます。
ノミネーションプロセス中に、ポートフォリオプレイブックテンプレートに含まれるアプリケーションの複雑さ (Excel 形式) のスコアシートテンプレートに、ノミネーションされたアプリケーションを入力します。このテンプレートのすべてのスコアリングおよび基準機能を使用するわけではありませんが、このシートを使用して、ノミネーションと優先順位付けの決定を記録することをお勧めします。
状況によっては、アプリケーションの指名プロセスを使用して優先順位付けを高速化し、スコアシートを必要としない場合があります。たとえば、少数のアプリケーションのみを優先する場合や、アプリケーション所有者がアプリケーションについて非常に精通している場合、アプリケーション所有者と利害関係者は、その知識と経験に基づいてアプリケーションを優先できます。この場合、スコアシートの使用をスキップし、直接優先順位付けに進むことができます。
アプリケーションの優先順位付けプロセスを次のように文書化します。
-
アプリケーションの優先順位付けランブックを開きます。
-
アプリケーションの複雑さのスコアリング基準セクションを削除します。このプロセスでは、アプリケーションの複雑さのスコアリングは使用されません。
-
アプリケーションの優先順位付けプロセスセクションで、次の操作を行います。
-
オプション 2: アプリケーションのノミネーションを保持し、他のオプションを削除します。
-
ユースケースに応じてプロセスを変更します。
-
Option という単語を含むこのセクションの見出しをすべて削除します。ランブックにこれらを残しておくと、ユーザーがプロセスがオプションであるか、複数のオプションが利用可能であると考えるように混乱する可能性があります。
-
-
アプリケーションの優先順位付けランブックを保存します。
オプション 3: 検出ツール
検出ツールに複雑なスコアリングやアプリケーションの優先順位付けの機能がある場合、この自動プロセスに必要なリソースは少なく、アプリケーションの優先順位付けプロセスを加速できます。ユースケースの検出ツールで基準をカスタマイズすると、検出ツールが自動的にアプリケーションを分析し、最終的な複雑さスコアを提供します。ツールにはすでにすべてのアプリケーションメタデータがあるため、入力する必要はありません。
例えば、Flexera One Cloud Migration and Modernization (旧 Flexera Foundation および CloudScape) 検出ツールには、Optimization Scorecard と呼ばれる複雑なスコアリング機能があります。この機能を使用すると、スコアリングに含める基準を選択し、好みに基づいて各基準を重み付けできます。データ検出が完了すると、検出ツールは指定した加重基準に基づいてデータを分析し、ツール独自の式を使用して最終的な複雑さスコアを生成します。詳細については、 Foundation and CloudScape ユーザーガイド
このプロセスの欠点は、環境内のエージェントレス検出ツール用にスキャンアプライアンスをセットアップしたり、対象範囲内のすべてのワークロードにエージェントをインストールしたりするのに (4～8 週間) かかることです。検出ツールでスコアリング機能を使用する前に、アプリケーションワークロードをスキャンしてアプリケーションスタック分析を実行することで、検出ツールがメタデータを収集するための追加の時間 (4～12 週間) を確保する必要があります。ただし、メタデータの収集とアプリケーションの優先順位付けに必要な時間とリソースを減らすことで、検出ツールの設定に必要な余分な時間が復旧される可能性があります。例えば、検出ツールのデータがまだ最新である場合、ポートフォリオワークストリームは検出ツールとそのデータを動員フェーズから再利用してパイロットアプリケーションを特定できます。
注記
検出ツールプロセスを使用している場合でも、手動のスコアシートテンプレートを使用してアプリケーションの複雑さを分析できます。この追加情報は、アプリケーションの優先順位を絞り込むのに役立ちます。
アプリケーションの優先順位付けプロセスを次のように文書化します。
-
まだ設定していない場合は、 環境で検出ツールをセットアップします。詳細については、 AWS 「 規範ガイダンス」ウェブサイトの「自動ポートフォリオ検出の開始方法」を参照してください。
-
ツールの指示に従って、検出ツールで複雑なスコアリングまたはアプリケーションの優先順位付け基準をカスタマイズします。条件の選択の詳細については、「」を参照してください複雑なスコアリング基準について。
-
アプリケーションの優先順位付けランブックを開きます。
-
アプリケーションの複雑さのスコアリング基準セクションで、 セクションを更新して、スコアリング基準が検出ツールで定義されていることを反映させます。例: 複雑なスコアリング基準は <検出ツール> で定義されています。
-
アプリケーションの優先順位付けプロセスセクションで、次の操作を行います。
-
オプション 3: 検出ツールを保持し、他のオプションを削除します。
-
ユースケースに応じてプロセスを変更します。複雑さスコアを含むレポートを生成する方法のstep-by-stepの手順を含めることが重要です。利用可能な場合は、ユーザーガイドへのリンクを含めることができます。
-
Option という単語を含むこのセクションの見出しをすべて削除します。ランブックにこれらを残しておくと、ユーザーがプロセスがオプションであるか、複数のオプションが利用可能であると考えるように混乱する可能性があります。
-
-
アプリケーションの優先順位付けランブックを保存します。
ステップ 2: アプリケーションの優先順位付けルールを定義する
このステップでは、アプリケーションの優先順位付けルールを定義し、アプリケーションの移行順序を決定するのに役立ちます。アプリケーションの複雑さスコアはアプリケーションの優先順位付けやウェーブの計画において重要な要素ですが、ビジネスやテクノロジーの要素も考慮する必要があります。各アプリケーションの優先度を評価し、適切なウェーブでアプリケーションをスケジュールするのに役立つルールを作成します。一般的なビジネスルールとテクノロジールールは次のとおりです。
-
データセンターの移行順序とスケジュールの指定
-
ビジネスユニットの優先順位付け
-
重要なビジネスアプリケーションの期限を把握する
アプリケーションの優先順位付けルールを次のように定義します。
-
アプリケーションの優先順位付けランブックを開きます。
-
「アプリケーションの優先順位付けルール」セクションで、移行用のカスタムルールを追加します。
-
アプリケーションの優先順位付けランブックを保存します。
-
アプリケーションの優先順位付けランブックのルールを維持します。ルールは、移行の進行状況、範囲の変更、またはスケジュールのシフトに応じて変更される可能性があります。
以下は、アプリケーションの優先順位付けルールの例です。
| 優先度 | ルール |
|---|---|
1 |
ニューヨークデータセンターのアプリケーションは、常にテキサスデータセンターのアプリケーションよりも優先度が高くなります。 |
2 |
IT 部門のアプリケーションは、マーケティング部門のアプリケーションよりも常に優先順位が高くなります。 |
3 |
複雑さスコアが高いアプリケーションは、優先順位が高くなります。 |
4 |
SAP アプリケーションは、年末までに移行する必要があります。 |
ステップ 3: アプリケーションの優先順位付けプロセスを完了する
次に、ポートフォリオワークストリームがルールとプロセスを使用してアプリケーションの優先順位を付ける方法を定義します。これは、ポートフォリオワークストリームが移行の実装段階で参照するプロセスです。
アプリケーション優先順位付けランブックでこのプロセスを次のようにカスタマイズします。
-
アプリケーションの優先順位付けランブックを開きます。
-
ステージ 2: アプリケーションの優先順位付けセクションで、ユースケースと環境に応じてプロセスを変更します。
-
アプリケーションの優先順位付けランブックを保存します。
タスク終了条件
次のタスクを完了したら、次のタスクに進みます。
-
使用可能なオプションからアプリケーションの優先順位付けプロセスを選択しました。
-
アプリケーションの優先順位付けランブックに以下を文書化しました。
-
アプリケーションの複雑さのスコアリング基準 (該当する場合)
-
アプリケーションの優先順位付けプロセス
-
アプリケーションの優先順位付けルール
-
-
アプリケーションランブックの「ステージ 2: アプリケーションの優先順位付け」セクションを更新しました。
