失敗しないクラウド移行計画の立て方（実践的な6つのStepを解説）

こんにちは。CTOの十川です。

NCDCでは、既存システムのクラウド移行に関する計画立案や、クラウド上でシステムを構築する際のアーキテクチャ検討など、これからクラウド活用に取り組むお客さまのサポート（コンサルティング）をよく行っています。
また、コンサルティングのみならずシステム構築まで請け負う案件や、自社プロダクト用にシステム構築をする機会もあるので、実際にクラウドを使い込んだ豊富な経験も有しています。

この記事では、それらの実績から得た知見を盛り込んだ、移行計画の進め方や注意すべきポイントなどを解説します。

クラウド移行計画の課題

クラウド移行の計画段階で難航しているプロジェクトでは次のような課題をよく聞きます。

• 何から手を付けていいのかわからない
• いろいろな移行の仕方があるが、どれが良いのかわからない
• 機密データのため、クラウド化することをリスクに感じている
• なんとなくクラウド化したほうが良いと思っているが、セキュリティの心配など反対意見が多くて進められない

こうした漠然とした不安や、部署間の意見調整に時間がかかって前進しないという課題は、次項から説明していくプロセスを踏んでしっかりした移行プランを組み立てることで、その多くを解決できるのではないかと思います。

クラウド移行計画のプロセス

ここから、NCDCで使用している移行計画のプロセスに沿って6つのStepを紹介していきます。
実際にはプロジェクトの特性に合わせてタスクが追加になったり、順番が変わったりしますが、今回はこのベースのかたちを用いて説明していきたいと思います。

Step1. クラウド移行の目的を決める

一言でクラウドといってもさまざまな機能や用途があり、何を主目的にするかによってクラウド移行のアプローチも異なります。
立場によって目的が異なることは想像しやすいと思いますが、実は、同じ部署に属する人どうしでも想定内容が異なっていることがよくあります。

そのため、まずこうした基本方針を確認することが大切です。

• どこまでクラウド化するのか
• それによって何を実現したいのか

目的を合わせていないと、計画を検討する際に優先度の付け方が人によって異なったまま話を進めることになり、何度も同じ議論を繰り返してしまいがちです。そうした時間を浪費しないために、まずはクラウド移行を何のためにやるのかをチーム内、関係者、経営層と認識を合わせておく必要があります。

どの程度の粒度で「目的」を定めておくかというと、できるだけシンプルで関係者全員が共通認識を持てるものが必要です。
例を挙げると次のようなものが考えられます。

この場合、「対象となるシステムはクラウドに最適化した構成で再構築。開発プロセス含めて刷新する。変更頻度の低い社内システムはクラウド化の優先度を下げる。」といったアプローチが考えられそうです。

この場合は、「現契約が切れるものから順次クラウドに移行して自社でのサーバーのメンテナンスはやめる。」「アプリケーションはクラウド上で動かすための最低限の改修だけ行い、移行を最短、低コストで行える手法を選択する。」といったアプローチが考えられそうです。

Step2. 目的を具体的な施策に詳細化する

次に、Step1で定義した目的を実現するために何が必要なのか、クラウド移行の候補となるシステムはどれなのかを洗い出します。
ここでは企画メンバーだけではなく、現行システムの担当者や、場合によってはインフラチーム、運用チームなども交えて検討することが必要です。

言葉にすると簡単に見えますが、こうした多くの利害関係者がいる会議がうまく機能せず移行の障害となっているケースは多いようです。

NCDCがコンサルティングに入らせていただく場合は、部署をまたいで多くの方に参加してもらうワークショップなどを実施することがよくあります。
クラウド移行プロジェクトの経験が豊富なコンサルタントがファシリテーターを務め、関係者が対話しながら進められる手法を使って施策の抽出を行い、一覧に整理していくのです。
（こうした会議のファシリテーションで困っているプロジェクトがありましたら、ぜひ一度ご相談ください。）

Step3. 着手の優先順位を決める

候補となるシステムが複数ある場合、すべて並行してクラウド移行を進めるのではなく、優先度の高いものから順次着手します。
その順番は、Step1で定義した「クラウド化の目的（得られるメリット）」と、「クラウド化の難易度（技術的な難易度、移行にかかるコスト、リスク）」の二軸で評価し、基本的に「クラウド化の目的に合致していて、難易度の低いもの」から着手すべきです。
それを表したのが次のマトリクスです。

• 上下が定義した目的に対する効果（上が効果が高く、下が低い）
• 左右が移行のコストやリスク、技術的な実現性などを評価した難易度（右が難易度が低い、左が高い）

つまり、右上に行くほど効果は高く、難易度が低いものになるので、この領域が最初に着手すべきものになります。
このマトリクスにStep2であげた施策やシステムをプロットしていきます。施策かシステムのどちらを評価したいかで使い分けてください。

ここでは、どの順番で取り組んでいくべきかの優先度を決められれば良いので、プロット位置の正確性は重要ではありません。システム間、施策間の「相対評価」が行えればOKです。
次の図でプロットしている番号が施策一覧、またはシステム一覧に記載されている番号だと思ってください。

対象システムの相対評価はこのようにマトリクスに直接プロットしていき、関係者で認識が合うのでしたら、それで十分です。
もし合意形成にもう少し議論が必要な場合は、次のような表を用いて評価項目ごとのスコアリングをしていき、このスコアで合意形成できてからマトリクスに配置するというアプローチもあります。

ここまでで各施策間、移行候補システム間の優先度付はできましたので、次は「どこまでの範囲をいつまでにやるのか」を計画していきます。

Step4.スケジュールを決める

移行の優先順位を具体的なスケジュールに落とし込んでいく際には次の２面から評価していきます。

1. ビジネス的にいつまでに必要か、もしくはメンテナンス契約が切れる期限などのニーズから来るスケジュール
2. 実際に移行を行うチームやベンダーからでてくる概算の費用と期間（このタイミングでは正確に見積もりを行うための情報は提供できないと思いますので、まずは参考情報程度のものを収集することになります。）

上記1,2の情報を踏まえて「Phase1ではいつを期限とし、どこまでやるか」「Phase2では…」というかたちでいくつかのフェーズに切り分けていきます。
Step2で用意したマトリクスに、各フェーズの対象がどれかという情報も加えて表現したのが次の図となります。

このサンプルはPhase1で施策7,9,1を実施し、Phase2で6,8,4を実施するということを表現しています。

上の図をスケジュールとして表現したのが次の図です。

Phase1では比較的リスクの少ないシステムに着手する設計になっていますが、もしクラウド化に技術的な不安がある場合、クリティカルなシステムに取り組む前に、Phase0として実際には商用リリースしないシステムをつかって一通り移行の手順を経験してみるというのも有効です。

Step5. 非機能要件の検討

次に非機能要件の検討を行います（Step4で必要となる概算の見積もりを行うためにも必要なので、タイミングとしてはStep3〜4と並行して取り組みます）。

IT部門の方以外は「非機能要件」がわからない方も多いと思うので、簡単に説明します。
非機能要件とはアプリケーションの画面や業務ロジックなどではなく、処理性能や、セキュリティ、格納できるデータ容量などの機能以外の要求を定義したものです。

例えば、次のようなものが非機能要件です。

• システムの稼働時間は？夜間は止めても大丈夫？
• 同時に使う人数は？障害発生をどこまで許容するか（障害発生時の復旧までの時間）
• ソフトウェア更新時にシステムが止まっても大丈夫？
• データのバックアップの頻度は？
• システムログはどこまで必要？（障害を追うことができればよい？　個人単位のアクセス履歴が必要？　保存期間は？ 3ヶ月 or 1年 or 永続？）

もちろん処理できる量や耐障害性は高ければ高いほど良いのですが、要求が高くなると当然コストも上がるので、どこまでできていればOKなのかを定義しておく必要があります。
ここで決めたことはインフラの構成やコストの見積もりの根拠となります。

Step6. アーキテクチャの検討

最初の移行対象が決まったら、移行を実行する前にどのようなアーキテクチャでクラウド上に移行するのかを検討しておく必要があります。
下図はAWSが定義する移行パスです（NCDCで簡単な説明を書き加えています）。

この考え方によると、まず対象の洗い出しを行い（Discover）、それぞれの方針を決定していきます（Determine）。
なかにはクラウドに移行せずRetain（そのまま）、Retire（破棄）という決定になるものがあります。
移行する方針となった場合は以下のパスが候補となります。

• Rehost、Relocate：アプリケーションはそのままで、クラウド上に配置だけを変える
• Replatforme：アプリケーションのコア部分はそのままで、一部、クラウドに最適化させる
• Repurchase：アプリケーションの機能をクラウド上のサービスで置き換える。例えば認証機能をAWS Cognitoに置き換えたりするものが対象となります。
• Refactor：クラウドを前提とし、設計段階からクラウドに最適化させて再構築します。

これらの中からどの移行パスを選択するかは、前述の「移行の目的」と、対象のシステムの使用している技術（プログラミング言語、使用しているミドルウェア、フレームワーク等）や、アプリケーションの作りに依存します。

例えば、既存のアプリケーションがWebベースの技術でできており、いかに短期間、低コストでクラウド化するかが目的であれば、Rehostのアプローチが適しています。
アプリケーションを迅速に開発することが目的であれば、クラウド化とともに、マイクロサービス化やサーバレス化を検討するRefactorのアプローチが適していると思われます。

NCDCは、このRefactorにあたるもの。つまり「設計段階からクラウドに最適化させて再構築するアーキテクチャ（クラウドネイティブアーキテクチャ）」を得意としています。先端的なクラウドサービスを活用した、より良いアーキテクチャをご提案できると思いますので、この方針で検討されている方がいたらぜひ一度ご相談ください。

クラウドマイグレーションの相談はNCDCへ

各Stepのポイントをまとめるとこのようになります。

• Step1: チーム内、関係者、経営層と認識を合わせて「クラウド移行の目的を決める」
• Step2: 要求事項や移行候補を洗い出し「目的を具体的な施策に詳細化する」
• Step3:「効果」と「難易度」の二軸から「着手の優先順位を決める」
• Step4:ビジネス面の要求や移行にかかる費用を加味して「スケジュールを決める」
• Step5:移行後のシステムに求める処理性能など「非機能要件の検討」を行う
• Step6:移行の目的と対象のシステムの技術を踏まえて「アーキテクチャの検討」を行う

NCDCでは、Step1〜6を網羅したクラウド移行の計画立案から、移行の目的に合わせたアーキテクチャの設計や実装段階の技術支援まで、クラウド移行に関する幅広いサービスを提供しています。
システムアーキテクチャコンサルティング
クラウドインテグレーション
マイクロサービス導入支援

これからクラウド移行に取り組みはじめる方はぜひご相談ください。