Virtual化する社会（Short ver.）

年が明けてから3ヶ月近く経って、新年の抱負も今年の予測も何もないが、今年は Virtual化（Virtualization）がますます進むと考えている。ここでいう「Virtual化」とは、SecondlifeのようなMetaverseだけを意味するのではなくて、もっと広義のVirtualizationのことである。具体的には、Web上の「ID」や「ハンドルネーム」でidentifyされた個人が、現実世界とは別個にWeb世界で活発に行動する傾向が進むということである。

「ハンドルネームでBlogを書く」というこの行為自体、ここで言うVirtualizationの具体例と言えるし、「Amazonで本を買う」「ヤフオクでレア品を競り落とす」という行為もVirtualizationの実例である。各々、AmazonのログインIDやYahoo!のIDで特定される「Web上の個人」が「Web上で商行為を行っている」と言えるからだ。ビジネスにおいて、こうしたWeb上の活動を捉える場合、現実世界のリアルな個人と紐付けて考える必要はない。現実世界における性別・年齢・職業と言った属性情報はWeb上では何の意味もなさず、あくまで「Web上のナニモノか」というidentificationさえできればよいからである。Web上での個人活動は、現実世界と深くリンクしている場合もあれば、全く異なっている場合もある。いずれの場合であっても、Webビジネスに深く関係するのはWeb上の行動でしかなく、それを捉えることが最も大事なのである。私自身を例にとれば、Web上であたかも技術者のように振舞っているTEDDY-Gを、現実世界の商社マンの振る舞いと紐付けて考えることは全く意味がない。寧ろ、「Web上での私」を捉える意味ではDecisionをmisleadする可能性すらあるのだ。

というわけで、既に3ヶ月が経過してしまっているが、今年はこの「Web上の人格」「Identification」に注目している。昨年盛り上がったMetaverseのような直接的なVirtualizationより、もっと深いところでVirtualizeされたサービスとかシステムとか、そういうものをビジネスにしたいというか作りたいというか、そんな妄想に耽る今日この頃である。

U2Bplayer、改修＋ややupdate

YouTube APIがGoogle Data APIに統合されて新しくなったので、U2B playerも更新。…って、とっくの昔に出来てたネタを、サーバにUPするのに1ヵ月半もかかってしまうというこの事実。以下、簡単に。

改修したところ
・「お気に入り」「投稿ビデオ」の表示数上限を25個に戻した。
Updateしたところ
・「Today's Top Rated Video」以外に、「Today's Most Viewed Video」「Recently Featured Video」を追加。
（Option Toolsで設定できます）

いずれもYouTube APIの変更により可能となったもの。サポートチームが「将来直すかも」と言ってたのはこのことだったのか。

PEAR::Services_Lingrで日本語を扱うときの注意

Cometを使ったホントの非同期ブラウザチャットのLingr、使ってみるとかなりCool。ブラウザベースだからソフトをインストールする必要もないし、軽くチャットするだけならアカウントを取る必要すらない。まさにインスタントなメッセンジャー。でもってこのLingr、APIまで公開してあり、様々なサービスに展開する可能性を秘めている。実にCool。Lingrの仕組みについては江島健太郎氏のこのエントリを読んでいただくとして、APIを使って何かしたい人には、既に様々なライブラリがDeveloper Wiki上で公開されている。いやあ、実に2.0、2.0。

でもって、ライブラリの一つ、Lingr APIをPHPで簡単にいじくることのできるパッケージのPEAR::Services_Lingrを使ってみたんだけど、Room.observeメソッドとかでメッセージを取り出すときに日本語のメッセージがうまく取れない。調べてみたら、Lingr APIが返してくるXML中の日本語が数値文字参照で、そのままだとXML_Unserializerが読んでくれないことがわかった。ので、Services_Lingrパッケージの中のLingr.phpの中でXML_UnserializerにXMLを投げるところの前（94行目あたり）に下記のようなコードを挿入して問題解決。

...
$result = $http->getResponseBody();
$map = array(0x0080, 0xffff, 0, 0xffff);
$result = mb_decode_numericentity($result, $map, "UTF-8" );

$xml =& new XML_Unserializer();
...

UTF-8じゃなくてEUC-JPにするときは、$map=array(0, 0x10FFFF, 0, 0xFFFFFF); とすればよい。これでXML_Unserializerで処理して返ってきた配列がちゃんと日本語で返ってくる。mb_decode_numericentityの使い方については、こことここを参考にした。有難うございます。
ひょっとしたら最新版のXML_Unserializer使えば問題なく動くのかもしれないけど、一応メモ代わりに。…って、Lingr APIをPHPで使いたい人、しかもXML_Unserializerｄが何かちゃんと日本語処理してくれない人、ってえらい限定された人向けのエントリだな。

Powered by ScribeFire.

今見ているページにGoogle Mapsを追加するBookmarklet

こないだのG2Gmapの応用。
今見ているページ上で住所部分を選択し、下記のBookmarkletを実行するとページ内にGoogle Mapsを表示する。
地図を表示

Bookmarkletの登録方法は、IEならば上記リンクの上で右クリックをして「お気に入りに追加」を選択。「追加しようとしているお気に入りは、安全でない可能性があります。続行しますか？」と聞かれるので黙って「はい」を選ぶと登録完了。追加先を「リンク」フォルダにするとリンクツールバーに表示できる。
Firefoxの場合も同様に右クリック→「このリンクをブックマーク」で登録可能。このとき、「個人用ツールバーフォルダ」を指定すると、ブックマークツールバー上に表示できる。Operaの場合も同じようにして登録できる。

前のエントリでもちらっと書いたが、知らない土地でレストランやお店の情報を得るときに、ブログや個人のウェブサイトが役に立つことが結構多い。で、そういう草の根情報が地図情報と一緒になってると助かるんだけど、個人サイトでそこまでサポートしてくれていることはあんまりない。そんなとき、このBookmarkletでひょいっとページ上に地図を表示したら便利じゃないかなと。こういう、「ウェブページをお好みでカスタマイズして使う」というのは、Greasemonkey然り、Widget然り、結構当たり前の方法になるような気がする。

Powered by ScribeFire.

How to Make "Mash Up"

Mash Up Award the 2ndが開催されるとのことで、僭越ながら前回受賞者としてコメントを寄せさせて頂きました。
今回は15社以上の企業がWeb APIを公開・提供するそうで、中々面白げ。現時点ではどういうAPIが揃っているのかまだ全部チェックしきれてないんだけれども（輸入CDのライナーノーツみたいだ）、コメントに書いた通り、それだけの企業が「乗ってきた」こと自体がすごいと思う。確かに企業にしてみれば、API公開はただのロックイン戦略でしかないんだけれど、この場合、ロックイン対象はGeeksなわけで、それだけGeeksを企業が重視するようになったということになる。つまり、インターネットの世界のEarly AdopterがGeeksだという認識と、Geeksをターゲットにしたマーケティング（ギーク指向マーケティング、Geeks Oriented Marketing）が漸く一般化してきたというわけだ。

「API公開」の企業にとってのもうひとつの利点は、市場に対する開発のアウトソーシングである。APIを公開しておくだけで、市場の草の根開発者が自動的に二次開発を行ってくれるわけで、企業としては開発コストを下げることが可能になる。うまくいけば開発コストダウンと、二次サービスによる集客アップが図れる一方、失敗しても投資の回収リスクは殆ど生じない（勿論、公開API準備コストが殆どかからないという前提だが）。本来自社でまかなうべきコストを市場に投げるという意味では、社員への報酬を市場取引に任せてしまうストックオプションに似た仕組みとも言えるかもしれない（すると、その内API公開のコストP/L計上すべきなんて議論に…!?）。

さて、前置きが長くなったが（いや寧ろここまでが本文か）、本題のMash Upの作り方について。既にKawa.net Blogでスマートに説明されてるので、その通りなんだけれども、大事なのはどういうRemixをするか、という点。自分の場合、大きく分けて、二つの方法論（というほどのもんじゃないが）に沿って作っている。一つ目は、「こういうことができればCoolだよなあ」という、Usage-Centricな発想に基づくもの。例えばU2B Playerがそれ。「YouTubeのお気に入りをブログで表示できたらよくね？」みたいなところからスタートして、自分が使うところをイメージしてインタフェースを作りこんでいく。二つ目は、ビジネスモデルの雛形に肉付けしていく、もっとBusiness-Orientedなもの。例えばYouTube＋Adsとか、Bidders MapAdsがそれ。「動画に広告」とか「地図に広告」とかをイメージする、或いはイメージしてもらう為に作ったもので、テーマが歴然としている。

恐らく、ビジネスマン的には後者の方が作りやすいし、簡単だ。「頭だけでビジネスを考えてしまう人たち」のエントリの冒頭部分に挙げた新規ビジネスの発想法の2と3などを参考に、素材とするAPIの組み込み方を考えるだけ、それだけの作業である。しかし、個人的にはこうして作ったMash Upは「あざとい」のでイマイチだと感じている。その一方、前者のようにUsage-Centricで作られたMash Upは、作者自身が楽しんで使っているだけにユーザーも素直に受け入れられる「面白さ」がある。いずれにせよ、Mash Upを作るにはできるだけ多くのAPIやサービスを知っていることが前提条件で、可能な限りのTrial & Errorを繰り返すことが方法論云々以上に重要だと思う。

ちなみに、「Last.Tube」はUsage-CentricかつBusiness-OrientedなMash Upだと思ってるんだけど、あんまり（というか全く）注目されてないっぽい。しょぼん。シンプルながらCOOLな「ZonTube」みたいなMash Upをメイクできるかどうかは、結局はセンスの問題、とか何とか身も蓋もないことを最後に言ってみる。

Got To Do (alternative GTD)

2005年に"Web2.0"というキャッチーなフレーズで総括されたここ数年のインターネットの「革新」が、2006年には世の中にかなり広く認知されるようになった。勿論それは、ベストセラーとなった梅田望夫氏の「ウェブ進化論」の貢献に因るところも大きいわけだが、それ以上に、YouTubeやはてなブックマークなどのサービスが非常に身近になったことや、ブログやSNSの「簡単さ」が一般ユーザーにとっての障壁を下げていることが大きいだろう。こうした流れの中で、ブログパーツ（Widget）を使えば"MashUp"さえも今や一般ユーザーが簡単に実現できるようになった。つまり、2006年はWeb2.0（或いはSemantic Web）のコモディティ化の年だった、と言える。

その一方で、Geeksは一般ユーザーには全く実現し得ない世界を構築しつつある。例えば、Perlを使ったインターネット上のリソースアクセス自動化ツールの「Plagger」などは、使い勝手・必要性・面白さの全ての意味で、一般人には理解不能なツールである（Googleに「はらへった」と入れただけでピザが届いても普通の人は喜ばない）。同様に、YAMLやJSONの便利さや、Ruby On RailsやCakePHPの生産性の高さも一般人には全く理解できない世界だ。この意味で、インターネットとITは、ますますハイエンド化が進み、敷居が高くなっていると言える。

このように纏めると、インターネットが相反する二つの方向に走っているように思える。しかし、この「コモディティ化」と「ハイエンド化」の双方に共通しているのが、「情報へのアクセス」を実現したいという欲望である。YouTubeやはてなブックマーク、Plaggerは情報へのリーチを容易にするし、ブログやWidget、Railsは情報のアウトプットを促進する。各々、必要な情報に「アクセスしたい」「アクセスさせたい」という欲望を実現するツールやサービスである。インターネットも誕生から10年が経過し、複雑になってきたように思えるが、結局のところ「情報流通」という原点に回帰しているだけだとも言えよう。

こうした中で、ますます重要性を増すのは「Search」である。何を今更、と思う向きもあるかも知れないが、世の中にはGoogleでさえリーチできない情報が多数ある。また、Googleのサーチアルゴリズムでは不満なユーザーも沢山存在する。単に情報を収集するだけではなく、情報の海の中から必要なものを峻別し、組み合わせることで価値あるものに仕上げる能力の重要性がこれまで以上に増している。「Search」と言うよりは「Discovery & Remix」という方が正しいかもしれない。

忘れてはならないのは、「Discovery & Remix」にはユーザーのアクションが不可欠だと言うことだ。私自身も、「自分がやらねばならない（I've got to do）」ということを強く意識しつつ、これからも様々なことに取り組んでいきたいと思う。

2006年最後のMashUp、Last.Tube

今年は色々とMashUpを作って公開してきたわけですが、いよいよ大トリの登場です。…というほど派手なもんではありません。

自分の好きなアーティストは人におススメしたいもの。で、他人にそのアーティストのよさを伝えるには、音楽性云々を語るよりも曲そのものを聞いてもらうのが一番早い。さらに、音楽だけでじゃなく、クールなPVを見せられたら、もっと効果的だろう。というわけで、Last.fmの自分のページの「Weekly Top Artists」のリストをもとに、YouTubeの動画とAmazonの広告をリストアップするWidgetを作った。右側の「Last.Tube」がそれ。貼り付けたい人は下記のscriptタグを自ブログに貼り付けてほしい。なお、YouTubeとAmazonで各々検索にヒットしなかった場合は、動画・広告が表示されず、アーティスト名だけが表示される。

<script type="text/javascript" src="http://www.got2do.com/api/Last2Bplayer.php?user=[Last.fmのユーザ名]&aid=[Amazon.co.jpのアソシエイトID]"></script>
（ユーザー名、アソシエイトIDは各々自分のものに変更してください。）

早い話がこれまたアサマシで、本年「TEDDY-G脅威のテクノロジー」を駆使して様々なアサマシを提案してきた当ブログの2006年最後を飾るにふさわしいエントリである。二つ前の「映像とか音楽とかのサービスのMashUpについて、あと最近聴いてる曲」のエントリを書きながら、「ああここでJ.Valentineのアルバムへのリンクを張りたいなあ」とか思ってるうちにアイデアが発展して、突貫工事で作ったもの。最後まで突貫工事というのも実に自分らしい。Weekly Top Artists以外のデータを使ったほうがいいんじゃないか、とか、どう見てもU2B Playerの使いまわしです、とかその辺は追々調整するかもしれません。

ところでこのLast.fm、私自身は吸収されたaudioscrobblerのほうのユーザーだったのだが、audioscrobblerの「自分のお気に入りを自動的に学習する」という仕組みと、Last.fmの「新しい発見を提供する」というExperienceが結びついて非常に優れたサービスになっている。M&Aで最も難しいのは買収後の組織の融合だが、Last.fmは見事に組織を"MashUp"させてすばらしいサービスを完成させることに成功した。2007年は2.0熱も多少冷め、金を稼ぐ仕組みを持ってる人たちによる、そうじゃない人たちの買収が加速し、淘汰が進んでいくだろう。そうした中で、自分たち自身をどれだけうまく"MashUp"させられるかが、買う人にとっても、買われる人にとっても重要になるのではなかろうか。

トラフィックの推移から見る日本のインターネット

2000年末から2001年にかけてブロードバンドサービスが開始した当初、そんなに広い帯域があってもどうすんの？という意見が散見されたが、YouTubeをはじめとするビデオ系サービスの隆盛を見るにつけ、漸くブロードバンドが利活用されるようになってきた感がある。また、MashUpはサーバー間のデータ通信を促進するし、AJAXも使いようによってはクライアントとサーバー間のデータ通信を増加させる要因になり得る。こうなってくるとインターネットのトラフィックは大変なことになってんじゃないの？と思って調べてみた。

ソースは総務省の「我が国のインターネットにおけるトラヒック総量の把握」と「ブロードバンドサービス等の契約数」。但し、2004年5月のトラフィック総量だけは公表値がないので、「トラヒック総量の把握」の資料添付の「国内主要IXにおけるトラヒックの推移」をベースに推計してみた（2004年11月以降の公表値を見る限り、国内トラフィック総量が主要IXトラフィックの約4倍であることより推計）。

結果は上図の通り。インターネット契約数をユーザ数とすれば、ユーザ当たりのトラフィックは、2005年を境に飛躍的に増加していることがわかる。ちなみに、推計値だらけになるので割愛したが、2003年以前のユーザ当たりトラフィックは、2004年と殆ど変わらないレベルで推移している。2005年というとYouTubeとGoogle Videoが開始した年であり、それと時を同じくして日本のユーザの一人当たりトラフィックが増加しているというわけだ。結構雑な調査ではあるが、最初に示した仮定の通り、ここ2年ほどでユーザが求める帯域幅は一気に拡大したと言ってよいだろう。但し、ビデオ系サービスのように瞬間風速が大きなものがその要因となっているのか、MashUpやAJAXのようなデータ交換技術が要因となっているかまでは、これだけでは不明である（まあ、多分前者なんだろうけど）。

今後、ますますこういった傾向が進んでいくと、ニーズが増えてくるのがトラフィックを軽減させるサービスだ。データ配信のルーティングの効率化技術や、データのキャッシュ技術、圧縮技術、負荷分散、といった最早枯れた感のある技術が以外に注目を浴びるのかもしれない。勿論、バックボーンではそうした技術はとっくに採用されているから、今後はもっとエンド側のネットワークやLAN内での活用が促進されるだろう。ブログがLAN内で活用され始めたように、Web上のサービスと同じような仕組みが、LAN内で活用され始めることが予想されるからだ。MashUpだの集合知だの、Web2.0の裏側で以外に地味な分野が儲かるのかもしれない。

映像とか音楽とかのサービスのMashUpについて、あと最近聴いてる曲

新年の辞で2006年は映像とか音楽のコンテンツの"Remix"(MashUp)が進むぜ！とか書いたわけですが、振り返ってみると思ったより進まなかった気がします。確かにYouTubeのTrafficの伸びっぷりはすごく、Alexaのグラフ(下図)で見るとまさに「うなぎのぼり」です。でもって、YouTubeの動画を引用しつつ書くスタイルのブログも割とポピュラーになっており、YouTubeでプロモーションをする企業も現れ始めました。こうしたコンテンツのReuseは確かにひとつの方向ではありますが、一次著作物以上の良さを提供するRe"Mix"に至るにはまだもうちょっと時間がかかりそうです。弊「U2B Player」も「YouTube+Ads」もRemixと呼ぶには少し足りない感じ。この辺は、純粋にRemixが難しいのに加え、音楽や映像コンテンツにアクセスする為のInterfaceをサービス側がもうちょっと用意する必要があるのかもしれません。

さて、音楽と言えば、米国に来てから車中心の生活になりましたが、当初はiPodで音楽をガンガン聴くつもりが以外に使ってません。じゃあ、何を運転中に聴いてるかと言うとラジオ。(ミーハーな)洋楽好きの私としては、普通にラジオを聴いているだけで十分に楽しめてしまうのです。特に良く聴くのが、R&B中心の地元ラジオ局のKMELで、そこで最近割とよくかかるのが、J. Valentineの"She's worth the trouble"。何か90年代を思い出させるベッタベタの曲調に妙にハマってAmazonとかiTMSで探してみても引っかかりません。と思ったら、来年アルバム発売ですか。で、さらにググってみるとimeemで音源を公開してる人がいました。このimeem、「P2P型のSNS」ということで当初は開始したのですが、今はコンテンツをシェアするSNSみたいになってる模様。ブログに貼るプレイヤーも準備されてた為、ああ違法だ違法だ著作権法改正後には貼るだけでも有罪だ、いや聴いた時点で有罪だ、とか思いつつ下記に貼付け(いきなり再生される為、「続きを読む」以下に貼ってあります)。

さて、そもそもこの曲の曲名とアーティスト名をどうやって知ったかというと、ラジオに表示される文字情報。ぼけーっとラジオを流し聞きしてて、いい曲だなと思ったらすかさずチェックできるので、新しい曲を発見するのになかなか便利。この辺の新しい発見ができるのが、iTunes+iPodからラジオに移行(回帰?)した理由のひとつでもあります。ビジネス的には、この辺をうまくRemixできればなあ、と思います(ハードに詳しい人ならば、文字情報をうまく使って、「それPlaggerで」というところなんだろうけど)。

2006年も残りわずかだというのに、とりとめもないエントリですが、ホントはここ2年くらいインターネットのビジネスを考える際にこれまで自分が使っていたフレームワークを公開しようと思って筆を執ったのでした。たぶん全7回くらいになる上、「父さん、今更こんなものを」感も強いのでアクセスの低い年末にこっそり書くつもりでしたが、どう考えても間に合いません。というわけで、新年早々古いネタのオンパレードになる予定。

Continue reading "映像とか音楽とかのサービスのMashUpについて、あと最近聴いてる曲"

サイト内検索をするBookmarklet

インターネットには驚くほど数多の情報リソースが詰まっている。特に驚くべきことは、個人が企業サイトも顔負けの情報量を持つウェブサイトを準備していたりすることだ。特にIT系、プログラミング言語のリファレンスページなど、専門書を買うまでもないくらい充実しているサイトも多い。しかしながら、古いサイトの場合、Movable TypeやXOOPSなどのCMSを使わずにHTMLだけで構成されていたりして、検索機能が弱い場合が結構ある。そんなときに重宝するのが、言わずと知れたGoogleのサイト内検索機能(site:オプション)だ。で、いちいちGoogleに飛んでsite:hoge.comとか書くのが面倒なので、Bookmarkletにしてみた。これ。

サイト内検索
サイト内検索(ディレクトリ指定)

上の方は、実行すると検索キーワードを聞いてくるので、入れるとGoogleに飛ぶ。但し、今見ているページが存在するディレクトリを指定する形になる。下の方は、実行すると検索キーワードの前に検索するディレクトリが今のページが存在するディレクトリでいいか聞いてくるので、もうちょっと上の階層を指定したければ、そこで指定し直せばよい。

このサイトもそういった先人に倣い、できるだけ有用な情報リソースになろうとしているんだけども、結局日記と特に変わらないレベルというこの事実。しょぼん。