マイグレーションを実現するために - 第 2 回 : 移行戦略と移行パスとは ?

さて、移行戦略とは何でしょうか ? 

いろいろな解釈はあると思いますが、

何のために、何を、何に、いつまでに、どの様に移行するのか

を決めておくことです。

この移行戦略をきちんと作らずに移行を始めてしまうと、移行プロジェクトが何らかの原因で進行が遅れた際や止まってしまった際に、混乱の末に何で今このプロジェクトやっているのか、と言うそもそも論の議論を引き起こす原因にもなりますし、その議論が沸騰した際の「立ち戻り先」がない状況になります。よって、この移行戦略を移行が開始される前に決めておくことはクラウド移行をブレなく実行するためにも非常に重要なことなのです。

ただし、移行戦略について考える前に、そもそも今抱えている課題がクラウド移行により解決されるものなのかを検討する必要があります。もちろん、クラウド移行はあくまで手段であり目的ではないため、どの様にすれば課題が解決できるかは入念に検討する必要があります。以降はクラウド移行が有用であると判断された前提で話を進めていきます。

では、移行戦略の一つ一つを見ていきましょう。

はじめに、「何のために」と「何を」ですが、第 1 回でお話をさせていただいたとおり、多くの企業において、ビジネスの発展のためデジタルトランスフォーメーションが必要であり、既存システムにかかっているコストをビジネス環境の変化に対応できるシステムへの投資に振り分けるためIT負債を解消するということが必要になっています。この様にクラウド移行がビジネスの課題解決に有用であると判断された際は、移行戦略の中の「何のために」と「何を」にこれらの理由があたっていきます。

さて、次の「何に」が色々選択肢が出てくるところです。

現在、オンプレミスで情報システムを運用されている企業において、今のままオンプレミスで行くのか、クラウドに行くのか、SaaSやパッケージの適用が可能か、どのクラウドを利用するべきか、と言ったことを考える必要があります。これらはそれぞれに考慮ポイントがあります。

もちろん、一度クラウドに移行すると長く使うことになりますので、クラウドベンダーの企業ビジョン、市場シェア、業界での評価、コスト低減の実績、パートナーやコミュニティの規模、Web や書籍等での情報入手の容易性、導入実績、第三者観点での稼働率の実績、等をユースケースに加えて判断材料とすることが必要になります。

これらを網羅的に検討することにより、「何に」が決まります。

次は、「いつまでに」ですが、これは様々な状況によって異なるポイントです。
データセンターの廃止が見えている際はその廃止時期が期限になりますし、そのような期限がない場合は、ハードウェアやミドルウェアの EOSL のタイミングが期限になるでしょう。実際は、そのような期限に加えて、社内稟議のリードタイム等を考えて、いつプロジェクトを開始すればよいか、という逆算でスケジュールを引いていくことも必要になります。

最後に「どのように」です。
クラウド移行に際して、どのようなアーキテクチャを採用するのか、ということを個々のシステムごとに考える必要があります。これを移行パスと呼び、英語の頭文字を取って 7 つの R でまとめることが出来ます。

これらは、既存システムが戦略的に変化対応力を求めるシステムなのか、現状のまま稼働し続けることを重視するシステムなのか、また既存のシステムのアーキテクチャや、使用しているパッケージやミドルウェアがどういったものなのか等を把握し、最初の段階で移行パスを決めておくことが必要になってきます。例えば、データセンターの契約終了が近いためまずはリロケートにてクラウドに移行するとしても、将来的にはビジネス価値最大化のためサーバーレスのシステムに移行する、といったような「意思ある二段階移行」を最初から考えているのと全く考えていないのではその後の対応に大きな変化があります。移行戦略を最初に検討していなかったために、リホストすることがゴールとなってしまい、本来のクラウドのメリットを享受しきれていないのでは、といった状況も目にしているのが現状です。

では、移行パスはどのような観点をもって選択すればよいのでしょうか。
観点は色々あるかと思いますが、

• クラウド適合度
• クラウド移行難易度

の 2 つの軸で検討することも一案かと思います。
ビッグデータや機械学習はすでにクラウド上で稼働させることが標準であることや、MySQL や PostgreSQL を使っている場合はライセンスに左右されること無くクラウド移行が可能であることから、クラウド適合度は高いと評価できるでしょう。また、クラウドではリージョン間で災害対策 (Disaster Recovery : DR) の構成が容易に取れることや、標準で世界中のリージョンが利用できることからクローバル展開が必要なシステムも適合度が高いと言えます。

一方で、メインフレームや商用 Unix、アプライアンスを利用している場合、そのままではクラウドへ移行できない事や、TCP/IP ベースでない通信プロトコルを利用している場合はクラウド移行難易度が高くなると考えられます。

システムを点数化したサンプルの図は以下のとおりです。システムごとの大まかな特性に応じて推奨される移行パスを示したものです。また、この図は大まかな移行パスを示すとともに、現在のシステムポートフォリオを示すこととなります。なお、以下の例は移行対象システムの対象が企業全体であったり、ある事業部門全体といった広い範囲の場合のアプローチを示していますが、システム数が少ない場合は必ずしも分類の必要はなくシステム単位で移行パスをご検討頂く方がシンプルかと思います。

これら企業毎に異なる様々な事情やシステムの特性を点数化し、システムごとにクラウド適合度とクラウド移行難易度の軸で分類し、大きな枠で移行パスを決めていくということを最初にするだけでもその後のクラウド移行の検討工数削減の実現が可能になります。また、移行パスを考える際には、データ連携があり関連が強いシステム群や、CRM や SCM などの業務分類での一括移行も検討されるべきです。

移行戦略を策定する中で、必ずやっておくべきなのが、大きなまとまりを踏まえたシステムごとの移行パスの策定なのです。

ビジネス価値の最大化を見据えてクラウド移行を行う際に、クラウド移行の最初の段階で移行戦略を考えておくこと、移行パスを決めておくことがほぼ移行戦略そのものであり、かつ移行戦略の最も重要なことであると言えるでしょう。加えて、外部環境、内部環境の変化やテクノロジーの変化に応じて、移行期間中に移行パスを含めた移行戦略の見直しをかける柔軟性も必要だと言えます。

今回は、クラウド移行の移行戦略と移行パスについてご紹介しました。移行戦略を最初に決めておくことでクラウド移行に関するブレがなくなりますし、企業によって様々なシチュエーションがあり評価の観点も異なると思いますが、移行パスの選択根拠を数値化して決めておけばなぜそのアーキテクチャを採用したのか、なぜ採用する必要があったのかをあとからトラッキングすることも容易にできるようになるなど、非常に重要なポイントであることをお話させていただきました。

次回は、既存システムの「具体的な移行方法」についてお話したいと思います。お楽しみに !