「IBM i(AS/400)」モダナイゼーションでよくみる失敗原因あるある

阿野幸裕 (ジーアールソリューションズ)

2020-10-14 07:00

 前回の記事において、基幹システムを稼働させているユーザーは、ベテラン技術者が在職の内に課題解決をする必要があり、コロナ禍とは言え先送りできない課題となっていることをお伝えした。しかし、大きなシステム開発、改修のプロジェクト予算を取ることが難しい時世において、ビフォアコロナ時代よりもさらに用心してモダナイゼーションを進める必要があり、失敗は許されない。

 今回は、過去に起きたモダナイゼーションの問題を分析し、同じ轍を踏まないために課題を整理していく。

別プラットフォームへのリプレースでかえってコスト増大

 「IBM i」以外の別プラットフォームにモダナイゼーションの何らかの手法でアプリケーションをリプレースした結果、IBM iの時より大きなハードウェアやソフトウェアの構成になることが発生している。それらの運用、管理工数も拡大することになり、今まで考えなくてよかったコストが新たにのしかかることになる。

 原因としては、IBM iが通常、データベースなどのミドルウェア、運用及び管理システム、セキュリティシステムなどを別々に購入した場合、サーバーに分散配置するような基盤ソフトウェアをOSに内包していることにある。ハードウェア上で最適化されて効率よく安全に稼働しているため、同等のシステムレベルをリプレース先のプラットフォームで実現するとなるとIBM iより大がかりなシステムの準備が必要となる。稼働アプリケーションが矮小な場合を除き、メインフレームなどの大型コンピューターのリプレース時においてのメリットとなるダウンサイジングが期待できないことを示している。

ツールでコンバージョンしたものの…

 RPGなどのIBM i上のプログラムを人手でJavaなどにリライトするより、効率的でコスト的にも廉価な方法としてツールを用いたコンバージョンが挙げられるが、提供ベンダーのツール、付帯サービスなどに課題があることがある。うまくコンバージョンできずに頓挫したり、コンバージョン成功後に発生したりする場合もある。

 多くのコンバージョンツールには独自のフレームワークがあり、RPG言語をJavaなどのクラス、メソッドに体系化させて置き換えている。結果としてRPGの言語体系で書かれたJava表記のソースとなってしまい、JavaエンジニアがRPGの言語体系を理解しないとソースが変更できなくなってしまう。

 RPGとJavaの間に、独自の中間言語を置いて変換するツールもあるが、中間言語を覚えなければメンテナンスや新規作成ができない。変更の無い塩漬けのシステムには非常に有効な手段であるが、コンバージョン後にソースを改変したいユーザーにとっては逆に塩漬けになってしまう問題が生じることを意味している。コンバージョン完了後にそのことに気付き、IBM iを使い続けざるを得ない企業も少なくない。

ZDNET Japan 記事を毎朝メールでまとめ読み(登録無料)

ホワイトペーパー

新着

ランキング

  1. セキュリティ

    従来型のセキュリティでは太刀打ちできない「生成AIによるサイバー攻撃」撃退法のススメ

  2. セキュリティ

    マンガでわかる脆弱性“診断”と脆弱性“管理”の違い--セキュリティ体制の強化に脆弱性管理ツールの活用

  3. セキュリティ

    クラウドセキュリティ管理導入による投資収益率(ROI)は264%--米フォレスター調査レポート

  4. セキュリティ

    Microsoft Copilot for Security--DXをまい進する三井物産が選んだ理由

  5. セキュリティ

    情報セキュリティに対する懸念を解消、「ISMS認証」取得の検討から審査当日までのTo Doリスト

ZDNET Japan クイックポール

所属する組織のデータ活用状況はどの段階にありますか?

NEWSLETTERS

エンタープライズコンピューティングの最前線を配信

ZDNET Japanは、CIOとITマネージャーを対象に、ビジネス課題の解決とITを活用した新たな価値創造を支援します。
ITビジネス全般については、CNET Japanをご覧ください。

このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]