NEWS
オフコン・汎用機からの移行先としてのIBM i オフコン・汎用機からの移行先としてのIBM i
2017.07.07

オフコン・汎用機からの移行先としてのIBM i(3)

オフコン・汎用機からの移行先としてのIBM i(3)
前回までのコラムをまとめると、新たな汎用機やオフコンを選択すると、移行の安全性は高いものの、テクノロジー刷新に難があり、Windowsサーバーを選択すると、テクノロジー刷新は実現されますが、移行の安全性に難がある、というわけです。安全性とテクノロジー刷新とは両立することがないので、なかなかどちらか一方に決定できず、検討に時間をかけても何も産み出せません。もしくは無いものねだりとあきらめて、覚悟を決めてWindowsサーバーへの移行に乗り出し、失敗してしまうケースも聞いています。両者を満足させる選択肢はないものでしょうか。

IBM i は果たして移行先候補になり得るか

ここでIBM i への移行、という選択肢はどう映るでしょうか。AS/400ないしその後継機として知られてはいても、残念ながらこのシステムが移行先候補として認知されることはあまり多くありませんでした。オフコンとしての性格を継承しているので、レガシーシステムを別のレガシーシステムに置き換えるだけだと受けとられるからでしょうか。しかしながら冷静にこのシステムが備える特性を見れば、何故数多くのお客様が移行先として選択されているのか、理解いただけるはずです。先に列挙した3つの考慮点、すなわち安全性、テクノロジー刷新、将来性、の観点から眺めてみましょう。

安全な移行は可能か

まず、年間最大100から150台近くもの汎用機・オフコンをIBM i に移行してきた実績があります。移行元マシンやOSなどのテクノロジーに対応した、自動変換率90%を超える各種のツールが整備されており、安全かつ迅速な移行作業を行えます。元々IBM i ないしその前身であるAS/400は汎用機のデザインを参考にしながら設計・開発されていることから、内部の構造や機能はレガシーシステムと近似しており、移行ツールを整備しやすいという背景があります。COBOLはIBM i のCOBOLに、JCLはIBM i のCLPに、スプールはIBM i にも備わっており、文字コードのEBCDICは無変換でそのまま利用可能できます。機械的に移行できるということは、新規構築の割合を抑制でき、ひいては移行の安全性を高めます。

テクノロジー刷新は可能か

単純に移行するだけでは、テクノロジーの刷新は実現されません。これまでのIBM i への移行実績においても、日常的にアプリケーションを利用しているエンドユーザーは、レガシー環境が維持されていたために、その事実に全く気付かなかったことさえあります。実際には多くのケースでは移行の第二段階として、Webやモバイルに対応させるなど、テクノロジー刷新を行います。一旦移行されたレガシー環境をそのまま活かしながら、単一のIBM i システム上で最新テクノロジーとの融合を実現する、というわけです。例えばレガシーのエミュレータ機能を前提にしたアプリケーションの保守・開発環境は、GUIを基盤としたオープンな開発プラットフォームであるEclipse(エクリプス)テクノロジーに置き換えます。EclipseはかつてJavaの開発環境として登場したテクノロジーなのですが、アドオン・モジュールを追加することで様々なプログラム言語をサポートできる柔軟性を備えています。IBMはCOBOLやCLP用のアドオン・モジュールを開発し、さらにこれらをEclipseにパッケージングした製品を提供しています。そしてこれら言語のプログラムは、エミュレータとEclipseのどちらを利用して開発されたものであったとしても、相互に互換性を持っています。すなわちエミュレータで開発されたプログラムをEclipseで改修、もしくはその逆パターンが可能です。ただ、このままではCOBOL実行において、エミュレータ搭載PCを前提としたCUI(Character User Interface)、すなわち文字だけのインターフェース利用に留まってしまいます。 IBM i においては旧来からのアプリケーション・プログラムに手を付けることなく、Webないしモバイル対応化するための様々なツールが提供されてきました。中にはEclipseのアドオン・モジュールとして利用できる製品がありますので、プログラムの開発・改修だけでなく、同じ開発プラットフォーム上で同時にWeb画面を設計できます。すなわちアプリケーション開発と画面設計はEclipse、実行環境はWeb、となるわけです。 これは表面的にはオープン系サーバーが提供する環境と何ら変わるところはありません。ただし、裏側にあるプログラム言語はCOBOLで記述されている、というところがユニークな点です。この仕組みはIBM i のテクノロジー進化における方向性を示唆するものだと考えられます。COBOLという昔ながらのアプリケーション・プログラムはそのまま活かしながら、最新のテクノロジーと融合させているのです。テクノロジーの刷新は、過去のアプリケーション資産の犠牲の上に成り立つ、というのが「IT業界の常識」だとするならば、IBM i は独自の「非常識な」製品戦略を持ちながら進化しているのです。どちらがユーザーのことを考えたシステムなのかは明らかです。

将来性はあるのか

IBM i に将来はあるでしょうか。IBM i の製品戦略を文書にまとめた日本語版ホワイト・ペーパーがWeb上(https://ibm.biz/Bdid6v)に公開されていますので、是非入手して目を通すことをお勧めします。この中にIBM i の将来バージョンがいつ登場し、メーカーとしていつまでサポートする計画になっているのかが明確に示されています。この原稿を書いている2017年時点での最新バージョンは7.3になりますが、二世代先、10年以上将来までの計画が明らかにされています。基幹業務を支えるサーバーとして利用されるからこそ、ユーザーが長期的なIT計画を立てられるよう、必要な情報を公開しているのです。IT業界全体を見渡しても、これほどの長期計画を公にし、それを実現し続けている製品は他に見当たりません。 この将来計画は、IBM i 最新バージョンを起点として、常に二世代先までを公開する、というポリシーの元に更新されています。もし次世代バージョンが発表されたならば、それを新たな起点として、さらに二世代先までの計画が明らかになります。そしてIBM i の将来性を考える上で重要なのは、その特徴です。旧来のアプリケーション資産を保護しながら成長する、この考え方は長期的にこのシステムを利用するユーザーに対して、計り知れないメリットをもたらします。アプリケーション・プログラムはテクノロジーに振り回されるべきではない、というかつてのAS/400開発者が掲げたコンセプトは今後も継承されてゆくはずです。

最適解があった

さて、これまで次期サーバー選定のための基本的な判断基準とIBM i の真の姿を述べてまいりました。何故これまでに汎用機からの移行の受け皿としてIBM i が数多く採用されてきたのか、さらに今後同様のことはオフコンからの移行についても言えそうなのか、多少なりともその背景・理由をご理解いただければ幸いです。サーバー選定は、その判断基準を冷静に見極めるところから始まります。安全で最新テクノロジーを実装できて、将来性が必要です。そして実績が示すとおり、IBM i ならばその理想的なプラットフォームとして期待に応えることができるはずです。
report005
著者プロフィール 安井 賢克(やすい まさかつ) 日本アイ・ビー・エム株式会社にて、パワーシステムの製品企画を担当。エバンジェリストとして、IBM i ないしパワーシステムの優位性や特徴を、お客様やビジネス・パートナー様に理解いただく活動を日々続けています。また、大学非常勤講師として、100人近い学生に向けてITとビジネスの関わり合いについて述べる講座も担当しています。
<バックナンバー> 移行先サーバーとしてのIBM i(1) 移行先サーバーとしてのIBM i(2)
いいねと思ったらシェア
twitter
facebook
hatena
オフコン・汎用機からの移行先としてのIBM i 目次を見る

この連載は…

オフコン・汎用機からの移行先としてのIBM i
あなたにオススメの連載
できるIBM i 7.4解剖
14記事
できるIBM i 7.4解剖
IBM i の”新”必須言語 〜FFRPG入門〜
14記事
IBM i の”新”必須言語 〜FFRPG入門〜
Windows10待ったなし!どうする5250徹底検証
4記事
Windows10待ったなし!どうする5250徹底検証
PAGE TOP