IBM i アプリケーションの
モダナイゼーション方法論
ハイブリッドクラウド化やサービス化を目指したIBM iアプリケーションのモダナイゼーションを開発言語の種別ごとに分類すると、以下の3つになる。
①JavaやPHPなどオープン系言語資産
Webアプリをファクタリングし、マイクロサービス化→REST化→コンテナ化する。呼び出しインターフェース（RPC、SOAP）をRESTに変更する。
② 非オープン系言語資産
RPG、COBOLなどレガシー言語アプリケーションは呼び出しインターフェースをREST化する。バッチプログラムにRESTインターフェースを追加。 エミュレータ利用のアプリケーションは画面インターフェースを除外してバッチプログラム化、またはエミュレータ画面をRESTラッピングする。
③新規開発
Python、Node-js、Node-REDなどOSSで新規開発する。クラウドネイティブ、コンテナ化前提で開発。すべてプログラミングするのでなく、IBM iサービスを活用して開発工数削減を図る。
既存資産はレガシー系言語やオープン系言語を問わず、あらゆる資産をすべて活用可能である。基本的な方針はRESTインターフェースの付加とサービス粒度を考慮したプログラム分割である。
保守性の観点から、共通機能の洗い出しや集約も重要な作業になる。共通機能はサービスプログラム化するのが基本方針である。また昨今、IBM iは外部からRESTサービスなどを使用してIBM iのOS機能やシステム資源をサービス利用するための「IBM iサービス」と呼ばれる数多くの機能テンプレートを提供している（本特集の最後にサービス内容一覧を掲載）。
従来、手組みでCLやRPG／COBOLでプログラミング開発していたロジックをIBM iサービスに置き換えれば、ユーザー固有の実装排除や開発コード量の削減に寄与できるので積極的に採用を検討すべきである。
JavaやPHPなどオープン系言語資産のモダナイズ方法
Javaを例に説明すると、レガシーなJavaアプリケーションのEAR、WARに含まれる複数の機能に対し、CI／CDサイクルをアジャイル開発する際の生産性に着目して機能分割する。
分割した機能ごとにRESTインターフェースを付加し、サービス（マイクロサービス）として実装し直す。コンテナ化が有益なアプリケーションについては、さらにコンテナ化する（図表1）。
非オープン系言語資産のモダナイズ方法
RPG、COBOLなどのレガシー時代から存在するアプリケーション言語についても、サービス化が可能である。方法は①とほぼ同じで、CI／CDの観点でプログラムの分割を検討する、複数プログラム間で類似の機能はサービスプログラム化する、というのが第1段階となる（図表2）。
さらに分割したRPG、COBOLプログラムにRESTインターフェースを付加することでサービス化が可能となる。場合によってはJSON対応も可能である。対話型アプリケーションの場合、5250画面を外してバッチ化する方法を採用すると、より柔軟性は高まるが、アプリケーション改修の難易度（RPG、COBOLの改修工数）は高くなる。
そのため代案としては、5250をWeb（HTTP）→REST とラッピングする方法も考えられる。ただしこの手法だと、極論すればRPG、COBOLアプリの改修をゼロにすることも可能であるが、アプリ動作は5250が基準となるため改修の柔軟性は限定される。
新規開発
新規開発の場合は、他のプラットフォームと基本的に同一である。OSSを中心に最適な言語を使って開発すればよい。要件によっては、IBM i上でRPG、COBOLでクラウド側と通信するプログラム（サービスプログラムなど）が必要になるかもしれない。
もしIBM i上の各種リソース（DB、OS管理のシステム資源、ユーザー作成スプールなど）をクラウド側からも利用したい場合は、IBM iサービスを使用して実装すればアプリケーション開発工数を削減し、機能を標準化できる（図表3）。
IBM iでは開発言語のバリエーションが豊富なので、図表4のような選定基準を参考にしよう。最初に検討するのはアジャイルの要否である。そのうえで他の要件も鑑み、言語選定するのが合理的である。
IBM i資産のサービス化をどう進めるか
一般にIBM i のプログラム本数は、1000本～数千本を超えるユーザーが大半だと思われる。結論を言えば、そのようなユーザーではビッグバンによるアプリケーションの全面再構築はほぼ不可能であろう。
そもそもマイクロサービス化の目的は、CI／CDを実現することで企業価値を高めることにあるので、CI／CD準備フェーズとも言える移行期間に年単位を要するのでは本末転倒である。
またすべてのアプリケーションをサービス化してクラウド展開すると、さまざまなデメリットも懸念され、この点でも現実的とは言えない。
アプリケーションサービス化対象の選定基準は、以下のとおりである。
基準1 ビジネス視点での適合性から選定
① 成長が予測されるビジネス分野
② ビジネス要求からの変更頻度が高い（頻繁に拡張・改修が見込まれる）
・ 改修影響範囲を極小化できるアジャイルの価値が活きる
・ アジャイル不要、CI／CDが不要ならマイクロサービス化する意義は薄まる
・ アジャイル不要、CI／CDが不要ならマイクロサービス化する意義は薄まる
基準2 IT視点での適合性から選定
・ 基準1に加えて、サービス化の移行容易性などを加味して対象アプリケーションを絞り込む
繰り返すが、基準2で言うところの「IT視点でのサービスの容易さ」を第1優先順位と考えてはならない。サービス化対象アプリケーションは、必ずビジネス的価値が見込まれる領域から着手すべきである。マイクロサービスアーキテクチャはアジャイル、CI／CDを適用して初めて価値が生み出されるからだ。業務的に何らアジャイルの必要性がない領域をサービス化しても、企業視点で価値を生み出すことはない。
業務視点でサービス化対象領域を絞り込むのは主にコンサルティング的手法に属するため本稿では省略するが、対象ビジネス領域を特定する手法例としては、IBM Component Business Model （CBM）、Strategic Capability Network（SCN）などがある（Column 4）。
マイクロサービス化はクラウドサービス連携やコンテナのような新技術要素をふんだんに検討するため、それだけに注力すると成果が中途半端になる。アジャイルやCI／CDの定着には現業部門を含む部門役割や連携の再定義、アジャイルやデザイン思考スキル育成などITのテクニカル領域以外でも大きな改革が不可欠である。
未見の多彩な技術を使ったアプリケーション再構築といった各論ばかりに目が行きやすく、全体の整合性や企業イノベーションの目的地がブレやすくなるため、ビジネス・ITの両視点を包含したハイブリッドクラウド移行（中期）計画書を取りまとめることを推奨する（Column 5）。
段階的なモダナイゼーションアプローチ
既存のモノリシックなアプリケーションを段階的にモダナイゼーションするために、アジャイルやCI／CDの必要性が高いアプリケーションロジックから段階的に切り出していく（図表5）。
切り出したロジックはREST API接続やデータのJSON化を主軸としてマイクロサービス化する。同時にKubernetesコンテナ化も可能なので、価値が見出せるならコンテナ化も行う。
サービス化したアプリケーションモジュールは、ハイブリッドクラウド移行（中期）計画に規定した将来構想に最も適するアプリケーション開発言語（OSS、Java、RPG、COBOL、その他）、稼働インフラ（クラウド、オンプレミス、IBM i、その他）を選定して再構築する。
著者｜
佐々木 幹雄
日本アイ・ビー・エム株式会社
システム事業本部 Power Systemsテクニカル・サポート
コンサルタントITスペシャリスト
システム事業本部 Power Systemsテクニカル・サポート
コンサルタントITスペシャリスト
AS/400誕生とほぼ同時期からIT業界に関わる。IBM i やPC、ネットワーク機器など一般企業のIT基盤の提案・構築、アーキテクトなどを幅広く経験。IBM i エバンジェリストとしての活動もある。
････････
特集｜IBM iのマイクロサービス化
････････
Column 1 OpenShiftかKubernetesか
Column 2 どこでもKubernetes
Column 3 ミドルウェアのコンテナ化対応
Column 4 SCNは戦略策定のためのフレームワーク
Column 5 ハイブリッドクラウド移行（中期）計画を作る
Column 6 アジャイルはSoEだけのものか？
Column 7 IBM iサービスとDb2 for iサービス
Column 8 IBM iのクラウドサービス
Column 9 コンテナテクノロジーを導入しても、イノベーションは起きない
［i Magazine 2020 Spring掲載］
