合理化決定を見直す

初期の戦略と計画の段階では、増分型の合理化アプローチをデジタル資産に適用することをお勧めします。 ただし、このアプローチには、結果としての決定にいくつもの前提が組み込まれます。 クラウド戦略チームとクラウド導入チームが、詳細なワークロード ドキュメントに照らし合わせてこれらの決定を見直すことをお勧めします。 この見直しは、ビジネスの利害関係者とエグゼクティブ スポンサーが今後の状態に関する決定に関与するタイミングとしても適切です。

重要

合理化に関する決定は、移行の評価フェーズでさらに詳しく検証されます。 この検証では、合理化のビジネス レビューに重点を置いて、リソースが適切に調整されます。

合理化に関する決定を検証する場合は、ビジネスとの対話をスムーズに進めるために、以下に示す質問を利用します。 質問は、合理化が見込まれる対象別に分類されています。

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

次の質問の共同レビューによって肯定的な回答が得られた場合、ワークロードはイノベーションに適した候補になる可能性があります。 このようなワークロードは、リフト アンド シフト モデルまたは最新化モデルによって移行されることはありません。 代わりに、ビジネス ロジックやデータ構造が、新たなアプリケーションまたは再設計されたアプリケーションとして作り直されます。 このアプローチには多くの時間と労力を要する場合があります。 しかし、ビジネス リターンが大きいワークロードであれば、投資に見合う価値が得られます。

• このワークロードのアプリケーションで市場の差別化を図れるか。
• このワークロードのアプリケーションに関連するエクスペリエンスの向上を目的として提案または承認された投資が存在するか。
• このワークロードのデータで新たな製品やサービスのオファリングが利用できるようになるか。
• このワークロードに関連付けられたデータの活用を目的として提案または承認された投資が存在するか。
• 市場の差別化または新たなオファリングの効果を定量化できるか。 できる場合、そのリターンはクラウド導入時のイノベーションのコスト増に見合うものであるか。

次の 2 つの質問は、合理化の見直しに高度な技術的シナリオを含めるときに役立ちます。 いずれかの答えが "はい" であれば、イノベーションに関連するコストを説明または軽減する方法を特定できます。

• クラウドの導入中にデータ構造またはビジネス ロジックが変更されるか。
• このワークロードを運用環境にデプロイするために既存のデプロイ パイプラインが使用されるか。

上記のいずれかに対する答えが "はい" であれば、チームはこのワークロードをイノベーションの候補として含めることを検討する必要があります。 少なくとも、このワークロードをアーキテクチャ レビューの対象と定めて、最新化の可能性を見きわめるべきです。

移行に関する指標

移行は、より高速でより安価にクラウドを導入できる方法です。 しかし、イノベーションの機会が活用されません。 イノベーションに投資する前に、次の質問に答えてください。 移行モデルがワークロードにより適しているかどうかを判断するのに役立ちます。

• このアプリケーションをサポートしているソース コードは安定しているか。 このリリース サイクルの期間中に無変更のまま安定性を維持することを見込んでいるか。
• このワークロードは現在の実稼働ビジネス プロセスに対応しているか。 それはこのリリース サイクルの全期間にわたっているか。
• このクラウド導入の取り組みにより、このワークロードの安定性とパフォーマンスが向上することが優先事項であるか。
• この取り組みでは、このワークロードに関連するコスト削減を目的としているか。
• この取り組みでは、このワークロードの運用上の複雑さを軽減することを目的としているか。
• 現在のアーキテクチャまたは IT 運用プロセスによってイノベーションが制限されているか。

これらの質問のいずれかに対する答えが "はい" である場合は、このワークロードの移行モデルを検討する必要があります。 これは、ワークロードがイノベーションの候補である場合も同様にお勧めします。

運用の複雑さ、コスト、パフォーマンス、あるいは安定性に関する課題が、ビジネス リターンの妨げとなることがあります。 クラウドを使用すると、これらの課題に関してすばやく改善することができます。 可能な場合は、移行アプローチを使用してまずワークロードを安定させることをお勧めします。 その後に、安定して即応性のあるクラウド環境でイノベーションの機会を進展させます。 このアプローチでは、短期的にはリターンを得られ、長期的には変化の推進に必要なコストを削減できます。

重要

移行モデルには、増分型の最新化が含まれます。 移行アクティビティでは、サービスとしてのプラットフォーム (PaaS) アーキテクチャを使用することが一般的です。 小規模な構成変更でも、こうしたプラットフォーム サービスが使用されます。 移行の範囲は、ビジネス ロジックまたは支援ビジネス構造に対する重大な変更として定義されます。 このような変更は、イノベーションに向けた取り組みと見なされます。

プロジェクト計画の更新

移行とイノベーションでは、取り組みに必要なスキルが異なります。 クラウド導入計画の実装時には、移行とイノベーションの取り組みを異なるチームに割り当てることをお勧めします。 チームごとに独自のイテレーション、リリース、計画のサイクルを設定します。 チームを分けることでプロセスの柔軟性が高まり、1 つのクラウド導入計画を維持しながらイノベーションと移行に対応できます。

Azure DevOps でクラウド導入計画を管理する場合は、親作業項目 (エピック) をクラウド移行からクラウド イノベーションに変えることで、その管理が反映されます。 このわずかな変更により、クラウド導入計画の関係者全員が確実に、問題解決に必要な取り組みや変更をすばやく追跡できます。 この追跡は、関連するクラウド導入チームへの割り当てを適切に行うことにも役立ちます。

複数のプロジェクトを伴う大規模で複雑な導入計画では、イテレーション パスを更新することを検討してください。 区分パスを変更すると、そのパスに割り当てられているチームだけがワークロードを表示できるようになります。 この変更により、表示できるタスクの数が減るため、クラウド導入チームの作業が容易になります。 ただし、プロジェクト管理プロセスはより複雑になります。

次のステップ

計画作業を開始するためにイテレーション計画とリリース計画を確立します。

計画作業を開始するためにイテレーション計画とリリース計画を確立します。