この記事は更新から24ヶ月以上経過しているため、最新の情報を別途確認することを推奨いたします。
はじめに
前回の記事はCloud Adoption Framework(以下CAF)のライフサイクルの”戦略”について以下の内容を記載しました。
- 動機の文書化
- ビジネス成果の文書化
- ビジネスケースの作成
- 最初のプロジェクトを選択
今回の記事では”戦略”の次に実施する”計画”について概要を記載します。計画には前回の戦略で立てたビジネス成果を目標とする、実行可能な”クラウド導入計画”を立てるための実施策が書かれています。
前回同様に全体概要を把握するための内容となっておりますのでその点は予めご了承ください。詳細についてはこちらの公式ドキュメントをご確認ください。
計画とは
はじめに説明した通り、計画とはビジネス目標を具体的な技術的取り組みに変換する導入計画のことを指しています。クラウド導入計画により次のような効果が得られると公式ドキュメントで説明されています。
“クラウド導入計画により、クラウド導入戦略の高い目標は実行可能な計画に変わります。 共同するクラウド チームはクラウド導入計画を使用して、技術的な取り組みを指導しながらビジネス戦略に合わせることができます。”
戦略を実行可能な計画にするため、CAFでは次のような支援を行います。
- デジタル資産の収集と合理化
動機やビジネス成果に合わせた想定に基づいてデジタル資産の目録を作成し、合理化案の検討を行う。
※デジタル資産の合理化は後述します。これを行うことで資産の整理とクラウドでのあるべき姿を一覧化できます。 - 組織配置とスキル準備
導入計画を支援する組織編成及びスキルの準備不足に対処するための計画を立てる。 - クラウド導入計画
戦略を具体的な技術的取り組みに変換する、アジャイル且つ反復的な計画を作成する。
■デジタル資産とは
デジタル資産は、仮想マシン・アプリケーション・データなどの物理的資産の他、ビジネスプロセスや操作/機能を向上させる IT 資産のコレクションのことです。
このとき、インフラ移行・アプリ刷新・イノベーション・運用安定などの「望ましいビジネス成果」を理解し、デジタル資産として測定します。
デジタル資産の収集・合理化
合理化の5R+リタイア
デジタル資産をクラウドへ移行する、または最新化を行う上で、対象のワークロードを将来見込まれる最適な状態に分類するため、対象ワークロードに対して評価プロセスを実施する必要があります。
ここでは、各ワークロードを評価・分類する種類について記載します。
5R+リタイア | 説明 | 促進要因 |
リホスト |
リフト&シフト。アーキテクチャ全体への変更を最小限に抑え、現在の状態をクラウドに移動/移行する。 |
資本支出(固定資産維持)の削減。 |
リファクター | PaaS ベースのモデルに適合するように、アプリケーションを少しリファクタリングする。 | コードの移植性。 CI/CDによる迅速なアプリ更新。 リソース、速度、コスト等の弾力性=効率性向上。 |
リアーキテクト | クラウドと互換性がない等の場合、選択する。クラウドネイティブになるよう再設計する。 |
テクノロジースタックが混在可能なとき。 |
リビルド |
差分が多く再設計出来ない場合、選択する。 |
イノベーションしたいとき。 アプリの短期間構築。 運用コスト削減。 |
リプレイス | すべてのアプリケーションを SaaS に置き換える。 常に最高のテクノロジー・アプローチとする。 |
ビジネスプロセス主導のアプローチ促進。 競争力や利点を生み出す他のアプリへの開発リソースを割り当てるとき。 |
リタイア | 不要な仕組みや手続きである場合や他のシステムに統廃合できる場合、そのデジタル資産は廃止する。 | 運用コストの削減。 移行作業コストの節約。 |
収集
合理化の分類について理解したら、企業が保持しておりクラウドへ導入しようとしている”デジタル資産”を収集し合理化を行います。
ここでは収集方法と、どのような一覧を作成すべきかを記載します。
■デジタル資産の分析・収集手法
デジタル資産を分析・収集するための手法として増分型の手法を以下に抜粋・記載します。
手法 | 説明 |
増分型の手法 | 以下の初期のコスト分析、移行計画、リリース計画、分析を実施する。 初期のコスト分析:資産に基づく手法で作業し、合理化せずにデジタル資産全体の初期コストの計算を行う。 移行計画:クラウド戦略チームにてワークロードに基づく手法を使用し、チームの集合的知識と利害関係者にて初回の移行バックログを作成する。 |
ドキュメントでは3手法紹介されていますが、全てを分析せず増分型で分析する手法をマイクロソフトは推奨しています。この手法を用いることで迅速に結果を得られ、且つ意思決定を遅らせる(最後まで最適な方法を探る)ことができます。
■インベントリ作成
増分型の手法にて、分析や合理化が可能なように IT 資産を収集し一覧化します。
また、インベントリは目的としているデジタル変革と、それに対応する変革の過程により変わります。
→クラウドへの移行、アプリケーションの刷新、データの刷新、セキュリティなどが変革の過程でありその内容によりインベントリの内容も変わります。
初回実施時に完全であることはほぼないとされており、ステークホルダーにて検証を行います。また、ネットワークトラフィックの分析や依存関係をツールなどを使用してインベントリとして識別します。
※インベントリの例は「合理化」下部の表に記載しています。
合理化
各資産は、合理化の 5R もしくはリタイヤのいずれかとなります。
しかし、何百何千とあるエンタープライズ規模のワークロードを分類しようとすると時間が掛かり困難であるため、先に示した増分型の手法では、前提条件・定量分析・定性分析などの分析を実施し、最初の10のワークロードを選択します。
- 例)勤怠Webシステム
- Webサーバー、Webアプリ、DBサーバー、DB
- (もしかしたら) 対応ブラウザーとブラウザー拡張機能
- (もしかしたら) 勤怠Webシステムと連携する IC カードリーダーと社員の持つ社員証 (※操作/機能を向上させるIT資産)
これら全てが1つのワークロードで、これらを合理化します。
最初に合理化する10のワークロードを選択したら、クラウド導入チームが最初のワークロードの移行/実装を実行します。その間に、クラウド戦略チームは残りのアプリケーションとワークロードの優先度付けを行います。
デジタル資産のインベントリは戦略と計画のテンプレートとして作成すべきテンプレートが提供されており、以下のような表形式にてデジタル資産を集約し合理化案を検討していきます。
アプリケーション/ワークロード | 事業部門 | ビジネスの優先順位(高、中、低) | 合理化案 |
例)メールサーバー | 全社 | 高 | Microsoft 365 E5 |
例)オフィスアプリケーション | 全社 | 高 | Microsoft 365 E5 |
組織配置とスキル準備
クラウド導入計画で最も重要な側面は、計画を実行する人の配置とされています。ただし、クラウド導入が進んだ後の本当の意味での組織配置には時間がかかるため、計画段階では初期の組織配置を計画します。
ここでは、初期の組織配置とクラウドソリューションにシフトするにつれて求められるスキルセットの準備について記載します。
組織配置
- クラウド導入チームとクラウドガバナンスチームを配置する。
- クラウド導入チームは、実際に作業を行うインフラ技術者やアプリケーション開発者・DevOps エンジニア等の技術実装チームやプロジェクトチーム。
- クラウド ガバナンスチームは、リスクとリスクの許容範囲を評価・管理します。IT ガバナンス・エンタープライズ アーキテクチャ・運用・事業継続とDR・財務所有者等のスキルを持ち、ビジネスで許容できないリスクを特定し、リスクを企業の管理ポリシーに転換するチーム。
- 初期の組織配置では、上記の“クラウド導入” と “クラウド ガバナンス” に対して説明責任を持つ人材を用意します。
- その他のチームはCAFの整理手法の「組織の配置を管理する」にて解説されています。
- 機能を充足するよう人を割り当てる。
※人がいるから機能を割り当てる、のではありません。
クラウドの導入が企業文化全体に拡大していく際、長期的な組織配置に取り組みます。その際はCAFの整理手法で組織を整理します。
スキル準備
現在企業が保持している既存の役割やスキルやプロセスをクラウド向けにするため、現状とのギャップを測定し人員のスキルセットを調整します。
- データセンタースペシャリストがクラウド管理者またはクラウドアーキテクトに置き換えらたり、開発者が DevOps のスキルを身につけたりといったことが発生します。
- CAF や Microsoft Learn を利用してスキルを準備します。
組織配置やスキル準備についても、戦略と計画のテンプレートにてテンプレートが提供されており、以下のような表形式にて対象者と受けるべき学習コース等を検討していきます。
コース名 | 対象者 (クラウドアーキテクト、管理者、開発者、運用者等) | レベル (100, 200, 300, 400) | ソース (MSラーニング、LinkedInラーニング、Udemy等) | 優先順位 (高、中、低) |
Azure 向けの Microsoft クラウド導入フレームワーク | 管理者、開発者、クラウド アーキテクト、ビジネス ユーザー、クラウド エンジニア | 100 | MS ラーニング | 高 |
Azure の基礎 | 管理者、開発者、クラウド アーキテクト、ビジネス ユーザー、クラウド エンジニア | 100 | MS ラーニング | 高 |
Azure のビジネス価値を学ぶ | ビジネス ユーザー | 100 | MS ラーニング | 中 |
DevOpsプラクティス | 管理者、開発者、クラウド アーキテクト、クラウド エンジニア | 200 | MS ラーニング | 高 |
クラウド導入計画の作成
合理化の分類を理解し、デジタル資産の収集と最初に合理化する10のワークロードを選択したら、クラウド導入計画を作成します。
クラウド導入計画は以下の手順で作成し、アジャイルなプロジェクト管理手法によって実施します。
- 戦略と計画を1つにする。
- 戦略
- 明確な動機:クラウドを導入する理由
- 定義されたビジネス成果:クラウドの導入によって見られることが期待される結果
- 業務上の正当な理由:ビジネスの成功を測定する方法
- 計画
- デジタル資産の合理化
- 組織の調整
- スキルの対応性
- 戦略と計画を1つにするとは、ビジネス目標を具体的な技術的取り組みに変換すること。
- HW更新/保守費用の低減を達成するため IaaS/PaaS による弾力的運用やパフォーマンス改善を行う、エンドユーザーとのエンゲージメント改善を達成するためにデータ分析基盤の構築や UI/UX 改善を行う等、ビジネス目標をオンプレからAzureに移行する/あるいはイノベーションすることで達成するという技術的取り組みに結び付ける。
- 戦略
- 順次計画から反復計画へ移行する。
- 方法論として DevOps を使用し、アジャイルなクラウド導入計画を作成・実施する。
※下部に DevOps テンプレートをデプロイした画面イメージを記載しています。
- 方法論として DevOps を使用し、アジャイルなクラウド導入計画を作成・実施する。
- クラウド導入計画を作成する。
- 初期ワークロードを優先順位付けし、性質の違う10のワークロードを選定する。
- アプリケーションやVM・データソース等について、移行・最新化・イノベーション等の追加検証を行う。
- 移行するのか、イノベーション=クラウドで製品開発するのかを再確認する。
- 2を行った結果として合理化決定を見直し、プロジェクト計画を更新する。
- ベロシティを確認し、イテレーション計画及びリリース計画を作成する。
- ベロシティ=チームが1回のイテレーションで処理できる作業量。
※イテレーションは2週間がベストプラクティスです。
- ベロシティ=チームが1回のイテレーションで処理できる作業量。
- タイムラインを見積もる。
- 各ワークロードのマイルストーンやビジネス成果へと影響する、目標とする日付を決定する。
- 各ワークロードのマイルストーンやビジネス成果へと影響する、目標とする日付を決定する。
- DevOps のクラウド導入計画テンプレートについて
Azure DevOps Demo Generator から CAF テンプレートをデプロイします。
すると Boards に戦略・計画・準備で実施すべきワークアイテムが作成されます。
Backlog で User Story を確認したり、それらをイテレーションに紐付けたりといった設定を行います。
初めに実施すべき戦略のワークアイテムを初回のイテレーションに紐付けると、そのイテレーションには紐付いたアイテムのみ表示されます。これらを処理することでベロシティが計測され可視化されていきます。
終わりに
計画は、デジタル資産を収集し、且つ組織配置や要員計画を立て、そして実際に最初の移行・イノベーションに取り組み、どの程度の期間で移行できるのかを測定する ”クラウド導入計画” を作成するフェーズです。
戦略を実行可能な計画に変換・作成するため、開発運用のみならずHQやHR等を含んでクラウド導入計画を立てる必要があるでしょう。
次回はCAFのライフサイクルの準備について記事を記載予定です。