IBM i のウンチクを語ろう
～ その24： サーバー比較の観点から見たIBM i -5
皆さん、こんにちは。前回に引き続き、古くなった汎用機の後継として、IBM i はどのように位置付けられるのか、という視点から話を進めたいと思います。汎用機の新モデルもオープンシステムも、後継候補としてなかなか決定打になり得ない事は、前回説明したとおりです。移行の安全性とオープン性という、重要ではありますが互いに矛盾する要件について検討する時、どちらのサーバーを選択した場合においても、片方の要件を満たす事はできても、他方を犠牲にせざるを得ませんでした。このままでは採用するべき次期システムをなかなか決定できません。
既存システムのリース期間満了が迫るなど、このまま決断しなければならなくなったとしたら、リスクを許容した上で次期サーバーを決定する以外にありません。ユーザーにとっては、検討に値するかもしれない選択肢を俎上に上げていない可能性がありますし、製品のマーケティング活動を行なっている立場からすると、そうと認識する事なくビジネス機会を逸してしまっているわけです。願わくば時間切れとなる前に、IBM i も検討いただきたいところです。製品認知度を上げるべく日々活動しているつもりではあっても、目に見える効果を上げるのは至難の業だと感じます。私が毎月このコラムを提供するのも、そのための努力の一環ではあるのですが。
運良く我々の活動が奏功して提案の機会が巡って来る事もあります。汎用機新モデルかオープンシステムか、という二者択一の検討が煮詰まった、周回遅れの状態から競合に参入する事も珍しくありません。それでも次期サーバーとして評価・採用いただけるのは大変にありがたい事です。サーバー移行の際の要件である安全性とオープン性は、IBM i においてはどのように評価できるのでしょうか。
移行の安全性とは、既存マシン上で稼働しているアプリケーションを、計画通りに着実に移行できる事です。作業量を決定するのは、移行前後の両マシンの互換性、すなわち実装されている機能やアーキテクチャーの共通性です。システムとしての成立ちを考えると、汎用機に対して、IBM i はオープンシステムよりも近い位置にあり、いくつかの共通性を見る事ができます。さらに言うと、凡そ日本のオフコンと呼ばれるサーバー群も同様に、汎用機と比較的近い関係にあります。
IBM i の前身にあたるSystem/38の開発プロジェクトが進められたのは1970年代です。当時のIBMは汎用機全盛の時代であり、いわゆるオープンシステムは未だ市場に投入されておりません。究極のビジネス用サーバーを作ろうと理想を掲げた開発チームが、既存の汎用機のデザインを参照するのは自然の成り行きです。いくつかの画期的なアーキテクチャーを実装した事に加えて、例えば文字コードとしてEBCDICの採用、メーカーによるCOBOL言語のサポート、ユーザー向けインターフェースとしての画面定義（画面DDS）の実装、プリンターに印刷情報を送信するためのスプールの振舞い（印刷後も印刷情報はそのまま残る）などは、汎用機と共通です。これがオープンシステムだと、文字コードはシフトJISやEUC、メーカーによるCやBASIC言語の提供、画面定義は各プログラム次第、印刷されたら印刷情報はスプールから消滅、となります。製品の登場以来IBM i もオープンシステムも機能強化が進みましたが、汎用機からの「距離感」は従来のまま概ね変わりません。
共通性が高ければ、プログラム移行時の変更量が少なくなり、バグの入り込む余地が小さくなります。IBM i 用には、移行元のあらゆるメーカー、プログラム言語、ユーティリティ毎に移行ツールが用意されており、95%近くの変換率を達成するものもあります。前回述べたとおり、いわゆる2000年問題が顕在化しつつあった時期に、サーバーの置き換え（主にダウンサイジング）が流行した時期がありました。アプリケーションを正常動作させるために、取り扱う西暦年号を下2桁から4桁に置き換える必要が生じたためでした。IBM i を対象とするアプリケーション移行ツールは、ピーク時で年間100件以上の実績を積み重ねており、精度向上に役立っています。
ちなみに実際に移行作業を専門に請負う会社の方にうかがったところによると、ツールの精度向上とは言っても変換率100%は目指さないのだそうです。プログラムには癖や傾向があり、あらゆるバリエーションに耐えられるような機能を盛り込もうとすると、ツールが巨大化してしまいます。むしろプロジェクト毎に癖を見極めて、適宜ツールを変更しながら移行します。変更によって得られる効果の割に手間が過大になりそうな場合は、ツールに頼るのを止め、手作業で作業を進めることもあります。
安全に移行できるだけでは、付加価値は生まれません。これまで利用されていたのはレガシーなアプリケーションであり、移行と同時に求められるのはテクノロジーの刷新、言わばオープン化です。より具体的な例としては、ユーザー・インターフェースの見栄え向上、すなわちエミュレータを利用したCUI画面から、ブラウザやモバイル・デバイスによるGUIへの置き換えが検討されるケースが多いようです。IBM i においては、移行直後のレガシーなアプリケーションには手を付ける事無く、この目的を達成するための実績あるツールがいくつか用意されています。 旧来からあるプログラム言語を利用しているからと言って、開発環境までCUIに縛られるわけではありません。例えばオープンなEclipseをベースにGUIを採用するRDi（Rational Developer for i : IBM製品番号5733-RDW）上では、RPGやCOBOL等によるアプリケーション開発を可能にしています。
さらにビジネス的価値を追求するためには、データ分析やAIなどSoRに対するSoE、言い換えると基幹業務に対する情報系などの周辺アプリケーションとの連携が必要になります。IBM i にはPASEというオープンな環境があり、Java、PHP、Ruby、Python、Node.js（サーバー上のJavaScript）、Perlといったプログラム言語がサポートされています。
移行の安全性とオープン性を確認できたとして、次に懸念されるのは将来性でしょう。サーバー移行は、同一メーカー・同一シリーズの後継機に置き換えるのと比べて、ユーザーに対して極めて大きな負荷がかかる事は否めません。移行作業もさることながら、今後付き合ってゆくベンダーとの関係も見直されます。このような面倒はできるだけ避けたい、自社ビジネスの都合による移行ならばまだしも、それがベンダー側に起因するのはたまらない、というのが本音ではないでしょうか。二度と同じ事を繰り返さないためにも、移行した先のサーバーの将来性、すなわち今後も継続的・長期的に機能強化がなされる事が、もう一つの重要な考慮点になります。
IBM i の将来は、二つの点から見極める事ができます。まずハードウェアについてはその心臓部分にあたる、POWERプロセッサの今後についてです。このコラムを書いている時点（平成30年5月）の最新プロセッサはPOWER9であり、開発部門では既に次世代のPOWER10の開発を進めています。もう一つはソフトウェア、すべての基本となるオペレーティングシステムであるIBM i についてです。IBMはホワイト・ペーパーにおいて、最新のバージョン7.3の二世代先、先行き10年以上の計画（サポート・ロードマップ）を明らかにしています。
今回のコラムをまとめておきましょう。IBM i に採用されているアーキテクチャーは既存汎用機と親和性が高く、数多くの実績に裏付けられた移行の安全性があります。単純に移行しただけではテクノロジーは刷新されませんが、アプリケーションを改修せずにユーザー・インターフェースをブラウザ対応化するなどして刷新したり、基幹業務以外のアプリケーションをオープンソース言語で開発したり、といったオープン化が可能です。そしてIBM i の機能強化は今後共継続されるので、将来も安心してご利用いただけます。
移行の安全性、オープン化、将来性の観点から、IBM i が移行先サーバーとして有力な選択肢になる事をご理解いただければ幸いです。次回は他のいくつかの考慮点について述べる予定です。ではまた
