Windowsのバージョンアップに影響されず、企業のプログラム資産を守る
Windows Server 2003の延長サポ?トが終了した2015年、これを機にWindowsからIBM iへの移行を検討するユーザーの動きが見られた。企業の財産である基幹システムを長く使い続けるために、求められるサーバー要件とは何か。Windowsからの移行ユーザーへの取材をもとに、Windowsと比較した基幹プラットフォームとしてのIBM iの優位性を明らかにしよう。
Windows 2003のサポート切れで
IBM iの導入を検討する
IBM iユーザーを取材していると、システム/36、システム/38の時代から長くIBM iを使い続けている企業に出会うことが少なくない。当時開発したシステムに改修を加えながら、20年、30年の時を経て今も使い続けることができるのは、IBM iが備える類まれな資産継承性ゆえであろう。
ちなみにそれ以外のケースでは、メインフレームから移行したケース、国産のオフコン製品から移行したケース、それにWindowsサーバーから移行したケースがある。メインフレームや国産オフコンからの場合は、そうしたプラットフォームの信頼性や運用性を熟知するユーザーが、よく似た環境を求めてIBM iへ移行するケースが多い。
サーバー移行という観点から見て、最も少ないのは、WindowsからIBM iへの移行例である。しかし昨年、Windows Server 2003が延長サポートを終了したのに伴って、WindowsサーバーからIBM iへ移行するユーザーの動きが見られた。そこでは、基幹システムの運用に堪え得るサーバー選択とは何かを考え抜き、決断を下したいくつかの事例がある。
本特集では、Windowsサーバーからの移行例を参考に、基幹システムを運用するプラットフォームとしてのIBM iの優位性を探ることにしよう。
WindowsサーバーからIBM iへ移行するユーザーには、2つの種類がある（図表1）。
【図表1】Windowsからの移行ユーザーと移行理由
1つは、過去にIBM iの運用経験がなく、Windowsサーバーから移行して初めてIBM iを利用するケース。もう1つは過去にIBM iを運用した経験があり、何らかの理由でオープン系サーバーへ移行したものの、運用に不満もしくは不具合が生じて、再びIBM iの運用に戻るケースである。
本特集では前者を「IBM i未経験型」、後者を「IBM i回帰型」と呼ぶことにする。
IBM i回帰型ユーザーは、過去のIBM iの利用経験から、その優位性をよく認識している。オープン系サーバーと比べた初期コストの価格差や、「いつまで古いオフコンを使っているのか」と問う経営トップの意向、あるいは「これからはオープン系の時代だろう」という漠然としたイメージから、Windowsサーバーへ移行したものの、IBM i時代とは異なる使い勝手の悪さ、運用性の低下といった問題が生じ、もう一度IBM iへ戻ることを決断する。
こうしたユーザーはIBM iの運用性を十分に理解しているので、いったん決断が下れば、戻ることにそれほど大きな障壁はないと考えられる。
これに対して未経験型ユーザーは、IBM iという未知の世界に足を踏み入れることになるので、ためらいは大きい。後述するように、IBM iはきわめて信頼性・運用性に優れるので、実際の運用管理業務の負荷は確実に軽減し、運用工数も削減できる。しかし「Windowsには慣れているが、IBM iのことはよく知らない」という精神的な負荷を取り除くために、ビジネスパートナーやソフトウェアベンダーの協力が不可欠となる。
また5250画面はWindowsの画面に比べると、エンドユーザーにどうしても古くさいイメージを与えるので、GUI化やWeb化などユーザー・インターフェースの工夫が必要になる。
本特集では、IBM i未経験型ユーザーとして野田スクリーン、IBM i回帰型ユーザーとして大東の導入事例を紹介している。また今回は残念ながら、掲載許可を得られなかったものの、さまざまなユーザーあるいは導入を担当したビジネスパートナーから、Windowsへの移行理由や移行案件の概要を聞く機会が得られた。
そうした取材をもとに、WindowsからIBM iへの移行シナリオを整理してみよう。
アプリケーション資産の継承性
システムを長く使い続けるために
Windowsからの移行理由で大きいのは、アプリケーション資産の継承性である。
IBM iは資産継承性に優れ、いったん開発したシステムは（ユーザーが望む限り）、半永久的に使い続けることができる。しかしWindowsサーバーでは、そうはいかない。
国産あるいは海外製を問わず、ERPと呼ばれるような統合業務型パッケージの場合、Windowsの次バージョンに対応させるために、再度ライセンスを購入せねばならないケースがよく見られる。
つまりWindowsのバージョンが変わるたびに、初期導入時と同じ額のコストが発生する。さらに自社要件にカスタマイズで対応している場合は、カスタマイズ開発したプログラムの改修費用も生じる。パッケージ製品ではなく、自社開発型の場合もプログラムの改修作業が生じる点では同じである。
今後もWindowsのサポート終了に応じて（図表2）、数年ごとに初期費用と同額のコスト、あるいは相当額のプログラム改修費が発生することに、ユーザーが疑問を抱くのは当然であろう。これはWindows Server 2003のサポート切れを契機に、ユーザーがIBM iに目を向けた大きな動機であり、今回掲載した野田スクリーンもこのケースに該当する。
【図表2】マイクロソフト主要製品のライフサイクル
企業システムはその性格や用途に応じて、基幹系システムと情報系システム、バックエンド系とフロントエンド系、最近ではSoR（Systems of Record）とSoE（Systems of Engagement）などという言い方で対比される（図表3）。
【図表3】システムに応じたサーバー要件
フロントエンド系のシステムは自社を取り巻く環境の変化、顧客ニーズへの対応、エンドユーザーである社員の機動性や情報活用力に応じて、常に変化し、積極的に作り変えていく必要がある。ライフサイクルは短く、もともとが改修を前提にしたシステムとなる。これに対して、業務の中核部分を担うバックエンド系の基幹システムはライフサイクルが長く、いったん作り上げたら長期間にわたって安定的に使用できることが重要な要件となる。
基幹システムは業務の変革や新規要件への対応など内部要件でのみ変化し、システム側の環境条件、たとえばOSのバージョンアップなどで作り直す状況は避けねばならない。その点で、IBM iは基幹システムを稼働させるサーバー要件を十分に備えていると言えるだろう。
コストの比較
本当に安価なのはどちらか？
前述した資産継承性の問題は、当然ながらコストに反映される。正確には初期導入費ではなく、TCO（Total Cost of Ownership）と呼ばれる総所有コストに影響することになる。
図表4は、WindowsサーバーとIBM iを3年間のTCOで比較したものだ。ここでのTCOはハードウェアと保守費、ソフトウェアと保守費、人件費、設備費で構成されている。3年というスパンで比較すると、Windowsサーバーに対してIBM iでは45％削減されるとの結果が出ている。
【図表4】3 年間の TCO 比較サマリー
もしこのコストを、Windowsのバージョンアップとそれに伴う前述のライセンス再購入費、プログラムの改修費などが発生する期間を含む長期にわたって比較すれば、両者の差はさらに拡大するに違いない。
また人件費への影響も見逃せない。今回掲載した野田スクリーンと大東はどちらも、IT担当者は1名のみである。名目上はITと他業務との兼務であるが、Windows時代は運用管理に手をとられ、事実上IT専任となっていた。
それがIBM iへの移行後は、どちらの担当者も、「本来の兼任体制に戻ることができた。それどころか実際のところ、IT関連の業務にはほとんど時間を使わなくなった」と指摘している。今回取材機会は得られなかったが、Windowsへ移行後、IT部門の人員が2倍近くに膨らみ、運用管理に疲弊した結果、IBM iに戻った回帰型ユーザーの例もある。
さらに、WindowsサーバーとIBM iでは「見えないコスト」が存在する。
信頼性・安定性に優れたIBM iに対して、オープン系サーバーでは障害対応に多くの時間を割かれる。
またセキュリティ対策費も、導入時には見えにくいコストの1つだ。Windowsでは脆弱性を突いた多種多様な攻撃を想定してセキュリティ対策を実施する必要がある。しかしIBM iでは1988年の発売以来、ハッキングやクラッキングの被害は1件も報告されていない。
導入時は、どうしても初期コストの差に目が向きがちである。導入状況やハードウェアスペックにもよるので安易な判断は避けたいが、IBM iとWindowsサーバーを比較すると初期導入コストはほぼ同額、もしくはIBM iのほうがやや高いケースがあると聞く。
しかしOSのバージョンアップ費用を含めた長期スパンのコストに、前述した見えないコストを加えれば、総じてアプリケーションを長く使用できるIBM iのほうが、コストパフォーマンスに優れると言えるのではないだろうか。
根強く残る「自社開発型」文化
業務にシステムを合わせたい
本特集に掲載する野田スクリーンと大東は、どちらもWindowsサーバー上で国産ERPパッケージを導入していた（利用製品は異なる）。ERPパッケージでよく言われるように、当初は独自要件に基づくカスタマイズは最小限に抑え、業務をシステムに合わせる運用に努力していた。
しかし業務上の必要性やエンドユーザーからの要望に、パッケージの標準機能だけでは応えきれず、結果的には多くのカスタマイズ開発を実施することになった。追加開発を繰り返したために、システムが複雑化し、不具合の発生や運用管理の煩雑化をもたらす状況になったことが、IBM iへの移行を決断した理由の1つに挙げられている。
とくに大東では、Windows時代のパッケージ運用経験を経て、IBM iへの移行後は自社開発型の（実開発は外部ベンダーに委託）システムを作り上げている。
またIBMのビジネスパートナーである（株）高木システムは、電気・電子部品や機械器具の専門商社に特化した販売管理システム「TREE」を提供している。IBM i上でのみ稼働するシステムなので、新規ユーザーを獲得する場合は、Windowsサーバーからの移行案件が多くなるという。
たとえば2014年、ある専門商社で「TREE」が本稼働した。このユーザーでは数年間、Windowsサーバー上で海外製ERPパッケージを運用していた。このERPパッケージの場合、導入時のライセンス費とは別に、クライアント本数分の使用料金を毎年払わねばならない。毎年の使用料が大きなコスト負担となり、同社では1人1台のクライアント体制を実現できなかったという。また海外製ERPパッケージでは独自の業務ニーズに沿ってあまりカスタマイズができなかったこともあり、コストの問題や業務要件の反映を考えて、高木システムの提案する「TREE」とIBM iの導入を決めた。
実は同社は以前にAS/400の運用経験があり、そのよさを見直してIBM iに戻ってきた回帰型ユーザーである。ただし現在は社内に、IBM iを知っている世代と知らない世代が同居している。「TREE」はパッケージ製品ではあるが、独自要件に応じて適度にカスタマイズも実施し、今では使い勝手のよい基幹システムが完成している。
本特集の取材でも、国産あるいは海外製を問わず、ERPパッケージを運用していたものの、カスタマイズが十分に実現できず、自社ニーズを忠実に反映できるスクラッチ開発型、もしくは「パッケージ＋カスタマイズ」型での導入を目的にIBM iへ移行したケースが少なからずあると聞いた。
長い歴史をもつIBM iは、RPGという生産性の高い開発言語の存在もあり、自社ニーズを忠実に再現する「自社開発型」「内製主義」の文化が根強く残っている。パッケージ製品の導入も増えているが、財務会計など標準化が進んだ分野を除き、販売管理や生産管理などでは、パッケージを導入しても独自要件に基づきカスタマイズするケースが多い。
Windows環境でEPRパッケージを利用する不自由さを解決したいと考えるユーザーが、業務にシステムを合わせて導入を考えるIBM iのアプローチに魅力を感じても不思議ではないだろう。
＊
IBM iへの移行、とくにIBM i未経験のユーザーがIBM iという未知の世界の扉を開けるには、いくつかの壁がある。「よく知らない」ことへの不安、そして「オフコンである」という誤ったイメージ、さらに「IBM iはいつまで存続するのか」という疑問。
IBM iは、IBMの最新テクノロジーを結集したPower Systemsというハードウェア上で稼働する。最新バージョンであるIBM i 7.3が、オープン系の要素技術を含めた多彩な機能を備えていること、そしてIBMから2026年までのロードマップが公開されていることは、本誌の特集「IBM i 7.2」に詳しいので参考にしてほしい。
重要なのは、基幹システムを稼働させるサーバー要件とはどうあるべきか、である。このテーマを突き詰めていけば、その先にIBM iが見えてくるのは間違いないであろう。
････････
i Magazine 2016 Summer（8月）掲載
