“ユーザーの声“という見えない呪縛
まずは“ユーザーの声“の定義から初めよう
ポエム回です。個人の考え方なので弊社の方針でもないし、他の面接官がどう思っているかは知りません。
はじめに
去年に開発チームのマネージャーになって、社会人として初めてマネージメントをしている。同タイミングで新卒や中途の面接もやっている。 その2つを半年ほどこなしてとあるキーワードがあたまの片隅に引っかかる。
「ユーザーの声」
はたしてこれは一体何を指しているのだろうか。
特に新卒面接で多いのだが、自社サービスかつ比較的toCが多い弊社や他社を選ぶ際の理由や、「どんなプロダクトを作っていきたいか」みたいな質問を投げかけると9割ぐらい「ユーザーの声」というキーワードが出る。あと受託からの中途面接でも多いかな？
では「ユーザーの声」とは何なのか聞いてみるとたいていは「SNSやレビュー」と言われる。
はたして本当にそれが「ユーザーの声」なんだろうか。
ユーザーの声とは
たしかに声の一部分ではあることは揺らぎない事実ではある。
だが「ユーザーの声」とやらの全てでは無いし、指向性というかベクトルはかなり偏っている気はする。
統計があるわけではなく経験則(これもまた偏った見方)になってしまうが、概ねレビューやSNSで“見ているユーザーの声“は事業的に外れ値であることが多いにも関わらず意思決定において極めて有効な材料になっていることが多く感じる。
“事業的に外れ値“という表現をしたのは、「このユーザーはレビューでコメントしてくれている」「SNSでSSと一緒につぶやいてくれている」みたいな理由でそのユーザーをプロダクトにおける一種のペルソナの具現化みたいな落とし込みをする人が多々いて、抽象度が高いから採用しやすいのはわかるが、実際問題その“熱量が高い“ユーザーが必ずしもプロダクトのグロースに貢献してくれるかというとそういうわけではない。という意味合い。
例えそれが課金しているユーザーだったとしても、母数が1の声を採用してn-1を無視したプロダクトを作ってもグロースはなかなか難しいと思う。どこかで頭打ちして“他に見えている声は無いか“と探してまたその人をペルソナにして…と。最後にはそのプロダクトは一体何のためのアプリなのか、何を解決するためのプロダクトなのか、誰もわからないモンスターが生まれてしまうのは目に見えている。
先程書いた部分と重なるところがあるが、“声が見えている“と勘違いしてしまうのは解像度・抽象度が高く、解決すると"見えている声"に変化が現れやすい。つまるとこコスパがよく見えるからである。 今までSNSやレビューと記してきたが、CXの問い合わせやユーザーインタビューだったりとにかく"非加工で可視・聴覚可能な声"全てに当てはまる。
ここでいう"コスパ"は、最近読んでいる"エンジニアリング組織論への招待"の言葉を一部借りるなら、誰も見えない"不確実性"を可視化という一番コストがかかる部分を最小限のコストで減らしてるように見えるという意味。
追うべきはサイレントマジョリティー
「じゃぁお前の中でのユーザーの声はなんなんだ」と言われると僕の中では「ユーザーの行動ログ」だと思っている。
実際のユーザーの行動をログという形で収集し、可能であればそれをデータサイエンティストあたりが"バイアスを極力排除した"状態で分析した結果、サイレントマジョリティーの声が見えてくると思っています。
そしてユーザーグロースの観点ではそのサイレントマジョリティーをどれだけ拾って行っていくかが重要になってくる。結局はここが一番のボリューム層になってくるので。
ユーザーインタビュー
「ユーザーインタビューはどうなん？」という問いは少し扱いが難しいと思っていて、一人とか二人やっても意味がないというかむしろ直接フィードバック受けてる分余計に意見に引っ張られて"事業的外れ値"よりたちが悪い。
やるとしたら何人がいいのかみたいな話でよく聞くのはヤコブ・ニールセン氏の「5人でユーザテストすればユーザビリティ上の問題のうち85%が見つかる」みたいな出典元がいまいちわからん話があるが、調べた限りの出典元の論文と現代のプロダクト開発と比較するとあまり当てはまってないという感想。
ユーザーインタビューは目的があーだーこーだありますが、個人的に一番注意が必要なのは、もしその目的が"その時点でのプロダクトについて"に聞いているなら継続的/反復的にやる必要があるという点です。
現代のプロダクト開発は大抵アジャイルで行われているので、"その時点"と来年ではプロダクトもある程度変わっているでしょう。(変わっていないならそれはそれで問題があると思いますが)来年に"その時点"のユーザーインタビューをアップデートしておらず永遠と"その時点"のプロダクトでの評価を引きずっているならプロダクト開発のイテレーションに盛り込まれていないということになります。
イテレーションに盛り込まれていないということは、プロダクト開発の一部としてのユーザーインタビューは無意味、むしろそのプロダクト開発にとって悪となる可能性が高いと思います。
アジャイル開発手法に盛り込むのであればイテレーションに含めて、理想を言えばリリース毎にユーザーインタビューを行ってそのフィードバックを得て仮説が正しかったか/間違っていたか、ユーザーに伝わっているか伝わっていないかなどをもとに次回(or 次次回)イテレーションの仮説検証に盛り込むというというのが時間軸に依存しないユーザーインタビューのやり方だと思います。
つまるところ「5人でもいいけど継続的にやらんと意味がないよね」的な話です。
とまぁ、ユーザーインタビューはそういうところが難しいよね～って思ってます。
社内ツールは最高の教材
社内ツール(おもによく言う管理画面とかダッシュボードとか言われるやつ)をつまらない、非生産的な作業だと思っているエンジニアをインターネットで見かけることはよくある。
弊社でもエンジニアに限らず、特に得られるもののないタスクの一環として作業している人を見かける。
で、僕が思っている結論としては「社内ツールはユーザーの声を拾う最高の教材」だと思っている。
よくよく考えてほしいが、ユーザーというのは何万人何十万人といる中で、社内ツールの一部の機能を使うのは(社内規模とかその機能がどういうものか置いといて)せいぜい数人～10人程度だろう。
そこを比較したときに社内ツールを満足に作れないでユーザーに価値提供・満足してもらえるようなものが作れるだろうか。
例えば使う人が3人だとして、少なくともオフィス(せいぜい数十m)にいて、いつでも、そして何回でも聞いてもタダで直接FBをもらえる(ようはN1インタビューし放題な)環境で満足に作れない人間にユーザー側の機能実装を任せようと思わないよね。
だって社内ツールって社内の人間が"ユーザー"なんだもの。
社内ツールは(プロダクトのユーザーに損害が出ない限り)最悪ごめんなさいって言えばいいので、聞いて、考えて、ぼくのかんがえたさいきょうのUXを提供すればいいんかなと。
それができない・思考放棄するならただ言われただけのものを作る人なんだなって認識してしまう。「忙しくてリソース足りないからそういうの考える時間が無い」ならプロダクトのユーザーにも同様に接するでしょ。
FBを得たいならtoCよりtoBの方がはるかに簡単
一番最初の話しに戻るが、「ユーザーの声を聞きたい」と思っている人がtoCにこだわる理由がいまいちわかっていない。
前述でも述べたが何かを作る以上そこにはユーザーがいて、toBでもユーザーはいるでしょと。
一番いい例はSlackとかAWSとかGCPとかはメインはtoBで収益を上げているプロダクトだけど、じゃあそのプロダクトを社内ツールとして利用している企業に所属している(もしくはこれから所属する)あなたはそのユーザーじゃないんですか？っていうとどう見てもユーザーですよね？
そして肌感一番最初に挙げた"すでに可視化されているユーザーの声"とやらはtoBの方が明らかに量が多い。お金払って契約している以上ポンポン乗り換えられないのでめちゃめちゃ直接フィードバックしてくる。
なので「toCだからユーザーの声が聞ける」というのはいまいちピンときてはいない。
まとめ
今回はユーザーの声の収集について書いてみたが、それらをどう生かすかはまた別の機会に。
一応言っておくと別にSNSやレビューを無視しろという話ではなく、それを全てのユーザーの代表のように扱うなという話です。
どうしても簡単に目に見えるものにフォーカスが偏ってしまうのは人間の性質なので、ある程度仕方がない部分はありますが、それを自覚して俯瞰的に見る、自分だけだと難しいなら専門家やそれに長けている人に相談する、というのが僕が考えるユーザーの声を取り入れる上でのベストプラクティスだと思っています。あくまで僕自身の考えですが。
あとは見方を変えるとそもそもの"ユーザー"って誰だっけ？という話になる。
そんな文章をチビチビ1週間かけて書いていたら面白いつぶやきがあってまとまっていたので貼って終わりにしようと思います。もっと書こうと思いましたが疲れたのでまたの機会に。
ゲームにおいてプレイヤーの「面白くなかった」という感想は間違いなく正しいが、改善提案はだいたいあまり正しくないという話について