CalmTech -Mind Dump-

niftyによりアバウトミーというサービスが公開されています。登録ユーザがアンケートに答えていくことで、他の人がどういう傾向があるか、自分がどういう傾向があるかに気づくという内容ですが、おもしろいのはユーザ自身もアンケートを作成できて、他のユーザが答えてくれたり、コメントがついたりという点です。「今どき」のWEBサービスではありますが、これも「うまいなー」と思わせる要素があります。

サービスを構成する要素を考えてみる

まず、WEBに限らず世にあるサービス(ゲームやギャンブルも含む)を構成する要素はなんだろう？とプロジェクトメンバで話していた時に、以下の4つがあるだろうという話になりました。主に娯楽サービスが根拠となっています。

ランダム

毎回、問題や結果が変わる。次を予測しにくい。

蓄積

アクションの結果をカテゴライズしながら蓄積していける。後から蓄積結果を参照できる。

単位時間

メインのサービスを一通り利用するために要する時間。

即時性

自分が起こしたアクションに対してすぐに結果が反映される。

この4つで構成されて、かつバランスが現代の時流や生活に合っているものが成功しやすいと考えました。中でも、単位時間と即時性の関係が大事だと思われます。

アバウトミーに照らし合わせてみる

では、実際にそれぞれの要素についてアバウトミーではどうなっているかを見てみます。

ランダム

毎回アンケート(質問)が変わる。ただし、「人気の質問」といった簡単な制限を加えられる。

蓄積

これまでに答えた質問、作った質問の履歴を参照可能。また、回答数と作成数のランキングもある。蓄積された情報すべてについて、性別・年代で絞り込みを行うことが可能。

単位時間

複数の選択肢から1つを選ぶのみなので数秒。問題作成についても、選択肢にテキストをどんどん入力するだけで作れるという簡単さ。いつでも止められるが、中毒性も高く、延々と答え続けられる。

即時性

自分がアンケートを作成した直後から、すでに回答がある場合もある。(アンケート数の増加によってこの速度は落ちていくと思われる)

4つの要素を満たすのは最低条件

では4つの要素を満たせば、すべてのサービスは成功するのか？といえばそうではないと思います。少なくとも、ここまで来てスタートラインでしょう。次に考えるのは「サービスのローカライズ」です。

少なくとも、日本人向けのサービスであれば「匿名性」「帰属意識」という要素が必須となると思います。根拠を話せば長くなりますが、実例は枚挙にいとまがありません。(匿名掲示板、SNS・・・etc)
ですが、これを考えてもまだブレークスルーとなるサービスにたどりつけるかどうかは別問題です。ここからは、やはり人間行動を分析して分析して・・・という積み重ねによって生まれた視点が決め手となると思います。

少なくとも、アバウトミーの場合は日本人の帰属意識という本質をうまくついていると思います。また、アンケート作成後にすぐレスポンスがあるという即時性は落ちていくと述べましたが、アンケートの多様化によってカバーされていくと思います。「企業からのアンケート」「アンケート作成者のアイドル化」「特定分野アンケートの増加」・・・ひらたく言えば、ニコニコ動画と同じ道でしょう。そこでどういった想定外の効果が生まれるか楽しみでもあります。

ここ最近は、技術的な話から普遍的真理や人間の行動を分析する機会が多くなってきました。だから、新しい人と会うのが、人と話すのが楽しいのかもしれません。というわけで宣伝ではありませんが、話を変えます。

IWDDミーティング #23に参加します。かつ第3部のプレゼンテータまでやることになりました。テーマはオープンUI設計をしてみるです。先日のバブルマップアプリについて、基本的な構想はできてきました。ここらで、その内容を共有して参加者でUI設計してしまおうかなと目論んでいます。
発表ネタになって、かつ様々な人のフィードバックをその場で受けれてと一石二鳥かなと。今から楽しみです。

いつの間にかRuby on Rails 2.1がリリースされていました。
これは試さねばと、gem update rails -yと実行するとrails 2.1.0がお目見え。とりあえず、他のリリースノートを見ていくと、named_scopeという新機能。・・・こ、これは！

さようならbuild_condition

私の場合、これまでは検索条件は各コントローラでbuild_conditionというメソッドを用意し、そこで管理するという実装ポリシーでした。例えばこんな感じ。

def build_condition
    conditions = Array.new
    if (params['price'] && params['price'] != ”)
        conditions << “products.price < ‘#{params['price']}’”
    end
    conditions.join(’ and ‘)
end

まぁ、複数条件を指定したい場合や、修正箇所を1か所にできるなどを考えて、美しくないと思いながらもこのような実装をしていました。このコードは例えば任意の価格未満の商品を探すといったものです。
しかし、実際は10,000円未満の商品は？といった探し方、つまり価格帯で探すのが、世のオンラインショッピングにおけるUIパターンの基本です。

10,000円未満の商品が欲しい

この要望をnamed_scopeによって実現します。まずは、model/product.rb

named_scope :below_10000, :conditions => ["products.price < 10000"]

#controllers/products_controller.rbでの呼び出し
@products = Product.below_10000

商品名でキーワード検索したい

named_scope :by_keyword, lambda {|*args|
    {:conditions => ["products.name like ?", '%' + args.first + '%']}}

#controllers/products_controller.rbでの呼び出し
@products = Product.by_keyword(”Rails”)

デフォルトの並びは商品の新着順にしておきたい

named_scope :order_default, :order => "products.created_at desc"

#controllers/products_controller.rbでの呼び出し
@products = Product.order_default

10,000円未満の商品を新着順に並べたい

@products = Product.below_10000.order_default

す、スマートすぎる・・・MVCアーキテクチャにおいて、知りあい関係をどう分担するかが肝となりますが、RailsにおけるModelはO/RマッピングにおけるEntityつまりDB上の1テーブルに対する実態とDAOの基本機能という存在でした。
結局のところ、検索・登録・更新・削除といった基本メソッドをもったところで、サービスの中心である「検索条件」という点についてはコントローラ側の役割と私は解釈していました。

しかし、これでControllerの役割であるユーザ入力からModelへのデータ引き渡しという本来の姿により近くなることができました。Modelの役割が増えたと考えるか、DAOとしての機能がModelに収まるので分業化が楽と考えるかはMVCアーキテクチャに対する解釈によりけりでしょうね。
ただ、実装側からすれば、より直観的な方法で実装できる分、嬉しいですね。

#2008/06/06　追記
orderに関する記述とconditionsに関する記述の順番が入れ替わっても平気だった

@products = Product.order_default.below_10000

ここはLinqより頭いいです。素晴らしい。

#2008/06/08　追記
:includeと:conditionsが併用できました。申し分ありません。

named_scope :by_genre, lambda {|*args|
    {:include => [:genres], :conditions => ["genres.uri = ?", args.first]}}

ほぼ完全にSQLをcontrollerに記述しなくてよいです。modelはDAOとvalidationがメインということで大分すっきりしました。

ブログ立ち上げからしばらくたちましたが云々「怠け」という言葉で片付けます。

さて、セルフプロトタイピングしながらブログデザインを考えて行きます。とにもかくにも何を発信したいのか、コンテンツを決めない事には始まりません。自分がクライアント役にもなるというのは、なかなか新鮮ですが難しいものです。まずは動的コンテンツと静的コンテンツで分類していきます。

動的コンテンツ(エントリ増加など可変のもの)

ブログ

身の回りの出来事や既存サービス、概念への考察がメイン

勉強会やセミナーのレポートなど(既にWDHAについて公開済み)

開発実績

開発実績(WEBサイトなど)の一覧と詳細

サイトのサムネイル、クライアント、要素技術も併せて

開発において取り組んだ事や工程について詳細のところで見せる

自主制作

自分で作ったプログラムなどの公開

今は特に出せるものはほとんどない

WEBサービスの場合は専用サイトにしてしまう？要検討

静的コンテンツ

プロフィール

活動内容や経歴などを簡単に

アクセス解析の結果、Aboutのデフォルトリンクをクリックするユーザが多かったため、ニーズはある

問い合わせ

直接の問い合わせではなく、ダウンロードコンテンツの前にはさむアンケートをメイン

フォームを自動生成する自前のJavascriptライブラリがあるので、そのテストもかねる

問い合わせはコンテンツとくくりだすほどのものではありませんが、PDFでの資料公開やらをしようとしたときに、抱き合わせで必須となるものなので、一応は静的コンテンツに加えます。

さらに、ここからそれぞれのコンテンツにどういった性質があるかを考えます。私の場合、ここで表示形式も一緒に考えます。よく使う言い方として以下のように定義しています。

• list - エクセルの表のような連続した行での表示 テキストメイン
• tile- 画像メインでサムネイル一覧でよく使われる表示形式
• show - いわゆる詳細画面(大きい画像やデータ詳細など)

まずメインであるブログですが、これはいきなり特殊な形式です。人によっては、「続きを読む」といったリンクを用意して、途中までかサマリをlistで表示するパターンが多いようです。
ですが、ブログの「時系列での記録」「トップに常に最新」というデファクトの性質を考えると、showでトップに最新１件のみを表示して、その代わりに過去のエントリへの導線を用意すれば十分と考えます。

そもそも、アクセス解析を見てもブログ立ち上げの頃は他リンクを押す人が多かったようなのですが、日が経つにつれて、ブックマークから見る人の割合が増えていました。加えて、直帰率が高いです。これは、ブログ全般に言える事だと思うのですが、トップに最新があるとわかっているのですから、初見か他へ誘導するリンクがない限りは、トップの記事を見て帰る・・・というのは自然だと思います。

ああ、頭の中ではすぐの事を文章で書くとこんなにも・・・まさにdump状態ですね。
まずはここまでにしたいと思います。次回ではアーカイブの性質を考えてみたいと思います。時系列で記録したブログをたどる場合の導線として、月別やカテゴリ別がありますが、そういった類いのものの是非と、自分のブログで用意すべきアーカイブ形式を考えたいと思います。

バブルマップといえば、Lifehack.orgでも紹介されたTODO管理の方法です。ストレスの度合をバブルで表現するというユニークな手法で、マインドマップを元に考案されたようです。私自身、マインドマップ自体は社員教育の一環で5～6年ほど前に勉強して、実際にプロジェクトやミーティングで使用していました。

おもしろそうだと思い、実際にバブルマップを実践してみたところ、進捗を表すため部分的に消したり、TODOを消化して一気に消したりすると、落ちものパズルゲームで一気にブロックを消した時のような爽快感があって非常におもしろいです。このバブルを消すのが趣味になりそうな楽しさがあります。

バブルマップを分析してみる

手書きでやりだすと、課題も見えてきました。バブルマップはストレスを大きさという軸で表現することと、部分削除で進捗を表す方法でガントチャート的な意味合いを持たせることに成功しています。
ですが、手書きの場合ではアラートがないんですよね。つまり、「今日のTODO」というとらえ方をするのであれば、今日中に終わっているかどうかという時間の軸があるともっといいのだろうなと思いました。

おさらいします。バブルマップを構成する軸は以下のとおりです。

• ストレス
• 達成度(進捗)
• 時間 < 個人的に追加したい軸

時間という軸は、常時監視して何かの動きを持たせること - つまりタイマーの役割が必要ですが人間には無理です。せめて、思い出した時に時間の経過が一目でわかればましかなと思います。

バブルマップアプリの仕様を考えてみる

こうなると話は想像できると思いますが、アプリケーションにしてしまえばいいわけですね。タイマーの役割をプログラムにさせるのが適材適所でしょう。また、こういった常時監視で、TODO消化というトリガーごとに確認するとなると、ウィジェットがいいと思います。贅沢をいえば、世のTODO管理プログラムとかスケジューラと連動させたいですね。

私だと以下のようなイメージで考えてみました。

• 1日の就業時間を決めておく(デフォルトは9:00 - 18:00？)
• 何もないところでマウス左ボタンを押し続けるとバブルが出現(上にふわふわ浮きだす)
• ボタンを押した長さでバブルの大きさ(ストレス)が決まる
• バブルをダブルクリックして内容と心の優先度を入力
• 時間経過とともにバブルが下に落ちていく
• TODOが進んだ場合は、バブルをダブルクリックして、スライドで消化率を設定
• 消化率が増加するとバブルが円グラフのように塗りつぶされる(大きさ収縮がいいか？)
• TODOを達成した場合はバブル上でcommand + クリックなどの特殊入力ででバブルがパン！と破裂
• バブルの大きさが小さいほど、優先度が低いほど、落下速度は速くなる(明日に持ち越してもいい場合が多い)
• 就業時間内に終わらなかった(地面に落ちた)バブルは下で固形化する
• 「翌日に持ち越す」を実行すると、残ったTODOが全てバブル化してまた上に浮上(消化率などは維持)

ざっとこんなところでしょうか。誰か作ってくれないかなー・・・と思ったら自分で作れってことでしょうね。

母から聞いた話ですが、モスバーガーでは電話注文すると、受け取りの際に専用の袋に入れて「10円」を渡すサービスがあるそうです。私は今日までそれを知らなかったのですが、その心配りに非常に感動しました。

モスバーガーは注文を受けてから調理をするので、ある程度の待ち時間が発生します。その時間を惜しんで、あらかじめ電話注文して指定した時間に取りに行くというユーザの工夫についてまで考慮しているわけですね。
個人的な感覚では、注文や問い合わせの電話は、発信者側が負担する経費であると思っていますし、よくあるパターンではフリーダイアルを用意すればいいことだろうと考えるところです。

つまり、発想の転換というところでしょうか。電話注文をしておくというのは、待ち時間が長いというマイナス要因に対するユーザの声であると言えます。その声に対して専用の袋まで用意して10円を渡すという行為は、プラスへの変換が巧みだと思いました。

注文の通話時間が長引いたら、もっと金額が増えるのか？といった野暮な発想は置いておきますが、自分で仕方ないと思っている小さな不満に、ささやかであっても「見過ごしてはいませんよ」というメッセージは人の隠れた欲求を満たすことになると思います。また、手渡しである直接のコミュニケーションによって、人間同士のふれあいの重要さまでを再確認させられます。それで電話注文するリピーターになったら、まさにモスバーガーの思うツボですね。すごくいい気分の「してやられた感」です。

これで何かできるのではないか？と、何か頭の中でつながるものがあったのですが、まだ具体的にはなっていません。もう少し、掘り下げが必要です。
少なくとも、新しいサービスというよりは、既存のサービスでかゆいところに手をとどかせるためのサービスだと思います。こういったサービスは新規顧客というより、リピーターの増加に貢献するでしょう。もしくは、すでに存在はしっていても、踏み切れていない2次的(潜在的？)新規顧客の層に「口コミ」として広がるタイプのサービスかと思います。

長谷川恭久さんのエントリが興味深かったので、自分なりに掘り下げてみようと思います。先のエントリは、まず自分から何かしなくては。行動がたりない。と危機感をもった内容でした。何かって、何だろ？と思ったので、自分なりの回答というか自論を展開したいと思います。

個人的には、「新たな発想は異業種との交流から生まれる」という結論を今は持っています。

WEBの変遷に最初から携わっていたわけではありませんが、思うにWEBの存在意義は、異業種の参入によって変化していったと思います。しかし現状を振り返ってみると、中身のすげ替えだけのサービスの氾濫、DHTMLとAjaxの混同、ハイパーリンクの解釈違い、パソコン通信への先祖返りと、あげたらキリがありませんが、WEBという媒体にどうしようもなく閉塞感を感じることがあります。いうなれば、WEBという媒体への囚われです。

なぜそうなってしまったのでしょうか？異業種との交流という切り口から考えてみました。
私が思うに、業界をけん引するトップランナーによく見られる共通点は、異業種の出身であることだと思います。専門家としての実績の背景には、必ずと言っていいほど、それ以前の異業種での体験が生きています。その体験を新たに飛び込んだ世界で応用することで、パラダイムシフトが起きる、もしくはその足掛かりとなってきたと考えています。

逆に言うと、今は異業種の体験、発想を使いきったがために閉塞感が生まれているのでしょう。また、1つの業種に長く従事すれば、その業種が持つ本質はいやでも見えてきます。実績を積み、技術も習得し、仲間もできてきます。しかし、そこまで辿り着いた人同士で・・・つまり内輪で本業の情報を回しあっても「同意」しか出てこなくなる時がきます。

その時が、異業種と話すタイミングだと思います。とはいえ異業種なら誰でもいいわけではなく、異業種側のトップランナーが理想でしょう。よく、2割8割の法則といわれますが、組織をけん引するのは2割の人間だとか、2割の顧客の売り上げが全体の8割を占めるとかいう法則です。

8割の人間を軽視しているようで嫌なのですが、まったくの嘘ではないとも思います。達人は達人を知るというか、類は友を呼ぶというか、よくわかりませんが人は同じような背景をもった人と自然と集まるという経験則があります。ここでの背景は「異業種の出身である」を指します。同業種で職種が違うのもありですね。もっと敷居を下げるなら、自分と異なる体験についての話を求めることでしょうか。

最後に、乱暴なまとめをして終わりにします。
WEBしか知らないWEB屋はどこかで詰まると思います。
1つしか言語を知らないプログラマがそうですから。

#今日の寄り道
・iWork08届いた。新しいおもちゃ。

その1はこちら

前回はその1ということで、自分が担当した第1部についてでした。今回は第2部についてです。
第2部は「サイト考察的WEBマーケティング術」というテーマでした。

要約としては、WEBサイト製作プロセスにマーケティングの世界では基本とされている法則を取り入れて、サイトコンセプト設定や企画・設計の足掛かりとするという内容です。また、サイトパターンをカテゴライズして、それぞれについて考慮すべきポイントを具体的にあげていました。

個人的には「ABC分析」しか単語を知らなかったのですが・・・それはそれとして、「50の質問」というのもおもしろかったですね。マーケティングを通じて、あなたはどういう仕事のしかたをしていますか？という自己分析を勧める内容が興味深いところでした。他に個人的になるほどと思ったのは、

1. マーケティングの法則は「公理」である
2. 各法則の内容はシステム設計の考慮すべきことと本質は一緒

1.について話を伺ったのですが、マーケティングの世界は、統計学などを利用して導き出された法則なのだろうと思っていたら、天下り的に「そういうもんだ」と言われている法則が多いのだそうです。そもそも、提唱者がそういうアプローチで広めているのだとか。

システム設計者のアプローチは「定理」というか、要件という各条件から毎回のように結論を導き出すことが仕事のひとつだと思っているので、経験則的に裏付けをとれる、結論を予測できるというのならまだしも・・・なんで？と思った場合には後付けで根拠をとっていくのですかね。勉強不足です。

2.は自分の解釈だとデザインパターンとしての存在価値があると思いました。
自分たちが設計するときに考えていることを、「マーケティング」という切り口で進めると、こういう言葉で説明するんだなと。

各マーケティングの法則は、結局はユーザビリティやページフロー、視線誘導まで落とし込むための足掛かりであって、それに法則という形で呼び名があれば、クライアントへの説明の材料となり、製作指針として容易に共有できると思います。共通ラベルがあるというのは、意思疎通をはかるには確かに便利ですし。

マーケティングそのものというより、自分の中に体系だってある、システム設計における原理や経験則をマーケティングという考え方とマッピングさせれば、また新しい結論やアイディアが生まれそうなので興味が持てました。どういう本がいいんでしょうね？最初の1冊って大事です。

そんなこんなで、WDHAは無事に終わりました。渾身会(このネーミング好きです)では、WDHAの今後の方向性や、見積もりの考え方といった具体的な話まで出たり、楽しいものでした。
WDHAはもともと、岩手で毎月第2土曜に開催されている、IWDDに倣う形で始まったそうで。今度はそちらにも行ってみたい・・・発表したいネタはまだまだあるので、今後もWDHA盛り上げていきたいところです。

その1はこちら

WDHAレギュラーミーティング#003が無事に終了しました。

第1部を私が担当し、第2部はdct-designの蝦名さんが担当されました。
私のテーマは「実学 現場のワークフロー」ということで、いわゆるクライアントとデザイナ、プログラマとデザイナが製作過程において、すれ違う理由というところにフォーカスをあてつつ話させてもらいました。

座談会のように気軽な意見交換を目指したのですが、私の進行が走ってしまったがために・・・。次回に課題を残しつつも、現場の生の声を引き出すという目論見は達成できたので、その中で出たトピックを1つ上げます。

• デザイナとプログラマの役割はどこで線引きをするのか？

デザイナとプログラマの分業を進めるためにも、ペーパープロトタイピングなどを利用して情報共有を視覚化していく方がいいという意見を出したところ、上記のような質問が出ました。
質問された方は、元々コーダとしてスタートし、実装からのアプローチをしていくので、チームで製作する場合に営業やデザイナとの擦れ違い、イメージのずれが発生しがちだとのこと。

私はプログラマの立場からでしたが、線引きはないと話しました。
分業化が当然になっている現状と矛盾すると思うかもしれませんが、あくまで得意分野を生かすように分担するのであって、責任範囲を狭める意味ではないと考えています。
プログラマという立場であっても、あくまで要件を、ユーザの欲求を満たすサービスを実現するためですから、レイアウトだけでなく、配色から何から、ありとあらゆる要素に口を出しますし、一緒に考えますよ。自分たちの得意分野から解決策を提示していきますよ。というのが私にとっての分業です。

私の場合、案件の区切りがあるごとに反省会を行ったり、クライアントとの打ち合わせ後は、作業的な話だけでなく、クライアントがどういう方だったか、それを踏まえて今後の出方を話し合うのが当たり前になっています。それに対し、質問された方は、作業に関する事務的なやり取りが中心になっているとか。

詰まる所、技術力はどれほど高くとも、日頃から情報共有をする土台、率直に意見交換できる信頼関係に基づいたコミュニケーションなくしては、製作は立ち行かなくなる。ということなのでしょう。
「デザインする」というと、ユーザに対してどのように情報を伝えるか？という外的な視点で考えがちになりますが、ワークフローという視点から考えれば、クライアントと製作側、または製作者の間といった内的な視点で、コミュニケーション方法、製作プロセスのデザインを同時に考えていくことも更に必要になると思いました。

その2へ続く

先ほど帰ってきました。パソコンスクールの講師をさせてもらってるのですが、肉体労働と言っても過言ではないですね・・・人にものを教えるレベルではないと思ってますが、教えることで学ばせてもらってます。

さて、明日はWDHA レギュラーミーティング #003にいってきます。
私は第1部で発表する側なのですが、テーマは「実学 現場のワークフロー」。

最初はSVNをWEBデザイナーも使いましょうといったテーマになる予定でしたが、途中で気が変わりまして。
「SVN導入する前にできることあるでしょ？」と思い、変更しました。

CSS-Nite in AOMORIに参加して、ビジネスアーキテクツの森田雄さんに、日頃の思ってることをありったけぶつけさせてもらって、色々と自分の中で確信をもつこともありました。(すべての質問に余すことなく、本音で答えてもらって、とてもためになりましたし、楽しかったです。ありがとうございます。)
何で作るとかWEB標準とかの前に、クライアント相手に、もしくはデザイナ同士が、何を考え遂行すべきなのか？を考えていくと、ワークフローの未成熟さの改善が先だ。と結論が出ました。
かといって、抽象論からいきなり入っても、参加者の求める内容やバックグラウンドはまちまちなので、今までの実体験をベースにした座談会形式で「あれは大変だったよなー」といった雰囲気で意見交換したいと思います。
重い話を明るく話すって大事だと思うんですよね。

で、上記のテーマです。WDHAのサイトでも、ここでも資料やフィードバックは公開していくつもりです。
というかすでに準備してあります。

#今日の寄り道
keynote買うことにした（今更。keynoteプロトタイピングってどうなんだろ？

メインはWindowsだけど、今日はMacBookでマウスなしでどこまで使えるか試してみた。ストレスが思うほどなかった。マウスなしでストレスがここまで少ないUI設計は素晴らしい・・・。
2本指タッチで縦スクロールをトラックパッドのデファクトにして欲しい。あと、マイティマウスで1ボタンやめたのだから、トラックパッドも1ボタンじゃなくすれば、もっと使いやすいのにと思う。
あと、Exposeのショートカットは、あ、ちゃんと記事にしよう。

脳内で世をにぎわすサービスについて、あれこれ考察するのが趣味のひとつみたいなものなのですが、ここ数年で「これはやられた！」と思ったサービスのひとつとして、「ニコニコ動画」があります。

ニコニコ動画とは何か？についてはGoogle先生に聞いていただくとして、あのサービスが盛り上がる要因の切り口として、「参加しているユーザを分類」というアプローチを取ってみます。今更ですけど。

手書きしてたのをスキャンしたのですが、改めて自分の字と絵の下手さに萎えてます。
気を取り直して。ユーザを3つに分けて考えてみました。

• ヘビー(発信)：動画を自分で製作し、直接コンテンツ増強に貢献している人
• ミドル(編集)：動画にコメントを投稿したり、タグをつけることで半直接コンテンツ充実に貢献している人
• ライト(閲覧)：動画の視聴のみだが、再生数のランキング向上などで間接的にコンテンツ充実に貢献している人

さらに、ヘビー、ミドル、ライトの相関関係を簡単にまとめると

• ヘビーの動画投稿でミドルやライトに対する人集めの効果
• ミドルによるコメントやタグ管理でコンテンツ自体に想定外の付加価値
• ライトによる再生数増加がランキング向上をもたらし、ヘビーとミドルのモチベーションアップ

このサイクルが成熟すれば、あとは勝手にコンテンツが増え、盛り上がり、口コミ効果（自分のブログでの紹介や、ニュースサイトでの取り上げ)という理想的なスパイラルへ・・・といったところでしょうか。

ここまでくれば、後は運営がサービスの横展開(市場、着メロなど)を加えれば、スパイラルの数が増えるだけでなく、それぞれのスパイラル自体も大きくなっていくと、まぁ、よくできてるなと本当に思います。儲かっているかとは別として、「人が楽しむ」という点では今後も楽しみです。

あとは、日本人が好む「WEBにおける匿名性」という点、動画投稿者に対して「うｐ主」という共通の呼称(愛称？)をつけて、偶像化というかアイドル化する性質などが、絶妙に相互作用しているなと思う次第です。

自分なりにまとめると、サービスというか、ソフトウェアの本質をつかんだ結果だと思います。

人の動きや感情に合わせて、形を変えていく。

これは、人の特性、この場合は日本人の特性を研究してきた人のなせる技だと思います。たぶん、最初から研究しようと思って生きている人は少ないと思いますけど、人の特性を「おもしろい」と思ったり、「なんで？」といつも思っている人でないと、こうはいかないだろうと思います。

日頃の何気ない動作や習慣すべてがサービスの源と再認識させられますね。マンウォッチングを趣味とする人は、総じて新しいサービスを生み出すチャンスを持っているのかもしれません。

なんか、堅苦しい文章になってしまいましたね。でも、実際は雑談というか、酒飲んだり、飯くったりしながら話したことばっかりですけどね。脳内ダンプのタイトルどおり、つらつらと書いてみました。

#今日の寄り道
ブログのカテゴリをざっくり4つに分類してみた。根拠については、ペーパープロトの公開とあわせる予定。
あと、WordPressの基本設定まわりをちょこちょこといじって、ルートアクセス時にブログ表示という形に。
mod_rewriteのルールをコピペしてね！ってどうかと思うんですが代替策はまだなく。

Inflame Casting #94まで聞いてる途中。そろそろ感想まとめと聞きなおしかな・・・

DropClockを使ってみた。色々と思うところはあるけど、それは後日。
でも、こういうの嫌いじゃない。