IBM i のウンチクを語ろう
～ その69：他社汎用機・オフコンからの移行の受け皿になるIBM i
皆さん、こんにちは。「IBM i コラムで取り上げても、既にIBM i を利用中の方にとってはあまり意味が無さそうだから止めておこう」が、「IBM i の価値を認識する上で役立ちそうな気がするので取り上げた方が良いかな」に変わり、しばらくすると「いや、やはり他の話題を優先させよう」になり・・・、と私の中で方針を二転三転させていた話題を今回取り上げることにしました。
きっかけの一つは、富士通がメインフレームの製造・販売から2030年度に完全撤退する、というメディア報道です。私自身は長らくAS/400やIBM i に関わっていたので、直接競合するような経験はありませんでしたが、同じレガシーシステムのカテゴリの中にあることから、仲間の一人が引退してしまうかのような感覚を思わず抱いてしまいました。富士通のニュースだけでなく、2017年の日立メインフレームに関するメディア報道を記憶されている方もいらっしゃるかもしれません。VOS3という独自OSの開発を継続するとしていますが、ハードウェア製造からは撤退し、IBMからの供給を受けるというものでした。
こういった撤退の背景にあるのは、市場の縮小、出荷台数の激減です。オフコンすなわちビジネス用途に特化した中小型システムのデータはありませんが、JEITA（Japan Electronics and Information Technology Industries Association: 一般社団法人電子情報技術産業協会）ホームページで、日本における全ベンダーの毎年のメインフレーム出荷実績を知ることができます。それによると、1990年代の年間出荷台数3,000超から、2020年の159台まで大きく数字を落としています。仮に製品寿命が平均で7年間だとしたら、日本国内で現在稼働中のマシン台数は全部で1,500くらいという計算になります。
かつては企業の基幹業務を担うシステムとして、メインフレームは盤石の地位を確立しておりました。1980年代以降になるとオープン系と呼ばれる比較的廉価な分散型システムが台頭する中で、対立軸として「レガシー」のレッテルを貼られてダウンサイジングのターゲットとなり、さらにここ数年はクラウドという急激にその力を充実させている新たな対抗勢力にも直面しています。逆風吹き荒ぶ中、どこにその生存の場を求めるのかが重要になる、という点において、IBM i が置かれた状況に酷似していると言えるでしょう。
メインフレームやオフコンは衰退・消滅の一途を辿っているのかというと必ずしもそうとは言い切れず、例えばIBM i とかIBM Zはご存知のとおり未だ健在です。レガシーシステムには、市場から退場しつつあるレガシーシステムと、未だに健在で将来に向けて継続的に機能強化されているレガシーシステムの二種類がある、ということなのでしょう。ほとんどのシステムは前者に属しているのに対して、例外的存在としてIBM i やIBM Z、さらに一部の他社メインフレームは後者に属しているというわけです。他社機の姿はわかりませんが、少なくともこれらIBM機に関する限り、レガシー的要素に加えてオープン性を追加で備え、両者を統合したハイブリッド型のシステムに変貌を遂げています。IBM i はレガシーシステムではなくハイブリッド型システムである、と私自身もよく主張するのですが、市場において一度貼り付けられたレッテルを引き剥がすのは、容易なことではありません。強弁ばかりしていても仕方ないので、甘んじてレガシーと呼んでしまうことも度々あるのが実情です。
さて、後継機という選択肢が失われてしまう以上は、「真の」レガシーシステムのユーザーは、遅かれ早かれこれまでとは異なる次期インフラを選定しなければなりません。ほとんどの方は、オープン系を志向するのではないでしょうか。従来のシステムではDX推進はままならなかった、オープン系へと移行すればDX推進のための技術的基礎は揃う筈だ、という発想・期待はごく自然なものです。
ここで既存の基幹業務アプリケーションをどのように扱うべきかが課題になります。その多くはかつて事務処理用プログラム言語のスタンダードとされた、COBOLで記述されています。今やその言語としての盛勢は見る影もなく、多くの場合はお払い箱になるべきレガシーの象徴とされてしまっています。すなわちオープン系への移行とは同時に脱COBOLであり、Windowsとその上で稼働する業務パッケージの導入を検討する、というのが典型的なパターンではないでしょうか。これでスムーズに新システムに移行できれば良いわけです。
検討を進めてゆく中で、オープン系への移行のハードルは意外に高いことに気付かれるケースもまた多いようです。既存のアプリケーションは自社の業務にフィットしていたはずですが、細かな業種毎に機能が整備されていたとしても、業務パッケージはどうしても最大公約数を想定したものになってしまいます。そこに収まらない部分はカスタマイズや追加開発の対象です。この割合が大きくなればなるほど、作業期間やコストは膨れ、パッケージ採用のメリットは薄れます。業務をベストプラクティスに合致させるべき、という議論もありますが、自社業務の特徴を消すように言われても、現実はなかなかそうもいかないものです。特に業務の現場からの反発が出るのは明らかです。
ちなみに経産省発行のDXレポート2においては、自社業務の強みを「競争領域」、すなわち他社に対する競争優位を維持するためのアプリケーション領域として集中投資の対象とするべき、といった主張をしています。業務の独自性は、各社の強みとして残してさらに強化すべきものなのか、放棄してベストプラクティスに従うべきないのか、冷静な判断が求められるということなのでしょう。
あとなかなか事前にイメージし辛いのが、いわゆる非機能要件と言われるものです。業務ロジック以外の部分、すなわちシステムを安定的に稼働させるために必要となる要件で、具体的にはパフォーマンス、運用性や安定性、セキュリティ、などといった考慮点を言います。レガシーシステムにおいては、ユーザーがあまり意識しなくてもアプリケーション稼働環境が守られていたのに対して、オープン系ではそれがむき出し状態になっている、と考えるとイメージし易いと思います。様々なミドルウェア製品を導入するなどして、個別に対処することになります。いきおい複数台のサーバーが必要になりますし、それらの間の相性の問題も解決しなければなりません。プロジェクト進行途中で事前に想定していなかった新たな要件が見つかることもたびたびあります。プロジェクト期間が長期化したり、最悪の場合は中止の憂き目に遭ったりすることも少なからず発生します。
仮に首尾よく移行作業を完了できたとしてもそれで終わりではありません。アプリケーション資産の継承性も失われるために、マシンを更新したりOSバージョンをアップグレードしたりするなどした際に、アプリケーションの改修やテストのやり直しが必要になります。同時にミドルウェア製品群のアップグレードも伴うかもしれません。オープン系の文化はレガシーのそれとは異なると言ってしまえばそれまでですが、何とか移行を済ませたとしても不満が残るようであれば不幸なことです。
IBM i が他社メインフレームやオフコンの移行受け皿として採用される理由の最大のものは、先に述べたようにそのハイブリッド性にあると言えます。COBOLをサポートするなどレガシーシステムとしての文化を踏襲しているだけでなく、同時にオープン性も兼ね備えていますので、DX推進のための基盤技術も手に入ります。そして何よりも将来性、すなわちメーカーであるIBMは将来にわたって継続的に投資する事は、安心感につながります。もちろんIBM Zも選択肢に入りますが、どちらが採用されるのかはシステムの規模やコストなどによって決まります。
レガシーという言葉には価値ある歴史的資産といった意味を含むこともありますが、ITの世界においては将来性の無い陳腐化したテクノロジーというニュアンスが色濃く反映される傾向があるようです。陳腐化はいわゆるレガシーシステムだけでなく、オープンシステムにおいても見られます。逆にレガシーシステムと言われていても、将来性あるシステムは存在します。巷を飛び交う表面的な言葉遣いに惑わされる事無く、冷静に個々のシステムを評価いただければと考えている次第です。
ではまた。
