タスク 3: アプリケーションの優先順位付けプロセスを定義する

アプリケーションの優先順位付けは、アプリケーションをクラウドに移行する順序を決定するプロセスです。優先度は、アプリケーションをクラウドに移行する複雑さと定義したルールに基づいて評価します。アプリケーションの優先順位付けについて議論する場合、優先度が高いと必ずしもビジネスにとってのアプリケーションの重要性と相関するとは限りません。実際、ビジネスクリティカルなアプリケーションはリスクが高いため、移行の優先順位は通常低くなります。大規模な移行では、ビジネスクリティカルではない低複雑さのアプリケーションを優先し、各ウェーブでは、ますます複雑またはビジネスクリティカルなアプリケーションを移行します。

何百ものアプリケーションが移行用に準備されている大規模な移行では、すべてのアプリケーションを一度に優先順位付けして計画することはお勧めしません。これは、大規模な移行プロジェクトにとってアプリケーションの優先順位付けプロセスを定義することが重要な理由の 1 つです。アジャイルな方法で移行にアプローチするには、最も優先度の高いアプリケーション (3～10 個のアプリケーション) を選択するか、3～5 ウェーブに十分なアプリケーションを選択できます。次に、選択したアプリケーションのみのアプリケーション検出とウェーブプランニングを完了します。このアプローチでは、大規模な移行の過程でアプリケーションの優先度とウェーブが変化することが多いため、大幅な時間の節約になります。

アプリケーションの優先順位に関する一般的な誤解の 1 つは、優先順位が最も高いアプリケーションが第 1 ウェーブにあることです。ウェーブプランニングを実行する場合、優先順位が最も高い 10 個のアプリケーションのうち、準備が整っていないアプリケーションが最初のウェーブにある可能性が高くなります。これは、依存関係、ビジネス上の制約、リソースの可用性など、さまざまな有効な理由が考えられます。アプリケーションの優先度はウェーブプランニングの重要な要因ですが、考慮する唯一の要因であってはなりません。

このタスクでは、アプリケーションの優先順位付けプロセスとルールを定義します。このタスクは、次のステップで構成されます。

• ステップ 1: アプリケーションの優先順位付けプロセスを定義する

• ステップ 2: アプリケーションの優先順位付けルールを定義する

• ステップ 3: アプリケーションの優先順位付けプロセスを完了する

次のセクションでは、複雑なスコアリングについて説明します。このプレイブックには、アプリケーションの優先順位付け方法に関する 3 つのプロセスオプションと、3 つのオプションのうち 2 つが複雑なスコアリングを使用します。プロセスオプションの詳細については、「」を参照してくださいステップ 1: アプリケーションの優先順位付けプロセスを定義する。アプリケーション指定プロセスを使用する予定の場合は、複雑なスコアリング基準を定義する必要はなく、 に直接進む必要がありますステップ 1: アプリケーションの優先順位付けプロセスを定義する。

複雑なスコアリング基準について

複雑さのスコアリングは、アプリケーションの移行の難しさを評価するために使用されるプロセスであり、アプリケーションの優先順位を付ける際の重要な要素です。複雑さスコアリングには、定義したのと同じビジネス基準と技術基準のセットに照らしてすべてのアプリケーションを評価する必要があります。アプリケーションを評価するときは、各基準にスコアを割り当てます。ビジネス基準と技術基準のスコアを合計すると、そのアプリケーションの移行の全体的な複雑さを反映する複雑さスコアが得られます。その後、アプリケーションの優先順位付けやウェーブの計画時に複雑さスコアを使用できます。

複雑さスコアリング基準には 2 つのカテゴリがあります。

• ビジネス基準 – このカテゴリの基準は、アプリケーションが使用できなくなった場合のリスク、セキュリティとコンプライアンスに関する考慮事項、リソースの可用性など、アプリケーションの移行に伴うビジネス上の複雑さに関連しています。

• 技術基準 – このカテゴリの基準は、オペレーティングシステムとそのバージョン、サーバーとユーザーの数、移行戦略など、アプリケーションの移行の技術的な複雑さに関連しています。

ユースケースに適したスコアリング基準を決定する必要があります。アプリケーションの複雑さを手動でスコアリングする場合、ポートフォリオプレイブックテンプレートでは、アプリケーションの複雑さのスコアシートテンプレート (Microsoft Excel 形式) に、基準とスコア値の標準セットが含まれています。これらの値から始めて、ユースケースに合わせてカスタマイズすることもできます。アプリケーションの優先順位付けに検出ツールを使用している場合、これらのツールには通常、標準の基準セットが含まれており、基準を追加、削除、または変更でき、必要に応じて重み付けできます。基準を確立するときは、次の 2 つのセクションの質問を使用して基準を絞り込みます。

ビジネス基準

以下は、複雑なスコアリングで一般的に使用されるビジネス基準です。

ビジネス基準	説明
ビジネスへの影響	このアプリケーションが使用できなくなった場合のビジネスへの影響を評価します。 財務上の影響はありますか？ 運用に影響はありますか？ カスタマーエクスペリエンスに影響しますか？ 製品や会社のイベントに影響しますか？
スタッフの可用性	移行中、アプリケーション所有者、対象分野の専門家 (SME)、ネットワークまたはインフラストラクチャ管理者、テスター、開発者からのサポートが必要になる場合があります。移行中に役立つこれらのリソースの可用性を評価します。 移行チームを支援し、ガイダンスを提供するために、移行中にこのスタッフを利用できますか？ この担当者は、移行後にアプリケーションをテストおよび検証できますか？ このスタッフが、ターゲット環境でアプリケーションを実行するために必要な IP アドレスまたはポートをプロビジョニングできますか？
ビジネスの複雑さ	相互に依存するステークホルダーや相互接続されたステークホルダー、情報技術システム、組織構造が多数あると、ビジネスの複雑さが増す可能性があります。ビジネスの複雑さを次のように評価します。 ファイアウォールの変更や新しいインスタンスのプロビジョニングなど、インフラストラクチャとネットワークの変更をビジネスが承認するまでにどれくらいの時間がかかりますか？ 検出ツールなど、サーバーへの新しいソフトウェアやツールのインストールをビジネスが承認するまでにどれくらいの時間がかかりますか？
準備状況	アプリケーションを移行する準備ができたかどうかを次のように評価します。 アプリケーションは現在、テクノロジーの更新を受けているか、または更新される予定ですか？ メンテナンスはスケジュールされ、スケジュールされた移行と重複しますか？ アプリケーションは廃止される予定ですか？ アプリケーションは現在アップグレード中であり、新機能は開発または統合されていますか？
セキュリティ	アプリケーションのセキュリティ要件とセキュリティポリシーの複雑さを次のように評価します。 アプリケーションにアクセスするために IP アドレスとポートをプロビジョニングする必要がありますか？ アプリケーションにはインフラストラクチャの保護が必要ですか？ アプリケーションにはデータ保護が必要ですか？ キー管理は必要ですか？ アプリケーションには特別なアクセス管理ポリシーが必要ですか？ アプリケーションにはモニタリングまたはログ記録が必要ですか？ アプリケーションにはインシデント対応プロセスと自動化が必要ですか？ このアプリケーションにはアラートと通知が必要ですか？
コンプライアンス	コンプライアンス要件は、州、事業者、または企業ポリシーによって提供される法律、規制、ガイドラインなどのアプリケーションに適用される場合があります。アプリケーションのコンプライアンス要件の複雑さを次のように評価します。 データのプライバシーと所在地の要件はありますか？ アプリケーションの保管中のデータは暗号化する必要がありますか？ アプリケーションとの間で転送されるデータは暗号化する必要がありますか？ 監査ログ記録は必要ですか？ アプリケーションは、システムおよび組織統制 (SOC) などの会計および財務標準に準拠している必要がありますか？ アプリケーションは、Payment Card Industry (PCI) などの支払いセキュリティ標準に準拠している必要がありますか？ アプリケーションは、医療保険の相互運用性と説明責任に関する法律 (HIPAA) などの患者の健康情報規制に準拠している必要がありますか？ アプリケーションは、情報システムのセキュリティ管理および評価プログラム (ISMAP) などのパブリッククラウドセキュリティプログラムに準拠している必要がありますか？
アプリケーションの知識	アプリケーション所有者など、組織内の誰かが、問題を維持、統合、トラブルシューティング、修正するための知識、スキル、経験を持っていますか？ また、ビジネス需要に合わせてアプリケーションを拡張できますか？
移行スキル	組織のスタッフには、ワークロードをターゲット環境に移行するスキルがありますか？

技術基準

以下は、複雑なスコアリングで一般的に使用される技術基準です。

技術基準	説明
ストレージ	アプリケーションの現在のストレージを次のように評価します。 アプリケーションは現在どこに保存されていますか？ 例としては、ネットワーク接続ストレージ (NAS)、ストレージエリアネットワーク (SAN)、ローカルドライブなどがあります。 現在のストレージの合計サイズはどれくらいですか？
ユーザー数	このアプリケーションには何人のユーザーがいますか？ 実際のログまたは見積りを使用できます。
サーバー数	アプリケーションスタックにはいくつのサーバーがありますか？
接続	このアプリケーションが組織内の他のユーザーにどのように接続されているかを次のように評価します。 このアプリケーションに依存している他のアプリケーションはいくつありますか？ このアプリケーションが使用できない場合、他のアプリケーションにはどのような影響がありますか？
アプリケーション OS とバージョン	次のように、オペレーティングシステム (OS) とアプリケーションのサーバーのバージョンを評価します。 サーバーの OS バージョンはサポートされなくなりましたか？ サーバーは Unix または Linux OS を実行していますか？ サーバーは Windows Server OS を実行していますか？ アプリケーションはメインフレームまたはミッドレンジサーバーにありますか？
アプリケーション依存関係	このアプリケーションが環境内の他のリソースにどのように依存しているかを評価します。 このアプリケーションはどのリソースに依存していますか？ リソースには、他のアプリケーション、コンポーネント、OS 固有のサービス (レジストリやウェブサーバーなど）、ライブラリなどがあります。 これらのリソースが 1 つ以上使用できない場合、このアプリケーションにはどのような影響がありますか？
データ移行	このアプリケーションのデータまたはファイルを移行する必要があるかどうかを評価します。 データ移行はどの程度複雑ですか？ ファイル移行はどの程度複雑ですか？
移行戦略	選択した移行戦略の複雑さを評価します。移行戦略の詳細については、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. ポートフォリオプレイブックテンプレートで、アプリケーションの複雑さについてスコアシートテンプレートを開きます。

2. アプリケーションシートで、移行に適した条件を追加、変更、または削除します。条件を変更するときは、次の操作を行います。

   • このプレイブックの 複雑なスコアリング基準についてセクションのガイダンスを確認してください。

   • 各基準が移行の期間、リソース、コストに与える影響を考慮します。

   • 信頼性の高い複雑さスコアを得るには、組織のさまざまなレベルの移行の複雑さを表す基準を含めます。

3. スコアリングガイドシートで、ユースケースに応じてデフォルト値と基準を更新します。

4. スコアシートを保存します。

5. アプリケーションの優先順位付けランブックを開きます。

6. 「アプリケーションの複雑さのスコアリング基準」セクションで、スコアシートの場所を反映するようにセクションを更新します。

7. 「アプリケーションの優先順位付けプロセス」セクションで、次の操作を行います。

   1. オプション 1 を保持する: 手動で複雑なスコアリングを行い、他のオプションを削除します。

   2. ユースケースに応じてプロセスを変更します。

   3. このセクションの「Option」という単語を含む見出しをすべて削除します。これらをランブックに残しておくと、ユーザーがプロセスがオプションであるか、複数のオプションが使用可能であると考えるように混乱する可能性があります。

   4. アプリケーションの優先順位付けランブックを保存します。

オプション 2: アプリケーションのノミネーション

この手動のアプリケーションの優先順位付けプロセスは、アプリケーションの優先順位付けのための最も簡単で迅速なアプローチです。このプロセスでは、アプリケーション所有者に、クラウドに簡単に移行できるアプリケーションを推薦するように依頼します。その後、指定したアプリケーションに関する深い知識が既にあるため、ユーザーとアプリケーション所有者はアプリケーションに迅速に優先順位を付けることができます。ワークショップ形式のセッションではステークホルダーと協力することをお勧めしますが、E メール、共有ドキュメント、その他のコミュニケーションプラットフォームでコラボレーションすることもできます。

ノミネーションプロセス中に、ポートフォリオプレイブックテンプレートに含まれるアプリケーションの複雑さ (Excel 形式) について、指定されたアプリケーションをスコアシートテンプレートに入力します。 samples/portfolio-playbook-templates.zipこのテンプレートのスコアリングと基準の機能の一部は使用しませんが、このシートを使用して、候補と優先順位の決定を記録することをお勧めします。

状況によっては、優先順位付けを高速化するためにアプリケーションの指名プロセスが使用され、スコアシートは必要ではない場合があります。例えば、少数のアプリケーションのみを優先する場合や、アプリケーション所有者がアプリケーションについて非常に知識を持っている場合、アプリケーション所有者と利害関係者は知識と経験に基づいてアプリケーションを優先できます。この場合、スコアシートの使用をスキップして、直接優先順位付けに進むことができます。

アプリケーションの優先順位付けプロセスを次のように文書化します。

1. アプリケーションの優先順位付けランブックを開きます。

2. アプリケーションの複雑さのスコアリング基準セクションを削除します。このプロセスでは、アプリケーションの複雑さのスコアリングを使用しません。

3. 「アプリケーションの優先順位付けプロセス」セクションで、次の操作を行います。

   1. オプション 2: アプリケーションのノミネーションを保持し、他のオプションを削除します。

   2. ユースケースに応じてプロセスを変更します。

   3. このセクションの「Option」という単語を含む見出しをすべて削除します。これらをランブックに残しておくと、ユーザーがプロセスがオプションであるか、複数のオプションが使用可能であると考えるように混乱する可能性があります。

4. アプリケーションの優先順位付けランブックを保存します。

オプション 3: 検出ツール

検出ツールに複雑なスコアリングやアプリケーションの優先順位付けの機能がある場合、この自動プロセスに必要なリソースは少なく、アプリケーションの優先順位付けプロセスを加速できます。ユースケースに合わせて検出ツールで基準をカスタマイズすると、検出ツールが自動的にアプリケーションを分析し、最終的な複雑さスコアを提供します。ツールにはすでにすべてのアプリケーションメタデータがあるため、入力する必要はありません。

例えば、Flexera One Cloud Migration and Modernization (旧 Flexera Foundation and CloudScape) 検出ツールには、最適化スコアカードと呼ばれる複雑なスコアリング機能があります。この機能を使用すると、スコアリングに含める基準を選択し、好みに基づいて各基準を比較検討できます。データ検出が完了すると、検出ツールは指定した加重基準に基づいてデータを分析し、ツール独自の式を使用して最終的な複雑さスコアを生成します。詳細については、「 Foundation and CloudScape User Guide」(Flexera ドキュメント) と「Optimization Scorecard」(Flexera ドキュメント) を参照してください。

このプロセスの欠点は、環境でエージェントレス検出ツールのスキャンアプライアンスをセットアップしたり、対象範囲内のすべてのワークロードにエージェントをインストールしたりするのに時間 (4～8 週間) が必要であることです。検出ツールでスコアリング機能を使用する前に、アプリケーションワークロードをスキャンしてアプリケーションスタック分析を実行することで、検出ツールがメタデータを収集するまでさらに時間 (4～12 週間) を確保する必要があります。ただし、メタデータの収集とアプリケーションの優先順位付けに必要な時間とリソースを減らすことで、検出ツールの設定に必要な余分な時間が復旧される可能性があります。例えば、検出ツールのデータがまだ最新である場合、ポートフォリオワークストリームは、検出ツールとその準備段階のデータを再利用してパイロットアプリケーションを特定できます。

注記

検出ツールプロセスを使用している場合でも、手動スコアシートテンプレートを使用してアプリケーションの複雑さを解析し、異なる条件セットに対してアプリケーションを分析できます。この追加情報は、アプリケーションの優先順位を絞り込むのに役立ちます。

アプリケーションの優先順位付けプロセスを次のように文書化します。

1. まだ設定していない場合は、 環境で検出ツールを設定します。詳細については、 AWS 「 規範ガイダンス」ウェブサイトの「自動ポートフォリオ検出の開始方法」を参照してください。

2. ツールの指示に従って、検出ツールの複雑さスコアリングまたはアプリケーションの優先順位付け基準をカスタマイズします。条件の選択の詳細については、「」を参照してください複雑なスコアリング基準について。

3. アプリケーションの優先順位付けランブックを開きます。

4. 「アプリケーションの複雑さのスコアリング基準」セクションで、「」セクションを更新して、スコアリング基準が検出ツールで定義されていることを反映します。例: 複雑なスコアリング基準は、＜検出ツール> で定義されています。

5. 「アプリケーションの優先順位付けプロセス」セクションで、次の操作を行います。

   1. オプション 3: 検出ツールを保持し、他のオプションを削除します。

   2. ユースケースに応じてプロセスを変更します。複雑さスコアを含むレポートを生成する方法のstep-by-stepの手順を含めることが重要です。利用可能な場合は、 ユーザーガイドへのリンクを含めることができます。

   3. このセクションの「Option」という単語を含む見出しをすべて削除します。これらをランブックに残しておくと、ユーザーがプロセスがオプションであるか、複数のオプションが使用可能であると考えるように混乱する可能性があります。

6. アプリケーションの優先順位付けランブックを保存します。

ステップ 2: アプリケーションの優先順位付けルールを定義する

このステップでは、アプリケーションの優先順位付けルールを定義し、アプリケーションの移行順序を決定するのに役立ちます。アプリケーションの複雑さスコアはアプリケーションの優先順位付けやウェーブの計画において重要な要素ですが、ビジネスやテクノロジーの要素も考慮する必要があります。各アプリケーションの優先度を評価し、適切なウェーブでアプリケーションをスケジュールするのに役立つルールを作成します。一般的なビジネスルールとテクノロジールールには以下が含まれます。

• データセンターの移行順序とスケジュールの指定

• ビジネスユニットの優先順位付け

• 重要なビジネスアプリケーションの期限を把握する

アプリケーションの優先順位付けルールを次のように定義します。

1. アプリケーションの優先順位付けランブックを開きます。

2. 「アプリケーションの優先順位付けルール」セクションで、移行用のカスタムルールを追加します。

3. アプリケーションの優先順位付けランブックを保存します。

4. アプリケーションの優先順位付けランブックのルールを維持します。ルールは、移行の進行状況、範囲の変更、またはスケジュールのシフトに応じて変更される可能性があります。

以下は、アプリケーションの優先順位付けルールの例です。

優先度	ルール
1	ニューヨークデータセンターのアプリケーションは、テキサスデータセンターのアプリケーションよりも常に優先順位が高くなります。
2	IT 部門のアプリケーションは、マーケティング部門のアプリケーションよりも常に優先順位が高くなります。
3	複雑さスコアが高いアプリケーションは、優先順位が高くなります。
4	SAP アプリケーションは、年末までに移行する必要があります。

ステップ 3: アプリケーションの優先順位付けプロセスを完了する

次に、ポートフォリオワークストリームがルールとプロセスを使用してアプリケーションの優先順位を付ける方法を定義します。これは、移行の実装段階でポートフォリオワークストリームが参照するプロセスです。

アプリケーション優先順位付けランブックでこのプロセスを次のようにカスタマイズします。

1. アプリケーションの優先順位付けランブックを開きます。

2. 「ステージ 2: アプリケーションの優先順位付け」セクションで、ユースケースと環境に応じてプロセスを変更します。

3. アプリケーションの優先順位付けランブックを保存します。

タスク終了基準

次の作業が完了したら、次のタスクに進みます。

• 使用可能なオプションからアプリケーションの優先順位付けプロセスを選択しました。

• アプリケーションの優先順位付けランブックに以下を文書化しました。

  • アプリケーションの複雑さのスコアリング基準 (該当する場合）

  • アプリケーションの優先順位付けプロセス

  • アプリケーションの優先順位付けルール

• アプリケーションランブックの「ステージ 2: アプリケーションの優先順位付け」セクションを更新しました。