ポートフォリオのバランスを取る

[アーティクル]
07/11/2023

クラウドの導入は、技術的実装として巧妙に見せ掛けたポートフォリオ管理作業です。ポートフォリオ管理の実行と同様に、ポートフォリオのバランスは成功に不可欠な要素です。戦略的レベルで、これは、クラウドを最大限に活用するために、移行、イノベーション、実験のバランスを取ることを意味します。クラウド導入作業が一方向に傾きすぎると、導入作業に複雑さが加わります。この記事では、ポートフォリオのバランスを実現するためのアプローチをわかりやすく説明します。

全般的な範囲の拡大

ポートフォリオのバランスを取ることは、本来、戦略的です。そのため、この記事で採用されているアプローチも等しく戦略的です。データ主導の意思決定に基づいた戦略とするため、この記事は、読者が既存のデジタル資産を評価済みであるか、そのプロセスを開始済みであることを前提としています。このアプローチの目標は、ワークロードの評価をサポートし、定性的質問とポートフォリオの改善によって、ポートフォリオ間の適切なバランスを確保することです。

ビジネス成果の文書化

ポートフォリオのバランスを取る前に、クラウド移行作業を推進するビジネスの成果を文書化し、共有することが重要です。次の表は、目的のビジネスの成果を文書化し、共有するために役立つ可能性があります。ほとんどの企業では同時に複数の成果を追求していることに注意する必要があります。この演習の重要性は、クラウド移行作業に最も直接的に関連する成果を明らかにすることです。

結果	測定基準	目標	期間	この作業の優先順位
IT コストの削減	データセンターの予算	200 万米国ドルの削減	12 か月	1 番
データセンターの閉鎖	データセンターからの撤退	2 つのデータセンター	6 か月	2 番
ビジネスの機敏性の向上	市場投入までの時間の短縮	デプロイ時間を 6 か月短縮	2 年間	3 番
カスタマーエクスペリエンスの向上	顧客満足度 (CSAT)	10% 向上	12 か月	4 番

重要

上の表は、架空の例であり、優先順位の設定に使用しないでください。多くの場合、この表は、コスト削減をカスタマーエクスペリエンスの上に位置付けることで、アンチパターンと見なすことができます。

上の表では、クラウド戦略チームとクラウド導入チームの優先事項が正確に表されています。短期的な制約のため、このチームは IT コストの削減に重点を置き、データセンターからの撤退を、目的の IT コスト削減を達成するための手段として優先しています。しかし、この表で競合する優先事項を文書化することによって、クラウド導入チームは、クラウド戦略チームが包括的なポートフォリオ戦略の実装をうまく調整する機会を見極められるように支援できます。

バランスを維持しながらすばやく動く

デジタル資産の漸進的合理化に関するガイダンスでは、バランスが取れていない位置から合理化を開始するアプローチを推奨しています。クラウド戦略チームは、リホストアプローチとの互換性について、すべてのワークロードを評価する必要があります。そのようなアプローチは、定量的データに基づいた複雑なデジタル資産の速やかな評価が可能になるため推奨されます。初めにこのような仮定を立てることにより、クラウド導入チームはすばやく取り掛かることができ、ビジネスの成果を得るまでの時間を短縮できます。しかし、その記事に説明されているように、定性的質問によって、ポートフォリオに必要なバランスが提供されます。この記事では、約束されたバランスを作成するためのプロセスを説明します。

サポート終了と廃止の決断の重要性

上記のビジネスの成果の文書化セクションの表では、1 番の目標である IT コストの削減に役立つ可能性がある重要な成果が上げられていません。 IT コストの削減が、ビジネスの成果の一覧のどこにランク付けされていても、ワークロードの終了と廃止の可能性を検討することが重要です。一部のシナリオでは、短期の投資に値しないワークロードを移行しないことから、コストの削減がもたらされる可能性があります。一部のお客様は、使用率が低いワークロードの廃止によって、20% を超える合計コスト削減のコスト削減を報告しています。

サポート終了や廃止の決断を適切に反映しているポートフォリオのバランスを取るために、クラウド戦略チームとクラウド導入チームが評価および移行フェーズ内で各ワークロードについて次の質問をすることをお勧めします。

ワークロードは過去 6 か月以内にエンドユーザーによって使われましたか?
エンドユーザーのトラフィックは一定していますか、増加していますか?
このワークロードは、今後 12 か月間ビジネスで必要とされますか?

これらのいずれかの質問の答えが "いいえ" の場合、ワークロードは廃止の候補となる可能性があります。廃止の可能性がアプリケーション所有者によって確認された場合、ワークロードを移行しても意味がないと考えられます。これにより、いくつかの適格性の質問が発生します。

このワークロードに対して、廃止またはサポート終了の計画を立てることができますか?
このワークロードは、データセンターからの撤退の前に廃止できますか?

これらの両方の質問の答えが "はい" である場合に、ワークロードを移行しないことを検討することが賢明であるといえます。このアプローチは、コストを削減し、データセンターから撤退するという目標の達成に役立つことがあります。

いずれかの質問に対する答えが "いいえ" の場合は、ワークロードを廃止できるようになるまで、ホストする計画を立てることが賢明であると考えられます。この計画には、低コストのデータセンターまたは代替のデータセンターへの資産の移動を含めることができ、それによってもコストの削減と 1 つのデータセンターの撤退の目標が達成できることになります。

プロセス変更の導入

ポートフォリオのバランスを取るには、導入フェーズ中に追加の定性分析が必要であり、これはシンプルなポートフォリオ合理化の推進に役立ちます。

上記のビジネスの成果の文書化セクションの表のデータに基づくと、ポートフォリオが移行を重視した実行モデルに傾きすぎるというリスクの可能性があります。カスタマーエクスペリエンスが最優先事項である場合、イノベーションが頻繁なポートフォリオでその可能性が高くなります。どちらが正しくどちらが誤りでもありませんが、一方向に傾きすぎると、一般に利益が減少し、不要な複雑さが加わり、クラウド導入作業に関連する実行時間が長くなります。

複雑さを軽減するため、ポートフォリオ合理化の従来のアプローチに、しかし反復モデルで従う必要があります。次の手順では、このようなアプローチへの定性的モデルを示しています。

クラウド戦略チームは、移行されるワークロードの優先順位付きのバックログを管理します。
クラウド戦略チームとクラウド導入チームは、各リリースの完了前にリリース計画会議を主催します。
リリース計画会議で、チームは優先順位付きのバックログの上位 5 位から 10 位のワークロードに同意します。
リリース計画会議外で、クラウド導入チームは、アプリケーション所有者と領域の専門家の次の質問を尋ねます。
- このアプリケーションは、同等のサービスとしてのプラットフォーム (PaaS) に置き換えることができますか?
- このアプリケーションは、サードパーティアプリケーションですか?
- 今後 12 か月間でアプリケーションの継続的な開発に投資する予算が承認されていますか?
- このアプリケーションの追加の開発によって、カスタマーエクスペリエンスが向上しますか? 競争上の差別化要素を作成しますか? ビジネスの収益の追加を促進しますか?
- このワークロード内のデータは、BI、機械学習、IoT、または関連テクノロジに関連するダウンストリームのイノベーションに寄与しますか?
- ワークロードは、Azure App Service などの最新のアプリケーションプラットフォームと互換性がありますか?
上記の質問の回答と他の必要な定性分析は、優先順位付きのバックログへの調整に影響することがあります。これらの調整には次のようなものが含まれます。
- ワークロードを PaaS ソリューションで置き換えることができる場合、移行バックログから完全に削除できます。少なくとも再ホストと置き換えの決断のための追加のデューデリジェンスがタスクとして追加され、移行バッグログからそのワークロードの優先順位が一時的に低下します。
- ワークロードが開発の進行中である (または進行させる必要がある) 場合は、リファクター、再設計、再構築モデルに最も適合する可能性があります。イノベーションと移行では、異なる技術的スキルが必要であるため、リファクター、再設計、再構築アプローチに合わせるアプリケーションは、移行バックログ以外に、イノベーションバックログによって管理する必要があります。
- ワークロードがダウンストリームイノベーションの一部である場合、データプラットフォームをリファクタリングすることは理にかなっている可能性がありますが、アプリケーションレイヤーをリホストの候補のままにします。ワークロードのデータプラットフォームのマイナーなリファクタリングは、多くの場合に移行またはイノベーションバックログで対処できます。この合理化の結果によって、バックログの作業項目が詳細になる可能性がありますが、優先順位の変更はありません。
- ワークロードが戦略的でなくても、最新のクラウドベースのアプリケーションホスティングプラットフォームと互換性がある場合は、アプリケーションに対してマイナーリファクタリングを実行して、それを最新のアプリケーションとしてデプロイすることが賢明であると考えられます。これは、クラウド移行の IaaS と OS の全体的なライセンス要件を削減することで、全体的な節約に寄与する可能性があります。
- ワークロードがサードパーティアプリケーションで、そのワークロードのデータがダウンストリームのイノベーションで使用するように計画されていない場合は、バックログにリホストオプションとして残しておくことが最善であると考えられます。

これらの質問は、各ワークロードについて実行された定性分析の範囲にすべきではありませんが、バランスが取れていないポートフォリオの複雑さに対処するための会話を導くのに役立ちます。

移行プロセスの変更

移行時に、ポートフォリオのバランスを取るアクティビティによって、移行の速度 (資産が移行されるスピード) にマイナスの影響が及ぶ可能性があります。次のガイダンスでは、移行作業の中断を回避するために作業を調整する理由と方法について説明しています。

ポートフォリオの合理化には、多様な技術的作業が必要です。クラウド導入チームにとっては、移行作業内のポートフォリオの多様性に対応したくなります。ビジネス利害関係者は、1 つのクラウド導入チームに移行バックログ全体に対処することを求めます。これはほとんど賢明なアプローチとはいえず、多くの場合に、非生産的になる可能性があります。

これらの多様な作業は、複数のクラウド導入チームとの間で分担する必要があります。 2 つのチームモデルを実行モードの例として使用して、チーム 1 を移行チームに、チーム 2 をイノベーションチームにします。より大規模な作業の場合は、これらのチームをさらに分割して、置換/PaaS 作業やマイナーリファクタリングなどの他のアプローチに対処できます。以下では、リホスト、リファクター、マイナーリファクタリングに必要なスキルとロールの概要を説明します。

再ホスト: リホストでは、チームメンバーがインフラストラクチャに重点を置いた変更を実装する必要があります。一般に Azure Site Recovery などのツールを使用して、VM や他の資産を Azure に移行します。この作業は、データセンター管理者や IT 実装者に適しています。クラウド移行チームは、この作業を大規模に提供するために適切に構成されます。これは、ほとんどのシナリオで既存の資産を移行するための最も高速なアプローチです。

リファクター: リファクタリングでは、チームメンバーがソースコードの変更、アプリケーションのアーキテクチャの変更、または新しいクラウドサービスの導入を行う必要があります。一般にこの作業では、Visual Studio などの開発ツールと Azure DevOps のようなデプロイパイプラインツールを使用して、最新のアプリケーションを Azure に再デプロイします。この作業は、アプリケーション開発ロールまたは DevOps パイプライン開発ロールに適しています。クラウドイノベーションチームは、この作業を提供するために最適に構成されています。このアプローチで既存の資産をクラウド資産に置き換えるのに時間がかかる可能性がありますが、アプリケーションではクラウドネイティブの機能を利用できます。

マイナーリファクタリング: 一部のアプリケーションは、データまたはアプリケーションレベルでのマイナーリファクタリングによって最新化できます。この作業では、チームメンバーがクラウドベースのデータプラットフォームにデータをデプロイするか、またはアプリケーションにマイナーな構成変更を適用する必要があります。これには、データまたはアプリケーション開発分野の専門家の限定的なサポートが必要になることがあります。しかし、この作業は、サードパーティアプリケーションをデプロイするときに IT 実装者が行う作業に似ています。この作業は、クラウド移行チームまたはクラウド戦略チームに適しています。この作業は、リホスト移行ほど高速でありませんが、リファクタリング作業を実行するより時間がかかりません。

移行時に、作業を上記の 3 つの方法で分割し、それらの作業を適切なイテレーションで適切なチームが実行する必要があります。ポートフォリオを多角化する一方で、作業の焦点が絞られたままであり、分離されていることも確認してください。

次のステップ

グローバルマーケットの決定が変革過程に与える影響を把握します。

グローバルマーケットについて理解する