前回の記事において、基幹システムを稼働させているユーザーは、ベテラン技術者が在職の内に課題解決をする必要があり、コロナ禍とは言え先送りできない課題となっていることをお伝えした。しかし、大きなシステム開発、改修のプロジェクト予算を取ることが難しい時世において、ビフォアコロナ時代よりもさらに用心してモダナイゼーションを進める必要があり、失敗は許されない。
今回は、過去に起きたモダナイゼーションの問題を分析し、同じ轍を踏まないために課題を整理していく。
別プラットフォームへのリプレースでかえってコスト増大
「IBM i」以外の別プラットフォームにモダナイゼーションの何らかの手法でアプリケーションをリプレースした結果、IBM iの時より大きなハードウェアやソフトウェアの構成になることが発生している。それらの運用、管理工数も拡大することになり、今まで考えなくてよかったコストが新たにのしかかることになる。
原因としては、IBM iが通常、データベースなどのミドルウェア、運用及び管理システム、セキュリティシステムなどを別々に購入した場合、サーバーに分散配置するような基盤ソフトウェアをOSに内包していることにある。ハードウェア上で最適化されて効率よく安全に稼働しているため、同等のシステムレベルをリプレース先のプラットフォームで実現するとなるとIBM iより大がかりなシステムの準備が必要となる。稼働アプリケーションが矮小な場合を除き、メインフレームなどの大型コンピューターのリプレース時においてのメリットとなるダウンサイジングが期待できないことを示している。
ツールでコンバージョンしたものの…
RPGなどのIBM i上のプログラムを人手でJavaなどにリライトするより、効率的でコスト的にも廉価な方法としてツールを用いたコンバージョンが挙げられるが、提供ベンダーのツール、付帯サービスなどに課題があることがある。うまくコンバージョンできずに頓挫したり、コンバージョン成功後に発生したりする場合もある。
多くのコンバージョンツールには独自のフレームワークがあり、RPG言語をJavaなどのクラス、メソッドに体系化させて置き換えている。結果としてRPGの言語体系で書かれたJava表記のソースとなってしまい、JavaエンジニアがRPGの言語体系を理解しないとソースが変更できなくなってしまう。
RPGとJavaの間に、独自の中間言語を置いて変換するツールもあるが、中間言語を覚えなければメンテナンスや新規作成ができない。変更の無い塩漬けのシステムには非常に有効な手段であるが、コンバージョン後にソースを改変したいユーザーにとっては逆に塩漬けになってしまう問題が生じることを意味している。コンバージョン完了後にそのことに気付き、IBM iを使い続けざるを得ない企業も少なくない。
