IBM i のウンチクを語ろう
～ その101：コストが決め手になったFF RPG選択
皆さん、こんにちは。アプリケーション開発・保守を外注に委ねているユーザー企業にとっては、頼りにしている企業の事業撤退は悪夢以外の何物でもありません。IT業界、いや国全体を通じて人材不足が顕在化しつつある昨今、外注先の問題がユーザー企業に影響しないとも限りません。このような状況下で、外注先企業からRPG/400プログラムの保守サービスを継続提供できなくなると聞かされたユーザーが、フリーフォームRPGに移行した事例を知る機会がありましたので、簡単に紹介したいと思います。
これまでもRPG言語には大雑把に言って3つの世代があることを説明してまいりました。すなわち古い方からRPG/400（RPGⅢ）、ILE RPG初期版（固定フォーム）、FF RPG（ILE RPGの機能強化版で俗称フリーフォームRPG）の3つです。今後の主力と目されているのは最新のFF RPGであるわけですが、一方で現在利用されている多くのプログラムは未だRPG/400に留まっているのが現実です。今のうちから将来を見据えて対策を練っていただきたい、と考えております。
前回コラム「FF RPGがなかなか浸透しない理由とは」でも述べたとおり、ツールがあるとは言ってもFF RPGへの移行に手間はかかりますし、移行しただけで直ちに何かの新機能が利用できるようになるわけではありません。また、全てのユーザーが直ちにFF RPGへの全面的な移行を実行できるだけの、余力・体力を備えていると想定することもできません。一般的に広く推奨できると私が考える、当面の現実的な対処法は、プログラムの追加開発や改修の都度、複数世代のＲＰＧを連携させることを前提に、徐々にFF RPGの割合を増やしてゆくことです。このようなやり方はユーザーの負荷を抑制しながら新たなスキルを蓄積できますし、実際に数多くの成功事例があります。
ただRPG/400のプログラム資産が残ることが前提にありますので、抜本的対策にはなりません。また冒頭に述べたように、既存RPG/400プログラムの保守サービス提供が打ち切られる事態となれば、「徐々に」などと悠長なことを言っている暇はありません。考えられる選択肢は、全面的に他の言語環境に移行するか、他のアプリケーション保守会社を探すか、二つに一つでしょう。ただ他社が開発したプログラムを保守してくれるような会社を探すのは、往々にしてドキュメントの整備が十分ではないケースも多いので、極めて困難です。ドキュメントは担当者の頭の中にある、といった属人的状況が背景にあるケースが多いようです。そうなると将来のリスクを回避するために、アプリケーションの書き換えを検討するのは極めて自然なことです。参考までにベル・データではそのようなユーザーに向けて、事前にツールによって各種ドキュメントを生成しアプリケーションを分析することを前提に、アプリケーション保守サービスを提供しています。
移行先言語として真っ先にあがりがちなのは、オープン系サーバー採用を前提とする他言語、典型的にはWindowsサーバー上のJavaでしょうか。Javaについては当コラム「最近JAVAは「元気」なのだろうか」にて述べたとおり、最近はその威光（？）の衰えを感じているところではありますが、依然として有力な選択肢であることに変わりはありません。ただ、見積もりを取ってみると、移行ツールを利用したとしても、コストと手間は想像以上になることがほとんどのようです。同時に様々な課題も浮上します。
そもそもRPGは手続き型言語であるのに対して、Javaはオブジェクト指向型です。これらの違いを話し始めると長くなりますが、要はプログラミングの根本的な思想が異なります。仮に移行ツールが期待通りに機能したとしても、見た目の文法はJavaでありながら限りなくRPGの様な、または手続き型の様なソースコードが出力されるようです。ツールによるのかもしれません。Javaプログラマにとっては違和感満載ですから、保守することは極めて困難です。RPGの知識無くして保守できないとしたら、わざわざ移行する意味はありません。
資産継承性が失われることにも目を向ける必要があります。オラクル社のOracle Java SE Support Roadmapによると、バージョン17以降のJavaの寿命は、長いとされるLTS（Long Time Support）で概ね8年間です。そして、アップグレードの際にはアプリケーションの見直しが必要になります。一方でIBM i の場合は概ね10年間であり、アプリケーションの見直しを必要とせずにバージョン・アップグレードできます。アプリケーション保守コストに関する限り、長期的視野に立てばJavaへの移行に優位性は見出せません。
特にバッチ処理において顕著になる傾向があるのですが、RPGはIBM i 向けに最適化されていることが、パフォーマンスの違いに表れます。コンパイラによって生成されたバイナリコードを直接実行するRPGに対して、Javaではインタープリタを介して中間コードを解釈しながら実行する、という違いも影響しているでしょう。Javaへの全面移行を目標に掲げながら、オンライン処理は何とか作業を完了できたけれども、バッチ処理については実行時間を目標内に収めることができずに諦めてしまったケースも見聞きします。結果的にオンラインはJava、バッチはRPGという、かえって複雑化させて終わってしまったというわけです。プロジェクトは（部分的には）成功したと評価されるのかもしれませんが、IT担当の方にとってはいい迷惑でしょうね。
Java移行のコストを見積もり技術的な懸念事項を洗い出し、さらに事例情報を収集してゆく過程で、ほとんどの方はIBM i とRPGの継続利用も選択肢に入れ直すようです。中には「オープンシステム」という言葉に引き寄せられて、Java化への道を突き進もうとされる方もいらっしゃいます。私達は生業としてJavaアプリケーション開発を請け負えるのですが、別に考慮するべき事情が無い限り、IBM i ユーザーにJavaへの移行を積極的に推奨することはまずありません。基幹業務システムのプロジェクトを失敗させてしまうわけにはいかないのです。だからと言って、RPG/400を継続利用するリスクも回避しなければなりません。そこでFF RPGに白羽の矢を立てることになります。
移行ツールがあることに加えて、資産継承性が維持され、IBM i に最適化されているというメリットがあります。現時点におけるプログラマ人口はRPG/400より小規模であったとしても、オープン系技術者にとっては参入し易いというメリットがありますし、前回コラム「FF RPGがなかなか浸透しない理由とは」にて述べたとおり、既に海外ではIBM i の主力言語としての地位を確立しています。また、IBM i の継続利用であれば、セキュリティやアベイラビリティ対策など日々のシステム運用のやり方は、従来のまま変更する必要はありません。
さて、外注先から事業撤退の告知を受けた件のユーザーは、移行先としてWindows+JavaとIBM i +FF RPGの両方の案を比較検討します。決定打となったのは、Windows+Javaへの移行コスト見積額が、IBM i +FF RPGの場合と比べて約10倍にもなるという事実でした。ここにはプログラムの移行だけではなく、IBM i が基本的に備えるミドルウェア的な機能、例えばデータベースやバックアップ用ソフトウェアなどを、Windows上に実装するためのライセンス料金も含まれています。事例の一つに過ぎませんが、どうやらRPGのFF化はコスト的に大きなメリットがあると言えそうです。
移行プロジェクトは、数千本のプログラムを対象に、予定通りほぼ1年の期間を経て完了しています。ここで留意しておきたいのは、ツールで変換して終わり、というわけにはいかない現実です。これだけの期間の大半は、変換作業ではなくその後のテストと修正に費やされています。
ご存知の通り、RPG/400からILE RPG初期版（固定フォーム）へ、さらにFF RPGへと変換するツールはありますが、変換率は100%ではないので手作業の余地はどうしても残されます。そして忘れてならないのは、ソースコードが変わるのでテストが必要になることです。個々のプログラムのコンパイルを完了させることができるか、システム全体として動作させることができて、旧来同様の出力を得ることができるか、を確認する作業です。新規アプリケーション開発と異なるのは、既に実現されているビジネス・ロジックは変更せずに、純粋に技術的な作業であることから、安全性は高めであると言える点にあります。
RPG/400を知る技術者が社内からいなくなるのか、外部のアプリケーション保守会社が撤退するのか、遅かれ早かれRPG/400を他の言語に移行せざるを得なくなる日はやって来ると考えるべきだと思います。そしてこれまで見てきたように、少なくとも現時点ではFF RPGよりも優れた選択肢は見当たらないのではないでしょうか。
ではまた
