プログラミング 美徳の不幸

Ruby, Rails, JavaScriptなどのプログラミングまとめ、解説、備忘録。

ユーザ目線で...

帰宅途中、いま自分がやっている仕事はなんのためにやっているか、考えていました。

まず自分はいま会社から仕事をいただいているので、そういう意味で第一義的にはクライアントが望むものを、望む通りの仕様、納期で実装し、納品することだと思います。
しかしながら、もう少し考えてみるといまやっている仕事はコンシューマ向けのウェブサービスで、やはりユーザのために価値を提供し、その対価としてユーザあるいは他の第三者に対して、ウィンウィンの関係を築いてマネタイズすることが目的であることは一目瞭然です。

まあこれは、C向け事業に携わる人間ならば当然のようにわかっていることなんですが、実践するにはなんだかんだと厄介事が多い。それはどうしても作っている側はユーザではなく製作者で、製作者には製作者の事情、例えば事業計画だったりチーム内の人間関係、努力を途中でやめてしまう等があるからです。


で、最近どうもユーザ目線は口ばかりで、実態は開発者目線なのではないかという疑問が生じ、心を無にして考えていました。
私はいまアメリカ向けのグルメサイトを作っているのですが、実際のところ真にユーザ目線で考えるならば、正直yelpでいいじゃんというのが答えになると思います。いま我々は打倒yelpを標語に、SEOでyelpに勝てるコンテンツをどうやって作っていくかとか、yelpとは別の切り口のアプリを、、という発想になっているのですが、これは完全に開発者目線ではないだろうか、と感じました。

例を上げて、ユーザ目線で考えるとこういう話です。
自分はいま料理をするときはクックパッドを使っているとします。クックパッドはレシピもたくさんあって、便利な機能も豊富です。最近広告がうざいという声を聞きますが、まぁ無料でも全然使えます。
一方で、ある会社が打倒クックパッドを標語に、クックパッドとは違う切り口のレシピサービスを出しているとしましょう。例えば「誕生日 低予算」みたいなキーワードを強烈にターゲティングしているとして。
ここでじゃあ誕生日・低予算でヒットしたサイトをクックパッドの代わりに使うかというと、個人的には全く使う理由にならない。それはたぶん、誕生日・低予算に僕が何か深刻な問題を抱えているわけでもないし、仮に多少のコンテンツ需要が僕の中にあったとしても、完全にブランド化されたクックパッドを捨てて移行するほどのインパクトはないからです。

というわけで、もし乗り換えるなら僕がクックパッドに深刻な問題を抱えているときだろうと思うわけです。深刻な理由とはなにか、それがぱっと出てくるほどクックパッドは脆弱なサービスではないですが、なんらかの事情があってクックパッドが使えないとか、クックパッドに危険な要素があって、それをどうしても避ける必要があるとか、そういうことでしょう。


そういった意味で、まずyelpに本気で勝つには、yelpユーザになってyelpの深刻な問題を自分で感じ取る必要があるのかもしれません。そもそも深刻な問題がないなら、新しいサービスを作る必要はない、これがユーザ目線なのかなーと、深夜に歩きながら考えたことです。