事例から探るWebサービスのビジネスモデル
2002年05月14日
日本アイ・ビー・エム ビジネス・イノベンション・サービス
 天野 富夫
1. はじめに

2000年にWebサービスという言葉が登場して以来,最近ではJavaやインターネット関係の雑誌にこの言葉が登場しないことはないほど普及するに至りました.もちろん,言葉だけではなくUDDI(Universal Description, Discovery and Integration)やWSDL(Web Services Description Language)などのWebサービス関連規格の整備が進み,Webサービス対応ミドルウェア製品やオープンソース実装も多数リリースされています.「Webサービスでシステム間を接続・連携させる」,「アプリケーションの部品としてWebサービスを使う」といったことが技術的に可能であることは既に実証されたといってよいでしょう.欧米の(最近では日本でも)Webサービス適用のさまざまな事例が報告されていることがこれを裏付けています.

先進的なユーザーによる利用という段階からもう一歩進めて,さらなるWebサービスの普及と発展のために必要なものは何でしょうか. ビジネス的な観点からWebサービス利用の動機づけをユーザーに与えるようなビジネスモデルだと筆者は考えます(本稿ではビジネスモデルを「利益を生み出すための仕掛けや方法」という意味で用いています).多くの企業がWebサービスの採用に踏み切るのは,技術的に可能であることに加えて「Webサービスを使って企業にどんな利益があるのか」,「その利益はWebサービスでなければ得られないのか」といった疑問に答えるビジネスモデルが明確になったときでしょう.

XMLコンソーシアムモデル部会のWebサービスワークグループではWebサービスの先進的な事例の情報を収集し何が利益を生み出す本質なのかを探る活動を行っています.本稿ではワークグループでの議論を元にして,事例から抽出したビジネスモデルのパターンを紹介しそれらの実現性について考察します.

2. Webサービスのビジネスモデル

現在のところどこかの機関が決めたWebサービスの正式な定義というものはありません.本稿では「ネットワーク(Web)を通して記述,公開,配置,および起動することのできるアプリケーションの部品」という意味でWebサービスという言葉を用いることにします.決められたフォーマットのメッセージをやり取りすることによりシステムやアプリケーション間の(いろんな意味で)緩やかな統合・連携を可能にする点がWebサービスの特徴の一つです.

Webサービスで前述の「記述,公開,配置,および起動」を行うためにSOAP(Simple Object Access Protocol)やWSDL,UDDIといった技術が使われます.現状ではこれら3つの技術のいずれかを用いているシステムやアプリケーションがWebサービスの事例ということになります.筆者らは雑誌やWebサイトなどの公開されている情報元からこのようなWebサービスの事例を収集していますが,これらの事例がビジネスモデルの観点−つまりどうやって利益を生み出しているのかという観点−から以下の3つのパターンに分類できるのではないかと考えました.

以下,これらのパターンごとに事例を紹介し利益創出の方法や留意点などについて考察を行います.

3. プロセス統合型モデル

プロセス統合とは別々の組織で行っている業務プロセスの一部または全体をWebサービスを用いて統合し連携させることをいいます(図1参照).統合・連携によって,重複していたプロセスの整理やプロセス間でのデータ交換の自動化が可能になります.いくつかプロセス統合型の事例を見てみることにしましょう.

図1 プロセス統合型Webサービスのパターンfig1

3-1 Storebrand社

Storebrand ASAはノルウェー最大の金融サービス会社であり顧客の銀行業務,資産管理,ならびに健康保険と生命保険の業務を行っています.Storebrand社が直面していた問題は顧客企業の年金計画に必要な情報の入力コストが膨大になることでした.Storebrand社側で年金計画の処理を行うためには,顧客企業の従業員一人一人の給与や住所を把握し昇進や退職による変化を更新していく必要があります.顧客企業のほとんどにおいてこれらの情報はコンピュータで管理されていますが,それらのシステムはStorebrand社のシステムとは連携していません.そのため給与等の情報を顧客側で紙に印刷して送りStorebrand側で再入力するといったことが行われていました.6500社,390000人に及ぶ従業員の情報の更新・管理のために50人の専任スタッフが必要でした.

Storebrand社はこの問題を解決するため自社の年金計画システムの入力部と顧客システムをWebサービスで直接接続することを考えました.Storebrand社内部の既存システムはIBMのMQシリーズのメッセージングプロトコルで従業員レコードの追加や変更を受けつけるものでしたがこのインタフェースをJavaで実装し,ツールを使ってWebサービスとしてインターネットから呼び出せるかたちに変換しました.Webサービスがやりとりするメッセージのフォーマットとしては業界団体が策定したXMLifeという標準フォーマットを用いました.同時に顧客企業の給与システムのパッケージソフト(Windows上で動作しています)を開発しているベンダーに対してこのXMLife形式でのデータ出力をサポートするように働きかけました.そして,出力されたXMLifeデータを入力としてStorebrand社のWebサービスを呼び出すCOMオブジェクトを開発し顧客企業に提供しました.これによって給与システム内のデータをStorebrand社内部のシステムに直接入力することが可能になりました(図2参照).XMLife出力をサポートする給与パッケージが増えていけば手作業を行っていたスタッフのコストが大幅に削減できると期待されています.

図2 Storebrand社と顧客企業におけるプロセス統合fig2

3-2 イギリス貿易産業省

Storebrand社の事例はある1社がWebサービスを提供し他社がそれを利用するという形態でした.逆に複数の会社が提供するWebサービスを1社が使用するという形態で利益が得られることもあります.イギリス貿易産業省DTI(Department of Trade and Industry)における取組もその一つです.

DTI(正確にはDTIで石油や天然ガスに関する規制や政策決定を行う機関)は石油および天然ガスの探索,免許,生産等に関する各種規制が確実に守られるよう,関係する多くの企業との間で頻繁にデータや文書の交換を行う必要がありました.交換される内容は環境データ,通常の生産活動に関する報告,資源探索活動や油田操業に関する情報などさまざまです.そしてこれらの情報の大部分が石油会社のデータベースに保管されているにもかかわらず,DTIへの報告は紙などのオフライン的な方法で行われており再入力のためのコストが発生していました.加えて,後で必要になったときのためにDTI側でも全データを保管するため,膨大な量のデータを管理するための人的・システム的なコストが発生していました.

上述のような問題は各石油会社が自社データベースへのアクセスをWebサービスとして公開することで解決できます.DTIは紙の報告を受け取る代わりに必要なときに各石油会社提供のWebサービスを呼び出して情報を取得すればよいのです.石油会社側に過去のデータがあり(政府に報告した内容は当然保管しておくでしょう),いつでも取得できるのであればDTI側でデータの保管を行う必要もなくなります.Webサービスによりデータ再入力とデータベースの維持・管理にかかっていたコストを削減することができるのです.

この事例のようにWebサービスの提供者が複数になると必要なWebサービスをどこから得られるのか,どのようなインタフェースでサービスを呼び出せばよいのか,といった事柄が必ずしも自明でなくなってきます.報告書を提供するWebサービスのURLやメールアドレスは石油会社側の理由で変更されるかもしれません.石油会社の買収・合併や新規参入により今までのURLが無効になったり,新たなURLが使用されることもあるでしょう.また,各石油会社は独自にデータベースを構築してきたわけですから,報告書の検索や取得のためのインタフェース(WSDL定義)もただ一つに統一することは難しいかもしれません.

Webサービスを呼び出すDTI側としてはUDDIレジストリを活用することでこのような「いつも決まった相手に決まった方法で問い合わせれば答えが得られるとは限らない」という状況に対処することができます.業界に参入し必要な報告をWebサービスで行う会社には自社のデータベースへアクセスするためのインタフェースをUDDIに登録することを義務づければよいのです.DTI側はまずUDDIを検索しデータベースアクセスに必要なURLやインタフェースの情報を取得し,その情報を利用して報告書の検索や取得を行うWebサービスを呼び出すわけです.

上記2つ以外にも多数のプロセス統合型のWebサービス事例が報告されています.これらの事例に共通していることは既存の機能やデータベースをWebサービスで利用可能にすることにより業務プロセスの大幅な効率化や適用範囲の拡大を達成している点です.得られる利益はコストの削減にとどまらず,Turn Around Timeの短縮や新規パートナーの獲得など多岐にわたっています.現状で最も実用化が進んでいるWebサービスの利用のしかたと言えます.

4. 機能提供型モデル

機能提供型のWebサービスとはベンダーがなんらかの機能をWebサービスで提供し,利用者側が対価を支払う形態(図3参照)をいいます.利用者は自身で使用するアプリケーションの開発者だったりアプリケーションやミドルウェアの開発ベンダーだったりします.利用者は自分で開発・保守することが困難であるような機能を利用でき提供ベンダーはソフトウェアのライブラリを売るようにWebサービスを売ることによって利益を得ることができます.

図3 機能提供型Webサービスのパターンfig3

4-1 PKIのWebサービス化

購買契約や在庫照会など企業間での情報のやりとりにあたっては,メッセージに電子署名をかけて改ざんや否認を防止することが必須の要件になります.XML署名のフォーマットの規格化は完了しましたが,実際に署名や検証の仕組みが機能するためには利用する側で認証局に公開カギを登録したり証明書の真正性を認証局に確認してもらったりという作業が必要になります.Verisign社やEntrust社といったPKI(Public Key Infrastructure)ソフトウェアのベンダーはこのような作業を行うためのライブラリを販売してきましたが,最近は必要な機能を呼び出すための規格(XKMS:XML Key Management Specification)を策定しWebサービスとして提供しようとしています.

実際にEvincible社はVerisign社提供のWebサービスを呼び出すことによって自社の販売するトランザクション管理用ミドルウェアに署名の添付や検証の機能を付加しました.Webサービスを利用することで全てを自社で行う場合に比較して短期間,低開発コストで新しい機能を追加することができたのです.

4-2 決済代行サービス

インターネット上で有料で商品やコンテンツを提供するECサイトにとって売買に伴う決済の機能は必要不可欠です.消費者の利便性という観点からはクレジットカードや宅配業者による代引きなどできるだけ多くの決済方法をサポートすることが望まれています.しかし決済方法や相手の違いごとにカード会社や宅配業者と契約し,接続のための仕様を決め,システムを変更するといった作業を行うのはECサイトにとっては大きな負担です.

KDDI社はこのようなECサイトのために複数の決済方法を利用可能にする決済代行サービスを行っています.ECサイトはKDDI1社と契約するだけて多様な決済方法を消費者に提供することができます.当初,ECサイトからの決済代行の依頼や応答は独自の接続方式で行われていましたが2001年9月からはSOAPを用いたメッセージ交換もサポートするようになりました.

機能提供型のWebサービスとしてはこの他に個人の認証情報(ユーザーIDとパスワードなど)やプロファイル(趣味や嗜好など)を管理していてインターネット商店などのWebサイトからの求めに応じて提供するサービスが注目されています.利用者側Webサイトは得られた情報に基づいて,サービスや情報へのアクセス制御やパーソナライゼーションを行うことができます.個人のプライバシーに関わる情報を個々のWebサイトが収集するのは困難ですしきちんと管理するためのコストも馬鹿になりません.この種の情報の収集・管理は専門の業者にまかせてサービスとして「買う」というのも自社の強みに傾注するための有力な選択肢になります.

5. 仲介型事例

Webサービスの提供者や利用者のために仲介を行い手数料収入を得るというモデルです.Webサービスの基本アーキテクチャには既にサービスの要求者と提供者に加えて仲介者(Broker)と呼ばれる実体が存在し(図4参照)UDDIがその役割を担うという説明がされたりしますが,実はIBM社やマイクロソフト社などが運営するPublic UDDIだけでは通常のビジネスで行われるような仲介の機能を実現することは困難です(例えば会社四季報に載っているような資本金〇〇万円以上といった条件で企業を絞りこむことはUDDIではできないのです).Public UDDIでは管理されていないさまざまな情報を補ってより付加価値の高い仲介機能を提供するビジネスが成立しうるし,また望まれています.Public UDDIの意義はこいった高付加価値仲介ビジネスが機能するための情報流通のインフラを提供する点にあります.WebサービスのPublish,Find,Bindの各段階において仲介ビジネスが考えられます.

図4 Webサービスアーキテクチャと仲介ビジネスfig4

5-1 WAND, Inc.

WAND社はインターネット上で売り手企業と買い手企業のマッチングを行うためのビジネスディレクトリを運営しています.製品やサービスの検索はブラウザから人間が行う形式が主流ですが,WAND社のディレクトリに登録している企業の情報をUDDIにも登録するサービスを行うと発表しました.登録している企業にとっては顧客がUDDI経由で自社の情報を発見してコンタクトしてくることが期待できます(Webサービスをサポートしていない企業でも電話やFAXなどの通常の連絡先をUDDIに登録することができます).Webサービスを提供している会社の場合,WANDの提供する検索機能(UDDIより機能が豊富です)によって顧客が自社を発見,選定した上でUDDIの情報に従ってWebサービスを起動してもらうという効果が期待できます.他社と差別化できるような特色や強みをもっている企業にとってはUDDIの比較的単純な分類体系ではなく,他との差異がわかるようなかたちで検索をかけてもらったほうが自社のWebサービスが選定される可能性が高くなるわけです.

5-2 Grand Central Networks, Inc

Grand Central Networks社はWebサービスの利用者と提供者の間の仲介に関わるビジネスを行っています.同社が介在することによってWebサービス利用者はメッセージのキューイング,暗号化などの恩恵を得ることができます.

同様に提供者と利用者の間に第三者が入ってWebサービスの計量・課金を行う仕組みが提案されています.前述の機能提供型のWebサービスビジネスモデルが成立するためにはWebサービスの計量・課金の仕組みは必須であり,この機能を提供することによって手数料収入を得るということも可能でしょう.

6. ビジネスモデルと事例に関する考察
6-1 Webサービス利用の必然性について

Webサービスの事例について議論していていしばしば問題となるのはWebサービスである必然性は何かという点です.「この事例がWebサービスで実現されていることはわかったが,それはWebサービスでなければできなかったのか?」,「〇〇でも同じことができるのではないか?」(〇〇のところはCORBAとかEAIとかいろいろです)という問いかけです.この問いにきちんと答えるためにはWebサービスで実現される業務の具体的内容にまでたちいる必要がありますが,一般的には次のようなことがいえると思います.

インターネットを介してシステムやアプリケーション間の連携を行う場合,Webサービス採用には既存IT投資の活用というメリットがあります.多くの企業ではインターネットでの情報交換用にWebサーバーやメールサーバーを運営しています.Webサービスで使用されるSOAPプロトコルではやりとりされるメッセージとトランスポート(データ通信層)が分離されていますからメッセージを既に利用可能なHTTPやSMTPなどのトランスポートに載せて送受信することができます.このことは単に導入済のサーバーソフトが利用できるというだけでなく,社外との通信に関わるセキュリティポリシーの決定やファイアウォール等を用いた実装,サーバーの保守・運用にかかるコスト,スキルを持った人材の育成等の投資をWebサービスでも利用できることを意味しています.

社外との連携用のメッセージ交換にインターネット標準以外のトランスポートプロトコルを使用することも技術的には可能ですが,上述のような投資の重複が発生しますし,相手企業が同じトランスポートをサポートしてくれる可能性はHTTPやSMTPと比べて極めて低くなってしまいます.機能提供型のビジネスモデルを実践するのであれば多くの人が参加してくれるような標準プロトコル-Webサービス-の採用は必然でしょう.

インターネット標準という以外にWebサービスが使われる理由は,Webサービスが他と接続することを意識しないで設計・開発されたアプリケーションやシステム間を連携に向いているという点です.Webサービス登場以前から,アプリケーションのフレームワークやミドルウェア製品は分散コンピューティングやアプリケーション間連携の仕組みをサポートしていました.「アプリケーションはこの提供クラスのサブクラスとして実装しなさい」とか「こういう順序で提供ライブラリの機能を呼び出しなさい」といったお作法に従えば同じお作法で作られたアプリケーションとは連携が可能です.しかし,部門間・企業間で使用しているフレームワークが異なるアプリケーションを連携させようとすると、両者の橋渡しとしてシステムに新たなコンポーネントを導入する、一方を他方のフレームワークに合わせて書き直す等の必要が生じます.たいていの場合,これらの作業のコストが連携のメリットを上回ってしまいます.前述のStorebrand社の事例ではWebサービスの提供側のロジックはメインフレーム上に実装されMQでデータ交換を行っていました.一方,利用者側のアプリケーションはWindows上で動きCOMで通信したりしていました.その他の例ではCOMとCORBAであったりします.双方が独立して開発された以上,連携対象システムが同一のフレームワークやミドルウェアの下で実現されていることはむしろ稀といえます.

Webサービスによる連携の基本は既存のアプリケーションになるべく変更を加えないかたちでWebサービスのインタフェースでラッピングし他者から呼び出せるようにするという点です.それぞれのアプリケーション固有のインタフェースをのりで貼り合せるようなイメージです(図5参照).Webサービスのインタフェースはプログラムに対するデータの入出力を単純にメッセージ交換で行っているだけですから,元のアプリケーションの作りかたに関わらず容易に実装することができます.実際,多くのSOAP実装では既存アプリケーションを変更なしでWebサービスとして登録することができます.

図5 Webサービスによる異なるフレームワーク間のアプリケーション連携fig5

アプリケーションやシステムの設計段階で接続・連携する相手のことを意識していなくても,必要が生じたときに容易に接続して動かすことができるということはは単に「分散環境で接続し機能が呼び出せる」という以上のものです.このような性質を非集中性といったりしますが,Webサービスの非集中性はプロセス統合を行う上で大きなメリットになります.大幅なアプリケーション書換えが必要であったシステム間連携を緩やかな結合により実現する,企業の合併や提携などビジネス的な理由で生じたシステム連携の要求に短期間で対応する,といったことが可能になります.

公平を期すためにWebサービスを採用していいことばかりではないことも述べておきましょう.前述の非集中性は単純で緩やかな結合故に実現されています.データを大きな単位でどんと渡して(SOAPではオブジェクトの参照渡しがサポートされていないことを思いだして下さい)答えをもらう,といったかたちです.アプリケーション連携によって実現される業務が比較的細かな単位のデータを何度もやりとりすることによって処理されるような場合,Webサービスではパフォーマンス面で要件を満たせない(HTTPもXMLも効率という面からみると最適な選択ではありません)可能性があります.

6-2 アプリケーションデータの標準化について

SOAPはWebサービスにおけるメッセージ交換の基本規格ですが,これが定めているのはさまざまなデータを包み込む封筒の部分です.その中に記述されるアプリケーションデータのフォーマットは業務ごと機能ごとに定めておく必要があります.そのため「特定企業のWebサービスを利用することでその会社のフォーマットの世界に取り込まれてしまわないか?」とか「Webサービスは業界標準のデータフォーマットが決まっていないと使えないのか?」等の疑問が生じます.

まずWebサービスにおけるアプリケーションデータフォーマットの決め方には以下のような2種類のアプローチがあります.

既存のアプリケーションを他からも使えるようにして業務を効率化しようという考え方が根底にある場合,プログラムのAPIをベースにしたほうが開発は容易です.APIをSOAP-RPCのエンコーディング方式にマッピングすることにより機械的にデータフォーマットを決めてWebサービスとして登録することができます.プログラムのコードから自動的にWSDL記述を生成してくれるツールもあります.

業界標準等への準拠が要件に入っている場合,採用する標準フォーマットを決めてからそれに合わせて既存アプリケーションの変更や作成を行います.適当な標準フォーマットが無い場合,業界団体等で策定しなければなりませんがこの作業には相応の手間と時間がかかります.

プロセス統合型の事例において企業内/グループ企業内でアプリケーションを連携させる場合,フォーマットの標準化の必要はありませんから既存APIをベースにしてWebサービス化を行えます.ただし、企業内に同じ種類のWebサービスを提供する複数の部門があった場合,業界標準ではないにしろ統一されたフォーマットを決める必要があるでしょう.逆に多くの部門が関連していて統一が困難という場合には複数フォーマットの存在を許容して社内UDDIで管理するというのも選択肢です.

プロセス統合の相手が中立的な第三者や顧客である場合や機能提供型のビジネスモデルを志向する場合は業界標準フォーマット準拠の必要性が増してきます.利用者側は独自フォーマットの世界に囲い込まれることを好まないからです.ただし,標準が決まっていない場合に利用者が「割り切り」をもって独自フォーマットのサービスを採用することも可能です.何年か先に標準が決まるまで独自フォーマットのWebサービスを利用して得られるメリットと標準が決まった時点でのシステム変更のコストをはかりにかけて判断するわけです.Webサービスのやりとりは疎結合が基本ですから変更が必要になる個所はメッセージの入出力部分に局在化できます.標準フォーマットの内容が独自フォーマットのスーパーセットになっていれば独自フォーマットからの移行は比較的容易です.

既存プログラムのAPI利用と標準フォーマットへの対応という相反する要件をうまく満たしている事例もあります.Storebrand社は顧客企業(正確には顧客企業の給与システムを開発しているソフトウェアベンダー)が取り扱うフォーマットとしては業界標準であるXMLifeを採用しました.一方でStorebrand側のサーバープログラムはJavaプログラムのAPIをツールで変換するという手間のかからない方法でWebサービス化しています.両者を連携させるためにXMLifeデータを読込んでSOAPのRPC呼び出しを行うCOMオブジェクトを顧客企業に提供しています.このようにしてサービス提供側では簡便な実装を行いつつ利用者は標準フォーマットでWebサービスを呼び出すことが可能になっています.

7. まとめ

本稿では実際の事例からWebサービスのビジネスモデルのパターンを抽出し分析することを試みました.

プロセス統合型ビジネスモデルは技術的ハードルも比較的低く,実施例も多く見受けられます.ただし,業務プロセスのどこを統合してどんな利益(○○の作業を一つにまとめるとか,自動化するとか)を生み出すのかを明確にしておくことがWebサービス適用の前提条件です.これがないと「Webサービスでシステムは動いてはいるけれどいったい何がメリットなのかわからない」といった事態が生じます.ビジネス的な観点から目的を明確にした上で,トランザクションの粒度や性質(例えば更新系か参照系か,ライフタイムが長いか短いかなど),標準フォーマットの必要性,等を考慮していけば成功するシナリオを導きだすことができると思います.

機能提供型ビジネスモデルはWebサービスの計量・課金の仕組みが技術面および運用面で確立されれば本格的な普及が期待されます.「どんな機能を外に頼むのか?」というビジネスニーズの問題はありますが,顧客の認証情報やプロファイル情報といった収集・管理に手間のかかる情報をWebサービスで取り寄せるというのが一つの候補です.サービスの品質保証の問題が解決すれば,在庫管理や販売管理といった企業活動に必須な業務をアウトソースすることも可能になるでしょう.

仲介型ビジネスモデルは上記2つのビジネスモデルが普及し世の中にさまざまなWebサービスが流通するようになったときにその意義が認知されるでしょう.Webサービスの発見一つをとってみても,現在は同じ機能を提供するWebサービスが品質や価格で競争を繰り広げるという状況にはいたっていません.Webサービスの市場が活性化するにつれてサービスの内容に即した検索の重要性が増してくるはずです.

Webサービスに関連してはさまざまな仕様や技術が存在し,今後も新しい魅力的なアイデアが生まれてくることでしょう.ユーザー企業にとっては今Webサービスでできるシナリオと得られる利益,将来的にWebサービスによって実現されるシナリオ,Webサービスには向かない事柄,等を見極めつつ(Webサービスの採否を含む)自社のIT戦略を建てる必要があります.そのために本稿の内容が多少とも役立てば幸いです.


参考文献
[1] Storebrnd事例 http://www-6.ibm.com/jp/developerworks/webservices/020111/j_ws-asa.html
[2] DTI事例 http://www-3.ibm.com/software/solutions/webservices/casestudies/dti.html
[3] PKIWebサービス事例 http://www.xmltrustcenter.org/xkms/cases/evincible.htm
[4] KDDI社事例 日経インターネットテクノロジー2001年11月号
[5] WAND社Webサイト http://www.wand.com/
[6] Grand Central事例 http://www-3.ibm.com/software/solutions/webservices/casestudies/grandcentral.html
[7] Webサービスの計量・課金 http://www-6.ibm.com/jp/developerworks/webservices/020222/j_ws-wsht.html