IBM i のウンチクを語ろう
~ その91:IBM i の技術者不足に対処するには
皆さん、こんにちは。DXを推進するにせよ、レガシーとされるIBM i のテクノロジーをオープン化するにせよ、さらには日々の運用においても、何をするにも人がいなければ事は始まりません。昨今のIBM i にまつわる様々なサーベイ結果やイベントにおけるテーマを見ていると、「いつかやって来るかも知れない」漠然とした人材不足問題が、そろそろ具体的なものとして目前に迫りつつあると、その兆候を感じる方が多くなってきたと感じます。企業が必要とする3つの資産、ヒト・モノ・カネの中で、確保するのに最も手間と時間を要するのがヒトではないでしょうか。手を打てばたちどころに解決する、といった特効薬はありませんし、以前もこの場でコメントしましたように、人材不足はIBM i に限らない、IT業界横断的な問題でもあります。解決策を探るための第一歩として、課題を細分化し、どのような対処法があり得るのかを考えれば、何か糸口を見いだせるかもしれません。
まず実情を把握するところから始めましょう。IBM i の人材不足を課題とするユーザーの割合は年々高まっており、アイマガジン社の「IBM i ユーザー動向調査」においては、2019年の58.7%が2023年には72.3%に伸びています。また、人材の需要と供給に関しては、経済産業省が2019年3月に「IT人材需給に関する調査」の報告書を公開しています。GDP連動性が高いことからIT需要伸び率として1%、2010年台のIT業界の労働生産性上昇率0.7%を適用すると、2030年時点の供給は113.3万人であり、16.4万人の不足が生じると予想されています。単純計算で充足率は87.4%(=113.3/(113.3+16.4))というわけです。
ちなみにマスコミがよく言うところの最大79万人の人材不足とは、IT需要伸び率が最も高い3-9%でありながら、労働生産性上昇率は0.7%に留まった時の、不足数78.7万人というワーストケースです。現実的には16.4万人から78.7万人のどこかに着地するのでしょう。報告書では中位シナリオとして44.9万人を示しており、このギャップを埋めるには生産性向上率3.54%が継続的に必要になると指摘しています。
![需要と供給](/images/col2401-01.png)
さて、不足とは需要と供給のバランスが崩れること、すなわち需要過多と供給不足のいずれか、またはその両者によって生じる現象です。人材不足を解決するにはこの逆、すなわち需要を減らす・供給を増やす、のいずれか、または両者を追求すれば良いはずです。
IT人材需要を減少させるためには、ビジネス遂行におけるシステムへの依存度を下げるか、運用などこれまで人が実施してきた作業を可能な限りシステムに委ねるか、どちらかしかありません。さすがにシステム利用から脱却するのは非現実的ですが、自社内が無理ならば社外にある人材への依存、すなわちアウトソーシング、典型的にはクラウドへの移行が解決策になるはずです。当コラム「オンプレとも違うし事業者間でも違うクラウド」の中でも述べたとおり、クラウドのメリットはコストよりもむしろサービスにあります。日常的なシステム運用や可用性を担保するための作業負荷を自社で賄うのではなく、ノウハウある事業者に委ねた方が質も高まるし、結果的にコスト削減が期待できます。
世間ではどのくらいクラウドが浸透しているのか、ここで利用動向を眺めてみたいと思います。令和3年度版の「情報通信白書」(総務省)における「企業におけるクラウドサービスの利用動向」によると、2020年時点で68.7%の企業が何らかのかたちでクラウドサービスを利用しているとあります。ざっと3社に2社以上というわけです。サーバーが何かは明示されていませんが、市場シェアを考えると大半はWindowsサーバーだと思って良いでしょう。一方IBM i ユーザーについては、アイマガジン社の「IBM i ユーザー動向調査2023」によると、2022年から4.2ポイント伸ばしたとは言え10.1%ですから、概ね10社に1社といったところです。単純比較はできませんが、これほど数字に差があるのはサーバーによってクラウドに対する姿勢の違いに原因がありそうです。
考えられることの一つは、基幹業務用アプリケーションやデータをクラウドに移行することに対する抵抗感、背景にあるのはセキュリティに対する懸念なのだと思います。上記情報通信白書を見ると、その用途の主なものは「ファイル保管・データ共有」「電子メール」などであり、基幹業務は少数派です。データはありませんが、IBM i の用途は基幹業務が圧倒的多数であることを思うと、クラウド浸透率に差が生じるのは無理からぬことです。ただ、クラウド事業者側も懸念を理解して様々な対策を打っていますし、私の知る限りセキュリティ事故を見聞きしたことはありません。
![メリットが小さい](/images/col2401-02.png)
もう一つは、IBM i の運用負荷は軽いので、クラウドへの移行によって得られるメリットがWindowsサーバーに比べて極めて小さいことです。IT要員があまりいない、中堅中小企業の基幹業務用途、というのがそもそもの位置付けのシステムです。例えばデータベース周辺の管理作業が不要になるとか、パフォーマンスの自動チューニングを搭載するなど、人手介在の必要性を最小限にする機能が独自のアーキテクチャによってもたらされています。上記レポートの「Automation」(自動化)セクションを見ると、業務時間後にIBM i を無人運転しているユーザーの割合は77%に達している、という結果が示されています。放置運転が可能なIBM i ならではだと言えるでしょう。ただWindowsサーバーほどの効果には及ばないにせよ、IBM i のクラウド採用は社内のIT関連業務量を削減する上で、特にセキュリティやアベイラビリティ対策の観点から、検討するユーザーが多いのも事実です。
オンプレミスのままであっても技術者需要を抑制する手段はいくつか考えられます。運用を自動化する各種ツール類もそうですし、ノーコード・ローコードと呼ばれるアプリケーション開発ツールもそれなりに作業時間削減効果があるとされています。急速に進化しつつあるAIもいずれは有力な選択肢になるはずです。
ここまでは多くの方に知られているところだと思いますが、外部に委ねることは難しいとされながら、最近その認識が変わりつつあるのがアプリケーション保守サービスではないでしょうか。数多くのアプリケーションが、RPG言語の開発生産性の高さを利用して自社開発され、資産継承性のメリットを活かして長期にわたって現役稼働しています。そしてその大半は最も世代の古いRPGⅢで記述されているのですが、往時の開発者の引退が視野に入りながらも、後継者が見つからない・育たない点に危機感を抱く、というのがIBM i の人材不足問題の典型的なケースです。
社内が無理ならアウトソーシングしようにも、第三者にアプリケーションの保守を委ねることは長い間不可能とされてきました。ところがIBM i のための解析ツールの有効性が市場に認知され、ツールを活かした保守サービスを提供するITベンダーと、採用するユーザー企業が増えつつあることが、事情の変化を物語っています。ちなみにベル・データもX-Analysisを活かした同様のサービスを展開しています。
![握手](/images/col2401-03.png)
もう一つ安井が注目しているのはNavigator、すなわちIBM i の日常的操作の全てをブラウザ画面から実施できるようにする標準機能です。直感的操作が可能になるので独自のコマンドを憶えなくても済んでしまいます。元々は1995年に登場しているのですが、New Navという名の元に2021年に全面的に焼き直され、パフォーマンスと使い勝手が大幅に改善されています。当コラムでも紹介したことがありますので、参照いただければ幸いです。他にもPythonやNode.jsといったプログラム言語、GitやJenkinsを活かしてDevOpsを実現するMerlinなど、業界で広く採用されていてそのままIBM i でも利用できる機能は、数え上げればきりがありません。
ここで無理のある机上の空論であることは承知の上で、ちょっとした比較をやってみましょう。冒頭で経済産業省の報告書を紹介し、人材不足を解消するには3.54%の生産性上昇が必要である旨を述べました。一方でIBM i の人件費はWindowsサーバーの約4.5分の1、仮に時間単価が同じだとすると生産性は約450%に及ぶというデータが、2017年に米Quark+Lepton社から公開(IBM i on Power Systems Meets the Diverse Needs of Midsize Businesses)されたことがあります。IBM i に置き換えれば不足はたちどころに解消されるはずですね。現実的にこうなることは無いでしょうけれども、IBM i の強みはどの程度のインパクトを持ち得るのか、感じていただけるのではないでしょうか。
昨今のIBM i の機能強化とは、業界標準テクノロジーの実装だと言っても過言ではありません。私達販売店側の努力の問題でもあるのですが、IBM i だとどうしても新機能が無いと誤認されたり、認知されるまでに時間を要したりするケースがあります。何か必要な機能があったら、IBM i を活かすとしたらどのように対処できるのだろうか、と問い合わせていただけると幸いです。もしかしたらそれが人材不足問題を少しでも緩和するための糸口になるかもしれません。
ではまた