AS/400（IBM i ）が使いにくい理由とは？継続利用と移行の判断方法も紹介

IBM i に構築されたCUIベースのプログラム資源はレガシー化されたIBM i 特有のプログラミング言語であり操作性や運用方法が古く感じられるようになってきました。

レガシー化したプログラム

IBM i は、1980～90頃に導入されたケースが多く、IBM i 特有のRPG(Report Program Generator)やCLのプログラム言語で企業の中核となるビジネスロジックやデータ処理に使われ今も業務の中心で使われています。とても安定しておりシステムを停止させることなく運用し続けているケースも多くあります。プログラム資産においては、オリジナルのコードが何十年にもわたり少ない更新で運用され続けていることも多く手間がほとんど掛かりません。

手間が掛からないことで逆に、プログラム資産がブラックボックス化されて十分な引継ぎがされず過去のプログラム資産の経緯が判らなくなってしまった、プログラムがどの様に利用されているものか判別できなくなってしまったというデメリットも生まれる場合があります。昨今の現代的なアーキテクチャと異なることから、慣れない方にとっては操作や運用が難しく感じてしまうのも事実となっています。

運用業務の属人化

RPGやCLは生産性が高くパフォーマンスに優れたIBM i 特有のプログラミング言語で、OSをバージョンアップしても上位互換であるためバージョンアップ後も問題なく使えるようにすることができ長期に渡り使い続けられてきました。

しかし、若手の技術者は、新しいテクノロジーへの関心が高く他のプラットフォームや言語に流れてしまいます。そのためIBM i に精通する技術者が育たずIBM i を熟知する担当者への属人化の流れという具合になってしまいます。さらに、長年運用してきた担当者が定年やその他の理由により退職になるが、ドキュメントが残っていない場合もあり引継ぎが難しくなるケースもあります。

スキルを持った人材の不足

プログラム資産がレガシーな仕組みであるため、スキルをもつ技術者は限られてきてしまいます。IBM i を熟知した担当者の年齢層は高くなり退職に向けての移行期で言わば減っていく傾向にあります。IBM i のスキルを新たに習得するには時間と労力が必要で、IBM i 技術者が高齢化するなかでIBM i 資産の知識や経験を次世代に伝える機会も限られてきてしまいます。

IBM i は、日常的な運用が少ないため実際のシステムに触れる機会も少なく経験を積むことも難しいところです。このようなところからスキルを持った人材が増えてくることはなかなか難しい状況にあります。

では、どのようにIBM i を利用するのがよろしいでしょうか。それは、モダナイゼーションして現代的なアーキテクチャにするか、または、継続利用するかの二択になります。

モダナイゼーションの実施

一つの選択肢はモダナイゼーションによる現代的なアーキテクチャへの移行です。モダナイゼーションにより、IBM i を利用した業務、IBM i に存在するデータを活用した新規施策など、デジタル化への取り組みが進みやすくなります。主なモダナイゼーション手法は、クラウドへのリフト＆シフト、リライト・リファクタリングなどによる刷新があります。

IBM i をオンプレからIBMCloudへの移行（リフト＆シフト）を行うことで、より柔軟でスケーラブルなインフラを活用することがでるようになります。必要に応じてリソースを動的にスケールアップまたはスケールダウンすることができるようになります。

リフト＆シフトは、既存のアプリケーションとデータをそのまま新しいクラウド環境に移行することを指し、アプリケーションの大幅な変更を避けつつクラウドの利点を享受しますが、IBMCloudは多様なAPIを提供し、利用することも可能です。これだけでは、モダナイゼーションは終わりではありません。

リフト＆シフトは第一歩にしかすぎずず、アプリケーションを根本から見直し改善を図る必要があります。リライトは古いコードを現代のプログラミング言語に書き換えることを意味します。これによりパフォーマンスの向上や保守が容易になり、新しい機能の追加や拡張がより簡単にできるようになります。

継続利用

IBM i は、現在も継続的なサポートが行われており、現時点（2023年時点）で2032までのロードマップが発表されています。もう一つの選択肢としてはIBM i を継続利用することです。IBM i を継続利用することでモダナイゼーションにかかるコストを抑えることができ、IBM i からデータ抽出する仕組みなどを利用すれば、IBM i を維持したままで外部システムと連携させてデジタル化を進めることもできます。

弊社の製品で例をあげるならAPI-Bridgeという製品で外部システムからAPI経由でIBM i 上の基幹ロジックとデータをリアルタイムにExcelやWebサイト、オープン系アプリケーション、クラウドサービスなどで活用できるようにする事ができます。逆に、IBM i がAPI経由で外部システムのアプリケーションやデータを利用することも可能で、APIで公開されている郵便番号などの住所データをIBM i の顧客データと連携させたり、外部の与信データをIBM i 上へ呼び込んだり、天候データをIBM i 上に取り込み、天候を踏まえた納品日の調整などに役立てるといった使い方ができます。

これらのようなツールを利用してデジタル化を進めるのも一つの方法です。もし、人材不足が懸念されるようであれば知見を持った外部ベンダーの活用もたいへん有効です。

IBM i は、CUIベースのレガシーなプログラミング言語により操作性が古く感じられることが多くあります。特に1980～90年代に導入され、現在も中核のシステムとして活用されているもので、非常に安定しており、長期間にわたり更新の少ない運用が可能です。ただし、これが原因でプログラム資産がブラックボックス化し、過去のプログラム経緯が不明瞭になることもあります。また、RPGやCLなどのプログラミング言語はIBM i に特化されたもので、新しい技術への関心が高い若手技術者が他のプラットフォームに流れがちで、IBM i の専門家が不足する傾向にあります。そのため、運用業務の属人化や退職する技術者の後任が見つかりずらくなることが問題です。

このような背景から、IBM i  の将来についてはモダナイゼーションまたは継続利用の二択が考えられます。モダナイゼーションでは、クラウドへの移行やプログラミング言語のリライト・リファクタリングを通じて、システムを現代的なアーキテクチャに刷新することが可能です。これにより、パフォーマンスの向上や新機能の追加が容易になります。一方、IBM i の継続利用では、外部システムとの連携を強化し、APIを通じたデータ連携やデジタル化の進展を図ることができます。どちらの選択肢も、IBM i の技術者不足という課題に直面しており、外部ベンダーの活用が有効な手段となります。最終的な選択は、企業の現状と将来のビジョンに基づいて検討することが重要です。