この記事はLITALICO Engineers Advent Calendar 2025 カレンダー3 の 3日目の記事です
はじめに
こんにちは！プロダクトマネジメント部の寺町です。
障害福祉事業所向けの業務支援SaaSのPdMを務めています。
入社以来2年少し色々な新規機能の企画や開発に携わらせて頂きました。
私はプロダクトの新規機能の開発や企画において、PdMとしてはユーザーインタビューが必須と考えています。この2年間、新規機能の開発にあたりユーザーインタビューを続けてきました。
ただ、最初からうまくできていたわけではありません。むしろ、今思えば “やってはいけないこと” をいくつも経験してきました。(今でもやってしまっています)
本記事では、
・ユーザーインタビューはいつやるか
・ユーザーインタビューの目的は何か
・ユーザーインタビューは訪問にした方がいいと考える理由
・失敗から学んだ教訓
を、私の数多くの失敗談を交えてまとめます。
新規開発やプロダクト改善に携わる方に、少しでもヒントになれば嬉しいです。
ユーザーインタビューはいつやるか
何か新しいものを作ろうとする際の上流工程では、ユーザーインタビューは欠かせないと考えています。
企画をしたり要求定義をしている過程では特に、PCに向き合って頭の中のユーザーと対話しているだけでは机上の議論になりがちです。
結果的に、私的にはものすごくわかりやすく便利だが、ユーザーにはイマイチヒットしない企画が出来上がってしまうこともありました。
この失敗を踏まえ、私は、「迷ったら行く」「案が少しでもできたら行く」という方針で動いています。
理想としては最低月に1回は顧客訪問をしたいし、すべきであると考えています。
継続的に現場と接点を持っていると、自然と“妄想の精度”が上がっていきます。
逆に、ユーザーから離れる期間が長くなると、途端に仮説がズレはじめることを何度も経験しました。
ユーザーインタビューの目的は「行動」と「文脈」を理解すること
インタビューの目的は、決して 「意見を集めること」 ではないと考えています。
もちろんユーザーのご意見を収集することも大切ですが、ご意見だけでは御用聞きになりすぎてしまうように感じています。
私が重視しているのは、「ユーザーの1日を、できる限りリアルに想像できる状態にすること」
です。
そのために、以下の視点を丁寧に拾っていきます。
• 実際の行動
• どのような流れで業務が進むのか
• そのときの感情や判断基準
• 言語化されていない制約や運用ルール
• 課題の大きさ、頻度、優先度
意見よりも実際の行動を把握できた方がより良い要求を抽出できるように感じています。
理由としては下記です。
• 意見はユーザーの中で課題だと思っていることにしか出てこないため、暗黙の運用でカバーできている部分が拾えない(表層的な課題になりがちでした)
• 行動を拾うことで、本来自社システムで拾うべき課題(ユーザーが運用でカバーしてしまっている部分)を拾える
• ユーザーが「まあそういうものだ」と諦めているため口に出さない課題を拾える
言語化できていない課題、わざわざ話す程でもないと思っている課題を拾うことを重視しています。
PdMこそユーザーインタビューに行きまくるべき
PdM は「何を作るか」を決める役割です。
だからこそ、一次情報を自分の肌感で理解しておく必要があります。
• 開発チームに説明するとき
• 優先度を判断するとき
• 仕様の妥当性を考えるとき
そうした意思決定の基準は、ユーザーの理解の精度によってズレてしまいます。
また、定期的にユーザーと会っていると、プロダクトの方向性がブレた時(企画を外している時)に早めにユーザーからFBをもらえます。
開発に取り掛かる前のワイヤ段階や案の段階でそれは要らないし使わないと指摘して貰えるため、軌道修正が早くからできます。傷が最小限です。
だからこそ、できるだけ頻繁にインタビューに出掛けるようにしています。
事前準備として私がやっていること
インタビューは「行けばなんとかなる」ものではありません。
明確に目的を持って行かないと楽しく雑談をして帰ることになってしまいます。
一方で、準備しすぎると視野が狭くなる危険もあります。
私はそのバランスを取るため、以下のポイントだけを押さえるようにしています。
1. 明らかにしたい問い（ゴール）を決める
今回のインタビューで何を知りたいのか、何を解像度高くしたいのかを事前に決めておきます。
例えば以下のような粒度です。
• 既存業務の流れを掴みたいのか
• 課題の大きさや頻度を知りたいのか
• 仮説の妥当性を検証したいのか
• ワイヤの抜け漏れを見つけたいのか
目的がないままインタビューすると、会話が散らばってしまいます。
設計が不十分でお客様の制度への不満を1時間拝聴して帰ることになった苦い経験もあります。
自分のリソースを割いて行くからこそ、最低限目的を設定してから出掛けるべきです。
2. 業務フローや価値の仮説をいくつか持っておく
当日、ユーザーの話を聞いたときに「何が自分の想定と違うのか」に気づきやすくするためです。
ガチガチに固めたフローを作り込むのではなく、お客様のAsIsとの比較対象を複数持っておくイメージです。
3. インタビューの構成は“ざっくり”だけ決める
私はインタビューガイドを作り込みすぎないようにしています。
以前、細かい質問リストを作ったことがあるのですが、決まった話しか出ず、周辺の重要な情報が全く取れなかったことがありました。(一問一答のイメージになりました)
それ以来、
• 聞く順番
• 深掘りするテーマ
• 優先順位
だけ決めて、会話ベースで聞いています。
4. アポ対象は幅を持たせる
話しやすそうな人だけに偏ると、ユーザー理解が歪むため、意図的に幅を広げるようにしています。
具体的には以下です。
• ペルソナとの合致度を確認
• 過去の接触履歴から人物像を想定
• あえて年代・リテラシー・地域にばらつきを持たせる
ユーザーインタビューは訪問の方がいい理由
オンラインで話を聞くこともできますが、現場にはオンラインでは絶対に拾えない情報があります。
対面で人と話せるので、以下のような情報が汲み取りやすいです。
・案やワイヤを見せたときの表情(刺さってそう/刺さってないけど遠慮してそう)
・視線の動き
・気にしている箇所(何度も見ようとしたり目線の感じがなんとなく違う等)
遠慮等から口には出さないが、実は考えていそう/重視していそうな項目が拾えるように思います。
他にも、現場に行くことで現場の雰囲気も拾えます。
• 机の上の紙の並び
• 掲示物
• 見せてもらっているデスクトップのフォルダ構造
• 棚に紙がどの程度収まっているか
• 現場の備品の配置
こうした現場の物の雰囲気の情報は、ユーザーさんが「困らないために工夫してきた結果の痕跡」だと考えています。
どうしても紙でほしいもの、準備していると言っているが仕舞ってあるため使っていなさそうなもの等拾える情報は様々です。
本人が口に出さない運用フローが汲み取れます。
以上のことから、その人の表情や雰囲気、デスクの感じ等を拾いやすいオフライン訪問がおすすめです。
私がやってしまった失敗と学び
ここからは、私が実際にやってしまったり、現在進行形でやってしまうことがある失敗を列挙します。
Geminiに相談したところユーザーインタビューにおける典型的な失敗をしているとのことのため、ぜひ同じ失敗をしないように私の轍を踏んでください。
1. 「これ使えますか？」「欲しいですか？」と聞いてしまった
初手から最悪の失敗例です
上記のように聞くと返ってくるのは、「使えると思います」「はい、大丈夫です」「欲しいです！」がほぼ100%です
聞いた時は絶賛だったのに、実際はあまり使われないこともありました
実際の例ではないですが、具体的には下記のような状態です
「カレンダーのアプリ欲しいですか？」と質問した時、だいたいあれば便利！使う！と回答がきます。
しかしその人の事務所には紙のカレンダーがあって、そこに予定がびっしり手で書いてあります。
この場合、実際は
• 壁に貼って皆が見られることが必須
• 共有スペースでの運用が前提
• みんなが毎日PCを見るわけではない
などの背景があり、「紙である理由」が存在します。
このような状態では欲しいと言っていても、純粋なカレンダーアプリでは絶対に使わなさそうです。
教訓
欲しいですか？等の意思を聞くのではミスリードを生む
実際の行動や運用からニーズを汲み取るべき
2. 業務の深掘り前に仮説（案）を見せてしまった
ユーザーさんは良い人が多いので、基本的に肯定してくれます。
直接訪問することが多いため、面と向かって開発者にノーと言ってくれない人も多いです。
ただ、表情を見ていると全く納得していなさそうで貴重な生情報を取り損ねることがありました
教訓
話しの運びの順番が大事
業務理解 → 仮説 → 確認 の手順を守ることで、「先ほど話していたXXの部分が今のままだとできないですが、」等のコミュニケーションができる
3. 優先順位付けをユーザーに丸投げした
「どれが重要ですか？」と聞いても、現場の文脈は反映されません。
なんとなくキャッチーな感じがする機能が大事！と言われてしまうケースもありました。
教訓
優先順位はユーザーの発言からではなく現場の雰囲気や業務フローにかかる手数のヒアリング結果からつけるべき
4. 真っ直ぐな質問だけで核心に届こうとしてしまった
「困っていることは？」と聞いても、
「特にないです」と言われて終わることも多いです。
でも、その裏には“気づいていない課題”が必ずあります。
一足飛びに課題を言ってくれるユーザーは極めて稀です。
教訓
観察 → 仮説 → 深掘り → 再確認 のループの徹底が必要
まとめ：PdMは現場に行くべき
机上でどれだけ考えても、ユーザーの行動や背景、感情を完全に理解することはできません。
だからこそ、
• 現場を見る
• 行動を聞く
• 文脈を捉える
• 仮説を丁寧に更新する
というサイクルが必要です。
PdMは、ユーザーの言葉だけではなく、机の上の紙、ホワイトボード、PCのフォルダ構造、紙のカレンダー等様々な情報に気を配るべきだと考えています。
この記事が、誰かのプロダクトづくりの参考になれば嬉しいです