講師は
佐々木 真さん
株式会社PM Club 代表取締役 CEO
でした。
いつものHCD系の方とはちがうユーザーヒアリングのお話でした。
■ユーザーヒアリングの基礎とプランニング設計
▼自己紹介
・連続起業家（4回目）
・プロダクト開発スクール「PM School」
・プロダクト開発人材の転職支援サイト「PM Career」
・「スタディサプリ」の元事業開発
・Webメディア事業売却経験あり
▼ユーザーヒアリングとは何のためにするものでしょうか？
1.ファクト集め→8割
2.仮説検証→2割
※ファクト→事実情報
ほとんどの場合が
ファクト情報が足りないのでユーザーヒアリングを実施する
ユーザーヒアリングが十分で課題の解像度が高い場合は
あとは解決策をつくるだけ
ユーザーヒアリング完全MAPとは
1対1インタビューを活用した
課題・ユーザー・解決策の
特定をする流れを図式したもの
▼ユーザーの課題特定
①課題の解像度を上げる
②ユーザーの解像度を上げる
③解決策の解像度を上げる
まずは課題があるかどうか確かめることから全て始まる
課題があまりないのに機能を作ってしまいがち
人が欲しがるものを作ろう
by ポール・グレアム
「誰の」「どんな課題を」解決するのかを考えるのがPMの仕事
そのためにまず「課題があるか」と「どれくらい大きい課題か」を見極める
課題の大きさ＝重要度×緊急度
Must have:なくてはいけない
Nice to have:あったら良いな
この2つを見極めプロダクト価値を向上させる
課題はたくさんある
1つのプロダクトで全て解決は不可能
大事なことは「自分たちのプロダクトは
どんな大きな課題を解決するのか」
ユーザーヒアリングは大きな課題を特定するための
全PM必須の手法
課題の選び方
大きな課題×プロダクトの方向性
【課題分け3パターン】
1.課題がまったく分からない場合
2.課題は分かるけど具体的なユーザー像
3.課題もユーザー像も分かる場合
▼ユーザーの課題特定
・ファクト収集→仮説構築
課題に気づくためにはまずファクトを集める
ファクトがないと全てが妄想になる
得くべき課題がわかるためには
ユーザー解像度を高く持つ必要がある
そのための最初の一歩が「ファクト収集」
例：PM Schoolのアイデアを思い付いたきっかけのファクト
「プロダクト顧問をしていて複数社で同じ
失敗と質問を繰り返しされた」
例：このファクトを元にした仮説
「もしプロダクト開発のことを学べる
スクールがればいつでも・誰でも学べて顧問がいらなくなるのでは？」
仮説検証の前に特に確かめること
1.それは十分な大きな課題か？
2.今後も継続して発生する課題か？
3.どんな解決策を望んでいるか？
4.過去に解決できなかったのはなぜか？
5.解決の技術的・経済的な制約はあるか？
ファクトを集めると課題の仮説が浮かんでくる
仮説が持てない場合はとにかく浮かぶまでファクトを集める
すべてのプロダクト開発はここから始まる
▼ユーザーの課題特定
仮説検証ヒアリング
仮説が浮かんだら
それを「確からしい仮説」にする
そのためにユーザーヒアリングをする
よくある失敗
ファクトを集めずに仮説を構築して
「誰も持っていない課題」を解こうとする
課題があるかヒアリングすることは大事
しかし同じくらい「どれくらい大きいか」を必ず確認する
ファクト収集ヒアリングシート
課題の解像度を上げるために集める
必要のある情報を一覧にしたもの
このシートが全て埋められれば
解像度は格段に上がる
課題が十分大きいと判断できる例
1.ミッション・KPIに設定されている
2.経営目標・事業目標に影響する
3.すでに問題が発生している
4.売上の損失が発生している
5.法律・制作に関わる対応
▼ディスカッション
・ユーザーインタビューでよくある失敗
1.インタビューが時間内に終わらない
たぶん社内の会議も時間内に終わらない人。
これを絶対に聞くということをはっきりとさせる。
プランニングができていない。
リサーチクエスチョンを明確にさせておく。
事前準備の部分が特に大事。
2.ユーザーから答えを得ようとしてしまう
・どんなサービスがあったらいいと思いますか？
・●●のようなサービスがあったら使いますか？
→鵜呑みにしない
→絶対嘘だろと思っておく
→ファクトをもとに、自分だったらどう解決するか考える
3.何人にも聞いたがインサイトが得られない
→インサイト→推測・洞察
→なぜヒントを得られないのか→課題を分かってない
■質疑応答
①既に課題が顕在化し、市場が存在している領域で、ユーザーインタビューする場合のポイントについてご教示ください。
この場合、競合サービスを利用する際の課題にフォーカスするのか、それとも、そもそもの課題を改めて深掘りするのが良いのか。どちらが正でしょうか
→結構難しい、本当に競合か？
自分たちの解決する課題を見つける
Slack・Microsoft・Teams・チャットワークこれ実は競合じゃないんですよ。
→競合はあまり意識しない
②課題の大きさは重要度×緊急度というのは非常にわかりやすかったです。緊急度は納期やスケジュール感をヒアリングすればいいと思うのですが、重要度はどのように明確化すべきでしょうか？
→会社のミッションに入っているか
兼務でちょっと追っているぐらいだと緊急度が低い
重要度が高いのに失敗する例はダイエットと英語
（緊急度がない）
③インタビューの適切な人数設定は何人ですか
→まず5人やるといい。できれば10人
④インタビューしてファクトを集めて仮説をアップデートしていくときに、どのように情報を整理していくか教えてほしいです。例えばスプレッドシートで仮説とユーザーのマトリックスを使って、作って、インタビューしながらアップデートしていくなど。
→ユーザーヒアリング系のSaaSだと結構むずい
→うちはNotionでやっていて、サマリーをSlackに流す。
⑤ファクトをついつい解釈してしまいます。
ファクトと解釈の違いを教えてください
→実際に起きたこと、過去形を聞く。未来を聞いてはダメ
解釈とファクトは分ける。
⑥ファクトを質問するに当たって、質問の内容の優先順位は、
どうしたら良いですか
→本当に事前にわからないか？IR情報などで収集する
⑦ファクト収集と仮説検証は同一の対象者に行うべきでしょうか？(インタビューは、同じ相手に繰り返し行った方がいいのかという観点の質問。
→課題がどれだけ大きいか。
少数で大きな課題を持っているものの方が売れる。
課題の大きい方に繰り返し検証する。
コメント