競合する優先順位のバランスを取る
デジタル変革が成功するかどうかは、ビジネスおよびテクノロジの利害関係者が競合する優先順位のバランスを取る能力によって決まります。
他のデジタル変革と同様に、クラウドの導入によって、導入のライフサイクル全体を通じて競合する優先順位が明らかになります。 また、他の変革形態と同様に、こうした優先順位のバランスを取る能力が、ビジネス価値の実現に大きな影響を与えます。 このような競合する優先順位のバランスを取るには、利害関係者間の (場合によっては個人の協力者との) 開かれた (時には難しい) 会話が必要になります。
この記事では、各手法の実装中に一般的に議論される競合する優先順位の一部について概要を説明します。 これは、クラウド導入戦略を策定する際に、こうしたディスカッションに備えるのに役立ちます。
以下のセクションは、上記のクラウド導入ライフサイクル図のフローに沿っています。 ただし、クラウド導入はシーケンシャル プロセスではなく反復的なプロセスであり、このような競合する優先順位はクラウド導入過程のさまざまな時点で再度出現する場合があることを認識することが重要です。
クラウド導入フレームワーク アプローチの一般的なテーマ
モノリシック ソリューションと高度な計画は、いずれも一連の仮定に基づいて構築されており、時間の経過と共に不正確であることが判明する場合があります。 クラウドを導入することは、多くの場合、会社およびその技術チームにとって新しいエクスペリエンスです。 ほとんどの新しいエクスペリエンスと同様に、最初の過程が正しくないと判明する可能性があります。
このフレームワーク内のほとんどのガイダンスでは、技術的な決定の遅延に関して実績のあるアジャイルの基本原則に従うことが好ましいアプローチです。 このアプローチでは、一般的な最終状態を確立し、初期実装に迅速に移行し、仮定をテストして検証し、早期にリファクターして誤った仮定に対処するという一貫したパターンに従います。 このような成長マインドセットでは、学んだことが最大限に生かされ、ビジネス価値に対するリスクが最小限に抑えられますが、多少のあいまいさを受け入れる必要があります。
場合によっては、あいまいさは誤った仮定よりも恐ろしい (またはより危険な) ものになります。 このフレームワークは実装時の学習とあいまいさへの対処を優先していますが、多くの状況では、チームは分析ベースまたは仮定ベースのアプローチを優先する必要があります。 以下のセクションでは、少なくとも 1 つの "範囲の拡張例"を示して、2 回目のより深い反復が役立つ可能性がある場面を説明します。
戦略フェーズでのバランス
戦略手法の中心となる目的は、利害関係者間の連携関係を作り上げることです。 定義が完了すると、連携された戦略的なポジションによって、各手法全体で行動が促進され、技術的な決定が望ましい業務の成果と確実に一致するようになります。 利害関係者間の連携関係を築くことで、、競合する優先順位の共通セット ("正当な理由の深さ" と "業務の成果が出るまでの時間") が作られます。
競合する優先順位:
正当な理由の深さ: 多くの場合、利害関係者は、戦略の方向性の合致に満足する前に、詳細な財務分析と完全な業務上の正当な理由を求めます。 残念ながら、このレベルの分析では、データの収集と分析が可能になるまでに長時間かかる場合があります。
業務の成果が出るまでの時間: 逆に、利害関係者は、定義された時間枠内で業務の成果を出す責任を負うことがよくあります。 分析と評価に時間がかかると、技術的な作業が始まる前に、そのような成果を達成できなくなる危険性があります。
最小範囲: 正しいバランスを見つけるには、プロセスの早い段階で利害関係者間で議論する必要があります。 この戦略手法では、この初期の取り組みの間は連携の範囲を制限することを推奨します。 この推奨されるアプローチでは、利害関係者は、一連の主要な動機、測定可能な成果、高度な業務上の正当な理由に焦点を合わせます。 利害関係者は、いくつかの初期プロジェクトまたはパイロットに迅速に取り組み、必要な学習機会を促進する必要があります。
範囲の拡張例: 初期のビジネス分析でビジネスに悪影響が及ぶ危険性が高いとわかった場合、利害関係者は、業務上の正当な理由の段階で、詳細な分析をより時間をかけて慎重に評価する必要があります。
計画フェーズでのバランス
戦略フェーズと同様に、計画フェーズでも、初期計画と技術的な決定の遅延のバランスを取る必要があります。
競合する優先順位:
クラウドでの技術的な実装の初期計画の深さは、多くの場合、多数の仮定に基づいています。 特に、チームにスキル ギャップがある場合、環境の検出のギャップに悩まされたり、ワークロードのアーキテクチャの最終状態が明確に定義されません。 こうした仮定はいずれも、詳細なクラウド導入計画でよく見られます。 これらの仮定を検証または改善するには、実験、パイロット、および定性分析が必要です。
技術的な決定の遅延では、技術的な決定を下すタイミングを遅くするほど、その決定がより正確になるという仮定に基づいています。 アジャイル製品計画の基本原則に従うことで、技術的な決定を遅らせることができ、十分な情報に基づいて適切なタイミングで決定できます。 ただし、このアプローチでは、初期計画がさらにあいまいなものになります。
最小範囲: 管理可能な計画内で即時のアクションを推進するために、アジャイル製品開発アプローチをお勧めします。 計画手法では、次の手順でこのバランスを実現することをお勧めします。
- 自動検出ツールを使用して完全なデジタルアセットの目録を作成します。ただし、段階的な合理化を使用して、今後 1 から 3 か月くらいの作業の計画を立てます。
- 迅速に対応するために、組織の適切な連携を確保します。
- 割り当てられたチームのスキル準備計画を立てます。 戦略と計画のテンプレートを使用して、初期バックログを迅速にデプロイします。
範囲の拡張例: クラウド導入計画の遂行は、時間に左右される、または影響の大きいビジネス イベントに対応して行われる場合があります。 成功させるために、一定期間内に多数のアセットを移行する必要がある場合、前述の手順に続いてより深い計画作業が行われることがよくあります。 このようなシナリオで成功するための鍵は、十分な計画を立ててから、その後、完全なエンゲージメントを計画することです。 このアプローチによって、計画が業務の成果を妨げる可能性が低くなります。
準備フェーズでのバランス
チームがクラウド導入への最初の手順の準備をしているとき、導入までにかかる時間と長期的な運用の間で優先順位が競合することがよくあります。 チームは、目の前のタスクを遂行するのに適していることと、適切に管理されることとの間のバランスで悩むかもしれません。 このような悩みは、プラットフォームの開発には物理的なアセットと獲得サイクルが必要な従来の IT 環境で必ず生じます。 ただし、IT プラットフォーム全体がコードで定義されている場合、リファクタリングなどの従来の開発戦略では、最初から適切に管理する必要が軽減されます。
競合する優先順位:
長期的な運用: 多くの場合、組織は、現在の運用管理、ガバナンス、およびセキュリティ システムと同等の機能を満たすクラウド環境を確保するという要望が妨げになっています。 ある調査では、組織の 90% 以上がその考え方を克服するためにサポートを必要としていました。 この阻害要因により、数か月間の遅延が発生し、業務の成果が遅れたり妨げられたりする可能性があります。
導入までの時間: Azure Policy、継続的インテグレーション、継続的デリバリー (CI/CD) アプローチ (Infrastructure as Code (IaC)、管理グループなど) などのクラウドベースのツールを使用すると、IT プラットフォーム全体でリファクタリングのプロセスを簡略化できます。 さらに、事前に定義されたランディング ゾーンがあると、多くの機能パリティ要件を既に満たしている環境への展開を加速できる、推奨事項を用意できます。 これらのツールは、長期的な運用への影響を最小限に抑えながら、市場投入までの時間を短縮する機会を提供します。
最小範囲: 準備手法は、迅速な導入から長期的な運用への直接的な道筋を示しています。 このアプローチは、環境をリファクターするために使用できるツールの基本的な概要から始まります。 このツールは要件を考慮して、事前定義されたランディング ゾーンの選択をガイドします。各ランディング ゾーンは IaC モデルで提供されます。 その後、クラウド導入の過程でこのコードをリファクターし、運用、セキュリティ、および管理を向上させることができます。
範囲の拡張例: 導入計画で 1,000 を超えるアセット (アプリケーション、インフラストラクチャ、またはデータアセット) をクラウドにホストするという中期目標 (24 か月以内) を必要とするチームの場合、より堅牢なビューのランディング ゾーンをお勧めします。 このような状況では、最初のランディング ゾーンの会話中に、ガバナンスと管理の手法を検討する必要があります。 ただし、このより深い検討により、クラウド導入計画に数週間から数か月が追加されることがよくあります。 業務の成果への影響を最小限に抑えるために、導入チームは、クラウド内で実際のワークロードをパイロットすると同時に、より成熟したランディング ゾーンと中央アーキテクチャ ソリューションを作成する必要があります。
移行フェーズでのバランス
移行中、導入チームは一般的に、ワークロードが現在の構成でクラウドにリホストされると仮定しています。 この仮定は、すべてのワークロードを再構築してクラウド機能をより有効に活用する将来を見据えた計画と競合します。 この 2 つの見方は相互に排他的なものではなく、共通のプロセスを使用して管理すれば両立させることができます。
競合する優先順位:
リホスト: 組織は多くの場合、移行を、すべてのアセットを現在の構成でクラウドにレプリケートする "リフトアンドシフト" アプローチとみなしています。 このアプローチにより、IT ポートフォリオ内の誤差がほとんどなくなります。 これは、既存のデータセンターのアセットを廃止する最速の方法でもあります。
再設計: 各ワークロードのアーキテクチャを最新化することで、コスト、パフォーマンス、および運用全体にわたってクラウド導入の価値が最大化されます。 ただし、このアプローチは時間がかかり、多くの場合、各アプリケーションのソース コードへのアクセスが必要になります。
最小範囲: 初期段階の計画では、この選択は技術的な決定ではなく、最初のビジネスの仮定に基づいていることを明確に理解したうえで、計画にリホスト オプションを使用します。 この移行手法では、クラウド導入チームは移行されたワークロードごとにこの仮定を検討します。 この手法では、各ワークロードまたはワークロードのグループに対する評価/移行/昇格アプローチに従い、移行ファクトリを作成します。 評価フェーズで、導入チームは、各ワークロードの技術的な適合とアーキテクチャを評価します。 アーキテクチャ内のコンポーネントの多くはリファクタリングと最新化のために選択される傾向があるため、その評価作業が純粋なリフトアンドシフト アプローチになることはほとんどありません。
範囲の拡張例: メインフレームや多層マイクロサービス アプリケーションなどのミッション クリティカルな、または機密性の高いワークロードの場合、評価フェーズでワークロードのより徹底的な評価が必要になる場合があります。 このような再構築の状況では、Azure Well-Architected レビューと Azure Well-Architected フレームワークを使用して、評価の間にワークロードの要件を調整する必要があります。
イノベーション フェーズでのバランス
真の顧客向けイノベーションによって、計画された機能セットを実現する必要性と、顧客の共感を得るプロセスの実装との間に競合する優先順位が頻繁に生み出されます。
競合する優先順位:
機能の焦点: イノベーションの初期計画は、顧客のニーズを満たす一連の機能を提供する既存のデジタルアセットとクラウド機能に基づいて構築されます。 この計画によって技術的な実装を簡単に促進し、開発作業に焦点を絞った機能を実現できます。 このアプローチは、多くの場合、一時的な利害関係者の満足にはつながりますが、顧客行動に影響を与えるイノベーションを促進する可能性は低くなります。
顧客の共感: 初期計画は、開発のビジネス面の重要な部分であり、定期的なレポートに含める必要があります。 ただし、顧客の共感を目標として学習、測定、および構築することは、イノベーションの取り組みにおいて成功をより正確に測定することになります。 機能よりも顧客に焦点を当てると、短期的および長期的な顧客満足度と業務の成果につながる可能性が高くなります。
最小範囲: イノベーション手法では、ビジネス価値の合意を通じて戦略と計画を統合する方法が示されます。 また、このガイドでは、イノベーションの各分野と実装のベスト プラクティスを加速できるクラウド ネイティブ ツールを紹介します。 最後に、プロセスの改善に関するセクションでは、クラウド導入過程で計画と戦略を尊重しながら、顧客の共感を構築するためのアプローチを示します。 このアプローチは、できる限り少ないテクノロジを使用してイノベーションを実現することに焦点を当てています。
範囲の拡張例: イノベーションは、ミッションクリティカルなワークロードや機密性の高いワークロードに左右される場合があります。 顧客が社内ユーザーの場合、最初期の繰り返しの間、開発作業がミッションクリティカルかつ機密性の高いものになる場合があります。 このようなシナリオでは、導入チームは Azure Well-Architected レビューと Azure Well-Architected フレームワークを使用して、プロセスの初期段階で高度なアーキテクチャ設計を評価する必要があります。
ガバナンス フェーズでのバランス
クラウド ガバナンスの実践とは、2 つの競合する優先事項 (速度と機敏性という事項と適切に統制された環境という事項) の間でバランスを保つことです。 クラウド ガバナンス チームは、統一された制御と変更の最小化により、ビジネスに対するリスクを評価および最小化することに焦点を当てています。 導入チームは、新しいリスクが必ず生じ、それによって変化がもたらされる業務の成果の推進に焦点を当てています。
競合する優先順位:
- 適切な統制: リスクを最小限に抑えるように設計されたすべての制御は、変更の一部の妨げになったり、設計の選択肢の制約になったりします。 制御は、適切に統制された環境には不可欠です。 ただし、制御を個別に設計および展開すると、防ぐつもりのリスクと同じくらいの損害が生じる可能性があります。
- 速度と機敏性: 速度と機敏性は、デジタル経済における基本的なビジネス要件です。 どちらも、イノベーションや導入を妨げるものを最小限に抑えて変更を推進する能力が必要です。 しかし、ガバナンスなしで変更を推進すると、予期せぬ形でビジネスに悪影響を及ぼす可能性のある新しいリスクが生じます。
最小範囲: ガバナンス手法では、ガバナンスも導入も単独で行われるべきではないことが推奨されます。 この手法は、ガバナンスの規律の理解と、ビジネス リスク、ポリシー、およびプロセスに関する会話から始まります。 ガバナンス チームは、クラウド導入全体の積極的な参加者として、クラウド導入計画内の具体的なリスクに対処するための最小限の一連のセーフガードを実装できます。 時間の経過と共に、ガバナンス チームは、新しいセーフガードをリファクターおよび拡張し、新しいリスクに対応することができます。 このアプローチを採用すると、リスクを最小限に抑えながら、学習とイノベーションを最大化できます。
範囲の拡張例: ビジネス リスクが高い場合は (特に導入の初期段階では)、クラウド ガバナンス チームはガバナンスの実装の拡大を加速する必要があります。 このより高いレベルのガバナンスを追加するには、同じガイダンスと演習を使用できますが、より迅速に進める必要があるかもしれません。 一部のシナリオでは、最初のランディング ゾーンの開発中に、高度なガバナンスの状態が必要になる場合もあります。
管理フェーズでのバランス
運用管理に関する IT ビジネス モデルは、過去 10 年間にわたって継続的に進化してきました。 ハードウェア メンテナンスが IT の中核的な価値提案ではなくなるにつれて、運用管理に対する見方も変化しています。 IT がビジネス価値の提供に重点を置くようになるにつれて、運用管理チームは、運用なし、および低運用と広範な投資とのバランスを取る必要性との葛藤に直面しています。
競合する優先順位:
広範な投資: 環境全体の停止回避、迅速な復旧、および監視に等しく投資することは、運用管理に対する従来のアプローチです。 このアプローチはコストが高くなり、場合によっては、クラウド ベンダーが提供するサポート製品と重複する可能性があります。
運用なしと低運用: クラウドネイティブの運用ツールを使用して、以前は従業員が行っていた反復的なタスクを最小限に抑えます。 これらの運用上の依存関係を減らすと、従業員は他の方法で価値を高めることができるようになります。 ただし、このアプローチ単独では、運用サポートが不十分なものになる可能性があります。
最小範囲: 管理手法では、クラウドネイティブの運用なしベースラインを確立することが推奨されます。 運用なしベースラインではすべてのビジネス ニーズが満たされるわけではないことを認めたうえで業務に取り組み、コミットメントを定義し、投資をより適切に調整します。 すべてのワークロードの共通ニーズを満たすためにベースラインを拡張します。 次に、プラットフォーム チームまたは特定のワークロード チームが、適切に管理された環境内で適切に管理されたソリューションを維持できるようにします。
範囲の拡張例: ほとんどの環境では、IT による運用への多額の投資を正当化する、ビジネス価値があるワークロードの割合はわずかです。 このようなシナリオの場合、IT チームは、Azure Well-Architected レビューと Azure Well-Architected フレームワークを使用して、より詳細な運用をガイドすることもできます。
整理フェーズでのバランス
この記事で説明している優先事項には、速度と機敏性に対するビジネス ニーズを実現しようとする IT の推進力が反映されています。 これと同じ変化が組織図や仮想チーム構造の変更に現れ、業務の成果に対するサポートが向上します。 IT リーダーはチーム構造を検討するときに、一般的に 2 つの競合する優先事項 (一元管理と委任管理) に対処します。
競合する優先順位:
一元管理: この運用モデルでは、厳格なポリシーを実施するために必要なすべての管理の一元化に焦点が当てられています。 このモデルでは、IT はイノベーション、速度、機敏性を妨げるものになります。 ただし、IT は安定性、コンプライアンス、およびセキュリティのレベルを高めることができます。
委任管理: この分散型の運用モデルでは、各 DevOps チームまたはビジネス アプリケーション チームが、事業目標の達成に必要なソリューションに基づいて、独自の一連の管理を用意することを前提としています。 このモデルでは、チームがリスクを回避できるようにガイドラインを提供します。ただし、強制される技術的な制約の数をできる限り最小限に抑えます。
最小範囲: ほとんどの組織は、時間の経過と共に自然な一連の進化を経ます。 整理手法では、最も一般的な一連の進化の概要を説明します。 チームは、委任管理アプローチを実現するために、クラウド センター オブ エクセレンス (CCoE) 構造に移行するよう努めることをお勧めします。
範囲の拡張例: 多くの状況で一元管理の必要性がトリガーされます。 サード パーティのコンプライアンス要件と一時的なセキュリティ侵害は、一元管理のトリガーの 2 つの例です。 このような状況では、一般的に、制限ポリシーと厳格で固定された管理を確立する必要があります。 ただし、イノベーションと導入を継続できるようにするために、中央の IT チームが各ワークロードの重要度と機密性に基づいてこのような管理を実現することをお勧めします。 管理が少なく、範囲またはリスク プロファイルを減らした環境を用意することで、管理が必要な場合でも柔軟に対応できます。
次のステップ
クラウド移行の取り組みの価値を最大限に高めるために、移行、イノベーション、実験のバランスを取る方法を確認します。