オピニオン：いまなぜWebサービスか？
第2回　Webサービスの事例と、今後の適応分野

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

　今回は、Webサービスの事例と今後の動向について話を進めてみよう。

■百貨店A社の事例

　私が目にした、ある百貨店の事例を最初に紹介する。Webサービスの導入に成功した例として、ぜひ目を通してほしい。

リアル店舗とオンライン・ショップを持つ、百貨店A社
　百貨店A社は、全米のうち24州、また欧州にも20もの店舗を展開している、有名ファッションブランド・ブテｨックを中心とした百貨店である。同社は既存店舗の展開に加え、新たなセールス・チャネル開拓を目的としてドットコム関連会社を設立し、オンライン・ショップを開設している。ここでは、靴のように一般には店舗に行って試着してみなければならないような商品の取り扱いもしており、リアル店舗とバーチャル店舗（オンライン・ショップのWebサイト）の組合せを利点としてうまく生かしている。また同社のオンライン・ショップは、商品の品切れの対応で顧客本位のサービスを行っているサイトである。徹底した顧客満足の実現を目標とし、優れたカスタマー・サービスの提供を重点項目においている企業として知られている。同社の問題解決プロセスは下記のようなものだった。

受発注プロセスの短縮が、A社の課題
　同社がオンライン・ショップ構築のためにXMLをベースとしたテクノロジの採用を検討したのは、短期的には同社の取引先との受発注プロセスで発生する（データの入力処理などの）コストや、ターンアラウンドをできるだけ縮小していくことを目的としたためである。しかし、最終目標としては、他社とは違った、優位性のある顧客サービスを実現するためにオンライン・サービスの機能を向上させようと考えていた。例えば、顧客の注文した商品が品切れであった場合の対応を改善するという場合がある。既存店舗や倉庫に商品がなくても、仕入先から顧客に直送させるということを、オンライン・ショップ上の機能で処理させようとした。またオンライン・ショップを利用している顧客からの注文確認処理を大幅に改善させる（それまではオンライン注文の確認を顧客に返すまでに1.5日を要したが、できれば30分以内）という目標を掲げた。

BtoB製品の導入が、A社のソリューション
　A社のeビジネス事業責任者は、同社のオンライン・ショップに新しいアーキテクチャを構築することを考えていた。最大の懸案事項としては、これまでのメインフレームを中心とするバッチ処理スタイルから、XMLを中心とする動的な取引先との処理を検討していたのである。これまでのEDIやVANによる一括処理型のスタイルでは、専用線やVANのコストは高い。こうしたトランザクションをインターネットに変えることによって通信コストを削減できる。またXMLベースのソリューションを導入することによって取引先との業務処理がより緊密になり、在庫情報やオンラインでの受発注処理がより連携されることを期待していたのである。このような期待のもと、A社はBtoB製品を採用した。いままでのバッチ処理形式やFTPベースの受発注処理をリアルタイムに変えるため、XMLとJavaをベースとしたBtoB製品の導入が、短期間でのシステムの再構築にふさわしいと考えたからである。

ERPとBtoBの部分的な置き換えを開始
　BtoB製品導入の第1段階では、A社は、同社のERPシステムと、同社とEDIで結ばれている49社の靴サプライヤとの間の業務連携をさらに進めた。従来のEDIの処理は、発注、発注受け、事前出荷通知、受注ステータス・レポート、価格およびセールス・カタログ更新のプロセスを行っていた。しかしBtoB製品の導入に当たっては、上記処理プロセスの分析を行い、カスタム・タスクなどを作成、その後2週間の導入テストを実施した。テスト終了後、6社の主要靴メーカーと4つのEDIドキュメントの処理を本番のBtoB製品での処理へ移行させた。その後さらに2週間で新たに6社の取引先との処理を開始し、さらにその2カ月後、残る靴取引先メーカーすべてのEDI処理を新システムへ移行させた。

　導入の第2段階では、A社はWebサービスの展開を考えた。同社では、社内のERPによる在庫管理など各種業務システムと顧客からの注文処理を連携させる手段として、メッセージ・ブローカー製品を使ってシステム統合を行っていこうとしていた。その方法は、短期的には十分に目的に合ったし、また現実的な方法だったからである。しかし、A社は今後のソリューションとして、オープンで標準化された技術であるWebサービスを採用した。

　Webサービスの採用の第一段階として、A社は、顧客からの注文処理と在庫確認の連携を進めた。Webサービス技術を使って、まったく異なるほかの社内システムから在庫状態、出荷日の状況を抽出するなど、クリティカル情報の抽出処理部分の業務に応用している。

　続いて同社は、オンライン・ショップ上でのギフトカードを使ったショッピング部分で、関連会社との決済システムと連携させるため、Webサービスを取り入れた。これは2001年夏に開発が進められ、クリスマス商戦までのわずか3カ月で開発を成功させている。近い将来、さまざまな社外取引先がWebサービスの標準に基づいたサービスの提供を開始した場合でも、社外サービスをプラグ&プレイの形で取り込んで、同社のシステムと連携させることを期待している。

BtoBサーバとWebサービスの導入で、発注プロセスの短縮や、オンライン・ショップのレスポンス改善が実現できた

発注プロセスの大幅な短縮、オンライン・ショップのレスポンス改善
　効果の1つ目は当初の期待どおり、取引先との発注処理プロセス時間の大幅な短縮である。新システムの導入以前では、取引先より送られてきた事前出荷情報を自社のERPシステムに手作業で入力しなければならなかった。新システムでは、取引先からの出荷情報は自動的に処理され、変換されて自社ERPシステムに蓄積される。さらにこのようなシステムの連携によって、取引先の在庫情報についても、リアルタイムに交換できるようになった。注文受け処理、出荷通知、カタログ情報の更新についても、逐一、リアルタイムに取引先より送信され自動的に変換されて社内システムに到達するようになったのである。

　こうした処理の一部分は従来のEDIでも行われていた。これがインターネット通信に置き換えられ、その結果得られた通信コストの削減も大きい。

　2つ目の効果は、オンライン・ショップ上でのレスポンスの改善である。従来、顧客がオンライン・ショップで注文した後、A社がその注文確認を顧客へ返すまでに1.5日も要していたが、それが20分にまで短縮された。今日、注文は顧客から入力された段階で、即座に注文対応処理まで自動的にキックされるようになっている。バッチ処理などで注文確認処理が滞留することはない。

　3つ目の効果は、Webサービス技術の適用により、たった3カ月で、在庫照会、ギフトカード取り扱い部分の決済確認のインターフェイス・システムを構築することができた点である。これは、既存のシステムを有効利用し、Webサービス技術によるラッピング機能を最大限に生かせたことが、一番の要因であろう。

■Webサービスの適応分野

　「Webサービスは、何やらよさそうなモノらしいが、じゃあ一体どうやって使うんだい」。読者の中にも、会社の上司からそのように聞かれたことはないだろうか？ 今日、Webサービスを使ったシステムの事例は少しずつ出てきているものの、その全貌は、まだ見えていない。そこで、Webサービスを使って、どのような適用例が考えられるのか、以下に整理しておきたい。

　Webサービスは、以下のようなさまざまなアプリケーションに適用される。

（1）データ供給サービス：株価情報の検索や金融ポータルといった、単純、単一ないし複合的な情報ソースの供給アプリケーション
（2）会員向け情報通知サービス：携帯電話やPDA、そのほかモバイル機器に対する接続サービスと情報通知
（3）複合的な業務処理機能：顧客や取引先とのアドホックな相互取引
（4）BtoBコラボレーション：取引先との標準化ビジネス・プロトコル・ベース、かつ複合的な業務コラボレーション（先に挙げた事例はこれである）
（5）EAI：企業内部での業務処理システム統合

　それぞれをもう少し詳しく紹介しよう。

　（1）データ供給サービスの事例として、すでに実際に稼働しているWebサービスの例を見ることできる。ただ現時点では、こうした事例は、「価格の引き合い」のようなデータ提供型アプリケーションに対する単純な「リクエスト／リプライ」形式の機能を提供しているにすぎない。有名な事例として、ネット競売最大手のeBayがある。ここでは、競売に出される商品アイテムを提供するとともに、Webサービス・インターフェイスを介した入札機能を提供している。　また、緯度や経度の情報を入力すると、地図情報を表示するというのもそれである。ただ、見た目上はWebサイトのGUIを通しているだけに、「これがWebサービス！」というハデさはない。しかしこの分野は技術も単純だし、いまあるWebサービス構築技術で実現できるので、今後日増しに増えるのではないだろうか。

　具体例として、社員の交通費や出張精算の業務を行うことを考えてみよう。パソコン上で、実際の旅程として通った路線情報を入力すれば、その情報を基に、その路線の乗車料金をWebサービスとして公開されているサイトにリクエストし、結果料金情報だけパソコンに返してくるというものである。路線情報は、いまでも各種ポータル・サイトで実現されているが、社員は、いちいち関連Webサイトを見にいって、料金内容を確認・転記する必要はないだろう。さらに、これが進んで、旅行代理店などが、出張予約（特急券や航空券、宿泊場所の手配）などを、Webサービス化して提供するのではないかと筆者は見ている。

　（2）会員向け情報通知サービスも（1）と同様、今後増えてくるとみている。Webサービスの対象がパソコンではなく、携帯電話やPDA、他モバイル機器に移るのである。この場合、旅費や出張精算、業務報告、さらにはスケジュール情報の共有などの機能がWebサービス的インターフェイスを持つであろう。利点は、（1）と同様、WebサイトのURLを指定して見にいくのではなくて、所要情報だけ指定すれば、エージェント的役割を担った携帯電話やPDA上のSOAPクライアントが、Webサービスを経由してその情報をリクエストし、結果を得て戻ってくるというものである。これは、広く一般顧客向けサービスも考えられるが、個々の企業でも、外回りをする営業系社員にこうした携帯電話やPDA機器を持たせて、会社と情報のやりとりを行うという使い方もあるだろう。

サーバからクライアントまで、Webサービスによって連係していくことで、さまざまなアプリケーションが実現されるだろう

　（3）複合的な業務処理機能は、（2）よりさらに一歩進んだ段階となる。企業間の価格の引き合いだけでなく、製品のカタログ情報、在庫情報の照会など、情報のリクエストの内容がさらに厚くなる。メール・システムとの連携も考えられるかもしれない。こうしたことは、現在のWebシステムでも十分に実現されていることだが、Webサービスの場合は、「リクエスト／リプライ」の処理をエージェント的技術で実現させるところが売りである。「リクエスト／リプライ」の操作にマン・マシン・インターフェイスを必要としないのである。

　また一方、“IPv6”が今後浸透していった場合には、会社内のプリンタや情報機器、家庭内のさまざまな家電や車載機器にIPアドレスが割り当てられ、ISDNやブロードバンド、携帯ネットワークを通して、マン・マシン・インターフェイスを介すことなく、さまざまな情報がやりとりされる。この結果は、毎日、会社や家庭内のパソコンやPDAを立ち上げると必要なものだけが通知されてくるだろう。在庫の補充をどうしましょうかとか、契約の更新時期ですよとか、プリンタのトナーが残り少ないとか、ウィンドウ・ウォッシャー液が残り少ないとか、オイルの交換時期だとか、エアコンのフィルタの交換時期だとか……（少々、というか、かなりやかましいかもしれませんね）。

　（4）BtoBコラボレーションについても、Webサービス型アプリケーションは、（1）や（2）程度の初歩的な段階の機能を、すぐに追い越すことになるはずである。BtoBコラボレーションはまさにその先にある領域である。これは、現在すでにXML技術を駆使して発表されている各種BtoBサーバ製品の発展型と見ればよい。（2）で挙げた、製品情報、在庫情報の照会に加えて、企業間の発注、受注、受注確認、出荷、在庫引き落とし、配送、入荷、請求という一連のサプライチェーンやCPFR（Collaborative Planning, Forecasting and Replenishment）の処理について、これを使って行なうようになる。これだけの一連の処理に、XMLやSOAPが使われるのだが、このためには、会社間ではなく、産業界全般が支持した、いわゆる「共通のビジネス・プロトコル」の普及がかなめとなる。RosettaNetやebXMLがそれに当たる。

　これまでのBtoB製品では、BtoBサーバ部分と、取引先に設置するXMLクライアント（コネクタないし、アダプタ製品）があり、その2つの拠点間をXMLで通信し、それぞれのバックエンドのシステムとの間では、XMLを通常のレガシーなプロトコルに変換するインターフェイスを持つ必要があった。RosettaNetやebXMLのような、より高レベルのビジネス標準をベースにしたBtoBアプリケーションは、より柔軟なインターフェイス機能を提供していくために、Webサービス機能を取り入れるはずである。

　またSAPやOracleといった主要なERPアプリケーション・ベンダも、ネイティブなWebサービス・インターフェイスを自社エンタープライズ・システムに組み込んでいくことをアナウンスしている。こうしたことはすべて、Webサービスによってインターネット上で業務処理機能を公開し、企業間の業務統合に向けたソリューションとして効果的に使うことができるということが、各ベンダで幅広く認識されていることを物語っている。

既存のアプリケーションやデータフォーマットを結びつけることができるようになるWebサービスエンジンが登場するだろう

　さて、ここでUDDIが加わるとどうなるだろう。UDDI（Universal Description, Discovery, and Integration）標準に従ったリポジトリは、公開されたWebサービスの記述に対するアクセス・ルートを提供する。（Webサービスを利用しようとする）クライアントは、そのリポジトリを検索して、必要とする適当なサービスを発見することになる。特定のサービスを検索するためのリクエストは、すでにサービスの名前なり、相手先が分かっていて、その名称を探す「一般の電話帳」方式を用いるか、あるいは、サービスの名前は分からないけれども、利用したいサービスのカテゴリが分かっている場合、「タウンページ」方式で検索を行う、という形になる。

　サービスの発見のために使用されるアクセスのタイプは、アプリケーションによって異なる。BtoBの場合の取引先は、既知の取引先（すでに取引基本契約を結んでいる）とのサービス交換を行うので、主に「一般の電話帳」方式を使用することになるだろう。「タウンページ」方式は、株価情報の閲覧とか、為替レートの情報の検索といった、広義に利用される情報検索のような一般顧客指向のサービスとして、より一般化されるであろう。

　BtoBコラボレーションでは、既知の取引先との協調処理を行うのであるから、BtoBシステムの内部に取引先に関する情報を格納しておけばよく、UDDIは不要であると考えられる。しかしUDDIによる動的なサービス提供機能によって、取引先との閉じている、定められたトランザクション処理とオープンで情報検索的な処理を組み合わせる可能性もあるかもしれない。

　（5）EAIについてはすでに連載第1回「Webサービスは、本当にブレイクするか？」で述べたように、Webサービスの技術を使って、社内の業務処理システム統合を進めるケースである。標準化ベースの技術であるWSDL、SOAP、XML技術を使っているので、固有ベンダの技術にロックインされないし、安価に構築できるということ。すでに社内に蓄積されているIT資産を有効利用するということで、注目株の領域であることは述べたとおりである。Webサービス・ベースのインテグレーションのケース・スタディが今後増えていくことがカギである。

　同じ1つのWebサービス技術によって、企業の外部・内部において、単純であったり、複雑であったりするさまざまな側面を取り扱うことができる。また、幅広い問題領域に対して、同じテクノロジを適用することによってこそ、ソフトウェアのインフラを購入したり、展開したり、運用したりするコストの低減化を実現することができるのである。こうした部分にフォーカスして、第3回目では、Webサービスは、ビジネスの変革に役立つかを提言したい。

　ではまた次回。

本連載コラムの予定 第1回　Webサービスは、本当にブレイクするか？　　　　　　（2002年2月） 第2回　Webサービスの事例と今後考えられる適応分野　　（今回） 第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メールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）