IBM i のウンチクを語ろう
～ その60：フリーフォームRPGは本当に効果があるのか -1
皆さん、こんにちは。原稿締切り間際まで書くべきテーマを思い付かずに呆然とし、思考を上手く表現できないボキャブラリの貧困さを呪いつつ、何とかこのコラムを続けて5年になりました。そろそろネタ切れになりそうだからもう止めたい、と周囲に愚痴ったこともあるのですが、結局は「あともうちょっと何とかなるかな」の言葉に励まされて（尻を叩かれて）今日に至ります。小さな節目ではありますが、一人勝手にささやかな達成感に浸りつつ、最終回を宣言するのは今しばらくお預けにできるかなと思っております。
さて、丸5年目を迎える記念（？）に取り上げたいテーマはフリーフォームRPG（以下FF RPG）です。様々なプログラム言語を選択できる環境下にありながらも、IBM i イコールRPGという図式はIBM i コミュニティの中に根強く染みついています。製品の将来性はRPGプログラマの動静が大きく左右すると言っても過言ではありません。将来性を確実なものにするための施策の一つとして、製品開発部門はFF RPGを既に用意しているのですが、お客様は実際にこの製品をどのように捉え、活用しているのでしょうか。IBM i Forum 2021セミナーの中でRPG活用事例を取り上げて紹介しようと、先日は何社かのお客様にインタビューする機会に恵まれました。その内容をシェアすることで、FF RPGの可能性を見直すきっかけにしていただきたい、というのが趣旨です。なお今回は長くなりそうですので、2回連続シリーズで話を進めてまいります。
FF RPGはプログラミングに際して、カラム位置を自由に記述できることからその名前が付けられていることはご存知と思います。1988年のAS/400と共に登場したRPG/400（RPGⅢ）は、1994年にILE RPG（RPGⅣ）、その後2013年に更なる機能強化を果たしてFF RPGに進化しています。RPG/400と1994年のILE RPGをあわせて固定フォームRPGと呼んで、FF（フリーフォーム）と区別する事もあります。少々ややこしい事に、FF RPGはILE RPGの中の機能強化版という位置付けにありますので、ILE RPGだけでは固定フォームなのかFFなのか区別できません。ちなみに「固定フォーム」は「Fixed Form」となり、区別できなくなってしまうので英語圏では「FF」という省略形は使われないようです。そしてFF RPGのメリットは、他のオープンなプログラム言語、例えばC、PHP、Pythonなどと類似の構文規則を備えているために、他言語経験者にとって学びやすい点にあります。
FF RPGを既に活用されているお客様にその理由を問うと、将来のRPG技術者不足への不安や、技術者の世代交代への備えを真っ先に挙げるようです。将来に対する不安を語る文脈の中では、RPGイコール固定フォーム、すなわちRPG/400ないし初期版のILE RPGを指していると考えて差し支えありません。これら旧来のRPGは基幹業務を記述する上で極めて生産性が高く、後の世代のハードウェアやIBM i バージョンにおいても互換性が維持されることから、長年にわたってプログラム資産を積み上げてきたお客様は少なくありません。かつてプログラムを開発し保守に携わってきた技術者の方もベテランの域に入り、いずれは引退が視野に入って来ようという時期が訪れます。一方、業務の見直しや拡張というビジネス要件が凍結されるわけではありませんので、プログラムの改修はIT部門として当然のように求められます。そうなると引退するベテランに代わる要員を確保しながらこのまま旧来のRPGを使い続けるべきなのか、他言語に切り換えるべきなのか、検討を迫られる事になります。
今回インタビューに応じてくださったお客様は、プログラム言語の白紙見直しを行いました。ビジネス要件が絶えず変化する中でITの柔軟性を確保するために、自力で保守できる体制を維持する事が大前提です。まず直面したのはRPG経験のある技術者を新たに確保するのは困難であったこと、そして可能だったとしても4~50代以上のベテランしか見つからないので、プログラムの長期的な保守体制構築の面では不安が残ることでした。プログラマ人口が多いため若年層技術者を確保しやすいだろうとの期待からJavaの採用も検討しましたが、自社では技術的に使いこなすのが難しそうだとの判断からこの案を見送っています。
IT以外に遂行するべきビジネスを第一とする企業にとって、Javaなどのオープン系テクノロジーを使いこなすのは難しいというコメントは、別のお客様からもよくうかがいます。例えば立命館大学様は「Javaなどの複数のオープン技術に対応できるスキルを学内の要員で維持することが困難」と自力保守の難しさを語っています。当初はJavaアプリケーションの保守を外部に委託しなければならなかったために、大学運営上の様々なシステム要件に迅速に対応するのが困難になってしまっておりました。さらにJavaにはアプリケーションの資産継承性も無く、FF RPGならばそれが可能になることから、最終的にはIBM i とFF RPGの採用へと舵を切りました。他のお客様において、将来のRPG技術者不足への不安から、Javaへの移行に挑んで挫折したケースもありました。オープン系テクノロジーの難易度の高さが原因です。当コラム「モダナイゼーションは正しい課題認識から」に簡単ながら顛末を紹介しておりますので、目を通していただければ幸いです。
何が明暗を分けたのでしょう。結果的にはそうなっているのですが、IBM i ならば上手く行く、といったような単純な図式になるわけではないと考えています。長年IBM i を使用していれば、何らかの技術的な不安・懸念を抱えるようになるのはごく自然なことです。
例えば将来のRPG要員確保に不安があるとします。先に述べたとおり、ここで言うRPGは固定フォームです。要員を自社で養成することを検討するケースはあるかもしれませんが、あまり魅力的なプロジェクトではなさそうです。手間もかかりそうですし、そもそも学習意欲を持つ人がどれだけいるのかもわかりません。これに対してRPGイコールIBM i という図式が根強くあれば、RPG以外のプログラム言語、IBM i 以外のサーバーへと脱却、すなわち典型的にはオープン系に移行しよう、という選択肢がより魅力的で有力なものに映りそうです。もちろんこのようなプロジェクトは容易に実現できるものではありませんし、仮にうまく行ったとしても本当にメリットのあることだとは必ずしも言えません。二の足を踏みながら結局はIBM i とRPGに留まっているケースがほとんどなのですが、踏み切ったケースも稀にある、といったところでしょうか。その一つが当コラムで紹介した事例だったというわけです。
RPG要員を必要としない体制への移行を検討するという発想は、おそらくどのお客様においても共通のものです。ここでRPGイコールIBM i と拡大視してしまうのか、ピンポイントに固定フォームRPGのことであると認識できるのか、の違いが決定的なのだと思います。ピンポイントの発想はFF RPGの存在を知らないと、なかなか出てこないものです。インタビューに応じたお客様はいずれも明らかに後者でした。IBM i コミュニティの中で、もっとFF RPGの価値を理解いただかなければならないなと自らの力不足も感じます。
おそらく一歩引いた視点から課題を眺めてみることが必要なのでしょう。FF RPGだからと言って、既に経験者がいるわけではありません。実際のところプロジェクトをどのように推進したのか、古い固定フォームのRPGはどうするのか、何か課題は残されていないのか、といったあたりを次回は述べてみます。
ではまた
