RPGを凌ぐ-モダンRPG
変化することは重要です。IBMが15年前にRPG/400の機能強化を止めてからコンピュータの世界で起こってきた変化の規模を、思い起こしてみてください。今日ではすっかり違った世界になってしまっています。RPGという言語に対する批判は前世紀のRPGに向けられるべきものですが、それにはRPG/400も含まれ、さらにRPG/400と同じスタイルで記述されているRPG IVも含まれます。今あなたが書いているコードが10年前に書いたコードに非常に似ているのであれば、考え直す時期が来ています。RPG IV言語は、i5/OSの新しいバージョンがリリースされるたびに重要な機能強化が行われており、IBMはRPG IV言語を常に最新の状態にするために大変な努力をしてきました。モジュール性が高く、結合しやすく、適度にカプセル化されたコードを、今日のRPGで書くことができます。言語自体は時代遅れになったわけではありません。言語を使用している開発者が、時代遅れになっているのです。RPGが問題なのではなく、ぬるま湯につかっている開発者が問題なのです。
ビジネス指向アプリケーションの価値は、それを記述するのに使用した言語で決まるのではなく、そのアプリケーションを使用するユーザーが達成できるビジネス目標で決まります。私は20以上のプログラミング言語(Java、PHP、その他さまざまなMicrosoftの言語)でアプリケーションを記述してきましたが、こうした言語は高水準ではあまり大差がないということがわかりました。文法はそれぞれ異なるかも知れませんが、プログラムを開発するのに必要な基本的概念というものは同じですから、使用する言語の選択は専門性の違いということになります。それでもやはり、ビジネス・ルールを記述する言語としてRPGが明らかに一番適していると私は思っている、ということを付け加えておきましょう。ビジネス言語で必要な、一番基本的な中核となる部分について整理してみましょう。
- データベース・アクセス
- 10進数に基づいた計算 (個数、重量、通貨)
- 日付に基づいた計算 (期限、出荷日、支払日、など)
- 文字列の操作
- 機敏性 (ビジネスの変化に伴う変更)
RPGは、データベースへのアクセスという意味で、常に他より優れた機能を提供しています。RPGのネイティブ・レコードI/Oは、業界で他に肩を並べるものはありません。SQLのサポートもしっかりしており、使いやすく、しかも強力です。
10進数については、10進数と浮動小数点の違いを認識しておくことが大切です。浮動小数点数は小数値を格納することができますが、その格納方法は真の意味での10進数の格納方法とは大きく異なります。浮動小数点数は、2進数の有理数と2進数の指数として格納されます。数値を有理数と指数に換算するたびに丸め誤差が発生する可能性があり、特に数値が大きくなればなるほど、その可能性は高くなります。特定のアプリケーションにおいては、浮動小数点は大きな価値を提供するものではありますが、ビジネスにおいては真の意味での10進数の精度が重要となります。RPGはパック10進数タイプとゾーン10進数タイプを提供することで、常に真の意味での10進数演算をサポートしてきました。V3R1では、式が導入されてこうした10進数を使用する際のややこしさが劇的に低減されました。あなたがまだADD、SUB、MULT、DIVなどといった古いオプコードを使用しているのであれば、損をしているといえるでしょう。
同じリリース(V3R1)では日付、時刻、タイムスタンプが導入され、文字列操作も改善されました。RPG/400の文字列操作は恐ろしいほど使いづらいものでしたが、RPG IVでそれが変わりました。文字列操作は、日付や式と同様に、V5R1でフリーフォーマットの文法が導入され、さらに強化されました。ただひとつ、最後の問題として残っているのは、自分たちのスキルを最新の状態に保っていない人たちは役に立たなくなるということです。ILEの概念を使用して、適度にカプセル化されたルーチンを結合しやすいサービス・プログラムに分解して作成する方法を理解しなければ、ビジネスの変化に伴って更新するのがとても困難なコードを作成してしまうことになるでしょう。適度なカプセル化とは、ビジネスの変化に伴って変更する必要のあるコードの量を単に少なくするだけではありません。カプセル化を適切に行えば、何を変更する必要があるのかを特定するのに必要な分析量も少なくしてくれるのです。モダンRPGコードを書くためには、サブプロシージャを使用してコードをカプセル化する方法を習得することが、おそらく最も重要なことではないでしょうか。
競争
Javaはこうした中核となる概念を全てサポートしていますが、RPGとはそのサポートの仕方が異なります。Javaでは、10進数、文字列、日付は基本データ・タイプではなく、クラスとして実装されており、こうしたデータを操作するにはそれぞれのクラスで定義されているメソッドを呼び出す必要があります。もちろん完璧に動作しますが、モダンRPGよりも手間がかかるのです。データベースへのアクセスに関してはさらに手間がかかります。JDBCは強力なツールではありますが、複雑で使いづらいツールとなる場合もあります。Javaでデータベースにアクセスする必要のあるコードを見てみると、CのSQL呼び出しレベル・インタフェース(CLI : Call Level Interface)を使用するのととてもよく似ています。CLI はほとんどのPC用プログラミング言語においてデータベースのタスクを実行するための標準的な方法であるため、これは特段驚くべきことではありません。しかし、データベースがシステムに深く統合されていることに慣れているRPGのプログラマにとっては、CLI は使いづらいものです。RPGのデータベース･アクセスの方がJavaよりも比べものにならないくらい優っています。実は、Javaはビジネス用の言語としてではなく、汎用目的のプログラミング言語として設計されたものなのです。
i5/OSとの統合という観点で言えば、オペレーティング･システムとの強固な統合は重要です。使用しているプログラミング言語が他のシステムで動作するように設計されているとしたら、自分のシステムの強みをどのように生かせというのでしょう。私が書いたJavaプログラムが i5/OS上で動作するのと同じようにWindows上でも動作する場合、i5/OSの強みをどのように生かせるのでしょうか。あなたが使用している言語がどのシステムでも動作するように設計されているとしたら、結局のところは「最小公倍数」に落ち着いてしまい、どのシステムでも利用できる機能しか使用できないことになります。何らかの機能を提供するのに、あるオペレーティング･システムが他のオペレーティング・システムに比べてより革新的な方法を提供しているとしたら、その革新的な方法をあきらめなければなりません。そうしないとクロス・プラットフォームのプログラムを作成できないからです。RPGは 5/OS用に磨き上げられていますが、Javaはそうではありません。
確かにIBMは、i5/OS上でJavaを使用できるように全く新しいコマンド･ライン環境(QShell)を構築しなければなりませんでした。またIBMは、大量のクラス(Java Toolbox/400)を開発しなければならなかったにもかかわらず、それでもなおJavaは、エラー・メッセージをジョブ・ログに送信するなどといったシステムの中核となる機能をサポートしていないのです。また、システム上で動作する他の言語にくらべてパフォーマンスが劣ります。実際のところ、IBMが最終的にJVMをネイティブの環境からPASE環境(ここではJVMは i5/OSのプログラムではなくAIXのプログラムとして動作する)に移すまでは、Javaのパフォーマンスは小規模の企業では使用に耐えないものでした。JavaをPASE環境で実行させるのは理に適っています。というのは、結局のところ、JavaはUnixを指向する企業であるSunが設計したからです。Javaを i5/OS下で動作させるのは、丸い穴に四角い杭を打ち込もうとするようなものです。その杭を引き抜こうとしているIBMには脱帽ですが。杭を引き抜くにはかなりのエンジニアリングが必要でした。
PHPがSystem i に関係したのはほんの短い間でしたが、それに興味を示した人は多数いました。RPGの文字列操作が優れたものであれば、PHPでも同様でしょう。PHPは私が今まで見た中で、おそらくPerl (PHPを使用する開発者に大きな影響を与えた)に次ぐ、最高の文字列処理機能を備えています。しかしながら、10進数演算やデータベース・アクセスはPHPではあまり強力ではありません。PHPは実際のところ、ウェブ・アプリケーションを開発するという単一の目的のために設計されているのです。PHPはその点では優れているのですが、ビジネス・ルールを記述することにおいてはRPGほどではありません。
あるコラムでドン・デノンコート氏は、PHPやEGLなどといったRPGの代替えとなるものを専門家が推奨していると述べています。おそらく同氏は誇張しているのではないかと私は思います。専門家の多くはPHPやEGLを"代替え"としてではなく、RPGと"組み合わせて"使用するツールとして推奨しているのです。
それぞれの仕事に最適のツールを使いませんか
RPGを"あらゆること"に使用するのはよくない、仕事に適したツールを使用すべきだ、と言う人がたくさんいます。ある程度は、私もこれに賛成です。ただし私の環境では、目的ごとに異なるツールを使用するのは現実的ではありません。私の部署にはIT用スタッフとして3人の社員がいます。この規模のスタッフでは、各プログラマはあらゆる業務について対処できる必要があります。RPG、Java、C、Cobol、Rexx、PHP、ヘルプ・デスク、PCサポート、ネットワーキングなどに、個別のチームを抱える余裕はありません。私は彼らを「プログラマ」、「アナリスト」と呼んでいますが、誰か一人が休暇を取ったり病気になったりすれば他の人がカバーしなければならないので、会社が必要とするあらゆるIT業務をサポートできなければなりません。スタッフそれぞれが専門性を身に付けるべきテクノロジーの数を限定することは理に適っています。全ての開発をRPGで実施したとしても、ITスタッフは依然として、RPGプログラムの開発保守業務の他に、Windowsデスクトップが正しく動作するようにしたり、i5/OSをインストール/保守したり、ネットワークの設定や保守をしたり、などといった業務に責任があることには変わりがないのです。地球上の全てのプログラミング言語を学習する必要がなくても、「仕事に最適なツールを使用する」と判断したことで学習曲線は急勾配なのです。
しかし一方で、他のツールを使用することも意味があるという意見には私も賛成です。もはや、1つのプラットフォーム上で1つの言語で何もかも事足りるという世界ではないのです。しかし、IT環境があまりに複雑すぎると新しい社員を迎えたときに教えることができなくなるので、使用するテクノロジーの数を最小限に保つことは賢明だといえます。私は、RPGからJavaのクラスを使用してExcelのスプレッドシートを作成したり読み込んだり、外部のデータベースにアクセスしたり、グラフを作成したりする方法についていろいろと記述してきましたし、その能力を日々の仕事に応用しています。
しかし、RPGだけによるソリューションが存在しないか、または他の方法に比べて著しく困難である場合にのみ、そうしています。ソケットやストリーム・ファイルが、他の言語に比べてRPGの場合に特段難しいわけではありません。XMLやウェブ開発などについては、それらをどう使うかによるでしょう。XML-INTOオプコードはV5R4でRPG言語に追加されましたが、その簡素さに近いXMLツールはどの言語においてもまだ見たことはありません。
しかしながら、より複雑なXMLの機能を使用する必要がある場合は、こうした簡素なツールでは役に立たないことがおわかりになるでしょう。これはウェブ開発についても同様です。CGIDEV2ツールキットでは、熟練したRPGプログラマであればウェブ・アプリケーションをRPGで1週間以内に記述できるようになりますが、ウェブ・アプリケーションがもっと複雑になると、必要な機能が全て揃っているわけではないことに気づくでしょう。RPGは他の言語との親和性がとても良いので、非常に複雑なアプリケーションを構築する必要がある場合は、いつでも他の言語と組み合わせることができます。
RPGは、CL、Cobol、C、Javaで記述されたルーチンを簡単に呼び出すことができます。実際デノンコート氏は、私がCをベースにしたAPI を使用してさまざまなことをやっているのを見て、モダンなシステムに求められていることをRPGでこなそうと思ったら、Cのプログラマになる必要がある、と述べています。しかし、プロトタイプを記述してしまえば(あるいは、私が記述したプログラムをダウンロードしてしまえば)、Cの知識はほとんど必要ないことがおわかりになると思います。確かに、基本的な事項はいくつか理解しておく必要がありますが、だいたいにおいては、CのAPI を呼び出すことはRPGのサブプロシージャを呼び出すのと何ら違いがありません。その時の学習曲線は、Javaを習得するのに必要なときの学習曲線とは比較にならないでしょう。
前述の通り、私は数多くのプログラミング言語を使用してきましたが、Javaが間違いなく一番習得するのに苦労した言語です。CのAPI をRPGから使用するということは、Cを習得しなければならないということではなく、Cをベースとした概念をいくつか知っておく必要がある、というだけのことです。それを、Javaを習得することと比べるのは、紙飛行機とスペース・シャトルを比べるようなものです。
本稿でもう少し紙面があれば(実際にはないのですが)、同じこと(たとえばXML、ストリーム・ファイル、ストアード・プロシージャ呼び出しなど)を処理するJavaとRPGのコード例を、横に並べてご説明したいところなのですが。そうすれば、Javaに比べてRPGも難しくないということがはっきりおわかりいただけると思います。実際、そんなに大きな違いはないのですから。
しかし、問題を取り違えないように注意が必要です。ストリーム・ファイルやソケットはビジネス機能の中核をなすものではありません。本当の中核機能に対しては、RPGが依然として適切なツールといえます。
でもASCIIは出力してくれない
デノンコート氏の記事では、ASCII を出力する必要がある場合、それはRPGでは難しいということを示唆しています。本当の意味でのモダン・アプリケーションではASCIIではなくUnicodeが使用されている、ということを指摘しておきたいと思います。UnicodeはRPGがネイティブでサポートしており、他の文字列と同様に使いやすくなっています。ただしASCII を出力する必要がある場合は、通常オペレーティング・システムがその変換を行います。たとえばウェブ・アプリケーションでは、HTTPサーバーがEBCDICをASCII に変換してくれます。これはRPGに限らず、他の言語でも同様です。IFSのAPI についても同じです。IFSのAPI は文字セットの変換を非常に容易にしてくれます。これはJavaの場合と同じです。
多重人格障害
デノンコート氏は記事で、RPGは多重人格であると述べていますが、その点については私も同じ意見です。ただし、この特徴は財産であると私は思っているのですが、デノンコート氏は明らかに全く反対に感じています。アプリケーションの開発に時間と労力を投資する際は、その投資を保護しようとするでしょう。これは古いテクノロジーにずっとこだわるべきだということではありません。そうではなくて、MicrosoftやSunの経営幹部が互換性を保てなくてもいいと判断したから変える、というのではなく、"ビジネスの観点から見て"変化が意味を持つまでそのテクノロジーにこだわるべきだ、ということなのです。
1993年当時Visual Basic 3.0でソフトウェアを開発していた人は、自分が当時書いたコードを未だに最新のVB.NETで稼動させることができません。かなり修正を加えてテストをやり直さなければならないからです。これとは対照的に、同じ1993年に書かれたRPG/400のプログラムを持ってきて、CVTRPGSRCコマンドにかけ、ILE RPG/400のネイティブ・アプリケーションとしてコンパイルし、全く問題なく動作させることができます。
これを理解していない人が結構たくさんいます。RPG/400 (AS/400用のRPG III )にかなり投資した人でさえも、RPG/400のコードをCVTRPGSRCコマンドでRPG IVにすばやく変換して、RPG IVのネイティブ・コードを生成することができます。コードを書き直す必要はありませんし、修正する必要もありません。ツールを使って変換するだけです。確かに、RPG III の特徴が残っているでしょうし、それは理想的ではないですが、少なくともコードをRPG III のコードとして永遠に維持しなくてもいいのです。
IBMは、RPG IIIの機能と同じ機能をRPG IVでも提供して、RPG III で記述したコードがRPG IVでも同様に動作するように多大な努力をしています。ただし、FREEオプコードのように、いくつか細かな例外があります。(率直に言って、FREEオプコードは正しく動作したことは一度もありません。このオプコードを使用している人のほとんどは、プログラムが終了するときにこのオプコードがファイルをオープンにしたままにしていることに気づいていませんでした。RCLRSCはファイルをクローズするとともにプログラムをメモリから取り外しますので、FREEオプコードを使用する理由はほとんど見当たらず、例外があったとしてもそれはアクティベーション・グループで処理できます。)
古いコードを変換することは、コードをモダンなシステムに合わせるための作業としていちばん簡単に始められる方法です。こうすることで、古くて時代遅れになったRPG III言語から脱却して、モダンな機能をコードに付け加える作業を始められる環境を使用できるようになります。ただしこれは、モダン化への道のりの最初の一歩に過ぎません。
次に、既存のコードのリファクタリングを行って、もう少しモダンなコードにしなければなりません。これを行うためのツールを探そうとしてはいけません。RPGを使い続けるにしても、既存のコードをJavaや他のプラットフォームに変換するとしても、あまり変わりはありません。ビジネス・ロジックを再考するのをサポートしてくれるほど、ツールは賢くありません。プログラマとしての知能に頼ってコードをリファクタリングし、よりモダンなコードにする必要があります。
RPGを使い続ける利点は、コードのモダン化を徐々に進めることができるという点です。RPG IVへの変換をすぐに行い、そこからゆっくりと、しかも確実に、既存のプログラムをよりモダンなRPGの「人格」に変換していくことが可能です。RPGであることには変わりがないので、他の言語に乗り換えた場合に比べて、学習曲線の勾配はずっと緩やかです。それでも習得すべきことはたくさんあり、アプリケーションの設計の考え方を変える必要はありますが、他の提供源から生まれてきた異なる言語を習得するよりはずっと容易に対処できる変化です。
RPGにはいろいろな人格がたくさんある点については、私も同感であると前述しました。実際のところ、デノンコート氏の記事では、いくつかの人格が省略されています。
V3R2では、RPGにサブプロシージャが与えられていましたので、複数の呼び出し可能なルーチンを持ったモジュールを記述することが可能でした。またプロトタイプを提供していたので、そうしたルーチン用の明確なインタフェースを記述することはかなり容易になり、コードを適度にカプセル化することが可能です。この段階を経て、RPG IVでは全く新しい人格が生まれました。つまりサービス指向のアプリケーションです。全てのビジネス・ルールを、システム上の他の全てのILEプログラムが(「サービス」として)利用できる一連のプロシージャとして設計ができるようになったのです。
さらにもっと最近では、ウェブ・サービスと外部ストアード・プロシージャが登場し、こうしたサービスを他のコンピュータ上にあっても構わないILE以外の言語にも提供できます。RPGのこの人格は、プログラムのほとんどがプロシージャの呼び出しで構成されており、モダンRPGプロジェクトにおいて目指すべき人格です。
モダンRPG
では、今後も生き残りを図るためには、RPGプログラムに取り入れていくことが重要なものは何でしょうか。私の考えでは、以下の重要な概念を確実に理解しておくことが必要です。
- サブプロシージャ
- プロトタイプ
- カプセル化 (サブプロシージャとプロトタイプを適切に使用する方法)
- 結合性 (どのプロシージャをどのモジュールやサービス・プログラムにグループ化するか)
- MVC (最も重要。表示ロジックとビジネス・ロジックを混在させないこと)
- サービス指向 (ウェブ・サービスのことを説明していると誤解されたくないのでSOAとは言いたくないですが、SOAは「サービス指向アーキテクチャ(services-oriented architecture)」の略で、まさに私がここで述べたいのはこのことです。ビジネス・ルールを設計する際は、ユーザー・インタフェースが使用できるような再利用可能なビジネス・サービスの集合と理解するようにしてください。良いサービス・プログラムを書くということを意味しているだけです。ウェブ・サービスとして提供しなければならないということではありません。)
- ウェブ開発 (緑色画面の考え方はもうやめましょう。緑色画面を使用しなければならない状況でも、他のインタフェースを代替え案として提供するか、または将来まったく新たに書き直すのではなく、新しいインタフェースを追加することができるような方法でコードを記述すべきです。)
最終的にはあなたの判断です
究極的には、どのプログラミング言語を使用するかよりは、その言語をどのように使うかの方が重要です。あなたが開発するアプリケーションがビジネスの目的を達成できるようにすることが、どの言語で記述するかよりもずっと重要なのです。同様に、コードを適度にカプセル化することの方が、特定のプログラミング言語でコードを書くことよりもずっと重要です。RPGは、ビジネス・アプリケーションを記述するための言語としては、私の知る限り、最良の言語だと思います。もし同様なお考えをお持ちであれば、RPGでモダンなコードを書くことができると安心してください。そしてただ、確実に行動に移すだけでいいのです。前世紀のRPG/400の考え方から抜け出してください。
