IBM Power

レガシーアプリケーション近代化への新しいアプローチ

記事をシェアする:

「DX」という潮流に乗るために、レガシー (既存) アプリケーションの刷新の検討をするユーザーは少なくありません。しかし、今後10年先を見据えたシステム像を描くとき、大事なのはレガシーの切り捨てではなくシステムの本質を正しく見極められるかどうかです。では、「本質を探るときのポイントと、その後のDX対応の現実解は何か」。この問いに対する解をさぐるべく、長年、お客様各社のレガシーアプリケーションの解析を実践してきたジーアールソリューションズ株式会社 阿野幸裕氏にインタビューしました。(インタビューアー:IBM久野)

基幹アプリケーションをとりまく現状の変化

- IBM i(AS/400)上で稼働するアプリケーションを長く使い続ける企業が数多く存在します。阿野さんから見てこれらの企業で何か変化が出てきているのでしょうか?

まずは、お客様意識の変化が挙げられます。

10年程前、アプリケーションのブラックボックスの解消のために、解析ツールの提案を行うとお客様のベテランのエンジニアの方々から「ソースコードを直接見るのと何が違うの?」「アプリの中身はわかっているから、(解析ツールは)ドキュメント化する際のちょっと助けになればいいだけ」といったお言葉をいただくことが多くありました。ところが、年々様子が変わり、属人化、ブラックボックス化、技術継承がお客様発信で課題に上がるようになってきており、現在、10年前のようなことをおっしゃる方はほぼいらっしゃらなくなっています。2025年問題に代表されるベテランの方の引退が迫っていることが大きな要因です。

一方で、その2025年問題を問題視した経営者が「IBM i 脱却」を試みたのも同じ年代となります。ですが、それは多くの失敗を生みました。

例えば、既存システムそのものを新たに作り直す場合、当然莫大なコストがかかる上、パッケージへのリプレースであれば、これまで蓄積してきた様々な業務ノウハウを捨ててしまわなければならない可能性もあります。では、機械的にコンバージョンすれば良いかというと、アプリの作り方によってはコンバージョンできない、できたとしても表面上は他のプラットフォームで稼働していてもIBM iと何も変わっておらず、システム変更などが結局RPGなどの言語ノウハウがないとできない、IBM i時代のパフォーマンスが出ずにインフラに相当コストをかけなくてはならないなどの問題が数多く発生し頓挫するプロジェクトが多発しました。ここまでの冒険をなぜ経営者が決定したかというと、国産メインフレームや国産オフコン等のミッドレンジ・コンピューターの撤退が不安をあおったと思われます。

その後、IBM i の10年以上先を見越した新バージョンのリリース・ロードマップが浸透するにつれ落ち着きを取り戻しました。2020年代前後においては「(IBMから) 脱却する」といったユーザーは少なくなりました。IBM i に残すものは残す、外に出す方が良いものは出して、連携を取るという現実的な道を進むユーザーが増えてきました。

<図1>IBM i の問題はプラットフォームではない

ジーアールソリューションズ社提供

-IBM i に残すアプリケーションとIBM i の外部で構築するアプリケーションの分担について特徴はありますか?

まず、業務特性が挙げられます。

ユーザーの業務は水平型と垂直型に分類されます。水平型とは、業界を問わず共通的または特定の部門に特化した業務(人事、会計、SFA等)です。垂直型とは、業界に特化した業務(製造・物流、建築、医療、金融、サービス業等)です。水平型業務がまず外部に構築される傾向にあり、垂直型の中で、その業界において企業特化性の少ない水平型業務が2番目となります。どちらも相当するパッケージやSaaSがあるかどうかという点が大きなポイントになっています。

次に、現行のIBM i 業務アプリとしての独立性と独自性、重要性の度合です。個別の業務システムとしての独立性が高くないと、IBM i の外部で再構築した途端に、多数で複雑なデータやプログラム連携が必要となり、結局、IBM i に戻るといったことが起こっています。また、独自性、重要性の高い垂直型業務の中でも、さらに企業毎に独自性の強いものは重要度も高く、その仕様の読み取りや、外出しのメリットがあるかどうかの判断は非常に重要なものとなっています。

-IBM iの継続利用には、次世代を担うエンジニアへのアプリケーションのスキルやノウハウの継承が必要との声が聞かれます。

前述の状況もあり、現在は、ベテランIBM i エンジニアのスキルやノウハウの継承に取り組む企業が増えています。

しかし、それは簡単な話ではありません。過去、アプリケーションの開発を大勢の社内エンジニアで行っていたり、外部のソフトハウスやSIerに開発を委託していたりする場合、継承されるスキルやノウハウが断片的なため、アプリケーションの全容を把握できずにいる企業が多いのです。エンジニアの多くが自分の関わった領域しか分からないため、それ以外のアプリケーション領域についてはブラックボックス化しやすいのです。複数の外部委託先を使ったことによる、ベテランも全容がわからないブラックボックス状態も少なくありません。

こうなると「IBM iに残すものは残す、外部に再構築した方が良いものは出して、連携を取る」ということもすぐには着手できなくなってしまいます。

-技術継承を迅速に進めるには、そのシステム化も必須

仕様書や設計書など、ドキュメントがほとんど更新されず、当時のままで継承がスムーズに進まないと考えているユーザーが見受けられます。

しかし、ドキュメントを次世代を担うエンジニアに渡すだけでは継承完了とはなりません。実践が必要なのです。ドキュメント化だけでなく、次世代エンジニアの開発やメンテナンス、テストなど実践的な作業における効率化やノウハウ平準化のために解析ツールを導入するユーザーが増加してきています。

<図2>技術継承は、若手の技術者の視点で考える

ジーアールソリューションズ社提供

実践をサポートし技術継承とモダナイゼーションを促進させる「X-Analysis」

-ユーザーによってはブラックボックス化しつつあるIBM iアプリケーションを可視化するには、どうすればいいでしょうか?

IBM i 上で稼働するアプリケーションであるプログラムやファイルが数千、数万に及ぶ企業は珍しくありません。人手で全てを把握するのは困難なため、アプリケーション解析ツールを使うのが現実的です。このデファクトスタンダードツールが、世界5,000社以上、日本でも100社以上に導入されている「X-Analysis」です。

既存顧客からの要望を積極的に取り入れ機能強化を図っている点が評価されており、俯瞰レベルから詳細レベルの可視化機能、調査工数を劇的に短縮できる影響分析機能、アプリケーションの品質評価と問題抽出ができる監査機能などが実装されています。

-X-Analysisを使うと、具体的にどういう技術継承ができるのでしょうか?

IBM i の技術継承において、以前の方法では、アプリケーションに到達する前に障壁がありました。OSの基本操作、コマンドを覚えてそれらをグリーンスクリーンで行わなければならないこと、プログラム、DBを始めとしたオブジェクトなど資産の在り方を理解する必要があったことなどです。実は、今やGUIでの開発・運用はある程度、IBM純正のオプションや製品でできるようになっておりますが、これらがあまり情報継承、利用されてこなかったために旧態依然のやり方を続けているユーザーがいらっしゃいます。

X-Analysisは、アプリケーションをビジュアルに可視化するのが売りです。関連情報をただ冗長的に並べるのではなく、ER図やフロー図などを使って分かりやすく可視化します。これにより、IBM iアプリケーションに詳しくない次世代エンジニアでも、アプリケーションの内容を理解しやすくなります。IBM iアプリケーションに精通する熟練エンジニアから若手エンジニアへスキルやノウハウを分かりやすく伝えるといった用途でも役立ちます。IBM iに触れたことがないエンジニアでもアプリケーションを調べられるといったメリットも見込めます。

<図3>X-Analysisの機能

ジーアールソリューションズ社提供

X-Analysisの機能の詳細は下記サイトに公開されています。
https://www.gr-sol.co.jp/x-analysis/category/product-details/

-X-Analysisを使うと、具体的にどんな支援が得られるのでしょうか?

例えば、ある製造業のユーザーでは、長年利用されてきたIBM i 上の主要システムが、これまで支社、工場などの拠点毎にそれぞれの開発・運用が行われ、システム全体像を示す開発ドキュメントがなくブラックボックス化していました。また、工場システム担当者の技術継承対策も急務でした。

X-Analysisの導入により解析された情報は、システムを俯瞰的な視点で評価できるため、開発経験が少ない技術者が、新たに参画した場合には、X-Analysisの解析情報そのものが引き継ぎ書の役割を果たし、そのビジネスの即戦力的な効果を引き出すことに成功しています。また、支社、工場間での技術者交流会を行い、X-Analysisを使った問合せ調査・トラブル対応時の活用事例を収集して、標準化を行い、ガイドラインとすることで、より充実度の高い開発業務へと意識変化が起こっています。

また、別のユーザーでは、IBM i はバックオフィスシステムの役割を担い、ビジネスの変化に合わせて変更・新規開発が多いフロントシステムはパッケージ・ソフトウエアによりIBM i の外側に構築されて、相互にデータ連携を行って稼働しています。必然的にフロントシステム系エンジニアの比率が高まり、IBM i の専任エンジニアは1名となりましたが、フロントシステム系エンジニアもデータ連携のためにIBM i 側のアプリケーション仕様を理解する必要があることと、将来的にはIBM i アプリケーションを維持・管理するための技術継承が必須であるため、その解決策としてX-Analysisの導入と利用が始まりました。

IBM i 導入時より担当するベテランとオープン系言語で育った若手の間で、Eclipse GUI解析ソリューション、X-Analysisという共通環境を通じて情報共有が進み、フロントシステム系のシステムからIBM i のデータベースに直接アクセスするプログラムの修正や、新規アプリケーション開発の効率化とスピードアップを実現する事ができました。

<図4>X-Analysisの実践効果

ジーアールソリューションズ社提供

X-Analysisの事例は他にも実名で数多く公開されています。
https://www.gr-sol.co.jp/x-analysis/review/

技術継承後のIBM iのモダナイゼーションとは?

-既存のIBM i アプリケーションを最大限活用するためにAPIの利用も活発になっていますね。

「APIエコノミー」という概念が語られだして久しくなりました。これはネットワークを介して、様々な企業が提供する機能と自社独自の機能をつなぎ合わせ、新しいサービスを構築できるようになったことで生まれたものです。

日々利用しているスマートフォンのアプリケーションも、その提供会社が独自に作った機能だけでなく、ネットワークを介して他の企業が作った機能のAPIと連携して作られています。このAPIの利用は日々発展と応用の進歩を続け、企業内の、特に水平型システムの新規構築においてもDX化を背景に標準に成りつつあります。

IBM i においても、標準搭載のアプリケーション(AP)サーバーであるIntegrated Web Service Server(統合アプリケーションサーバー)で既存のRPGやCOBOL、データベースをREST 呼び出しできるようになってきており、サードパーティのISVも様々なAPI化ツールを市場に投入してきています。

API化されれば、Webサービスやスマートフォンアプリなどを構築するエンジニアからは、IBM i のアプリケーションであるかどうかは意識する必要がなくなり、市場のエンジニアを幅広く利用することが可能となります。また、そのままモノリシックなアプリケーションをAPI化するだけでなく、X-Analysisで機能を解析後、分割コンパ―ネント化やスリム化を経て、API化していくことでより効率的でDXにおいて可用性の高いシステムを実現できます。

また、既存のアプリケーションの利用だけでなく、X-AnalysisのメーカーであるFresche Solutions社においては、フリーフォーマットRPGアプリやAPIをローコード開発できるツール「X-Elevate」を欧米では市場投入しており、ユーザーのモダナイゼーションを後押ししています。

<図5>既存アプリを活かすAPI

ジーアールソリューションズ社提供

-IBM i ユーザー様に、これからの未来を見据えた助言をお願いします。

DX時代に求められるシステムには柔軟性が欠かせません。とりわけ新規事業を早期展開するようなケースでは、尚更です。IBM i の次世代を担うエンジニアに何を残すかが重要となります。

今回は、次世代エンジニアがIBM iを新しい方法で開発・運用を行い、「誰でもアプリ開発できる」、「誰でも運用できる」一方、ハッキングに強く、また最新テクノロジーで常にアップデートしている真のオープンシステムであるIBM i を継承していくことをお薦めしました。お読みいただいたユーザーのみなさまの参考になれば幸いです。

お問い合わせ先

ジーアールソリューションズ株式会社


More IBM Power stories

IBM i 関連情報

日々進化を続ける、IBM i の最新情報を、ぜひ下記リンクからご入手ください。 IBM i 関連情報 IBM i ポータル・サイト https://ibm.biz/ibmijapan i Magazine (IBM i […]

さらに読む