IBM i のウンチクを語ろう
～ その16：RPG言語は好きですか？ -2
皆さん、こんにちは。早速ですがRPGと聞いて何を思い浮かべるでしょうか。最も一般的にはファイナルファンタジーとかドラゴンクエストなどのRole Playing Gameでしょう。このコラムのテーマにしているのはIBM i 用プログラム言語のReport Program Generatorのことなのですが、最後にGeneratorすなわち「生成するもの」とあるので、どちらかと言うと何かの簡単なツールをイメージさせます。それもそのはずで、プログラマーでなくても使える簡便性を訴求するために、IBMロチェスターの開発部門は当初はRPGを敢えてプログラム言語であるとは主張しませんでした。RPGが開発された60年近く前は、プログラマーは特殊技能を持った高給の技術者だったので、システムを使いこなすにあたって人件費を抑制できる事をアピールしたかったようです。
簡単に使いこなせて、しかもアプリケーション資産が保護されるからといっても、現在ではRPGで記述された古いプログラムをどうにかしたい、しかしながら他の言語に書き換えるのは負荷が大き過ぎる、といったジレンマに陥っているユーザーが多いことは、前回のこのコラムで説明したとおりです。ではどうすれば良いのか対策を考えようというわけですが、その前にそもそもRPGの何が問題なのか、あらためて確認するところから始めましょう。
おそらく最も多い指摘は、時代遅れのユーザー・インターフェース、ないしCUI画面が使われているという点です。GUIを標準とするPCでありながら、RPGプログラムを利用しようと5250エミュレータと呼ばれるソフトウェアを起動させると、そのウィンドウ内だけは異質な空間が展開されます。グリーン・スクリーン、ブラック・スクリーン、黒画面などと称される、黒地に緑字の文字だけの表示が古さを感じさせます。画面あたり横 80文字（半角文字の場合）、縦24行と情報量が少ないばかりでなく、画像を表示できないので直感性に劣っていて使い勝手がよろしくありません。実態はともかく、見栄えの悪さはアプリケーションの機能の低さと見なされてしまい、社内インフラを保守していないかのような印象を与えるとしたら、IT部門にとっては心外です。アプリケーションも人も見た目が9割、というわけです。
念のためにアプリケーションの構成要素を眺めてみると、画面以外にアプリケーション・ロジックやデータ（データベース）もありますが、これらはあまり問題視されません。すなわちRPGの問題と言ったところで、その実態は言語そのものではなく、画面の見栄えの悪さを指摘していることが多いのです。それを解決するためのツールとして、IBMからはHATS、他にもサードパーティから各種の製品が数多く販売されています。これらに共通するメリットは、既存のプログラムに手を加える事なく、CUIをブラウザやモバイル・デバイスなどGUIに変換できる点にあります。自動変換機能だけで済ませてしまう事も可能ですが、画面設計機能を利用して見栄えを調整することで、使い勝手を向上させる事ができます。
さらには画面遷移を変更し、複数画面情報を統合する事で、アプリケーション利用における生産性向上を追求できる製品もあります。古いプログラムは開発者の都合に合わせて、その機能毎にメニューがまとまっている傾向があるのですが、ユーザーの都合はこれに合致しない事も多いのです。例えば在庫状況を参照してからオーダーを受注しようとしたら、機能の異なる二種類のプログラムを利用する必要があります。すなわちメニュー画面があるとしたら、それらは大分類のレベルで別系統に配置されますが、ユーザーは両者を連携して利用する必要があります。二つの画面を行きつ戻りつするよりも、一つにまとまっていた方が明らかに便利です。
ただCUIは常に問題視されるとは限りません。例えば大量の伝票入力に従事するオペレータの方は、伝票から目を離すことなく、ただひたすらにキーボードからデータを入力していきます。マウス操作を前提とするよりも、キーボード操作だけの方が格段にスピードが上がります。またネットワーク上を流れるデータ量も、画像を含むブラウザなどに比べると非常に少なくて済みます。各種属性情報を含めたとしても、CUIだと一画面あたり2～3KB程度しかないのに対して、ブラウザだとその10倍以上になることは稀ではありません。
言語の仕様が問題視されることもあります。RPGはIBM i の主力言語であるわけですが、バージョン毎に見るとその中でも最大のシェアを占めるのはRPGⅢでしょう。カラム位置が固定されていて見た目の古さを感じさせるだけでなく、独自のコマンドや構文をきちんと学習しない限り、ソースプログラムを読み取る事はまず不可能です。PHP、C、Pythonなどといった言語の学習経験があるプログラマーであったとしても、それまでの知識・経験はまず役立ちません。
IBMはこの状況を手をこまねいて眺めていたわけでありません。RPGⅣにおいては、プログラムのモジュール化に対応しました。これによりRPGだけでなく、他の言語を適宜組み合わせて、アプリケーションを開発できるようになりました。さらにプログラムの見た目も改善されました。サポートされるコマンドの綴りが他の言語のものと近くなり、ほぼ同じ、または容易に連想できるものになりました。実例を挙げると、条件分岐はif ～ else ～ endif、ループはfor ～ endfor、といった具合です。さらにフリーフォームRPGと呼ばれるように、カラム位置の制約も撤廃されました。右へと桁をずらしながら記述することで（インデント）、ループ（繰り返し演算）や条件分岐の在処を明確にするのはごく一般的なスタイルですが、同じ記述法を取り入れて他の言語と構文を共通化しました。こうすることで、RPGは全く知らなくても例えばC言語経験者であれば、プログラムは何をしようとしているのか概要を読み取る事が容易になります。
この狙いはRPGプログラマーの増加です。RPGはそれぞれのユーザー企業において、基幹業務をサポートするプログラムを記述するために採用されていますが、これを保守・改修できる人材が枯渇してしまったら、企業の存続に関わります。PHP言語経験者にRPGⅣを学習してもらい、プログラマーとして戦力化するという取り組みも海外では既に始まっています。そして見た目がPHP言語に似ていたとしても、後継バージョンにおいて互換性が維持されるRPGのメリットには変わりがありません。
新規にプログラムを開発するのであれば、RPGⅣは理想的な解になり得るのですが、このままでは既存のRPGⅢプログラムをどうするのかという課題に対する解決策にはなりません。次回はこのあたりを探っていく予定です。ではまた。
