IBM i のウンチクを語ろう
～ その15：RPG言語は好きですか？ -1
皆さん、こんにちは。これまで何回かに分けて、オープンであることに対する世間の理解のあやふやさや、IBM i が追求するオープン性、その中でもPASEテクノロジーの重要性について述べてまいりました。アプリケーションを開発する際のテクノロジーとして、IBM i は幅広い選択肢を提供している事はご理解いただけたものと思います。新規開発の際には良いのですが、既にできあがってしまっているアプリケーション・プログラムにおいて、豊富な機能を活かすことはできるのでしょうか。資産継承性ゆえにアプリケーションが長い間全く見直されるが事なく、気が付いたらどのようにして改修すれば良いのかがわからなくなってしまう、旧来のプログラムは書き換えをしない限り、このまま塩漬け状態、すなわち過去の遺産であり将来に対する負債になってしまうかもしれない、そう感じられている方も多いかも知れません。このような負の側面を取り上げることで、IBM i の将来に対する不安を煽ろうとするケースもあるようです。他のサーバーであれば、置き換え時に「強制的に」見直すことになるのでアプリケーションは比較的新鮮に保たれる、という論法です。自動車を持たなければ歩かざるを得ないので体力が充実する、といった類の説にどのくらいの方が賛同するのか怪しいものではありますが。
このシリーズを通じて考えたいのは、既存のRPGプログラムをどうすれば良いのか、というテーマです。同じレガシー系言語として、便宜上COBOLもここに含まれるものとして話を進めます。選択肢として用意されているのは、RPGプログラムを破棄して他の言語に置き換えるというRPGからの完全離脱、資産継承性を活かして何もせずにRPGプログラムのまま現状維持、もしくはこれらの中間的な何かの策、のいずれかしかありません。これらの中で、どのように考えてそれぞれの事情に合った最適解を見出せば良いのか、という点を議論してまいります。なお予めお断りですが、ここには唯一の絶対的な模範解答はありません。ですが、リスクや作業量の大小を認識し、ユーザーの全般的傾向を知る事ができれば、今後の方針は立てやすくなるはずです。
今でこそ大分鳴りを潜めておりますが、IT業界がJava一色に染まっていたと言っても過言ではない時期がありました。当初はWebアプリケーション・サーバーなど基幹業務以外の領域、今で言うところのSoEにおいて採用されるケースが多かったのですが、その後EJB（Enterprise Java Beans）など様々なテクノロジーが登場することで、基幹業務（SoR）においても採用例が増えて大きく躍進しました。Javaこそがプログラム言語としての理想を追求したものであり、コンパイル済みアプリケーションがあらゆるプラットフォーム上でそのまま稼動する、というコンセプトが市場に広く受け入れられたのでしょう。今では信じ難い事かも知れませんが、IBM自身もRPGはいずれJavaないしEJBを基盤とするプログラムに置き換わってゆくであろう、と予想しておりました。
しかしながら2000年代半ばには、IBMはプログラム言語への開発投資に関するロードマップを軌道修正し、RPGの行く末はJavaに置き換わるのではなく、投資を継続することで、RPGには永続性がある事を明確に主張するようになりました。Javaそのものにおける技術的な欠陥や限界が発覚したわけではありません。IT業界がほぼJava一色だったにも関わらず、ほとんどのユーザーはRPGからJavaへと動くことはなかったのです。特にRPGなどによる基幹業務用アプリケーション・プログラムの書き換えには、極めて大きなワークロードとリスクを伴うことを理解していたからでしょう。私自身が見聞きする範囲に限っても、無理にブームに便乗しようとしたユーザーの中には、不幸にもいくつかの失敗事例があります。
言語変換作業の効率を上げるためのツールであるコンバータも存在しましたが、決定打とはなりませんでした。基幹業務において実用に供するためには、あらゆるプログラム・ロジックを通過するテストを実施しなければならないのですが、コンバータを利用したところでその負荷を免れる事はできません。さらに変換後のプログラムにも課題がありました。RPGは手続き型言語、Javaはオブジェクト指向型言語、と両者は異質の言語カテゴリに属しています。RPGをJavaに変換すると、プログラムとしては機能したとしても、生成されるのは限りなく手続き型に近い、Javaの特徴を度外視した「異様な」コードだったので、Javaプログラマーが保守できないという問題に直面しました。プログラムの保守・改修を行うために、いちいち変換前のRPGに立ち返らなければならないのでは、手間をかけてJavaに変換する意義はありません。
およそ機械的に生成されたプログラム・コードを人手で保守するのは困難である、というのは経験的に真理と言えるのではないかと思います。変換であれ、新規であれ、機械生成プログラムについては、保守・改修機能をも包含したツールを採用する、というのが現実的な対応でしょう。言語のレベルではなく、それよりも上位のツールの枠組みの中でプログラムを保守してゆく、という考え方であり、従来からあるいわゆる4GL製品はこの考え方でユーザーをサポートしています。
ツールに「全て」を委ねて、アプリケーション開発と保守の効率を高める、というメリットがある反面で、特定ベンダーの特定製品の環境に囲い込まれる、という考え方を嫌うユーザーもいます。このあたりはそれぞれのポリシーなのでこうでなければならない、というものはありません。ただ特定メーカーに囲い込まれることを避けるためにオープン系サーバーを採用しておきながら、統合型のアプリケーション開発ツールを採用しそれに囲い込まれていたりするケースがあったりと、ポリシーなるものも結構怪しいケースもあるようです。
結局のところ、RPGを別の言語に書き換えるのは、割の合う作業ではなさそうです。だからと言って現状維持のままとするのも進歩がありません。何か良い中間策はないものか、次回はこのあたりを探ってみる予定です。ではまた。
