【レガシーシステム近代化へのアプローチ　第1回】DX推進にレガシーシステムは邪魔？　システムの正しい理解とアプリの構造把握がカギに（連載全3回）

URLをコピーしました！

“DX”という潮流に乗るため、レガシーシステムの刷新を検討する経営者は少なくありません。しかし、今一度踏みとどまってほしい。本当にレガシーシステムはDX時代にふさわしくないのか。10年先を見据えたシステム像を描くとき、大事なのはレガシーの切り捨てではなくシステムの本質を正しく見極められるかどうか。では本質を探るときのポイントと現実解はどうあるべきか。ジーアールソリューションズ　阿野幸裕氏に話を聞きました。

IBM i（AS/400）を使い続けるべきか

－メインフレームやオフコンに代表されるレガシーシステム。中でも「IBM i（AS/400）」ユーザーは今なお多いと聞く。どのくらいのユーザーがいるのか？阿野：ミッドレンジコンピューターとして多くの企業が導入したAS/400は、その前身となるS/3シリーズを含めて、今も多くの企業がその継承環境であるIBM iを使い続けています。2000年代にはIAサーバーを中心とした一般にオープンとされるシステムの普及が進んで市場は徐々に縮小したものの、IAサーバーの信頼性や安定性に不安を持つ企業が、IBM iとその稼働環境であるPowerSystemsを利用し続けるケースが目立ちます。今も約1万社がIBM iを利用しています。

写真：ジーアールソリューションズ　阿野幸裕氏

－信頼性や安定性が強みとのこと。ならば、用途は基幹システムが多いのか？阿野：はい。特定の業種に限って使われているわけではありませんが、例えば製造業の場合、生産管理や販売管理システムなどの基幹システムの稼働環境としてIBM iを使うケースが多いですね。一方で、エンドユーザーである消費者が直接触れるスマートフォン向けアプリやWebサービスで特に基幹連携の必要のないものなどは、オープンシステムやクラウドといったテクノロジを積極的に活用する企業が多い。つまり、用途に応じてシステムを使い分けているという点では、IBM iユーザーが他の企業と大きく違うということはないですね。

図1：IBM iユーザーは、今後の正しい見極めが求められる

－約1万社と言われるIBM iユーザー。DXを推進する機運が高まる中、いよいよシステム移行を検討する企業が増えているのか？阿野：実は必ずしも増えているとは言えません。もちろん大企業の中にはIBM iから全面脱却し、全社システムの見直しと最適化を図ろうとするケースが散見されます。一方で、今後もIBM iの継続利用を見据える企業も多いのです。－IBM iを使い続ければ、DX推進やシステムの全社最適化の障壁になるのではないか？阿野：それは誤解です。レガシーシステムを使い続けることがDX推進の妨げになるとは必ずしも言い切れません。例えばIBM iの場合、2033年までのロードマップが示されています。それ以降も製品やサポートは生き残ると言うのが市場見解です。IBM iがすぐに使えなくなることはなく、「早急にシステム移行しなければ」とはならないのです。　DXに関わるシステムというと、スマートフォンのアプリやWebサービスといったフロント系のシステムを構築・運用するケースが多いですよね。顧客の変化に追随し、必要な機能を盛り込んだWebサービスを早期開発、運用開始するなどの例です。このケースでは、メインとなるシステム基盤にIBM iを用いることは原則ありません。当然、ハードウエアリソースを短期に調達できるクラウドを利用するでしょう。つまり、フロント系システムを早期開発してDXを進めるという点で、IBM iが足かせになることはありません。また、これらのフロント系システムが、IBMiの基幹データやアプリケーションと連携しなければならない場合もありますが、IBM i はレガシーなプログラム資産のAPI化を可能としており、データはRDBMSであるDB/2に格納されているため、RESTなどのインターフェイスを用いてフロントアプリケーションと簡単に融合できるようになっています。－とはいえ、“オープン化の波”に逆らってIBM iを使い続けることにメリットはあるのか？阿野：実はIBM iは、“オープン化”しています。前述のAPI化などが良い例です。さらにIBMは現在、IBM iの稼働環境として「Power Systems」を提供しています。このインフラではIBM iのほか、UNIXやLinuxといったOSを、同じ筐体上で同時稼働できます。つまり、レガシーと呼ばれるIBM i環境と、Linux上に構築したシステムを併用できるのです。IBMは「Power Systems」で各種OSの稼働するプラットフォームを共通化するることで“オープン化”に対応しているのですが、実は知らないという経営者は少なくないんです。－「Power Systems」では用途に応じた環境を構築できるのか？阿野：その通りです。さらに、Power Systemsに搭載する最新プロセッサ「POWER10」は、処理速度はもとより信頼性に定評があります。米国、EU圏では、SAP社のインメモリーデータベース「SAP HANA」を標準プラットフォームとする第4世代のERP製品「SAP S/4HANA」を稼働させるインフラとして定着しつつあるほどの信頼を得ています。－では、IBM iユーザーは今後も使い続けることに悲観的になるべきではないと？阿野：信頼性や安定性に加え、オープンシステム対応の面で、基幹システムの稼働環境としてIBM iを使い続ける価値は十分あります。まずはIBM iの現状や評価を正しく理解し、5年、10年先を見据えた運用体制を構築することが大切です。

アプリケーションの構造把握こそ喫緊の課題

－IBM i上で稼働するアプリケーション。今後も稼働するだろうが機能強化や改修は難しくなるのでは？阿野：その通りです。IBM iユーザーが真に目を向けるべきは、IBM i上で稼働するアプリケーションです。多くの企業がずいぶん前にスクラッチ開発したアプリケーションを使い続けています。さらに、その当時のパッケージを独自にカスタマイズして運用している例も少なくありません。これこそが「レガシー」です。新しい機能を追加しようにも、技術者が高齢化するなどして対応できる人材が社内に限られてきています。アプリケーションを理解する技術者が引退してブラックボックス化してしまうことも。こうした問題こそ、きちんと考えなければいけないと思います。－スクラッチやカスタマイズの問題は、IBM iユーザーに限った話ではないのでは？阿野：幸いなことに「Power Systems」では、例えば何十年か前に開発した、IBM iの前身であるAS/400で開発したアプリケーションが手を加えることなく動いてしまう。ハードウエアやOS、仮想環境、データベース、アプリケーション連携環境などの基盤が年々進化し、アプリケーションだけレガシー化が進んでいる状況です。これでは基幹システムとSaaSのデータを連携して分析するなどの用途に使うのは難しくなってしまう。例えばAPI化は基盤的に可能でも、レガシープログラムが機能的にコンポーネント化していない“モノリシック（1枚岩）”ではAPI化できません。また、プログラムの仕様が分からなければコンポーネント化も進められません。IBM iユーザーに限ると、こんな問題に直面しています。－アプリケーションの仕様を記したドキュメントを見ればスキルやノウハウを継承できるのでは？阿野：当社がIBM iを利用する顧客と話をする限り、大半の企業がそうしたドキュメントを残していないんです。そのためアプリケーションの仕様が分からない、手を加えられないという課題を抱える企業は非常に多いと思います。

図2：IBM iユーザーが考えるべきは「古いアプリケーション」

－であればやはり、汎用的なSaaSなどに移行し、それをカスタマイズするしかないのではないか？阿野：IBM iユーザーは約1万社いると話しましたが、その中の小企業でさえ、IBM i用のプログラムが2000本超あるケースが珍しくありません。これらをもし、全て汎用パッケージやSaaSに移行し、独自の業務仕様にカスタマイズすれば、それだけで億単位のコストを伴うでしょう。豊富な資金を有する大企業なら英断できるかもしれませんが、多くの企業にとって全面的なシステム移行は現実解ではありません。　また、前述のドキュメント化していない仕様がアプリケーションに組み込まれていることも移行の大きな障壁です。IBM iで稼働する基幹システムの中には、取引先各々に併せた仕様にして運用するケースがあります。例えば、製造業が卸先企業と個別取引条件を商品ごと、商品区分ごとにルール設定するなど、複雑かつ細かく定めていることがあります。このルールをドキュメント化していないために分からず、システム刷新を阻害しています。－問題はアプリケーションの中身を正しく把握し、IBM iのベテラン社員が引退後も手を加えられる社内体制を構築できるかに懸かってくるのでは？阿野：IBM i用アプリケーションのプログラミング言語の主流は「RPG」です。現在、20代や30代の若手エンジニアの中でCOBOLよりマイナーなRPGに精通する人は稀でしょう。そこで、アプリケーションを“触れる”エンジニアを育成する、もしくはRPGを初めとしたIBM iに精通するエンジニアのスキルやノウハウを若手エンジニアに継承する仕組みと体制を構築するといったことを考えなければなりません。－スクラッチやカスタマイズしたアプリケーションの把握はさらに難しいのでは？阿野：確かにRPGを理解したからといって、数十年前にスクラッチ開発し、数十年かけて仕様を更新し続けたアプリケーションの全容を把握するのは難しいでしょう。そこでアプリケーションを把握する手段として、アプリケーションの構造を解析するツールを活用するのが手です。アプリケーションの構造や構成を洗い出し、機能や動作などの仕組みを可視化するのに役立ちます。こうしたツールを活用することで、ブラックボックス化したアプリケーションの中身を理解でき、改修に必要なソースコードを特定したり、改修コストや時間を削減したりできるようになります。－アプリケーションの全容把握こそIBM iユーザーが喫緊で取り組まなければいけない課題だと？阿野：IBM i用アプリケーションは、ハードウエアプラットフォームの更新に対して何も手を加えずとも現在動いています。これはコスト面では素晴らしいことですが、半面、別のプラットフォームであれば刷新に伴うアプリケーション刷新の機会を逃してきたことになります。これがIBM iユーザー共通の、先送りしてきた課題です。今後はIBM i上で稼働する基幹システムを含め、さまざまな業務システムから収集・蓄積するデータの利活用が進むはず。さらには基幹システムの頻繁な機能強化も求められるはず。次代のシステム像を描くとき、IBM i用アプリケーションが全社の中核システムとして効果的に機能できるようにしなければなりません。そのためには今からアプリケーションにメスを入れ、その役割を最大化できるよう準備することが不可欠です。

―――――――――――――――――――――――――――
第1回の連載はここまで。第2回では、IBM i用アプリケーションの構造を把握・分析するツールを使うメリットや、具体的な利用方法、効果について紹介します。