「OfficeがWebブラウザを置き換える」と言われて,違和感を覚える読者は多いだろう。インターネットでもイントラネットでも,クライアントにはWebブラウザがあれば十分。それをOfficeで代替すると言われても困ってしまう。

 ところがMicrosoftは,それを本気で狙っている。多様なシステムのクライアントを目指して,次期Officeは製品の名称まで変更した。名称は「Office System」。日本語版の登場は2003年第3四半期の予定である。

Webシステムのクライアントを目指す

 MicrosoftがOffice Sytemで主に狙うのは,企業の業務システムのクライアントである。Webブラウザを完全に置き換えようとは,さすがに考えていない。業務システムのクライアントとしては,Webブラウザは使いにくい面がある。そうした場合にOfficeを使ってほしいというのがMicrosoftの提案なのだ。

 ブラウザが使いづらいのはデータ入力の場面である。元々ブラウザは,さまざまな情報を閲覧するためのもの。データを入力する機能は二の次なのである。

 例えば交通費精算のためのWebシステムを考えてみる。入力フィールドが縦横に並び,各行で日付や乗車駅,降車駅,運賃などを入力する。ブラウザで面倒なのは,入力フィールド間のカーソル移動である。Tabキーで順に移動するか,いちいちマウスを操作するしかない。行の追加や削除も特別に作り込まない限り無理である。1行抜けていることに途中で気付いたら,そこから入力をやり直すことになる。
 
 Excelなら,そんなことに苦労しなくていい。カーソルの移動は自由だし,行の追加・削除も簡単だ。大量の表形式のデータ入力も難なくこなせる。余白を電卓代わりに使って結果をコピーすることもできる。

 Officeならではの活用方法もある。データを受け取って,さまざまな形に加工できる。例えば売上データをExcelでグラフ化したりシミュレーションしたりできる。ブラウザだと,あらかじめ決まった通りに表示することしかできない。

 こうしたOfficeの利点が生かせる場合に,Microsoftは次期Officeを使ってほしいと考えている。

Webサービスへの対応で連携を容易に

 業務システムへの接続を容易にするのに,MicrosoftはWebサービス技術を取り入れた。Webサービスは,Webの技術を使って異なるシステムを連携させる仕組みである。Microsoftのほか,米IBMや米Sun Microsystemsなど多くのベンダーが推進している。Webサービスに対応すれば,Officeはさまざまなシステムと連携しやすくなる。相手がUNIXシステムでも関係ない。

 Webサービスでは,交換するデータ・フォーマットに業界標準のXML(eXtensible Markup Language)を使う。通信プロトコルは「SOAP」。XMLを電子的な“封筒”に入れてやり取りするためのプロトコルである。マルチベンダーのシステムであっても,SOAPの相互接続は問題ないレベルになってきている。

 そこでOffice SystemではXMLへの対応を大幅に強化した。Excelでは,セルのデータをXMLデータの要素として対応付けられるようにした。ExcelファイルからXMLデータをエクスポートしたり,逆にインポートしたりできる。WordではXMLデータの構造に応じた文書作成が可能になった。Office Systemではさらに,XML技術を全面的な採用したソフト「InfoPath」(開発コード名「XDocs」)も新たに用意した。

 もちろん現状では,Webサービスに対応したWebシステムは数少ない。企業間の電子商取引システムなど,Webサービスの適用分野は今のところ限られている。ただ,より使いやすいシステムを作るために,Officeをクライアントに使ってWebサービスと組み合わせる選択肢を提示してきたとは言えるだろう。「Office SystemはWebサービスの新たなイノベーションを生む可能性がある」(イー・ブリッジ コンサルティング本部長の岡部惠造氏)という声もある。

機能がどうも中途半端

 このように新しい用途を目指して開発されたOffice System。日経バイト2003年6月号でOffice Systemの特集記事を執筆するに当たり,その機能を評価してみた。2003年4月にマイクロソフトが配布したベータ版を利用した。

 Office System全体を見ると,確かにXMLへの対応は大幅に強化されている。Webサービスのシステムとつなぐ仕組みも用意されている。しかし感想を一言で表すと「どうも機能が中途半端」となる。「これは当然あるだろう」という機能が意外になかったりするのだ。

 業務データの管理に幅広く使われている「Excel」では,ワークシート内のデータをXMLファイルとして読み書きする機能が加わった。ところが,それをWebサービスとやり取りするのが容易ではない。面倒なコーディングをしないとWebサービスにつなげないのである。XML技術を全面採用した前述の「InfoPath」なら,コーディングなしにWebサービスに接続できる。Excelで同じような機能が使えないのは,どうにも不満である。

 InfoPathはXMLへの対応で比較すると,Officeの中で最も進んだソフトである。InfoPathは,XMLがデータと文書の両方の性質を持つという特徴を生かしている。文書そのものと,文書固有の属性情報とを用途に応じて独立に扱えるのである。

 ワープロなどで作成する文書では,文字にさまざまな装飾を付ける。フォントの種類や大きさを指定したり,左寄せや右寄せといった書式を選んだりする。一方見積書や業務日報のような定型的な文書では,複数の文書を比較するデータとして取り扱いたいものがある。データとして扱う際には,文書に付随する装飾のための情報は不要になる。

 こうしたときにXMLなら,データ本体(XMLデータ)と,装飾やレイアウトのためのデータ(スタイルシート)を分けて管理できる。InfoPathの文書は,実際にXMLデータとスタイルシートが分かれた構造になっている。このため見積書や業務報告書をInfoPathで作成すれば,文書として保存すると同時に,そのなかのデータを集計/分析できる。

 InfoPathは,Webサービスとの親和性も高い。作成したXMLデータをWebサービスとやり取りするのにコーディングの必要がない。GUI画面でWebサービスのURLを指定したりするだけでWebサービスに接続できる。

 このInfoPathにも機能面で不満がある。まずデータの計算が苦手である。データの合計程度ならいいが,ちょっとまともな計算をさせようとすると途端にコーディングが必要になる。単価と数量から合計を出すといった計算である。見積書といった定型文書には,こうした計算はなくなてはならないものだろう。また,一つの文書でXMLデータを1種類しか扱えないという制限もある。複数のWebサービスにアクセスする文書を作成するには複雑なコーディングが必要になる。

Sunもリッチ・クライアントにアプローチ

 Officeのようなリッチ・クライアントを業務システムで使いたいというニーズは確かにある。通常はWebブラウザで十分だが,テン・キーでデータを大量に入力したいような場合にはリッチ・クライアントを使いたい。

 例えばSun Microsystemsも最近になって,改めてリッチ・クライアントへのアプローチを進めている。現在,JCP(Java Community Process)でJavaServer Facesと呼ぶ技術を開発中である。これは基本的にはWebブラウザのインタフェースを簡単に作成できるようにするもの。GUIベースのツールで「ボタン」や「入力フォーム」などを画面上で貼り付けていくだけでWebページが作成できる。Sunはこの仕組みの延長線上でリッチ・クライアントに対応しようとしている。詳細は不明だが,ツールを使ってWeb画面とリッチ・クライアントの両方を自動生成できるようにしたいようだ。

 リッチ・クライアントの実現手法はほかにもある。「米MacromediaのFlashも有力な候補」(日本IBMソフトウェア事業部WebSphere事業推進の伊藤かつら営業企画推進部長)。旧来からのVisualBasicやJavaアプレットを使う方法もある。しかし「その本命はまだ見えていない」(ウルシステムズCTOの山岸耕二氏)。

 「何でもWebブラウザで」から「場合によってはリッチ・クライアント」に考え方が移行するのは確実と見てよさそうだ。その本命が何になるかを今後も追いかけていきたい。

(安東 一真=日経バイト編集委員)