IBM i のウンチクを語ろう
～ その61：フリーフォームRPGは本当に効果があるのか -2
皆さん、こんにちは。お客様へのインタビューに基づいて、FF RPGの採用事例の紹介を今回も続けようと思います。これまでにRPGを利用しながらも、将来への不安からアプリケーション開発言語を白紙検討し、新規プロジェクトにおいてFF RPGを改めて選定するに至った事例です。単純に「RPG」とは言っても、新しいFF RPGは固定フォームRPGとは大きく異なる言語である事がポイントでした。そしてプロジェクト実施に際して既存アプリケーションの改修も同時に必要になりましたが、ツールを利用してFF RPGに移行する案は採らずに、固定フォームのILE RPGを残しています。なぜテクノロジー刷新は見送られたのか、そして新旧両テクノロジーにまたがるプロジェクトはどのように実施されたのか、最後に今後の課題は何なのかを探ってみます。
まずはプロジェクトに参画した人員の構成から見てみましょう。旧来からILE RPGプログラムを保守してきたベテラン技術者と、新規に採用された2~30代を中心とする若手技術者による、人数比は概ね半々の混成チームでした。インタビューは複数社に実施したのですが、この人数比は同じようなものでした。そして若手はJavaやCなどといったオープン系言語の経験しかありません。逆にベテランはFF RPGに対してわかりにくいという印象を持っていました。そこで無理にどちらか一方に寄せるのではなく、ベテランは既存ILE RPGの改修、若手はオープン系言語に似たFF RPGによる新規開発、と分担・連携することにしました。言語世代は違ってもこれらRPGは問題無く共存することができます。既存アプリケーションがRPG/400で記述されていたとしても同様です。
実際のプロジェクトの現場において、IBM i 開発部門の思惑どおりにJavaやCのスキルはFF RPGに役立つのでしょうか。前述のとおり、開発チームに新たに加わった若手技術者の中に、RPGはおろかIBM i 経験者は皆無です。会社として備えている教育体制や、独り立ちしたとする判断基準の差にもよるのだと思いますが、FF RPGの習得期間は約1.5ないし3ヶ月だったというのがインタビュー時に得られた回答でした。C、Java、JavaScriptの経験者の方は、FF RPGをせいぜいCから派生した数ある言語の一つ、といった程度に捉えていたので、違和感を意識することは全く無かったそうです。一方別のお客様から聞いたことがあるのですが、かつてRPG/400のような固定フォーム型を教育しようとして、オープン性とは縁遠い特異な文法・構造ゆえに抵抗を示した新人の方がいたこともあるそうです。オープン性というのは製品を語る際の属性に留まらず、人の学習意欲とかその効率にも関わってくるので、決してないがしろにはできないようです。
アプリケーション開発におけるオープン性を考える際には、開発ツールにも目を向けなくてはなりません。ご存知のとおりFF RPG開発にあたっては、エディタとしてエミュレータを前提とするSEUは使えないので、RDi（Rational Developer for i）が必要になります。Eclipseをベースに、RPG、COBOL、CLといったIBM i プログラム言語用のエディタ、コンパイラ、デバッガなどのツール類を、アドオン・モジュールとして組込んだ製品です。Eclipseは現代的なGUIを備えたオープンなテクノロジーですので経験者も数多いですし、仮に未経験の方であったとしても違和感を抱くことはまずありません。インタビューに応じたお客様においても、若手の方はごく当たり前の事のようにRDiを受け入れ馴染んでいったようです。この開発ツールについては、コラム「アプリケーション開発ツールを考える」でも紹介しておりますので、あらためて目を通していただければ幸いです。
もう一つ考慮しなければならないのが、データベースへのアクセス手段です。旧来からネイティブ・アクセスないしレコードレベル・アクセスと呼ばれている、IBM i 独自の手法が主流の座にありました。IBM i 未経験ということはこのテクノロジーについても未経験であることを意味しており、製品に対する違和感のもう一つの要因になっています。これに対するオープン性ある解決策はSQLの利用です。「SQL標準」と呼ばれる業界標準テクノロジーがあり、例えばバージョン7.4のDb2 for i は最新の「SQL:2016」に準拠している事が、IBMのドキュメント「Db2 for i SQL 解説書」のページxiに示されています。データベースには大抵独自の機能拡張がなされているものですが、他システムでSQLに触れた経験があれば、そのままIBM i においても役立ちます。実際のFF RPGプロジェクトにおいてもSQLが採用されました。
今回のインタビューの中で感じたのは、プロジェクトの成功要因の一つは連携にあった、ということです。旧来のテクノロジーで開発されたアプリケーションを長年保守してきたベテラン要員と、最新テクノロジーを活かしてアプリケーション開発に携わろうとする若手要員は、単一の目標に向けて共同作業を行っています。両者を分断してしまっては、これまでに積み上げてきたシステムやスキルなどの資産を活かすことができませんし、リスクも高くなります。保守要員の高齢化やテクノロジーの陳腐化が進むに任せながら、従来のシステムについては切り替えるまでの寿命とばかりに塩漬け状態にする一方で、それとは全く別にオープン系の新規プロジェクトを進めようとして失敗してしまうケースを見聞きします。結果的に慌てて旧システムを延命させるために右往左往してしまうのは不幸なことです。新旧の要員もテクノロジーも、分断ではなく連携を第一に考えるべきだと言えるでしょう。
さてこれで全ての課題が解決されたわけではありません。若手にはなかなか手が出ない既存の固定フォームRPGプログラムが未だ残されています。ベテランが皆退職してしまう前に、保守体制を再構築しなければなりません。ARCAD 社のTransformerないしConverterというFF RPGへの移行ツールの存在は皆さんもご存知だと思います。しかしながらいずれのお客様においても、プロジェクトのそもそもの目的は新たな要件を満たすためのアプリケーション開発にあったことから、付随的作業になる移行は一旦見送られました。判断において考慮したのはデータベース・アクセスと、プログラムにおけるつぎはぎ状態の二つです。ARCAD社のツールを活用するにしても、これら課題の解決に取り組むべきかどうかを判断し、必要であればある程度の作業量を見込まなければなりません。
上に述べたように、IBM i におけるデータベースへのアクセス手段には、旧来から主流であったネイティブ・アクセスと比較的新しいSQLとがあります。ツールを利用してFF RPGへと移行したとしても、この部分は変換されずに取り込まれます。RPGの移行作業の負荷に比べれば軽いであろうとは言え、「SQL化」のためには手作業が必要になります。
また、資産継承性が備わっていることからIBM i のプログラムは一般的に長寿命です。その間に全く手付かずということは無く、何度も改修が繰り返されています。都度ドキュメントに痕跡を残し、読み易さを維持するようにプログラムしていれば良いのですが、残念ながら現実はそうなっていないことが多いようです。手間を惜しんで文書化を怠ったり、場当たり的につぎはぎ状態になってしまっていたりするケースも多く、そうなると次第に保守性は低下してゆきます。言わばブラックボックス化しつつある状態です。移行ツールを通しただけでは、つぎはぎを含んだままのFF RPGが生成されてしまいます。
次世代を見据えたアプリケーション保守体制の構築がFF RPGへの移行の狙いであるはずですので、ツール利用だけで済ませずに、多少の手間を要したとしてもプログラムにおける懸念事項は払拭しておきたいところです。インタビューしたお客様のうちの一社では、既存プログラムの保守のためにX-Analysisを役立てています。構造を理解するためのドキュメントが出力されるだけでなく、漏れ無く改修における影響範囲を特定できるので、プロジェクトの迅速化・高品質化を図ることができます。いずれFF RPGへの移行を行うことになったら、SQL化は手作業になるかもしれませんが、つぎはぎを解消するためにこの分析機能を役立てることになるでしょう。もしかしたらこれらの作業負荷が大きく見えてしまうかもしれません。それでも資産継承性の無いプログラム言語へと移行して、インフラを刷新する都度アプリケーションの全面的な見直しを余儀なくされる事に比べれば、はるかに安全で簡便に済むのではないかと思います。
ではまた。
