見出し画像

ユーザーインタビューよりも、低コストで持続的にユーザーの声を取り入れてプロダクト開発する仕組みをつくった話

小阪 勇汰

クラウドワークス Advent Calendar 2021 20日目の記事です。
どうも。クラウドワークスのプロダクトオーナー小阪です。

最近ゲーム（Apex）にハマっており、スポーツのように楽しく真面目に取り組んでいます。こんなnoteも書きました(/･ω･)/

今日はお仕事のお話です。要点をまとめると、

  1. NPSをリニューアルして「満足度アンケート」つくったよ

  2. 「満足度アンケート定期チェックMTG」を実施してるよ

  3. （シンプルでありがちに見えるけど）めっちゃ良いよ

という内容です。

お時間無い方は前半をスキップして、「[ここ一番大事！]満足度アンケート定期チェックMTGの実施」から読んでみて下さい。

これまでのUXリサーチ活動

クラウドワークスでは2017年にUXリサーチ活動を開始し、2018年からブログでも発信を始めました。

私がデザイン部に異動をして、UXリサーチを専任で始めたのが2018年5月。
プロダクトオーナーに転向して、プロダクトオーナーの立場からUXリサーチを実施し始めたのが2019年10月。

これまでの3年半で、100名以上のユーザーインタビューやユーザビリティテストをしてきました。酸いも甘いも身にしみて感じています。

UXリサーチの課題と、実施してきた対応策

UXリサーチの課題

UXリサーチの課題は、やはり「実施コスト」です。

外部に委託するには金銭的コストがかかりますし、社内でやるには時間的コスト・労力的コストがかかります。（ユーザーインタビューを実践されている読者の方が大きく頷いてるのが目に浮かびます）

2018年当初だと、

  • リサーチの設計：2〜4時間　※1プロジェクトあたり

  • リクルーティング：5〜10時間　※1プロジェクトあたり

  • 実査：3時間　※1人あたり（準備込）

  • 分析：5時間　※1人あたり（準備込）

※5人実施の場合の総時間=54時間

くらい掛かっていたと思います。上記以外の雑務もたくさんあるため、メルペイ社はアシスタントさんを専任で雇われてますし、弊社もインターン生を雇ってアシスタント業務をお願いしていたこともあります。

リードタイムも長く、「調査したい」と思ってから「分析完了」まで1ヶ月で終われば早いほうでした。

実施してきた対応策

UXリサーチの実施コストを下げるために、大いに参考にさせていただいたのがメルペイ社です。それまで単発で実施していたリサーチを、定期実施するようになりました。

ルーティン化してしまえば、どんどん仕組み化が進みます。
下記のように工程をすべてマニュアル化し、誰でもUXリサーチを実施できるようにもしました。

（設計と分析のマニュアルはnoteで公開してます）

下記マニュアル達を参考に、実際に他部署でもUXリサーチがおこなわれました。

UXリサーチのマニュアル一覧

2021年現在だと、1人60分のインタビューで

  • リサーチの設計：1〜2時間　※1プロジェクトあたり

  • リクルーティング：3〜4時間　※1プロジェクトあたり

  • 実査：2時間　※1人あたり（準備込）

  • 分析：1時間　※1人あたり（準備込）

※5人実施の場合の総時間=21時間

くらいでできるようになりました。（会社としての熟達もありますが）

54時間→21時間に短縮できたので、約61%の工数削減です。

それでも、やっぱり大変なUXリサーチ

これだけ工数削減しても、やっぱり大変です。

3年前は私も含めて専任のUXリサーチャーは2名居ましたが、ジョブチェンジや退職などで今や0名。

プロダクトオーナー中心に実施していくしかないですが、ここ1年くらいは1人30分×1日2名×隔週実施=1ヶ月に4名がリソース的に限界でした。

UXリサーチが大切なことは社内で誰よりも理解してますが、これ以上増やせない葛藤。本当は専任のUXリサーチャーを置くのがベストなんですが…。

ということで、ユーザーの声を集める方法について再検討しました。

白羽の矢が立った「NPS」

ユーザーの声を集める方法は色々あります。
クラウドワークスで実施していたのは下記の5つでした。

単発のUXリサーチ

前述の通り、じっくり定性調査ができる代わりに、実施コストが高いのが難点です。

また、リードタイムが長く聞きたい時にすぐに聞けない。必要な時にしか実施しないため、偶発的な発見が少ないなどの課題もあります。

定期的なUXリサーチ

前述の通り、単発実施のデメリットを解消するためにルーティン化しました。多少ラクになったものの、大変さは拭えません。

1人30分、1ヶ月4名では局所的なユーザー情報しか得られずカバー範囲が狭くなってしまいます。

単発のアンケート

時々「単発のアンケート」も実施していました。得られる情報としては浅いものの、カバー範囲が広く、全体感を知るには良い手法です。

UXリサーチよりは実施コストは軽いですが、それなりの準備コストはかかり、都度準備する必要があるので持続性もありません。

ご意見箱

サイト内に設置されている目安箱です。機能実装されているため、自動的にご意見が集まる状態です。

毎日数件のご意見が投稿されますが、一部の人しか投稿してくれないため、これもまたカバー範囲が狭いです。

NPS

NPSも設置していました。利用者全員に表示をして、回答を集めていました。

カバー範囲も大きいですし、機能実装されているものなので自動的にご意見が集まる。

ということで、NPSを活用していく方向で検討を進めました。

（それまでNPSの結果をチェックしたり、改善に活かしたりしていなかった事をここに懺悔します…。）

それまでのNPSではダメだった2つの理由

実際にNPSの回答を見てみたところ「運用していたNPSをそのまま使い続けることはできない。」という結論に至りました。

そこには、大きな課題が2つありました。

課題①：NPS表示タイミングが悪い

クラウドワークスの発注者ユーザーは
「会員登録→募集→（応募が集まる）→契約→（業務のやり取り）→完了」
という流れを踏みます。

従来の仕様では「募集」の後にNPSを表示していました。クラウドワークスの場合、募集はスタートに過ぎず、その後に応募→契約→業務→納品されて始めて価値を感じることができます。

そのため「まだ利用を始めたばかりで分かりません」という回答が多く、お世辞にも役立つものではありませんでした。

課題②：聞き方が悪い

NPSは「あなたがクラウドワークスを他人におすすめしたい度合いを10段階で教えて下さい」というものでした。

ここで罠なのが「他人におすすめしたい度合い」というもの。

クラウドワークスの場合、

  • ①ワーカー獲得の競争率が高まるから、他の人には教えたくない

  • ②周りにビジネスをやってる人がいないから、教える対象が居ない

などの意見が多くありました。②はともかくとして、①はマッチングビジネス特有なのかなー。面白いなーとは思いますが、相応しい聞き方ではなかったようです。

また、そもそも日本人にNPSは合わない論（参考記事①、参考記事②）も散見されたため、聞き方も再検討することにしました。

爆誕した「満足度アンケート」

そんな現状分析のもと、NPSの反省を生かして「満足度アンケート」としてリニューアルすることにしました。

要件①：表示タイミングは仕事依頼の「完了」後

表示タイミングは一連の体験が「完了」した後に変更しました。

発注回数は問わない形にしたので、会員登録して1回目の仕事依頼を完了した人にも表示されるようになっています。満足度を聞くためには複数回発注したあとに聞いたほうがいいという考え方もありますが、回答数を多く集めることを優先しました。

とはいえ毎回表示されても鬱陶しいので、1度回答した人には3ヶ月表示されないようになっています。

要件②：聞き方は「満足しているか」

聞き方は「満足しているか」に変更しました。

アンケートはアンケートでも、なるべくユーザーインタビューのように本質を知れる仕様にしたい思いがありました。

そのためには全体感についての感想を聞いてしまうのが一番で、アンケートとしては王道ですが「満足しているか」という質問にしました。

また、10段階の選択肢だと無難な5〜8あたりを選びたくなるのが日本人ですし、例えば「8」が良い評価なのか中立評価なのかの解釈も人それぞれでズレるため、「満足/やや満足/どちらでもない/やや不満/不満」の5択にしました。

質問内容は、

①クラウドワークスについて、どのくらい満足していますか？（必須）
　→5択から選択（満足/やや満足/どちらでもない/やや不満/不満）
②クラウドワークスについて、満足している点は何ですか？（必須）
　→複数選択肢から複数選択可
③上記について、理由を教えてください（任意）
　→自由記述
④クラウドワークスについて、不満な点は何ですか？（必須）
　→複数選択肢から複数選択可
⑤上記について、理由を教えてください（任意）
　→自由記述

です。

選択肢の項目は、ユーザビリティテストを経て決定

「②クラウドワークスについて、満足している点は何ですか？」
「④クラウドワークスについて、不満な点は何ですか？」

この2つの質問に関しては、自由記述では回答ハードルが高いし、分析が大変になってしまうので選択式にする必要がありました。

ただし、選択肢を考えるのは難しいですよね。ましてや機能実装してずっと使うものであれば、尚更よく吟味された選択肢にすべきです。

そこで事前に単発の満足度アンケートを実施して、選択肢のユーザビリティテストをおこないました。

1. 仮決めした選択肢と、自由記述欄を作ってアンケートを配信
2. 回答が少なかった選択肢は削除
3. 回答が多かった選択肢は分解
4. 自由記述で多かった回答を選択肢化

というフローを経て、無事に選択肢決定です。

ちなみに、エンジニア陣が選択肢を変更しやすい設計にしてくれたので、今後もアンケート内容はチューニングし放題です。

[ここ一番大事！] 満足度アンケート定期チェックMTGの実施

ここが一番キモです！

NPSや満足度アンケートを取っている企業様は沢山いらっしゃると思いますが、重要なのはその結果をどう活かすかです。

弊社も従来はNPSを見れてませんでした…。（2回目の懺悔…。）
ご意見箱は見てましたが、Slackに流れてくるものを各自チラチラ見ているくらいでした。

手順①：意志を持って毎週MTGにPO全員が集まる

最初の半年はトップラインを担うプロダクトオーナー3名で、
その後は、マーケ担当とビジネスコンサル担当も加えて計5名で実施しています。

ユーザー向け施策を担当するメンバーはユーザーを一番理解しているべきだと私は強く思っています。

毎週月曜に全員集まり、1時間で前週の満足度アンケートの回答に目を通していきます。このMTGに異議を唱える人がいないのは弊社の良いところかもしれません。

手順②：自由記述回答すべてに「課題カテゴリ」付けをする

満足度アンケート定期チェックMTGで扱うのは、主に不満ポイントです。

不満ポイントを解消すれば満足度が上がり、
満足度が上がれば継続率が上がり、
継続率が上がれば事業成長に繋がるからです。
（まだ仮説ですが）

選択式で回答されたものは集計すればすぐに結果がでます。
MTGでチェックしていくのは、自由記述がついているものです。これは週50〜100件ほど集まります。

自由記述の不満コメントを1件ずつ全員で確認し、「課題」を抽出して、1件1件カテゴリ付けをしていきます。（ユーザーインタビューの分析のような要領です）

当てはまる課題カテゴリが無い場合は都度追加していきます。いま数えてみたら、ぴったり100個の課題カテゴリがありました。

満足度アンケート定期チェック用シート

手順③：課題について議論や、アイディアリスト化

あるあるの課題もあれば、目新しい課題もあります。
頻度が明らかに増えてきた課題もあります。

気になった課題はその場で議論。各自が持っている情報を共有しながら、課題について理解を深めていきます。

すぐに修正できそうな課題はその場でアイディアリスト（アイスボックス）に追加して、解決できるように動いていきます。

満足度アンケート定期チェックMTGのメリット

やってることはシンプルで地味ですが、メリットが大きいです。

メリット①：PO間でのユーザー課題認識が揃う

PO間でユーザー課題の認識を揃えるのは大変なことです。

ユーザー課題の認識が揃っていないと、取り組む施策の方向性もずれてくるし、各POの正義がずれてしまいます。

ユーザー課題の認識を合わせるために、かつてはユーザーインタビューになるべく出席してもらっていました。ただし、1人60分のインタビューでも参加するのは大変だし、当然1人分のインタビューでは不足です。

週にたった1時間のMTGでユーザー課題認識を揃えられる生産性は凄まじいです。

メリット②：特定課題に対するご意見を遡りやすい

なにか新しい施策を作ろうとした時、誰かからユーザー課題について聞かれた時、たいていは定期チェックMTGでつけている課題カテゴリ100個に当てはまります。

そのため、スプレッドシート上でフィルタをかければ、特定課題に関するユーザーの生の意見が1クリックで一覧化されます。

改めて詳細分析しやすいのが最高です。
当然そこからユーザーインタビューの依頼を投げることもできます。

メリット③：もはや定量データになる

アンケートなので、最初から定量データかもしれませんが、自由記述の不満コメントに関しては定性データだと思っています。

そんな定性データに地道にカテゴリ付けをすることで、Qごと半期ごとに振り返った時に定量データになっています。

「この課題カテゴリの意見が一番多いから優先的に取り組もう」など、施策の優先順位決めに大いに役立ちます。

だからといって、UXリサーチをやらない訳ではない！

ここまでユーザーインタビューやユーザビリティテストの株を下げて、満足度アンケートを祭り上げてきましたが、

だからといって、UXリサーチをやらないで良いなんてことはありません！

アンケートはアンケート。上辺の情報しか得られないので、実際に施策検討する際には深い調査が必要になります。

ただし、その目のつけどころがシャープになります。

前述したように「この課題カテゴリの意見が一番多いから優先的に取り組もう」となるため、その特定課題に関して改めてUXリサーチをおこなっています。

当然、サービス上の行動データからの一般的な定量分析もするため、

サービス上の行動データ
×
満足度アンケートデータ
×
UXリサーチデータ

大きくこの3つを組み合わせて、いまのクラウドワークスでは施策作りをしています。

最後に

2020年には、

こちらの記事で書かれていることに取り組んで、

2021年で本記事で書いてきたことに取り組んできました。

この2年でプロダクトマネジメント組織として、本質に向き合い腰を据えて施策作りができるようになってきた感覚があります。

先述したように課題カテゴリがなんと100個もあります。どんどん潰していって、会社ミッションである「個のためのインフラになる」に近づいていきたいです。

ユーザー中心のプロダクト開発をしていきたいPdM、エンジニア、デザイナーの方は、まずはカジュアル面談しましょう！

来年はどんなことに取り組んでいくんでしょう。
来年も楽しく仕事していきましょう。良いお年を！

この記事が気に入ったらサポートをしてみませんか？