お使いのブラウザは最新版ではありません。最新のブラウザでご覧ください。

CNET Japan ブログ

Webサービスのリアリティ

2004/01/26 02:11
  • このエントリーをはてなブックマークに追加

今回は、CNETに掲載された記事への批判という形式をきっかけにエントリーをしてみる。ターゲットは、IBMでDirector of Web Servicesという役職にあるBob Sutor氏の記事だ。

CNET Japan : Webサービスの「ウィッシュリスト」

この記事の中では、2004年に望まれる4つの「ウィッシュリスト」が挙げられている。

1)WS-IのWebサービス標準「Basic Profile」が普及する
2)業務を効率化するためにWebサービスを利用する企業が増える
3)Webサービスの用途が広がる
4)M&A

2004年にもなって、しかもWebサービスの大御所たるIBMのWebサービス担当の御仁が、未だにこのような浅いレベルの議論を行っていることに正直言って驚いた。

■「サービス」を理解せずしてWebサービスは語れない

まず1番目のBasic Profileが普及する、というもの。これはいい。相互運用性についての詳細が定まっていくことは何であれ、喜ばしいことである。

2番目に挙げられているのが、業務効率化のためにWebサービスが利用されるようになる、という視点。Webサービスの主たるアプリケーションがサプライチェーン統合の分野であるということも、彼らの期待が込められているという点では異議はない。(しかし後に述べるように、これは戦略的には誤った考え方である)

しかし、サプライチェーン統合というゴールに対して、Webサービスがどのぐらい役に立つかと言えば、「私の会社では、競争力のあるいい車を作りたい」という顧客に対して「それならお客様、我々が提供するこの画期的なボルトとナットが何よりも素晴らしい役割を果たすでしょう」というトンチンカンな会話をするセールスマンの会話に似ている。ボルトやナット(インターフェース)は車(アプリケーション)を作るための構成要素のひとつではあるが、エンジンやブレーキなどのキーパーツ(コンポーネントまたはサービス)よりも重要なんてことはない。

また、Webサービスの課題としてシステム負荷やセキュリティについて言及しているが、これも同じような理由により議論のポイントがズレている。競争力のある車を作りたいユーザにとって、ネジ単体の強度について議論してる時間なんて無駄以外の何物でもない。そもそも、例えばシャーシがアルミの軽量なスポーツカーを作りたいのだったら、ネジを重厚で頑強な素材にするのは目的に合わない。ネジ屋がネジの強度について深く研究するのは結構なことだが、それは車を作るメーカーから見れば枝葉末節でしかない。

3番目の点については、もはやシングルベンダーでシステムは作れないのだからWebサービスでSOA(サービス指向アーキテクチャ)を実現しようというものだが、これまたSOAなどというバズワード(専門用語めいた無意味な流行語)に踊らされたひどいコメントである。

ここでいうサービスとは何を意味する言葉だろうか?ソフトウェア技術の文脈で語られる狭義のサービスとは、リクエストを受けて仕事をして必要に応じてレスポンスを返す「常駐化されたプロセス」に過ぎない。SOAでいうところのサービスは、そのスコープよりも広い概念(例えばソフトウェアの概念の外にあるもの)なのだろうか?

さらに、「サービス(もしくはコンポーネント)が隠蔽化可能である」という幻想が定着してしまったことが、この問題を一層複雑にしている。オブジェクト指向のプロパガンダにより、オブジェクトはまるでプログラムのサブルーチンのように隠蔽化可能であるという信仰が広がっている。しかし、それは木を見て森を見ない人間の短絡的な思考回路を形にしただけで、俯瞰的に観れば存在している異なるオブジェクト間の相互依存性やオブジェクト自身のふるまいの不確かさといった別の視点における法則性には目をつぶろうというのに等しい。

繰り返し使うプログラミングのロジックを単に部品化しただけのサブルーチン(ちょっと難しい言い方で言うと、与えられた入力に対してプログラミング言語という形式論理言語の厳密な演繹だけから構成される、外部との相互作用を伴わない系)にふるまいの不確定性は存在しないが、オブジェクトという粒度になるとその内部では必ずしも内部的なロジックの積み上げだけとは限らない。そのオブジェクトが呼び出し元からの入力以外に外部からのデータを読み込んだり、または人間からの入力を受け付けて何かを行う場合、そのオブジェクトのふるまいに不確定性が生まれる。(完全に余談だが、ここでいう不確定性は「呼び出し元」という観測者にとっての不確定性であって、システム全体を俯瞰して見た場合には不確定性が相殺され、統計的な法則性を示すことがままある。このあたりはハインゼンベルグの不確定性原理がニュートンの古典力学などが扱う中視系以上では無視できることに若干の類似性が見出せる)

一般に、前者のようなサブルーチンは付加価値を生むことを目的としていない。指示を受けたら自分の殻に閉じこもり、言われたことを言われた通りにこなすだけである。一方でオブジェクトやサービスに期待されるものは付加価値を生む、つまりプラスアルファの何かを生み出すことであるならば、それはオブジェクトの外の世界とのインタラクションを伴うものである。そうなった途端、全体としてのふるまいは(もちろん程度の差は大きいが)複雑系に変容する。そして外の世界との間に「隠れた相互依存性」がある限り、サービス自体が統合されたり、分割されたりといった「オブジェクト境界の変化」も常に生じる可能性を含んでいる。

つまり、「サービスは隠蔽可能」と一般化することは、それ自体が自己矛盾なのである。このような不確定性を持つサービスの組み合わせがアーキテクチャ基盤の骨格になるという考え方は、トンデモない話である。

そして最後の4番目に述べられているのは、大規模なM&Aにおけるシステム統合がWebサービスのおかげでスムーズにいったという事例を望んでいる、というような話である(ちょっと原文と翻訳でニュアンスが違っている)。この件に及んでは、2004年に起きる現実性はゼロであるということを断言しよう。インターフェース先行でシステムを考えるということ自体は将来性のあるアプローチであるが、それはインターフェースの構成要素であるシンタックス(入れ物、SOAPなど)とセマンティクス(メタデータ)のうち、セマンティクスについての話である。シンタックスに過ぎないWebサービスのおかげでどうのこうの、という話ではない。

■インターフェースとアダプター

先の例でも挙げたが、Webサービスの本質は、平たく言えば「標準化されたボルトとナット」である。様々なものを繋ぎ合わせる接着剤としてのインターフェース技術の一種である。

例えば電力を供給するコンセントの形状は国内では完全に統一されており、あらゆる国産の電化製品で電源コードを簡単に接続して電力を得ることができる。電源コードは見かけ上、壁のコンセントに簡単にプラグインできてアダプターは不要である。しかし、目には見えにくいが、電力会社から供給される標準化された電圧(家庭用では100V)や電流(家庭では20A程度)および交流の周波数(東日本が50Hz、西日本が60Hz)を、電化製品が要求する電力、および必要に応じて交流から直流に変換することなどが必要となる。このような変換を行うアダプターは、電源アダプターのような形状として見えていることもあれば、電化製品の内部に埋め込まれていることもある。

このアナロジーで言えば、目に見えるコンセントの形状はインターフェースのうちシンタックスの部分である。これが合っていないとそもそも絶対に繋がらないという意味で、シンタックスの標準化は必須条件である。そういう意味で、WebサービスによってSOAPやXMLといったエンコーディング規則が定められたことは、一定の意義がある。

さらに、電源アダプターなしで電化製品をコンセントに繋ぐと火を噴いたり壊れたり挙動がおかしくなるように、電力や周波数といったものが正しく変換されなければ、コンポーネントは役に立たないのである。この目に見えない変換を行う電源アダプターは(例えとしては物足りないが)セマンティクスの翻訳を行っている部分にやや近い。

しかし、このハードウェア世界におけるインターフェースのアナロジーが物足りないのは、目に見えないメタデータのようなものを説明するうまい例がないことである。ハードウェアのアナロジーを用いると、上記例のように電力や周波数といった目に見えないものでも必ず完全に変換可能であるかのような印象を与えてしまう。しかし、セマンティクスの場合にはそうはいかない。粒度が異なるものに無理矢理マッピングしなければならなかったり、そもそも翻訳できない概念であったりと、とにかくソフトウェアの場合にはインターフェースを媒介するたびに何がしかの品質劣化(情報量の欠落)が起きる。これが、サービスの粒度を適切に下げることが難しい最大の難関なのである。

■イノベーションのジレンマとWebサービス

さて、次は経営学の観点からWebサービスを捉えてみよう。

ご存知のとおり、WebサービスはマイクロソフトやIBMといったIT業界のトッププレイヤーたちによってここ数年かけて強力に推進されている技術である。そして、彼らにとってのWebサービスの戦略的扱いは「前面にアピールする」であり、主流ビジネスをドライブするものと位置づけられている。

この判断は、「イノベーションへの解」でクリステンセン教授が定義した理論に照らせば、間違っていると言ってよい。

Webサービスは、その生い立ちから言っても、その特徴から言っても、本質的には破壊的イノベーションである。技術的には特に画期的なものではなく今までにあった技術の組み合わせであり、簡単・お手軽・ポータブルで、オモチャのような代物である。サプライチェーンシステムに使えると言われても片腹痛いのはそのためであるが、年間で何兆もの売上を誇るIT企業の成長を支える柱として期待するならば、相応の規模のある市場に無理矢理にでも投入しようと躍起になる。ここにミスマッチがある。

しかし、「イノベーションへの解」で述べられているように、あるテクノロジーが破壊性を帯びるかどうかは市場定義などの戦略とのパッケージングによるところが大きい。破壊的イノベーションはローエンド戦略と新市場戦略に大別され、少なくとも大企業の主流ビジネスとは相容れない。巨大な規模を誇る企業の成長需要(例えば、年間500億円規模の売上に貢献する)を満足するようなものではないのだ。

例えば、RSSのような配信型の亜流Webサービスは新市場型戦略に位置づけられる。また、GoogleやAmazonが提供しているWebサービスのインターフェースは、これまでならHTTPとHTMLを直接ハンドリングする独自のノウハウが込められたリッチなクライアントを必要としていたものが標準的なインターフェースの皮一枚で簡単に行えるようになるという観点で、ローエンド戦略の一種である。いずれも市場としては極めて小さく(それどころか、ほとんどの場合にはフリーソフトが支配しており市場として成立さえしていない)、大手ベンダーの経営陣は簡単にこれらの市場を「無視する」という判断を下すだろう(実際、そうしている)。しかしこういった市場は、いずれ将来にはサプライチェーンにおけるEDI市場などのハイエンド市場を侵食するイノベーションを育てる、潜在的なインキュベーションステージなのである。

恐らく何年も前に「イノベーションのジレンマ」を読んだであろうMBAホルダーを多数抱える大手IT企業の戦略家たちも、やはり過去に繰り返されてきた同じ過ちをここでも繰り返しているようだ。彼等は恐らく、この本を読んではいるが内容をきちんと消化できていないか、またはこの理論は熟知しているがWebサービスが破壊的イノベーションだとは考えたこともなかったかのどちらかなのだろう。

Webサービスのプロトコルスタック標準化はいまだ紛争が絶えず、トランザクションやセキュリティといったハイエンドなニーズにフォーカスした議論が果てしなく続いており収束しないことが何よりの証拠である。彼等は、現在の主流顧客に売り込める高付加価値な商材としたいがために、Webサービスは高度で画期的なものでなければいけないと思っているのだ。

しかし真実はその逆で、むしろいかにシンプルな技術体系のまま最適なアプリケーションを見つけることができるかなのだ。固定化すべきは技術の方で、パラメータとして変動させるべき要素はアプリケーションの方なのだ。「標準化されたお手軽なネジ」を必要としている市場を探さねばならないのだ。

■Webサービスのこれから

かつて3年前、私にインタビューしたことのあるIT関係の記者の方なら覚えているかも知れないが、当時の私はWebサービスを完全に疑問視していた(メディアのWebサービス迎合路線に背いた発言は黙殺されたので、ほとんど世には出ていない)。今だって、ベンダーが煽るような所謂「独立したサービスが自動的に連携されてひとつのシステムを作り上げる」という大袈裟なバラ色の未来を匂わせる「Webサービス」は全く馬鹿げていると思っている。

しかし、今は単なるアンチWebサービスではない。少しずつではあるが、SOAPのような技術がうまく適合できる分野が見つかってきているし、Blogやニュースサイトで急速に浸透してきたRSSという思いがけない追い風で、XML+HTTPを活用したシステムは「鶏(提供者)が先か、卵(利用者)が先か」の状況にブレイクスルーの兆しが出てきた。

いま必要なのは、さらなる上位レイヤーの標準の統一化ではなく(そんなことはできないし無意味である)、こういった新しいカジュアルな市場で地歩を固め、イノベーションを破壊的なパッケージングへと育てていくことなのである。

ところで「Webサービス」という言葉、あまりに一般的な用語の組み合わせで、しかも定義域が曖昧なため皆が不便を感じていると思うのだが、もっと細分化されたいい別称はないものだろうか?まぁ、IBMやマイクロソフトが主流顧客に向けたマーケティングワードとして使っている限り引っ込みがつかないだろうことは予想に難くないのだけれども、いい名前を与えられなかったプロジェクトは求心力が弱くエントロピーが高まってしまうという心理的要因から、プロジェクトそのものが失敗する確率も高いということはご存知ないのだろうか?

♪ U.K. / IN THE DEAD OF NIGHT

※このエントリは CNET Japan ブロガーにより投稿されたものです。朝日インタラクティブ および CNET Japan 編集部の見解・意向を示すものではありません。
運営事務局に問題を報告

最新ブログエントリー