RPGはIBM iの主要言語であり続け、Javaとの共存がIBM i を進化させる

　IBM iのモダナイゼーションとDevOps

フランスのARCAD Software社は、IBM iのモダナイゼーションとDevOpsをテーマに多彩なソリューションを展開しています。

たとえば既存のRPGプログラムを、オープン系プログラミング言語の構文によく似たフリーフォームRPG（FF RPG）へ自動変換する「ARCAD Transformer RPG」。あるいはIBM i上の情報資産を分析し、その構造や相関関係を見える化する「ARCAD Observer」。このほかにも、多彩なDevOpsソリューションをラインナップしています。

IBM iに必要なモダナイゼーションとDevOpsを語るうえで、ARCAD Software社は2つの言語を対比させています。1つは長い歴史のある手続き型言語、もう1つははるかに新しいオブジェクト指向言語、すなわちRPGとJavaです。

2つは対極の存在ですが、IBM iの世界ではRPGが主要言語であり続け、IBM iのモダナイゼーションやDevOpsを推進するには2つの言語の共存が欠かせないと指摘しています。そのアプローチをご紹介しましょう。

　RPGはIBM iの主要言語であり続ける

モダナイゼーションに対する典型的な反応の1つは、「RPGよりもはるかに汎用的で移植性の高い言語であるJavaですべてを書き直す」というものです。

IBM iを知らない人にとっては、至極もっともな選択に見えます。Javaで書き換えれば、2つの重要な課題が解決できると思い込みます。1つはIBM iからの脱出の準備、もう1つはRPGのスキル不足（もしくは人材不足）への解答です。

RPGとJavaはそれぞれ、最初から特定の技術環境に適応するように考案されました。 JavaはWebの登場とともに誕生し、そのニーズを満たすように設計されています。レガシーなビジネスアプリケーションが求める大量のバッチ処理など、Javaから見れば別世界の要件でしょう。

このことが、「RPG（つまりはFF RPG）が現在も、そしてこれからもずっと、IBM iの主要言語であり続ける」と考えられる理由です。

RPGはIBM iというプラットフォームで生まれたので、当然のことながらIBM iに最適化されています。

もちろんRPGはオープン系のあらゆる言語と共存する必要がありますが、IBM iとの緊密な連携と比類なきパフォーマンスを見れば、IBM iで開発されたビジネスアプリケーションにとってRPGは唯一無二の存在です。

　設計哲学が根本的に異なるJavaとRPG

自動変換ツールを使って、RPGプログラムをJavaにリプレースしようと試みた企業は多いですが、（かなり控えめな言い方をしても）芳しい成果は上がっていません。RPGのような手続き型言語を使用して記述されたアプリケーションを、Javaのようなオブジェクト指向言語に変換するのは困難です。

なぜなら、設計哲学が根本的に異なるからです。実際、この方法で変換されたコードを読んだJava開発者は、すべて同じ反応を示します。彼らは異口同音に、「これは実際にはJavaではない」と指摘します。それにもかかわらず、アプリケーションの実行環境としては、かなり高額なコストを費やさねばなりません。

　COBOLとRPGの違いは「進化」への姿勢

COBOLはメインフレームの標準言語です。50年以上にわたって開発された数十億行のソースコードが、世界最大の企業のコアシステムを支えています。

IBM iのRPGについても同じことが言えます。RPGは最もミッションクリティカルなビジネスアプリケーションを支える言語です。COBOLとRPGの唯一の違いは、開発されたコードの総量でしょう（RPGはIBM iでのみ使用可能なので）。

RPGは、IBM iで開発されたアプリケーションの85％以上を構成しています。RPGの障壁となっているのは、初期のRPGで使用されたあまり一般的ではない構文（固定フォーマット）です。これはほかの言語では使用されていないので、初心者がRPGを学ぶ際の障壁になります。その結果、若い世代の開発者をRPGから遠ざけ、IBM iの開発者が高齢化する一因になっています。

ビジネス指向言語と呼ぶべきCOBOLとRPGのもう1つの大きな違いは、「進化」です。 1974 年以降、構造があまり進化していないCOBOLに対して、RPGには強力な機能強化が実施されています。RPGがIBM iには不可欠と考えるIBMは、積極的にこの言語を改良してきました。

1995年には統合言語環境（ILE）が登場し、オブジェクト指向言語と同様のモジュール性と機能を搭載しました。

しかし最も大きな変革は、2003年に登場したFF RPGです。FF RPGの構文は、JavaやC＃などの言語とよく似ているので、オープン系の開発者にとってRPGの学習が容易になります（半日のeラーニングコースで十分に学習できます）。

そしてFF RPGのもう1つの大きな特徴は、IBM iというOSに密接に統合されていることです。これにより、開発者は他の言語では利用できない数々の機能を使用できます。もちろんFF RPGの実行はPower Systemsのマシンに最適化されているので、パフォーマンスは良好です。

　技術者の世代間ギャップを解消する

どうしても古くささが喚起されるので、RPGという名前を変えてはどうかとの議論もありました。しかし、FF RPGはどの世代にとってもバランスのよい名前であるという結論に落ち着きました。

若い世代の開発者が使いやすくするための機能改善は、ベテランにとっても役立ちます。世代間で共通の言語を共有することで、企業は多額のIT予算を無駄にしたり、経営的なリスクをもたらすような「テクノロジーの破綻」を回避できます。

皮肉なことに、これまでIBM iの最大の脅威であると考えられていたRPGという開発言語の独自性が逆に最大の資産となり、技術者の世代間ギャップを解消することになるのです。

　なぜJavaなのか？

今日でもJavaは、次々に登場する最新言語のターゲットにされていますが、それでも業界の標準であり続けています。ただしJavaの高いスキルレベルと開発生産性を獲得するには、人材への多額の投資、組織改革、開発プロセスの変更が必要です。これは多くの企業にとって、なかなか受け入れ準備の進まない大きなリスクです。

Javaは、Webアプリケーション（またはインターフェース）の開発という点で最善の努力を重ねていくでしょう。Javaがこの分野で今後も長きにわたり、見本とされ続けることは間違いありません。しかし果たしてJavaだけが、すべてのアプリケーション資産に対する唯一の標準なのでしょうか。

　優先すべきは言語ではない

RPG（最新のFF RPG）とJavaは相対する言語ではなく、互いを補完する言語です。それぞれが利点、スキルのある人材、エコシステムを保有しています。理想的な解決策は、双方の長所を活用するために2つの言語を共存させることです。

このための最適なアプローチは、DevOps戦略に投資することです。優れたDevOpsツールは、多様性のある人材を互いに比較して競わせるのではなく、自然な形で接近させます。 DevOpsを採用すれば、開発言語は変更・変化を管理する方法論ほど重要ではなくなります。

多くの新しい言語が次々に登場しており、それぞれが最新ニーズによく適合しています。レガシーシステムのモダナイゼーションで優先されるのは言語ではなく、開発を管理する手法です。一言で言えば、それがDevOpsなのです。

【モダナイゼーション、プログラム資産管理・継承、見える化、FFRPG、Web化、DevOps】
IBM iアプリケーションのモダナイゼーションを実現：ARCADシリーズ

三和コムテックIBM i向け製品一覧はこちら
三和コムテックIBMi向けソリューション一覧はこちら
IBM i ポータル資料ダウンロードはこちら