|
Googleとfacebookの”データ調達ルート”の違い
ネットビジネスは多くの場合、ユーザに何らかのデータを見せるというサービスを提供している。ユーザに見せる「何らかのデータ」は、その入手経路の違いにおいて、大きく以下の2種類に分けることが出来る。
(1)データの調達ルートとデータの消費ルートが違う場合
(2)データの調達ルートがデータの消費ルートが同じ場合
分かりやすい例を挙げれば、(1)はGoogle(の検索サービス)、(2)はfacebook(のSNSサービス)となる。
Googleの検索サービスのデータの調達ルートは2つある。1つは、クローリングによるWebコンテンツの収集。もう1つは、広告主による広告の提供だ。これを検索サービスとしてユーザに提供すること(データの消費ルート)によって、サービスの骨格が成り立っている。
一方、facebookのSNSサービスは、登録ユーザのアクションを記録し、それをユーザ間で共有することで成り立っている。Googleの検索サービスに対するオルタナティブと目されている「Like」という機能にしても、 facebookとしては、「Like」というボタンをユーザが押すと、そのデータをfacebook上で共有できるということから成り立っている。ユーザがボタンを押さなければ、facebookには何のデータも貯まらず、それを閲覧することもできない。
データ調達コストを低減させるためには?
前述の(2)は、「ソーシャル○○」というキーワードで括(くく)られることが多い。重要なのはユーザ獲得とその活性化であり、ユーザがアクションを起こしてくれない限り、何のデータも貯まらない。ユーザのアクションを記録しやすいネットというメディア特性を活かしたサービスモデルであり、リアルサービスでは対応物がまだ少ない。ブックオフのような中古販売のビジネスモデルは、ユーザの持ち込む商品を転売するという意味で近いといえる。しかし、ここで注目したいのは(1)の方だ。
(1)は、データをどう調達するかでそのモデルは千差万別だ。先に挙げたGoogleの検索サービスの例では、部品となるWebコンテンツをクローリングにより調達し、ランキングアルゴリズムにより付加価値をつけてユーザに提供する。ニュースサイトのように、自身でコンテンツを生産するところもあるし、ネットゲームのようにゲーム(およびゲーム内アイテム)を開発し、それを提供するところもある。いずれにしろ(1)の場合は、データの調達に何らかのコストがかかる。(2)がユーザ獲得のマーケティングコスト中心になるのに対し、(1)にはデータ調達コストを考える必要が出てくるわけである。
データ調達コストを低減させるためにはどうするか?別に難しい話ではない。自身でデータを製造・収集するのではなく、既に収集されたデータを手に入れれば良い。視点を変えて言うと、データを製造・収集するサービスとデータを加工し、ユーザに提供するサービスを分離させれば、それぞれの強みを特化させることができ、効率化を図ることができる。いたって、シンプルな分業モデルだ。
ティム・オライリーの主張するエコシステム
ここでいう「データを製造・収集するサービス」こそ、政府や行政機関の強みを活かせるサービスだと宣言したのが、ティム・オライリー氏のいう「ガバメント2.0」である。同氏は、5年ほど前にWeb2.0というコンセプトを打ち出した。その後、Web2.0の含意は様々に拡張、拡大解釈され、いったい何をWeb2.0と呼んでいるのかよくわからなくなった。ただ、このガバメント2.0というコンセプトと対比してみると、Web2.0で言いたかったことがうっすらと見えてくる。つまり、Web2.0にしろ、ガバメント2.0にしろ、「データを製造・収集するサービス」と「データを加工し、ユーザに提供するサービス」を(少なくとも概念的に)分離し、互いに補完するようなエコシステムを作るべきだと主張していると捉えられる。前者の「データを製造・収集するサービス」を「プラットフォーム」と呼んでいるわけだ。ここでは、後者の「データを加工し、ユーザに提供するサービス」を、便宜的に、フロントエンドサービスと呼んでおこう。
図書館のデータに光をあてた蔵書横断検索『カーリル』
プラットフォームの構築には投資が必要になる。既に述べたデータ調達コストもかかるし、たくさんのフロントエンドサービスに使ってもらうためのハードやネットワーク費用も多大にかかる。しかし、政府や行政機関はその業務上、既にデータの調達を日常的に行っているはずだ。それは各種の統計情報であったり、行政の運営上必要な管理データであったりする。しかも、それらのデータはかなり有用であるはずだ(そうでなければ、税金で収集するのはおかしい)。日本でも、電子政府や各自治体の電子化はそれなりに進展しているようだ。ただし、それらのデータをプラットフォームとして、様々なフロントエンドサービスに提供するというのは、かなり遠い道のりのように感じてしまう。
しかし、実例ができた。それが、Nota Inc.の提供している図書館の蔵書横断検索システムの「カーリル」だ。図書館は、各自治体ごとに程度差はあるが、それぞれのサイトを運営し、蔵書検索ができたり、予約ができたりするシステムが導入されている。とはいえ、Amazonやブクログなどの書籍購入・管理サービスなどと比べるとユーザビリティの面で物足りないし、また、それにそれぞれの自治体が投資をしていくとすると、日本全体で見れば、税金の使い道として、非効率だ。それに対して、ユーザビリティの面は、「カーリル」に任せてしまうと割り切ってしまえば、図書館はそのデータのメンテナンスに専念するだけでよいことになる。もちろん、「カーリル」だけでなく、他のサービスが参入したって良い(この場合、市場的に難しい気がするが)。

『カーリル』のマネタイズと新たなビジネスへのヒント
問題は、「カーリル」のようなフロントエンドサービスはどうマネタイズできるか?である。ひとつは、前回のコラム「『FREE』が抱える矛盾。フリーであることの目的とは?」で書いたように、ユーザのアクションログをマネタイズの種とすることだ。ただし、これには、政府や行政機関の収集したデータを使って私企業がマネタイズするということに関する抵抗をうけるリスクと、使用するデータによっては、そのログもかなり個人情報に近いものになってしまうリスクがありうる。
「カーリル」は、構想含めて2ヶ月で制作したらしい。もちろん、メンバが優秀であるということもあるだろうが、データさえあればその期間でのサービス開発が可能だということでもある。つまり、これは上記のリスクをなんとかクリアしさえすれば、かなり有用なネットサービスが低コストで作れるということを意味する。リスクのクリアは政府や行政機関の対応次第のところもあるが、そこには貴重なデータが使われずに埋まったままになってもいる。それをなんとか引きずり出せないか?こんなところにも、新しいネットビジネスのヒントはあるかもしれない。
|