よく、製品開発には、ユーザの意見を聞くのがとても大切だ！ユーザの意見を聞け！とよく言われる。
でも、実際にやると、いろいろな事情が入り組んできて、とても奥が深く、難しくて、訓練が必要だと思う。そこで、ああでもないこうでもないと普段考えている事を書いてみたい。
ちなみに、僕のアプリのユーザはこの記事を読むとフィードバックのパンチ力が弱まって遠慮しちゃう可能性もあるので、読まないで欲しい。もしくは、これ読んでも遠慮しないで欲しい。
NOと言うのが精神的につらい
この前見た動画で、アップルのアイブさんがこんな事を言っていた。
「僕たちは素晴らしいアイデアに数えきれないほどNOと言ってきて、その却下したアイデアの数こそを誇りに思っている。」
これはアプリ開発では大切な事だと思っていて、そもそも、提案される機能やアイデアの一つ一つは合理的で納得のいくものばかり。
ただ、すべての素晴らしいアイデアを採用すると、いつの間にか誰も使わない複雑怪奇なゴチャゴチャしたアプリになってしまう。
なので、製品の軸を定めて、重要な部分を守るために何を捨てるかを常に意識しないといけない。
ここまでは、よく言われている事なので、大前提として話を進めるとします。
ただですね、これ頭ではわかっていたとしても、実際に機能要求とか、こうしてほしい！というフィードバック来た時にどう返事するか、これはあまり語られていない気がする。
「Yesというのは楽だ、でもNoというのはしんどい。」
と37signalsの本でも書いてた。
僕のイメージでのアメリカ人はNoと言える人種なので、そんな強い精神力を持ったアメリカ人でさえ辛いなら、NOと言えない日本人には大変な事ではないかと。
だって、99のアイデアにNoと言うのがデフォなんだから、強心臓を持つ日本人じゃないと、これ、きついんじゃないですか。
どう返事すればいいのか
じゃあ、どうNoと言えばいいのか。
せっかく貴重な時間を使い、フィードバックをしてくれているありがたいユーザにたいして、何と返事すればよいか。
悩みますね。
例えば、「Aという機能を追加してほしい！」という要求が来た時、自分の考えでは、Aという機能は確かに便利だけど、これを追加するとアプリが複雑化するからYesと即答できないとする。
この時、「これは便利だけど、ほとんどの人には不要だから付けられない。」と答えたとする。
しかし、この、ほとんどのユーザっていうのは、統計データを出さないとわからない。要望したユーザからすると、自分は標準だと普通思うから、これは納得できない。
ちなみに、統計データは説得力があるけど、データだけでUIや製品開発の軸を決めるのは落とし穴にハマる可能性もある。
出来る事なら、「将来的にやります！」とか、言いたい。しかし、自分がユーザだったら、「予定にあるって言ってたのにいつやるんだよ、イライラ」となるし、待たされるのはきつい。
さらに、予定に入っていても、計画変更する事は日常茶飯事の製品開発で、約束するのは一番よくないと思う。
もう、これは答えがないのだけど、37signalsのgetting realでは、基本的には「検討します」と言えと書いていた。また、ちゃんと事情を説明すると大抵のユーザはわかってくれるとも。
検討します。。なんか、「善処します」っていう政治家を中学生の頃にみんなでディスっていたけど、若干気持ちがわかる。
僕も、考えてみますね、とか、検討してみますね、とかをよく使うけど、これは、採用するつもりのアイデアも、大抵こういう感じで、あまり約束はしないようにしている。
なぜかというと、それはやらないと思いますって言っても、ころっと考えが変わる時もよくあるし、それは次のアップデートで採用しますって言っても、やっぱやらないってなる時もあるからだ。
でも、決まり文句のようにこんな返事していても失礼なので、出来る限り気をつけているのが、どういう理由で要望をしているのかを、出来るだけ聞くということです。
理由を聞く
なにか要望があれば、なぜそういう要望しているのか、裏の意図を誤解しないように聞くのが重要だと思う。
よく、「Why」を繰り返せとか、言われてますね。Whyを繰り返すと、機能要求の裏にある、ユーザの本当のニーズが分かると。
でも、これ口で言うのは簡単だけど、リアルワールドはそう簡単ではない。
「なんで？なんで?」とか繰り返されたら、もう要望してる側からすると、疲れちゃうじゃないですか。
なので、出来る限り、「その要望はこうこう、こういう理由ですかね？」といった感じで、ある程度想像できる部分は自分で補って確認する形がいいかもしれない。
まあ、バグ報告とかだと理由聞かなくてもいい場合もある。
ただ、表面上の機能要求だけを聞いていると、開発側の勘違いで、あさっての方向にアップデートしてしまう危険性が。
まあ、いろいろ理由を聞いていると、感情移入してきて頭の中にストックされるから、将来的にきた要望を採用する可能性が高まるのは間違いない。
僕は使ってていいなと思うサービスは積極的に要望を言うようにしてます。
最近のWebサービスは気軽にフィードバックできる仕掛けがあるし、すぐ返事くるし、やっぱ本場のスタートアップは進んでいるなと感じる。
Twitterエゴサーチで返信するか
ここも、判断が難しい。
Twitterで自分のアプリ名を検索した時に、アプリの感想を書いてくれている人がいたとします。
例えば、「ああ、○○○というアプリは、ここがクソだな。こうしたほうがいいのに。」とか。
この時、開発者とか、アプリのアカウントに直接メンションきたら、もちろん返事するけど、ただのつぶやきの時は返信するべきか悩む。
返信した場合、「おお、作者から返信が来た。嬉しい。」となって喜んでもらえる可能性もあるし、「え、こんな常に見られている感じがすると、これから正直な感想呟きにくいな。」となる場合も。
フィードバックというのは、アプリ開発の事情とかを無視して、好きな事を自分の好みで言ってくれるのが一番参考になるわけです。
返信するともっと言ってくれる人か、返信すると、次から遠慮してのびのびと感想を呟いてくれなくなるか。
ここは、つぶやきの内容や、状況にもよるけど、ケースバイケースで判断が難しいところだと思ってる。
優先順位が。。
さて、ここまで、ある意味スタンダードな部分を書いてきたけど、リアルワールドでは、「シンプルさを守るために、うんぬん〜」とかカッコいい理由じゃない場合もよくある。
たんに、その実装は大変だとか、コストに見合う利益が見込めないとか、優先順位が低いとか、こういう時の返信はさらに難しい。(笑)
継続課金サービスならともかく、売り切りアプリでユーザーフィードバックにそんなコストかけてらんねーよっていう開発者がほとんどかもしれない。
まあ、こういう理由で、ちゃんと儲かるものを作るというのは最終的にユーザのためになるなとしみじみ思う毎日。
あとは、開発で忙しいとか、コミュニケーション苦手とか、いろいろあると思う。
そうは言っても、ユーザの意見を聞くと「ああ、作っててよかったな」とか思うし、どの部分にニーズがあるのか分かるので、規模にもよるけど、どうくみ取るかを考えるのは凄く重要だと思う。
そもそも反響がないとやる気もなくなるので、ある程度改善する予定があるアプリやサービスなら、その間だけでもフィードバックを取り込む仕組みを作るのは凄く有益なはず。と綺麗にまとめて終わる。
関連記事
モバイルアプリに手軽にご意見ボックス付けれるサービス。
アプリに組み込むヘルプサービス、Helpshiftがいい
英語だけど、この記事は本当にいいと思う。
PRODUCT STRATEGY MEANS SAYING NO
*家計簿と読み上げのアプリ作ってます。自己紹介と過去ログはこちら。
