2006-04-02 WebサービスAPIによる「B2D(Business to Developer)モデル」の可能性
■[Web2.0]WebサービスAPI充実に想う「B2D(Business to Developer)ビジネスモデル」の可能性
最近、昔ちょこっとかじったPHPを使って、Amazon Web ServiceやYahoo!オークションWebサービスAPIをイジってるんですが、すごく面白いんですよ!わずか数行のコードを書くだけで、膨大な情報を引き出して自分のアプリに組み込むことが出来るんですから「おっ、俺ってちょっとスゴイ?」なんて悦に浸れる事に間違いありません。
「これが開発者の特権、マッシュアップかぁ!ずるいなぁ〜楽しいなぁ〜」なんてひがんだりしながらも、ふと思ったのがサービス開発者の立場として「WebサービスAPIの提供をビジネスモデルとして説明できるか?」ということです。
WebサービスAPI提供のビジネスモデルを説明してみる...んだけども。
そこで、ビジネスモデルの説明としてB2C(Business to Consumer)やB2B(Business to Business)といった考え方を使ってみたのですが、しっくりこないんです。何故でしょう?
もちろん、AmazonやYahooやGoogleそのものはB2Cとしてサービス全体を説明できるんですけど、WebサービスAPI提供に絞ると途端になんだか説明が難しいのです。
僕としては、このしっくりこない感について色々考えてみた結果、WebサービスAPIの提供相手がConsumerでもなくBusinessでもなく、"サービス開発者であるDeveloper"であることが原因であるような気がしました。
そこで今日は、B2CでもなくB2Bでもない、サービス開発者向けのWebサービスAPI提供のビジネスモデル、B2D(Business to Developer)モデルについて考えてみたいと思います。
なお、B2Dという単語は僕が考えを集約する為に勝手に作った言葉であり、一般用語ではありませんのでご留意ください。以下でも当たり前のごとく頻発しますが、ご容赦ください。
B2D(Business to Developer)モデルを定義してみる
僕は、B2D(Business to Developer)のビジネスモデルを考えるにあたって、まずは以下のように定義してみたいと思います。
「自らが所持するコンテンツを、再加工/再利用を目的としたサービス開発者に対してコンテンツのみを提供する事により、自らのサービス価値を高めるビジネスモデル」
違った角度から単純化して言い換えれば
「サービス提供者のサービス提供者によるサービス提供者のためのサービスモデル」
とも言えるかもしれません。(WebサービスAPIについてご存知の方にとっては、「なにを、当たり前の事を!」と思われるかもしれませんね)
サービス開発者に対して提供される「モノ」は、提供側のコンテンツ(=データ)でありコンテンツを引き出したり登録したりするための窓口となるAPIです。
また、サービス開発者は誰かに対するサービスを提供する立場であり、彼らには彼らの顧客でありユーザが居ることが前提となります。
モデルを図にしてみると、以下のようなイメージとなります。
B2Dモデルの分類とメリットの整理
- B2Dモデルのメリットは?
サービス開発者側(提供を受ける側)にとってのメリットは、簡単な手続きで価値の高いコンテンツを手に入れ自らのサービスに組み込むことが出来ることであり、サービス提供側にとってのメリットは、サービス開発者からの直接的な収益を得ることができる、もしくはサービス開発者が提供するサービスを経由した間接的なトラフィックを得ることが出来ることです。
サービス提供者側にとってのメリットはビジネスモデル全体の組み方によって変わってくるので、すこし分類したいと思います。
- B2Dモデルの分類
以下、WebサービスAPI提供者側から見たときの価値の求め方を軸に、3つのモデルに分類してみたいと思います。
(1) トラフィック課金型
WebサービスAPIの提供側がサービス開発者に対してコンテンツやストレージ等を提供し、提供されるそのものが売り物であり、サービス開発者に対して課金を行うモデルです。
典型的な例としては、Amazon Web ServicesのAlexa系のサービスAlexa Top Sites,Alexa Web Information Service,Alexa Web Search Platformが「トラフィック課金型」モデルです。
売り物がハッキリしているので、分かりやすくて良いですね。
(2) トラフィック誘導型
WebサービスAPIの提供側がサービス開発者に対してコンテンツや検索APIを提供し、サービス開発者が開発したサービスからトラフィックが集まってくることによって、アクセス数の増大による広告収入の増加、若しくはショッピングサイトであれば商品販売件数の増加をメリットとするモデルです。
典型的な例としては、Google Web APIsやYahoo!検索Webサービスのようなサーチエンジンの検索API(メリットはトラフィックの増大)や、Yahoo!オークションWebサービスやAmazon E-Commerce Serviceのようなショッピングサイトの商品検索API(メリットは商品販売数の増大)が「トラフィック誘導型」モデルです。
一般的に、WebサービスAPIというとこのモデルを指すことが多いですね。
(3) コンテンツ増強型
上記の二つと大きく違う点は、WebサービスAPIの提供側がサービス開発者に対して提供するのがコンテンツではなく、コンテンツを登録するためのAPIであることです。一般的にはコンテンツ登録用だけではなく検索・参照用のAPIも一緒に提供されるので、サービス開発者側からはコンテンツの保存や処理を行ってくれるブラックボックスに見えます。(まさにAPIですね)
WebサービスAPI提供側としては、サービス能力を開発者側に提供する見返りに、自サービスのコンテンツが増強される事をメリットとするモデルです。
典型的な例としては、はてなブックマークAtomAPIですね。またGoogle Baseで登録用APIが公開されれば、この「コンテンツ増強型」モデルに属すると思います。
一般的には、このモデルに該当するサービスはコンテンツの整理・分類をしてくれたり、ユーザからの注目を集める媒介としての役割を果たしてくれる場合が多いように思います。言わば(2)のトラフィック誘導型の逆とも言えると思います。
B2Dモデルの成立条件と適用の可能性
このB2Dのモデルも、どんなサービス提供者でも実現できるというわけではないと思います。以下に、どんなサービス(およびサービス提供者)であればB2Dのモデルが成立しうるかをリストアップします。
- B2Dモデルの成立条件
- B2C若しくはB2BのWebサイトを持っていて、既存のトラフィックが存在すること。
- サービス開発者が再加工/再利用してみたいと思うような「コンテンツ」を持っていること。
- B2Dのメリットを理解し、永続的にWebサービスAPIを提供できる文化があること。
実は成立条件としてとても大事な事は、3番目の「B2Dに対する理解」のような気がします。
B2Dのモデルは、言わば自サービスの肝であるコンテンツを外部に流出させてしまうことであり、下手すれば競合を利するような結果にもなりかねません。このデメリットは、ちょっと頭が固めの方や、ネガティブ思考の方から突っ込まれる最大のポイントになるはずです。(「商品そのものをタダで競合に渡すなんて、君は何バカな事を考えているんだ!?」とか思いっきり突っ込まれそうです)
ですので、是非僕個人としてはB2Dのモデルのメリットについて、色々な方と話をして考えを深めたいと思っています。無論、具体的な事例も必要だとも思います。
- B2Dモデルの適用の可能性
また、これから新規でサービスを組み立てるとき、もしくは既存サービスの最大効率化を考えるときには、そのサービスがB2CかB2Bのモデルとしてどうかという視点と共に、B2Dのモデルが成立するかどうかを考えられると面白いと思います。
もし、B2Dのモデルがハマるのであれば、そのサービスがリーチできる範囲が大きく広がります。特に「規模」が重要となるロングテール系のビジネスでは、「規模」すなわち「サービスの強さ」を強化することができるので、ひいては収益面でも良い影響を与えることが出来るはずです。
とはいえ課題も...
ここまで、B2Dモデルとは何か?から始まって、そのメリットと成立条件についてお話させていただきました。
とはいえ、課題もあります。
当然、プログラミングが出来る技術者が世の中に腐るほどいる訳でありません。むしろWebサービスAPIを使ってサービスを組み立ててみようという意欲的な技術者の方は、ごく少数なのだと思います。
仮にWebサービスAPIを提供したものの、大して使われないような事が発生すると、コンテンツをオープンにしてしまうリスクと、B2Dモデルのメリットが釣り合わずリスクの方が大きくなってしまう可能性があります。また、将来のバージョンアップ時の費用という観点でもWebサービスAPIは重く圧し掛かってくるでしょう。
この為、比較的小規模なサービス提供者では、WebサービスAPIを提供しにくいという現実もあると思います。
この課題を払拭し、手軽にWebサービスAPI提供に踏み切ることが出来、使う側も可能な限り低いスキルレベルで利用できるような解決策を、すみませんが僕は今思いつきません・・・。
技術に精通していなくても、マッシュアップができるような提供方式・・・。
今でいえば、RSSの提供という事になるのでしょうか?もしくはBlog Widgetのような形での提供でしょうか?
今後も、B2Dモデルへの参入障壁を下げるような方法論と、B2Dモデルのメリットについて、考え続けてみたいと思います。
【あとがき】
なんだかエライ長い内容になってしまって、読むにも一苦労の内容だったと思います。その上「B2D」という言葉を勝手に考えたにも関わらず、書いていくプロセスで僕自身の中で一般化してしまったので、説明不足だったところもあると思います。最後まで読んでいただいて、ありがとうございました。
また、この着想を得る事が出来たのは、id:kokepiさんのGoogle Base関連の記事があったからこそです。この場を借りてお礼を言いたいと思います。素晴らしい記事を書いて頂き、ありがとうございました。
この記事によって、読んで頂いた方がサービスを考えるときの思考ツールが増えたり、考える取っ掛かりになったり、考えの整理の一助になれば、僕にとってそれ以上嬉しいことはありません。
- 378 http://b.hatena.ne.jp/
- 93 http://b.hatena.ne.jp/hotentry
- 24 http://www.hatena.ne.jp/
- 14 http://acc.blogdb.jp/
- 13 http://b.hatena.ne.jp/entrylist?sort=hot
- 13 http://ja.reddit.com/
- 12 http://feedbringer.net/feed
- 12 http://www.google.co.jp/ig?hl=ja
- 10 http://b.hatena.ne.jp/hotentry?mode=daily
- 9 http://b.hatena.ne.jp




