オピニオン：いまなぜWebサービスか？
第1回　Webサービスは、本当にブレイクするか？

渡邊 純一
日本アイオナテクノロジーズ株式会社
パートナー・ストラテジー担当ディレクター
2002/2/23

■Webサービスの静かなブーム

　ここ数カ月の間、筆者は仕事でさまざまな顧客を訪問してきた。すると、さすがに「Webサービス」なるものがどんなものであるかについては、程度の差こそあれ、行く先々で理解が浸透してきているのだなと実感している。すでにWebサービスのプロトタイプ的なものまで作成しているユーザーもいる。しかし、一方で、Webサービスの考え方は分かったが、

• それはそんなにスゴイものなのか
• EAIやBtoBと一体何が違うのか
• そして、それはほんとうに「使える」モノなのか
• 今後伸びるモノなのか
  

という疑問も少なくないことを感じている。　ITの新技術が台頭する際には、最初に熱狂なり、興奮をもって迎えられる時期があるものだが、その熱狂期を過ぎると、一転して今度は、“criticism”にさらされる。つまり、「いわれているほど、効果はあるのだろうか」という疑問である。

　米国でもITバブルが弾けて以来、投資家は一転、ITベンダに対して疑問符を突き付けてきた。そのことを裏付けるようにeマーケット・プレイスやBtoBはそれほど進展してこなかった（それには、それなりの理由があるのだが……）。Webサービスも、本当にこれから普及する技術なのだろうか、ROI（投資効果）などの効果のあるものなのだろうか。まだ様子見の段階ではないのか。さらにいえば、昨今の経済の不透明性の中で、あえていまこのような新技術に取り組むだけの必然性があるのだろうか。

　他方、米国の各アナリストのWebサービスに関するレポートを見る限り、Webサービスは、おおむね好意的に見られているようだ。　その理由として、Webサービスが、

• インターネットの普及とその要素技術（HTTP、HTML、XML、分散コンピューティング）を土台としていること、つまりこれまでの技術の積み重ねのうえに成り立つということ
• より「速く」実現できる技術であること
• これまでのEAI、BtoB技術に比べて、より「簡単に」「柔軟に」実現できること
• これまでの技術に比べて、より「安く」できること

　であるからと見ている。実際に、The Stencil Groupが2001年6月に発表したレポートでは、Webサービスの本格的な普及は2002年後半からとしている。

■日本での普及は今年からか

　日本でも数多くのIT系雑誌では、Webサービスは2002年から普及期に入ると見ている。Webサービスは、一昨年に登場したが、約1年から1年半の「様子見」とプロトタイプ作成による評価期間を経て、本年後半よりようやく普及するというのである。

　従来、米国で普及したIT技術の日本への到来は、2〜3年（場合によっては5年？）を要するのが一般的と考えられていた。しかし日本におけるJavaやXMLの普及などを見れば分かるように、Early Adapterにとっては、「チャレンジャー」であるが故に、日米の普及格差は縮小する。筆者の感覚としても、Webサービスの普及期については、日米同時といっても過言ではないと見ている（もっとも、それはあくまでも「Early Adapter」についていえることなのだが）。

　筆者は1月下旬より米国に出張し、IONA Technologies社の年度始めのキックオフ・ミーティングに参加した。あの同時多発テロ事件の余波はいまでも続き、米国内の空港では、ボストンのローガン空港をはじめとして、その異常ともいえる「戒厳令」的な手荷物検査、ボディチェックの厳しさに閉口させられた（筆者の人相が特別悪いのではない。大半の旅行者が同じ思いをするのだから）。しかし、この出張でいくつかのユーザー事例を見てきて、米国企業ユーザーのWebサービスに対する期待は大きいのだ、ということを実感し、この連載のための情報収集にも大いに役立ったと思う次第である。

　連載では、こうした先進ユーザー事例も取り上げていきたい。

■Webサービスの意味するもの

　読者諸氏にとっては、「Webサービスとは何？」ということはすでにご存じだと思う。ただし、「Webサービス」という名前はあまりに漠然としている。そのおかげで、さまざまな誤解や困惑が生じているのも事実だ。ここでは、おさらいの意味も含めて、The Stencil Groupの定義を例に取ってWebサービスの説明を試みてみよう。

（1）Webサービスとは、再利用可能なソフトウェア・コンポーネント群から構成される
Webサービスは、これまでの「オブジェクト指向デザイン」の発展型である。プログラムの処理機能を、「始めから終わりまで」一気に書き上げるのではなく、よく利用される機能を「コンポーネントとして」整理し、再利用できる形にして、かつ内部をカプセル化して隠蔽してしまう。こうすることによって、期待される機能とイン／アウトだけ知っていればだれでも利用できるように単純化することができる。結果、プログラミングの生産性は、極めて向上する。Webサービスでも、すでにWeb系システムの構築で作成されてきたEJBコンポーネントを再利用できるように、ラッピングし、カプセル化してしまおうというものである。

（2）それらのコンポーネント群は、疎結合に構成される
従来のシステム構築デザイン手法では、どうしても関連するシステム間の相互接続性を緊密なものにする、という傾向があった。そのためシステム間のインターフェイス機能は、各システムの機能に基づく「固有のもの」となってしまう。このことが、企業のシステムを複雑にしてしまう。いわゆる社内システムの「スパゲティ・コード化」である。他システムとのインターフェイスを設定し、新たな機能を付け加えようとすると、さらに膨大な工数がかかるのである。コンポーネント群を「疎結合」に構成する、ということは、こうしたインターフェイスを簡潔にし、より柔軟性を持たすことが可能となる。もっとも構築されるシステム全体が、最初からそうした「思想」を持っていれば、ことさら声高にいうことではないのかもしれないが。

（3）Webサービスは、セマンティックに分離独立された機能をカプセル化したものである
ご存じのようにWebサービスは、オブジェクト指向デザインをベースにしているために、Webサービス自体は、Appletのような単一の機能を内包する。この機能をほかのソフトウェアから、そのコンポーネントに対して期待された機能に基づいて、インとアウトの情報を交換するのである。しかもWebサービスのセマンティックに分離独立された機能とは、従来のオブジェクト指向プログラミングにある「コンポーネント・ベース」という枠組みからはるかに逸脱した、もっと機能粒度の粗い、いうなれば、業務的機能に近い「サービス指向」の単位となることが期待されている。

（4）Webサービスは、プログラミング的にアクセスされる
Webシステムやデスクトップ・システムと異なり、Webサービスは、マン・マシン・インターフェイスとして設計されたものではない。従って、ヒトが操作するためのGraphical User Interfaceを用いない。むしろ、ほかのソフトウェアからデータを交換するために呼び出されるサブルーチンのようなものだといえる。この説明は、Webサービスの本質をわい小化するかもしれない。このことの本来的な意図は、あくまでインターネット上のヒトを介したマン・マシン・インターフェイス・システムとの連携をさらに簡潔・柔軟にするための機構にあるのだが……。

（5）Webサービスは、インターネットを介して、分散利用される
ここが重要である。（1）〜（4）の説明は、（5）のための前座にすぎないかもしれない。社内のシステム・サービス機能をカプセル化し、インターネット上で公開し、社外のシステムから簡単に利用できるようにするということ、これはインターネットによるユビキタス・コンピューティングの実現と、HTTPのようなすでに一般に普及したプロトコルによって、「いまだからこそできる」ことなのである。Webサービスは、分散コンピューティングやRPC（リモート・プロシージャー・コール）技術を応用している。これまでもCORBAやDCOMによって、社内システムでのオブジェクト指向アプローチによる機能集約は実現されていた。XMLによって、HTTPフレンドリなファイアウォールを乗り越えられる技術、SOAPやWSDL、UDDIといった技術の洗練化によって、すでにある技術とインターネット利用技術が集大成された。これがWebサービスの本質である。

■その期待されている役割

　以前、＠ITのあるフォーラムを読んでいたときに目に入ったのが次の疑問である。「Web系システム構築技法によって、せっかくシステムを集中処理型に集約できるようになったのに、いままたWebサービスによって分散処理に戻すのか？」

　かつて、メインフレームによる一極集中型システムから、分散クライアント／サーバ型システムになって、GUIによって、システムの表現力が大幅に向上し、利便性が増したが、一方でシステムが分散されているが故にメンテナンス性が恐ろしいまでに悪くなった。インターネットの普及によって、再びWebシステムによる集中管理型システムを経て、なぜいままた分散型のWebサービスに戻る必要があるのだろうか。

　Webサービスが、こうした問いに明確に答えきれているかどうか、筆者にはまだ分からない。昔のクライアント／サーバシステムは、サーバ上のデータベースの構造に変更があったような場合、クライアント側プログラムにも変更をきたし、結果、クライアント・プログラムの修正と各拠点への再頒布が必要というやっかいなものであった（ストアド・プロシージャで吸収するという方策もあるが）。Webサービスでもこれに似たようなことが起きないという保証があるのだろうか？ 分散環境上に特有な問題として、システムの独立性をどこまで保てるのだろうか。

　これに対する期待値として、XMLやSOAPがその答えになってくれているのではないだろうか？ 単に分散コンピューティング上で、プロプライエタリな技術に依拠したRPC技術をベースにしているだけであるならば、こうした問題はすぐに起きてしまう。Webサービスが、XMLやSOAPのような標準化メッセージ技術を核としている以上、各拠点内部の詳細な処理機構をカプセル化し、隠ぺいした後に、情報のやりとりは、メッセージを標準化した形で交換できるようにされているはずである。すなわち、これが正しければ、かつてのクライアント／サーバ型システムのメンテナンスビリティで起きた悪夢は起きないはずなのである。

　Webサービスの狙いは、はるかに先にある。社内外のシステムをユビキタス状に連携させ、これまで考えられたより、ずっと速く、簡潔・柔軟に、安価にシステム間連携とサービスのコミュニケーションを実現させようというものなのである。

■EAIなのかBtoBなのか

　では、視点を変えてみよう。社内システムの連携のためのソリューションとして、EAIがある。社外システムの連携のためのソリューションとして、BtoBがある（日本では、まだどちらもそれほど浸透していないかもしれない）。WebサービスはこのようなEAIやBtoBとどのように差別化できるのか。

（1）EAIとの違い
EAIが目的としているところとは、社内システムを連携させるための「共通基盤」を用意することである。社内のさまざまなシステムが、EAI製品として用意されたアダプタ群を通して、その「共通基盤」にプラグインされ、情報を連携させる。このことによって、社内システムのスパゲティ化を脱し、整然と整備することによって、IT資産を有効に利用できるようにしようというものである。このことの発想は極めて正しい。問題は、EAIツール自体が、ベンダ固有の技術でできているために、結局のところ、そのベンダ方式にロックインされてしまうということである。しかも製品価格は高価である。製品に100万ドル、導入にコンサルティングも含めて、500万ドルもかかるという例も少なくない。

　Webサービスでは、EAI的な使い方にも効果があるはずである。システム連携のための「共通基盤」をWebサービスによるラッピング技術でバス化して実現すればよい。また大規模な社内システムでは、社内UDDIを立てて、各サービス内容をディレクトリに登録しておけば、その有効利用性は増すであろう。Webサービスは、内部のコンポーネントが、SOAP、WSDLといった標準化技術で構成されているために、特定ベンダ技術にロックインさせる可能性も低い。これまでのIT資産を活用し、かつ必要に応じて、“Best of breed”な形でさまざまなベンダの提供する製品を利用してWebサービスを構築すればよい。このようにして、社内システムがプラグインできる形でビルディング・ブロック化され、安価にWebサービス化できるのである。

（2） BtoBとの違い
Webサービスの目的は、社内外システムを簡潔に連携させることにある。このことは、本来はBtoBシステムの役割であった。XML技術の台頭によって、旧来のEDIよりはるかに柔軟性を持つBtoBシステムが出現した。問題は、BtoBを導入しても、社内システムと結合する際に、やはりXMLからレガシーなデータ記述へ変換する必要があったし、社外の取引先と連携するためにも、同様のことがいえる。このインターフェイス部分にやはりベンダ固有の技術が入らなければならない。XML技術によって、情報や文書を華麗に交換できるBtoBシステムだが、肝心の社内および社外システム連携をどうするかが、その普及を押しとどめているといえよう。

　先に述べたように、社内システムが、Webサービス化によって、「サービス指向化され、プラグインできる機能群」として集約化されたらどうだろう。XMLをベースにしたSOAPメッセージは、HTTPによるファイアウォール・フレンドリなプロトコルに乗って、軽々と社外との連携を可能にするだろう。ここに至って、BtoBの本来の目的は、Webサービス技術の到来を経てようやく実現する。社内システムの「サービス指向」に基づいたより整然とした統合があって、BtoBは初めて現実性と抜本的な有効性を帯びるのである。

■WebサービスはEAIもBtoBも包含する！

　結局のところ、Webサービスは、EAIもBtoBも包含することになるだろう。IONA Technologiesでは、これを “Web Service Integration”といっている。EAIにも、BtoBにも、レガシー部分とのインターフェイスをどのように解決するかという部分に、Webサービス技術を適用していこうとすれば、それはもうWebサービスによるインテグレーションにほかならない。

図3　EAI、BtoBとWebサービスの関係 （出展： IONA Technologies）

　Webサービスによるインテグレーションについては、連載第四回目で詳しく述べたい。ここで連載の各回で触れるテーマについて紹介しておこう。

本連載コラムの予定 第1回　Webサービスは、本当にブレイクするか？　　　　　　 （今回） 第2回　Webサービスの事例と、今後の適応分野　　　　　　　（2002年3月） 第3回　Webサービスは、ビジネスの変革に役立つか　　　 　（2002年4月） 第4回　Webサービス・インテグレーションとそれがもたらすもの　　（2002年5月）

　ではまた次回。

筆者紹介

渡邊　純一（わたなべ　じゅんいち） 1957年生まれ、東京都出身。成蹊大学経済学部経済学科卒。CRC総研（現CRCソリューションズ）に入社。アーンスト＆ヤング コンサルティング（現キャップ ジェミニ アーンスト＆ヤング）を経て、2000年10月にシリコンバレーのBtoBベンダの1つであるNetfish Technologies Inc. リージョナル・ディレクター。2001年5月、IONA Technologies PLCのNetfish社買収に伴い、IONAへ移籍。現在、同社日本法人（日本アイオナテクノロジーズ株式会社）、パートナー・ストラテジー担当ディレクターとしてパートナ企業開拓に携わる。著書に「実践eコラボレーション」（共著）　同文舘 2001年10月がある。 メールアドレスは junichi.watanabe@iona.com

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