[技術解説]

2009年2月6日(金)平井 明夫

リスト

BIは大きく3つの時代を経て進化してきた。具体的には「オープンシステム時代」「Web時代」、そして現在の「ERP統合時代」である。つまり、コンピューティングスタイルの変化と共に、機能や存在価値を変化させてきたのだ（図3-1）。

図3-1 システムアーキテクチャや用途で見るBIの変遷
 

最初のオープンシステム時代は、1990年から97年ごろを指す。いわばBIの“黎明期”に当たり、クライアント/サーバー型での活用が基本だった。UNIXサーバーの普及によって情報系という分野が生まれ、それまでEIS（Enterprise Information System＝経営者向け情報システム）とかDSS（Decision Support System＝意思決定支援システム）などと言われていた分野がBIに発展。クライアント側のアプリケーションを開発するツールも多く登場し、いわゆる「ファットクラアント」でのコンピューティングスタイルが基本だった。

このクライアント/サーバー型アプリケーションの1つとして、汎用機やオフコンからデータを取り出し、それらデータをサーバーに移行した上でクライアントPCから分析するOLAP（オンライン分析処理）が始まった。キューブ型の多次元データベースを使って所定の集計処理をサマリーしておき、スライス&ダイスやドリルダウンといった手法で様々な分析結果を得るBIツールが、営業やマーケティングの分野で使われるようになった。

当時のOLAP分野における代表的なツールとして、フロント系では加コグノスのPowerPlay、多次元データベースでは米アーバーソフトウェアのEssbaseや米IRIのExpressなどが挙げられるが、ユーザーはパワーユーザーに限られ、それほど多くの人が使うものではなかった。

この時、BIと並行して市場の注目を集めていたのがデータウェアハウス（DWH）だ。ハイエンドマシンの登場によって生まれたDWHというデータの活用分野は本来、BIとは別の世界。そこでは、ITリテラシーが高くないエンドユーザーでもDWHのデータを活用できるように配慮した「Query & Report」ツールが提供され、情報システム部門主導で導入が進んだ。

具体的な製品としてはBuisnessObjects、BrioQuery、Cognos Impromptu、MicroStrategy、Oracle Discovererなどが挙げられる。機能としてはそれほど高度なものではなかったが、一般ユーザーを対象とした製品だけに数がはけて、ベンダーにとって手離れもよかった。例えばコグノスでは、看板製品はOLAPツールのPowerPlayでも、ビジネス面ではImpromptuが支えるという構図になっていた。

OLAPツールとQuery & Reportツールの時代は長く続いた。しかし、OLAPツールはメンテナンスが難しく、高度な技術スキルが要求されたことから、広く浸透するには至らなかった。一方、Query & Reportツールは、DWHのデータ「抽出」ツールへと変化していくことになる。

機能衰退を起こしながらもWeb対応でコモディティ化

インターネットの普及と共に97年ごろから始まったWeb時代は、ITインフラの変化によってコンピューティングスタイルが大きく変化した時代である。BIから見れば特に必要な変化ではなかったが、DB/アプリケーションサーバー/ブラウザの3層型に対応するのは時代の趨勢から必然だった。OLAPツールもQuery & Reportツールも、Web対応を余儀なくされた。

しかし、これは一時的にせよBIツールの機能の退化につながった。BIの中心的な機能をアプリケーションサーバーに置き、表示系をクライアント側で処理するわけだが、Javaアプレットの成熟度はまだ低く、ネットワークインフラも細かった。このため、ユーザーインタフェースが貧弱にならざるを得なかったのだ。

この流れの中で、Query & Reportツールは「Webレポーティングツール」へと変化した。もともとITリテラシーが高くないエンドユーザー向けのツールだったが、ブラウザベースでさらに簡単に操作できる点が受けてユーザー数は一気に増えた。これはBIのコモディティ化の始まりであり、高度な分析という意味からは、BIの空洞化ともとらえられた。ただ、BIベンダーにとっては、ビジネスを拡大するチャンスだったことは確かだ。

このころ、もう1つの大きな変化が起こった。RDBのキャッシュ技術の進化、ストレージとのデータ通信の高速化、CPUパワーの増大などによって、多次元データベースのようなキューブ型のモデルで分析を行う必然性が薄れたのである。

多次元モデルによるOLAP、つまりM-OLAP（Multi-dimentional OLAP）は、データをバッチ処理で取り出して、あらかじめ多次元DBにデータを格納し、ユーザーの要求に応じて切り出すことで、クロス集計などを高速化していた。スライス&ダイスという、BIの代名詞的な使い方は、M-OLAPの最も得意とする分野だった。

これに対してRDBで多次元分析するR-OLAP（Relational OLAP）は、分析要求に対して都度クエリなどの処理を行うため時間がかかり、実用的ではないとされてきた。ところが先に触れたコンピューティング能力の向上によって、問題なく使えるようになった。フロントのOLAPツールがWebへ対応すると共に、サーバーサイドでは単純なOLAPであればR-OLAPで十分対応できるという考えが広がり、M-OLAPの有意性が薄れてしまった。

もっとも、M-OLAPがどうしても必要な分野もあった。管理会計の分野である。勘定科目の体系や企業の組織は、「不均一階層」の構造を持っており、大量のデータを処理する上では、RDBで表現するのに向かない。管理会計ソフトウェアベンダーとOLAPツールベンダーの統合が始まることになった背景の1つはここにある。不均一階層とは例えば、「営業本部の下に営業部と営業企画部、営業管理課があり、営業部はさらに営業1課と2課に分かれる」といったように、組織や体系内の階層の数にばらつきがある状態を指す。

管理会計ソフトの大手である米ハイペリオンソリューションズがEssbaseやBrioQueryといったBI関連ツールを買収によって手中にする一方、BIベンダー大手の仏ビジネスオブジェクツが管理会計ソフトの仏カルテシスを買収したのは典型例だ（図3-2）。「単体ではビジネスにならない」といった認識のもとで統合が進み、今のERP統合の時代につながっている。

図3-2 メガベンダー3社の企業買収の経緯（図をクリックでPDFをダウンロード）