現行資産の可視化・分析はモダナイゼーションの入口であり、「活かす資産」と「捨てる資産」を慎重に見極めることで、
進むべきロードマップが描かれる。IBM iモダナイゼーションに向けて提示される選択肢と、それぞれのアプローチを見ていこう。
モダナイゼーションで考える
「活かす資産」と「捨てる資産」
運用歴の長いシステムほど、現在のシステム環境を将来に向けてどうモダナイズしていくか、いわゆる「モダナイゼーション」が大きなテーマとなる。
プログラムの資産継承性が高いIBM iでは、自社の業務や独自性にきめ細かく対応した基幹システムを作り上げ、長年にわたり運用しているケースが目立つ。今後はRPG技術者の不足や世代交代に伴うスキル転換の必要性も指摘されており、現在のプログラム資産を未来に向けてどう刷新していくか、頭を悩ませるユーザーは多い。
本誌では「今あるIBM iの資産を最大限に活かしながら、今後求められる新しい業務要件や利用モデル、最新のテクノロジーに対応させること」と、モダナイゼーションを定義している。その手法は多彩で、企業の考え方によってシナリオは異なる。なかには、将来を考えるなら、「脱IBM i」こそがモダナイゼーションの道であると考えるユーザーもいるだろう。
ただしオープン系への完全移行に向けて動き出してはみたものの、費やすコストと工数、そして想定されるリスクの大きさに比べて、得られる業務的・ビジネス的な価値が小さいことに気づき、移行計画を中止し、現在の資産を最大限に活かした形でのシナリオに書き替えるケースも少なからずあると聞く。「なんとなく古くさい」「このままではいけない」などの安易な発想によるオープン系への移行は、非常に危険であると言わざるを得ない。
IBM iのモダナイゼーションで重要なのは、「活かす資産と捨てる資産を慎重に見極める」ことである（図表1）。本特集で紹介するホクモウの取り組みは、これを充実に実行したモダナイゼーション事例である。
現在のシステムは、長年にわたり積み重ねてきた業務とノウハウの結晶である。そのどれを捨て、何を継承し、どう活かすのか。そのコンセプトによって、モダナイゼーションのシナリオも、その成果も大きく変わってくる。
モダナイゼーションの第1ステップ
資産の可視化・分析
長年運用されているIBM iのアプリケーションは、改修の過程が仕様書や設計書などのドキュメント類に残されておらず、システム内容がブラックボックス化する傾向にある。
そこで現行のアプリケーション資産を分析・可視化することが、モダナイゼーションに向けた第1ステップとなる。どのような手法でモダナイゼーションに着手する場合でも、現状を正確に分析することが出発点であり、モダナイゼーションの成否を決めることになる。
最近はこのソリューション領域が関心を集めており、「SS/TOOL-ADV」（アイエステクノポート）、「Trinity」（ZeroDivide）、「Arcad OBSERVER」（三和コムテック）、「REVERSE COMET i」（NCS&A）、「ADT」システム文書化サービス（ソルパック）など、多彩な製品やサービスが提供されている。
その1つとして注目されるのが、カナダのFresche Solutions（フレッシェ・ソリューションズ）社が開発・販売する「X-Analysis」である。RPG、COBOL、CLなどのプログラム資産を可視化・分析するソリューションとして高度な機能群を誇り、グローバル市場では導入実績が最も高い。国内でも、「資産の可視化・分析」というソリューション領域を開拓したトップランナーと言える。
同社は2017年1月、「X-Analysis」のブランド名を変更し、製品の再編成に着手した。 従来提供されてきた中核製品は「X-Analysis Professional」で、ソースレベルとオブジェクトレベルの双方からプログラム構造を可視化する機能に加え、PF情報をもとにしたデータモデル構造の可視化、およびWordやExcel、PDFファイルなどへ文書化する機能をサポートしていた。
これにオプション製品として、IBM i上で実行されている全コードとデータベースの詳細なメトリック分析によりソースコードの品質を監査する「X-Audit」、ビジネスルールを分析・抽出してリエンジニアリングに役立てる「X-Rules」が提供されてきた。
しかしブランド変更後は、前述の「X-Analysis」から文書化以外の機能群をサポートする「Fresche View」、そして文書化および「X-Audit」「X-Rules」の機能をサポートする「Fresche Advisor」という2つの製品に再編成された。
また国内では販売されていないが、Fresche Solutions社はデータベース関連のコンバージョン、さらにRPGからJavaへ、もしくはDDSからDDLへ変換するツールなど多彩な製品を提供している。そこで「Fresche View」「Fresche Advisor」を含めたこれら一連のツール群を、「X-Analysis Suite」のブランド名で総称することになった。
日本での正規販売代理店として「Fresche View」「Fresche Advisor」の導入に力を入れるジーアールソリューションズ（以下、GRS）の鎌田悟代表取締役社長は、ブランド変更と製品の再編成に込めた狙いを次のように語る。
「X-Analysisは可視化・分析ツールのなかでは最も高機能かつ高価格である、つまりハイエンドな製品であるというイメージが広がりつつありました。そこでお客様にもっとわかりやすく、そして導入しやすい価格設定に変えて広く普及させるために、今回のブランド変更に踏み切ることになりました」
注目されるのは、その戦略的な価格設定である。ベース製品は「Fresche View」、そのオプション製品が「Fresche Advisor」という位置づけだが、文書化機能を必要としないのであれば、「Fresche View」だけを導入すればよい。国内標準価格は全マシンクラス共通で160万円（年間保守料は標準価格の20%。ベル・データでは現在、今年3月末までの予定で特別キャンペーンを実施中）。
また「Fresche Advisor」とセットにしても、標準価格は500～840万円（マシンクラスにより異なる。年間保守料は標準価格の20%）と、従来価格の半分以下で導入が可能である。
「Fresche ViewとFresche AdvisorはどちらもCPUライセンスなので、端末台数の制限はありません。端末にモジュールを導入すれば、何ユーザーでもお使いいただけます。欧米では開発に携わるチーム全員が端末でリアルタイムに参照しながら活用を進め、文書に印刷しないケースが多いので、Fresche Viewから文書化機能を外しました。国内ではまだWordやExcel、PDFなどへ文書化して利用するケースが多いようですが、欧米のように全員が端末で参照するというスタイルを採用すれば、とても低価格でご導入いただけます」（鎌田氏）
またFresche Solutions社の取り組みとしてもう1つ注目されるのが、ツールの提供と同時に、モダナイゼーションに向けたコンサルティングサービス「Discovery Service」を展開していることである。
「Discovery Service」は、図表2のように「ポートフォリオ戦略」「モダナイゼーション・ロードマップ」「範囲の絞り込みと分析」「計画と見積」、そして実際の「モダナイゼーションプロジェクト」という5つのステップで構成されている。 
最初のステップから「Fresche View」「Fresche Advisor」などのツールを利用してボトムアップでのソース&オブジェクト解析と、トップダウンによるマネジメント層への経営ビジョンに関するヒアリングを双方向から進める。そして現行資産の継続利用からオープン系への完全移行まで、多様な角度で将来のシステム基盤計画を策定していく。
このサービスはオンサイトで進められ、ユーザーとともにワークショップを開催しながら現状を理解し、将来構想を描いていくもので、Fresche Solutions社のコンサルティングチームが世界各地に赴いてサービスを提供する。同チームの参画する超ビッグプロジェクトが、世界中でいくつも動いているようだ。
「企業やプロジェクトの規模によらず。日本でもこうしたコンサルティングサービスの必要性を強く感じています。当社ではFresche Solutions社からスキルやノウハウを吸収し、2018年度中には国内でもDiscovery Serviceの提供を開始したいと考えています。2017年10月にベル・データ様との協業をスタートさせる一方、当社のパートナーである第一コンピュータリソース様とも連携し、IBM iモダナイゼーションに向けたエコシステムの整備に取り組んでいます」（鎌田氏）
IBM iユーザーが選ぶ
モダナイゼーションのアプローチ
IBM iのモダナイゼーションには、企業の現状や課題、方向性、そして前述した「活かす資産」「捨てる資産」の考え方に応じて、さまざまなアプローチがある。以下に概要を紹介しよう（図表3）。
保守改良型
RPG開発者の不足が懸念され、ベテランから若手への世代交代が進むなか、人的リソースの観点から、現状のRPGアプリケーションを今後も変わらず保守できるのかと、危惧するユーザーは多いだろう。
ドラスティックなモダナイゼーションには着手しないと決定した場合でも、現行のプログラム資産を可視化・分析することで、社内でのRPG開発者の育成と並行しながらアプリケーション保守を効率化したり、今まで自社で実施していたアプリケーション保守を外部に委託するなどして、保守業務そのものを改革することもモダナイゼーションの一環と考えられる。
インターフェース刷新型
ビジネスロジックには手を加えず、昔ながらの5250画面を廃止して、GUIやWeb画面へ刷新する。インターフェース刷新は、モダナイゼーションの入口に位置づけられる。
これは従来から、「リフェーシング」「リインターフェース」などと呼ばれてきた。5250画面をラッピングしてGUI化／Web化する、Web画面へコンバートする、新たなGUI／Web画面を作成するなどの手法がある。スマートデバイスで基幹データを活用する、いわゆる「モバイル化」もモダナイゼーション手法の1つである。
IBM iの「古くさいイメージ」は、昔ながらの5250画面に起因する部分も大きいので、見栄えを一新することで、若手社員を中心とする「5250アレルギー」を解消できる。また短期間で結果を出せるので、経営層に向けてもアピールできる。
最近ではモバイル端末独自の機能性を活かし、現場に密着したモバイルアプリケーションを実現することで、単に画面の見栄えを変えるだけにとどまらず、現場の業務改革を推進する原動力ともなっている。
リプレース型
RPGで開発された現行システムを、パッケージ型システムへリプレースする。パッケージ型なので、RPGを使った自社でのアプリケーション保守は不要になる。
ただし現在IBM iで基幹システムを運用するユーザーは、パッケージ製品だけでは対応しきれない独自要件を抱えることが多いので、パッケージ製品を導入した場合でもベンダーによるカスタマイズ開発で対応するケースがよく見られる。
リライト型
ビジネスロジックはそのままに、現行のプログラムソースを別の言語へ書き替える。たとえばRPGプログラムをツールにより、Javaプログラムへストレートコンバージョンする。もしくはJavaアプリケーションを新たに構築するケースもある。
Javaへのストレートコンバージョンによるメリットとしては、開発工数やコストを最小化して現行のビジネスロジックを継承できること、Javaであれば開発者の育成・確保やスキル継承が（少なくともRPGよりは）容易であると期待できる点などが挙げられる。
さらに当面はIBM i上でJavaアプリケーションを運用するものの、移植性や相互運用性に優れたJavaであれば、将来的に（もしIBM iがなくなったとしても）オープン系サーバーへ移行して運用を続けることが可能であるとの判断も働くようだ。
またリライトという観点では、RPG ⅢのソースをILE RPGへ、もしくはフリーフォーマットRPG（以下、FF RPG）へコンバートする「Arcad Transformer RPG」（三和コムテック）なども提供されている。
FF RPGは、Javaなどオープン系言語との親和性が高いので、RPG開発者とオープン系開発者のスキル共有や人材育成の面でも期待されている。現行の資産を分析したうえで、インターフェース周りや保守・改良の頻度が高いプログラムだけを選択的にFF RPGへコンバージョンすることで、今後の開発生産性や保守性、機能性を高められる。
リビルド型
新たな業務要件、新しいビジネスモデルやサービス、新規事業などへの対応を目的に、RPG以外のツールや言語を使って、新たなシステムをスクラッチ型で開発する。これがリビルド型である。
これには「Profoundシリーズ」（三和コムテック）などILE RPGのプログラムソースを自動生成するツール、あるいは「LANSA」（ランサ・ジャパン）、「Delphi/400」（ミガロ.）や「SOFLA AG」(ソフラ)、Javaアプリケーションを自動生成する「GeneXus」（JBCC）、JavaScriptのソースを生成し、FF RPGにも対応する「Valence」（ミガロ.）など非RPG型のリビルドツールがある。
ハイブリッド型
全面再構築、全面移行のコストやリスクを最小化するため、既存資産を活かせる場合はRPGプログラムを残しつつ、前述のリビルドツールで新システムを構築し、連携・共存させる。IBM iのモダナイゼーションでは、こうしたハイブリッド型（共存型、ミックス型）の取り組みがよく見られる。
たとえばビジネスロジックはRPGで残しつつ、画面周りなどフロントエンド系は新しいツールや言語で開発するという、プログラム領域を棲み分けたツールミックス型がその一例である。
また従来のRPGに対してPHPやJava、JavaScriptなどのオープン系言語、さらにNode.jsやNginxなどのオープンソースソフトウェアを活用するオープン系混在型も考えられる（本号のユーザー事例として紹介している九州三菱自動車販売では、IBM i上でNode.jsを利用し、RPGの基幹システムと連携する新しいアプリケーションを開発している）。
スキル統一型
最近はRPGでの開発を継続するものの、IBM iに関してもオープンの世界で標準とされている開発手法や開発環境に統一しようという動きが見られる。
たとえばEclipseベースの統合開発環境である「IBM Rational Developer for i」（RDi）を採用して、RPGの開発環境をオープン系のそれと統一させる。あるいはオープンソースの世界でよく利用されているソフトウェア構成管理ツール「Git」や、クラウド環境での開発を目的にしたWebブラウザベースの統合開発環境「Eclipse Orion」をIBM iでも採用する例などが挙げられる。
人材育成を考える場合、オープン系技術者がIBM iの開発に携わる際に最も大きな障壁となるのは、言語自体の特性ではなく、エミュレータの存在であると指摘されている。そこで開発環境をオープン系と統一し、「脱エミュレータ化」を図ることで、IBM iの開発人材の拡大を図る。これもモダナイゼーションの一環と捉えることができる。
リホスト型
運用環境を変えるリホスト型には大きく、クラウド化とオープン化の2つがある。
クラウド化では、オンプレミス型で運用しているIBM i環境をクラウドサービスへ移行する。クラウドサービスへの移行は、現行のRPG資産をそのままIaaS型のクラウド環境へ移すことで、ハードウェアの運用管理や保守サービスの停止といった問題からユーザーを解放するメリットがある。
またオープン化は、IBM iの利用から撤退し、オープン系サーバーへ完全移行する場合である。前述したリライト型で見られるJavaへのストレートコンバージョン、あるいはリビルド型のJavaアプリケーション構築時に、IBM iではなくオープン系サーバーを選択して移行するケースが見られる。ただし、Part2の「特別対談 現行資産の可視化・分析がモダナイゼーションへの第一歩である」でも語られているように、オープン系サーバーへの移行プロジェクトは難航するケースも多く、安易な計画の下での実施はあまり薦められない。
DBサーバーはIBM iで
アプリケーションはオープン系で
前述したハイブリッド型には、Javaアプリケーションをオープン系サーバーへ移行する一方、データベースはIBM iに残すケースも含まれる。
JBCCでSIビジネスを統括する中野恭宏氏（執行役員、SIイノベーション事業部 事業部長）が描くのは、「現行資産を活かしつつ、Javaを軸に、段階的に新プラットフォームへ移行する」というモダナイゼーションシナリオである（図表4）。
段階的な移行の最初のターゲットとなるのはアプリケーション。つまり脱RPG路線を掲げ、アプリケーションはJavaで新たに構築し、オープン系サーバーへ移行させる一方、データベースはIBM i上で運用を継続する。つまりアプリケーションサーバーはオープン系で、DBサーバーはIBM iで、という意味でのハイブリッド型である。
同社では、JavaアプリケーションやDBを自動生成する超高速開発ツール「GeneXus」を中核に、その上流工程に位置して設計情報をリポジトリで一元化し、分析から設計、さらにGeneXusへの連携をトータルにサポートする「Xupper Ⅱ」を組み合わせたモダナイゼーション提案を活発化させている。さらに状況に応じては、RPGのプログラム資産を分析・可視化する「REVERSE COMET i」を推奨するケースもある。
「IBMは2016年に、今後10年のIBM iロードマップを発表しました。つまり、少なくとも今後10年はこのプラットフォームを使えるわけですから、決してオープン化を急ぐ必要はないと考えています。ただし、IT市場全体で技術者の不足が懸念されるなかでも、RPG開発者の人材不足は深刻で、世代交代も進んでいます。IBM i環境が今後変わらず提供されたとしても、RPGプログラムを開発・保守する技術者がいなくなれば、使い続けることはできません。そこで我々はアプリケーションをJavaでオープン系サーバーへ移行させる一方、データベースはIBM iに残し、DBサーバーとして引き続き運用していくモダナイゼーションをご提案しています。お客様の資産はプログラムではなく、データベースである。データベースを守っていくことが、お客様の資産を守ることであるという考え方です」（中野氏）
現在同社では、年間50件以上のGeneXus案件を手掛けるが、その70?80%はIBM iユーザーである。GeneXusで自動生成したJavaアプリケーションはIBM i上でも利用できるが、同社ではパフォーマンスや将来構想などを踏まえ、オープン系サーバーでの稼働を提案している。上記のGeneXus案件のなかで、IBM i上でJavaアプリケーションを運用しているケースは1件もない。ただし、IBM iから完全撤退したユーザーもいないという。JBCCの描くシナリオどおり、混在型なのである。
「お客様のなかには、いろいろと分析した結果、どう考えてもバッチ処理はRPGで継続したほうがよいとの結論に至るケースもあります。そうした場合は、バッチ処理はRPGで残し、Web画面をはじめとするフロントエンド系や改修頻度の高いプログラムだけを選別してJavaで構築し、オープン系サーバーで運用します。つまりJavaとRPGの混在型でもあるわけです。実際のところ、予算やリスクを考えて、完全な脱RPG路線を避けるお客様のほうが多いと言えるかもしれません」（中野氏）
—————————
モダナイゼーションに向けて、どの資産を活かし、どの資産を捨てるのか。
捨てるのはエンドユーザーが毎日向き合う5250画面なのか、RPGのプログラムなのか、言語独自のスキルなのか、開発環境としてのエミュレータなのか。
あるいはアプリケーションを捨てて、データベースを活かすのか。内製主義を捨てて、自らの手で実施していたアプリケーション保守を外部へ委託するのか。あるいはオンプレミスベースでの運用環境からクラウドへ移行することで、「自社で所有するIBM i環境」を捨てるのか。
活かす資産と捨てる資産を決めることが、モダナイゼーション・ロードマップの基点であり、その決定が今後のロードマップの道筋を示してくれることは間違いなさそうだ。
