AWS導入が進まないのは企業文化のせい!?移行に失敗しない方法とは

　AWSは、マイクロソフトのAzure、GoogleのGoogle Cloud（旧Google Cloud Platform）と並び、世界で最も多く利用されているクラウドインフラのひとつです。AWSでは200以上のサービスを提供しており、その内容はインフラストラクチャや仮想サーバーの構築、データ分析、アプリケーション開発、生成AIなど、多岐にわたります。

　AWSに移行するメリットとしてはさまざまなものがありますが、わかりやすい効果としては「コスト削減」があります。

　AWSをはじめとするクラウドは、オンプレミスのようにハードウェア・ソフトウェアを自社で購入する必要がありません。システムの管理もクラウド事業者側が行うため、TCO（※1）を削減することも期待できます。さらに、システムは災害対策が施されたデータセンターで管理されているため、BCP（※2）の観点でも有効です。

※1：TCO…システム導入時から、導入後の管理・維持・廃棄にいたるまでのすべてのコストの総額のこと。Total Cost of Ownershipの略。

※2：BCP…災害など緊急事態の発生時に、その損害を最小限に抑え、事業の継続・復旧を図るための計画のこと。Business Continuity Planの略。

　クラウドにはこのようなメリットがある一方で、「クラウドはセキュリティが不安」と、移行をためらう人も多いかもしれません。クラウドの移行後は、自社のデータを社外で管理するため、これまでオンプレミスで管理してきた企業が、移行に不安を覚えるのは当然といえます。

　AWSではセキュリティの責任について、AWSとユーザー企業の双方が負う「責任共有モデル」（Shared Responsibility Model）という考えを提唱しています。責任共有モデルとは、AWS側がデータセンターの管理などのクラウド全体の物理的なセキュリティを守り、AWSを使うユーザー企業側はアプリケーションやアクセス権限の管理といった各種設定を管理するというものです。

　例えるなら、家のセキュリティシステムはAWSが責任を持ち、鍵の開け閉めや管理はユーザー企業側が責任を持つといったイメージで、AWSとユーザー企業の間で、セキュリティに関する責任を分担するのが責任共有モデルです。

　ユーザー企業が責任共有モデルで求められるセキュリティ基準をクリアするのは大変そうに見えますが、AWSにはID管理やデータ保護、脅威の検出、インシデント対応など、ユーザー企業の責任をサポートするサービスも存在しています。これらのサービスを活用すれば、従来のオンプレミスよりも高いレベルでのセキュリティガバナンスも可能です。

AWSのセキュリティの責任共有モデル（AWSのサイトより引用）

　クラウドへの移行に失敗しないためのポイントとしては、ITの要素よりも、“非IT”の要素もあるようです。

　AWSが公開している「クラウド移行戦略立案の推進とポイント」という資料によると、クラウド移行で発生する課題の割合は、開発や運用、セキュリティ対策のような「テクニカル」（専門技術）な課題よりも、ユーザー企業が持つIT戦略や企業文化、ビジネス計画などの「ノンテクニカル」（非専門技術）な課題のほうが多く、その比率は「3：7」といいます。

クラウド移行で発生する課題の割合は、ノンテック分野の方が多いという
（AWS「クラウド移行戦略立案の推進とポイント」資料より引用）

　クラウド移行で発生する課題の割合は、ノンテック分野の方が多いという （AWS「クラウド移行戦略立案の推進とポイント」資料より引用）

　テクニカルな部分の課題については、他社の事例を参考にすることもでき、AWSのパートナー企業やITベンダーを活用することで課題解決支援を受けることが可能です。一方でノンテクニカルな部分については、企業ごとに課題が異なるため、企業が主体となって解決する必要があります。

　ノンテクニカルな部分で起きがちな失敗のひとつに、完璧な形を目指すために検討に時間をかけすぎたり、単純な一定の結果だけを見て、成功か失敗かを判断したりすることがあります。

　こうした失敗をしないためには、単純なクラウド移行完了をゴールとするのではなく、ITシステム全体のサービスやライフサイクルに合わせた継続的な改善を行うという意識が求められます。たとえ失敗したとしても、その経験と学びを活かして次の取り組みにつなげていくことが重要です。目的・ゴールを設定し、そこから逆算する「バックキャスト」の戦略が求められるといえるでしょう。

　AWSでは、企業がAWSへの移行を考えるに当たっては、以下の「7つのR」の選択肢を検討すべきとしています（AWS「移行戦略 (7R) の概要(AWS 移行準備シリーズ)」資料より引用）。

【1】リロケート（Re-locate：移転）
オンプレミスの仕組みをほとんど変更せずに、AWS上に移行する方法です。クラウド移行を迅速に進めたい場合に有効です。

【2】リホスト（Re-host：移行）
オンプレミスのアプリケーションをほぼそのままクラウドに移行する方法です。最小限の変更で移行でき、スピードが求められる場合に適しています。

【3】リプラットフォーム（Re-platform：最適化）
オンプレミスの設定に一部の変更を加えて、クラウド環境に最適化する方法です。例えば、データベースのみをAWSのサービスに置き換えるなど、改善をしつつ移行します。

【4】リファクタリング（Refactoring：再設計）
オンプレミスのアプリケーションを根本的に設計し直して、クラウドに最適化する方法です。手間とコスト負担は大きくなります。

【5】リパーチェス（Re-purchase：再購入）
アプリケーションを新しいものに置き換える方法です。既存のシステムを廃止し、新しいものに切り替えます。

【6】リテイン（Retain：維持）
「移行しない」という選択肢のひとつで、要は現状維持です。まだクラウドへの移行が必要ない、または移行のメリットが低いシステムを、オンプレミスのままにしておくことを指します。

【7】リタイヤ（Retire：廃止）
リテイン同様に「移行しない」という選択肢で、現在使われていない、または必要なくなったシステムやアプリケーションを廃止する方法です。これにより、管理コストが削減できます。

　これら7つのRを全て選択肢に入れ、当初掲げた目的に対し、最適な選択はどれか考えながら意思決定をしていくことが、クラウド移行の重要なポイントです。

企業がAWSへの移行を考えるに当たって検討すべき「7つのR」
（クラウド移行AWS「移行戦略 (7R) の概要(AWS 移行準備シリーズ)」資料より引用）

　実際にオンプレミス環境からクラウドへ移行するにあたっては、【評価】→【準備】→【移行】→【運用】という、4つのステップに沿って進めるのが理想的といいます。

　最初の【評価】フェーズでは、実際にクラウドへ移行するかどうかを決めて動き出す前に、その計画の妥当性を評価します。この評価は、大きく分けると「コスト（経済的合理性）」、「実現性」、「難易度」の3つの観点があります。

　たとえばコスト面では、TCOの観点から検討します。ハードウェアの費用をAWSの利用料に置き換えれば、ソフトウェアのライセンス形態も変化する可能性があります。オンプレミスからクラウドへ移行すれば、機器や設備を維持するための電気代や冷暖房費、運用にかかる人件費も削減されるでしょう。

　次の【準備】のフェーズでは、実際の移行作業をする前に、必要な計画を策定したり、必要な整備を行います。前述の「7つのR」に基づいて、あるものはリホストする、あるものはリパーチェスを選ぶといった意思決定を行い、場合によっては技術検証を行うことで、移行に伴うリスクをあらかじめ最小化しておきます。

　【移行】は、実際に移行を行うフェーズです。事前に策定した計画や設計に基づいてクラウド上に環境を構築し、サーバーやデータベース、ストレージといった各コンポーネントを移行していきます。移行の際には、AWSが運用や管理を代行するマネージドサービスや、サードパーティー製の移行ツールを使用するなども検討します。

　移行の際には、“当初の計画や設計の変更を恐れない”ことが重要です。オンプレミスでは、ハードウェアやソフトウェアを既に購入した場合、計画の変更は難しいですが、クラウドであれば、スペックの不足や過剰に対して柔軟に変更ができるため、たとえ計画から変更があったとしても、その悪影響は小さく抑えられます。

　最後の【運用】は、AWSへ移行後のフェーズです。自社のビジネスの変化や、クラウドサービスの変化などに応じて、各種設定を柔軟に変化させながら、継続的に改善を図っていきます。

　ここまで挙げたように、オンプレミスのシステムをクラウドへ移行するためには、事前の準備や計画、導入後の運用など、さまざまな要素が求められます。中には「面倒くさいから外部のベンダーに全て丸投げしよう」と考える企業もあるかもしれませんが、それでは失敗する可能性が高いかもしれません。

　本文で触れたように、クラウド移行に失敗する要因としては、テクニカルな要素よりも、ノンテクニカルな要素の方が大きい傾向にあります。クラウド移行における意思決定や、クラウドを利用した事業価値の創出は、ユーザー企業にしかできません。

　テクニカルな部分は外部ベンダーのサポートに頼るとしても、クラウドをどのように使い、どのようにビジネスに活用していくかは、企業自身が決定するものです。企業がクラウドにコミットするかしないかは、移行の成否を大きく分ける要素といえるでしょう。

　加えて、導入後の運用についても、クラウドで成果を出すためのポイントといえそうです。

　クラウドでは、たとえ計画時にサーバーのスペックなどを過大または過小に見積もっていたとしても、実際に稼働した状況に合わせて柔軟に伸縮することができます。ビジネスの変化に合わせて少しずつシステムを改修していくことで、最適なIT活用が柔軟にできますが、逆に初期設定を見直さず、ずっと同じステータスのままで運用すると、逆にオンプレミスよりも負担が増えるケースも考えられます。

　クラウドは設定の変更が柔軟にできるため、変化が激しい現代のビジネスシーンに“強い”システムといえます。まだ自社にオンプレミス環境が残っている企業は、本記事で取り上げた要素に留意しながらクラウドを導入していくことで、少なくともクラウド移行に失敗することが防止できるはずです。クラウドの運用を続けていくうちに、DXによるビジネスの変革に成功する日が訪れることでしょう。