この記事は更新から24ヶ月以上経過しているため、最新の情報を別途確認することを推奨いたします。

この記事ではCAFの計画フェーズにおいて最初に実施する デジタル資産の合理化 の際に必要となる知識 合理化の5R について解説していきます。

はじめに

計画フェーズは戦略フェーズの次に実施します。計画フェーズでは以下の作業を実施していきます。合理化の5Rはこのうち 「1. デジタル資産の収集とインベントリの作成および合理化手法の決定 」を実施する際に必要となる知識となります。

【計画フェーズの流れ】
1. デジタル資産の収集とインベントリの作成および合理化手法の決定
2. スキルの準備、チームの作成
3. クラウド導入計画の作成

ここで重要なのが、計画フェーズを実行する前に戦略フェーズを完了していることです。戦略フェーズではクラウド導入の動機や成し遂げたい成果(ビジネス成果)を決めるフェーズで、特にビジネス成果が計画フェーズを進めていくための前提となります。

戦略、計画の理解促進のために併せて以下も参照してみてください。
Cloud Adoption Framework 計画の概要
Cloud Adoption Framework 戦略の概要
[CAF]戦略と計画テンプレートを使ってみる ～戦略編～ ①
[CAF]戦略と計画テンプレートを使ってみる ～戦略編～ ②

デジタル資産とは

合理化の5Rとはデジタル資産を合理化するための手法のことです。合理化の5Rについて説明する前に、まずはデジタル資産について触れていきたいと思います。デジタル資産を一言でいうと、組織が所有しているIT資産のコレクションのことです。戦略に基づきこのデジタル資産の目録(インベントリ)を作成して合理化するところまでが、最初に記載した「 1.デジタル資産の収集とインベントリの作成および合理化 」で目指すゴールとなります。この一連の流れをCAFでは「合理化のプロセス」と呼んでいます。

参考としてデジタル資産の具体例を記載します。戦略で検討したビジネス成果をベースにして何をクラウドに移行・構築するかを考えることでデジタル資産を特定するヒントとなります。

ビジネス成果	デジタル資産の例
インフラストラクチャの移行	VM、サーバー など ※クラウドへの移行対象となるワークロードを分析することで特定
アプリの刷新	アプリ、API、トランザクションデータなど
データ手動のイノベーション	組織全体のサイロ化されているデータ
安定した運用	ワークロードとビジネス継続性、ディザスターリカバリー、信頼性を向上させるための各資産 ※冗長構成やバックアップ といったシステムを構成しているデジタル資産が考えられる

合理化の5Rとは

改めて合理化の5Rとはクラウドへの移行対象として選定した各ワークロードが、将来的にクラウドではどのような状態が適しているのか分類するための方法です。
戦略、計画の理解促進のために併せて以下も参照してみてください。
Cloud Adoption Framework 計画の概要 の再掲となりますが、合理化の5Rについて各分類の概要を記載します。

リホスト　　　：アーキテクチャ全体への変更を最小限に抑えてIaaSに移行する。
リファクター　： 多少の変更を行いPaaSもしくはIaaSに移行する。
リアーキテクト： 大きな変更を行いマイクロサービス化する。
リビルド　　　： 現行の資産を廃止してアプリをクラウドネイティブに作り直す。
リプレイス　　： すべてのアプリをSaaSに置き換える。

参考：クラウドの合理化、Azure へのアプリケーション移行例の概要

次に合理化の5Rの各分類について掘り下げて説明します。なお、説明のためにアプリケーションのワークロードを例にしています。

リホスト

リフトアンドシフトとも呼ばれます。リホストが一番既存環境への影響や手間がが少ないため、合理化を検討する際には最初に候補に挙がると考えられます。しかしながら既存環境をそのままクラウドに持っていただけの状態のため、クラウドネイティブではないという点が挙げられます。そのためリホストでクラウドに移行した場合はそれがゴールではなく、今後クラウドに最適化していく場合があると考えられます。
リホストを選択する理由としては次が挙げられます。

・アプリをクラウドに迅速に移行する必要がある
・アプリを変更せずに移行する必要がある
・ビジネスにとって重要だがすぐにクラウドネイティブにする必要が無い

リファクター

リホストのように既存環境をそのままクラウドに移行するのではなく、最小限の修正(コード修正を含む)を行いクラウドに最適化して移行します。クラウドを活用するいう観点では可能ならリファクターを選択したいところではないかと考えられます。
アプリケーションの場合には App ServiceやSQL DatabeといったPaaSに移行します。既存のアプリケーションをこれらに移行することがリファクターのイメージとなります。

リファクターは可能であれば選択したほうが良いのではないかと思うので、以下にはリファクターを選択できる条件を記載します。

・App Serviceで動作するようにアプリを再パッケージ化できる
　→App Serviceで動作するようにコード修正ができる
・すでにDev Opsを取り入れている
　→既存のリポジトリからApp ServiceにCI/CDできる　※既存のコードがApp Serviceで動作する必要あり
・すでにコンテナーを使用している
　→例えばAzure Container Registoryにコンテナーファイルを登録し、App Serviceにデプロイが可能

リアーキテクト

個人的にはリファクターをさらに一歩前進させたようなイメージを持っています。変更を最小限に抑えるリファクターに比べて、リアーキテクトでは現行の仕組みマイクロサービスをベースにした仕組みに再設計します。
マイクロサービスアーキテクチャとすることで回復性のあるスケーラブルなアプリを構築することができますが、非常にハードルが高いためまずはリファクターから入るのが現実的であると考えられます。
参考：Azure でのマイクロサービスの構築

リビルド

現行の資産を移行するのではなく、クラウドネイティブなアプリケーションを1から再構築するのがリビルドです。すべての仕組みをPaaS化してフルマネージドにします。
AzureのサービスとしてはFunctionやLogic Appなどのサーバーレスも活用していきます。
リビルドを選択する状況としては以下が考えられます。

・現行のアプリがクラウドと互換性が無い
・現行のアプリの有効期限が差し迫っている

また戦略フェーズにおけるクラウド導入の動機がイノベーションである場合には選択する可能性があります。リビルドはハードルが高いですが、移行よりもイノベーションを推進するという戦略がある場合には、達成したいビジネス成果の観点からリビルドを選択することもあるのではないかと思います。

参考：動機:クラウドに移行する理由

リプレイス

合理化の5RにおけるリプレイスはSaaS化することを意味します。現行のアプリケーションがピッタリと合致するSaaSがあれば別ですが、そうではないことがほとんどだと思いますので基本的にリプレイスが選択されることはないのではないかと考えられます。

・・・・
合理化の5Rについてそれぞれの特徴をまとめてみました。
まとめると移行が優先される場合においては多くの場合リホストまたはリファクターが選択され、イノベーションが優先される場合にはリアーキテクトまたはリビルドが選択される可能性もあるもののハードルは高くいきなり選択するのは難しいだろうということが分かりました。
戦略を踏まえた上で合理化を決定する際の参考になればと思います。