メニューボタン
IBMiコラム2016.11.24

IBM i のウンチクを語ろう
~ その5:オールインワン

安井 賢克 著

皆さん、こんにちは。今回のテーマはオールインワンです。全てが一つにまとまっている、すなわちアプリケーション・プログラムを用意すれば、それを稼動させるために必要となるハードウェアやソフトウェア・コンポーネントの全てが揃っていて、直ちにシステムとして利用可能な状態にあることを言います。IBM i のユニークなアーキテクチャーの一つとしてこれをとりあげているつもりなのですが、市場を眺めてみると、この言葉自体はIBM i の「専売特許」でありません。実はオールインワンにも違いがある、今回はこの点から話を始めていきたいと思います。

どのようなシステムであれ、「オールインワン」の状態に到達するには、膨大な数の各種コンポーネント(部品)を組み上げる必要があります。ハードウェアとしてのマシンとその部品だけでなく、オペレーティング・システムやデータベースなどソフトウェア製品や、それらを補完する機能までも含みます。違いというのは、これらの最終組み立て工程がどこで誰によってなされるのか、という点にあります。

IBM i の場合は工場出荷の際にメーカーとして、オールインワンを達成することを目指しています。開発部門は最終製品を想定して各コンポーネントを設計開発し、工場ではそれを目に見える形に組上げ統合します。アプリケーション・プログラム以外のほぼ全ての機能がその対象になります。当然のことながら、このあらゆる工程において統合に向けたテストが行われ、相性の悪さが見つかれば修正されます。言わば、オールインワンは最初からデザインに組み込まれているわけです。ちなみに多くの方がご存知と思いますが、IBM i の「i」は「Integration」、すなわち「統合」の頭文字に由来しています。IBM i イコール統合、なのです。

IBM i コラム挿絵1

他システムのオールインワンは、インテグレータが既に市場にある製品を組み合わせ統合することによって達成されます。ここで言う製品とは、アプリケーション・プログラム導入前の最終形ではなく、その手前の言わば部品の段階にあります。そして市場にある部品のメーカーが責任を持つのは自社製品に対してであって、ユーザーが利用するであろう最終形としての統合されたシステムに対してではありません。

統合の過程で相性の悪さが見つかったなら、インテグレータは各部品メーカーに修正を要求します。この時に部品メーカーは自社製品の問題と判断すれば修正を行いますが、相方の他社製品に原因があると判断したら要求は受け入れらません。誰が修正作業を行うべきかなかなか決着しない、もしくは致し方なく回避策をもって運用で「逃げる」しかなくなるかも知れません。

システムとして組み上がり、運用フェーズに入れば安心かと言うとそうではありません。どこかでバグが見つかるかもしれませんし、部品毎にサービスパックがリリースされるかも知れません。せっかく稼動しているシステムなので余計なことはしたくないと思ったとしても、製品の寿命には限りがあります。メーカーのサポートを受け続けるためには、どこかのタイミングでバージョン・リリースをアップグレードしなければなりません。IBM i であればシステム全体の同期をとりながらアップグレード作業を行うことができます。他のサーバーであれば、部品単位でのアップグレード作業になりますので、他部品との相性の良し悪しの懸念が再度浮上します。

オールインワンがシステムのデザインに組み込まれているか否か、ということは、システムとして構築するだけでなく、その後の運用の手間に影響するわけです。仮にその部分をインテグレータに委ねたとしたら、それはインテグレータに対する費用支払いのネタを作り出しているに過ぎないかもしれません。システムを組上げる作業は、お客様自らが取り組むケースもあるでしょう。そうなるとインテグレータと同じ作業を、部品を選定する段階から取り組まなければなりません。経営に役立てるためのシステムであるはずなのに、その構築と保守を行うことが目的化してしまうようでは本末転倒です。

明確に数値で表現されているわけではありませんが、オールインワンはさらにシステムとしての信頼性にも関わると考えています。例えば日経コンピュータ社が毎年実施している、IT製品に関する顧客満足度調査結果を見ると、IBM i 搭載パワーシステムはその信頼性において、他システムと比べて極めて高い評価をいただいています。

高価で信頼性の高い部品を使用しているからですか、とお客様から問われた事があります。私はそうではないと考えています。同じ世代、同じテクノロジーをもって作られた各部品の品質に、有意性のある違いはないであろうというわけです。システムに統合するプロセスの違い、どれだけ早期に相性の悪さを設計・開発の過程で洗い出し、修正した結果を製品に反映させる事ができるのか、の違いです。万一運用開始後において何か不具合が発見されたとても、メーカーとして迅速に保守サポートできる体制の違いでもあります。

これまで見てきたように、IBM i のオールインワンはテクノロジーというよりも、部品からシステムまで、設計・開発から生産、さらにはその後の保守にいたるまでの、製品ライフサイクル全体を貫いている極めてユニークなプロセスであることがわかります。

そろそろ紙面も尽きてきたようです。次回は単一レベル記憶について述べる予定です。

あわせて読みたい記事

サイト内全文検索

著者プロフィール

パワーシステム・エバンジェリスト

安井 賢克
やすい まさかつ

2017 年 11 月付けで、日本アイ・ビー・エム株式会社パワーシステム製品企画より、ベル・データ株式会社東日本サービス統括部に転籍。日本アイ・ビー・エム在籍時はエバンジェリストとして、IBM i とパワーシステムの優位性をお客様やビジネス・パートナー様に訴求する活動を行うと共に、大学非常勤講師や社会人大学院客員教授として、IT とビジネスの関わり合いを論じる講座を担当しました。ベル・データ移籍後は、エバンジェリストとしての活動を継続しながら、同社のビジネス力強化にも取り組んでいます。

PAGE TOP