アプリケーションモダナイゼーション

「無駄のないモダナイゼーション」アプローチでレガシーアプリを変革

2023年5月26日

Google Cloud Japan Team

※この投稿は米国時間 2023 年 5 月 16 日に、Google Cloud blog に投稿されたものの抄訳です。

企業が顧客、ビジネスパートナー、従業員とのやり取りにおいてデジタルサービスへの依存度を高める中、古いアプリケーションでは現在のビジネスニーズに応えられないため、アプリケーションのモダナイゼーションプロジェクトの優先度が高まっています。

最近の ESG 調査¹では、組織の 86% がパブリッククラウドインフラストラクチャ上で本番環境ワークロードを実行していると回答しており、パブリッククラウドがアプリケーションと基盤インフラストラクチャをモダナイズするための手段とみなされていることが明確に示されています。また、この変革を可能にしているのが仮想マシンからコンテナベースのプラットフォームへの移行であることも明白で、68% の組織が本番環境アプリケーションにコンテナを使用しています。

ただし、アプリケーションをクラウドに移行するだけでは、組織が期待した結果を得られない可能性があります。同じ ESG 調査では、56% の組織がアプリケーションをオンプレミスに戻したと回答しており、29% が「スケーラビリティと弾力性の期待に応えられないため」、34% が「予想外の費用の増加」をその理由に挙げています。

Google Cloud では、お客様と密接に連携して、デベロッパーの生産性を大幅に向上²させながらインフラストラクチャ費用を削減³し、クラウド戦略からより多くのメリットを実現できるように、デジタルサービスの設計と構築を支援してきました。

今回のブログ投稿では、「無駄のないモダナイゼーション」の概念について説明します。このアプローチは、レガシーアプリケーションを完全にモダナイズしようとするのではなく、最新のソフトウェアエンジニアリングの原則とクラウドネイティブテクノロジーを使用して、特定のユースケースに合わせた新しいデジタルサービスを構築することに焦点を当てています。「無駄のないモダナイゼーション」はストラングラーパターンを補完し、DORA の指標を活用してデベロッパーの生産性を向上させ、確実に成功を導きます。

変革が必要な事例

1 つのモダナイゼーションアプローチが、すべてのアプリケーションに適合するわけではないことを、前もって知っておく必要があります。資産を評価し、各アプリケーションのタイプに応じた正しい戦略を見極めることが最善の方法です。しかし、ビジネスにとって重要度が増しているアプリケーションの場合、再構築を考えるのは無理があります。また、クラウドが提供する機能を十分に活用できるよう設計されていない可能性が高いため、クラウドに移行するだけでは済みません。

ユースケースとして思い浮かぶのは、リアルタイム決済です。銀行は、決済のバッチ処理からリアルタイムソリューションの提供への移行に取り組むにあたり、アーキテクチャを大幅に変更する必要があります。しかし、相互に依存するバッチジョブのネットワークを解読し、最新かつイベントドリブンのサーバーレスアーキテクチャで、変更を迅速かつ安全に反映できるように再構築するというのは、簡単なことではありません。

このようなユースケースをはじめとした多くのユースケースで、技術的なアーキテクチャだけでなく、エンジニアリングのプロセスや文化にも大きな変化が求められるでしょう。

無駄のないモダナイゼーション

Google Cloud では、最新のソフトウェアエンジニアリングと、優れたソフトウェア / ハードウェアを作り上げる方法を継続的に改善するプロセスに情熱を注いでいます。DORA の調査と結果から、たとえば、ソフトウェアエンジニアリングのプロセスにおいてセキュリティを移行することが成功には不可欠であり、最新のソフトウェアエンジニアリングの原則を習得した企業はビジネス目標を達成する可能性が 2.5 倍高いことがわかりました⁴。

このような知見が、古いアプリケーションのモダナイゼーションにどのように役立つかを考慮すれば、無駄のないモダナイゼーションのアプローチを採用するきっかけとなります。基本的な考え方はシンプルです。

すべての新規ビジネス要件で、市場投入までの時間を短縮する必要がある場合には、サービス提供を遅らせたり、修正を待ったりするのではなく、「新しく構築する」アプローチを適用します。こうすることで、技術的負担が増す古い方法論やテクノロジーの採用を回避できます。
必要な関係者の各グループから選んだ、遂行可能な最小限の人数のメンバーで小規模なチームを構成します。なお、チームの全員が同じ考え方を持っている必要があります（たとえば、「この新機能を迅速に提供することは可能である。では、それはどのように行えばいいか？」など）。これらのチームが新しいプロセスと機能を自由に操作できるようにすることで、ビジネス要件や規制要件により迅速に対応できる優れたソフトウェアを提供します。そして、このような無駄のないチームから学び、その結果を次のプロジェクトのエンタープライズアーキテクチャに統合します。

事業を展開している業界や環境によっても異なりますが、このアプローチの潜在的なメリットには次のようなものが挙げられます。

新機能の市場投入までの時間を短縮できる
マネージドテクノロジーまたはサーバーレステクノロジーを活用することで、温室効果ガス排出量と費用を削減できる
レガシーのシステムやプロセスという負担を抱えていない企業による混乱を回避できる
新しい要件や規制に継続的に適応できるようエンジニアリングプロセスを改善できる
時間の経過とともに技術的負担を減らすことができる
常に最新の実践とテクノロジーを使用しているため、エンジニア人材の獲得を容易にすることができる
最新のクラウドベースメッセージングアーキテクチャとサーバーレス機能の開発により、レガシーシステムと容易に相互作用できる新しいサービスを実現し、両方の共存を可能にすることができる

もちろん、これらのメリットにより、詳細な検討が必要になる分野もいくつか出てきます。

規制要件のため、やむを得ず「古い」やり方を続けているように見える場合もありますが、それが徐々にレガシーソフトウェアと技術的負担を生み出す原因となります。そのため、最適なユースケースを事前に検討することが重要です。デフォルトで「できる」アプローチを採用すると、限界を押し広げる助けとなります。
ソフトウェアエンジニアリングと配信のアウトソーシングは、費用を管理し、既存の調達プロセスや運用プロセスに適合させるための優れた方法であることに変わりはありません。しかし、ソフトウェアエンジニアリングを強化する際、これらの関係はどのように考えればよいでしょうか。Google パートナーの多くは、優れたソフトウェアエンジニアリングの専門知識を持っています。そのため、すべてをアウトソーシングするのではなく、展望のある最小限の組織に Google パートナーを迎える方が将来的に良いかもしれません。
新しいデジタル機能を検討する際には、構築するか購入するかの決定が常に付きまといます。ソフトウェアエンジニアリングのスキルが向上するにつれ、構築によって特定のユースケースに対してより柔軟で機敏な対応ができるようになるため、この点について再検討する契機になると思われます。