【レガシーシステム近代化へのアプローチ　第2回】ブラックボックス化したIBM i（旧AS/400）アプリにメス　ツールによる全容把握でノウハウを平準化（連載全3回）

－「IBM i（AS/400）」上で稼働するアプリケーションを長く使い続ける企業は少なくない。長く使い続けることでどんな問題が起こりうるのか？ 阿野：IBM iユーザーは今なお多く、20年、場合によっては30年以上前に開発したアプリケーションを使い続ける企業は珍しくありません。しかし“古いアプリケーション”ゆえに、最新テクノロジを活用しにくい、最新の機能を備えていないなどの課題が顕在化しつつあります。 　一方で、アプリケーションを理解する人が減っていることも大きな問題です。アプリケーションの導入や運用に関わったエンジニアが、定年を迎えるなどして現場から離れつつあるのです。アプリケーションに問題が発生した場合、誰がどう対処すればいいのか分からない。そんな問題に直面する企業が増えています。IBM iのアプリケーションに精通するエンジニアを定年後に再雇用するケースも見られますが、それでは問題を先送りにしたに過ぎません。問題が発生したときに対応できる体制を社内に構築することが大切です。若手エンジニアへのスキルやノウハウの承継にも取り組む必要があるでしょう。 －若手エンジニアへのIBM iアプリケーションのスキルやノウハウの承継は十分進んでいない？ 阿野：スキルやノウハウの承継に取り組む企業はいます。しかし、承継しさえすれば大丈夫、という話ではありません。アプリケーションの開発を大勢の社内エンジニアで開発したり、外部のソフトハウスやSIerに開発を委託したりする場合、承継されるスキルやノウハウが断片的になりやすい。そのため、アプリケーションの全容を把握できずにいる企業が多いのです。エンジニアの多くが自分の関わった領域しか分からないため、それ以外のアプリケーション領域についてはブラックボックス化しやすいのです。複数の外部委託先を使うことによるブラックボックス化も少なくありません。 －アプリケーションを可視化する“ドキュメント”を整備し、承継に用いるべき。 阿野：外部のソフトハウスやSIerにアプリケーション開発を委託する場合、原則として納品物に仕様書や設計書といったドキュメントが含まれます。しかし、そのドキュメントはほとんど更新されず当時のまま、というケースが目立ちます。つまり、アプリケーション納品後の機能追加やカスタマイズに関する内容をドキュメントに反映していないのです。そのため実際のアプリケーションとドキュメントの内容は乖離し、ドキュメントを若手エンジニアに渡せば承継完了、とは必ずしもならないのです。 －アプリケーションを理解するのに欠かせないドキュメント。なぜ更新しないのか。 阿野：納期に追われがちなアプリケーション改修を優先するからです。ドキュメントは改修後に更新すればいいと考えるケースが多い。ただし、多数のアプリケーションを頻繁に改修する場合、ドキュメントの更新が追いつかなくなってしまいます。特に、改修したプログラムが周囲のどのプログラムに影響するかといった影響分析の内容を、ドキュメントに漏れなく反映するのは手間と時間がかかる。こうした負担が、ドキュメントを更新しない大きな要因となっています。

－いっそのこと、古いアプリケーションをERPなどに入れ替えるのも手だが。 阿野：アプリケーションの対象領域によっては、ERPやSaaSに入れ替えることでブラックボックス化を解消できるケースもあります。例えば会計はこれらへ移行しやすい領域といえます。企業ごとに会計業務の進め方や作業内容の差異が少なく、最新ERPに合わせた業務の見直しなどが軽微で済むからです。 　一方、生産管理や購買・調達向けのアプリケーションは、自社独自の機能を盛り込むことが珍しくありません。ERPに移行するならフィット＆ギャップ分析を実施し、最新アプリケーションの機能と業務プロセスの差異を洗い出さなければなりません。しかし、ERPと業務プロセスがどのくらい乖離しているのかが、企業は分からない。ドキュメントがなく、アプリケーションを十分理解せずに運用しているため、ギャップ（乖離）を洗い出せないのです。もし、生産管理や販売管理向けアプリケーションをERPに移行するなら、アプリケーションプログラムのロジックやビジネスルール等を読み取り、独自仕様の機能を把握するしかありません。しかし、膨大な独自仕様の機能をロジックとビジネスルールからすべて読み取る作業は現実的ではないでしょう。 －時間とコストがかかるかもしれないが、企業はIBM i上の“古いアプリケーション”を1つずつ可視化、もしくは最新アプリケーションに移行するプロジェクトを今から進めるべき。 阿野：実は、その必要性を感じない企業が多いのです。なぜなら、IBM iはアプリケーションの高い継承性を強みにしています。AS400の前身である「System/36」や「System/38」で稼働していたアプリケーションさえ、手を加えることなく動いてしまう。IBM iユーザーにとっては、古くても問題なく稼働しているアプリケーションをなぜ買い替えなければ、と考えてしまうわけです。トラブルなく安定稼働するアプリケーションにメスを入れようとは思わないのです。 　とはいえ、今後のデジタル化社会を見据えたとき、手を加えられないアプリケーションを運用し続けるのは大きなリスクです。事業領域や規模に応じて複数のクラウドを選択利用するのが当たり前になった今、クラウドと容易に連携できないアプリケーションは業務の足かせになりかねない。今からでもアプリケーションのブラックボックスを解消し、次代に合う柔軟なシステムを構築できる体制を模索しなければいけないと思います。

－ブラックボックス化しつつあるIBM iアプリケーションを可視化するには、どうすればいいか。 阿野：IBM i上で稼働するアプリケーションであるプログラムやファイルが数千、数万に及ぶ企業は珍しくありません。これらアプリケーションのロジックやビジネスルールを1つずつ読み取って可視化するわけにはいきません。そこでこうした読み取り作業を代行するツールを使うのが現実的です。代表的なのが、IBM iに特化したアプリケーション可視化/解析ソフトウエア「X-Analysis」です。ソフトウエアを使うことで、数千、数万ものアプリケーションを可視化できるようになります。

－X-Analysisを使うと、具体的にどういったことができるのか？ 阿野：現在のオープン系システムでは一般的な方法としてリポジトリを作成し、アプリケーションの中身をデータベース化しています。アプリケーションの「設計書」を作り出すためのツールではなく、データベースから必要な情報を参照できるようにするのが特徴です。データベースからアプリケーション情報をインタラクティブに取得し、最新情報に基づく可視化を可能にします。 　例えば、任意のプログラムがどのプログラムとデータをやり取りしているのか、どのプログラムがどのファイルを利用しているのか、プログラムがどういった順番で使われているのかなどを把握できます。 　BIツールのようなダッシュボードを使い、アプリケーションをビジュアル的に可視化するのが売りです。関連情報をただ冗長的に並べるのではなく、ER図やフロー図などを使って分かりやすく可視化します。これにより、IBM iアプリケーションに詳しくない若手エンジニアでも、アプリケーションの内容を理解しやすくなります。IBM iアプリケーションに精通する熟練エンジニアから若手エンジニアへスキルやノウハウを分かりやすく伝えるといった用途でも役立ちます。IBM iに触れたことがないエンジニアでもアプリケーションを調べられるといったメリットも見込めます。

　影響分析機能を備えている点も強みです。例えば、ファイルフィールドの桁数が10桁から12桁に変わったとします。このときの影響がどのプログラムの変数に及ぶのかを洗い出します。ファイルフィードを任意の変数に置換し、また、繰り返し他の変数やフィールドに代入した場合でも、その置換先も含めて影響範囲を割り出すことができます。一般的なツールの場合、影響するであろう任意の文字列を検索し、該当する文字列を含むソースしか影響範囲を割り出せないため、影響範囲に抜け漏れが生じるケースが珍しくありません。

　そのほか、ドキュメントの作成を支援する機能や、コードの複雑度分析機能やビジネスルールの抽出機能、アプリケーションの品質を約60項目に分けて評価する機能なども備えます。System/36やSystem/38を含む、すべてのIBM iシリーズで稼働するアプリケーションを可視化します。 －X-Analysisはどんな使い方を想定している？ 阿野：X-Analysisはライセンス販売するソフトウエアで、利用対象者はIBM iを使う企業の情報システム部門担当者などです。1つのアプリケーションを可視化するのにX-Analysisを一度使う、という使い方ではなく、毎日利用することで効果を最大化できます。IBM iアプリケーションについて調べるとき、X-Analysisを使ってデータベースから必要な情報を引き出すといった使い方を想定します。アプリケーションにトラブルが発生したり、他のアプリケーションと新たに連携したりするときにX-Analysisで調べるケースは少なくありません。 －X-Analysisを導入することでどの程度の効率化を見込めるのか？ 阿野：例えば、自分が担当していないジョブが落ちるといったトラブルが発生したとします。担当者は不在で、自分がどうにかしなければならない。こんなときにX-Analysisを使って調査を実施するケースは少なくありません。規模によりますが、こうした調査にかかる時間を約30％短縮させることができます。落ちたプログラムではどんなファイルを利用しているのか、連携するプログラムには何があるのかなどを効率よく洗い出せます。アプリケーションの計画的なメンテナンスの実施時間短縮も見込めます。 　影響分析なら、調査でより大幅な時短を見込めます。アプリケーション数などに依存するものの、影響分析に要する時間を10分の1や100分の1まで短縮したケースを聞きます。IBM iアプリケーションについて十分理解していない、自分の担当外の領域を調べなければならないなどのケースほど、大きな導入効果を見込めるでしょう。 －X-Analysisを使いこなすには、ツールを操作できるスキルも求められる。 阿野：BIツールのように直感的に操作できますが、当社や当社の販売パートナーでは、操作を習得できるトレーニングプログラムを用意しています。8時間のプログラムを受講することで基本的な操作を習得できます。 －X-Analysisを使えば、これまでブラックボックスだった多くのアプリケーションを容易に可視化、調査できるようになる。 阿野：DX時代に求められるシステムには柔軟性が欠かせません。とりわけ新規事業を早期展開するようなケースでは、業務を支援するシステムを短期間で構築、運用できるようにしなければならない。しかし既存の基幹アプリケーションがブラックボックスでは短期構築どころかシステム連携すらままなりません。X-Analysisはこうした課題を解消し、これからの時代に追随するシステム構築に外せない役割を担うと考えます。 　さまざなアプリケーションをDX時代にふさわしい姿へと昇華させるには、アプリケーションに対するノウハウの「平準化」こそ重要な取り組みです。しかし“手作業”では時代に取り残されかねない。平準化作業を強力に推進し、自社システムに柔軟性を付与させるには、X-Analysisのようなツールを徹底的に使いこなす体制構築や人材育成にこそ目を向けるべきです。

―――――――――――――――――――――――――――
第2回の連載はここまで。第3回では、X-Analysisの具体的な導入事例や、IBM iを運用する企業の情報システム部門がDX化を目指すために必要な姿勢や考え方について紹介します。