へたれwebディレクターの覚え書き

twitter疲れ、Facebook疲れの人にお勧めしたい『threadsy』

“タイムライン疲れ”してますか？

タイムライン形式のいわゆる「ミニブログ」「リアルタイムウェブ」と呼ばれるサービスが増えています。Twitter、Facebook、アメーバなう、Mixiボイスなどがそれにあたります。

使い始めた最初のうちはフォローの数が増えてくるとうれしいですし、タイムライン（以下『TL』と表記）を追うのが楽しいですが、追うべき情報は日々増える一方。いつしか、TLを追うことが義務っぽくなってきます。Twitter疲れというやつです。 
（ここではTwitterに限らないので『タイムライン疲れ』と呼ぶことにします）

そんなタイムライン疲れな方にぜひ一度使っていただきたい『Threadsy』というサービスをご紹介します。

threadsyとは

Threadsyとは複数サービスのTLをひとまとめに表示する『フィードアグリゲータ』と呼ばれるサービスで、以下のような特徴を持っています。

Twitter、Facebook、Gmailなど、複数サービスの情報を一つのTLにまとめることができる
マルチポスト（複数サービスに動じ投稿）可能
「自分宛の情報のみのTL」「全情報がマージされたTL」の2ペイン方式（これがかなり便利）
「自分宛の情報のみのTL」は既読・未読処理対応
強力な検索機能
いいね！もリツイートも、Threadsy上で行える
もちろんプレビューも豊富。Flickr、Youtube、Twitpicなどなど複数サービスに対応。
Meebo、Facebook、AIMチャットのクライアントにもなる
日本語でレスするとたまに文字化けする（汗）

なぜThreadsyがいいのか？ほかのフィードアグリゲータの問題点

フィードアグリゲータサービスはほかにいくつか存在します。いくつか使って見ましたが、以下のような理由で使い続けるにいたりませんでした。

情報過多問題が解決していない

タイムライン疲れの理由の一つ「単純に情報が多すぎる」は、ただ情報を一つにまとめたところで解決しません。見やすくはなっても情報の量は変わっていないからです。

情報過多問題を対策するために、Twitterだけ、Facebookだけといったように表示するサービスを絞り込む機能を提供している場合もありますが、それはただ振り出しに戻っただけです。せっかく複数サービスの情報をまとめたのに、問題を解決する方法が「サービスごとに再びわける」というのではあまりに脳がありません。

価値の異なる情報を同列に扱っている

TLに表示される情報は、自分にとってすべて同じ価値ではありません。自分のつぶやきにつけられたレスやじっくり書かれた友だちの日記が、「朝だ、起きた」というつぶやきと同じ価値なはずがありません。

それでも情報が少ないうちは目で追いながら価値を選別できましたが、情報が多くなってくるとそれもかないません。

そこでThreadsy

Threadsyでは、「自分に宛てられた情報」と「すべての情報」をペイン分けして表示します。
右ペインには、すべての情報が単純に時系列で並べられます。
左ペイン（下の画面で枠囲い部分）には、Facebookでの発言に対してのコメント、自分のTwitterでのつぶやきへのリツイート、自分宛のメール、自分のFrickrの写真につけられたコメントなど、「自分に対しての誰かからのアクション（と思われるもの）」だけが抽出されます。

私は、自分宛の情報は常にチェックして、そうではない情報は寝る前になんとなく流し読む（ぜんぶ読まなくてもいい）という使い方をしています。

自分の読むべき情報が絞られるのでタイムライン疲れになりませんし、右ペインがあるおかげで「なんとなく情報が流れる」Twitter本来の楽しさを失うこともありません。

まとめ

Webから受け取る情報はこれからもどんどん増えていくでしょう。
情報をどのように整理するのか、がサービスの差別化要因になっていくと思います。
「ファインダビリティ」「情報アーキテクチャ」といった分野は重要になっていくでしょう。

Threadsyがその完成系なわけではありませんが、現時点では優れた例の一つといえます。ぜひお試しください。

「URLなどが途中で折り返しされず表示枠をはみ出てしまう」問題を解決するCSSが紹介されていたので試してみた

海外のサイトで『Wrapping Long URLs and Text Content with CSS』という、長いURLやテキストの途中でも、枠をはみ出すことなく折り返すCSSを紹介する記事を見つけたので、実際のサービスで使えるの？という視点で試してみました。

「URLなどが途中で折り返しされず表示枠をはみ出てしまう」問題とは？

ちょっと前に『Firefox3.1（3.5）では半角文字の途中でも改行できる』でも書きましたが、ブラウザによっては、記号を含まない半角文字列やURLを途中で折り返すことなく、表示枠をはみ出して表示してしまうことがあります。

対策として、文中に強制的に改行を入れたり、タグを挿入したりしているサービスもあります。しかしこれは、コードが冗長になってしまいエレガントではないという問題が発生しますし、なにより構造化言語であるhtmlの趣旨に反してしまっています。

また、を単純に一定文字数ごとに挿入することで句読点が行頭に来てしまい、可読性を損なってしまう場合もあるようです。（どうせやるなら、せめて禁則処理ぐらいすればいいのに、と思ったりもします）

個人的には「ちゃんと折り返されないのは、ブラウザがそう解釈してるんだから仕方ないじゃん」と思います。
しかし企業が提供するサービスではそうも言ってはいられず、「ユーザーの名前やIDはすべて表示しなければならない」などの厳格なレギュレーションが規定されていることがあり、対応しないといけないもののようです。

表示確認

ということで、前述のCSSが、この問題の救いの神になるのかどうか試してみました。
より実際の使い方に近い動作にするため、

preタグ以外のタグでも動作するか（今回はddタグで試しています）
文中に空白スペースが含まれている場合はどうか
日本語の場合はどうか
リンクが挿入されている場合はどうか

を各種ブラウザで確認してみました。

ブラウザで動作を確認したい場合やコードを確認したい場合はこちらをどうぞ。

safari4（mac）

Firefox3.6（mac）

Google Chrome5（mac）

IE8（win）

IE7（win）

IE6（win）

Opera10.5（mac）

Opera9.27（mac）

まとめ

結論ですが、このCSS、使ってもいいけど、別に無理に使う必要はないんじゃないの？となります。ここまで長々と書いておいてなんですが…。

表示結果を見て、最初は「すばらしい！」と思ったのですが、今回のこの表示結果って前回のword-wrapを利用したときと同じなんですよね。
ならば、word-wrapを使った方がCSSが簡潔になるので、そちらのほうが良いと思います。
（word-wrapとwhite-spaceってどう使い分けるんだろう…？折り返しルールの制御ならやはり“wrap”ってついてるほうなんでしょうか）

word-wrapプロパティに限ってはIE6も先行対応してたりします。Firefox3.0は未対応ですが、これは特に問題にならないでしょう。

ちなみに下記のようなささやかな問題もありますので、念のために書いておきますね。

半角スペースなどの特殊記号が含まれるとどうしてもそこで折り返されてしまう

“word-wrap: break-word;”を指定しなければいいのかな？と思ったが、なにも変化はなかった
しかし実際のサービスで、これが問題になることはほとんどないと思われる

IE以外のブラウザで過去のバージョンだとうまく折り返されない場合がある

しかしIE以外のブラウザを使っている人のほとんどはブラウザを最新バージョンにしているであろうし、シェアも低いので考慮しなくて良いと思われる

なにかの参考になれば幸いです。

Adobe CS5はCS4と比較して実質値上げしている気がする

単なる愚痴です。

Adobe CS5が発表されましたが、これだけ世はデフレで円高も進んだのに、実質値上げされていることに驚き、そしてがっかりしました。

私はいまだにSTUDIO-8ユーザーなのですが、これをWEB PREMIUMにアップグレードするときの価格を、CS4発表当時のそれと比較してみましょう。
（数字の端数はテキトーにカットしています）

表1・STUDIO-8からWeb PREMIUMへのアップグレード価格

発表日	アップグレード価格（US）	同（JP）	製品発表当時の円ドル為替レート	アドビジャパン内為替レート？
CS4 （2008/09/23）	$799	123,900円	$1 = 約106.1円	$1 = 約155.0円
CS5 （2010/04/12）	$799	134,400円	$1 = 約93.3円	$1 = 約167.7円

（正確な価格表は Adobeのサイトでご確認ください）

しかもCS4発売当時は、キャンペーン価格として発売から半年は92,400円でアップグレードできました。それと比較してしまうと。。。

「日本人は金払いがいいぜ！」って感じなんでしょうか。

サイトのUI検討にAIDA・AIDMAモデルが使えそうな気がしたので試してみる

マーケティングのフレームワークに「AIDAモデル」「AIDMAモデル」というのがあります。
おおざっぱに言うと、商品に気づいてから購入にいたるまでのプロセスを、

Attention（注目）
Interest（関心）
Desire（欲求）
Memory（記憶）, Motive（動機）
Action（行動）

に分けた消費行動の法則で、AIDAやAISASなども使われることもあります。（詳しくはWikipediaなどをご確認ください）

このAIDA・AIDAMAモデルがUI検討にも使えるのではないか？と思い立ち、そのやり方を考えてみます。

例として、以下のような状況に置かれたときの改善案をAIDAモデルで検討する、というのをやってみます。

あなたはファッション関連のケータイ用ブログを運営しています。そのブログは、訪問者数は多いのですが、離脱率が高いという問題を抱えています。

アクセスログを解析したところ、検索サイト経由でブログのエントリーを読んでくれた人の多くは、ほかのエントリーを見ることなく離脱していることがわかりました。
離脱率を下げるためには、ほかのエントリーに遷移するリンクをクリックしてもらうことが必要そうです。

では、訪問者に、ほかのエントリーを読むためのリンクをクリックしてもらうために、どのような工夫をすればいいでしょうか？

エントリーを読んだ人が他の記事を読むための条件をAIDAモデルで考える

クリックして欲しいリンクがある。このような状況のとき、
「リンクをもっと目立たせればいいのでは」
といった短絡的な判断になりがちです。

これをAIDAモデルを使うとどのようになるのか、こういうふうに検討していくというのはどうだろうか、というのをステップごとに記してみます。

ステップ1・AIDAに、訪問者が満たされるべき欲求を当てはめる

まずは、あるエントリーを見た訪問者が、ほかのエントリーへのリンクをクリックするために満たされなければならない欲求を、AIDAに当てはめてみました。

Attention：このブログにほかのエントリーが存在することに気づいてもらう
Interest：ほかのエントリーも、訪問者が興味のあるファッション関連のものだと思ってもらう
Desire：これまで条件にプラス、このブログのほかのエントリーが、ユーザーが期待してるレベルに達していると思ってもらう
Action：このブログのほかのエントリーへたどるためのボタン（リンク）をクリックできる状態にある

ステップ2・欲求を満たすための条件を洗い出す

欲求を当てはめることにより、欲求を満たすための条件が見えてきました。

たとえば、InterestとDesireを満たすためには、訪問者に「ほかのエントリーも読む価値がありそうだ」と思ってもらわなければならない、ということがわかります（図の条件①）。

さらに、「面白そうだ」と思ってもらっているときに、そのリンクを提供してあげる必要もありそうです（条件②）。

特に条件①は重要です。ほかのエントリーも面白そうだと思ってもらうには、「いま読んだエントリーは自分が読みたいジャンルと一致」していてかつ「いま読んだエントリーが面白いと思った」という条件が満たされていなければなりません。

しかしすべての訪問者が、この条件を満たしているとは限りません。ここで、「条件を満たしていない訪問者のことも考える必要がある」ことに気づけました。

では条件を満たしていない訪問者とはどのような状態にあり、それに対してどのような施策を打たなければならないでしょうか。

ステップ3・訪問者の状態ごとに条件を再度洗い出す

訪問者の状態のパターンを洗い出してみます。
ここでは簡略的に、「ファッションに興味があるかどうか」「いま読んだエントリーに満足したかどうか」で分けてみました。

実際のサービス検討では、「どこからこのページにたどり着いたか」「目的があって探しているのかどうか」などなどなど、もっと細分化するべきかと思います。

状態ごとに改めて欲求を満たす方法を検討することことで、さらに新たな条件が見えてきました。

一つは「状態２・ファッションに興味はあるがエントリーに不満足」の訪問者に対してDesire欲求を満たすためには、なんらかの工夫が必要であること（条件③）。

この時点で、訪問者の状態によって表示するリンク（機能）は違っていてもいいのでは、と思えてきました。単純なほかのエントリーへのリンクは、いま読んだエントリーに満足した訪問者にしかクリックする気になってくれないことがわかったからです。

訪問者の状態に適したリンクを出し分けるのが効果的であるとするなら訪問者ごとに有効なリンクを表示させるために、
「エントリーを読んだことによる訪問者満足度をなんらかの方法で把握する必要がある」
という条件を加える必要もありそうに思います。(条件④）。

（条件５は今回はパス）

ステップ4・それぞれの条件を検討

ここまでで、ほかのエントリーへのリンクをクリックしてもらうために必要な条件がいくつ洗い出せました。

ではその条件を満たすための案を検討
サンプル代わりにベタな検討案を書いておきます。

条件１の対応

「前の記事」のようなリンクではなく、エントリータイトルを表示させることにより、リンク先の記事も同じジャンルである（もしくは違うジャンルであること）をクリックする前にわからせる
記事カテゴリごとになるべく同じカテゴリーの記事を紹介する
いま読んだ記事と似ている記事を表示する

条件２の対応

適切な位置にリンクを表示させる

条件３の対応

単純な送りリンクに加え、目立つ場所に人気の記事一覧を掲載する。

その際、ブックマーク登録数を表示することで、公平な評価であるというイメージも伝える。

条件４の対応

エントリー本文を（一定以上の長さなら）分割して表示する。
1ページ目には、ほかのエントリーを読んでもらうことをあきらめてて、別のリンク（機能）を提供する

たとえば、このエントリーにたどり着いたのが検索からなら、改めて検索結果をこのブログ内に表示させ、そこに広告を表示して稼ぐ、など

2ページ目以降が表示されたなら、「いまこの訪問者はこのエントリーを面白いと思って読んでいる状態（面白いと思わなければ1ページ目で離脱しようとするはず）」と仮定し、それ用のリンクを表示させる

AIDAモデルによってたどり着いた検討結果

「訪問者の離脱率を下げる」という目的のために、「エントリーを複数ページに分割して表示する」という、一見なんの関連もなさそうな、もしかしたら逆効果と思われるようなUI案にたどり着きました。

今回は個人で試しにやってみただけなので、たどり着いた結果が正しいかどうかはわかりません。
しかしあとで大手ブログのケータイ版などを見たところ、しっかりと一つのエントリーでも分割されたページごとにリンクの出し分けがされているものがありました。
あながち荒唐無稽な策ではないようです。

まとめ：認知的ウォークスルーにも似てますね

ここまで書いていて、このやり方って「認知的ウォークスルー」に似ているな、と思いました。

違いは、認知的ウォークスルーがアクション需要に対しての供給視点で、AIDA・AIDAMAモデルはアクションへの需要視点である、と言えるかもしれません。

私自身がまだ認知的ウォークスルーもAIDA・AIDAMAモデル方式も完全に理解実践できてるわけではありませんので、今後、双方を比較しながら何度かやってみて、それぞれに合った場面を見つけたいと思っています。

ヤフーで除夜の鐘が鳴らせる

ヤフートップページの鐘が、クリックで鳴らせます。

108回鳴らすと何が起きるんでしょうか。。。

ユーザーは自分の行動をメリットだけで判断していない

せっかくサービスを作ったら閲覧だけでなく、あたりまえですが投稿などもしてもらいたいものです。

サービス上でユーザーにアクションをしてもらうために、「このアクションをしてください、するとこんな素敵な出来事が！」とメリットを伝えるのはよくあるやり方だと思います。

たとえばCGM系サービスを運営していて、「ユーザーにコメント投稿してほしいな」と思ったなら、
「あなたがコメントを投稿すると、そのコメントがほかの人に読まれ、そこからコミュニケーションが広がっていきます」
などでしょうか。

しかしユーザーは、自分がアクションするかどうを、メリットだけをみて決めているわけではないと思います。

コメントをしようと思ったときにメリットとは逆の、
「このコメントをすると、誰かに迷惑かけないだろうか？」
「自分に対してよくないことが起きないだろうか？」
ということも考えているのではないでしょうか。

アクションしてもらうために必要な「許しのデザイン」

アクションしてもらうためには、これらの不安を払拭する必要があります。そのための機能やデザインのことを僕は「許しのデザイン」と呼んでいます。

「許しのデザイン」の例として、たいして意味のないコメントを投稿しても大丈夫だよね、と思わせる工夫されているサービスを挙げてみます。

Twitterの場合

Twitterでは、投稿された発言（つぶやき）がたとえfollowの発言であっても見落として平気、という世界観がうまく構築されています。その世界観が、「邪魔なら無視されるだけだから、だからガンガン発言して大丈夫」と思うために役立っています。

Facebookの場合

たくさん発言しても迷惑にならないよう表示方法が工夫されています。
連続して発言すると、発言のうちのいくつかが、クリックしないと表示されないようになります。

また、最近追加された「ニュースフィード」では重要そうな発言を上位にピックアップして表示するようになっているようです。（まだまだ不完全ですが）

ソーシャル系サービスほど許しのデザインは重要

少し前まで、サービスは自分ひとりで使うものでした。ですからアクションに対する不安は自分に対してだけであり、最悪「まぁなにかあっても自分が困るだけだし」で解決、ということもありました。

しかしいま主流のソーシャル系サービスは人との繋がりが前提です。「他人に迷惑かけちゃうのでは」という心配が新たに発生します。

一人のアクションが多人数に影響するソーシャル系サービス全盛の時代。許しのデザインの重要性は増してきている気がします。

『Google 日本語入力』になにか釈然としないものを感じる理由

なんか納得いかないなぁ、と言うだけのエントリーです。

「Google 日本語入力」が賞賛を浴びているようですが、個人的にはなにか釈然としないものを感じています。

今回もGoogleが得意としている

なんらかの方法でデータを集め
そのデータを整理加工し
新たな価値を生み出して提供する

というサービスのように一見思えます。

しかし今回は、「このサービスはGoogleが生み出しました」と言うために必要な“新たな価値”がないように思うのです。

ネット上の文章を収集して正しい変換辞書を作るには、正しい日本語で書かれている文章がネット上に存在しているという条件があるはずです。

その正しい日本語を書くには、IMEの存在なくしては難しかったでしょう。

「Google 日本語入力」がしたことは、他社有料IMEが生成した情報を収集して、それをIMEに戻して、付加価値をつけただけのように思えます。

あくまで付加価値であり、新たな価値は生まれていないのです。これを「Googleの新サービスですよ」と言われても納得しづらいです。

なんというか、直接データを吸い出すと叱られちゃうから「インターネット」というクッションを一枚挟んでみました、ってのと何が違うの？という感じすらします。

これによって、ATOKなど、これまで地道な研究により改良を重ねてきたIMEが淘汰されてしまったとしたら、それはとても悲しいことです。

ということで、仮に「Google 日本語入力」が法に反していないとしても、私としてはやはり釈然としないのです。

ソーシャルブックマークをパーソナルナレッジデータベースとして利用できていますか？

わたしはソーシャルブックマーク（以下『SBM』）に『はてなブックマーク』を利用しています。

はてぶに登録するまでのフローはだいたい以下のようなものです。

『check*pad』に「あとで読む」リストを作成し、気になるサイトがあればブックマークレットを使って放り込む
時間ができたときに「あとで読む」リストに登録されたサイトの内容を確認。今後も役に立ちそうだと思ったらはてなブックマークに登録する
必要なときに登録したブックマークから情報を得る

このように登録するのはスムーズに問題なく行えています。
しかし登録したブックマークをイマイチ有効活用できていないような気がしています。

ブックマーク数は増えていますが、その登録した情報をパーソナルナレッジデータベースとして使い切れていない気がするのです。

はてなブックマークをパーソナルナレッジデータベースとして利用する際の問題点

はてぶをパーソナルナレッジデータベースとして利用できていない理由は、以下だと思います。

古い情報と新しい情報が一緒になってしまう

技術情報などは常に進化するので、それを残しておいてもナレッジデータベースとしての価値を汚すだけのものになる場合があります。これを整理するのは面倒です。
また、単純にソートすれば済むというわけでもありません。

SBMに登録した情報を使おうとしても、もしかしたら改めてGoogleなどで検索したほうが最新の良い情報が見つかるのではないか？と思ってしまう

結局Googleを使ってしまうのなら、SBMに登録する必要あったの？となります。

登録したブックマークから必要な情報を再取得するのが難しい

SBMに保存される情報はURL、タグ、そして数行のコメントくらいです。本文は保存されません（例外もあります）。
そのブックマークにどんな情報があったかを思い出すために、それら少ない情報から記憶を呼び起こすか、さもなくば登録した膨大なブックマークのURLを再度アクセスして探さなければなりません。
サイトの内容の一部を覚えていたとしても、それを元に検索できるわけでもありません。

webサイト外からの得た情報とマージするのが難しい

有用な情報のすべてがwebから得られるわけではありません。人から聞いた話しや街で見かけたものに情報価値があることはよくあります。
職業がweb関連以外の人ならなおさらでしょう。

今回は、これらの問題を解決しつつあるサービスをチェックしてみます。

はてなブックマークプラス

はてなブックマークは「ソーシャル」の部分がクローズアップされがちですが、今回の『はてなブックマークプラス』のリリースでは、ブックマーク自体の機能を強化することで個人のためのパーソナルナレッジデータベースとして使ってもらうことをかなり意識しているのではないかと思われます。

これによりビジネスツールとして一般企業への導入を目指しているのかもしれません（がぜんぜん違うかもしれません）。

ナレッジデータベースの視点で見ると、本文テキストの全文検索が利用できるようになったのが大きな進化だと思います。
（ちなみに全文検索機能はYahoo!ブックマークも対応しているのですが、多分利用者ですら気づいていないと思います）

また、その全文検索機能は、Googleなどの検索サイトと同時に表示できるようになりました。（firefoxのみの機能？）

欠点は有料なこと、サービス自体がとても重くなる時間帯があることでしょうか。

evernote

『evernote』はSBMではないですが、ナレッジデータベースとして利用できるのではないかと思い使ってみています。

SBMより便利な点としては、URLではなく、データ自体を保存するタイプだと言う点です。これによりサイト中の必要な部分だけの登録もできます。

また、webサイト以外の情報も可能です。今は英語だけですが、デジカメで撮影した画像を登録すると画像中のテキストを抽出して検索対象にすることも可能です。iPhoneならこのあたりの連携がよりスムーズに行えるようです。
パーソナルwikiと同じような使い方ながら、wikiより格段に便利だと思います。

とはいえこちらもパーフェクトなわけではなく、WIndows用クライアントの出来がそれほど良くないこと、１アイテムごとにコメントを記入したいができないこと、そしてなにより日本語で使えないことがネックになっています。

Googleのパーソナライズ検索

Googleのパーソナライズ検索は単に検索結果をブラッシュアップさせるためのものでなく、Google検索自体をパーソナルナレッジデータベース化させるためのものだと思います。

検索結果のページで気に入ったサイトのランクを上げることで、ブックマークに保存させることなく、ブックマークとしての役割を検索ページが果たせるようになります。

全文検索はもちろんできますし、最新のサイトも検索結果にマージされていること、なによりもSBMの検索結果と違い、適合度順にサイトを表示してくれるのは魅力です。

しかしUI的な問題があります。

検索結果からたどったサイトを見て気に入り、そのサイトのランクをアップさせようとした場合、再び検索ページに戻らなければならないのは面倒です。

また、検索結果ページを経由することなく開いたサイトのランクを上げたい場合は、そのためだけにGoogleで検索しなければなりません。

しかしこれらUIの問題は今後、GoogleツールバーやGoogleブックマークと連携して改善されるような気もします。

ソーシャルブックマークをパーソナルナレッジデータベースとして利用できていますか？：まとめ

これら3つのサービスはそれぞれアプローチ方法が違っていますが、ナレッジデータベースという視点で見ると競合になるのではないでしょうか。

どれも一長一短がありますので、しばらくこの3サービスを併用して様子を見ようと思います。

ほかにパーソナルナレッジデータベースを使いこなす方法をご存じの方がいらっしゃいましたら、教えていただけるとうれしいです。

Firefoxで一時的にFlashをoffにする方法

例によってまわりで知ってる人が少なかったのでエントリー。
もう本当にどうでもいい内容です。

たまに仕事で、Flashをインストールしていないときの動作をテストすることがあります。

テスト環境を用意するために、Flashをアンインストールしたり、Firefoxに『Flash Switcher』というアドオンをインストールする人が多いのですが、

「アドオンの設定画面で無効化すればいいだけなのに…」

といつも思うのです。

Flash Switchrはなぜだか不安定なので、こちらのほうが安全ですね。

すごくくだらない内容なのですが、でもまわりでやってる人が本当に少なかったのでエントリーしてみました。

どの機能に対応するべきかを「ユーザーの利用意向」を超えて考える

ちょっと前にとあるサイトの企画をしていて「ケータイの機能でどれに対応するか」という話をしていました。

最近はどんなサービスでもケータイ対応は必須だと思います。
しかし一口に「ケータイ対応」と言っても、メールでの投稿に投稿に対応するとか、GPSに対応するとか、そのレベルはいろいろあると思います。
使われない機能はユーザーにとっては妨げでしかないですから、確実にユーザーに使ってもらえる機能を選んで実装したいものです。

今回は、そんな機能の取捨選択について、例によって自分にできているかどうかは棚に上げて、思ったことをなんとなく書いてみます。

対応する機能・対応しない機能の判断基準

たとえばCGM系サイトを作るとします。

ケータイから投稿できるというのは必須だとして、ではケータイに数ある機能の中から、どれに対応すればいいのでしょうか。

画像の投稿に対応するか？
絵文字の投稿に対応する？
GPSによる位置情報投稿には？
デコメ投稿は？

機能に対応するかどうかを「自分が使うから or 使わないから」で判断するのは問題外だとして、陥りやすいのは、インターネット白書などの資料を取り寄せて各機能の利用率と利用意向率を見て、単純にその数字から判断してしまうことです。

たとえばGPSに対応するかどうかを判断するときのことを考えてみましょう。

『インターネット白書2007』のデータを見ると、GPS機能を使ったことのある率は16.4％、利用意向率は27.3％、逆に利用したいと思わないと答えた人は34.6％となっています。
この数字だけを見ると、「GPSを利用している人は少ないし、使いたいと思っている人も少ない」との判断になりがちです。
たしかにGPSは位置情報取得に時間がかかり、電池を大量に消費するため、使い勝手の良い機能とは言えません。ましてやそんな困難を日記に地図を貼りたい人などめったにいないので、この数字は妥当でしょう。

しかしこの判断方法が本当に正しいのか、わたしは疑問に思っています。

なぜなら、ある機能を自分が使っている姿を、いま世に存在しているサービスや自分が体験したことのあるサービスを超えて想像できる人は少ないからです。ということは、GPS機能を使うかどうか、これから使いたいかどうかの数字は、いま世に存在しているGPS対応サービスの枠の中で出されたものであり、決して来るべき近い将来の姿を予想した結果から出た数字ではない、と思うのです。

「使わない理由」を把握する

その機能は本当に使われないのか？を判断するときには、使わないと判断した理由を聞いてみることは大事だと思います。

「GPS機能はいらない」「GPS機能を使わない」という人に、そう判断した理由を聞いてみると、だいたい以下のような意見が出ました。

電池を食うから
位置取得に時間がかかり、やりたい作業の妨げとなるから
他人に自分の居場所や、いた場所を教えたいとは思わないから

こうして理由を聞いてみると、１つめと２つめの理由は「たしかに使いたくないよね」と思わされますが、でも近い将来、それこそ1年とかのスパンで解決しそうなものであることがわかります。

3つめについては、積極的にGPSが必要ないと言っているわけではないことに気づきます。

こうして理由を確認してみると、サイト制作側からの提案次第ではGPSは十分に受け入れられる可能性があるように思えます。

たとえば日記サイトなら、投稿画面にアクセスした時点で、最近撮影した画像が撮影時間と位置情報を参考にグルーピングされて投稿画面横に表示されていて、ドラッグ＆ドロップするだけで投稿可能、とかになっていると、画像付き日記の投稿がとてもしやすくなるかもしれません。
（すでにeye-fyやDoCoMoの実験サービスなどもあることから、撮影したら自動で即ネット上ストレージにアップされてて再利用可能な状態、という時代もすぐに来るでしょう）

GPSに対応することで、位置情報を貼り付けられるようになるだけでなく、UIの改善に利用できるのです。

まとめ：新しいなにかを作るために「今使われていないから」「使いたいと思っている人がいないから」を超えた判断をする

なにか新しい提案をもったサービスを作ろうとしているのなら、現時点での「この機能は使われないだろう」という判断の枠を一度リセットする必要があるように思います。

近い将来解決されそうな問題を把握し、それが解決されることを前提にアイデアを出すことで初めて、ユーザーに機能を利用するかどうか聞ける状態になるのだ、といえるかもしれません。

なぜなら実際の作ったものを（プロトタイプでもOK）触ってもらうかしない限り、一般ユーザーにその便利さは伝わらないと思われるからです。
（だからこそ新しいサービスには前もってモックアップによるプロタイピングテストの必要性があるのだと思います）

このような例はすでにいくつもあります。

ajaxのような非同期通信は最初、プッシュ技術として登場したときは「定期的に最新のニュースを配信してくれる」くらいの使い道しかありませんでした。
当時はインターネットアクセスは従量制だったため、定期的にネットにつなげられたらたまらん、ということで非同期通信はほとんど需要がありませんでした。
しかし時がたって、インターネットが高速化・定額化したときに、それはGoogleマップという実際のサービスの形になり、非同期通信の評価は変わりました。

きっとGoogleのスタッフたちは、非同期通信技術が広まる条件を把握し、それが満たされることを予測し、有効な使われ方を検討し、その準備をしていたのだと思います。

デコメも同じです。
2年前の調査では、デコメも「使わない」「使いたいと思わない」と答える人が大半でした。
しかしその後、メールで絵文字を選ぶのと同じインターフェースで使えるようになったとたん、爆発的にヒットし、今では当たり前のように利用されるようになりました。
（本来デコメとはイコールhtmlメールのことだったのですが、最近のユーザーは『オリジナル絵文字機能』と認識し、利用しているようです）

デコメを使わない理由、使いたくならない理由は「入力がめんどくさい」だったのですが、それが解決されたことで利用率、利用意向率ともあっという間に増えたのです。

ケータイに限らず、機能や技術は次々に現れますが、それがユーザーに受け入れられないと判断する前に
「なにが解決すれば使われるのか」「それが解決したらユーザーにとってどんな利便を提供できるようになるか」そして「その問題はもうすぐ解決されるのか？」
を考えるのが、新しいサービスを企画する上で必要なスキルのような気がするのです。