とにかくユーザーリサーチをやった１年を振り返る
こちらはプロダクト筋トレのアドベントカレンダー12月19日（日）の記事です！
はじめまして、freeeでプロダクトマネージャーをしている和田です。freee人事労務のオンボーディングUX改善を目的とした開発を主に担当しています。タイトルにある通り、今年を振り返るとユーザーリサーチに費やした１年だったなぁと思うので、リサーチってどんなことするの？や、まだそれほどリサーチってしたことないジュニアPMの方向けに、どんなことをしてきたのか駄文をつらつら綴ります。
2020年の苦悩
2020年6月のコロナ下の中で転職活動を行いPMとなりました。なのでスタートは開発チームともほぼ顔をあわせることもなく、というか最初は担当の開発チームも無く(涙)、既に別目的で開発しているチームに対して、合間のおこぼれ工数で施策の開発を行ってもらう状況でした。チーム全体で協力するよりは、一人で企画を考え、メインの開発の合間でできるような小さい開発としてどうやるか内容を考え、タイミングを見計らって開発してもらうような仕事の進め方を最初数ヶ月やっていました。施策の背景となるWHYの部分もあまりコストかけずに今考えられるものという思考に囚われ、既にあった別のリサーチ結果から推測した仮説によるものや、手元で可能なユーザー行動の定量分析を行った結果を根拠に立案していました。
その結果何が起きたかというと、何も起きなかったんです(涙)。とにかく打席に立つ回数も少ない上に空振りばかりが続くような苦悩の日々でした。振り返ってみて、問題は開発体制だけでなくtoCプロダクトの感覚で自分を想定ユーザーに見立てて施策を考えてしまい、本当に価値を届けたいターゲットユーザーを明確にできていなかったというのもありました。(ユーザーテストも行っていましたが、検証ターゲットの条件が不十分だったので、とりあえずやったと言えるためにやってたかもな…)
2021年の転機
エンジニア採用が好調に進んだ結果、2021年1月からは専属のメンバーで開発できる体制が整いました。エンジニア2名、UXデザイナー1名、PM1名(私)のチーム体制です。ここから同じ目標に対してチームで学びながら開発を進めていくということができ、大胆な開発にもチャレンジできるようになりました。
そこで昨年の反省から、手元でできる定量分析だけでなく、ユーザーをもっと理解するための定性リサーチにも着手していくぞと動き出しました。幸いfreeeにはリサーチ組織が存在してサポートが貰える仕組みがあったため、その力を借りながら迷うことなく動き出せました。
ユーザー理解のためにやったこと
基礎編ユーザーインタビュー
まず最初はご存知ユーザーインタビューです。
定量データから候補を抽出し、そこにアポイントのメールを出しまくりました。けどなかなかインタビューが成立しないってこともあり、追加候補を抽出したり、カスタマーサポート対応有りにして、つでにインタビューさせてもらうなどの工夫が必要でした。
インタビューをして思ったのは、やはり想像と実際のユーザーは違って視点を改める必要がありました。特にユーザーのITリテラシーは想像を超えていました。ITアレルギーと言われる人がいる現場でも導入検討をされはじめていて、そういった現場のユーザーが改善したいメインターゲットに含まれていることに気付きました。
もう一つ気づいたのは、実はユーザーに近いカスタマーサクセスからヒアリングしていた課題とも根本課題は少し異なってくる点でした。「〜なユーザーは〜の内容で困ることが多いんです。」という情報を事前に聞いてはいたのですが、ヒアリングしてみると根本原因についてはまた別の課題が見えてきました。当初その意見だけで開発を進めていたら、やってはいけない『ユーザーの意見を鵜呑みにして開発する』と同じだったかも。。。
応用編エスノグラフィ
次にやったのはエスノグラフィです。こちらはどんな取り組みで、やってみてどんな発見があったのかをプロ筋Confのセッションでお話しましたので、そちらをご覧ください。下記にセッション動画へのリンクがあります。(Track Aの一番最後にグダグダ話してるのが私です。)
未知編ユーザー支援
最後に現在取り組み中ですが、直接カスタマーサクセスの一員としてユーザー支援を行っています。0→1のタイミングでPMFしているかどうかを直接ユーザーに営業して確認するPMもいるという話から自分もチャレンジしたいと思いやってみました。下準備が大変ですが(汗)、自分から直接ユーザーに説明してみる経験はは大変学びが多いです。
特にやってみて気づいたのは、直接伝える機会があれば伝えられる内容を、伝える機会が無いユーザーってどこで気づけるんだろうか…？と思う事が何度もありました。インタビューでは「ヘルプページが充実していて大変助かっています。」という意見もあったのですが、いざ自分でサポートしていくとあまり問題視されていなかった部分にユーザーが疑問を持っていたりすることがあったり、ユーザーの理解度に合わせた説明が無いと伝わらない部分やデザインを直したい部分がまだまだあると思いました。
まとめ
改めて、toBプロダクトにおいてユーザーに目線を合わせるためのリサーチは必須だと思います。toCをやってた頃は自分がそのプロダクトの一番のユーザーであれば大きく見当違いにはならなかったのですが、toBはユーザーの状況にそれぞれ違いがあり、toCの考え方のままだと空振りの失敗続きになっていました。データだけ見てユーザーの何を理解した気になっていたのか恥ずかしくなってきました。
もう一つ、ユーザーの一次情報をフィルターが掛かっていない状態で観ることが大切というのも感じました。例えばデザインに対する「ここが見づらかったです」という発言も、デザインに不満が無いかと質問して何とか捻り出されたものなのか、ユーザーから自発的に不安そうな表情で発言されたものなのかで深刻度が変わります。けれども誰かがまとめたものだと「〜という発言があった」だけでその深刻さが伝わらない状況になります。誰かのまとめを読むだけでは気づけ無い情報を直接観ることで、数だけでは分からない本当にユーザーが必要としている価値に気付けます。
最後に、リサーチにどれだけの作業量を費やすのかのイメージが湧かず、着手に戸惑っている人もいると思うので、どれだけのリサーチ活動しながら、並行してどれだけリリースも行えたのか、みなさんの参考にできればくらいの感じで今年の結果を共有したいと思います。(最初からちゃんとできてるPMはもっと多いんだろうなと思いつつ、自分の場合はこんな感じです。)
リサーチ全体の作業量：およそ3ヶ月分くらい
リサーチ計画〜アポ取り：1ヶ月半分くらいの作業量
リサーチ実施
インタビュー件数：50件(1時間/1件)
エスノグラフィ件数：8件(2~3時間/1件)
ユーザー支援：1件(準備含めて20時間くらい)
リサーチ結果の分析やまとめ：2週間分くらいの作業量
施策のリリース回数：21回(大小あります&障害対応などのリリースは除く)
事業に出せたインパクト：測定中、来年お会いできたらお話しましょう(笑)
ここもまでお読みいただきありがとうございました。
追伸：PMがリサーチにどれだけの作業量を割いているものなのかにも関心あるのでコメントなどいただけると幸いです。
この記事が気に入ったらサポートをしてみませんか？