デジタル資産の合理化

  • [アーティクル]

クラウドの合理化は、クラウドで資産をホストする際の最適なアプローチを決定するために資産を評価するプロセスです。 アプローチを決定し、インベントリを集計したら、クラウドの合理化を開始できます。 クラウドの合理化に関する記事では、最も一般的な合理化オプションについて説明しています。

次のビデオを視聴して、移行作業の計画と優先順位付けに役立つ包括的な評価の実施に関する概要を確認してください。

合理化に関する従来の見方

複雑なデシジョン ツリーとして従来の合理化のプロセスを視覚化すると、合理化を理解しやすくなります。 デジタル資産に含まれる各資産は、5 つの回答 (合理化の 5 R) のいずれかとなるプロセスを通して提供されます。 小規模な資産の場合、このプロセスは適切に機能します。 大規模な資産の場合、これは非効率的で、大幅な遅れに至る可能性があります。 このプロセスを調べて、理由を確かめましょう。 その後で、より効率的なモデルを紹介します。

インベントリ: 従来のモデルを使用して完全な合理化を完了するためには、アプリケーション、ソフトウェア、ハードウェア、オペレーティング システム、システム パフォーマンス メトリックを含む、資産の完全なインベントリが必要です。

定量分析: デシジョン ツリーでは、定量的な質問によって、意思決定の最初のレイヤーが動かされます。 一般的な質問には、次のようなものがあります。

  • その資産は今日使用中ですか。
  • そうである場合、最適化されていて、適切なサイズになっていますか。
  • 資産の間にどのような依存関係が存在しますか。 これらの質問は、インベントリの分類に不可欠です。

定性分析: 次の一連の決定では、定性分析の形式で、人の知性が必要とされます。 ここで説明する質問は、多くの場合ソリューションに固有のもので、回答できるのはビジネスの利害関係者とパワー ユーザーだけの場合があります。 通常、これらの決定はプロセスを遅らせ、物事のスピードが大幅に低下します。 この分析では、アプリケーションごとに FTE 時間が 40 ～ 80 時間かかります。

定性分析質問の一覧の作成に関するガイダンスは、デジタル資産計画の手法に関するページを参照してください。

合理化の決定: 経験豊富な合理化チームの手で、定性データと定量データから明確な意思決定が下されます。 残念ながら、高度な合理化の経験を積んだチームを雇用するには多額の費用がかかり、トレーニングには数か月かかります。

エンタープライズ規模の合理化

50 台の VM を含むデジタル資産に対して、この取り組みは時間がかかり困難である場合、数千の VM と数百のアプリケーションが含まれる環境でビジネスの変革を推進するために必要な労力を想像してみてください。 必要とされる人間の作業は、1,500 FTE 時間と 9 か月の計画を簡単に超過します。

完全な合理化は最終状態であり、すばらしい方向性を持つ目標ですが、必要な時間と労力の割に、高い ROI (投資収益率) が得られることはめったにありません。

合理化は、財務上の決定に不可欠ですが、プロセスを加速させるため、クラウドの合理化を得意とする専門のサービス組織を検討する価値があります。 その場合でも、完全な合理化は、高いコストがかかり、時間のかかる取り組みとなることがあり、それが変革やビジネス上の成果を遅らせます。

この記事の残りの部分では、増分型の合理化と呼ばれる別の手法について説明します。

増分型の合理化

大規模なデジタル資産の完全な合理化は、リスクとなる傾向があり、その複雑さのために遅れに苦しむ可能性があります。 増分型の手法の背後にある前提は、意思決定を遅らせることで、企業が障害のリスクを軽減する際の負荷に時間差を設けることです。 この手法では、長期にわたって、必要なプロセスとエクスペリエンスを作成するための有機的なモデルを作成します。その目的は、合理化についての意思決定を、限定的に、より効率的に行うことです。

インベントリ:検出データ ポイントを減らす

完全なデジタル資産の正確なリアルタイムのインベントリの維持に、時間、労力、費用を投資している組織はほとんどありません。 多くの場合、損失、盗難、更新サイクル、および従業員の採用によって、エンド ユーザー デバイスの詳細な資産追跡が正当化されています。 従来のオンプレミス データセンターでサーバーとアプリケーションの正確なインベントリを維持する場合の ROI は、多くの場合低くなっています。 ほとんどの IT 組織は、データセンター内の固定資産の使用状況の追跡よりも、緊急に対処すべき問題を抱えています。

クラウドの変革では、インベントリは運用コストに直接関連しています。 適切な計画には正確なインベントリ データが必要です。 残念ながら、現在の環境スキャン オプションでは、週単位、または月単位で意思決定が遅れる場合があります。 幸いにも、データの収集を加速するためのこつがいくつかあります。

エージェント ベースのスキャンは、遅れの原因として最もよく引き合いに出されます。 従来の合理化で必要とされる堅牢なデータは、多くの場合、各資産で実行されるエージェントでしか収集できません。 多くの場合、エージェントに対するこの依存関係は、セキュリティ、操作、および管理機能からのフィードバックを必要とすることがあるため、進行速度を低下させます。

増分型の合理化プロセスでは、最初の検出にエージェントレス ソリューションを使用することで、早期の意思決定を促進できます。 環境の複雑さのレベルによっては、エージェント ベースのソリューションが引き続き必要な場合もありますが、ビジネスの変化に対するクリティカル パスからは削除できます。

定量分析:意思決定を能率的にする

インベントリ検出の手法に関わらず、定量分析によって、初期の意思決定と前提の設定が促進されます。 最初のワークロードを識別しようとするときや、合理化の目標が高レベルのコスト比較であるときには、これが特に当てはまります。 増分型の合理化プロセスでは、クラウド戦略チームとクラウド導入チームが、合理化の 5 つの R を 2 つの簡潔な意思決定に限定し、それらの定量的な要因のみを適用します。 これによって、分析を合理化し、変化を促進するために必要な初期データの量を削減します。

たとえば、組織がクラウドへの IaaS 移行の途中にある場合は、ほとんどのワークロードが廃止または再ホストのいずれかとなると想定できます。

定性分析:一時的な前提条件

潜在的な結果の数を減らすことで、資産の将来の状態に関する最初の意思決定に達しやすくなります。 選択肢を減らすと、この初期段階で企業が受ける質問の数も減ります。

たとえば、選択肢が再ホストまたは廃止に限定される場合、初期の合理化時に企業に確認する質問は実際には 1 つだけになります。つまり、資産を廃止するかどうかという質問です。

"分析では、この資産を積極的に使用しているユーザーはいないことが示唆されています。 これは正確ですか。それとも何か見落としているでしょうか。"このような二択の質問は、一般に、定性分析を通して行うのがはるかに簡単です。

この合理化された手法では、ベースライン、財務計画、戦略、および方向性が生み出されます。 以降の活動では、各資産は一層の合理化と定性分析を経て、その他のオプションが評価されます。 この最初の合理化で考慮するすべての前提条件は、個々のワークロードを移行する前にテストされます。

前提条件を吟味する

前のセクションの結果は、多数の前提条件が含まれる大まかな合理化です。 次は、これらの前提条件の一部を吟味するときです。

資産を廃止する

従来のオンプレミス環境では、小さな未使用の資産をホストしていても、年間コストに大きな影響を及ぼすことはめったにありません。 いくつかの例外はありますが、実際の資産を分析して廃止するために必要な FTE の労力は、それらの資産の除去と廃止から得られるコストの削減を上回ります。

クラウドの会計モデルに移行すると、資産の廃止により、年間の運用コストと事前の移行作業の点で、大幅な節約を生み出すことができます。

定量分析の完了後に、組織がデジタル資産の 20% 以上をインベントリから削除することも珍しくありません。 アクションを実行する前に、さらに定性分析を実施することをお勧めします。 確認後にそれらの資産を削除することで、クラウド移行における最初の ROI の成果を生み出すことができます。 多くの場合、これは最大のコスト節約要因の 1 つです。 したがって、クラウド戦略チームは、移行の方法論の実行と並行して、資産の検証と削除を監視し、早期に財務上の成果を達成する必要があります。

プログラムの調整

1 つの企業が乗り出す変革の過程が 1 つだけであることはめったにありません。 コストの削減、市場の成長、新しい収益ストリームの間で下す選択が二者択一の決定であることはまれです。 そのため、クラウド戦略チームには、IT 部門と協力して、並行する変革過程の中で、主要な変革過程の範囲外にある資産を特定することをお勧めします。

この記事で示されている IaaS 移行の例では、以下のことを行います。

  • 既にデプロイの自動化の一部になっている資産を特定し、それらをコアの移行計画から除外するように DevOps チームに依頼します。

  • 新しい収益ストリームの原動力となっている資産を特定し、それらをコアの移行計画から除外するようデータと研究開発のチームに依頼します。

プログラムに焦点を絞ったこの定性分析は迅速に実行可能であり、複数の移行バックログ間に対応関係が作られます。

場合によっては、しばらくの間、一部の資産を再ホストと見なす必要があります。 初期の移行後、後から合理化を段階的に進めることができます。

最初のワークロードを選択する

最初のワークロードを実装することは、テストと学習の鍵です。 これは、成長の思考様式を築いて示す最初の機会です。

ビジネス上の条件

ビジネスの透過性を確保するために、クラウド戦略チームの事業部門のメンバーによってサポートされるワークロードを識別します。 できれば、チームが既得の利害関係を持っていて、クラウドに移行する強い動機を持っているものを選択します。

技術的な条件

依存関係が最小限で、小さな資産グループとして移動できるワークロードを選択します。 検証を容易にするために、定義済みのテスト パスを含むワークロードを選択することをお勧めします。

最初のワークロードは、多くの場合、運用やガバナンスのための容量がない実験環境にデプロイされます。 セキュリティで保護されたデータを操作しないワークロードを選択することが重要です。

定性分析

クラウド導入チームとクラウド戦略チームは協力して、この小さなワークロードを分析できます。 このコラボレーションによって、定性分析の条件を作成してテストするための制御された機会が生まれます。 より少人数であれば、影響を受けるユーザーを調査したり、1 週間以内に詳細な定性分析を完了したりする機会が得られます。 定性分析の一般的な要因については、「合理化の 5 R」で具体的な合理化目標を参照してください。

移行

継続中の合理化と並行して、クラウド導入チームは、以下の重要な領域での学習を拡大するため、小さなワークロードの移行を開始できます。

  • クラウド プロバイダーのプラットフォームを利用してスキルを強化します。
  • 長期的なビジョンに合わせるために必要なコア サービスと Azure の標準を定義します。
  • 変革の後期に運用がどのように変化する必要があるか、より深く理解します。
  • 固有のビジネス リスクと、それらのリスクに対する企業の許容範囲について理解します。
  • 企業のリスク許容範囲に基づいて、ガバナンスのためのベースライン、または実用最小限の製品 (MVP) を確立します。

リリース計画

クラウド導入チームが移行または最初のワークロードの実装を実行している間に、クラウド戦略チームは残りのアプリケーションとワークロードの優先度付けを開始できます。

10 のパワー

合理化に対する従来の手法は、すべての予見可能なニーズを満たそうとするものです。 幸い、変革の過程を開始するために、すべてのアプリケーションについて計画を立てる必要はありません。 増分型のモデルでは、10 のべき乗アプローチを出発点にすることをお勧めします。 このモデルでは、クラウド戦略チームが、移行する最初の 10 個のアプリケーションを選択します。 これら 10 個のワークロードには、単純なワークロードと複雑なワークロードが混在して含まれている必要があります。

最初のバックログを作成する

クラウド導入チームとクラウド戦略チームは、最初の 10 個のワークロードの定性分析に関して、一緒に作業することができます。 この努力によって、優先度付けされた最初の移行バックログと、優先度付けされた最初のリリース バックログが作成されます。 この方法では、チームは手法を繰り返すことができ、定性分析のために適切なプロセスを作成するのに十分な時間が提供されます。

プロセスを成熟させる

2 つのチームが定性分析の条件について合意したら、評価をそれぞれの繰り返しに含まれるタスクにすることができます。 評価の条件について合意に達するには、通常は 2 ～ 3 回のリリースが必要です。

評価が移行の増分型実施プロセスに移されたら、クラウド導入チームはより迅速に、評価とアーキテクチャに関する繰り返しを行えます。 この段階で、クラウド戦略チームも身を引くことになり、費やす時間が減少します。 これにより、クラウド戦略チームは、特定のリリースにまだ含まれていないアプリケーションの優先度付けに集中して、変化する市場条件への緊密な適応を確実にすることもできます。

優先度付けされたアプリケーションのすべてが、移行準備が整っているわけではありません。 チームがより深く定性分析を行うにつれて、バックログの優先度付けの再実行を促す可能性があるビジネス イベントと依存関係が検出され、処理の順序が変化することがあります。 一部のリリースでは、少数のワークロードをまとめてグループ化することがあります。 他のリリースには、1 つのワークロードだけが含まれることもあります。

クラウド導入チームは、おそらく、完全なワークロードの移行を生み出さない繰り返しを実行します。 ワークロードが小さいほど依存関係は少数になり、ワークロードが 1 つのスプリントまたは繰り返しに収まる確率が高くなります。 このため、リリース バックログの最初のいくつかのアプリケーションは、サイズが小さく、外部の依存関係をほとんど含まないようにすることをお勧めします。

最終状態

時間の経過と共に、クラウド導入チームとクラウド戦略チームの連携によって、インベントリの完全な合理化が完了します。 この増分型の手法では、チームは合理化プロセスを継続的に迅速化できます。 事前の分析にそれほど工数をかけずに、明白なビジネスの成果をより早期に生み出す変革の過程を実現することもできます。

場合によっては、追加の合理化を行わないと、財務モデルに余裕がなさすぎて決定を下せないことがあります。 そのような場合、より従来型の、合理化に対する手法が必要になる可能性があります。

次のステップ

合理化の取り組みの出力は、選択した変革によって影響を受けるすべての資産の、優先度付けされたバックログです。 このバックログは、この時点で、クラウド サービスのコスト モデルの基礎として使用する準備ができています。

コスト モデルをデジタル資産に対応付ける