合理化決定を見直すReview rationalization decisions

初期の戦略と計画の段階では、増分型の合理化アプローチをデジタル資産に適用することをお勧めします。During initial strategy and planning stages, we suggest you apply an incremental rationalization approach to the digital estate. ただし、このアプローチには、結果としての決定にいくつもの前提が組み込まれます。But this approach embeds some assumptions into the resulting decisions. クラウド戦略チームとクラウド導入チームが、詳細なワークロード ドキュメントに照らし合わせてこれらの決定を見直すことをお勧めします。We advise the cloud strategy team and the cloud adoption teams to review those decisions in light of expanded-workload documentation. この見直しは、ビジネスの利害関係者とエグゼクティブ スポンサーが今後の状態に関する決定に関与するタイミングとしても適切です。This review is also a good time to involve business stakeholders and the executive sponsor in future state decisions.

重要

合理化に関する決定は、移行の評価フェーズでさらに詳しく検証されます。Further validation of the rationalization decisions will occur during the Assess phase of migration. この検証では、合理化のビジネス レビューに重点を置いて、リソースが適切に調整されます。This validation focuses on business review of the rationalization to align resources appropriately.

合理化に関する決定を検証する場合は、ビジネスとの対話をスムーズに進めるために、以下に示す質問を利用します。To validate rationalization decisions, use the following questions to facilitate a conversation with the business. 質問は、合理化が見込まれる対象別に分類されています。The questions are grouped by the likely rationalization alignment.

イノベーションに関する指標Innovation indicators

次の質問の共同レビューによって肯定的な回答が得られた場合、ワークロードはイノベーションに適した候補になる可能性があります。If the joint review of the following questions yields an affirmative answer, a workload might be a better candidate for innovation. このようなワークロードは、リフト アンド シフト モデルまたは最新化モデルによって移行されることはありません。Such a workload wouldn't be migrated via a lift and shift or modernize model. 代わりに、ビジネス ロジックやデータ構造が、新たなアプリケーションまたは再設計されたアプリケーションとして作り直されます。Instead, the business logic or data structures would be re-created as a new or rearchitected application. このアプローチには多くの時間と労力を要する場合があります。This approach can be more labor-intensive and time-consuming. しかし、ビジネス リターンが大きいワークロードであれば、投資に見合う価値が得られます。But for a workload that represents significant business returns, the investment is justified.

  • このワークロードのアプリケーションで市場の差別化を図れるか。Do the applications in this workload create market differentiation?
  • このワークロードのアプリケーションに関連するエクスペリエンスの向上を目的として提案または承認された投資が存在するか。Is there a proposed or approved investment aimed at improving the experiences associated with the applications in this workload?
  • このワークロードのデータで新たな製品やサービスのオファリングが利用できるようになるか。Does the data in this workload make new product or service offerings available?
  • このワークロードに関連付けられたデータの活用を目的として提案または承認された投資が存在するか。Is there a proposed or approved investment aimed at taking advantage of the data associated with this workload?
  • 市場の差別化または新たなオファリングの効果を定量化できるか。Can the effect of the market differentiation or new offerings be quantified? できる場合、そのリターンはクラウド導入時のイノベーションのコスト増に見合うものであるか。If so, does that return justify the increased cost of innovation during cloud adoption?

次の 2 つの質問は、合理化の見直しに高度な技術的シナリオを含めるときに役立ちます。The following two questions can help you include high-level technical scenarios in the rationalization review. いずれかの答えが "はい" であれば、イノベーションに関連するコストを説明または軽減する方法を特定できます。Answering "yes" to either could identify ways of accounting for or reducing the cost associated with innovation.

  • クラウドの導入中にデータ構造またはビジネス ロジックが変更されるか。Will the data structures or business logic change during the course of cloud adoption?
  • このワークロードを運用環境にデプロイするために既存のデプロイ パイプラインが使用されるか。Is an existing deployment pipeline used to deploy this workload to production?

上記のいずれかに対する答えが "はい" であれば、チームはこのワークロードをイノベーションの候補として含めることを検討する必要があります。If the answer to either question is "yes," the team should consider including this workload as an innovation candidate. 少なくとも、このワークロードをアーキテクチャ レビューの対象と定めて、最新化の可能性を見きわめるべきです。At a minimum, the team should flag this workload for architecture review to identify modernization opportunities.

移行に関する指標Migration indicators

移行は、より高速でより安価にクラウドを導入できる方法です。Migration is a faster and cheaper way of adopting the cloud. しかし、イノベーションの機会が活用されません。But it doesn't take advantage of opportunities to innovate. イノベーションに投資する前に、次の質問に答えてください。Before you invest in innovation, answer the following questions. 移行モデルがワークロードにより適しているかどうかを判断するのに役立ちます。They can help you determine if a migration model is more applicable for a workload.

  • このアプリケーションをサポートしているソース コードは安定しているか。Is the source code supporting this application stable? このリリース サイクルの期間中に無変更のまま安定性を維持することを見込んでいるか。Do you expect it to remain stable and unchanged during the time frame of this release cycle?
  • このワークロードは現在の実稼働ビジネス プロセスに対応しているか。Does this workload support production business processes today? それはこのリリース サイクルの全期間にわたっているか。Will it do so throughout the course of this release cycle?
  • このクラウド導入の取り組みにより、このワークロードの安定性とパフォーマンスが向上することが優先事項であるか。Is it a priority that this cloud adoption effort improves the stability and performance of this workload?
  • この取り組みでは、このワークロードに関連するコスト削減を目的としているか。Is cost reduction associated with this workload an objective during this effort?
  • この取り組みでは、このワークロードの運用上の複雑さを軽減することを目的としているか。Is reducing operational complexity for this workload a goal during this effort?
  • 現在のアーキテクチャまたは IT 運用プロセスによってイノベーションが制限されているか。Is innovation limited by the current architecture or IT operation processes?

これらの質問のいずれかに対する答えが "はい" である場合は、このワークロードの移行モデルを検討する必要があります。If the answer to any of these questions is "yes," you should consider a migration model for this workload. これは、ワークロードがイノベーションの候補である場合も同様にお勧めします。This recommendation is true even if the workload is a candidate for innovation.

運用の複雑さ、コスト、パフォーマンス、あるいは安定性に関する課題が、ビジネス リターンの妨げとなることがあります。Challenges in operational complexity, costs, performance, or stability can hinder business returns. クラウドを使用すると、これらの課題に関してすばやく改善することができます。You can use the cloud to quickly produce improvements related to those challenges. 可能な場合は、移行アプローチを使用してまずワークロードを安定させることをお勧めします。Where it's applicable, we suggest you use the migration approach to first stabilize the workload. その後に、安定して即応性のあるクラウド環境でイノベーションの機会を進展させます。Then expand on innovation opportunities in the stable, agile cloud environment. このアプローチでは、短期的にはリターンを得られ、長期的には変化の推進に必要なコストを削減できます。This approach provides short-term returns and reduces the cost required to drive long-term change.

重要

移行モデルには、増分型の最新化が含まれます。Migration models include incremental modernization. 移行アクティビティでは、サービスとしてのプラットフォーム (PaaS) アーキテクチャを使用することが一般的です。Using platform as a service (PaaS) architectures is a common aspect of migration activities. 小規模な構成変更でも、こうしたプラットフォーム サービスが使用されます。So too are minor configuration changes that use those platform services. 移行の範囲は、ビジネス ロジックまたは支援ビジネス構造に対する重大な変更として定義されます。The boundary for migration is defined as a material change to the business logic or supporting business structures. このような変更は、イノベーションに向けた取り組みと見なされます。Such change is considered an innovation effort.

プロジェクト計画の更新Update the project plan

移行とイノベーションでは、取り組みに必要なスキルが異なります。The skills required for a migration effort are different from the skills required for an innovation effort. クラウド導入計画の実装時には、移行とイノベーションの取り組みを異なるチームに割り当てることをお勧めします。During implementation of a cloud adoption plan, we suggest that you assign migration and innovation efforts to different teams. チームごとに独自のイテレーション、リリース、計画のサイクルを設定します。Each team has its own iteration, release, and planning cadences. チームを分けることでプロセスの柔軟性が高まり、1 つのクラウド導入計画を維持しながらイノベーションと移行に対応できます。Assigning separate teams provides the process flexibility to maintain one cloud adoption plan while accounting for innovation and migration efforts.

Azure DevOps でクラウド導入計画を管理する場合は、親作業項目 (エピック) をクラウド移行からクラウド イノベーションに変えることで、その管理が反映されます。When you manage the cloud adoption plan in Azure DevOps, that management is reflected by changing the parent work item (or epic) from cloud migration to cloud innovation. このわずかな変更により、クラウド導入計画の関係者全員が確実に、問題解決に必要な取り組みや変更をすばやく追跡できます。This subtle change helps ensure all participants in the cloud adoption plan can quickly track the required effort and changes to remediation efforts. この追跡は、関連するクラウド導入チームへの割り当てを適切に行うことにも役立ちます。This tracking also helps align proper assignments to the relevant cloud adoption team.

複数のプロジェクトを伴う大規模で複雑な導入計画では、イテレーション パスを更新することを検討してください。For large, complex adoption plans with multiple distinct projects, consider updating the iteration path. 区分パスを変更すると、そのパスに割り当てられているチームだけがワークロードを表示できるようになります。Changing the area path makes the workload visible only to the team assigned to that area path. この変更により、表示できるタスクの数が減るため、クラウド導入チームの作業が容易になります。This change can make work easier for the cloud adoption team by reducing the number of visible tasks. ただし、プロジェクト管理プロセスはより複雑になります。But it adds complexity for the project management processes.

次のステップNext steps

計画作業を開始するためにイテレーション計画とリリース計画を確立しますEstablish iterations and release plans to begin planning work.