【第36回】RPGアプリケーションの将来を保証する7つの鍵 | IBM i 総合情報サイト

【第36回】RPGアプリケーションの将来を保証する7つの鍵


RPGアプリの将来を保証するということは、単に現行のRPGアプリが将来に渡って動作し続けることを保証することではありません。これは、時の経過と共に変化するビジネスルールやビジネスモデルに合わせ、迅速に必要な修正や機能追加ができるようにRPGプログラムの構造を変革することではじめて達成できることです。その鍵となる7つの基本方針についての解説記事をご紹介します。(編集部)

RPGの将来を保証するテクニックを実装することで、アプリケーションはもっと弾力的で維持管理したり、時と共に機能強化したりするのが容易なものになります。

09/01/2017 ジョン・パリス&スーザン・ガントナー

RPGの将来を保証する技法を実装することで、アプリケーションはより弾力的になるだけでなく、維持管理したり技術革新に遅れないように時と共に機能拡張したりするのが容易になります。将来を保証し損なったアプリケーションは古びてしまうリスクがあり、その結果会社は必然的に他のもっと能力の劣るプラットフォームに膨大な無駄金をつぎ込むことになります。

これらの話題は以前にも取り上げられてきましたし、その多くについて私達のiDevelopというブログで述べてきました。これらの重要な話題を一か所に集約すれば、読者諸氏の同僚や上司との議論の基盤が提供できるのではないかと期待しています。

以下で述べているのは、筆者がRPGの成功に重要だと感じている7つの要素です。このリストを1つずつ見て行く前に、1つのことを理解しておくことが重要です。それは、ここで概要を説明したすべての各項目に、現時点でチェックマークを付けられないとしても、それを失敗だと考えるべきではないということです。何もせず、現状を維持することが唯一の失敗への確かな道なのです。

1.現代的RPG技法を使用する

現代のRPG技法は、単にフリーフォームRPG構文を使うという域を超えています。以下に現代のRPG技法のチェックリストを示します。このリストは決してすべてを網羅しているわけではありませんが、よい取っ掛りではあります。これらの項目の幾つを実施済みですか?

  • すべてのRPG/400プログラムはRPG IV(いわゆるRPGLE)に変換済みである
  • 意味のある大文字、小文字交じりの名前を使っている(*訳注1)
  • そうせざるを得ない場合にだけ番号標識(注:01~99、*INxxなど)を使用し、次にそれらの標識に意味のある名前を付けている(*訳注2)
  • すべてのRPGプログラム(演算と宣言部分)をフリーフォームでコーディングしている
  • プログラムを構造化するためにプロシージャを使用している
  • 再利用可能なコンポーネント用にサービスプログラムを作成している

これらの項目のすべては、プログラムの可読性を高め、理解し易いものにします。このことは、プログラマーにとってだけでなく生産性の面でも重要です。というのも、理解し易いプログラムは、新しい機能拡張を加えたり問題の修正をしたりするときに、どこを変更するかがもっと明確になるからです。可読性はプログラムを維持管理し易いものにします。このことは、回り回ってプログラムの信頼性を高めます。なぜなら、変更を加えたときの誤りを一段と減らすからです。

RPG IVへの変換が済んでいることが、このモダナイゼーション・チェックリストの他のすべての項目の前提になります。悲しいかな、1994年以降RPG IVがずっと存在し続けているにもかかわらず、比較的少数の企業しかプログラムのすべてを変換し終わっていないことを私達は知っています。

それに続くチェックリストの2つの項目は名前(通常、標識を含む変数名)に関係しています。AccountBalanceと言う変数名はACCBALよりずっと明確ですし、CUSNMは実際のところCustomerNameなのか、はたまたCustomerNumberなのでしょうか。問題点は分かりましたか?暗号のような変数名に関して、間違った想定をするとしばしばエラーに繋がります。

(*IN47のような)標識番号は本質的に不明瞭な名前です。O仕様書やDDSの表示ファイルやプリンターファイルのように不可避である場合を除き、これらをRPGで使わないでください。その場合にも、ファイル宣言のINDDSサポート経由で意味のある名前、または*IN配列に対する添え字として名前付き定数を使うか、あるいは意味のある名前を与えるために*IN配列を再マップしてください。(*訳注2)

私達は以前このオンライン記事を含めて、フリーフォーム構文の重要性について取り上げ、その記事でフリーフォームRPGを使うべき5つの理由の正しさを論証しました。ネタバレ注意:(すべてでないにせよ)多くの理由が可読性に関係しています。

プロシージャは容易にサブルーチンを置き換えることができますし、パラメータ渡しと戻り値の受け取り、ローカルデータ、サービスプログラム経由による再利用のしやすさという付加的な利点を提供するので、RPGプログラムを構造化するための優れたツールです。

ここでまた可読性が顔を出します。日付値の曜日を決定するルーチンを呼び出す2つの可能な方法を見てください。

Exsr DayOfWeek;     v.s.        WeekDay = DayOfWeek(deliveryDate); 

どちらが起こっていることについてより多くの情報を提供するでしょう?プロシージャDayOfWeekの呼び出しは、ルーチンに対して何が入力として使われ、演算の結果が何処に格納されるかを教えてくれます。サブルーチンからその情報を得るためには、サブルーチンのロジックを詳細に調べる必要があり、これは時間が掛る上に潜在的に間違いを起こし易い作業です。

2.再利用可能な関数ライブラリを確立する

サブプロシージャを中心にしてアプリケーションを構成し始めるとすぐに、元々それ用に開発されたプログラムの外にユーティリティをもつルーチンを探すのが自然なことになります。明らかな候補には、住所の正当性を確認する、電話番号を整形する、電子メールを送信する、顧客検索を実行する、そして信用調査をするなどが含まれます。

このアプローチは多くの恩恵を生み出します(つまり、関数が1つの状況下で顧客番号の正しさを検証するといった所与の仕事を正確に実行するなら、その関数はすべての状況下で正確に動作するでしょう)。これは、1つのプログラムから別のプログラムにコードをコピーするよりもずっと良いことです。このコピーという慣習は多くの企業で標準になっているものの、複数のバージョンが独立に存在するという状況を生み出す可能性があります。その結果、この慣習は機能を追加したりバグを修正したりするのに時間が掛り、かつエラーを招きやすいプロセスになります。数年前、古いスタイルのRPGの維持管理に特有の収穫逓減の法則と格闘し続けているお客様がありました。そのお客様は、維持管理および対応が改善されることを期待して、最終的に主要アプリケーションの1つを再利用可能なコンポーネントを中心に再構築することを決定しました。

そのお客様は2つのことを発見しました。第1に、プログラマーは「ブラックボックス」を独立して完全にテストでき、コードの記憶が新しいうちにバグを修正できるので、新しいアプリケーションのテストは、もっと早く、広範で、問題の発生がより少ないということでした。第2に、プログラマーは、以前は不可能だった方法で新しい機能の要求に応えることができるということでした。この事実から1年後、新しい習慣の50%以上の時間が、古いシステムでは夢見ることのできなかったウェブサービスやその他の新たな機能を開発するのに使われているとこのお客様は報告しました。

3.Db2とSQLを活用する

私達の多くは、データベースへのアクセス法に関する決断をするのに多くの時間を費やしません。他の多くの言語と違い、RPGはSQLまたはRPG独自のネイティブなデータベース・アクセスのどちらを使用するかの選択肢を開発者に与えます。大半のRPGプログラマーは次の2派のどちらかに分かれます:SQLだけを使う派、またはSQLは遅く複雑だと理解しているのでSQLを絶対に使わない派。

私達は仕事のために最善のツールを使うことを信条としています。これはしばしばSQLをその集合指向の特性と共に使用することを意味します。しかし、開発者にSQLだけを使うよう強制すると、カーソルを扱い、処理方式を条件付けるために複雑なRPGロジックに繋がる可能性があります。ですから、私達はデータアクセスに最も適した方法を決定するために、開発者にアプリケーションにおけるデータベースの用途に目を向けるよう勧めています。RPGのネイティブなアクセスとSQLによるアクセスを混ぜることを禁じる法律はありません。

どのようにデータベースにアクセスするかに関係なく、ビジネスルールをデータベースに埋め込み、RPGロジックを簡素化するために、会社はDb2 for iの使用を検討するべきだということは間違いありません。これは複数の方法で行えます。

参照整合性と検査制約を実装することで、値域および値の検査と同様に関係制約を規定することができます。こうすることで、必要なRPGロジックの量を減らし、データの妥当性検証の処理ロジックを確実にもっと首尾一貫したものにするのに役立てることができます。RPGあるいはSQLで書かれたトリガーは、複雑なビジネスルールを首尾一貫した形で処理することができます。ワークステーションベースのソフトウェアは、ODBC/JDBCまたは他の形式の遠隔アクセスを採用しているので、ユーザーが自分自身の目的のためにデータベース・テーブルにアクセスする可能性が高まるにつれて、データベースに規則を埋め込む必要性は日々高まっています。

SQLビューを作ることができ、その結果SQL文の実力を十二分に活用することができます。これはDDS論理ファイルの能力を遥かに凌ぐものです。またSQLビューを作ることで、プログラムロジックなしで関連するテーブルからデータを集めるために、選択、結合、あるいは和集合を求めるといった操作を行うことによってRPGロジックが簡素化されます。

すべてのSQLを直接プログラムに埋め込むことも可能である一方で、SQLビューを使うことは、外部記述ファイルを更に大きく前進させるようなものです。私達のプラットフォームにおいては、各プログラムの列、データ型、そしてサイズ定義をハードコーディングしようと夢見ることは決してありません。そして、私達はその哲学をデータの選択や表示の仕方にも拡張します。

4.手持ちのツール群をモダナイズする

私達はRational Developer for IBM i (RDi)が大好きです。5250ベースのPDMやSEUツールセットは、これらについてだけでも多くの記事を書くことができる製品ですが、これらと比較してRDiを使用するのには多くの理由があります。しかし、ここでは私達の好きな機能のごく僅かな部分にハイライトを当てることにします。

RDiを使うと、編集のために多くのソースメンバを一度に開くことができ、同時に複数のメンバを見る必要がある場合には、実際の画面サイズが許す限り画面を幾つにも分割できます。このことは、今日のよりモジュラー型のコーディング・スタイルと共に重要になります。1度に見ることのできるコード行数は、画面サイズと調整可能なフォントサイズの組み合わせだけで制限されます。一般的に、SEUと比較して2~3倍のコード行を1度に画面表示できます。

否応なく発生するように思われるコンパイル時エラーのすべての修正は、ソースコードと共に画面上にコンパイルエラーのリストをポップアップするRDiのエラーフィードバックのお陰で劇的に速くなります。リスト内のエラー上で素早くダブルクリックすると、違反のあるコード行が即座に表示されます。

RDiのアウトラインビューのお陰で、内部定義されたものであろうが外部定義されたものであろうが、変数のサイズと型が一目で分かります。アウトラインの相互参照は、各変数(またはプロシージャ、あるいはサブルーチン)をコード内で参照しているすべてのコード行の表示もします。アウトラインからの同じデータは、変数定義をホバーテキストとして表示されるようにするためにも使用され、新しいロジックを書くときにコンテンツアシストがプログラム文の完成を支援できるようにします。

ショートカット・キーは、日常的な行動をより迅速に実行する方法を提供してくれるので、私達が好きなもう1つの機能です。私達は自分達の好きな独自のキーボード・ショートカットのピンナップリストを公表しています(https://systemideveloper.com/pages/downloads/RDiShortCuts/)。

他の重要な開発ツール

変更管理および/またはバージョンコントロール・ソフトウェアは、今日のアプリケーション開発サイクルの早いペースに信頼性高く対応するための要件になりました。IBM iに特化したツールのサードパーティ・サプライヤーの多くは、伝統的なソースメンバ保管モデルを理解しています。多くのツールは、たとえばコード配布支援のような、単なる変更の追跡を遥かに超えた機能さえ有しています。IBMの最近のオープンソース・イニシアチブのお陰も一因ですが、Gitのようなオープンソース・ツールもまた急速に人気を獲得しつつあります。

他の多くのツールは、RPG/400をフリーフォームRPG IVに変換するものや、文書化のための複雑なロジックを復号化したりリファクタリングしたりするのを支援するツールを含め、RPG開発者の日常をもっと余裕のある、より生産性の高いものにすることできます。ここで述べたほとんどのツールは確かに有料ですが、結果のROIは開発ツールへの支出に対する明確な投資対効果検討用資料になります。

5.ユーザーインターフェースを強化する

5250画面は幾つかのアプリケーションには十分である可能性があります。(そして、GUIインターフェースよりも上手く、またはずっと上手く使えると主張する人々がいます。)しかし筆者等の経験では、そうした5250画面に対する主張の大部分は、お粗末なUI設計に帰着します。問題の単純な事実は、銀行業務から音楽を聴くこと、あるいはお気に入りのレストランでのメニュー選択に至るまで、今日の労働者はあらゆることにGUIおよびタッチインターフェースを使っています。UIのモダナイゼーションに失敗すると、会社にとって人材募集や新しいユーザーの訓練は難しいものになります。

たとえ5250画面が、幾つかの仕事用として十分である、あるいは適してさえいると認めたとしても、そのインターフェースを使用することが「幸せ」なのは財布のひもを握っている人ではないので、それは関係ありません。財政支援を支配している人々は、5250画面の傑作を見て、即座にそれを古臭いものとして軽視する人々と同一人物です。幸いにも、非常に洗練された「スクリーン・スクレイパー」からバックエンドロジックを動かすために既存のRPGスキルを活用することで、新しいグラフィカルアプリケーションやモバイル指向のアプリケーションを構築するために設計されたツールに至るまで、モダナイゼーションを支援する多くのツールが利用可能です。これらのツールのほとんどが、筆者のような設計力の劣る開発者でも実用的なインターフェースを迅速かつ容易に作成できるよう支援するために、フレームワークあるいはテンプレート駆動システムを使用しています。

6.もう1つ他の言語を学ぶ

ここでの主要な考えはRPGを置き換えることではなく、RPGを増補することです。そしてもっと重要なことは、考え方を刷新することです。たとえば、私達がPHPを学んだときに、PHPが特にRPGの中で配列やDS配列を使用するという私達のアプローチを変えたことに気付きました。同様に、直ぐに利用可能な広範にわたるPHPの関数ライブラリのお陰で、絶えず車輪を再発明するよりも、事前に構築されたソリューションを探すという決断を下すことが増えました。

IBM i上で使用価値のある言語の大半はPC上でも実行できます。IBM iにPHP、Python、node.js等をロードする許可を得る必要はありません。PC上で言語を学び、これらの新しい言語が会社にとって価値あるものであることを上司達に証明するために、Db2にアクセスすることさえできるのです。

RPGは、今後何年もの間ビジネス・アプリケーションの中核に位置し続けると私達は何気なく信じていますが、あなた自身のキャリアを強化するためのちょっとした「将来の保証」に決して害はありません。新しい要件にアプローチする最善の方法について、管理職が助言を求める相手があなたであることを確実にしてください。あまりにも多くのRPGプログラマーが、どんな言語がIBM iでサポートされているかをよく知りません。その結果、彼らは誰かがIBM iプロットフォームを問題にしたときに異を唱えません。

7.オープンソースを活用する

IBM i上の新しい言語の到来によって、高品質、低コスト、あるいは無料アプリケーションの(無限とまでは言わないまでも)広大な世界が広がります。

効果的でコスト効率の高い運用を行いたいのであれば、車輪を再発明する風潮に抵抗しなければなりません。既存のツールやアプリケーションを活用することを学びましょう。そして、新しい言語を学ぶという私達の戦略と同じように、ソフトウェアに親しみ、それがうまく適合するかどうか判断するためにPCが使えることを忘れないでください。

また、RPGで作成されたツールの数も増えてきています。この記事の執筆時点で、手持ちのプログラムをJSONを活用した新しいRESTウェブサービスを利用、提供することができるようにしたいお客様のために、筆者等は概念実証を完了するプロセスを進めています。これは、ウェブサービスを利用するためのHTTPAPIと一緒にスコット・クレメント氏のYAJL JSONライブラリの移植版(という広範にテストされてきた2つの優れたソフトウェア)を活用して達成されています。また、これには新しいウェブサービスを独立してテストするために、IBM iベースのツールと一緒に無料のSoapUIデスクトップ・アプリケーションを使っています。

小さなステップが大切

モダナイゼーションは、IBM iを使用しているすべての会社内そして会社間で起こるべき重要な会話です。唯一の間違ったアプローチは何もしないことだと覚えておいてください。これらのアプローチの幾つかを試してみてください。どんなことが達成できるか誰にも分からないのですから。

*訳注1:英大文字と半角カナ文字を使用している日本語環境では英小文字は正しい変数名として認識されませんのでご注意ください。

*訳注2:これについては、下記のジョン・パリス氏の記事にある具体的なコーディング技法を参照すると理解し易いでしょう。
“AN INDICATOR BY ANY OTHER NAME” https://www.itjungle.com/2011/08/24/fhg082411-story01/

Copyright © IGUAZU