IBM i のウンチクを語ろう
～ その34：モダナイゼーションの呪縛
皆さん、こんにちは。イベントやセミナーのアンケートの中で、自社のIBM i を今後どのように進化させたいかをお客様にうかがうと、キーワードとしてモダナイゼーションが挙がるケースがあります。IT業界は進化しているのに、自社のIBM i システムには技術的なギャップがある、そこを埋めてゆきたいという課題意識の表れなのでしょうか。最近は登場する頻度は減ったようですが。
モダナイゼーションという言葉がIT業界で語られるようになったのは、1990年代の終わり頃ではないかと思います。少し前から世間に浸透しつつあったインターネット・テクノロジーを既存の基幹業務と連携させることで、ビジネスのやり方を革新しようという試みが始まったあたりです。IBM社はこれをe-Businessという言葉で表現していました。いくつかあった方法論の中で最もわかり易くシンプルなのが、いわゆる黒画面とかグリーン・スクリーンと呼ばれる従来のエミュレータ画面に代えて、ブラウザなどのGUIから基幹業務システムにアクセスできるようにしようという取り組みです。それ以来20年以上にわたって訴求し続けていた事もあり、製品に携わっていた私にとっては、ブラウザ対応化はモダナイゼーションとほぼ同義と言っても過言ではありません。最近になって漸くAIとかIoTといった「新興勢力」が勢いを増しており、これもそろそろ過去のものになりつつあるな、などと勝手な思い込みを持っておりましたが、お客様から今後の課題とうかがって、モダナイゼーションという言葉の執念（？）を感じます。
手元の英和辞典によると、モダナイゼーション（Modernization）には「現代化」とか「近代化」といった訳語が当てられています。そもそもIT用語ではありませんし、ましてやブラウザ対応化といった意味に限定されているわけではありません。何かを進化・刷新させれば、それがすなわちモダナイゼーションになるはずであり、人によって思い描く内容は異なっているのが自然です。ではその実態は何なのか、米Profound Logic Software社がIBM i のモダナイゼーション事情についての調査レポート（The 2017 State of IBM i Modernization）を公表しています。英文ではありますが、グラフだけでも全体を一度眺めてみる事をお勧めします。中でも私の目を引いたのはページ11の下半分にあるグラフ、「Which IBM i modernization projects took priority in 2017? （どの IBM i モダナイゼーション・プロジェクトが2017年に優先的に取り組まれたか）」です。トップが「エミュレータ画面のGUI化」、そして「RPGプログラムのフリーフォーム化」、「モバイル・アプリケーション」、「データベースのSQL化」、「Node.jsなどオープンソース言語の活用」と続きます。
アメリカはきっと日本よりも進んでいるだろうから、エミュレータによるユーザー・インターフェースをGUIに置き換えようという取り組みは既にあたり前のものであり、何か別のもっと先進的な取り組みがなされているに違いない。私のこの想像は、ブラウザ対応化と同類と表現しても差し支えないであろう、上記グラフの第一位と三位によって見事に裏切られていました。そろそろ影が薄くなりつつあると思い込んでいたテクニックが、アメリカにおいてすら未だに多数派として君臨していたのですから。製品担当者の思惑は実態から乖離していた、というわけです。
もう一つ意外、というよりもむしろ感心したのは、第二位にランクインしているRPGプログラムのフリーフォーム化です。ちょっと説明が必要かもしれません。
AS/400登場以来、RPG/400（RPGⅢ）、ILE RPG（RPGⅣ）、フリーフォームRPG（以降FF RPG）と進化してきた経緯はご存知と思います。ILE RPGとしての保守容易性やパフォーマンスに加えて、他言語と共通の構文をサポートしているFF RPGは、IBM i アプリケーション開発における今後の主力を担うものと期待されています。構文の共通性は学び易さにつながるものであり、Java言語経験者に一週間の教育を施しただけでFF RPGプログラマとして稼働させた事例もあるそうです。一方のRPG/400の方は直接事例を聞いた事がないのですが、、アイラーニング社の教育プログラムを見ると、プログラミング基礎編と実践編だけで、合計8日間のコースが用意されています。実際にはこれに復習のための時間が必要になるでしょうから、学習期間は数週間といったところでしょうか。
新規開発はさておき、旧来から持っているRPG/400やILE RPGで記述されたプログラム資産、中でも圧倒的多数を占めるであろうRPG/400をどうするべきかは考えておく必要があります。移行ツールを利用して、コストと手間をかけてFF RPGに移行するべきなのか、特にプログラムを改修するべきビジネス要件が無いのであれば、現状維持のままとするか、という判断が求められます。
RPG/400の機能強化は既に凍結されておりますが、当コラム執筆時点で出荷とサポートが停止される予定はありません。被るかもしれない不利益とかそのための期限が存在しないのであれば、現状維持のままでも構わない、私自身お客様からこのようなコメントをうかがった事があります。確かに急ぐべき理由は無いかも知れません。しかしながら調査レポートの第二位という結果は一見これに反しています。
そもそもFF RPGが登場した背景にあるのは、RPGプログラマを増やそうという製品開発部門の思惑です。RPGアプリケーションは専ら基幹業務遂行をサポートする目的で利用されます。基幹業務が無くならない限り、今後共RPGアプリケーションは長期的に利用されますので、保守要員としてプログラマを確保しなくてはなりません。現在は確保できたとしてもベテラン層が多い可能性がありますし、いつまでも会社に留まる保証はありません。いずれは若年層へと保守責任を引き継いでゆく日が訪れます。
RPG経験のある若年層はまずいないので、あらためてRPG/400を一から学んでもらうのか、さもなければ予めFF RPGに変換しておいて学習のハードルを下げるのか、どちらか一方を選択しなければなりません。言い換えると、RPG/400学習のための時間対、FF RPGへの移行コストとはるかに少なくて済む学習時間の合計、さらに開発者の数を掛け算して比較する、という見方が必要になりそうです。調査レポートが示唆するのは、アメリカのお客様における、問題が予見され解決策が既に存在するのであれば、今のうちから解決策を打っておこう、という意欲の表れだと理解できます。日本においても、きちんと検討した結果が現状維持という結論なのであれば良いのですが、今は手を付けるのが困難だから、と単なる課題の先送りになっているのだとしたら将来に心配の種を残します。
私がこれまでに見聞きする範囲において、基幹システムの将来を全く顧みない、という事はまずありません。FF RPGそのものの価値や、多かれ少なかれRPG/400から移行する方が望ましい事は認識されています。これに伴って開発ツールも、エミュレータ前提のADTSから、EclipseをベースとするRDiに置き換えるべき事も理解されています。ただ、アプリケーション開発言語やツールは、必ずしも直接的に業務を改革するための手段ではありません。FF RPGは、生産性を高める事で、間接的に各会社のビジネスに寄与するタイプの製品だと言えます。IT部門の外に向けて上手くアピールできず、理解を得られていないことはないでしょうか。
追加投資はしたくないのでアプリケーション開発環境のモダナイゼーションは先送りするが、IT部門が頑張って多少のツールの不利はカバーして欲しい。そもそもこれまでにやってきた事と何ら変わりはないではないか。このような主張を見聞きする事があります。何とか拭い去らないと改革は進みません。上記レポートを読んで、私達はIT部門のモダナイゼーションをもっと広く世間に訴求してゆかねばならない、という思いを新たにした次第です。何と言っても企業活動におけるエンジンなのですから。
ではまた
