| @労働

雷山千如寺 五百羅漢

今年はよくユーザーアンケートをとった。アンケート、最初は手探りだったけど最近は知見が貯まっていい感じにできるようになってきたのでノウハウをまとめたいと思う。ポイントは以下。

  1. 問いの設定
  2. Google Form の機能を駆使して誰が回答しているのかをわかるようにする
  3. Big Query と Looker を使った集計・ビジュアライズ

正しくアンケートをやってユーザーの声を聞けば、イチロー並みかそれ以上の打率で機能をリリースすることができるという気がしている。

問いの設定

アンケートで聞くべきは何か。いつも課題を聞くようにしている。やってはいけないのは「欲しい機能は何ですか?」と聞くことだ。良く言われることだがユーザーは自分が欲しい機能をわかっていない。だから課題に感じていることを聞く。

「課題と言っても何を聞けばいいのかわからない」と思う人もいるだろう。自分はいまある程度規模が大きくなってきたプロダクトの PM をやっているので、ユーザーの課題は何となくわかる。問い合わせやユーザー要望、ユーザーの利用データなどから何となくこの辺が課題だろうなというのは見えてくる。課題はこれらを確認することでわかってくるので課題リストにストックしておく。

次にどんな機能を開発すか検討するときに課題リストの中から「これを解決すると良いのでは(ビジネスインパクトが大きいのでは)」というのを見繕って、「〇×にどのくらい課題を感じますか?」という形でアンケートを送るようにしている。回答選択肢は三択で「とてもそう思う」「そう思う」「そう思わない」くらいにする。いくつかの課題を並べて聞き、「とてもそう思う」という回答の割合が一番高いものがペインが大きいと認定し、その課題を解決する機能の開発に取り組むようにしている。

Google Form の機能を駆使して誰が回答しているのかをわかるようにする

アンケートのシステムには Google Form を使っている。一時期は自前でアンケートシステムを作ろうかと考えたが、 Google Form ほどの柔軟性を持ったアンケートシステムを作るのは工数がかかるし、マーケティングチームの人もアンケートを多用していて Google Form に慣れているので Google Form で行くことにした。

ただ、ちょっと使い方を工夫していて、ペライチのページを作って iframe で Google Form を自ドメイン内のページに埋め込むようにしている( Google Form は iframe での埋め込みをサポートしている)。こうすることで以下のメリットがある。

  • アンケートページの URL がサービスと同じドメインになり怪しさがない
  • ログイン後のページに配置することで自ドメインで作成されたクッキーにアクセスできるようになり、ユーザー ID を取得できるようになる

Google Form はクエリパラメーター付きで https://docs.google.com/forms/d/e/XXX/viewform?entry.0000=value とすることでフォームに値を埋め込むことができる。アンケート依頼はアプリへのプッシュ通知で送ることが多いので、その場合には value の部分にユーザー ID が入るようにしていた。しかし一括送信するメールやアプリ内のバナーへリンクを設置する際にこのやり方は使えなかった。サービスのドメイン内にログイン必須のペライチページを作ってフォームを埋め込むようにしたことで、どんな導線からアンケートページに辿りついてもほぼほぼ確実にユーザー ID を取得できるようになった。

ユーザーアンケートは誰が回答しているのかを知るのが超重要だ。プロダクトのヘビーユーザーの回答なのか、ライトユーザーの回答なのかわからないと、次に作るべき機能を検討するときに判断材料として使えない。ライトユーザーの課題を解決する機能を開発しようとしているときに、誰が回答したのかわからないアンケートデータをもとに意思決定をするのは困難だ。

アンケートでユーザー ID を取得する際のデメリットとして、匿名回答ができないことでアンケートの回答率が下がることが懸念されるが、上述の通りどんな属性の人が回答したのかわからないアンケートはデータとしてあまり価値がないのでその部分は割り切ることにしている。また匿名の回答はサービスへのネガティブ感情が強い人からの回答が集まりがちで、自由入力欄の罵詈雑言で集計時に精神的にダメージを受けることもあるのでそれらを避けるという意味でもユーザー ID 必須のアンケートにしてしまって良いと思う。

BigQuery と Looker を使った集計・ビジュアライズ

集まったアンケートの回答は一旦 Google Spreadsheet 形式に変換する( Google Form の機能を使うだけで簡単にできる)。スプレッドシートの機能を駆使すればクロス集計したりグラフを作ったりできるが、折角取得したユーザー ID との掛け合わせができない。なので Google Spreadsheet のデータを BigQuery に取り込んでいる(詳しいやり方は Google スプレッドシートを BigQuery のテーブルとして扱う - べにやまぶろぐ 参照)。勤務先では BigQuery にデータウェアハウスが構築されているので、 Production DB のレプリカとアンケート回答を JOIN することで、どんな属性の人がアンケートにどんな風に回答しているかがわかるようになる。さらに幸運なことに勤務先では Looker を使えているのでこの辺の分析がとてもしやすい。こんな感じでアンケート結果をビジュアライズしている。

アンケートの集計

このやり方をとるようになって、リリース後に「大きく外した」ということがなくなった。少なくとも機能をリリースするときにユーザーに受け入れられるかどうか不安に思うことがなくなった。イチローになったような気分でプロダクト開発することができるのでおすすめです。


この記事は YAMAP エンジニアのカレンダー | Advent Calendar 2021 9 日目の記事でした。明日は @t-yng さんの「僕がフロントエンドのコードレビューをする時に意識していること」です。

| @労働

ソフトウェアエンジニアからプロダクトマネージャーにジョブチェンジするにあたり、社内説明するために作った資料を公開します。プロダクトマネージャーという職種はプロダクトマネジメントについて書いてある本(シリコンバレーの PM が書いたもの)でも「定義は会社や組織によって異なる」とあるので、自分の会社でも役割を明確にしておく方がやりやすいだろうと思って作りました。プログラマー/エンジニアは How にフォーカスするけど、プロダクトマネージャーは What にフォーカスする職業だなぁと最近は思っています。

以下は HTML バージョン


プロダクトマネージャーの役割

ソフトウェアを継続的に企画・製造してユーザーのニーズを満たし、ビジネス上の成功を実現する

ビジネス上の成功とは何か?

Product/Market Fit

Product-Market-Fit.png

※図は Dan Olsen のスライドから引用

Product/Market Fit とは何か?

良い市場を見つけ、市場の要求を満たすプロダクトを作る

なぜ Product/Market Fit が重要か?

すでにある製品を買ってくれる相手を探すより、市場に存在する問題を解決する製品を作る方が簡単だから

なぜプロダクトマネージャーが必要か?

  • Market Driven な製品開発
    Market Driven でプロダクトを作っている会社の方が 31% 儲かりやすい
  • 組織のゴールが明確になり、プロダクトのリリースと収益化が迅速化される

(良い) プロダクトマネージャーは何をするのか

  • 何が作る価値があるものか、何がそうでないかを明らかにする
  • すでに市場(ユーザー)で価値の検証が済んでいるものだけを作る

エンジニア・デザイナーとどう違うのか

  • エンジニア・デザイナーは解決空間を担当
  • プロダクトマネージャーは問題空間を担当する

Product-Market Fit - 2.png

具体的な役割

Product-Execution.png

  • ユーザーヒアリング
  • 解決すべき課題の定義
    すでに存在する問題だけではなく、ユーザー自身も気づいていない問題も定義する
  • 作るものの定義
    機能要件、スコープ
  • 成功の定義とメトリクスの計測

※図は Making It Right から引用

プロダクトマネージャーが扱うデータについて

  • データ分析チームとは異なり、ありのままの現実を調べる
    線形解析とか難しい統計とか機械学習などは担当しません

まとめ

Product-Market-Fit.png

  • Product/Market Fit がミッション( Objective )です
  • どうやったら Product/Market Fit したかを含め、成功そのものを定義します
  • 成功するプロダクトを作ることに注力します( Engineering からは身を引きます)

参考ページ