クラウド移行に踏み出す前に固めておきたい重要な判断があります。とりわけ大切なのは、移行によって得られるビジネス価値です。他に押さえるべきポイントを解説します。
クラウドや別のクラウドプラットフォームへ移す前に、各workloadの適合性を見極める
パブリッククラウドへの移行はゴールではなく、継続的な取り組みの第一歩にすぎません。一部のworkloadでクラウド移行の主要ステップを習得すれば、その後さらに多くのworkloadを移行したくなるはずです。あるいは、コスト削減や機能性・セキュリティの向上を理由に、別のクラウドへの乗り換えを検討する場面も出てくるでしょう。しかし、何かを動かす前に押さえておくべき重要な問いがあります。
1. 経営層の賛同は得られていますか?
この問いに「はい」と答えられないなら、クラウド移行は失敗します。大半の企業が2024年までにITホスティングの80%をクラウドに割り当てることを目標としている一方で、自社のクラウド移行施策が約束どおりの成果を出せると確信しているC-suiteの経営層はごくわずかです。だからこそ、クラウドを単なるITプロジェクトとしてではなく、企業の将来の成功を支える効率性・イノベーション・成長を推進するプラットフォームとして位置づけ、経営層の賛同を得ることが不可欠なのです。
そして、その賛同を引き出せるかどうかは、移行計画の説得力次第です。何をどこへ移行するのか、そして何より、どのビジネス課題を解決するのかについて、慎重かつ体系的・戦略的なアプローチを示す必要があります。自社の現在の成長段階、規模、そして抱えている課題を踏まえ、移行が生み出す本物のビジネス価値を説得力をもって示しましょう。
2. この移行で事業として何を実現したいのか?
Gartnerの予測によれば、cloud-nativeプラットフォーム上にデプロイされる新規デジタルworkloadの割合は、2021年の30%から2025年には95%超へと拡大する見込みです。workloadを別のクラウドへ移したり、残るオンプレミスのworkloadをクラウドへ移したりする前に、企業はその移行を進める理由を明確にしておく必要があります。
主な動機としては、コスト削減、インフラ負担の軽減、スケーラビリティ、可用性、ユーザー体験の向上などが挙げられます。成長によってオンプレミスのシステムやインフラが限界に近づき、成長に合わせて拡張できる新しい基盤が必要になっているのかもしれません。あるいは、開発者やユーザー向けの手順・プロセスを簡素化し、ITをより効率化して顧客要件への対応を加速させる、グローバル市場の変化に俊敏に応えるためのアジリティを高める、といった狙いもあるでしょう。
クラウド移行は、大規模なイノベーションをスピーディに引き出し、クラウドなしでは何年もかかってしまうような重要なマイルストーンの達成を可能にします。目的が何であれ、ビジネスリーダーは移行の狙いを明確にし、達成に向けた進捗を追跡・測定できる状態にしておく必要があります。
3. このworkloadはクラウド向きか?
多くのフロントエンドアプリケーションは変更頻度が高く、クラウドの柔軟性の恩恵を受けやすいため、パブリッククラウドへのデプロイは理にかなっています。クラウドに最も向いているworkloadは、ライフサイクルが短く、利用量に頻繁なスパイクがあり、迅速なインフラのデプロイを必要とする傾向があります。
しかし、すべての種類のworkloadがクラウドに適しているわけではありません。サブミリ秒のレイテンシが要求されるアプリケーションは、基本的にオンプレミスに残すのが最善です。たとえば金融取引システムを運用している場合、その部分にはクラウドは最適解になりません。製造業もまた時間遅延に極めて敏感な業種で、だからこそ著名な自動車メーカーの一部は、オンプレミスと比べて相対的に高いクラウドのレイテンシを持ち込まずに自社施設内でアプリケーションを構築・実行するために、AWS Outpostsのような仕組みを活用しています。
workloadをオンプレミスに残す方が望ましいケースは、少なくとも短期~中期的にはもう一つあります。オンプレミスのインフラに多額のCapex(資本的支出)を投じており、クラウドのOpex(運用支出)モデルに移る前に、その投資から最大限のリターンを引き出す必要がある場合です。
一方で、一般的な印象とは異なり、コンプライアンスは通常、workloadをオンプレミスに留めておく理由にはなりません。むしろ、可視性の向上やより厳密な統制が可能になる点を踏まえれば、こうしたworkloadの配置先としてクラウドはむしろ優れた選択肢といえます。たとえばEUの一般データ保護規則(GDPR)についても、規制への細やかな配慮とクラウドへの確かな理解があれば、データセンターよりもクラウドへのデプロイの方が高い投資収益率を実現できます。
workloadに最適なデプロイモデルを見極めるには、クラウドパートナーに依頼して徹底的なworkload分析を行うのが有効です。これにより、現在のworkloadの技術的な全体像、課題、依存関係に加え、必要となる労力に対する移行の価値、そして移行の最適な順序が明確になります。
4. なぜそのクラウドを選ぶのか?
多くの組織は複数のクラウドを利用していますが、必ずしも効率的・戦略的に活用できているわけではありません。その一因は、パブリッククラウド導入の多くがシャドーITの結果であり、IT部門の認識や統制を経ずにソフトウェアやデバイス、サービスが購入されていることにあります。
workloadの割り当ても、分析ではなく目先の都合で決まりがちです。各workloadに対してインフラがどのようなパフォーマンスを示しているかを示す正確なデータがなければ、最適なクラウドを選ぶ判断は、根拠ある意思決定というより運任せになってしまいます。
workloadを特定のクラウドへ移す理由を改めて整理しましょう。主要なクラウドプロバイダーはそれぞれに強みがあり、ビジネスのユースケースに適合する領域も異なります。たとえば、サービスの幅広さと深さを評価してAmazon Web Services (AWS)へ移行する顧客は多く、Microsoft既存ユーザーは慣れ親しんだサービスでイノベーションを起こすためにAzureを選ぶことがよくあります。Google Cloudはデータ分析の能力で抜きん出ています。
理論上は同じworkloadを複数のクラウドで動かすことも可能ですが、その場合は最大公約数的な構成に合わせざるを得ません。各クラウドプロバイダーには競合クラウドにはないネイティブサービスがあるため、どのクラウドでもworkloadがシームレスに動作することを期待するのは現実的ではありません。パブリッククラウドの真価であるイノベーションを引き出すには、デプロイ先を選ぶ際に、選んだクラウドの強みを最大限に活かすことが肝心です。
5. どの移行アプローチを採用するか?
これまでのクラウド移行経験や、適切な専門知識へのアクセス状況に応じて、移行アプローチは次の5つのカテゴリのいずれか(またはその組み合わせ)に該当します。rehost(リフト&シフト)、refactor、replatform、rebuild、replace、retireです。
- Rehosting(リホスト)は最もシンプルなアプローチで、既存のデータとアプリケーションを変更を加えずにクラウドのストレージとコンピューティング資源へ再デプロイするだけのものです。必要となるクラウドの専門知識は比較的少なくて済みますが、クラウドの能力を活かしきれず、すべてのworkloadに向くわけでもありません。
- Refactoring(リファクタリング)は、クラウド環境へ移す前にアプリケーションを再設計するため複雑度は高くなりますが、クラウドネイティブな機能や本来備わる柔軟性・弾力性を活かせるため、高い投資収益率が期待できます。
- Replatforming(リプラットフォーム)はリホスティングとリファクタリングの中間にあたり、自動化やスケーリング改善といったクラウドならではのメリットを得るために、workloadに一定の手を加えます。
- Rebuilding(リビルド)は、クラウド環境の機能をフルに活用するためにworkloadをゼロから作り直すアプローチです。高度なスキルとコミットメントが求められます。
- workloadをcloud-nativeアプリケーションに置き換える(Replace)場合、既存のアプリケーションを廃止し、稼働に必要なデータのみを移行します。オンプレミスで使っている同じツールをそのままデプロイ・運用しようとするより、クラウドベンダーが提供するユーティリティを使う方が容易な場合には、賢明な選択となり得ます。
- 役目を終えたworkloadを廃止する(Retire)ことも、移行中の時間とリソースの浪費を防ぐうえで重要です。ただし廃止する前には、上流の依存関係を必ず洗い出しておきましょう。
選ぶ移行アプローチは、クラウドコストからアーキテクチャに関する判断まで、あらゆる場面に影響します。
6. コストはどれくらいかかるのか?
クラウド移行の予算策定では、移行前の計画段階から、移行後にクラウド上でworkloadを運用するフェーズまで、プロセス全体を視野に入れる必要があります。経営層が移行の必要性で一致していたとしても、どのように、どのようなペースで進めるかを判断するには、関連するコストを把握しておかなければなりません。
クラウドの総所有コスト(TCO)は、クラウド上でworkloadを運用する間に発生するさまざまなコストをライフタイム全体で算出するための手法です。クラウドのデプロイ形態は案件ごとに異なりますが、同じアプリケーションをオンプレミスで動かす場合とクラウドで動かす場合のコストを比較することが重要です。アプリケーションの機能は全体として捉える必要があり、特にセキュリティや他のアプリケーションへの依存関係など、コストに大きく影響しうる領域には注意が必要です。クラウドTCOのもう一つの重要な要素は、移行に伴って関わってくる各クラウドプラットフォームについてチームの習熟度を高めるためのスキルギャップ対応コストです。
7. 移行のセキュリティ・コンプライアンスへの影響は?
オンプレミス環境向けに築き上げてきたセキュリティの統制や運用慣行は、クラウドではそのまま通用しません。対応すべき大きな違いの一つが責任共有モデルです。クラウドプロバイダーがインフラのセキュリティの大半に責任を負う一方、利用企業はデータやアプリケーションなど自身が直接管理する設定や構成について責任を持ちます。これは「クラウドそのもの」のセキュリティと「クラウドの中」のセキュリティと表現することもでき、ベンダーがクラウド自体のセキュリティに責任を持ち、利用企業はクラウド内に置いたものを守る役割を担います。
クラウドセキュリティのもう一つの特徴は、クラウドがソフトウェア中心であることに起因し、新しい技術で対応すべき統制やプロセス上の固有要件が生じる点です。ガバナンスのワークフローや組織連携を組み直し、よりアジャイルで継続的なものにする必要があるかもしれません。幅広いステークホルダーや技術領域の担当者を巻き込む準備をしておきましょう。
8. 移行に必要なリソースは確保できているか?
熟練したIT人材の不足が、クラウド関連技術の導入を遅らせています。Gartnerは2021-2023 Emerging Technology Roadmapの中で、IT幹部が新興技術(データベース、機械学習、先進的なストレージや分析など、いずれもクラウドを前提とした技術)導入の最大の障壁として人材不足を挙げていることを明らかにしています。
必要なスキルを揃えたら、次はチームが一枚岩で動ける状態をつくることです。たとえばデータエンジニアがネットワーキングの専門家と切り離されて作業し、各自が自分の担当範囲を終えれば仕事は完了だと考えているようでは、プロセスは破綻します。全員に積極的な関与を促し、「全員が終わるまで誰も終わりではない」という意識を浸透させましょう。クラウドジャーニーの推進を担う統合的なチーム作りで停滞を生まないためにも、上級ステークホルダーの関与と賛同が欠かせない理由はここにあります。さもなければ障害が積み重なり、移行プロジェクトはやがて失速してしまいます。
クラウド移行を社内のスキルだけでは進められない場合、チームを教育・スキルアップさせて担当させるという選択肢もあります。ただし、それには時間がかかるうえ、すでに価値ある仕事に取り組んでいる人材をそこから引き離すことになる点には留意が必要です。移行を導く専門知識と経験を備えたクラウドパートナーと組むことは賢明な一手であり、経験豊富なアーキテクトによる確かな実践的アドバイスを通じて、ジャーニーを加速できる可能性があります。
9. 次の一歩は?
これらの問いを一通り考えてみて、クラウド移行をやり遂げるためのスキルとリソースが本当に自社にあるのかと不安になったかもしれません。しかし、別の道もあります。DoiTのようなクラウドパートナーと組めば、追加コストなしでプロセス全体を伴走してくれる移行のエキスパートを活用できます。
当社はAWSのプレミアパートナーであり、Google Cloudのパートナーでもあります。価値ある最適化・分析・ガバナンス技術に裏打ちされたマルチクラウドの専門知識を提供します。要件定義とビジネス目標の設定、適切なクラウドアーキテクチャの構築、そしてインフラのスケーリングまで、一貫してサポートします。こうした体制があれば、次に出てくる問いは「どこから始めようか?」になるはずです。