【激論！】RPGは残す？残さない？ をうけて（１）

これまで3回にわたって 【激論！】RPGは残す？残さない？ を連載してまいりましたが、最後に、日本IBM エバンジェリストとして長年活動し、現在はベル・データ株式会社にてエバンジェリストとして活動している　安井 賢克 氏　にお話しをお伺いいたしました。 ＜お話を伺った人＞ ベル・データ株式会社 パワーシステム・エバンジェリスト 安井 賢克 氏   RPGに関するこれまでの論調を総じて言えば、残すのが妥当、もしくはアプリケーションの用途を見極めた上で残すべきところを残し、用途次第では別の言語を採用する、といったあたりに落ち着いているようです。他方IBM i コミュニティの外部には、もっと厳しい否定的見解もあります。技術的な懸念事項からIBMが撤退する可能性に至るまで、根拠とされるものに出処の怪しさを感じる事もありますが、それなりに理由や背景を伴っています。IBM i とRPGとは実質的に一心同体と見なされる以上は、IBMとしてもこれに対して手をこまねいていたわけではありません。 このコラムは筆者のRPGにまつわる経験・知見を総動員しながら、否定的見解の一つ一つに対する対策や考え方を集大成としてまとめてみたものです。長くなりますので、3回シリーズの形でお届けします。IBM i を生業とする組織に属してはおりますが、どなたにも納得いただけるよう可能な限り主観を排除し、事実や客観性のあるデータに基づきながら論を進めるつもりです。最後まで読み進めた時に、RPGに対する見方が変わったとまではいかなくても、RPGの価値を今一度きちんと見直してみようか、と思っていただけるようになれば大変に嬉しく思います。  

JavaかRPGか

「Write once, run anywhere」（一度書けばどこでも動く）　かつてのサン・マイクロシステムズ社が掲げたJava言語のスローガンです。歴史を紐解くとJava言語が登場したのは1995年に遡ります。ある特定のマシンを想定して記述されたプログラムは、別のマシン上では稼働しない、というそれまでの常識を打ち破る画期的な概念を、一言で言い表しています。C言語をベースに、開発生産性を高めるためにオブジェクト指向の概念を取り入れた言語として、未だにそのブームは続いていると言っても過言ではありません。言語の人気ランキングの一例に過ぎませんが、TIOBE社のサイトによると、一時的にC言語に逆転されるケースはあったものの、過去15年間以上概ねトップの座を保ち続けています。 RPG言語にも同様にスローガンを与えるとしたら、さしずめ「Write once, run forever」（一度書けば将来いつまででも動く）といったところでしょうか。正確な記録が見当たらないのですが、最初のリリースは1950年代末でした。IBM i 上で世代を超えて実現されている互換性は、ソースコードではなく、コンパイル済み実行コードのレベルで達成されているのが、他言語にはないユニークな点です。この利便性は、IBM i が独自に備えるTIMI（Technology Independent Machine Interface）と呼ばれる仮想マシン上で実現されていますので、RPGだけでなくCOBOLにおいても該当します。参考までにTIMIは、1978年発表のシステム38までその起源を遡ることができますので、「run forever」は大風呂敷だとしても、少なくとも「run for 40 years」（40年間動く）は実証済みです。 広くIT業界にいる方に、これからプロジェクトを開始するとしたらどちらの言語を採用するか、と問えば、Javaが圧倒的多数を占めるであろうことはまず間違いありません。「そもそもRPGってRole Playing Gameの事？」と思う方もいることでしょうし、軍事に詳しい方にとっては対戦車兵器の一つであるRocket Propelled Grenadeかも知れません。Report Program GeneratorというIBM i （AS/400）向けの独自言語という認識はあっても、絶滅危惧種扱いされる可能性すらあります。実際にIBM i 上でRPGプログラムを利用されている方であっても、このまま使い続けていて良いのだろうか、と懸念される方もいらっしゃいます。 RPGプログラムはJavaに置き換えられるべき、といった論調を実際に見聞きする事もありますが、脊髄反射的に反応する前に、ちょっと踏み止まって考えてみたいと思います。凡そプログラミング言語においては、何かが別のものよりもあらゆる面において優れる、という事はありません。用途とか想定されている環境が違うに過ぎないのであり、変化の激しいIT業界の中で40年間以上も存在しているからにはそれなりの理由があります。残す・残さないを議論する前に、そもそも何のためのプログラム言語なのか、どのような特徴を備えているのか、を認識する必要があります。  

何故プログラムの資産継承性は重要なのか

RPGはSoR（Systems of Record：直訳すると「記録するシステム」）ないし基幹業務向け言語です。「基幹業務」とは企業の経済活動そのものであり、より具体的には生産管理、販売管理、総務（人事、給与、経理）といった業務です。コンピュータがこれだけ世の中に普及しているのも、あらゆる企業が基幹業務用途に採用している事がその大きな要因になっています。（もっとも世界初のコンピュータとされるENIACは第二次大戦期の弾道計算用、また同時期の他のシステムも暗号解析用と軍事の影が色濃いのですが。）業務とは仕事のやり方、多くの人の作業とその連携であり、企業独自の慣習が改善を伴いながら長年にわたって継続・蓄積されるものです。したがって、それを支えるシステムをそうそう簡単に抜本的に変更する事はできません。 一般社団法人日本情報システム・ユーザー協会編纂の第22回 企業IT動向調査2016（15年度調査）ページ44によると、基幹業務システム（アプリケーション）の寿命は2012年時点で平均14.6年、明確には算出されていませんが2016年になるとさらに伸びています。稼働開始時期を見ると、約20%は21年以上前、約40％は11～20年前であり、さらに将来も何年か利用されるのですから合算すると極めて長期になります。一方マシンの典型的な使用期間は、リース期間とかメーカーによる保守期限の影響を受けますので5年とか7年になり、アプリケーションに比べると明らかに短命です。マシン交換の際に業務要件に変更が無ければ、アプリケーションはそのまま、すなわちコンパイル済み実行コードに手を付けずに乗せ換えたいところです。ソースコードの互換性が実現されればユーザーの負荷は多少軽減されますが、再度のコンパイルが必要となると、アプリケーションの稼働テストは必要になってしまいます。冒頭にあげたIBM i 上のRPGやCOBOL実行コードの「run forever」の価値はここにあります。 もしJavaで基幹業務アプリケーションを記述したらどうなるでしょうか。個人的経験に過ぎませんが、業務用途にもJavaを採用するケースをよく見聞きするようになったのは2000年代初頭、バージョンで言うと1.4とか5の頃です。このプログラム実行環境を最新のものにアップグレードしようとしたら、例えばWindows Server 2016ならば、JVMのバージョンは7以上でなければなりません。もしくは当コラム執筆時点（2018年4月16日）でダウンロード可能な最新バージョンは8です。Javaにはバージョン間の互換性はありませんので、アプリケーション要件は何も変わらなかったとしても、ソースコードの見直しが必要になります。ビジネスを支えるためのテクノロジーであるはずなのに、テクノロジーの事情ゆえにビジネス資源を投入しなければならない、という本末転倒の事態に陥ります。とてもこのような手間は掛けられないとしたら、旧来からあるJVMをアップグレードせずに維持し続けるしかありません。アプリケーションに手を付けられないために、サーバー環境全体が「塩漬け」になってしまう、Javaのレガシー化を招く事になります。冒頭の「run anywhere」には、「JVMバージョンが同じであれば」という条件が付いているのです。  

RPGの課題と対策

プログラム資産継承性を考慮するならば、RPGに分がある事は明らかです。ですがアプリケーションを利用するためのPC画面の多くは、黒い背景に緑色の文字の「ブラック・スクリーン」とか「グリーン・スクリーン」と呼ばれるCUI（Character User Interface）であり、古さを感じさせます。将来にわたってプログラム保守要員を確保できるのかが不透明、という声もよく聞きます。長い間使えるというメリットがある反面、小刻みな改修を積み重ねてきたためにプログラムが複雑に入り組んでしまい、解読と保守が著しく困難になってしまっている（いわゆるスパゲッティ状態）、という懸念もあります。次回以降これら一つ一つの項目について検討してまいります。 ではまた     ＜Company Information＞ ベル・データ株式会社 事業所：本社（東京都新宿区）/東日本支店/名古屋支店/大阪支店/九州支店/熊本営業所 設立： 1991年7月 事業内容：インフラストラクチャー インテグレーター事業/システムインテグレーター事業/クラウド・アウトソーシング事業/情報提供サービス URL：www.belldata.com/index.html