【激論！】RPGは残す？残さない？～第2回ＪＢＣＣ株式会社

慌てず、騒がず、既存資産を棚卸して的確な判断を―RPGの移行は“ソフトランディング”で臨むべき

レガシー化しつつあるRPGについて「残すべきか？残さないか？」をさまざまなベンダーが交代で登場し、議論を深めていくのが本企画のテーマだ。第2回はＪＢＣＣ株式会社（以下、ＪＢＣＣ）に話を伺った。1988年のIBM AS/400販売開始以来、IBM i を基盤とするシステムの開発・販売に深く携わってきた同社は、現在では超高速開発ツール「GeneXus」をベースとした高品質アプリケーションのアジャイル開発に注力している。このソリューションを通じてＪＢＣＣが提示するRPG資産の移行シナリオを探ってみる。＜お話を伺った人＞

執行役員 SIイノベーション事業部　事業部長中野恭宏氏

SIイノベーション事業部 SIイノベーション営業部　部長田中靖久氏

今後RPGはどうなる？現場の実態とIBMの意向を正しく理解する

今後10年以上にわたるロードマップを発表IBM i やRPGの保守サポートを確約

IBM i シリーズはAS/400の時代から約30年にわたり一貫した設計思想を維持し、基幹システムの安定運用を支える高信頼性のIT基盤として高い評価を受けてきた。また、その主力プログラム言語であるRPGで作られたアプリケーション資産は、現在も多くの企業で稼働を続けている。だが、ここにきてユーザー企業の現場では、RPG技術者の「高齢化・退職問題」（若手技術者の不足）が顕在化している。たとえばIPA（独立行政法人情報処理推進機構）は、5年前に発行された「IT人材白書2012 」の中でRPG 技術者の動向についてすでに言及しており、もともとRPG技術者は他のプログラム言語と比べて人口が少ない（COBOLの約1/10、PL/1の1/2 程度）こと、人材のシニア化が進んでいること、利用環境がIBM i シリーズに限定されるといった理由から、「今後10年でエンジニアがいなくなるリスクが高い」という予測を示している。すなわちそれは、今から5年後の2022年のことである。こうした状況を知れば知るほど、否応なく不安は高まっていく。今あるRPG資産のすべてを今後2～3年のうちに別のプログラム言語を使って再構築すべきだろうか。潤沢なIT予算が有り余っているというのならそうした判断も成り立つかもしれない。だが、ほとんどの企業にとっては難しい話だろう。ＪＢＣＣの執行役員でありSIイノベーション事業部の事業部長を務める中野恭宏氏は、「コストをかけて既存のRPG資産を再構築したとしても、新しいシステムで出来ることが以前と変わらないのであれば意味がありません。経営者はそのような投資を許さないでしょう」と言う。では、今あるRPG資産を仮にそのまま残した場合、企業は近い将来にどんな事態に直面することになるだろうか。ここまで述べてきたことを覆すようだが、実はそれほど心配する必要はない。 IBMは2016年9月21日、IBM i シリーズに関して今後10年以上に及ぶロードマップを発表し、保守サポートを確約しているからだ。このような長期間にわたる投資プランを公開することはIT業界全体を見渡してもあまり例がなく、IBM i ユーザーが今後も安心して既存のRPG資産を利用し続けることができる大きな後ろ盾となっている。「ＪＢＣＣがシステム開発を請け負ったケースでも、ほとんどのお客様が既存のRPG資産の一部をそのまま残しています」と中野氏は語る。

まずは既存資産の棚卸から。RPGから変えるもの、残すものを冷静に見極める

5年先、10年先のビジネスはどうなっている？変える必要のないシステムはそのまま残すべき

IBM i シリーズによるインフラも、RPGで作ったアプリケーションも、今後10年以上にわたって稼働することが確約されているのだから、先を急いですべてのシステムを再構築しなければならないわけではない。「実際のところ5年先、10年先にマーケットやビジネス環境がどのように変化し、自社や競合企業のビジネスモデルがどうなっているかは予測が難しいのですから、慌てる必要はありません。『変える必要のないシステムはそのまま残す』と割り切ることで、運用コストも最小限に抑えることができます」と中野氏は説く。中野氏が示唆するところの「変える必要のないシステム」とは、具体的には「SoR（System of Record）」や「モード1」などと呼ばれる基幹システムを指す。主に業務の効率化や省力化を支えてきた“守りのIT”だ。特に基幹系システムの中でも受発注管理、在庫管理、経費精算などの業務を担っているアプリケーションがこれにあたり、処理内容は長期にわたってほとんど変化することがない。むしろ中途半端な形で再構築に乗り出してしまうと、ミッション・クリティカルなシステムであるだけに「動作検証に多大な労力とコストが発生する」「システムの使い勝手が大きく変わって不慣れな担当者が操作ミスを起こす」といったリスクを高めてしまう。

“攻め”を狙ったシステムについてはオープン系プログラム言語への移行を推奨

一方で、すぐにでも刷新が求められる、あるいは自社の競争力強化のために新規に構築しなければならないシステムもある。「SoE（System of Engagement）」や「モード2」などと呼ばれる、新たな事業創出や利益拡大の原動力となる“攻めのIT”だ。「当然、こうした“攻め”を狙ったシステムについてはRPGではなくオープン系のプログラム言語で作ることを強くお勧めします。」と中野氏は語る。 RPGとオープン系のプログラム言語の間には、実務上で「出来ること」にどんな違いがあるのだろうか。 SoEの重要な鍵を握るのがユーザーインターフェースである。SoEを日本語に訳せば「絆のためのシステム」であり、そのタッチポイントにおいて、かつてないカスタマー・エクスペリエンス（顧客体験）を提供することが求められるのだ。例えば近年では、スマートフォンのGPS機能から測定した位置情報とユーザーの購買・行動履歴から最寄りのお勧めのショップを案内してくれるアプリなどが登場しているが、これもSoEの一種である。さらに最先端の分野では、例えば自動車にコネクテッドやAI（人工知能）の機能を持たせることで、気候や路面の状態を把握して的確な運転のアドバイスをしたり、保守が必要な部品の故障や性能劣化を事前に検知してその対処法を伝えたり、好みの音楽をかけてリラックスさせたりといった研究開発が行われている。こうした高度なエクスペリエンスを体現するユーザーインターフェースをRPGで構築するのは、荷が重い。ただし、オープン系のプログラム言語でシステムを刷新する場合でも、新しいプラットフォームに丸ごと移行するのが必ずしも得策とは限らない。「IBM i のインフラ部分（ハードウェア筐体、オペレーティング・システム、データベース）については、アーキテクチャーを含めて継承することを考えるべきです」と中野氏は提言する。先述したようにIBM i シリーズは今後10年以上に及ぶ保守サポートが確約されているため、今から構築するアプリケーションについても高い資産継承性が得られるからだ。また、過去30年以上にわたって多くの企業で使いこまれてきているだけに、非常に高度な信頼性や運用性、堅牢なセキュリティを備えていることも他のプラットフォームを凌駕するメリットだ。加えて、「バッチ処理についてはRPGを残す場合もあります」と中野氏は語る。IBM i シリーズとRPGの組み合わせで実行するバッチ処理は、同等の価格レンジのオープン系プラットフォームに比べてより効果的にパフォーマンスを引き出せるケースが多い。こうしたことからも「ITモダナイゼーション」に臨む際には、まずは既存資産の棚卸をしっかり実施しておきたい。その上でRPGからオープン系のプログラム言語に移行すべき部分、RPGを残す部分を見極めていくことになる。

「レガシーシステム」にしないシステム構築や運用の仕組みづくりへ

そしてもうひとつ、ITモダナイゼーションに際しての重要ポイントとしてＪＢＣＣが強調するのが、「レガシーシステムを生み出すシステム構築や運用を繰り返さないための仕組みづくり」である。なぜ既存のRPG資産の多くがレガシーシステム化してしまっているのだろうか。これらのアプリケーションも稼働を開始した当初は、設計内容とソースコードが正確に一致していたはずだ。ところが長年の運用を重ねるうちに、ソースコードを変更した結果が設計書に反映されていない箇所が徐々に増えていく。本来の手順は、設計書を修正・検証した後にソースコードを修正するはずだが、複雑な設計書の整合を保つのは困難であり、直接ソースコードを変更してしまう。オフィスツールによる設計書管理の限界だ。こうしてソースコードとのギャップが広がった結果、一部に不整合が見つかった場合、設計書は意味を持たず、参照も保守もされなくなってしまうのだ。本格的に保守を行うためには、常に稼働中のソースコードから調査を行う必要があり、多大な労力とコストがかさむ。だからこそオープン系のプラットフォームやプログラム言語に移行するシステムについては、同じ轍を踏むことがあってはならない。設計品質を保つため、ＪＢＣＣではXupperⅡを活用している。また、システムを見直す際には既存資産について必ず業務視点でアセスメントを行い、あらためて課題を定義する必要がある。「これにより現行のRPG資産も活かしつつ、段階的に新プラットフォームへ実装していく“ソフトランディング”の移行シナリオを描くことが可能となります」と中野氏は強調する。例えばRPG技術者の高齢化に伴うシステムの属人化や保守作業手間を可視化ツールを活用して解消し、まずは次世代システムを検討するための余力を生み出す。また、変化する業務要件への迅速な対応という課題に対しては、IBM i 資産を活かした保守性の高いシステムで実現する。そしてSoEのアプリケーションを通じたエクスペリエンスの提供という課題に対しては、業務プロセスそのものを改善するユーザーインターフェースを実装するとともに、将来にわたってテクノロジーの変化に追随可能な基盤を構築する。これがＪＢＣＣの提案する解決策の基本的アプローチだ。

ＪＢＣＣが「IBM i ＋GeneXus」で提唱するITモダナイゼーションの基本ステップ

4,000ステップ相当の画面をわずか15分で自動生成が可能

ＪＢＣＣによる課題解決のアプローチをさらに掘り下げていこう。ＪＢＣＣが基本としているのは、改修が必要なアプリケーション部分だけを取り出して迅速に開発するという手法だ。ここで活用しているのが、既存システムを分析する「Reverse Comet i」、上流工程で設計を支援する「XupperⅡ」、高速開発を実現する「GeneXus 」などのツール群だ。なかでも重要な役割を担っているのがGeneXusであり、同社 SIイノベーション事業部 SIイノベーション営業部の部長を務める田中靖久氏は、次のように説明する。「GeneXusを簡単に言えば、物理的なバグのない高品質のプログラムを自動生成する超高速開発ツールです。項目情報を定義するだけでプログラムやデータベースなどが自動生成されます。こうしたことからプログラム言語に関する専門知識は不要で、1～2か月程度のOJTを積むことで、アプリケーション開発に必要なスキルを習得することが可能となります」例えば、Javaでプログラムを記述した場合、約4,000ステップのプログラムがGeneXusを使えば15分程度で作ることも可能となり、この開発作業が自動化されるのだ。人手によるプログラミングでは避けられなかったタイプミスやオペレーションミスなどのヒューマンエラーに起因するバグも発生しない。また、ボタン操作1つでソースコードを生成するプログラム言語をJava、C#やSwiftなどに切り替えたり、各種データベースソフトに対応したテーブル定義情報を自動的に設定したりすることも可能だ。さらに特筆すべきが、IBM i シリーズとGeneXusとの相性の良さである。もともとGeneXusは1989年に南米ウルグアイのGeneXus S.A.社が開発したGeneXus初代バージョンを当時のAS/400上で稼働するアプリケーション自動生成ツールとして発売されたことに始まる。こうした経緯から現在でもGeneXusは、IBM i との高い親和性を維持しているのである。

ブラックボックス化した既存アプリケーション改修・移行を進める3つのステップ

GeneXusは新規のアプリケーション開発のみならず、既存のRPG、COBOLプログラムを再構築するケースでも迅速なアプリケーション開発を実現する。さらに「属人的な開発・運用体制などが原因となって既存システムの内容を誰も把握していないブラックボックスに陥っている場合でも、　ＪＢＣＣのご提供する開発基盤ツールとその活用手法でレガシー化・ブラックボックス化を再発させないという大きな効果を発揮します」と田中氏は訴求する。具体的にどんな手順でブラックボックス化した既存資産の改修および移行を進めていくのだろうか。通常のケースでは、下記の3つのステップでプロジェクトを進めている。 ●第1ステップ：既存システム分析：（IBM i の見える化） Reverse Comet iを活用し、ブラックボックス化した現行システムのプログラムソースを解析。影響分析（修正の影響が及ぶ範囲の解析）、構造分析（プログラム構造の解析）を行う。

●第2ステップ：上流設計環境構築：（業務の見える化＋設計） XupperⅡを活用し、ビジネスのフローや処理ルールなどの上流設計に必要な情報を精査。開発したアプリケーションが再びレガシー化することを防ぐためにリポジトリに情報を蓄積し、設計情報を共有する。

●第3ステップ：システム開発環境構築：(システム開発) GeneXusを活用し、業務の内容を記述する。たとえば見積りシステムであれば、お客様番号や見積りに必要な項目を定義する。GeneXusが定義情報を自動的に分析し、生成する言語やデータベースを指定すれば、プログラムは自動的に生成される。

直近2年間でＪＢＣＣがサポートした約80件のプロジェクトでいうと、約半数がIBMi システムが対象であり既存のIBMi 資産を活かしながら上記のステップで再構築しているという。なお、すべての既存資産を一気にオープン系に再構築した例はまだないとのことだ。こうした実際の企業の判断や動きからも見て取れるように、RPGを「残す」「残さない」を単純な二元論で語ることはできない。あくまでもケース・バイ・ケースで検討する必要がありそうだ。そして、いざオープン系への移行を決断した場合にも、「足りないスキルや知識をツールで補い、最小限のコストと最短の期間でITモダナイゼーションを成し遂げることができる方法がある」（中野氏）というのが、ＪＢＣＣの一貫した主張である。

＜Company Information＞ ＪＢＣＣ株式会社本社：〒144-8721 東京都大田区蒲田5-37-1 ニッセイアロマスクエア 15階設立：1988年4月1日（旧NSISS株式会社） ※2006年4月1日日本ビジネスコンピューター株式会社（1964年設立）より分社し、2012年4月1日ＪＢエンタープライズソリューション株式会社（旧NSISS）と合併。事業内容：システムに関するコンサルティング、ソリューションの提案、システム設計及びソフトウェア開発、システム基盤構築及び運用・保守サービス、ハードウェア・ソフトウェアの販売、ソフトウェアパッケージ開発、グローバル経営を支えるITサービスの支援 URL：http://www.jbcc.co.jp/