IBM i と言えばRPG

IBM i と言えばRPG、RPGと言えばIBM i。IBM i の上で利用されているアプリケーション開発言語についてユーザー・アンケートを取ると、トップにランクインするのはまず間違いなくRPG言語でしょう。しかも第二位に圧倒的大差をつけてです。その一方で、IBM i を継続利用するべきか脱却を目指すべきか、検討の際に否定的な要因として真っ先に槍玉に挙げられがちなのもRPG言語です。数多あるプログラム言語の中で、RPGほど好悪入り混じった感情を持って語られる言語は他に無いのではないでしょうか。

主力言語でありながらも嫌われる原因にもなっている、その最大の理由はレガシーであるという点にありそうです。辞書を引くと「遺産」とか「時代遅れのもの」といった訳語に出会うので、テクノロジーの世界では否定的に受け取られる傾向がありますが、私達は日常会話において、この言葉に「後の世代に引き継いでゆくもの」といった意味を含ませることもあります。RPGは時代遅れなので破棄されるべきなのか、それとも後の世代に引き継いでゆくべきものなのか、この相反する見方を掘り下げてみるのが本章の狙いです。

初代のRPGが登場したのは1959年とされていますので、人間で言うと既に還暦を過ぎています。業界で人気の高いオープン系言語のPythonの登場は1991年、Javaは1995年ですので、これらに比べれば「高齢」であることは否定しようがありません。やや乱暴ながら、世間では大雑把に以下のような印象を持って捉えられているのではないでしょうか。

• RPGはレガシー・テクノロジーであり、技術者も減少する一方だし将来性が無い
• だからRPGのプラットフォームであるIBM i も同様である
• 一方で、新しいPythonやJavaはオープンであり、技術者不足とは無縁だし将来性がある
• だからこれら言語のプラットフォームであるWindowsなどのオープン系サーバーも同様である

ここで私が主張したいのは、言葉がもたらす印象に振り回されるのではなく、事実をもってテクノロジーを評価したい、ということに尽きます。RPG言語の特徴を冷静に見れば、おそらく以下のように捉えることができるはずです。

• 歴史の長さと将来性とは相反する、という見解に合理性はない
• RPGアプリケーションには資産継承性があるので、将来においても安心して利用できる　一方のPythonやJavaには資産継承性は無い
• だからRPGのプラットフォームであるIBM i も同様である
• フリーフォーム化によって新規参入するためのハードルは下がっている
• 他のテクノロジーと連携するためのインターフェースが整備されているので、レガシーとオープンの両者の長所を組み合わせたソリューションが実現可能になる

資産継承性の意義

開発され実行可能となったアプリケーションを、そのままで後の世代のハードウェアやOSバージョンの上で動かせること。IBM i の最大の特徴であるアプリケーション資産継承性をこのように説明することができます。

オープン系システムにおいて、ハードウェアやOSを刷新することだけが目的であったとしても、それに伴ってアプリケーション見直しも必要になることに、どれほど多くのユーザーが苦しめられてきたことでしょう。多大な作業負荷やコストを回避するために、メーカーによる保守期限を超過したまま騙し騙しシステムを使い続ける、いわゆるオープン・レガシー化してしまったシステムも存在します。ITの世界一般においては、システムの成長と資産継承性とは相反する関係にあるのに対して、IBM i はこれらを両立させているユニークなシステムだと言うこともできます。

ただ、必須ではないために見直すきっかけを見失ってしまい、10年20年と全く変わらないアプリケーションを使い続けるユーザーがいるのも事実です。これを「資産継承性が仇となっている」と表現する人もいるのですが、資産継承性の狙いを正しく理解していれば、見方は全く違ったものになるはずです。

資産継承性の本来の価値とは、アプリケーションはテクノロジーから分離されているので、両者の見直しを同期させる必要が無い、というものです。ビジネス要件が生じたら、アプリケーションを見直す必要があります。環境の変化に合わせて仕事の進め方も変えるのは、至極当然のことです。一方で、保守切れやリース満了のタイミングではマシンを刷新することになります。特に基幹業務を担うシステムを、メーカー保守の無い状態で利用し続けるのはリスク以外の何物でもありません。そしてアプリケーションとテクノロジーを見直すべきタイミングは、相互に影響しあうことがない、というわけです。

参考までに、資産継承のメカニズムについては、当文書のセクション2-1．IBM i の長期的コスト削減をもたらす「アプリケーション資産継承性」を参照いただければと思います。

RPG三世代

テクノロジーの世代を越えて使えるRPG、というわけですが、初代が誕生して以来、今日に至るまでに何度かの大きな進化を見ることができます。この過程を一言で表現するならば、オープン化、または標準テクノロジーの取り込みです。世の中には様々な設計思想に基づいた数多くのプログラム言語が存在しますが、大きなトレンドのようなものがあり、そこから逸脱していることは、新たな言語学習者を獲得する上で障壁になる可能性があります。

IBM i 関係者にとってはRPGの登場はそれなりに大きなイベントだったはずなのですが、IBM社の歴史を紹介するサイトを見ても、残念ながらその年月は明確には記されていません。真偽の確認のしようがないのですが、Wikipediaによると1959年に当時のIBM汎用機1401用に開発されたとあります。AS/400登場を遡ること約30年、プログラム言語の歴史はシステムよりも長いようです。

IBM社がIT市場においてその存在感を圧倒的なものにする原動力となった製品はSystem 360でした。いわゆる大型汎用機、今で言うところのメインフレームです。大手のユーザーが主なターゲットであったわけですが、一方で中堅以下のユーザーを対象に強さを発揮したライバル企業がDEC（デジタルエクイップメント）でした。当然のことながら競合することもあったのですが、System 360最下位モデルでも大き過ぎてしまうケースにおいて、IBMは苦戦を強いられることになります。そこでIBMが中堅以下の市場に本格的に進出するにあたって、1969年に発表したのがIBM i の遥かな祖先にあたるSystem 3であり、主力言語として採用されたのがRPGⅡでした。その後数世代を経てSystem 38の登場と共にRPGⅢにアップグレードされ、そのままRPG/400として1988年のAS/400に引き継がれます。

RPGがIBM i の歴史に登場するのは、このRPG/400またはRPGⅢからです。その後1995年のILE RPGまたはRPGⅣ、さらに2013年にはフリーフォーム（FF）RPGと呼ばれるILE RPG（RPGⅣ）の進化形へと発展します。フリーフォームRPGが登場したことで、初期のILE RPGは固定フォームRPGとも通称されるようになります。もちろんこれらは大雑把な括りであって、各世代の途中においてもIBM i のバージョン・アップグレードに伴う機能強化も行われています。

この文書では便宜上、古い方から順にRPG/400、ILE RPG初期版、FF RPGという言葉で3世代のRPGを表現してまいります。ちなみに「FF」だとFixed Form（固定フォーム）とFree Form（フリーフォーム）のどちらを指すのかが明確ではないので、海外ではこの表記は使われません。

ILE RPGの進化

ILE RPG初期版がRPG/400に比べて進化した点を一つだけ挙げるとしたら、プログラム間の呼び出しにおいて、静的呼び出し（Static Link：スタティック・リンク）が新たにサポートされるようになったことだ、と言えるでしょう。従来のRPG/400においては動的呼び出し（Dynamic Link:ダイナミック・リンク）のみがサポートされていたのに対して、もう一つの呼び出し方法が加わったというわけです。これだけだと意義がわかりにくいのですが、実はプログラミングの方法論に及ぶようなインパクトを伴っています。すなわち、従来の一枚岩的な、英語で言うとモノリシック（Monolithic）なプログラムから、モジュール構造化されたプログラムへの移行、が狙いです。一つの大きなプログラムではなく、複数の小さ目なプログラムの集合体というわけです。

個人差はありますが、人が見通せるプログラムのステップ数には限界があるとされています。500位という方もいらっしゃいますし、1,000位までは大丈夫という方もいらっしゃいます。ここでこの限界を超える長いプログラムがあったとしたら、読み解いて修正時に手を入れるべき箇所を特定するのが著しく困難になるなど、保守性が損なわれてしまいます。適度な大きさの複数のプログラムをリンクさせて使う方が望ましいというわけです。もちろん何でも闇雲にバラバラにすれば良いのではなく、プログラムの部品化、すなわち機能の塊を意識する必要があります。例えばメイン・プログラムからサブ・プログラムへ、さらに別のサブ・サブ・プログラムへ、そしていずれは元のメイン・プログラムへ帰って行く、という具合に実行されてゆきます。

メインからサブのプログラムに制御を移す際に、サブ・プログラムをストレージの中から「拾い上げ」てから「飛んで行く」ことになるのですが、この一連の準備作業をプログラム実行中に行うのが動的リンクです。業務とは直接的には関係が無いので、「余分な」作業だとも言えます。パフォーマンスを考慮するのであれば、実行時に「余分な」作業を行わないで済ませるために、プログラムを一つにまとめるように作っておいた方が有利に働きます。結果的にリンクにあまり頼らない、規模の大きな一枚岩的なプログラムを作ろうとすることになります。

一方で、実行前のプログラム生成時に、サブ・プログラムを拾い上げてメイン・プログラムに連結して一つにまとめておくのが静的リンクです。プログラム生成時に「余分な」作業を実施するので時間は要しますが、アプリケーション実行時の仕事量を抑えることができるので、パフォーマンスに優れることは容易に想像できると思います。規模が小さい多くのプログラムを前提とする、モジュール構造と相性が良いのは静的リンクの方だということです。

モジュール構造化による保守性とパフォーマンス向上は、現代の他の数多くのプログラム言語においても共通のものです。また、ILE RPG初期版によって、Javaなど他の言語とリンクすることも可能になりました。RPGはオープン化への一歩を踏み出したというわけです。

FF RPGの進化

ILE RPG初期版がプログラムの構造をオープン化したのであれば、FF RPGはプログラムの構文をオープン化したと言えるでしょう。ILE RPGの特徴、すなわちモジュール構造化と他言語との連携の容易性を引き継ぎながら、現代の他のプログラム言語に近い構文をサポートすることで、他言語経験者がIBM i のプログラミングに容易に参入できるようにすることが狙いです。背景にあるのは技術者、特にプログラマ不足への懸念です。

企業の基幹業務を支えるシステムにおいては、プログラムは改修されながらも長期的に利用されます。ここで資産継承性のメリットが活かされるわけですが、アプリケーションを保守する技術者の世代交代もスムーズでなくてはなりません。企業はRPG技術者を募集しても、将来を担ってくれるはずの若年技術者はなかなか集まらず、見つかったとしてもベテランしかいない、とよく聞きます。システムとしていかに優れていたとしても、この問題を放置すればIBM i 離れを加速しかねません。

プログラム言語の人気動向は様々なサイトで紹介されています。例えば当文書執筆時点（2024年11月）でオランダTIOBE社サイトではトップ3はPython、C++、Java、日本の日経XTECHでは同様にPython、JavaScript、Javaと続きます。旧来のRPG/400にせよILE RPG初期版にせよ、これら言語とは似ても似つかないものでしたが、FF RPGはこれらのオープンな言語と親和性が高いとされています。

もう少し細かく見てみましょう。言語が違えば仕様は異なるのですが、これら人気プログラム言語の構文には共通性があります。インデント、すなわち桁ずらしによる表記によって、条件分岐や繰り返し演算などのプログラムの実行順序が一目瞭然となり、関数を多用することで、サブ・プログラムの存在と戻り値の扱いがわかり易くなることです。この共通性はFF RPGにもそのまま当てはまります。FF RPGを手掛けた方からは、Pythonに近かったとか、C#のスキルが活かせた、といったコメントが聞かれます。逆に特にRPG/400経験者の方は、FF RPGに違和感を覚える方が多いようにも思います。FF RPGは旧来のRPGプログラマよりも、むしろ未経験者に優しい言語なのかもしれません。

では実際にどのくらいの習得期間を見込むべきなのでしょうか。他言語の経験はあるけれども、IBM i のプログラミングは初めてという方の事例は、既に何件か報告されています。整備されている教育体制などにも依存するので幅はありますが、概ね数週間から3カ月程度の範囲内に収まっているようです。私達は技術者の年齢層に着目しがちなのですが、むしろ他言語経験の有無の方が重要だった、とコメントしたユーザーもいます。いずれにせよ、将来ある方によるアプリケーション開発と保守を目指すのであれば、そして資産継承性というメリットを享受し続けるのであれば、IBM i においてはFF RPG一択と表現しても過言ではないと思います。

米ミネソタ州ロチェスターにあるIBM i 開発部門の方に、IBM i のアプリケーション開発を行う際に、何も前提条件を考慮する必要が無かったら、どのプログラム言語を推奨するか、と直接質問を投げかけたことがあります。答えは単純明快、FF RPGでした。

複数世代RPGの共存

これまでRPGの世代毎の進化を見てきたわけですが、一連の動きは「オープン化」という言葉で括れるのではないかと思います。そしてもちろんRPGファミリの一員である以上は資産継承性も維持されますし、RPG/400からILE RPG初期版、さらにFF RPGへと移行するツールも整備されています。

ツールの変換率は必ずしも100%ではありませんし、変換したところでテスト不要を保証しているわけでもありません。また手間暇かけてようやく変換したところで、直ちに何か新しい機能が利用可能になるわけでもありません。それでも何故FF RPGに移行した方が有利なのか、理由は将来にわたる人材確保と資産継承性、そして他の言語に移行するよりもはるかに少なくて済む作業負荷だと言えるでしょう。

ただ、それなりの作業負荷はかかるので、全てのユーザーが直ちにFF RPGへと移行できるわけではありません。当面は旧来のRPGとFF RPGとを共存させるのが、現実的な策なのだと考えています。幸いなことに、IBM i では複数世代のRPGを共存・連携させることができます。既存プログラムの改修の都度、または新規要件に対応するための開発の都度、FF RPGを採用し、少しずつでもその割合を増やしてゆく、という考え方です。実際にFF RPG採用事例を見てみると、複数世代の共存によるものが大半を占めています。当面は旧来のRPGを保守するベテランと、FF RPGの新規開発を行う若年層が共存し連携する、長期的にはベテランの引退を見据えながら、FF RPGへの全面移行を計画する、というのが現実的な策なのだと考えています。