デジタル資産の合理化Rationalize the digital estate

クラウドの合理化は、クラウドで資産をホストする際の最適なアプローチを決定するために資産を評価するプロセスです。Cloud rationalization is the process of evaluating assets to determine the best approach to hosting them in the cloud. アプローチを決定し、インベントリを集計したら、クラウドの合理化を開始できます。After you've determined an approach and aggregated an inventory, cloud rationalization can begin. クラウドの合理化に関する記事では、最も一般的な合理化オプションについて説明しています。Cloud rationalization discusses the most common rationalization options.

合理化に関する従来の見方Traditional view of rationalization

複雑なデシジョン ツリーとして従来の合理化のプロセスを視覚化すると、合理化を理解しやすくなります。It's easy to understand rationalization when you visualize the traditional process of rationalization as a complex decision tree. デジタル資産に含まれる各資産は、5 つの回答 (合理化の 5 R) のいずれかとなるプロセスを通して提供されます。Each asset in the digital estate is fed through a process that results in one of five answers (the five Rs of rationalization). 小規模な資産の場合、このプロセスは適切に機能します。For small estates, this process works well. 大規模な資産の場合、これは非効率的で、大幅な遅れに至る可能性があります。For larger estates, it's inefficient and can lead to significant delays. このプロセスを調べて、理由を確かめましょう。Let's examine the process to see why. その後で、より効率的なモデルを紹介します。Then we'll present a more efficient model.

インベントリ: 従来のモデルを使用して完全な合理化を完了するためには、アプリケーション、ソフトウェア、ハードウェア、オペレーティング システム、システム パフォーマンス メトリックを含む、資産の完全なインベントリが必要です。Inventory: A thorough inventory of assets, including applications, software, hardware, operating systems, and system performance metrics, is required for completing a full rationalization by using traditional models.

定量分析: デシジョン ツリーでは、定量的な質問によって、意思決定の最初のレイヤーが動かされます。Quantitative analysis: In the decision tree, quantitative questions drive the first layer of decisions. 一般的な質問には、次のようなものがあります。Common questions include the following:

  • その資産は今日使用中ですか。Is the asset in use today?
  • そうである場合、最適化されていて、適切なサイズになっていますか。If so, is it optimized and sized properly?
  • 資産の間にどのような依存関係が存在しますか。What dependencies exist between assets? これらの質問は、インベントリの分類に不可欠です。These questions are vital to the classification of the inventory.

定性分析: 次の一連の決定では、定性分析の形式で、人の知性が必要とされます。Qualitative analysis: The next set of decisions requires human intelligence in the form of qualitative analysis. ここで説明する質問は、多くの場合ソリューションに固有のもので、回答できるのはビジネスの利害関係者とパワー ユーザーだけの場合があります。Often, the questions that come up here are unique to the solution and can be answered only by business stakeholders and power users. 通常、これらの決定はプロセスを遅らせ、物事のスピードが大幅に低下します。These decisions typically delay the process, slowing things down considerably. この分析では、アプリケーションごとに FTE 時間が 40 ~ 80 時間かかります。This analysis generally consumes 40 to 80 FTE hours per application.

定性分析質問の一覧の作成に関するガイダンスは、デジタル資産計画の手法に関するページを参照してください。For guidance about building a list of qualitative analysis questions, see Approaches to digital estate planning.

合理化の決定: 経験豊富な合理化チームの手で、定性データと定量データから明確な意思決定が下されます。Rationalization decision: In the hands of an experienced rationalization team, the qualitative and quantitative data creates clear decisions. 残念ながら、高度な合理化の経験を積んだチームを雇用するには多額の費用がかかり、トレーニングには数か月かかります。Unfortunately, teams with a high degree of rationalization experience are expensive to hire or take months to train.

エンタープライズ規模の合理化Rationalization at enterprise scale

50 台の VM を含むデジタル資産に対して、この取り組みは時間がかかり困難である場合、数千の VM と数百のアプリケーションが含まれる環境でビジネスの変革を推進するために必要な労力を想像してみてください。If this effort is time consuming and daunting for a 50-VM digital estate, imagine the effort that's required to drive business transformation in an environment with thousands of VMs and hundreds of applications. 必要とされる人間の作業は、1,500 FTE 時間と 9 か月の計画を簡単に超過します。The human effort required can easily exceed 1,500 FTE hours and nine months of planning.

完全な合理化は最終状態であり、すばらしい方向性を持つ目標ですが、必要な時間と労力の割に、高い ROI (投資収益率) が得られることはめったにありません。While full rationalization is the end state and a great direction to move in, it seldom produces a high ROI (return on investment) relative to the time and energy that's required.

合理化は、財務上の決定に不可欠ですが、プロセスを加速させるため、クラウドの合理化を得意とする専門のサービス組織を検討する価値があります。When rationalization is essential to financial decisions, it's worth considering a professional services organization that specializes in cloud rationalization to accelerate the process. その場合でも、完全な合理化は、高いコストがかかり、時間のかかる取り組みとなることがあり、それが変革やビジネス上の成果を遅らせます。Even then, full rationalization can be a costly and time-consuming effort that delays transformation or business outcomes.

この記事の残りの部分では、増分型の合理化と呼ばれる別の手法について説明します。The rest of this article describes an alternative approach, known as incremental rationalization.

増分型の合理化Incremental rationalization

大規模なデジタル資産の完全な合理化は、リスクとなる傾向があり、その複雑さのために遅れに苦しむ可能性があります。The complete rationalization of a large digital estate is prone to risk and can suffer delays because of its complexity. 増分型の手法の背後にある前提は、意思決定を遅らせることで、企業が障害のリスクを軽減する際の負荷に時間差を設けることです。The assumption behind the incremental approach is that delayed decisions stagger the load on the business to reduce the risk of roadblocks. この手法では、長期にわたって、必要なプロセスとエクスペリエンスを作成するための有機的なモデルを作成します。その目的は、合理化についての意思決定を、限定的に、より効率的に行うことです。Over time, this approach creates an organic model for developing the processes and experience required to make qualified rationalization decisions more efficiently.

インベントリ:検出データ ポイントを減らすInventory: Reduce discovery data points

完全なデジタル資産の正確なリアルタイムのインベントリの維持に、時間、労力、費用を投資している組織はほとんどありません。Few organizations invest the time, energy, and expense in maintaining an accurate real-time inventory of the full digital estate. 多くの場合、損失、盗難、更新サイクル、および従業員の採用によって、エンド ユーザー デバイスの詳細な資産追跡が正当化されています。Loss, theft, refresh cycles, and employee onboarding often justify detailed asset tracking of end-user devices. 従来のオンプレミス データセンターでサーバーとアプリケーションの正確なインベントリを維持する場合の ROI は、多くの場合低くなっています。The ROI of maintaining an accurate server and application inventory in a traditional, on-premises datacenter is often low. ほとんどの IT 組織は、データセンター内の固定資産の使用状況の追跡よりも、緊急に対処すべき問題を抱えています。Most IT organizations have more urgent issues to address than tracking the usage of fixed assets in a datacenter.

クラウドの変革では、インベントリは運用コストに直接関連しています。In a cloud transformation, inventory directly correlates to operating costs. 適切な計画には正確なインベントリ データが必要です。Accurate inventory data is required for proper planning. 残念ながら、現在の環境スキャン オプションでは、週単位、または月単位で意思決定が遅れる場合があります。Unfortunately, current environmental scanning options can delay decisions by weeks or months. 幸いにも、データの収集を加速するためのこつがいくつかあります。Fortunately, a few tricks can accelerate data collection.

エージェント ベースのスキャンは、遅れの原因として最もよく引き合いに出されます。Agent-based scanning is the most frequently cited delay. 従来の合理化で必要とされる堅牢なデータは、多くの場合、各資産で実行されるエージェントでしか収集できません。The robust data that's required for a traditional rationalization can often only be collected with an agent running on each asset. 多くの場合、エージェントに対するこの依存関係は、セキュリティ、操作、および管理機能からのフィードバックを必要とすることがあるため、進行速度を低下させます。This dependency on agents often slows progress, because it can require feedback from security, operations, and administration functions.

増分型の合理化プロセスでは、最初の検出にエージェントレス ソリューションを使用することで、早期の意思決定を促進できます。In an incremental rationalization process, an agentless solution could be used for an initial discovery to accelerate early decisions. 環境の複雑さのレベルによっては、エージェント ベースのソリューションが引き続き必要な場合もありますが、ビジネスの変化に対するクリティカル パスからは削除できます。Depending on the level of complexity in the environment, an agent-based solution might still be required, but it can be removed from the critical path to business change.

定量分析:意思決定を能率的にするQuantitative analysis: Streamline decisions

インベントリ検出の手法に関わらず、定量分析によって、初期の意思決定と前提の設定が促進されます。Regardless of the approach to inventory discovery, quantitative analysis can drive initial decisions and assumptions. 最初のワークロードを識別しようとするときや、合理化の目標が高レベルのコスト比較であるときには、これが特に当てはまります。This is especially true when trying to identify the first workload or when the goal of rationalization is a high-level cost comparison. 増分型の合理化プロセスでは、クラウド戦略チームとクラウド導入チームが、合理化の 5 つの R を 2 つの簡潔な意思決定に限定し、それらの定量的な要因のみを適用します。In an incremental rationalization process, the cloud strategy team and the cloud adoption teams limit the five Rs of rationalization to two concise decisions and only apply those quantitative factors. これによって、分析を合理化し、変化を促進するために必要な初期データの量を削減します。This streamlines the analysis and reduces the amount of initial data that's required to drive change.

たとえば、組織がクラウドへの IaaS 移行の途中にある場合は、ほとんどのワークロードが廃止または再ホストのいずれかとなると想定できます。For example, if an organization is in the midst of an IaaS migration to the cloud, you can assume that most workloads will either be retired or rehosted.

定性分析:一時的な前提条件Qualitative analysis: Temporary assumptions

潜在的な結果の数を減らすことで、資産の将来の状態に関する最初の意思決定に達しやすくなります。By reducing the number of potential outcomes, it's easier to reach an initial decision about the future state of an asset. 選択肢を減らすと、この初期段階で企業が受ける質問の数も減ります。When you reduce the options, you also reduce the number of questions asked of the business at this early stage.

たとえば、選択肢が再ホストまたは廃止に限定される場合、初期の合理化時に企業に確認する質問は実際には 1 つだけになります。つまり、資産を廃止するかどうかという質問です。For example, if the options are limited to rehosting or retiring, the business needs to answer only one question during initial rationalization, which is whether to retire the asset.

"分析では、この資産を積極的に使用しているユーザーはいないことが示唆されています。"Analysis suggests that no users are actively using this asset. これは正確ですか。それとも何か見落としているでしょうか。"Is that accurate, or have we overlooked something?" このような二択の質問は、一般に、定性分析を通して行うのがはるかに簡単です。Such a binary question is typically much easier to run through qualitative analysis.

この合理化された手法では、ベースライン、財務計画、戦略、および方向性が生み出されます。This streamlined approach produces baselines, financial plans, strategy, and direction. 以降の活動では、各資産は一層の合理化と定性分析を経て、その他のオプションが評価されます。In later activities, each asset goes through further rationalization and qualitative analysis to evaluate other options. この最初の合理化で考慮するすべての前提条件は、個々のワークロードを移行する前にテストされます。All assumptions that you make in this initial rationalization are tested before migrating individual workloads.

前提条件を吟味するChallenge assumptions

前のセクションの結果は、多数の前提条件が含まれる大まかな合理化です。The outcome of the prior section is a rough rationalization that's full of assumptions. 次は、これらの前提条件の一部を吟味するときです。Next, it's time to challenge some of those assumptions.

資産を廃止するRetire assets

従来のオンプレミス環境では、小さな未使用の資産をホストしていても、年間コストに大きな影響を及ぼすことはめったにありません。In a traditional on-premises environment, hosting small, unused assets seldom causes a significant impact on annual costs. いくつかの例外はありますが、実際の資産を分析して廃止するために必要な FTE の労力は、それらの資産の除去と廃止から得られるコストの削減を上回ります。With a few exceptions, FTE effort that's required to analyze and retire the actual asset outweighs the cost savings from pruning and retiring those assets.

クラウドの会計モデルに移行すると、資産の廃止により、年間の運用コストと事前の移行作業の点で、大幅な節約を生み出すことができます。When you move to a cloud accounting model, retiring assets can produce significant savings in annual operating costs and up-front migration efforts.

定量分析の完了後に、組織がデジタル資産の 20% 以上をインベントリから削除することも珍しくありません。It's not uncommon for organizations to retire 20% or more of their digital estate after completing a quantitative analysis. アクションを実行する前に、さらに定性分析を実施することをお勧めします。We recommend conducting further qualitative analysis before taking action. 確認後にそれらの資産を削除することで、クラウド移行における最初の ROI の成果を生み出すことができます。After it's confirmed, retiring those assets can produce the first ROI victory of the cloud migration. 多くの場合、これは最大のコスト節約要因の 1 つです。This is often one of the biggest cost-saving factors. したがって、クラウド戦略チームは、移行の方法論の実行と並行して、資産の検証と削除を監視し、早期に財務上の成果を達成する必要があります。Therefore, the cloud strategy team should oversee the validation and retirement of assets, in parallel with execution of the Migrate methodology, to achieve an early financial win.

プログラムの調整Program adjustments

1 つの企業が乗り出す変革の過程が 1 つだけであることはめったにありません。A company seldom embarks on just one transformation journey. コストの削減、市場の成長、新しい収益ストリームの間で下す選択が二者択一の決定であることはまれです。The choice between cost reduction, market growth, and new revenue streams is rarely a binary decision. そのため、クラウド戦略チームには、IT 部門と協力して、並行する変革過程の中で、主要な変革過程の範囲外にある資産を特定することをお勧めします。As such, we recommend that the cloud strategy team work with IT to identify assets on parallel transformation efforts that are outside of the scope of the primary transformation journey.

この記事で示されている IaaS 移行の例では、以下のことを行います。In the IaaS migration example given in this article:

  • 既にデプロイの自動化の一部になっている資産を特定し、それらをコアの移行計画から除外するように DevOps チームに依頼します。Ask the DevOps team to identify assets that are already part of a deployment automation and remove those assets from the core migration plan.

  • 新しい収益ストリームの原動力となっている資産を特定し、それらをコアの移行計画から除外するようデータと研究開発のチームに依頼します。Ask the data and R&D teams to identify assets that are powering new revenue streams and remove them from the core migration plan.

プログラムに焦点を絞ったこの定性分析は迅速に実行可能であり、複数の移行バックログ間に対応関係が作られます。This program-focused qualitative analysis can be executed quickly and creates alignment across multiple migration backlogs.

場合によっては、しばらくの間、一部の資産を再ホストと見なす必要があります。You might still need to consider some assets as rehost assets for a while. 初期の移行後、後から合理化を段階的に進めることができます。You can phase in later rationalization after the initial migration.

最初のワークロードを選択するSelect the first workload

最初のワークロードを実装することは、テストと学習の鍵です。Implementing the first workload is key to testing and learning. これは、成長の思考様式を築いて示す最初の機会です。It's the first opportunity to demonstrate and build a growth mindset.

ビジネス上の条件Business criteria

ビジネスの透過性を確保するために、クラウド戦略チームの事業部門のメンバーによってサポートされるワークロードを識別します。To ensure business transparency, identify a workload that is supported by a member of the cloud strategy team's business unit. できれば、チームが既得の利害関係を持っていて、クラウドに移行する強い動機を持っているものを選択します。Preferably choose one in which the team has a vested stake and strong motivation to move to the cloud.

技術的な条件Technical criteria

依存関係が最小限で、小さな資産グループとして移動できるワークロードを選択します。Select a workload that has minimum dependencies and can be moved as a small group of assets. 検証を容易にするために、定義済みのテスト パスを含むワークロードを選択することをお勧めします。We recommend that you select a workload with a defined testing path to make validation easier.

最初のワークロードは、多くの場合、運用やガバナンスのための容量がない実験環境にデプロイされます。The first workload is often deployed in an experimental environment with no operational or governance capacity. セキュリティで保護されたデータを操作しないワークロードを選択することが重要です。It's important to select a workload that doesn't interact with secure data.

定性分析Qualitative analysis

クラウド導入チームとクラウド戦略チームは協力して、この小さなワークロードを分析できます。The cloud adoption teams and the cloud strategy team can work together to analyze this small workload. このコラボレーションによって、定性分析の条件を作成してテストするための制御された機会が生まれます。This collaboration creates a controlled opportunity to create and test qualitative analysis criteria. より少人数であれば、影響を受けるユーザーを調査したり、1 週間以内に詳細な定性分析を完了したりする機会が得られます。The smaller population creates an opportunity to survey the affected users, and to complete a detailed qualitative analysis in a week or less. 定性分析の一般的な要因については、「合理化の 5 R」で具体的な合理化目標を参照してください。For common qualitative analysis factors, see the specific rationalization target in the five Rs of rationalization.

移行Migration

継続中の合理化と並行して、クラウド導入チームは、以下の重要な領域での学習を拡大するため、小さなワークロードの移行を開始できます。In parallel with continued rationalization, the cloud adoption team can begin migrating the small workload to expand learning in the following key areas:

  • クラウド プロバイダーのプラットフォームを利用してスキルを強化します。Strengthen skills with the cloud provider's platform.
  • 長期的なビジョンに合わせるために必要なコア サービスと Azure の標準を定義します。Define the core services and Azure standards needed to fit the long-term vision.
  • 変革の後期に運用がどのように変化する必要があるか、より深く理解します。Better understand how operations might need to change later in the transformation.
  • 固有のビジネス リスクと、それらのリスクに対する企業の許容範囲について理解します。Understand any inherent business risks and the business's tolerance for those risks.
  • 企業のリスク許容範囲に基づいて、ガバナンスのためのベースライン、または実用最小限の製品 (MVP) を確立します。Establish a baseline or minimum viable product (MVP) for governance based on the business's risk tolerance.

リリース計画Release planning

クラウド導入チームが移行または最初のワークロードの実装を実行している間に、クラウド戦略チームは残りのアプリケーションとワークロードの優先度付けを開始できます。While the cloud adoption team is executing the migration or implementation of the first workload, the cloud strategy team can begin prioritizing the remaining applications and workloads.

10 のパワーPower of 10

合理化に対する従来の手法は、すべての予見可能なニーズを満たそうとするものです。The traditional approach to rationalization attempts to meet all foreseeable needs. 幸い、変革の過程を開始するために、すべてのアプリケーションについて計画を立てる必要はありません。Fortunately, a plan for every application is often not required to start a transformation journey. 増分型のモデルでは、10 のべき乗アプローチを出発点にすることをお勧めします。In an incremental model, the Power of 10 approach provides a good starting point. このモデルでは、クラウド戦略チームが、移行する最初の 10 個のアプリケーションを選択します。In this model, the cloud strategy team selects the first 10 applications to be migrated. これら 10 個のワークロードには、単純なワークロードと複雑なワークロードが混在して含まれている必要があります。Those ten workloads should contain a mixture of simple and complex workloads.

最初のバックログを作成するBuild the first backlogs

クラウド導入チームとクラウド戦略チームは、最初の 10 個のワークロードの定性分析に関して、一緒に作業することができます。The cloud adoption teams and the cloud strategy team can work together on the qualitative analysis for the first 10 workloads. この努力によって、優先度付けされた最初の移行バックログと、優先度付けされた最初のリリース バックログが作成されます。This effort creates the first prioritized migration backlog and the first prioritized release backlog. この方法では、チームは手法を繰り返すことができ、定性分析のために適切なプロセスを作成するのに十分な時間が提供されます。This method enables the teams to iterate on the approach and provides sufficient time to create an adequate process for qualitative analysis.

プロセスを成熟させるMature the process

2 つのチームが定性分析の条件について合意したら、評価をそれぞれの繰り返しに含まれるタスクにすることができます。After the two teams agree on the qualitative analysis criteria, assessment can become a task within each iteration. 評価の条件について合意に達するには、通常は 2 ~ 3 回のリリースが必要です。Reaching consensus on assessment criteria usually requires two to three releases.

評価が移行の増分型実施プロセスに移されたら、クラウド導入チームはより迅速に、評価とアーキテクチャに関する繰り返しを行えます。After the assessment has moved into the incremental execution process of migration, the cloud adoption team can iterate faster on assessment and architecture. この段階で、クラウド戦略チームも身を引くことになり、費やす時間が減少します。At this stage, the cloud strategy team is also abstracted, reducing the drain on their time. これにより、クラウド戦略チームは、特定のリリースにまだ含まれていないアプリケーションの優先度付けに集中して、変化する市場条件への緊密な適応を確実にすることもできます。This also enables the cloud strategy team to focus on prioritizing the applications that are not yet in a specific release, ensuring tight alignment with changing market conditions.

優先度付けされたアプリケーションのすべてが、移行準備が整っているわけではありません。Not all of the prioritized applications will be ready for migration. チームがより深く定性分析を行うにつれて、バックログの優先度付けの再実行を促す可能性があるビジネス イベントと依存関係が検出され、処理の順序が変化することがあります。Sequencing is likely to change as the team does deeper qualitative analysis and discovers business events and dependencies that might prompt reprioritization of the backlog. 一部のリリースでは、少数のワークロードをまとめてグループ化することがあります。Some releases might group together a small number of workloads. 他のリリースには、1 つのワークロードだけが含まれることもあります。Others might just contain a single workload.

クラウド導入チームは、おそらく、完全なワークロードの移行を生み出さない繰り返しを実行します。The cloud adoption team is likely to run iterations that don't produce a complete workload migration. ワークロードが小さいほど依存関係は少数になり、ワークロードが 1 つのスプリントまたは繰り返しに収まる確率が高くなります。The smaller the workload, and the fewer dependencies, the more likely a workload is to fit into a single sprint or iteration. このため、リリース バックログの最初のいくつかのアプリケーションは、サイズが小さく、外部の依存関係をほとんど含まないようにすることをお勧めします。For this reason, we recommend that the first few applications in the release backlog be small and contain few external dependencies.

最終状態End state

時間の経過と共に、クラウド導入チームとクラウド戦略チームの連携によって、インベントリの完全な合理化が完了します。Over time, the cloud adoption team and the cloud strategy team together complete a full rationalization of the inventory. この増分型の手法では、チームは合理化プロセスを継続的に迅速化できます。This incremental approach enables the teams to get continually faster at the rationalization process. 事前の分析にそれほど工数をかけずに、明白なビジネスの成果をより早期に生み出す変革の過程を実現することもできます。It also helps the transformation journey to yield tangible business results sooner, without as much upfront analysis effort.

場合によっては、追加の合理化を行わないと、財務モデルに余裕がなさすぎて決定を下せないことがあります。In some cases, the financial model might be too tight to make a decision without additional rationalization. そのような場合、より従来型の、合理化に対する手法が必要になる可能性があります。In such cases, you might need a more traditional approach to rationalization.

次のステップNext steps

合理化の取り組みの出力は、選択した変革によって影響を受けるすべての資産の、優先度付けされたバックログです。The output of a rationalization effort is a prioritized backlog of all assets that are affected by the chosen transformation. このバックログは、この時点で、クラウド サービスのコスト モデルの基礎として使用する準備ができています。This backlog is now ready to serve as the foundation for costing models of cloud services.