XML＆Webサービス開発事例研究（3）

BIソリューションを支えるXML／Webサービス
〜データウェアハウスからBIツールの全社展開へ〜

XMLとWebサービスの事例を紹介していく本シリーズの第3回は、データウェアハウス構築を起点にBIソリューションを導入しようとする企業動向を取り上げ、大手SIerの視点によるテクノロジ要件とXML、Webサービスが果たす役割をレポートする。（編集局）

編集局
2003/12/26

■BIソリューションを後押しするビジネス環境の変化

EISの抱えている問題

主な内容 BIソリューションを後押しするビジネス環境の変化 　　・EISの抱えている問題 　　・現場発の新たなニーズにどう応えるか 　　・データウェアハウスからBIシステムへ BIソリューションを手掛けるSIerの選択 　　・100％のWeb対応であること JavaとXMLを基盤にするCognos ReportNet 　　・Javaアプリケーションとしてのメリット 　　・中間データとしてのXML、そしてメタデータ Webサービスは情報系システムに定着するか

　これまでの情報統合型システムは、経営幹部の限られた人しか利用できないツールであった。これはEIS（エンタープライズ情報システム）と呼ばれるもので、ボタンをクリックするとその日の経営状況（売り上げデータや在庫データなど）がディスプレイに表示されるシステムだ。経営幹部に見せるレポートなので全社的なデータを収集できればよく、あまり複雑な検索は求められない。単に必要なレポートがきれいなレイアウトで表示されればよかった。

　ところで、EISパッケージ製品はライセンスのみで600万〜700万円、ハードウェアや開発費を加えると最低でも2000万円以上の投資が必要になる。経営幹部に見せるレポート作成という限られた用途のために、高価なパッケージ製品を導入する企業は非常に限られているのが現状だ。

現場発の新たなニーズにどう応えるか

　高価なEISシステムを導入している企業で、最近になって経営幹部以外の社員から「うちはEISシステムを入れているのだから、自分たちにも使えるようにしてくれ」という要望が情報システム部門に寄せられるという。ビジネス環境の急激な変化に直面している現場の社員にとって、情報ツール導入の要望は当然といえるだろう。質の高い情報を素早く取り出して活用したいのは、なにも経営幹部に限った話ではないのだ。

　経営幹部用のEISであれば、定型帳票のイメージをPCのディスプレイに表示できればよく、あらかじめ決まっている情報を取得してレイアウトすればよかった。これはそれなりに利用価値はあるのだが、運用方法としては、経営層が必要としている帳票内容を情報システム部門が作り込みをして実現するもので、扱う情報も網羅的なデータが中心である。

　これに対して、昨今のニーズは非経営層の社員がツールを使って自分で情報を取り出し、加工したい、というものである。いちいち情報システム部門に作り込みを依頼しているようでは、現場の動きに素早く対応できない。また現場から上がってくる要望は、従来の定型帳票には収まらない複雑な情報加工を要するものも多い。これらにその都度情報システム部門が対応していては、彼らの負担は重くなる一方で、結果的に対応できる範囲も限られてしまうだろう。実はこのような状況を予測できるので、EISシステムは非経営層には公開してこなかったという側面もあるようだ。

　しかし情報マネジメントの理想をいえば、経営幹部だけでなく中間管理職、あるいは現場の社員に対して、自社の保有する有用な情報は積極的に公開するべきである。現在では一般社員のコンピュータリテラシーは非常に高く、ExcelやAccessなどを使ったデータ加工などできて当たり前だ。ならば、一般社員が自身でデータを収集し、加工できるツールを与え、企業のデータウェアハウスに蓄積された情報を利用させたらいい。

データウェアハウスからBIシステムへ

　このようなニーズが浮上してきた背景には、企業がデータウェアハウスを構築してある程度の年月を経たことがある。データウェアハウス導入の先進事例は1990年代中ごろからで、1990年代後半には多くの企業が続き、現在では一定規模以上の企業ではほとんど導入が終わっている。つまり、データウェアハウスの中に利用価値の高いデータが数年分蓄積されているのだ。

　それでもコストの掛かるEIS製品の導入まで踏み込んでいる企業は圧倒的に少ない。現時点でのデータウェアハウスは、データベースを中心としたデータの保管場所であって、BI（ビジネス・インテリジェンス）システムとは呼べないものだ。しかしここ数年で、IAサーバの性能向上などハードウェアの価格は劇的に下がっているし、テラバイト級のデータを扱えるサーバ環境も整ってきた。

　ほんの3年前には、複数のUNIXマシンを並列処理させる構成では、ハードウェアだけで数億円掛かっていたが、現在では1台のマシンで同じCPUパワーを発揮できる。それほどコストを掛けなくても、一般社員の頻繁なアクセスを可能にするシステムを構築できるのだ。システム基盤が整ってきたことで、全社展開を前提としたBIソリューションの立ち上げはにわかに現実味を帯びてきた。

■BIソリューションを手掛けるSIerの選択

　SIer（システム・インテグレータ）の大手、アイ・ティ・フロンティア ソリューション推進統轄本部 井原一氏によると「BIソリューション製品を単なるレポーティングツールの手段から、全社員が活用する情報インフラととらえる顧客が増えている」という。当初は経営幹部だけが使うシステムとして立ち上げたとしても、「非経営者層からも使いたいという要望が出てくるのは前もって分かっているので、全社システムに展開できるような視野を持っている顧客が多い」。情報統合に積極的な経営者は、自分たちが使う範囲以上のことを実現する情報システムを求めているようだ。

　データウェアハウスを導入すると、それに伴って、レポートを出力するシステムも検討するユーザーが多いが、特に最近ではデータを収集するだけでなく、一般社員向けに情報を開放しようという動きが強まっている。流通業、製造業、通信メディアなど、特に業種には偏らず、データウェアハウスを導入した企業では、一般的にこのニーズがあると井原氏は指摘する。従業員数でいえば数百〜数万人の企業で、データウェアハウス導入をきっかけにBIソリューションを構築しようという動きがあるという。

図1　データは限られた幹部社員のものから全社的なインフラへ移行しつつある

　ホストコンピュータを使って定型帳票を出力するシステムでは、作り込みを前提としたシステム開発であったため、情報システム部は大変な負担を抱えており、彼らからも社員に自立して情報ツールを使ってほしいという本音が聞かれる。従来のレポーティングツールは利用者が限られており、なおかつクライアント／サーバ型のシステムだったので十分対応できていた。ところが一般社員にまでデータを開放しようとすると、どうしてもWeb対応にしなければならない。

100％のWeb対応であること

　アイ・ティ・フロンティアがBIソリューション製品として選択したのはレポーティングツールの「Cognos ReportNet」である。最近の顧客ニーズに対応するにはWeb対応は必須条件だが、Cognos ReportNetは当初から100％Webベースとして開発されており、「この点が非常に重要だと考えた」（井原氏）。他社の製品は基本的にクライアント／サーバ型で作られており、後付けでWeb機能を追加したものがほとんどだったという。これらの製品では、クライアント／サーバ型で実現可能な機能の一部しかWebベースで実現できない。よくて70％、下手をすると半分の機能しかWebベースで使えず、Webベースでできるのは閲覧だけというケースが非常に多い。

　つまり、データ分析に関しては、情報システム部の担当者がクライアント／サーバ型機能を使ってあらかじめレポートを定義しておかなければならず、ユーザーはその結果をWebで見るだけ（配信機能のみ）になってしまう。これでは情報システム部の負担はいっこうに減らない。閲覧以上のこと、つまりデータ分析をユーザー自身にやらせるなら、クライアント・アプリケーションを全社員に導入する必要があるが、それはコストの面からほぼ不可能だ。

　この点について、井原氏は「Cognos ReportNetは、初めからWebベースの機能だけに絞られているので、目移りしなかった。しかも従来のクライアント／サーバ型のレポーティングツールに対して、機能的に劣るところはなく、逆にアドバンテージさえあった」という。

図2　Cognos ReportNetのシステム概念図

　アドバンテージとしてアイ・ティ・フロンティアが着目したのは多言語対応版としてリリースされていること。実はこの部分で、SIerはこれまでさんざん泣かされていたという。海外ベンダの製品では英語版で動いているのに、日本語版では動かないということが非常に多い。特に日本法人がしっかりしていないところだと、日本語版だけにあるバグへの対応が後回しにされてしまう。Cognos ReportNetはJavaで実装されているため、リリースされているのは多言語対応版が1つだけで、最初から2バイト文字が通る製品であることは開発者に大きな安心感を与えたようだ（Javaについては後述する）。また、通貨表示が各国語対応しているなど日本の帳票文化に適合したきめ細かい表示機能が備わっている、フォルダ単位でのアクセス制御、カスタマイズ環境が整っている、などもアドバンテージだったという。

■JavaとXMLを基盤にするCognos ReportNet

Javaアプリケーションとしてのメリット

　基本的にCognos ReportNetはJ2EE上で動作するJavaアプリケーションである。製品には標準でTomcatが搭載されているが、商用アプリケーションサーバで動かすことも当然可能で、プラットフォームも、Windows、UNIX（Solaris、HP、AIX）で動く。「UNIXが使えるというスケーラビリティの面が大きいのと、アプリケーションサーバとしてWebSphere、WebLogicが使えるという安心感があった。冗長構成はアプリケーションサーバ側で構築するので、すでに開発者側でアプリケーションサーバによる多重構成のノウハウを持っていると、その蓄積をそのまま活用できる。これなら数万人規模の全社システムにも対応できる」（井原氏）

図3　Cognos ReportNetのJavaアプリケーション・アーキテクチャ

中間データとしてのXML、そしてメタデータ

　各コンポーネントやデータベースとWebブラウザ間を流れる中間データとして、Cognos ReportNetはXMLを使っている。例えば、あるデータベースに対してどんなSQLを投げるかは、以下のようなXMLで定義されている。

<string id="sql_replicate">replicate</string>   <string id="sql_replicate.syntax">replicate( <文字列>, <整数> )</string>   <string id="sql_replicate.tip"><文字列> を <整数> 回繰り返した文字列を返します。</string>   <string id="sql_sign">sign</string>   <string id="sql_sign.syntax">sign( <数値> )</string>   <string id="sql_sign.tip"><数値> の符号を示す値を返します。<数値> が正の値の場合は '+1'、ゼロの場合は '0'、負の値の場合は '-1' を返します。</string>   <string id="sql_space">space</string>   <string id="sql_space.syntax">space( <整数> )</string>   <string id="sql_space.tip"><整数> 個のスペースで構成される文字列を返します。</string>   <string id="sql_str">str</string>   <string id="sql_str.syntax">str( <数値> [ , <整数 1> [ , <整数 2> ] ] )</string>   <string id="sql_str.tip"><数値> の文字列による表現を返します。<整数 1> は返される文字列の長さ、<整数 2> は小数点以下の桁数です。</string>   <string id="sql_stuff">stuff</string>   <string id="sql_stuff.syntax">stuff( <文字列 1>, <整数 1>, <整数 2>, <文字列 2> )</string>   <string id="sql_stuff.tip"><文字列 1> の <整数 1> を開始位置として <整数 2> の文字数を削除し、同じ位置に <文字列 2> を挿入した文字列を返します。文字列の最初の文字の位置が 1 になります。</string>   <string id="sql_year">year</string>   <string id="sql_year.syntax">year( <日付> )</string>   <string id="sql_year.tip"><日付> から年の部分を返します。extract(year from <日付>) と同じ処理です。</string>

データベースなどバックエンドとフロントのブラウザ間に流れるXML中間データのサンプル

　もちろんこの部分はユーザーからは見えないし、開発者にとっても定義はツールで生成するので、開発の段階ですらほとんどXMLを目にすることはない。このようにXMLを内部的に利用していても、開発者にその存在を意識させないツールを用意することは、現在の情報系ミドルウェア製品に共通する傾向だ。開発者の負担を減らす、という意味でこのような親切設計は当然といえよう。ただ、XMLを水や空気のような存在として意識の外に追いやってしまえるわけではない。

　BIソリューションに代表される情報統合型のシステム開発で重要なのは、XMLによるメタデータの統合だ。異なる環境に混在するさまざまなデータを収集し、分析するBIソリューションでは、なんらかの基準によるメタデータ定義を避けて通れない。

　Cognos ReportNetはオープンな規格であるCWMI（Common Warehouse Metadata Interchange）に対応している。CWMIはXMLで定義されたデータウェアハウス向けのメタデータで、データウェアハウス系の製品、ETL（Extract／Transformation／Loading）ツール、あるいはデータベース自身が持っている場合もある。簡単にいうとデータベースの表や列の名前については、エンジニアは英文字の短縮形の名前を付けることが多い。例えば、在庫であればzXXXなど記号的な名前を付けるだろう。この際に生きてくるのがメタデータである。記号の名前を、実際にユーザーが使うビジネス用語に置き換えてくれる仕組みである。

　　 　列名　　zXXX　→　在庫○○

　ところが、こういったメタデータを各システムがバラバラに持っていると、1カ所の修正がシステム全体に影響を及ぼすことになる。あるシステムに新たなメタデータを登録すると、別のシステムでも再度登録し直さなければならなくなるわけだ。これは結局、ユーザー情報管理の抱えている問題（すべてのシステムが個別にユーザーリストを保持しており、パスワードの更新は全部のシステムで個別に対応しなくてはならない、ある人の所属組織が変わったら全部を変えなくてはならない）と同一で、データウェアハウスやその周辺のツールは同じような問題を抱えている。

参考記事 緊急提言：Webサービスの光と陰を考察する

　帳票に出てくるビジネス名とデータベースが使用する記号名（別名）がすべて統一されていると、エンドユーザーは製品名や数量をドラッグ＆ドロップするだけで帳票を作っていける。Cognos ReportNetは定義やデータ交換が業界標準の決まりでやりとりできる製品なので、システム構築はやりやすい。つまり、データウェアハウスやデータマートを作る際にきちんとデータを定義してしまえば、レポーティングツールはそれをインポートするだけで済むのだ。データは1カ所で管理するか、あるいは共通して使えるデータフォーマットで保持することは、情報統合を目的とした企業インフラとして重要な要素である。

■Webサービスは情報系システムに定着するか

　これからのBIソリューションで重要になってくるのは、Webサービスのインターフェイスだろう。例えば、ExcelのSOAPクライアントを使ってCognos ReportNetのシステムに直接データを問い合わせに行くようなカスタマイズが可能だ。アイ・ティ・フロンティアではCognos ReportNetのWebサービス機能について「まだ社内テストの段階であり顧客に納入した事例はない」と断ったうえで、「Webサービスが使われる機会は増えていくだろう。この製品はもともと冗長構成を取れるため、個々のモジュールを分散配置できる」という認識を示した。

　特に導入が進むと思われる構成は、レポートを実際に生成する場所と、クライアントがデータを受信する場所がファイアウォールで仕切られているような場合、あるいはデータウェアハウスがDMZ（DeMilitarized Zone）の中にある場合、それぞれのファイアウォール間の通信にSOAPを採用するとファイアウォールに穴を開けずに済む。SIerにとって、ここがWebサービスを採用する最大のメリットだという。実際に製品をインストールするときやテスト運用では意識する必要はないが、実際に顧客のシステムに導入し分散環境で運用を始めたとき、80番のポートならば通信できるというメリットは大きい。もちろんSSLのポート（443番）にすることも可能だ。このように製品の方でWebサービスへの対応が完了していれば、開発者は余計な労力を使わずに済む。

　将来、さまざまなアプリケーションがSOAP通信に対応してくれば、新たな展開も見えてくるだろう。例えば、SAPはSOAPのインターフェイスを備えているので、それをどうシステム開発に取り込んでいくかはSIerのアイデア次第だ。

　ただし、現時点ではWebサービスのBIソリューションでの活用は理想論だ。アイ・ティ・フロンティアのテストでは、各種のEAI製品のWebサービスアダプタを使った接続実験では、つながらないケースが多々あったという。原因は、完全に標準仕様に実装が合致していない、あるいは標準仕様のゆらぎといった原因だ。ほかには、製品のバージョンの違いによって相互接続に問題が生じるケースもある。ベンダは製品の内部実装情報は明らかにしないので、相互接続性については開発者で解決することは困難だ。

参考記事 Webサービス相互運用性

　逆に、「すべて開発者が作り込んだアプリケーション間でWebサービスを実装する限りでは、Webサービスを利用して大丈夫」（井原氏）という判断だ。おそらく現時点でWebサービスを運用しているのは、このケースがほとんどだろう。

　レポーティングツールによるBIソリューションは、リクエストを投げてレスポンスをもらうだけで、更新の仕組みは持たない。これはWebサービスを導入するには適した分野といえる。分析システムなら問題が生じても、レポートが出てこないといったレベルで済まされる。アプリケーション統合などにWebサービスを使用する場合は、トランザクション管理やセキュリティ確保が必要になってくるので、もっとしっかり規格が固まり、ベンダがきっちり実装してくる必要があるだろう。現在のSIerのスタンスは、将来に備えてWebサービスへの展開も準備しているといったところである。

◇

　今回は、レポーティングツールによるBIソリューションとXMLの重要性、そしてWebサービスの可能性について考察した。XMLはツールが内部的に使用する中間データというだけでなく、ビジネスインフラ構築のためのメタデータ統合という重責も担っていることを理解してもらえただろう。

取材協力 株式会社アイ・ティ・フロンティア ソリューション推進統轄本部 コンピテンスセンター　先進技術部　部長 井原 一 コグノス株式会社 マーケティング本部 副本部長 山田 和昭

■関連記事

　・緊急提言：Webサービスの光と陰を考察する
　・連載　Webサービス相互運用性
　・連載　ビジネスWebサービス最新事情


■連載

　1. Webサービスで運用するRFID制御システム
　2. リレーショナルDBへの挑戦
　3. BIソリューションを支えるXML／Webサービス

「XML&Webサービス開発事例研究」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）