リプラットフォームでクラウド移行を実現し、勝ち抜く組織へ

経営のスピード化やコロナ禍、自然災害を踏まえたBCP導入、ハイブリッドワークといった働き方改革などが契機となり、日本企業のクラウドシフト、クラウドリフト、もしくはリフトアンドシフトは着々と進んでいます。デジタル庁が主導する、地方公共団体の基幹業務システムの統一・標準化に向けたガバメントクラウドの取り組みも含め、これからの時代は、十分なセキュリティやコンプライアンスに配慮した上でのクラウド活用が主流になっていくことは間違いないでしょう。

「情報通信白書 令和5年版」にあるIDCの予測によると、パブリッククラウドサービス市場は年々右肩上がりとなっており、2026年の市場規模は4兆2795億円と見込まれています。これは2021年と比較すると約2.6倍の市場規模となっています。

このような予測がある一方で、ガートナージャパン（Gartner Japan）では日本におけるクラウド活用に対して懸念を示しています。「2026年時点で『2025年の崖』を越えられず、レガシーシステムを2030年まで使い続ける日本企業が90％以上存在する」と予測しています。ちなみに「2025年の崖」とは、経済産業省がDXレポートで発表したもので、日本企業のDXが進まずに老朽化したシステムを使い続けることで、2025年を目途に経済的な損失が発生するというものです。

この崖を越えられない理由として、ガートナージャパンではサーバーなどの
ITインフラのクラウド移行が諸外国に比べて遅れており、デジタル前提のビジネスを推進するカギとされるクラウドネイティブ・アプリケーションの利用・開発が進んでいないことを挙げています。

同じく、ガートナージャパンの2023年4月の調査によると日本のクラウドの平均導入率は21％で、このペースでは2030年でも35％程度にとどまり、世界のデジタル産業革命から日本は置き去りになると予測しています。さらに同調査でIaaSの導入率は24％であるものの、クラウドにリフトした後、クラウドネイティブにマイグレーションしたケースは少ないと指摘しており、クラウドにリフトするだけではレガシーシステムに過ぎず、崖を越えたとは言えないと論じています。

その要因として、以下の6つの可能性を挙げています。

1. 「クラウドはまだ早い」という認識のユーザーが30％存在する可能性
2. 「2025年の崖」を越えられなかったユーザーが「レガシーをさらに2030年まで継続」する可能性
3. 「オンプレ対クラウドの議論を継続」するユーザーが40％存在する可能性
4. 「ベンダーへの丸投げ状態」から脱却できないユーザーが30％存在する可能性
5. 「クラウド化しても、コストが下がらない」というユーザーが40％存在する可能性
6. SIや仮想ホスティングとクラウドの違いがわからないユーザーが30％存在する可能性

これらはすべて、クラウドを活用するユーザーの認識の甘さや、技術的なリテラシーの低さに起因するものとなっています。このような問題を解決するために、まず始めるべきは、ユーザーがクラウドの定義を正しく理解して、時代の流れとクラウドネイティブに即したITの導入・運用スタイルにシフトすることにあります。自社主導でクラウド活用を進めるのであれば、「正しく運転するドライバーとしてのスキル」が、あるいはクラウド活用を外部に委託するのであれば、目的地を的確に伝えて「正しく運転してもらうためのナビゲーターのスキル」が必要になると言えるでしょう。

その際に、押さえておきたいキーワードが「リプラットフォーム」です。

そもそもリプラットフォームとは、AWS（Amazon Web Services）が提唱するクラウド移行戦略パターンの1つです。クラウド移行を成功させるためには、システム担当者が最低限必要な知識をインプットした上で、議論を重ねてプロジェクトチームで意識を共有し、最適な移行の戦略を練る必要があります。AWSでは、オンプレミスのシステムをクラウドに移行する際に7種類の移行戦略パターン、言い換えるならばクラウド移行のベストプラクティスを示しています。

不要と判断したアプリケーション・データベースを廃止、削除すること。システムのランニングコストや運用管理にかかる稼働、人件費などを抑えられるメリットがあります。

業務上、移行する理由がない、あるいは移行コストがかかるなどの理由からシステムを従来のオンプレミス環境で稼働させ続けること。あえてクラウドにマイグレーションしない選択肢です。

オンプレミスで稼働するVMwareなどの仮想環境を、AWSにマイグレーションすること。VMware Cloud on AWSでは、既存システムに手を加えることなくオンプレミスの仮想マシンをそのまま動かせます。

既存のアプリケーションやデータベースに手を加えずAWSにマイグレーションすること。オンプレミスのソースコードを変更しなくても問題なくクラウド上で稼働する場合に、採用すべきパターンです。

アプリケーションやデータベースを既存製品から完全に別製品に切り替えること。既存システムが老朽化していたり、複雑過ぎていたりする場合に活用を諦め、パフォーマンス向上を目的として新規でAWSに乗り換えるパターンです。

アプリケーションやデータベースを部分的に最適化してマイグレーションすること。セキュリティとコンプライアンスを損なわず、レガシーシステムを稼働させ続けることが可能です。リフトティンカーアンドシフト（Lift Tinker and Shift）、リフトアンドリシェイプ（Lift and Reshapeとも呼ばれることもあります。

アプリケーションやデータベース改修でクラウドネイティブ化を図ること。リプラットフォームよりも大きな変更を加えた上でマイグレーションします。リアーキテクト（Rearchitect）とも呼ばれます。

システムの状況などによって、これら7種類を使い分けることをAWSは推奨しており、すべて「R」から始まるため、「7つのR（7Rs）」と呼ばれています。もともとは2011年にGartnerが「5つのR」として定義したものを、AWSが2016年ごろから「6つのR」として独自に展開し、その後「7つのR」に至ります。

なかでも導入例（ユースケース）が多いのは、既存のアプリケーション・データベースに少し手を加えた後に移行するリプラットフォームです。一部のシステムのみの修正で対応でき、アーキテクチャを変更する必要がないため、「短期間でのクラウド移行やコスト削減ができる」、そのまま移行する場合に比べクラウドネイティブに対応しやすいため、「最小限の稼働でクラウドに合わせられる」、大規模な修正は行わないため、システムを使うユーザーへの負担が押さえられ、「外部から見た際の挙動は変わらない」というメリットの多さが人気の理由です。

一方で移行時に予期しない不具合が発生するかもしれないことから、「改良した結果、他のシステムに影響を及ぼすリスクがある」、潜在的な改良箇所がどんどん明るみに出てきてしまい、「予想以上に改良に要する稼働が大きくなることがある」、老朽化したシステムには手がかかることが多いため、「レガシーシステムに適していない」といったデメリットがあることも把握しておくべきでしょう。

これは余談ですが、ITILにも「変更」を実施する際に考慮したほうが良い項目を「変更管理7つのR」としてまとめています。それは、「RAISED：変更の要請者は？」、「REASON：変更する理由は？」、「RETURN：変更により得られるものは？」、「RISK：変更による危険性・不確実性は？」、「RESOURCE：変更に必要なリソースは？」、「RESPONSIBLE：変更の責任者は？」、「RELATIONSHIP：ほかの変更との関係は？」というものです。

リプラットフォーム化を進めるには、4つの手順を踏む必要があります。これらを実践すれば、先に挙げたデメリットをリカバーすることが可能です。以下、順番に解説していきます。

まず、重要になるのは「現行のシステム状況の洗い出し」です。現在稼働中のシステムの状況を詳しく調査して重要度を明確にすることで、移行するシステムの優先順位が把握しやすくなります。ときには重要度が低いシステムであっても、移行にかかる稼働やコストが低い場合には優先した方がいいケースもありますので、状況に応じて議論を重ね、ロードマップを作成しましょう。

続いて「KPIの設定」です。KPIとは重要業績評価指標のことで、目標を達成する過程で達成度を測る中間的な指標のことです。クラウド移行が順調に進んでいるかどうかの判断基準を事前につくっておくことで、システム改良や移行の方針がチーム内で統一しやすくなります。ちなみに、平均応答時間や最大応答時間、合計タイムアップ、エラー率などをKPIに設定することが多いようです。

KPIの設定が終えたら、「システムの変更箇所の検討」を行います。既存システムの機能がきちんとクラウド上でも問題なく動くのかを確認し、そのまま移行できない場合には、修正箇所として追加する必要があります。可能であれば、クラウド移行を検討する初期段階で変更箇所を洗い出すべきです。修正すべき箇所が多すぎる場合、リプラットフォームとは別の方法を検討すべきでしょう。

そして、最後が「運用体制の検討」です。クラウドへの移行を完了して終わりではなく、移行後に安定して運用管理を回せるようになってこその成功であり、ゴールと言えるでしょう。言うまでもなく、オンプレミスとクラウドでは運用スタイルが大きく変わります。クラウド上で稼働するシステムは自ら運用する必要があるため、対応マニュアルの準備など移行後の運用体制を確立しておきましょう。

リプラットフォームはシステムの部分的な最適化を行うものですが、オンプレミスからクラウドへの移行は大規模な変革となるため、見通しを持って計画を進めましょう。あくまで既存システムを最大限に活用する考えに立ち、新たな技術やビジネスモデルを融合させながら実現に向けて進めることが重要です。

リプラットフォームなどマルチクラウド・ハイブリッドクラウドの移行・導入には、複合した課題の解決が求められます。これからは自社でクラウドを「正しく運転するドライバーとしてのスキル」、あるいは目的地を的確に伝えて「正しく運転してもらうためのナビゲーターのスキル」が必要になると冒頭で説明しました。しかし、たとえ自社でクラウドを「正しく運転するドライバーとしてのスキル」を身につけたとしても、最短の経路や渋滞を避ける道案内をしてくれる伴走者の選定は必要になります。

このようなクラウド移行の課題を抱える企業の伴走者としておすすめなのが、NTT Comのクラウドマネージドソリューション「X Managed（クロスマネージド）」です。幅広いICTの知見や豊富な経験を持つプロフェッショナルが、クラウド化に向けたグランドデザインの策定から、クラウド移行・導入のサポート、監視による安定運用までをワンストップで提供します。AWS、Azureなどの各種ライセンスの再販サービス、従来のオンプレミスシステムからクラウドマイグレーションに伴う環境の構築、運用代行をメニュー化し、クラウド導入後の環境の一元監視、運用で、安全・安心なIT環境が利用可能です。

AWSへのリプラットフォームを推進するならば、「AWS導入支援・運用サービス」がおすすめです。リプラットフォームによるAWS導入をネットワーク構築から保守運用までワンストップで完結できます。クラウド化における成功のカギとは何か、その最適解を見つけ出し、成功体験までのプロセスを楽しく、わかりやすく理解できる解説マンガもありますので、合わせてご覧ください。

AWSパートナーネットワークに参加するNTT Comなら、AWSのリプラットフォームをトータルに支援できます。2025年の崖が間近に迫っていますが、いまならまだ間に合います。崖を乗り越え、強靭かつ柔軟なクラウドネイティブな組織に生まれ変わる好機です。これを機に導入を検討してみてはいかがでしょうか。