IBM i のウンチクを語ろう
～ その37：モダナイゼーションは正しい課題認識から
皆さん、こんにちは。10年・20年、もしくはそれ以上にわたってIBM i を利用いただいている方は数多くいらっしゃると思います。この業界にいる者として大変にありがたい事です。アプリケーションに手を入れなくてもマシンやOSバージョンを更新できるというメリットは、言わずもがな、といったところでしょうか。IT部門としてはそれで良しとしていたとしても、ユーザーや経営層がシステムに対して異なる印象を抱くのはよくある事です。クライアントに5250エミュレータが採用されていたら、その見栄えが最新のGUIではないために、自社のシステムは市場において遅れをとっているように見えるかも知れません。アプリケーションがRPG/400で記述されていたら、いずれプログラマが枯渇してしまい、プログラムの保守が立ち行かなくなってしまうリスクがあると考えるかも知れません。次回のシステム刷新時には、単純にマシンを置き換えるのではなく、最新のテクノロジーを取り入れることで、後れを取り戻そう・将来のリスクの芽を摘み取っておこう、と考えるのはごく自然な事です。
モダナイゼーション、すなわちシステムの実装テクノロジーの刷新は、随時取り組んでいただきたい課題です。単にテクノロジーの枠内に留まらず、ビジネスのあり方を革新し、各企業が成長するための原動力ともなり得るものです。ただ残念ながら、出発点における課題設定を誤ったために、当初目標を達成できなかったり、プロジェクトそのものが無意味に終わってしまったりしたケースがあるのも事実です。今回のコラムでは敢えて失敗事例を取り上げて検討してみます。
そのお客様（ここでは仮にA社としましょう）は20年以上にわたるIBM i ユーザーです。基幹業務用のアプリケーションはRPG言語による自社開発で、エミュレータを利用して日々の業務処理を行っておりました。昨今の業務量拡大に伴うシステムの性能劣化の問題に対処しようとする一方で、いずれIBM i やRPGの技術者を確保するのが困難になるかも知れない、といった漠然とした不安が頭をもたげるようになります。経営層からの要求（圧力？）もあったのでしょうか。ハードウェア刷新だけではなく、モダナイゼーションが同時に取り組むべき喫緊の課題として急浮上します。当時の資料から読み解くと、設定された課題と解決策は以下のように4点ありました。A社にとってのモダナイゼーションとは、IBM i やRPGから脱却してWindowsに移行することであり、将来の技術者不足のリスクを回避するためのクラウドの採用でもありました。必ずしもA社だけのユニークな発想ではなく、実際に取り組むかどうかはさておき、長年のユーザーに見られる典型的な思考パターンだと言えそうです。
| 1. パフォーマンス不足 | → | システム刷新 |
| 2. 将来のIBM i 技術者不足への懸念 | → | Windowsクラウドへの移行 |
| 3. 将来のRPG技術者不足への懸念 | → | Javaへの移行 |
| 4. ユーザー・インターフェースがCUIであること | → | （同上） |
この中で最も負荷が大きい作業は、項目3のRPG言語からJavaへの書き換えでしょう。1年足らずの間に一通りの移行作業を行ったと聞いていますので、このスピード感から判断して、何らかの移行ツールを利用したと推測されます。そうであるにも関わらず、その期間は結果的に、プロジェクトとしての困難さを認識するためだけに費やされてしまいました。冒頭で述べた、アプリケーション資産の継承性というIBM i のユニークな価値はあたり前のものになってしまったためか、残念ながらA社の意識に上らなかったようです。
パフォーマンスは基幹業務に耐え得るものではありませんでした。RPG言語はIBM i 向けに最適化されていますが、JavaはWindowsに対して同様であるとは言えません。コンパイルによってバイトコードを出力するとは言え、そもそもインタープリタ型であるという構造上のハンディキャップがあります。特にバッチ処理において、他のサーバーでRPGと同等のパフォーマンスを叩き出すのは容易なことではありません。オンラインの応答時間2秒が2.2秒に伸びても耐えられるとしても、バッチ経過時間5時間が30分間延長されたら、システム運用に支障が生じるかも知れません。同じ伸び率10%でも影響度は格段に違います。また、プロジェクトが進捗するにしたがって、新たに作り込まなければならない機能要件が次々と発覚します。IBM i がOSとして備える機能範囲はWindowsよりも広範にわたるので、移行しようとしたら差分の作り込みが必要になります。事前の作業見積りに反映されない項目が数多くあったのでしょう。プロジェクトは収拾がつかなくなり、中止の憂き目を見ます。
RPGをJavaに書き換えようという試みは他にも聞いたことがありますが、最初から対象となる機能範囲を限定するならばともかく、全面的移行の成功事例はなかなか聞きません。基幹業務システムに手を付けることのリスクと作業負荷、ないしはアプリケーション資産の継承性を放棄するコストを意識するならば、IBM i をWindowsに置換えると決する前に、一旦踏み止まって考えていただきたいところです。極めてストレートに考えるならば、技術者確保が懸念されるのであれば、補充できる体制を整備するか、必要な人員を削減する事が考えられます。ユーザー・インターフェースに古めかしさが感じられるならば、そこを刷新できないか検討すれば良いわけです。直接的な対策を取りようがないのであれば、そこではじめてインフラであるIBM i の問題ないし限界を疑い、移行を検討する事になります。そこまで煮詰まったケースは寡聞にして知りませんが。
先のA社の4つの課題はそのままに、解決策を再検討してみた結果が以下です。アプリケーション資産の継承性というIBM i のユニークな価値を活かしながら、懸念事項を解決する、というのが大方針です。
| 1. パフォーマンス不足 | → | システム刷新 |
| 2. 将来のIBM i 技術者不足への懸念 | → | ハウジングと運用支援サービス |
| 3. 将来のRPG技術者不足への懸念 | → | アプリケーション診断・保守サービス |
| 4. ユーザー・インターフェースがCUIであること | → | ユーザー・インターフェースの刷新 |
最大の課題である項目3について少し補足しておきましょう。A社が自社開発したアプリケーションを、外部の会社が保守することはできるのかという点です。20年以上も前に開発されており、小刻みな改修を繰り返してきたので仕様書はあったとしても役立たず、A社自身ですらプログラムを改修するにあたって現状を把握するのに苦労するような状況です。マシンやOSの世代を越えてアプリケーションを長期的に利用できることはメリットですが、ドキュメント化ができていなければ、ブラックボックス化のリスクを抱える可能性がある、という点は認識しておきたいと思います。
このような課題を解決するためのソリューションが、プログラムの可視化ツールです。プログラムの構造を分析して仕様書を生成する機能を備えるだけでなく、改修する際の影響分析機能を備えたものもあります。IBM i 用の実績ある製品として、NCS&A社のREVERSE COMET i、アイエステクノポート社のSS/TOOL-ADVなどがありますが、弊社ベル・データでは様々な製品を比較・検討した結果、最も機能的に優れていると判断されたX-Analysisを取り扱っています。
IBM i を最大限に活かす戦略について、最後にまとめておきましょう。アプリケーション資産継承性というユニークな価値を活かしながら、ブラックボックス化させないためにプログラムの可視化ツールを導入し、適宜最新テクノロジーを実装してビジネスにイノベーションをもたらす、といったところでしょうか。IBM iのモダナイゼーションのためには、旧来からある画面や帳票の刷新から、アナリティクスやAI活用に至るまで、各種の実績あるソリューションが用意されています。是非他のシステムには無い優位性を活かしていただければと思います。
ではまた
