IBM i のウンチクを語ろう
～ その17：RPG言語は好きですか？ -3
皆さん、こんにちは。そしてあらためまして、今後共よろしくお願いいたします。
今回プロフィールを更新した事に気付かれましたでしょうか。37年以上にもわたるメーカーの立場から、ITの現場により近いところで活動を継続するべく、この11月1日付けで販売店に転職いたしました。初々しさはありませんが、入社1ヶ月にも満たない新入社員です。立場は違っても、できるだけ多くの方にIBM i のメリットをご理解いただきたい、との思いを新たに活動を継続いたします。もちろんこのコラムも継続です。
長年にわたって小刻みな改修を繰り返してきたために、最新の仕様がわからなくなってしまい、保守するのが困難になってしまっているアプリケーション・プログラム。RPGⅢに限らずどの言語を採用していたとしても発生し得る状況なのですが、プログラムがブラック・ボックス化してしまうと、何故か言語そのものが「犯人」扱いされる事もあります。前回はフリーフォームRPGの代表的な優位性をいくつか述べてまいりましたが、ソースコードレベルで見た言語の仕様は全く異なるため、既存のRPGⅢプログラムには当てはまりません。今回はこのRPGⅢプログラムにどう取り組めば良いのかを考えてみます。
RPGプログラムは長期にわたって利用できるというメリットがあるおかげで、仮に見直されることがあったとしても、修正範囲は限定的なものになる傾向があります。変更内容が都度きちんと仕様書に反映されていれば良いのですが、現実は必ずしもそうではありません。次第に改修にかかる手間、というよりもその前に、既存のつぎはぎだらけのプログラムを理解するのに要する時間が増えてきて、どこかで限界点に達してしまうこともあり得ます。人手ではこれ以上は保守できなくなってしまう、すなわちプログラムがブラック・ボックス化してしまうのです。
問題の本質は中身が見えないことにありますので、何とかして見えるようにすれば良いはずです。その目的に適うのが、プログラムの構造やデータベースとの結びつきを可視化するツールです。各社から様々な製品が販売されているのですが、例えばIBMからはARCAD Observerという製品が販売されています。プログラムの理解を促し、改修の際の影響分析を容易にすることで、プログラマの生産性を高める効果があります。さらにARCADシリーズ別製品のConverterを利用することで、RPGⅢからフリーフォームRPGへの自動変換を実現します。RPGでありながら、RPG未経験者をターゲットとした言語であり、IBM i に触れるのが初めての方にとっての心理的・技術的敷居を大きく引き下げます。
RPGを活用し続ける事ができそうな事はわかったとしても、おそらくその前に一歩踏みとどまって確認したい点があります。メーカーであるIBMは今後どのような方針で取り組もうとしているのか、このままRPGに投資し続けるにしても梯子を外されないだろうかという懸念です。
二回前のこのカラム「その15： RPG言語は好きですか？ -1」において、IBMの開発部門はRPGに対する投資を継続する意向であることを述べました。ここでもう少し踏み込んで、アプリケーション開発テクノロジーに関するロードマップを見てみましょう。このロードマップは三つの側面から構成されています。まずユーザー・インターフェース、そしてプログラム言語、最後に開発ツールです。
ユーザー・インターフェースの今後の主力はGUIです。具体的にはブラウザや、最近ですとAndroidやiOSなどのモバイル・デバイスもこれに含まれます。だからと言ってCUI、すなわちエミュレータ環境が消滅するわけではありません。利用シーンは限定的ではあるものの、大量のデータ入力などの場面において根強く使われますので、今後も継続的に投資がなされます。システム操作における直感性よりも、マウス操作を必要とせずに、キーボードだけで作業ができる生産性の高さは将来においても必須の環境です。
プログラム言語の今後という事では3通りの方向に投資がなされます。まずILE RPG（RPG Ⅳ）ないしILE COBOLです。旧来のRPGやCOBOLの新バージョンであり、特にフリーフォームRPGはロードマップにしたがって登場したRPG Ⅳの機能強化版です。メーカーとしてRPGやCOBOLの出荷やサポートを止める事は無いし、今後も機能強化を継続します。 次にILE RPGないしILE COBOLと、Javaやオープンソース言語との組み合わせです。一見ややこしそうですが、あらゆる需要に効率良く応えられる万能のプログラム言語は存在しない、というのが現実です。例えばブラウザから利用できる商取引アプリケーションを考えてみましょう。機能的にはWebアプリケーション・サーバーと、販売管理プログラムで構成されると考えることができます。人が触れるフロント側機能には直感性が求められるのでGUIが必須であり、JavaやPHP、Rubyなどといった言語が好まれます。一方背後のプログラムに対する要件は異なっており、長期的・安定的に使える事の方が重要です。そうなると資産継承性を発揮できるRPGやCOBOLに分があります。そして両者の独立性を保ちながら、それぞれの長所を組み合わせた、ハイブリッド型のアプリケーションを構築するのが良さそうです。 3点目としてJavaやJVMに継続的に投資を行って最新バージョンに追随させてゆく、という方針が定められています。
開発ツールについてはEclipseテクノロジー、具体的製品名で言うとRational Developer for i に継続的な投資を行います。Eclipseは元々Javaアプリケーション開発プラットフォームとして登場したオープンソース製品なのですが、プラグイン・モジュールを追加することで様々なプログラム言語に対応できる柔軟性を持っています。EclipseにRPGやCOBOL、さらにはCLなどのモジュールを追加しパッケージングしたのがこのRational製品です。必要に応じてIBMのGUI化ツールであるHATS（Host Access Transformation Services）をプラグインとして追加すれば、プログラミングからGUI設計までの作業を単一のEclipse環境上で実施できるようになります。
これらを組み合わせれば、Eclipseでアプリケーション開発と画面設計を行い、ブラウザで利用することが可能になります。表面的にはいわゆるオープン系サーバーが実現していることと何ら変わりはありません。唯一違うのは、プログラムがRPGやCOBOLなどの資産継承性のある言語で記述されている、という点です。
念のためではありますが、旧来のRPG Ⅲやエミュレータを前提とした、PDMという開発ツールに対する機能強化は最早行われません。2008年のバージョン6.1のタイミングが最後でした。今後は現行機能はそのままに、最新のIBM i バージョンと共に出荷され、サポートが提供されます。
ロードマップとして主張しているのは、従来のアプリケーション資産を守りながら、新しいオープンなテクノロジーを取り込むという方向性です。これは過去から将来に至るまでの、IBM i の機能強化全体を貫いている考え方そのものです。おおよそ現存するシステムで発展しない製品はありません。その中でも旧来のシステム資産を犠牲にするのか保護するのか、という製品の戦略に大きな違いがあるのです。システム資産の犠牲を伴いながら発展するシステムは新しさが目立ちますが、IBM i はそうではありません。個人の趣味とは違う、業務用システムであるという前提に立って、単なる見栄えやイメージにとらわれずに、冷静かつ長期的にそれぞれのシステム計画を立案いただきたいと思います。ではまた
