クラウドへの移行リスクを見極める事前調査ガイド

クラウド/DX

2020.05.19 2020.05.08

この記事は『クラウドへワークロードを移行するための手順』という記事のうち、移行に向けた調査フェーズを詳細に説明した記事になります。

全体像が知りたい方は下記をご覧ください。

なぜ移行前の調査が必要なのか

まずは、移行作業に着手する前になぜ調査をすべきなのか、理由を説明します。

クラウドは万能の技術ではありません。オンプレミスとは違い、絶えず技術は新しくなっていきますので、古いOSやミドルウェアは載せ替えることができません。

具体的にはWindows Server 2008などサポートが切れたOSを新たにクラウド上で構築することはかなりの制約が発生してしまいます。

また、極端に大きなストレージなども、移行不可能でないにせよ手段が限られることがありますので注意が必要です。

こうした、技術的な観点から事前のアセスメントが必要になります。

ビジネスの状況いかんによっても移行は左右されます。

例えばユーザが絶えず利用するサービスなのでデータ移行や切り替えのタイミングがシビアであるというような場合、メンテナンス等に合わせて作業を進める必要がありますので移行が遅くなりがちです。

特にユーザデータなどを持つDBサーバは切り替えが難しいため、Webサーバなどに比べて後回しにされることがよくあります。

こうしたサーバについては、内外で十分なヒアリングが必要になります。

また、この調査フェーズ自体が、典型的には1~4ヶ月程度の期間を要します。移行しなくても最低限のコストはかかりますので、それも織り込んでおく必要があります。

移行作業は、調査や実験も含めて一時的にコストが増大しがちです。

このコストとは金銭的なものだけでなく、時間や、新しい技術の習得コストも含んでいます。

予めリスクと必要なリソースを見積もり、スケジュールを立てなければプロジェクト自体が立ち行かないばかりか、他のシステムの運用にも支障をきたすことがあります。

ここからは、上記の観点をベースに、具体的にアセスメントを進めるための手順について考えていきます。

フレームワークについては、大きくビジネス観点とテクノロジー観点に分けることができます。

ビジネス観点でのアセスメント責任者は、主にCEOやCFOです。場合によってはHRの責任者の手も借りる必要があるでしょう。

基本的に判断すべきは下記のような図に表すことができます。

もちろん、これらの試算は後述の技術的な調査後にしか判明しませんし、将来的なリスクを完全に算出できるものではありません。

しかし、こうした数年単位でのロードマップを引くことで、経営的な判断がしやすくなることは事実かと思います。

また、上記の図ではいわゆる基幹システムを想定しコストメリットの点から妥当性を計っていますが、クラウドに習熟することにより、ユーザの目に触れるようなサービス面での開発効率が上がるなどの効果も判断材料に加えるべきです。

次にテクノロジーの観点からの調査事項です。本稿ではこちらの方にやや重きを置いて説明しています。

移行作業に伴う技術的な調査は最も時間を使うべきポイントです。事前にリスクを洗い出しておくことで、POCや本番移行作業での手戻りを減らすことができます。

■ワークロードの移行

ワークロードの移行にあたっては、かなり細かくかつ多項目にわたって情報の収集が必要になります。

サーバOSのバージョンや搭載されているソフトウェアはもちろん、停止していい時間やデータ容量によっても移行の優先順位と難易度が変わってくるためです。

本来はIT資産台帳などがあるべきですが、そういった物が無い場合はいい機会ですので調査と整理をおすすめします。

例えば、下の表のような観点で情報を取得すると良いでしょう。