3D mode!

Entries tagged with "Twitter"

TwitterのイベントをNotifo経由でプッシュする「Notwife」をリリースしました

「名前、どうしよっか」「んー、Twitter と Notifo だから、Notwifo でいいんじゃないの」「お、いいねー」ってお話をしていたはずなんだけれど、気が付いたら最後の “o” が “e” に変わって Notwife が名前になっていました。

Notwife is not your wife.
Notwife is not your wife.

@kei_s@june29 のチームで作ったアプリを紹介します。

Notwife ってなあに

アプリケーションの説明は Notwife の Web サイトに書いてあります。

なんで Notwife を作ろうと思ったの

モチベーションはみっつくらいありました。

  • Twitter の Site Streams に触れてみたい
  • Pushable Web への布石にしたい
  • むしゃくしゃしてやった

Twitter の Site Streams に触れてみたい

2010年9月28日に投稿された User Streams goes Production, Site Streams adds Home Timelines – Twitter Development Talk | Google Groups を読んで Site Streams は面白そうだなぁと思いました。

Twitter のユーザは数え切れないほどたくさんいて、API に触れているのは、そのうちの100人に1人くらい。さらに、Streaming API に触れているのは、そのうちの100人に1人くらい。さらにさらに、Site Streams の API に触れている人となると、そのうちの100人に1人くらい。そんなふうにざっくりと仮定してみて、Site Streams は遊び甲斐がありそう、遊んでみよう、と思うに至りました。

いやあ、Favstar.fm の「速さ」には恐れ入ったのですよ。クローリングとかスパイダリングとかスクレイピングとか API を叩くとか、データを取得する方法はお行儀の悪い方法から正式な方法まで色々とありますけれど、たくさんのユーザの行動データを Streaming API で取得できると、ここまでユーザ体験が変わるもんですか、ってね。

Pushable Web への布石にしたい

TwitterのChirpUserStreamsをWebSocketで垂れ流すで書いたような個人用システムは半年前にはすでに動いていて、プルだけじゃなく「プッシュ」という選択を自由に活用できる状態で Twitter を楽しんできた。ときには、他の Twitter ユーザさんの iPhone にプッシュを送る「プッシュ代行業」を趣味で展開したりもしていて、喜んでくれていて、この状態はもっと多くのユーザが簡単に体験できるべきだ、との考えを強めていた。

たとえば「ふぁぼられた!」を瞬間に検知できるのと、その日の夜に「あ、ふぁぼられていたのか」と遅延とともに知らされるのとでは、休み時間の教室でボケをかましたときに、その場で笑いが起きるのと、その日の夜にメールで「あれ、面白かったよ」と知らされるのと、それくらいの違いがある。その場で笑いが起きれば、縦続けに次の言葉をつなげられるかもしれないところで、フィードバックが得られないとなると、コミュニケーションの質は下がり量も減ってしまう。

目の前にお話相手がいれば、自然と笑い声が耳に届くように、本来、ボクらの生活には「プッシュ」が溢れている。ところが、舞台を Web に移すと、途端に「プル」だらけの世界になって、なんだかそれが当たり前だと言わんばかりの空気さえある。違う違う、情報の種類に応じて、コミュニケーションの種類に合わせて、プッシュとプルは上手に共存するべきものです。

Twitter のようにリアルタイム性の高いデータを流通させてくれるサービスや、WebHookspubsubhubbub などの概念、プロトコル、実装のラインナップが増えてきて、Web は次第にプッシュフレンドリーになってきたと言えます。さらに、iPhone 等のスマートフォンなんかがあれば、これらをいつでもどこでも受信できる。これらが人々の生活に自然に溶け込む世界を思い描いている。

Notifo は、よくできているので、もっと多くの人が活用を始めたらいいなって思っています。今回、ボクらが作成した Notwife の体験を通じて、誰かひとりでも「ああ、プッシュってこういうことか」「じゃあ、あの情報もプッシュで受け取れた方がいい!」「Notifo を使えば簡単に iPhone にプッシュできるのか!」なんて思ってくれたら、プロジェクトとしての Notwife は成功ってことです。

Notwife が、Pushable Web への布石になりますように。

むしゃくしゃしてやった

Web アプリケーション開発ならなんでもよかった。今でも反省していない。とても楽しかった。やっぱり自分は Web が好きなんだな。

開発の動機をざっくりまとめると「Rails」と「Twitter」と「Notifo」で遊びたくて、Notwife はちょうどいい遊び相手になってくれました、ということです。

まとめ

Twitter のイベントを Notifo 経由でプッシュする Notwife をリリースしました。このエントリには、開発の裏側にあるコンセプトを書きました。

企画、設計、実装、運用。まるっとすべての作業を @kei_s@june29 の2人で分担してこなしています。フロントエンドはボクが作り、バックエンドは @kei_s さんがしっかり作ってくれました。実装の詳細は、@kei_s さんと整理した上で、エントリを改めて書きます。準備中です。


あとで書いた。@kei_s さんのNotwife というサービスを始めました – 札幌市西区や、Notwife の About ページをご覧ください。

思い付いたアイディアを「Twitter のさ、Site Streams でさ、新着イベントをさ、Notifo でさ、iPhone にさ…」ぐらいのぼんやりした感じで話しただけで、このエントリに書いたようなコンセプトの深いところまで読み取って、すぐに作業を始めてくれた @kei_s さんには、今回も感謝しています。これまで過ごしてきた時間の密度に支えらえて、ブレなくプロジェクトを進行できたと思います。

裏側のお話ばかりになりましたが、Notwife をどうぞよろしくお願いします。よかったら使ってみてください!プッシュ生活をあなたにも!

Twitterのタイムラインを可聴化するChirp sound playerを作った

皆さん、Chirp していますか!ボクは相変わらず Chirp のある日々を楽しんでいます。Chirp がなければ出会わなかったであろう tweet ってのがけっこうあって、API の設計ひとつでユーザの行動にも影響があるなぁと考えると面白いです。

このまま Chirp がまっとうに進化していけば、あらゆる Twitter クライアントが既存の API から Chirp に移行し、誰もが即座に自分の tweet に対する反応等を知れるようになるでしょう。これに対してボクは何か働きかけようとは思いませんでした。

他に Chirp の可能性はないだろうか。模索していました。タイムラインに流れる tweet を数十秒遅れではなくリアルタイムに受け取れるようになったとき、何が変わるでしょうか。考えてたどりついたひとつの答えが「音」です。「つぶやき」とも呼ばれる tweet が人々の「おしゃべり」だとしたら、数十秒おきにまとめて、ではなく、リアルタイムに感じられるべきでしょう。

というわけで、Twitter のタイムラインを可聴化する Chirp sound player を作ってみました。

ChirpUserStreams => WebSocket にリンクがあります。

JavaScript で audio タグを生成して音を鳴らしている実装の都合から、Firefox の上でしか動きません。前回のエントリで ChirpUsersStream を WebSocket で閲覧するアプリを紹介したときには「Google Chrome でしか動かない」と書きましたが、今回は swf を間に噛ませて Firefox でも WebSocket が動くようにしています。

Chirp を毎日眺めていると、ユーザの行動習慣のようなものが見えてくるときがあります。「また○○○さんのハイパー follow タイムが始まった」「□□□選手の fav 無双だー!!」といった具合です。しかし、これを見つけるためには訓練が必要です。もっというと「目」が必要です。ところがボクの目はふたつしかなく、そのふたつを常に Chirp に割り当てていては職を失ってしまうでしょう。そこで「耳」を使います。

Chirp sound player では、Twitter ユーザの screen_name を用いて音階を決めています。screen_name が変わらない限り、ユーザの音階は固定となります。これにより、優れた耳があれば、ある程度、音だけでタイムラインの様子を知ることができるようになります。screen_name から単一の音階ではなくメロディを作るようにすれば、ユニーク性が増してもっと楽しくなるかも知れませんね。

そもそも「可聴化」という言葉は @negipo さんの2年前のエントリで出会い、書かれていることにも大きく納得させられたのでした。今になって読み返してみてもやはり面白い。

LDR上ではてブ数を可聴化するgreasemonkey、LDRHatebuCountListenableを書いた (polog)

実装について少し

JavaScriptで波をつくろう。リアルタイム波形生成&再生 – Yanagi Entertainment

@yanagia さんの上記エントリが素晴らしくて、刺激を受けた背景があります。今回は「JavaScript から任意の音階の任意の長さの音を出したい」が要望だったので、公開されているソースコードを大いに参考にして関数を作りました。

june29′s jsaudio at master – GitHub

HTML5 に触れたい!と思い、WebSocket と audio タグで遊んでみる、というところまできました。どんな工夫を取り入れたらもっと可愛らしく面白くなるだろうかなー。

今回分かったこと

音を扱う作業をしていると、作業中に BGM をかけることができなくて悲しい。

TwitterのChirpUserStreamsをWebSocketで垂れ流す

Twitter の ChirpUserStreams を WebSocket で垂れ流して閲覧できるアプリを作りました!WebSocket 対応ブラウザ(Chrome 等)でお楽しみください!WebSocket すごい!ユーザ体験が変わる!

ChirpUserStreams => WebSocket

Tweets and Events

ボク @june29@kei_s から見た世界を体験できるようにしてあります。ChirpUserStreams については、以前にエントリを書きました。

TwitterのChirpUserStreamsをごくごくしてみた

本家の API がベータ版であり、まだまだ不安定なので、たまにスクリプトの再起動をかけたりしながら動かしています。見てみたいけど「なんにも表示されないよ?」って方がいたら、@june29@kei_s に話しかけてみてください。対応できるかもしれません。


User Streams goes Production, Site Streams adds Home Timelines – Twitter Development Talk | Google Groups にて、ChiprUserStreams は User Streams として正式リリース、とアナウンスがありました。伴い、本エントリで紹介している成果物も動かなくなっています。

ご自身のアカウントで試したいという方は、Ruby で書いたソースコードならありますので、よかったらご利用ください。

ソースコード: june29′s chirp2websocket at master – GitHub

ChirpUserStreams を WebSocket に流すまで

システムの基本構成は以下の通りです。

基本構成

Twitter の ChirpUserStreams が「水道の蛇口」だとしたら、Ruby でつくったホースを蛇口につなぎ、ホースのもう一端に WebSocket のアタッチメントをつけました、というところ。protected な対象はホースに仕掛けたフィルタで除去します。Chrome 等の WebSocket 対応ブラウザでアクセスすると、まるで水のように tweet と event が流れてきます。面白いのは、すべてのデータは「フロー」であって、システム内に一切の「ストック」を持たない点です。ユーザが自由に蛇口とホースとアタッチメントを選べるようになったら本当に面白いことになりそう。

さてさて、せっかくなので ChirpUserStreams で遊びたい放題しようと思い、以下のような構成のシステムを動かしています。

全体構成

Ruby でフェッチした ChirpUserStreams のデータは、RabbitMQ に突っ込むと同時に mongoDB にも投げつけました。あとから好きなようにデータを解析できます。JSON 形式そのままで投げつけることができるので保存はとても楽です。自分用 buzztter や自分用ふぁぼったー、自分用twitter検索を作ったら面白そう!

RabbitMQ に突っ込むと、ここから分岐させて stream データを活用できるようになります。本家 Twitter からのフェッチは1本にしておいて(制限もあるので)、利用は何本でも自由に、ってのが良いですよね。

今回は、自分の tweet が favorite されたり retweet されたり、reply をもらったり follow されたときに、iPhone にプッシュ通知を送り、MacBook に Growl で通知するように仕掛けてみました。favorite/retweet/reply から5秒以内に iPhone が「ティロリン」と鳴る体験は、なかなか刺激的で面白いものです。im.kayac.com は、HTTP リクエストを iPhone のプッシュ通知に変換してくれるもので、今回のようなソーシャルアプリ以外にも、システム運用や様々な場面で活用できます!

メモ

ただただ ChirpUserStreams を curl で取ってきてコンソールに出力してキャッキャと騒ぎ始めてから、気が付いたらデータで遊び放題できるところまでシステムを組んでいました。ここ数日間で知った要素技術、それを実装したソフトウェア、利用したアプリケーション等のメモです。

いろんな場面で EventMachine が登場して驚いた。これからますます活用されるようになりそうだ。

まとめ

WebSocket って、正直なところ、あまりピンときていませんでした。恐らく「垂れ流してみたいデータ」がなかったからだと思います。それが、Twitter の ChirpUserStreams の登場によって「これで勝つる!」とシビれるに至りました。キラーアプリケーションというか、キラーデータ、キラーストリームといったところです。

ChirpUserStreams 面白い!どうか公式 API になってほしい!WebSocket 面白い!もっといろんなストリームを垂れ流したい!みんなも遊んでみよう!

TwitterのChirpUserStreamsをごくごくしてみた

Twitter API Wiki / ChirpUserStreams

例によって @kei_s@darashi が「わー」「たのしー」「きゃーきゃー」と騒いでいて感化されました。身近に新しいもの好きのハイセンスな人がいると日常が刺激的で楽しいなー。

ChirpUserStreamsってなーに

小池さんの説明が詳しいです。

高密度小池 / User Stream 時代の Twitter の過し方

followings の tweets がリアルタイムで流れてくる、ってのも確かに刺激的で面白いんですが、小池さんが言うように、受信時刻がせいぜい数十秒違うくらいです。ただ、この数十秒がユーザ体験にどういった変化を与えるか考えるのは有益だと思います。

それよりも面白いのは、followings の favorite や follow や retweet といったイベントが流れてくることです。将来的にこの API が標準化されて、クライアントアプリケーションでもこの辺りのイベントを扱えるようになると、ユーザ体験がリッチになるでしょう。

お遊び

@kei_sgist: 373523 を参考に、10行くらいのスクリプトを書いて流れてくるものをすべて保存してみた。4月27日と4月28日の分を漏らさず取得できたので、さっくりチャートを作ってみたよ。1時間ごとの tweets 数と event 数です。Google Chart Tools はなかなか使いこなせないのだけれど、こういうときに気軽に使えて重宝しています。

4月29日分を追加した。

Number of tweets (27, April)

Number of tweets (28, April)

Number of tweets (29, April)

Number of events

Number of events

Number of events

一応の考察。

  • tweet 数は、日本人の活動時間を反映しているように見える。昼休みもちょっと見える
  • favorite 数は、だいたい tweet 数と同じ推移の形に見える
  • follow 数は、時間帯に関係が薄いように見える
  • retweet 数は、総じて少ない。ちなみにこれは、いわゆる公式 ReTweet の数。非公式が愛用されているのだろう

ほいで、全体を貫いて最も重要だと思っていることは「これは、あくまでも @june29 の見ているタイムラインのお話にすぎない」ということ。Web エンジニアや技術好き、新しいもの好きのユーザを中心に、1500人ほどを follow しているボクの見ている世界は、こんな形をしている。それ以上のことは言えない。きっと、他の人のタイムライン、ユーザストリームは、また違った形をしていて、ユーザ間で比較したときにようやく本格的な考察ができるのだろう。

まとめ

ChirpUserStreams をごくごく飲んで遊んでみたよ。いついなくなるか分からない子だけれど、もうちょっと遊ばせておいてほしいな。他のユーザさんから見えるタイムラインがどんな形をしているか見てみたい。楽しそう。

foursquareで遊びながらここ数年のソーシャルなんちゃらを想う

foursquare を利用する日本人ユーザが急速に増えている。きっかけは2010年1月18日の、このエントリでしょう。

Twitterの次はこれじゃね?今一番イケてる(と僕が思っている)『foursquare』について調べてみた – IDEA*IDEA ~ 百式管理人のライフハックブログ

ボクは例によって「とりあえずアカウントだけ取得した」状態だった。確か TechCrunch Japan の「位置情報サービスってなにそれおいしいの?」に答えてみるを読んで foursquare に登録したのだったと思う。

foursquare

「自分のまわりにユーザがいないと何も楽しめない」のは「他のユーザを友達登録して遊ぶ」ソーシャルなんちゃらの常で、しばらく放置していた。そして、この数週間の大流行だ。一気に foursquare 上での Friend が増えて、見える景色もずいぶんと変わった。

よくある「ソーシャルなんちゃら」の特徴を持ち、誰もが難なく思い付く「モバイル端末からの位置情報ポスト」ができ、かつ「ゲームっぽい」要素が散りばめられた foursquare に触れていると、ここ数年に体験してきたソーシャル系アプリのことを想わずにはいられない。

このエントリでは、各サービスや各アプリケーションの批評をしたいのではなくて、それらによって自分の生活、行動、思想にどういった影響があったのか、思い出しながら記録してみたい。きっと1年後には、ボクはまた別の新しいアプリケーションで遊んでいて、昔の気持ちを思い出したくなるはずだ。そのときのために記録する。

ゲームとしての foursquare

foursquare は「ゲーム」である。ボクが抱いている印象だ。

他の多くのソーシャルなんちゃらと区別するために「ゲーム」と呼ぶのは、foursquare 上でユーザに何かを与えるのは「他のユーザ」だけではなく、foursquare そのものだからである。具体的には「Point」や「Badge」や「Mayor」によってそれらは目に見える。

序文の中で「自分のまわりにユーザがいないと何も楽しめない」とは書いたものの、使い始めたときに実際にそう思ってはみたものの、実は foursquare はそうでもない。ひとりで使っていても、システムがそれなりに相手をしてくれる。foursquare を使えば使うほど Point が貯まるし、「おめでとう!あなたはこの地の Mayor (代表ユーザ) になりました!」とか「ついに Superstar の Badge (称号) を獲得しました!」などと、ユーザを「乗せて」くれるのだ(といっても今のところ Point をお金などに交換できそうな気配はない)。

だからボクは foursquare を「ゲーム」と呼ぶ。

付け加えて、foursquare の iPhone アプリには Point のランキングを見せてくれるビューがあって、これまた上手にユーザを煽ってくれるので、ソーシャルゲームと呼ぶのもいいかもしれない。

The stats

さぁ、ボクと一緒にこのソーシャルゲームで遊ぼう!なーんて!

foursquare :: june29

brightkite と foursquare

brightkite

ボクは brightkite.com がとても好き。2008年11月21日に invitation を受け、ちょくちょくポストするようになったのは2009年の5月。かれこれ半年以上も愛用している。

brightkite は「Twitter + 位置情報 + 写真」って感じで楽しむアプリケーションで、普段は行かない場所に行ったときとか、写真付きで何かを言いたいときは、brightkite の iPhone アプリからポストを楽しんでいる。

foursquare を楽しむようになって、brightkite へのポストは減った。「位置情報で遊ぶ」「iPhone で遊ぶ」あたりの特徴が重なるので、当然と言えば当然かも知れない。自分にどんな変化が起こったかを観察してみると面白い。

最初に foursquare に触れたときは「foursquare はソーシャルゲーム、brightkite は他のソーシャルなんちゃらの流れを汲むライフロギングアプリケーション」と感じた。

普段の生活の中で身を置く場所。たとえば自宅や勤務先、通勤経路となる駅などに Check in したくなるのは断然 foursquare だ。foursquare には Mayor という「その場所を代表する人」の仕組みがあって、同じ場所に頻繁に Check in するとユーザに Mayor の称号が与えられる。brightkite においては、同じ場所に繰り返し Check in するモチベーションを見つけられなかった。

brightkite を使い始めた頃から気付いていたことで、ボクらは「今いる場所の住所や緯度経度をポストしたい」わけではなく、「今いる場所を代表するような呼び名をポストしたい」のだ。ほとんどの人は「東京都新宿区新宿3丁目38-1なう!」ではなく「新宿駅なう!」もしくは「新宿なう!」と Twitter にポストする。さて、ここで問題なのは、その「呼び名」が検索しても見つからなかった場合のフローだ。

brightkite も foursquare も、ユーザが「場所」を新規登録できる仕組みがある。brightkite では「場所」の登録時に「住所」の入力が必須であり、これがユーザを新規登録から遠ざけているように感じる。ボクは何度か「あ、検索しても出ない。住所も分からないからあきらめよう」となったことがある。一方、foursquare では、検索で所望の場所が見つからなかった場合、検索語をそのまま「呼び名」として登録できるフローがあって、住所の入力は省略できる(気が向いたときにブラウザから編集してもよい)。さらに、新規登録したユーザには Point まで与えられて、登録が「歓迎される」つくりになっている。

brightkite を使っていて、「そもそも、登録されている場所に偏りがある」と感じることもあった。たとえばとちぎRuby会議02に参加するために西那須野公民館に行ったときのこと。公民館自体は brightkite で見つけられないのに、公民館のトイレはすぐに見つかって、仕方がないから、みんなでトイレに Check in した。

トイレにチェックイン!

公民館よりもトイレの存在が重要視される「場所のデータベース」と考えると、「カーナビ用データベース」が裏側にはあるのかもしれない。余談でした。

Twitter と foursquare

foursquare は Twitter と「完全連携」している。なんと、ユーザページの URL (ボクでいう http://foursquare.com/user/june29 のこと) のユーザ名部分は、Twitter のユーザページの URL と同じものになる。

これが何を意味するかというと、foursquare にアカウント登録して、Twitter のアカウントと統合すれば、「Twitter の following で foursquare を使っている人」をいきなり一覧できるってことだ。いわゆる Social Graph、考え方自体は何年も前から存在しているけれど、foursquare は思い切って Twitter を密な連携先に選んだ。これは2010年初頭においては極めて効果的な現実解かもしれないな。最強かもしれない。DataPortability.org が理想的な設計を行って、理想的な実装が登場するのを待つよりも、不安定ながらとりあえず元気に動いている Twitter の蜜を吸うのは妥当な戦略だと思う。Twitter ジュース美味しいです!

その上でひとつ分からないのは、なぜ foursquare 上の表示名に Twitter の screen name を採用しないのか、ってこと。First name と Last name で表示名を作るの、そんなに大事だろうか。Twitter で知りあって、実名を知らないような Friend さん、screen name で表示してもらわないと誰か分からなくて困ること多し!

Tumblr と foursquare

Tumblr は優しくて、とても好き。

「Tumblr は、自分さえ楽しければ他に何も要らないってことを教えてくれた」って声を以前にどこかで見聞きしたような覚えがあって、ソースは見つけられなかったのだけれど、とにかくボクはこの声に共感している。

foursquare の Mayor の仕組みは面白くて、新宿駅の Mayor になろうと思ったら(Mayor はひとつの場所にひとりなので)競争率が高くて相当な労力が必要になるけれど、誰もいないところを狙えば誰でも簡単に Mayor になれる。Friend の最近の Check in を眺めていると、みんなけっこう Mayor な場所を持っていて、画面に「王冠のアイコン」が踊っていて楽しい。ユーザのプロフィールページに Mayorship として表示されるのは、「最も頻繁に Check in している場所」ではなく、そのユーザが Mayor な場所である。頻度で場所をピックアップしてしまうと、多くのユーザのプロフィールページに「新宿駅」等のメジャースポットが並んでしまうが、そうではなく、より強くそのユーザを特徴付ける場所がプロフィールとして表示される。上手い。

foursquare

地方ユーザの brightkite や Twitter に対する反応で「近くに他のユーザがいないとつまらない」という声を聞くことがある。foursquare にも同様のことが言えるかもしれないが、Mayor 制度がそういったユーザにも楽しみを与え得るんじゃないかな。「この地域に関しては俺が誰より詳しい!」を示せるユーザプロフィールページになっている。

この「俺は俺で楽しいんだよ!」と、ユーザごとに自分の楽しみ方ができて、他のユーザの楽しみ方に大きく干渉しない仕組みは、Tumblr の楽しさを思い起こさせてくれた。

成長期として見る foursquare

foursquare を brightkite と比較したときは、foursquare に有利なように書いた。けれども、foursquare に写真を投稿することはできないし、他のユーザのポストに対してコメントを書いたりもできない。brightkite にしかできないこともあるので、現状、ボクは両者を使い分けている。

今後、このパワーバランスがどうなっていくかは分からない。どちらか一方が、もう一方の特長を取り入れて成長していくことは大いにあるだろう。それにしても、foursquare のバランス感覚というか、決断の背景に強い意志がありそうな感じ、ただならぬ覚悟を感じる。

「あれ、他のユーザのタイムラインって見れないのか」「コメントできないんだっけ」などと感じていて、ボクが「あっても良さそうと思う機能」がいくつもなかったりする。機能に優先順位を付けて、今は「本質のみを最速で」創ることに注力しているんじゃないかと予想している。「そんな機能は不要だから実装しない」と中の人が判断しているのだとしたら、きっと今のボクが想像もしていないような世界を彼らは描いている。今後、追加されていく機能、変化していく様子を見ながら、foursquare が実現しようとしている世界の姿を知っていきたい。

ところで、今の foursquare が最優先していることとはなんだろう。試しに考えてみる。それは「ひとつでも多くの位置情報付きデータをポストしてもらうこと」じゃないだろうか。それ以外に何かあるだろうか。

ゲーム要素を持たせてユーザを乗せるのも、ポスト数を増やすため。Point 制も、Mayor の仕組みも、場所の新規登録を歓迎する仕掛けも、ポスト数が多くなるようにデザインされている。とにかくたくさんのデータを集める。膨大な数の位置情報付きデータを集める。その思惑に向かって、今のところ順調に進んでいるようだ。

foursquareの1週間でのチェックイン回数が100万回を突破。成長規模は1ヵ月で2倍

じゃあ、データが集まったあとはどうしようか。たとえば、iPhone から位置情報に応じたデータを閲覧できるビューアを用意してみようか。そこに広がる景色は、セカイカメラが目指した世界なのかもしれない。ボクはまだ試せていないのだけれど、ビューアとして使えそうな FoursquareX という Mac OS X 用の foursquare クライアントもすでに存在している。「何か」が一気にひっくり返る瞬間は、そう遠い未来ではないだろう。

ソーシャルなんちゃらは「便利なもの」か「楽しいもの」か

このブログで、これまでにも何度かソーシャルなんちゃらの「便利さ」と「楽しさ」について書いてきた。

2010/02/11 22:45

ユーザが生成するデータから「便利さ」につながるような「価値」を捻出するためには、ある程度の「量」が必要となる。では、その量をどのようにして集めるか。「あなたがデータを生成してくれさえすれば、これだけ便利になるんです」と懇願するか、「楽しんで使ってもらう」ことでデータが生成される仕組みを作るか、大きく2つの方法がある。そんな風に考えることもある。

だけれども、今のボクは「楽しんで使ってもらう」そのこと自体に大きな価値があるととらえている。そして、楽しそうにしている人がいる「場」には、自然と人が集まってくるものだ。成功しているソーシャルなんちゃらは、例外なくそういった「場」を生み出している。

ボクが研究室に在籍していた頃、2004年ぐらい。「Web をもっと便利にしよう」みたいな大きな流れがあった。Web を研究対象として見ていたらから、そう感じていたのかもしれない。当時、「集合知」という言葉をよく見聞きした。また、「衆愚」という言葉も同じくらい見聞きした。

それが「賢いもの」であれ「愚かなもの」であれ、どちらも「人がたくさんいる状態」のお話をしている。ソーシャルなんちゃらってのは、つまりはそういうことか。人をたくさん集める、人から生み出されるデータをたくさん集める、それが根幹だ。そうして集まったデータを活かすか殺すか、それは次のフェーズのお話だ。

まずは何より人をたくさん集めること。そのためには「楽しさ」が不可欠であること。「楽しさ」が宿る場を用意すること。「楽しさ」そのものに価値があること。foursquare で遊びながら、ボクが考えたこと。

「集合知」の体現例として挙げられることのある Wikipedia もソーシャルブックマークも、便利であるより先に「楽しい」ものだとボクは思う。Wikipedia の上で適当にハイパーリンクをたどっていて「こんなことまで書いてあるのか!」と笑ってしまうことは少なくない。

今の foursquare には「楽しさ」がある。これから状況は変わっていくだろう。さらに人が増えれば「Mayor の私に断りも入れずに Check in だなんて、非常識だと思いませんか。この Venue は無断 Check in 禁止です」なんてネタが飛び出すかもしれない。向かう先にある「便利さ」や「お金の匂い」を嗅ぎつけて人が増えると、空気は変わってしまう。それを悪いと言うつもりはない。ただ、個人として、ひとりのユーザとして、悲しいと思ってしまうことは、ある。

Twitter はまさに今、人が集まってきたところだ。最近読んだ記事の中で、グッとくる表現があった。

すごろくやの「フォロワーの数×1円割引」キャンペーンは、1回きりで終わる見通しだ。「初めてだからこそ面白がってもらえた。あまり続けると悪用する人もでてくるし、フォロワー数の意味が変わってしまう」ため。今後もまた、別の形でTwitterを活用していきたいと丸田さんは話している。

「フォロワー数×1円割引」——太っ腹な“Twitter割り”はなぜ可能だったのか – ITmedia News

「フォロワー数の意味が変わってしまう」と言っている。この表現に込められているであろう意味に、強く共感した。

ボクはソーシャルなんちゃらを「場」だと捉えている。この「場」を「ツール」だとみなすと、途端に世界の見え方は変わってしまうのだ。このことを忘れたくない。このエントリで今の気持ちを記録しておきたい。

謝辞

テキストチャットを中心に、いつも「ソーシャルなんちゃら」に関する議論の相手となってくれている @darashi さん、@snoozer05 さん、@kei_s さん、どうもありがとう!みんながいなかったら、ここまで考えを整理できていません。このエントリには、みんなの言葉がたくさん含まれています。みんなの言葉は示唆に富んでいて素晴らしい。