POLAR BEAR BLOG

「世界情報通信サミット2006」受講してきます。

またまた個人連絡です。明日は「世界情報通信サミット2006」を受講してきます。受講できるかどうかは抽選だったのですが、なんとか上の写真の通り、受講票を入手することができました。

今回の情報通信サミットのテーマは「デジタル・ワークモデル」。デジタル技術が働く環境をどう変えていくのか、どう変わっていくべきかが討論されます（多分）。キーノートスピーチには『フューチャー・オブ・ワーク』のThomas Malone教授も登場されるとのことで、こちらも楽しみ。

例によってThinkPad X41を片手に参加しますので、会場で見かけた方は、ぜひ優しく声をかけてやって下さい。

「熟練のカン」を見える化

いわゆる「団塊の世代」と呼ばれる人々が大量に定年退職してしまい、彼らの持つ暗黙知が失われてしまう危険があるという「2007年問題」。徒弟制を導入し暗黙知を暗黙知のままで若い世代に引き継がせたり、定年退職者を再雇用する制度を作るなど様々な解決法が論じられています。中でも「暗黙知を形式知化する」ことには多くの企業がチャレンジしていますが、それをサポートするソフトが開発されたというニュース：

東京電機産業 技能伝承ソフト -- 熟練の勘・経験データ化（日経産業新聞2006年2月21日第1面）

東京電機産業が開発した「バッチルポ」というソフトについての記事。製造現場における技能伝承を支援するソフトで、ベテラン社員の書く帳票を数値化し、データを分析して知識を「見える化」しようというものです。このアイデアの場合、どうやって暗黙知を数値化するのかがポイントになるわけですが、バッチルポでは次のような仕組みとなっています：

1. 材料の投入量、投入時の温度・圧力といった加工条件を帳票に記入。
2. 熟練工が現場を確認、「バルブが詰まり気味」「材料の状態：どろどろ」といった注記を書き込む。
3. 対応策を行った場合、その詳細も記入する（圧力設定や材料投入量をどう調整したか etc.）。
4. 帳票を電子化し、一連の作業結果（生産効率や品質など）に関する数値データと組み合わせる。

以上のプロセスにより、定性的な状況認識と、数値化された行動・結果が関連付けられたデータとして保管されるわけです。実際の製品を見ていないので想像でしかありませんが、例えば「材料の状態がどろどろの時、完成品の純度が最も高くなったのは、圧力設定を○○に調整した場合」といった検索も可能なのではないでしょうか。これならば「知恵」が具体的な結果として可視化されていますし、ユーザーにとっても安心して過去の例に倣うことができるようになるはずです。

また自然文で書かれる「注記」がどの程度解析されるのか分かりませんが、「どろどろ」を「どろっとしている」「粘度が高い」といった別の表現で検索できたり、「材料の状態がおかしい」「変質している」といった上位概念で検索できたりすれば、さらに知識の掘り起こしが楽になるでしょう。さらに「どろどろ」という表現、もしくはその類似表現が使われた場合、加工条件が○○であることが多いといった風に、定性的なレポートを定量的な原因分析につなげることも可能なのではないでしょうか。

「定性的な情報に、定量的なデータを可能な限り結び付けておく」という仕組みをブログに当てはめると、例えばSeeSaaのように最初からダイエット記録がつけられるようになっているブログで、「○○というキーワードが多く登場する週は、体重の減りも速かった」などといった分析ができるようになるかもしれないですね。本文記入欄以外に、フリーで様々な数値データを入力してける項目が用意されているブログ、なんてあれば様々な応用ができそうです。

「はてなコミュニティ」雑感

ブログを書きつつ「はてなブックマーク」を観察していると、ふと気付くことがあります。まず「はてなウケ」するトピックと、そうでないトピックがあること。この点については他の人も語られていますが、Polar Bear Blogの中でブックマークされた記事の傾向を見ると、

• はてなに関係したトピックである、もしくは「はてな」関係者についての記事である
• 「Web 2.0」というキーワードが入っている
• ネットコミュニティについて語った記事である
• 「○○ベスト10」など、ランキングやまとめ的な記事である
• タイトルが分かりやすい
• タイトルが刺激的

と言ったところのような気がします。個人的には、もっと注目して欲しい記事があったりするのですが・・・

次に気付くのは、「ブックマークしているユーザー数は、ある一定数を越えると急激に増加する」ということ。これは感覚的にそんな感じがしていたのですが、今日改めて「はてなブックマークでブックマークされたPolar Bear Blog内の記事」を集計してみて傾向がつかめました。ブックマークしているユーザー数が3人以上の記事を集め、ユーザー数でソートしてグラフ化してみると、次のようになります（クリックで拡大）：

青線が実数、赤線が近似曲線です。縦軸が「ブックマークしているユーザー数」、横軸は記事の累計数になります。近似曲線のR二乗値が約0.98なので、まあ有意な散布になっているのではないでしょうか。つまりブックマークしているユーザー数はランダムに決定されるのではなく、多くのユーザーに登録されればされるほど、記事は注目を集めてさらにブックマークを増やすという傾向があるということです。当たり前といえば当たり前なのですが。

Polar Bear Blogの場合、ユーザー数20人が1つの壁のようです。この壁を越えると、ブックマークしてくれるユーザーは急激に上昇しています。この「20人」というのが他のブログにも当てはまるのかどうか、ちょっと調べてみたい気がします。

もう1つ調べてみたいのは、「あの人が登録している記事だから僕も/私も登録しよう」という「ハブ」的な存在がいるかということ。これは感覚的にも存在していそうな気がしますし、MixiなどSNSの研究では、人間関係においては「ハブ」が存在することが証明されています。ただ「あの人が良いというから僕も」という心理が働くかどうか、働くとしたら「ブックマークしている人が多いから僕も」という心理とどちらが強いのか（質が重要なのか、量が重要なのか）をきちんと調べてみたら面白いように感じます。

その他にも、ブックマークしているユーザー数が増加するスピード（20人を越えたら加速度が急上昇する？）とか、コメントの有無との関係（コメント付きブックマークが多い方が登録されやすい？）とか、いろいろ仮説が立てられるような気がします。とずらずら書いてみたのですが、既にこんな調査をしている方がいらっしゃるかもしれませんね。もしご存知の方がいらっしゃったら、教えていただけると嬉しいです。

ソーシャル・サービスのユーザー階層

米Yahoo!の技術部門責任者であるBradley Horowitz氏のブログに、Flickrやdel.icio.usといったソーシャル系WEBサービス（記事中では"social media sites"と総称）のユーザー分類について、面白い解説がされています：

Creators, Synthesizers, and Consumers (Elatable)

曰く、ソーシャルメディアの利用者はクリエーター、シンセサイザー、コンシューマーの3つに分かれ、以下のような構成比率になるとのこと（記事中に掲載された図を転載）：

またYahoo! Groupsを例にとり、それぞれのユーザー種別を以下のように詳説されています：

• 1% of the user population might start a group (or a thread within a group)
• 10% of the user population might participate actively, and actually author content whether starting a thread or responding to a thread-in-progress
• 100% of the user population benefits from the activities of the above groups (lurkers)

この概念を基に、Horowitz氏は「サイトに訪れる利用者の100%をアクティブ・ユーザーにしなくても、優れた価値を生み出すことができる」と論じています。つまり1人のクリエーターと、それに反応して議論を深めるシンセサイザー達が合わせて10人いれば、合計100名のユーザーにとって価値のあるコンテンツを提供できるわけです。逆に100名がアクティブな情報発信者になってしまったら、ノイズが増えて逆にサイトの価値は下がる、とも述べています。

クリエーター/シンセサイザー/コンシューマーの構成比率についてはサイトによってバラつきがあるかもしれませんが、ソーシャル系WEBサービスが少数のコンテンツ作成者と、多数のコンテンツ利用者から構成されていることは議論の余地は無いでしょう。ここで新しい視点なのは、このユーザー構成が価値を生み出しているのだから、無理にユーザー全員にアクティブな参加を求めなくて良い、としている点だと思います。

記事でも指摘されている通り、この考え方に立てばソーシャル系WEBサービスは「投稿（コンテンツを作り出すこと）」機能を充実させるだけでなく、「閲覧（コンテンツを利用すること）」機能も充実させる必要があるということになります。つまりコンシューマーはコンテンツを「生む」ことではなく「得る」ことにサイトの価値を見出しているのだから、彼らのただ乗りを否定するのではなく、それを促進するような仕組みが無くてはならないわけです。具体的には、検索機能や分類機能の充実、ダウンロード機能の追加といったところでしょう。音楽や映像などで言えば、権利関係を明確にしておくことなども入るかもしれません。

この3層構造を意識しておくことは、ビジネスモデルの構築や収益の予測を行う際にも重要かもしれませんね。自分の提供するサービスがどのような構成比率になるかを把握することができれば、誰にいつ、どんな機能を提供して、そこからどれだけの収益を上げるかを考えることができます。そこでもし思ったように収益が上がらないことが分かった場合、自分の望ましいように構成比率を変化させる手段を考えてはならない -- クリエーターやシンセサイザーにならなくてもサイトに価値を見出してもらえるように、それぞれの層に合った価値を提供することを考えなくてはならないというのが、Horowitz氏の記事から得られるアドバイスだと思います。

二人の距離を、音楽が縮める -- ミュージック・シンクロナイザー

遠く離れた二人でも、同じ時間を共有していたい -- そんな恋人たちの小さな願いをかなえるのが、"Music Synchronizer"。このサービスにサインアップし、専用ソフトをインストールすれば、複数のPCでリアルタイムに同じ音楽ファイルを再生できます。例えば昨日ダウンロードした宇多田ヒカルの新曲を、自分のPCで再生しながら、恋人にも自宅のPCで聞いてもらう -- そんな「同じ時間、同じ音楽の共有」体験が可能に。チャット機能付きなので、気の合う仲間でチャットしながら、「DJ役」の選曲した音楽で盛り上がる -- なんて使い方もできます。

さらに注目なのは、音楽を日記にする"Music Diary"機能。Music Synchronizerを通じて再生したファイルの履歴を、専用サーバ上に保管しておくことができます。だから「去年のクリスマスに二人で聞いた曲を、今年も同じ時間に再生する」なんてロマンチックな体験が可能に。Music Diary機能は単独のPC上で再生した履歴も保管可能。履歴を集計して表示することもできますから、「今年はどんな曲をヘビーローテーションしたのかな？」なんてことも簡単に確認できちゃいます。

サービスの利用と専用ソフトは一切無料。ただしアップグレードサービスの"Music Synchronizer ++"に登録（月額525円税込）すれば、過去の再生履歴と一緒に、再生したファイル自体も保管しておくことができます。これならPCを買い換えた場合や、間違ってファイルを削除してしまった場合でも大丈夫。

あなたに新しい音楽体験を約束する"Music Synchronizer"。ベータテスト参加希望者は、こちらからメールアドレスをご登録下さい：

-----------------------------------------

というサービスを、昨日風呂に入りながら妄想していました（けど別に「遠く離れた恋人」がいるわけじゃありません）。カンの鋭い方はもうお分かりかもしれませんが、Music Synchronizerを通じて集められた音楽ファイル再生履歴データは、音楽業界関係者に高く売りつけます。それこそが裏のビジネスモデル。

既に類似のサービスがあるかないか、特に気にせず書いているので、もし「そんなのもうあるよ」とご存知の方はお知らせ下さい。お詫びして訂正いたします。

「ブログ用チャット」3bubbles続報

先日お伝えした、個々ブログ記事にチャット機能が追加できる"3bubbles"ですが（関連記事：3bubbles -- ブログ用チャット機能）、どうやら僕はベータテストのご招待はいただけなかった模様。しかしTechCrunchで実物を確認できるようになっています：

3bubbles Beta is Live (TechCrunch)

ちなみに以下が上記の記事に設けられたチャットルームのスクリーンショット（クリックで拡大）：

記事と同じページにチャット機能が埋め込まれるのではなく、別ページに遷移するようになっています。Stowe Boydの記事を読んで、ブログ記事の下部に"comments (2) | trackbacks (1) | chat (5)"みたいなイメージで表示されることを期待していたのですが、ちょっと違うようですね。

しばらくTechCrunchのチャットをROMしていたのですが、ネガティブな意見が多かったような。"3Bubbles - Why I’m Skeptical About Live Chat on Blogs"なんて記事も出てるし、前途多難か？

マクドナルドの注文処理インターフェース

ちょっと気になったので、自分用メモ。マクドナルドに寄ってきたのですが、最近はこんな風に、注文票がデジタルで表示されるのですね：

（店員さんの目の前にあるモニタに注文票がデジタル表示される。画面に見える小さな四角が1つの注文票で、処理されると画面から消え、後続の票が順に1つ前に移動する。）

ずっと前からそうだったのかもしれませんが、マクドナルドに行くのは久しぶりだったので、珍しくて思わず撮影してしまいました。多分周囲の人々は「おかしなヤツ」と思ったことでしょう。

また以前は「注文を受けたら、基本的にその注文は受けた店員が最後まで処理する（緊急の場合を除く）」というルールになっていたような気がするのですが、店員が随時画面を確認し、その場で求められている行動を取る（1つの注文を複数の店員で処理する）という形態になっていました。

もちろんちょっと観察しただけなので、これがマクドナルド全体のルールなのか、このお店（吉祥寺店）だけの仕組みなのか、僕の勘違いなのかよく分かりません（間違いがあれば指摘して下さい）。ただ僕の見る限り、画面が小さいせいか店員がモニタの前に集まって作業してしまい、混雑して作業がやりにくそうでした。また注文を受けた店員以外に品物を出されたり、会計処理をされたりすると、なぜか「間違えていないだろうか」という不信の目で店員を見てしまいます。

この仕組み、当然考え抜かれた理論に基づいてのものなのでしょうが。仕組みを考えた本人は、現場の観察をしたことがあるのでしょうか？もっと言うならば、自分でお客としてこの仕組みの前に立ったことがあるのでしょうか。余計なお世話ですが、卓上の理論だけでは細部までは見切れないなぁと、自戒の念を込めて。

3bubbles -- ブログ用チャット機能

TechCrunchでまた面白いサービスが紹介されていました。今回は"3bubbles"という、ブログ記事にチャット機能を付けることができるサービス：

Preview of 3Bubbles (TechCrunch)

左にあるのがそのロゴなのですが、3つのふきだし（bubbles）をかたどった分かりやすいマークになっています。このサービス、Stowe Boydがアドバイザリートして関わっているとのことで、Boydのブログ"/Message"にも記事が出ています：

First Glimpse: 3bubbles (/Message)

内容はごくシンプルで、簡単なコードを埋め込むだけで、ブログ記事単位でチャット機能を付け加えることができるというもの。/Messageの記事には次のような記述があります：

Imagine that next to your post's "comments (2) | trackbacks (1)" there was an additional "chat (5)" indicating that 5 people were discussing that post, right now.

コメント、トラックバックに続く、ブログ第3のコミュニケーション・メディアとして「チャット」が追加される、というイメージになっているわけです。TechCrunchはブログにチャット機能を導入することに肯定的で、Memeorandumのようなニュース・アグリゲーションサイトにも埋め込んだらどうか、と提案しています。

将来の計画では、チャット画面には広告が表示され、広告収入はブロガーとシェアされるとのこと。もしくは広告を表示させたくないユーザーは料金を払い、広告が出ても良ければ無料で使うことができる、というモデルにすることも検討しているようです。

うちのようにトラフィックが少ないサイトではあまり意味が無いかもしれませんが、人気ブログにチャット機能があったら、今までにないコミュニケーションが可能になるかもしれませんね。記事の内容をめぐって、ブロガーと読者の間でリアルタイムのディスカッションが始まるとか。またブログを中心としたコミュニティ、というものも、チャット機能があればより強化されると思います。

最近coCommentのように、ブログが持つ「会話を引き起こす」力を促進するサービスが現れてきています。3bubblesもチャットという新しい側面をもたらすことにより、ブログの会話力醸成を一段と強化させることでしょう。この流れで考えれば、自分が行ったトラックバックを一元管理する仕組みや、記事を書いたブロガー本人ではなく、読者がリンク/トラックバックを記事に埋め込むことを可能にする仕組みなど、いろいろな新サービスが考えられるのではないでしょうか。

この3bubbles、招待制ベータテストが来週から始まるとのこと。参加申し込みは公式サイトで受け付けているので、興味のある方は是非（もちろん僕は登録しました）。もし招待に落選してしまっても、/Messageに3bubblesのチャット機能が埋め込まれるそうなので、実物を確認したい方はチェックしてみて下さい。

Web 2.0とユニバーサルデザイン

梅田望夫さんの『ウェブ進化論』を読み終えました。前の記事でも書いた通り、現在と未来のWEBの姿を、独自の切り口から解説されています。新書サイズということに加え、話の進め方が論理的なので、さっと読むことができますよ。時間が無いという方も、この１冊だけは是非↓

と、梅田さんの言うところの「ネット上の自分の分身」に稼がせる仕組みを置いたところで本題。実は梅田さんの本と一緒に、ユニバーサル・デザインに関する本を買いました↓

この本を買ったのは、WEBサービスのインターフェースを考える際に参考になるのではないか？という思いからでした。もちろんWEBサイトのインターフェースを解説する本は星の数ほどあるのですが、「WEBサイト」という限られた空間ではなく、ユーザーの生活全体を念頭に置いてインターフェースをデザインすることができないか、その手助けとしてユニバーサル・デザイン（以下UD）の考え方が参考にできないか、と考えたのです（ちょっと論理が飛躍していますが）。

UDに少しだけ触れて関心したことは、それが「全ての人」に対して使ってもらうことを徹底的に追求している点です。もちろん商品であれば、必ずターゲット・ユーザーというものが存在しています。しかし「ターゲットユーザーに受けるためのデザイン」がある一方で、「実際にその商品/サービスを使うことになった人が誰であれ、全ての人が使いやすいと思わせるためのデザイン」がUD、と言えるでしょうか。

WEBの世界には、まだまだUDの考え方は取り入れられていないように感じます。特にWeb2.0系のサービスでは、ターゲットユーザー（もっぱら若者）に使ってもらうことは想定するものの、「老若男女、誰でも使える」という発想でデザインされているサービスはごく僅かなのではないでしょうか。もちろん梅田さんのような、「あちら側」と「こちら側」を結ぼうとされている人はたくさんいらっしゃいます。しかしWeb 2.0のサービスを見ると、「これがこれからのスタンダードだ、俺達に従え」と無言で威圧しているように感じることがあるのです。

「クルマを運転できない人は、電車やバスを利用すればいい」という程度の問題ならば、Web 2.0に参加する人/しない人の差は放っておいても良いでしょう。しかし問題なのは、Web 2.0の世界が圧倒的な利益を生み出しつつあるという点です。特にWeb 2.0は「集合知（Wisdom of Crowds）」を利用するサービスを次々生み出しており、知識・知恵が生み出される速度が加速度的に高まっています（ちなみに『ウェブ進化論』では「学習の高速道路化」という言葉が出てきます）。「クルマが運転できない人は、田舎に行くと苦労する」などといった苦労の何十倍もの損失を、Web 2.0に参加できない人は被ることになりかねません。

だからこそ、Web 2.0のサービスには、「誰でも参加できる、誰でも利用できる」というUDの発想を強く持っている必要があるのではないでしょうか。サービスの参加者が多くなることは、サービス自体の価値を高めることにもなるはずです。その点でWeb 2.0とUDは、非常に親和性が高いものだと思います。

デジタル・ディバイドは以前からも指摘されてきた問題ですが、Web 2.0の時代、それがさらに悪化しかねません。梅田さんはWeb 2.0の本質を「ネット上の不特定多数の人々（や企業）を、受動的なサービス享受者ではなく能動的な表現者と認めて積極的に巻き込んでいくための技術やサービス開発姿勢」と捉えていられます。であるならば「不特定多数≠デジタル技術に精通した人々」という考え方の下に、サービスが開発されていって欲しいと思います。

ダウンのお知らせ

ということで、今日は会社には来たものの、頭痛＋嘔吐でダウン。ほとんど病院のお世話になってました。

こんな時、ボタン１つで全てのコミュニケーション・ツールにダウンのお知らせを表示することができれば・・・例えばGoogle Talkに上のようなメッセージを置くだけで、Gmailは着信に対して自動返信を行い、Bloggerには「体調不良でダウン」っていうエントリが投稿されるとか。

あ、そしたらMixiとGREEはどうしよう。会社のメールアカウントもあるし。それにこんな機能が実現されてたとしても、PCからしか操作できなかったら意味がない。今朝のように病院にかかりきりになってしまったら、携帯電話からボタン１つで設定できるようになっていないと・・・。

ということで、コミュニケーション・ツールが多様化すればするほど、告知には手間がかかるという実感でした。