フリーフォームRPGを使う５つの理由とは？

RPG IVの公開後の2001年、フリーフォームRPGのロジックが導入されました。とはいえ、フリーフォームで宣言ができるようになったのは2012年とつい最近のこと。さらにすべてのカラムが使用でき、「すべてのカラム」が何を意味するか（つまり、あなたのRPGスペックにカラムがいくつあるのか）すら定義できるような完全なフリーフォームが達成されたのは2015年のことです。そのため、今でも多くの固定長フォーマットのソースコードを目にしますし、フリーフォームの波に飛び乗ることに対してまだあまり熱心ではない多くのRPG使いの声も耳にします。その「理由」とは以下のようなものです。

• 「必要性を感じないから。今のままで問題ないし」
• 「固定長フォーマットのコードの方が読みやすいから」
• 「フリーフォームでロジックを作ってもいいけど、フリーフォームで宣言するとSEUが壊れてしまうから」
• 「フリーフォーマットにしようにも既存のプログラムがあまりにもたくさんあるから」
• （非常に残念だけど）「うちのマネジャーに理解がなくてそうさせてくれないから」

こうした否定的な声を真摯に受け止め、今回の記事ではフリーフォームRPGの主な優位性を解説していきます。ちなみに少しネタバレとなりますが、最も重要な事は一番最後に書かれていますので結論をすぐに知りたい方は最後をご覧ください。

1）インデントされたコードは読みやすい

フリーフォーマットでロジックを書けば、ステートメントをインデントしてコードの構造を示すことができます。ですから、入れ子になったIf文やSelect/When文のような込み入った論理ブロックを含む場合や、モニターブロック、入れ子やオーバーレイが用いられている複雑なデータ構造を含む場合には、コードがより簡単に理解できるようになるのです。 なぜコードの読みやすさが重要なのでしょうか。だって、コードを書くのが難しいとしても、コードを読むことまで難しくする必要はないですよね？コードが読みやすいほど、理解も簡単になります。書かれたコードが理解できればそれをすばやく変更でき、変更によってエラーが生じる可能性も低くなります。 でも、こんな声が聞こえてきそうです。 「インデントは必須じゃないし、もっと言えば、それを間違える可能性だってあるでしょ。その場合、さらに読み間違えやすくなって、インデントがない場合よりもずっと混乱するのでは？」 確かにそうかもしれません。そのため、最近のRDi（Rational Developer for i）では、RPGソースメンバーにある複数あるいはすべてのコードをフォーマット（または再フォーマット）してくれるという、素晴らしい機能が追加されました。インデントとして何個の空白を使用するかは設定で指定できます。これについては以下をお読みください。

http://www.ibmsystemsmag.com/ibmi/developer/rpg/rdi-v95/

2）ソースコードでより効率的にスペースを使用できる

RPG IV開発者のほとんどは、めったに演算項目1のカラムを使用しません。それだけでなく、私たちはもはや単純な算術演算子だけを用いるわけではありません。特に組み込み関数を含むような式の多くは非常に長く、その式を書き終えるために複数行が必要になることも多々あります。その結果、固定長フォーマットのコードでは、左側には無駄な大量のスペースがあるのに、右側は多数の複数行ステートメントでごちゃごちゃ、という状況が頻繁に発生します。フリーフォーマットのロジックを使えば、式のためにより多くのスペースを使えます。編集スクリーンはいわば「クリーナー」であり、私たちは一度により多くのロジックを見ることができます。なぜなら、複数行にする必要性が減るからです。もちろん、コードをより読みやすくするために、プログラマーが複数行の使用を選択した場合は別ですが。 フリーフォームの宣言を用いれば、スペースをより効率的に使用できます。これは、14文字のD仕様書カラムに入りきらない変数名を定義しようとした際などには特に有効です。確かに、省略記号（…）を使用して、次の行に書けば書けるのですが、それではスペースの無駄遣いで、不格好です。 私たちは、今ではフリーフォームの宣言を用いるようになったため、変数やプロシジャに、より長くて意味のある名前をつけるようになりました。これは別に意図して長い名前をつけようとしたわけではありません。これまでのように「ProcessCustomer」や「ErrorMsgDisplay」などの許容される省略形を考えたりしなくて済むようになったからなのです。かつてのようなおぞましい省略記号や、さらに醜悪な古いRPG形式での難解な短縮名は必要なくなったのです。

3）フリーフォーマットだけで使える新機能もある

さらに、フリーフォーマットのロジックだけで使える機能もあります。これは、実装の際にステートメント中に相当のスペースが必要な新機能だったりするので、旧来のRPGのようなカラム指向の言語では制限が生じてしまうためです。 私たちが気に入っている例として、CHAINあるいはSETLLでキーを特定するためのKLISTを、フリーフォーマット独自の形で置き換える２つの方法があります。１つは私たちがほぼすべての場面で使っている、命令コードに続くカッコの中に、変数名あるいはリテラルや式の形でキー値を提供するというやり方です。%KDSという、KLISTとよく似ているけれどもずっと柔軟な組み込み関数もあります。 もう１つの例として、UPDATE命令の影響範囲になるフィールドサブセットを特定する関数である%Fieldsの使用をあげておきましょう。これは、O仕様書をEXCEPT命令と一緒に使うよりもずっと簡単です。

4）コードを書くのと宣言を読むのが楽（特にファイルの）

正直言って、私たちはこれまでF仕様書が嫌いでした。各カラムの各文字が何を意味するのか、そしてどれが必要なのかを覚えておくことは苦痛で、手間のかかる作業です。Barbara Morris（IBMのRPGコンパイラー開発チームのリーダー）はかつて、F仕様書を読んだり書いたりするときには秘密の読解魔法が欲しくなると言っていました。ほとんどの場合、私たちはどのカラムにどの文字を入力すべきなのかを理解しようとするのではなく、F仕様書をどこか別のところからコピーして使っていたのです。しかしこの方法では、時として思いがけない結果が生じ、挙げ句の果てに長いデバッグ・セッションを経験することになります。コピーしたF仕様書に、私たちには必要のない、何らかの機能が指定されていたり、あるいは逆に必要なものが指定されていない場合があるためです。 でも、もうF仕様書のコピーなどしなくてもいいのです！ 今では、どんなファイルに対しても、意味のある必要なキーワードを簡単に定義することができるからです。さらに素晴らしいことに、すべてのキーワードをコードする必要はありません。キーワード値に合理的なデフォルト値があるおかげで、ファイルが外部に記述されているとか、プリンターファイルは出力のみ、などといったことをわざわざ指定する必要はないのです。 キーワードのおかげで、フリーフォームのファイル宣言を読むのはずっと簡単です。ファイルとデータの宣言を混在させられる（つまり、最初にファイルを宣言しておく必要がない）ので、ファイル宣言に関連したデータ宣言の特定がずっと簡単になるのです。なぜなら、例えばデータをREADやCHAINしたりするのに使われているDSやファイルのINFDS（情報データ構造）の定義などを、コード中にひとまとめに書いておくことができるからです。

５）RPGに新しいプログラマーを呼び込める

最後の理由ですが、だからといって重要度が低いというわけではありません。フリーフォーマットのコーディングにより、RPGは他の現代的なプログラミング言語と同じ土俵に立つことになりました。最新のプログラミング言語はすべてフリーフォーマットだからです。現在、あるいは今後システム開発の世界に参入してくる新しい開発者を呼び込むうえで、これは重要なことです。フリーフォーマット言語の世界では、旧来の固定長フォーマットRPGは単に奇妙なものとして映るため、RPGに対し、先進的なアプリケーションタスクには向かない古臭い言語という、不当な印象が持たれてしまいます。 しかしながら実のところRPGはパワフルで柔軟性のある言語です。興味さえ持ってもらえれば、若い開発者の多くがビジネスアプリケーション用の他の人気言語よりもRPGを好むようになるでしょう。ではRPGに興味を持ってもらうためにはどうすればよいのでしょうか。興味深いことに、RPGのようなビジネス指向言語の利点を理解した後であれば、古い固定長フォーマットコードを取り扱わせたとしても、ほとんどの人は問題を感じないということに私たちは気がつきました。これまでほとんどの場合、開発者たちはその真価を認識できるだけの時間をほとんど与えられないまま、この言語に引き合わせられてきたのです。 もしかしたら、RPG使いのあなたはこう考えているかもしれません。「新しい若い開発者たちがRPGに来たら、自分の仕事が脅かされるのでは？」私たちは複数のRPG開発会社の経営者と、使用言語を変更する可能性や、その過程でおそらくはIBM iからも引き上げる可能性について話をしたことがあります。それは単に、優れたRPG開発者を探すのがあまりにも難しく、また、見つかったとしても高くて雇えないからというのが理由でした。つまり、他の言語への移行を考えているのは、RPGで彼らのニーズが満たせないからではなく、エンジニアたちが退職年齢に近づいており、将来におけるアプリケーションの拡張や維持について懸念を持っているからなのです。結局のところ、RPGに新しい開発者を呼び込めなければ、あなたの仕事、そしてあなたのコード遺産に対し、より現実的な脅威が迫ってくることになるでしょう。 私たちは、RPG使いを探すのに苦労している開発会社に「RPGを使える人や経験者を探すのはやめなさい」とアドバイスしました。その代わり、どの言語でもいいのでビジネス指向に優れた開発者を探し、そして彼らにRPG（もちろんフリーフォーム形式で）とIBM iを教えることを勧めました。この問題に関して私たちの考えをもっと知りたいという方は、以下のブログの投稿をご覧ください。

http://www.ibmsystemsmag.com/Blogs/iDevelop/Archive/Programming-Highs-and-Tire-Lows/

フリーフォーマットRPGへの拒否反応は根拠なし？

幸いなことに、冒頭であげたフリーフォーマットRPGに対する疑念に対しては、明確に回答できたと思っています。まず「必要性を感じない」「固定長フォーマットのコードの方が読みやすい」という２点については、これまでの記述で答えは出ています。 「SEUが壊れる」問題に関しての私たちの考えは、おそらくあなたの予想通りでしょう。開発には絶対にRDiを使用するべきです。RDiではRPGの最新機能のすべてがサポートされていますし、将来的にもサポートされるはずだからです。SEUは、時がたつほど時代遅れになっていきます。 「既存のプログラムがあまりにもたくさんあるから多くののコードを変換しなければならない」、という問題について言えば、自分で書いたコードを手作業でフリーフォーマットに書き直すことはお勧めしません。私たちはフリーフォーマットRPGを愛してやみませんが、コードを手作業で変換することに時間をかける価値はほとんどありません。その代わり、すべては無理としても、ほとんどの書き換え作業には自動化ツールを使ってください。RDiエディターには、RPGロジック（ただしH、F、D、P仕様書以外）をフリーフォーマットに変換するオプションがあります。ただし、これでできるのは非常に初歩的な変換だけなので、あなたが本当に必要とするような自動変換は無理でしょう。ですから、あなたの手持ちのコードがすでにかなり最新の形式で書かれているのでない限り、この方法はお勧めしません。 作業の大部分を自動化してくれるツールは他にもあります。私たちが使ったことがあるのは、RPG Toolbox from Linoma Software（日本未発売）とArcad SoftwareのARCAD-Transformer RPGです。これら２つはどちらも、ロジックだけでなく宣言も変換してくれるオプションをサポートしています。そして、どちらにもRDi用のプラグインがあります。手作業する場合に比べてこれらのツールで節約できる時間を考えると、こうしたツールのコストパフォーマンスは非常に高いと言えます。商用ツールにお金を出したくないというのなら、クレイグ・ラトリッジのオープンソース変換ツールがいいでしょう。これはコマンドのコレクションで、ロジック（JCR5FREEコマンドを探してみてください）と、より最近のV7フリーフォーマット機能（「Free H F D」の下にあるコマンドのグループを探してみてください）の変換に使用することができます。RDi用のプラグインはなく、商用ツールを使用する場合に比べ、より多くの手作業が必要になりますが、無料というのは大きな魅力です。 では最後の難問。時代遅れのマネジャーへの説得についてはどうすればよいでしょうか。その対策として、この記事を彼（女）に読ませてみてはいかがでしょう？ 本記事は「IBM Systems Magazine」の許諾のもと、原文を日本語化するとともに、一部再編集したものとなります。原文をご覧になりたい方は下記よりアクセスしてください。 原文タイトル： 5 Reasons to Use Free-Format RPG 原文著者： Jon Paris, Susan Gantner