インタビューを重ねても、欲しい機能しか返ってこない──PdMが「最後に困った場面」まで戻る聞き方

顧客インタビューを終えるたびに、機能要望は増えていく。「一覧でまとめて変更したい」「通知を細かく設定したい」「この画面だけで全部を確認したい」。話は具体的で、議事録も埋まっている。それでも企画会議になると、どの課題から解くべきかを選べない。

欲しいものを聞いたのだから、要望が返ってくるのは自然である。問題は、顧客が課題をうまく話せないことではない。こちらの質問が未来の理想へ寄り、直近に実際に起きた行動、迂回、諦めた条件を確認できていないことにある。

PdM、PO、上流SEが次に持つべきなのは、要望を増やす質問票ではない。最後に困った一件を、`直前 → 行動 → 迂回 → 結果` の順で復元する一枚のメモである。

要望だけが増えるとき、質問は未来へ寄っている

「どんな機能が欲しいですか」「理想の状態は何ですか」と聞けば、相手は解決案を考えてくれる。業務を知る人から出る案には、現場の痛みが含まれている。だから、機能要望を軽く扱う必要はない。

ただし、要望は観察できた事実と同じではない。「一括変更が欲しい」という言葉だけでは、何をまとめたいのか、どの場面で止まるのか、いまはどう切り抜けているのかが分からない。発生頻度も、ほかの利用者に同じ問題があるかも、まだ確認できていない。

この状態で要望を一覧化すると、強く話された案や作りやすい案から検討しやすくなる。選んだ理由が、課題の重さではなく、発言の分かりやすさへ引っ張られてしまう。

最後に困った一件を、四段階で戻る

次は仮想ケースである。利用者から「商品情報を一括で更新できる機能が欲しい」と言われたとする。ここで仕様へ進まず、まず「それが必要だと感じたのは、一番最近ではいつでしたか」と聞く。

その一件について、次の四つを時間順に確認する。

1. 直前：困る直前に、何が起き、何を受け取ったか

2. 行動：最初にどの画面や資料を開き、何をしたか

3. 迂回：進まなくなったあと、誰に聞き、何で代替したか

4. 結果：最後に何が終わり、何が残ったか

たとえば、価格変更の連絡を受け、対象商品を一件ずつ探し、途中で一覧を別ファイルへ書き出し、差分を確認してから入力へ戻った、という流れが見えるかもしれない。すると、確認すべき論点は一括更新の有無だけではなくなる。対象を探す条件が足りないのか、変更内容の確認に時間がかかるのか、入力後の検証が難しいのかを分けられる。

四段階は、インタビューの外部標準ではなく、この記事で提案する実務上の整理法である。大切なのは四つの言葉を守ることより、意見を増やす前に、実際の一件を起点から終点までつなぐことだ。

復元している途中では、正しい業務手順へ直そうと急がない。「本来はそうしない」「前回だけ特殊だった」という補足が出たら、それも消さずに残す。理想の手順と、その日に実際に選ばれた行動の差に、迷い、制約、代替手段が現れるからである。聞き手が先に整った説明へ変えると、困った地点も一緒に見えなくなる。

要望と事実を分けて、採用判断へ渡す

インタビュー後のメモでは、聞いた内容を一つの箇条書きに混ぜない。最低限、次の三つに分ける。

• 要望：本人が欲しいと話した解決案

• 確認できた事実：その一件で実際に行った操作、迂回、残った問題

• 未確認：頻度、影響範囲、ほかの利用者にも起きるか

一枚のメモでは、上半分に四段階の時系列を置き、下半分に要望、確認できた事実、未確認事項を並べる。会議へ持ち帰るときも、要望の数を報告するのではなく、「どこで止まり、何で迂回し、次に何を確かめるか」を説明する。これなら、開発へ渡す前に追加インタビューが必要なのか、利用記録を確認するのか、小さな運用変更を試すのかを選びやすい。

聞けなかった欄は、推測で埋めない。「未確認」と残すこと自体が、次の質問と調査の順番を決める材料になる。

先ほどの仮想ケースなら、一括更新は要望である。一件ずつ対象を探したこと、別ファイルへ書き出したこと、入力へ戻ったことは、その会話で確認した事実になる。一方で、それが毎週起きるのか、同じ職種の人にも起きるのか、業務全体でどれほど影響するのかは未確認のままである。

ここまで分けると、選択肢を「要望どおり作る」「作らない」の二択にしなくて済む。検索条件を見直す、変更前後を比較しやすくする、運用を変える、別の利用者にも聞く、利用記録で頻度を確かめる、といった次の調査や判断へ進める。

一人の発言から、ニーズの普遍性や市場規模までは決められない。インタビューで見つけたのは、検証すべき具体的な場面である。採用判断には、別の利用者の行動、問い合わせ記録、利用データ、事業上の優先順位など、目的に合う材料を追加する必要がある。

次のインタビューで変えるのは、一問でいい

質問票を全面的に作り直さなくてもよい。機能要望が出たときに、「それで最後に困った一件を、直前から教えてください」と一問を足す。答えが抽象的なら、行動、迂回、結果の順に戻る。

PdMの価値は、欲しい機能をたくさん引き出すことだけではない。相手が差し出した解決案を否定せず、その案が必要になった現実の場面まで戻り、チームが課題を選べる材料へ変えることにある。

次のインタビューで聞き直すなら、直前、行動、迂回、結果のどこから始めますか。

次に読む：

はじめての方へ：

マガジンの紹介：

IT業界の「技術×キャリア×整える」を束ねるマガジンを公開中です！
ビジネスや心と体を整える良記事が集まってきていますので、
是非、覗いてみてくださいね。
記事は全て無料記事のみです。
気に入って頂けたらマガジンのフォローもよろしくお願いします！
共同マガジンに参加希望の方も募集中です！