RPG資産を次世代へ引き継ぐための準備は今が踏ん張り時 ~連載|RPG Ⅳの魅力と可能性◎第13回

RPG Ⅲに比べて
RPG Ⅳは何がよいのか

 今年の冬は降雪に地域差はあるものの、総じて例年より寒いという印象を受けます。私個人の寒い冬という印象は、東海道新幹線の関ヶ原辺りで雪が積もっているかどうか、という単純なもので、この冬は新幹線に乗るたび関ヶ原の雪景色を目の当たりにするからなのですが、この「RPGⅣの素晴らしさ」の連載が始まって3回目の冬になりました。3年にわたりRPGⅣの素晴らしさをお話ししてきたつもりですが、必ずしもその甲斐あって、というわけではないものの、徐々にRPGⅢからRPGⅣへのシフトは始まっているという声を耳にするようになりました。

 RPGⅢに比べてRPGⅣは何がよいのか、という質問を今でも多くいただきます。一方でRPGⅣのよさを理解し、RPGⅢからRPGⅣへ移行したい、という方も増えたように思いますが、そのほとんどが「そんなことをしている余裕がない」という状況のようです。自社でシステムを開発しているシステム部門は、少ない人数でシステムを切り盛りし、それだけでなく倉庫でフォークリフトを操作したりトラックを運転したりという、システム部門以外の作業も日常的に行っていると聞きます。そういう状況でRPGⅢからRPGⅣへの移管などは夢のまた夢、ということなのでしょう。

 現場の苦労がうかがえる話ですが、同時にIBM iの凄さが見え隠れします。RPGⅢの資産はS/38の時代にまで遡り、30年近く昔の資産も多くあるようですが、それが当時のままの姿で稼働しているという事実です。

 30年近く前であればS/36も活躍していた時代で、実はRPGⅢだけでなくRPGⅡのプログラムも現在に引き継がれ、現役で頑張っているのです。それらのシステムが未来永劫と言っていいほどに動き続けるのがIBM iのよさで、「ハードウェアやOSを最新にしても、アプリケーションに手を加える必要はない」ことは、私どもアイ・ラーニングの研修でもずっと申し上げてきたことでした。この論法であれば、RPG ⅢやRPGⅡのままシステムを使い続けて何が悪い、という話になるかもしれません。

 

 

フリーフォームRPGへの
移行が理想的

 しかし現実では、IBM iに人間のほうがついていけなくなったという悲喜劇のようなことが起こってしまっています。30年前のままのシステムを見守りながら定年を迎える技術者は多いと思います。しかし、残されたIBM iと、若い技術者の人たちはどうすればよいのでしょうか。このままではIBM iは30年前のシステムを動かし続けているタイムマシンのような存在になってしまいます。

 次の世代に引き継ぐには、現段階でのRPGⅡ、RPGⅢアプリケーションを、RPGⅣ、それもフリーフォームのRPGに移行するのが理想的なやり方です。フリーフォームのRPGであればJavaやPHPなどのオープン系アプリケーションのプログラミングスタイルに近く、Java、PHP経験者であれば、習得がこれまでと比較にならないほど早くなります。また、フリーフォームRPGで、DBアクセスをSQLに変えることによって、多くの若いプログラマーが感じる「固定位置記入RPGのわけのわからなさ」を払拭できると思われます。

 これから数年、RPGプログラマーは、今までのRPG(RPG ⅡやRPGⅢ)と、新しいRPG(RPGⅣ/フリーフォームRPG)の両方を知っておく必要があると思います。RPGプログラマーとしてはこれまでにないスキルの高さが要求されると思いますが、フリーフォームRPGへの切り替えが進んでいけば、それらの資産を若い世代に引き継ぐことができます。今がRPGプログラマーの正念場といえるでしょう。フリーフォームのRPGまではなかなか、という方には、次のような形でプログラム修正し、次世代に引き継ぐ準備にだけでも取り組んでみられてはいかがでしょうか。

 

 

RPGプログラムを
次世代へ引き継ぐための準備

 

① 標識の撤廃

 RPGⅢで標識をまったく使わずにプログラムを書くことは事実上不可能ですが、それでも最小限に抑える努力は必要です。若いプログラマーにとって、この標識の存在が高いハ ードルなのです。RPGⅢの段階で標識をなるべく使わず、IFそしてサブルーチンを使ったプログラムに変えるだけでも、かなり見やすいプログラムになります(図表1)。このプログラムをフリーフォームのRPGに変えたものが図表2になります。

 

② RPG内部論理の撤廃

 これができるからRPGでの開発効率が高いのですが、今となっては多くのプログラマーが理解不能なプログラミングスタイルになりました。マッチングや制御レベルの使用は今でも便利なものではありますが、マッチング、集計などのそれぞれ標準化のスタイルを決め、それに当てはめていく方法がよいと思われます。

 図表3は、従来RPG内部論理で制御グループ処理を行ってきたものを、パターン化した繰り返し処理に当てはめたものです。ロジックは従来より増えますが、パターンとして定着されれば、バグも発生しにくくなります。

 

 

③ プログラム記述の撤廃

 RPGⅡからの資産では入力仕様書が使われています。SQLを使用するようになるとファイル仕様書とともにまったく不要なものになりますが、いったんデータ構造として定義しなおし、それをRPGⅣに変換すると定義仕様書になりますので、ゆくゆくはSQLのデータの受け皿として流用が可能です(図表4)。

 

フリーフォームRPGは
RPG Ⅲプログラマーのほうが理解が容易

 現在のRPGⅡ、RPGⅢ資産を次世代に引き継ぐには、RPGⅡ、RPGⅢ、そしてフリーフォームRPGを熟知していなければなりません。しかも若いJava、PHPプログラマーがRPGⅡ、RPGⅢを理解するよりも、RPGⅡ、RPGⅢプログラマーがフリーフォームRPGを理解するほうがはるかに容易です。

 フリーフォームになっても、やはりRPGはRPGなのです。今のRPGⅡ、RPGⅢプログラマーの責任は重大で、苦労は増えるばかりという感じもしますが、今が踏ん張り時であると思います。次世代にRPGを引き継ぐための準備を、少しずつでも進めていきたいものです。 

 

著者|中村 潤 氏

株式会社アイ・ラーニング
IT研修本部 IBM製品研修部
ラーニング・アドバイザー

[i Magazine 2017年2月号掲載]

・・・・・・・・

◎ 連載|RPG Ⅳの魅力と可能性 目次