メインフレームのモダナイゼーションでは何が起こるのか、Googleがアンチパターンを解説：リフト＆シフトは万能ではない

Googleは公式ブログで、メインフレームのワークロードを移行する際に考慮すべき一般的な落とし穴やアンチパターンを解説した。「ビッグバンアプローチ」「リフト＆シフト」「インプレースモダナイゼーション」のそれぞれに落とし穴がある。

[＠IT]

　Googleは2021年2月25日（米国時間）に公式ブログで、メインフレームワークロードの移行時に考慮すべき一般的な落とし穴やアンチパターンを解説した。つまり、移行に失敗する際によくある間違った解決策を紹介している。

　Googleは、「メインフレームワークロードの移行やモダナイズは、理想的な条件下でも複雑で困難だ。今回挙げたアンチパターンを回避すれば、こうした変革が成功する可能性が高まる」と述べている。

　このアンチパターンはメインフレームワークロードを「Google Cloud」やオンプレミス仮想マシン、他のクラウドプロバイダーのいずれに移行する場合も有効だという。

　メインフレームワークロードの移行時に選択できる手法は3つある。「ビッグバンアプローチによるコード書き換え」「リフト＆シフトによる移行」「インプレースモダナイゼーション」だ。それぞれのアンチパターンとはどのようなものなのだろうか。

（1）ビッグバンアプローチによるコード書き換えはコスト高で危険

　ビッグバンアプローチによるコード書き換えとは、レガシーなメインフレームのコードを、モダンな設計パターンとモダンな言語を用いて手動で書き換え、リアーキテクトすることだ。

　例えば、レガシーなCOBOLプログラムの集合体からビジネスロジックを複製して、新しいJavaアプリケーションを開発するといった手法だ。新しいプログラミング言語と新しいドキュメントを使って作成された、新しいプラットフォームに対応した新しいコードベースが、開発チームに求められる成果だ。

　ビッグバンアプローチは今回取り上げた3つの手法の中で、最も大規模な資本と時間の投入が必要になる。リエンジニアリングを行い、ビジネスロジックを改善したいという誘惑に抵抗できず、この道を選んでしまう組織が多い。

リエンジニアリングの難しさ

　モダンな技術や設計パターン、最新のベストプラクティスを使ってシステムのリエンジニアリングを行えば、将来にわたってイノベーションを行うことが可能になる。組織が蓄積してきた知識も継承される。

　このシナリオは魅力的であり、IT意思決定者から承認を取り付けやすい。このアプローチは合理的に思えるものの、開発チームが当初は認識しない、隠れた落とし穴やリスクがある。予算超過や予想外の複雑さ、スタッフの入れ替わりのようなリスクにより、大規模な書き換えが難航し、メリットがなかなか得られない恐れがある。

　ビッグバンアプローチによるコード書き換えは、ステークホルダーに提示された最良のケースのシナリオ通りに進むことはめったにない。多くの場合、失敗してしまう。

コストが膨らみ、破綻する恐れ

　プロトタイプを素早く開発し、元々のコードと同じように機能させることは難しい。だが、ほとんどの開発チームは問題を過小評価してしまう。さらにこの取り組みはすぐには終わらず、必ずといっていいほど長期化する。

　ビッグバンアプローチによるコード書き換えでは、「新しいコードを以前のコードと全く同じように機能させる」か、「新しいコードに以前のコードとは異なるビジネスロジックを実装し、リエンジニアリングを行う」という2つの選択肢がある。

　最初の選択肢を取り、新システムで以前の機能を忠実に再現しようとすると、常に作業時間が想定よりもかさんでしまう。古いコードを理解して元々の仕様通りの動作を実現するには、多大なエンジニアリングの労力を要するからだ。

　後者の選択肢を取り、新しいコードでビジネスロジックを変更すると、以前のビジネスロジックに依存していたビジネスプロセスや下流システムに変更を加える必要が生じる。しかも、そうして変更を加えると連鎖反応が起き、下流システムでますます変更が必要になり、リスクが増大するとともに、書き換え作業が長引く恐れがある。

　本番運用している現行のメインフレームシステムに対して、コードの書き換え中も継続的に保守や更新を行う必要がある場合は、問題がさらに複雑化する。開発中の新システムと現行システムの間で、新機能の調整が必要になり、しかもその作業は、コードを書き換える過程で多発するからだ。それに伴ってプロジェクトは長期化し、失敗する可能性が高まってしまう。

　メインフレームソフトウェアをモダナイズする方法を比較した結果として、Googleは「ビッグバンアプローチによるコード書き換えは、最も高コストだ」と述べている。リスクや予想外のコスト、遅延を考慮すると、ROI（投資対効果）に対して納得感がかなり低くなるかもしれない。

（2）リフト＆シフトによる移行は安全だがメリットは少ない

　リフト＆シフトによる移行は、アプリケーションをあるシステムから別のシステムに、最小限の変更とダウンタイムで移行する確立された方法だ。コモディティハードウェアで動作する仮想マシンを、パブリッククラウド上の仮想マシンに移行するために広く使われている。メインフレームの移行でも同様のアプローチが可能だ。

　メインフレームプラットフォームは、プロプライエタリなハードウェアをベースにしているため、x86ベースのマシンでメインフレーム環境をエミュレートする必要がある。仮想マシンを介して、アプリケーションをメインフレームからクラウドに直接移行するためだ。エミュレートされた環境でアプリケーションを動かすには、エミュレーションベンダーから提供されるコンパイラを使って、アプリケーションを再コンパイルする。

クラウドへ迅速に移行

　リフト＆シフトによる移行は、オンプレミス環境からクラウドに最も迅速に移行する方法とみられることが多い。この捉え方はメインフレームワークロードにも当てはまる。

　メインフレームハードウェアを更新する場合は、莫大（ばくだい）な資金が必要になり、更新に伴って会社の貸借対照表の債務やリース債務が増加することが多い。だが、メインフレームからパブリッククラウドに移行すれば、メインフレームワークロードのスケールアップやスケールダウンにより、リソース使用や運用コストを最適化できる。他の選択肢と比べて、リフト＆シフトによる移行では、ROI（投資対効果）を最も早く実現でき、リスクを最小に抑えることができる。

リスクが小さいものの、メリットも小さい

　リフト＆シフトによる移行では、他のアプローチと比べてビジネスリスクが小さく見える。だが得られる可能性があるメリットも小さい。

　まず、メインフレームからクラウドに移行することによるメリットは結局得られない。なぜならメインフレームエコシステムに引き続きロックインされ、新たにエミュレーションレイヤーに依存することになるからだ。

　さらに、メインフレームソフトウェアを変更しないため、多くの重要な問題を放置することになる。例えば、メインフレームに精通した人材の希少化、停滞したエコシステム、アジリティの欠如、イノベーションが望めないといった問題だ。

　クラウドインフラコストと継続的に発生するエミュレーションソフトウェアのライセンス料を合計すると、確かにメインフレームハードウェアを更新する場合よりも費用は抑えられる。だが、節約効果はリフト＆シフト計画への投資に対して割に合わない。リフト＆シフトによる移行では、移行に伴う固有のリスクに対応できたとしても、得られるメリットはごくわずかなものだ。

（3）インプレースモダナイゼーションはビッグバンアプローチよりも手堅い

　インプレースモダナイゼーションでは、メインフレームを維持しながら、ソフトウェアの品質や保守性、テスタビリティの向上を図る。このアプローチを取る理由は、メインフレームを将来にわたって有効と位置付けており、アプリケーションソフトウェアを相応にモダナイズする必要性を認識していることだ。

　メインフレームで動作するモダン言語を使ってアプリケーションソフトウェアを書き換えたり、リアーキテクトしたりできる。Kubernetesのような技術を導入し、部分的にクラウドのようなエクスペリエンスを実現することもできる。

プラットフォームの移行リスクを回避

　メインフレームソフトウェアには、保守性やイノベーション、アジリティ、拡張性に関連する問題がある。だが、リアーキテクトやリエンジニアリングによって、モダンな標準や設計パターンに適合させることができれば、大規模なリプレースの落とし穴の多くを回避できる。メインフレームからの移行は大きなリスクであり、それを回避すれば、プロジェクトが成功する可能性が高まる。このため、インプレースモダナイゼーションは、メインフレームモダナイゼーションのアプローチの中で、最もリスクが低く見える。移行の要素がないため、ダウンタイムのリスクもない。

　モダンな方法論によるメインフレーム開発の支援ツールを提供するベンダーのエコシステムもある。インプレースモダナイゼーションは、リフト＆シフトによる移行や、コード変換よりも長期間かかる場合が多いものの、モダナイズを徐々に進めることで、新しい開発プロセスをチームが学ぶのに必要な時間が得られる。

メインフレームの問題点を温存

　メインフレームソフトウェアの手動アップデートを伴うインプレースモダナイゼーションは、ビッグバンアプローチによるコード書き換えと同じ問題を多く抱える。予算とスケジュールが超過しがちである他、パフォーマンスと正確性の問題も生じる。新しい言語によるビジネスロジックの書き換えは、大規模なテストを必要とするからだ。

　インプレースモダナイゼーションの最大の問題は、理想的な成果を得たとしても、元々ある問題の多くがそのまま残ってしまうことだ。メインフレームに精通した人材プールは年々縮小しており、メインフレームソフトウェアプラットフォームは孤立し、ベンダーエコシステムもしぼんできている。