結論:商品への賛成より、最近の行動を聞く
顧客ヒアリングの目的は、自分のアイデアに賛成してもらうことではありません。誰が、どんな場面で、何に困り、いまどう対処しているかを理解することです。起業前なら、商品説明を急ぐより「最後にその作業をしたとき」の話を具体的にたどる方が、提案の前提を確かめやすくなります。
相手が「便利そう」と言ってくれても、支払いや導入の条件はまだ分かりません。逆に、商品案への反応が弱くても、別の深刻な問題が見つかるかもしれません。会話の成功を「褒めてもらえたか」で測らず、「事前には知らなかった事実が増えたか」で振り返りましょう。
以下は、英国政府の公開調査ガイドを手がかりに、創業者向けに編集した準備・質問・記録の方法です。質問例と時間配分は編集部の提案です。特定の人数を聞けば需要が証明される、という使い方は想定していません。
1.話しやすい人より、確かめたい経験を持つ人を選ぶ
まず決めるのは、年齢や役職だけではなく、どの経験を持つ人に話を聞くかです。「経理担当者」より「直近の月次締めで複数部署の数字を集めた人」の方が、聞くべき出来事が明確になります。想定する利用者に加え、その作業をやめた人、別の手段でうまく解決している人も比較候補です。
GOV.UKの参加者募集ガイドは、実際の利用者または利用する可能性のある人を対象とし、募集方法や日時などによる偏りに注意を促しています。対象条件と募集経路を記録する発想は、少人数の聞き取りにも使えます。GOV.UK「Finding participants for user research」
- 利用する人:実際の手順と不便を知っている。
- 費用を承認する人:予算、優先順位、比較対象を知っている。
- 導入を支える人:設定、情報管理、現場変更の制約を知っている。
一人がすべてを兼ねる場合もありますが、立場が分かれるなら同じ答えを期待しないことが大切です。知人から始めても構いません。ただし、知人は断りにくい可能性があります。応援の気持ちと業務上の必要性を分けるため、関係性をメモし、別の募集経路でも確かめます。
募集文には、研究目的、対象となる経験、所要時間、形式、謝礼の有無を書きます。「困っている方限定」と絞りすぎると、困らない条件が見えなくなります。録画必須のオンライン面談だけでは参加しにくい人もいるため、必要に応じて音声だけ、対面、文字などの選択肢を検討します。
利用者には自分が行った作業、承認者には実際に判断した条件、導入支援者には自分が対応した設定や移行を聞きます。全員に同じ質問を当てはめず、その人が直接経験した範囲を聞き、他人の行動の推測と混ぜないようにします。
2.調べたい問いを三つ程度に絞り、録音は事前に説明する
一回の面談で、市場規模、機能、価格、営業先まで全部を決めようとすると、広く浅い会話になります。たとえば「いつ問題が起きるか」「いまの対処で何が残るか」「変更の決定に何が必要か」のように、今回は何を判断するための会話なのかを絞ります。三つは整理の目安で、調査方法の規則ではありません。
質問表は台本より地図として使います。基本となる話題、最初の問い、具体化する追問、最後に確認したい点を一枚にします。面談前に別の人と練習すると、「運用」「効率化」のように相手によって意味が変わる言葉や、一度に二つを聞いている質問に気づけます。
参加者には、目的、記録方法、共有先、保管期間、途中でやめられることを説明しましょう。GOV.UKの同意ガイドも、参加者が研究内容とデータの使い方を理解したうえで参加する手順を示しています。ここでは調査の参考として紹介しており、日本の法的義務をこの資料だけで判断するものではありません。GOV.UK「Getting informed consent for user research」
自動文字起こしやAI要約を使うなら、そのサービスにどの情報が渡るかも事前に確認します。録音を断られたらメモへ切り替えられるようにし、画面共有では顧客名や個人情報を隠してもらいます。研究参加への同意と、広告への実名掲載や営業連絡への同意をひとまとめにしないことも大切です。
3.誘導しやすい質問を、具体的な出来事に直す
「大変ですよね」「こんな機能があれば使いますか」は、自分が期待する答えを含みやすい質問です。相手は礼儀として肯定するかもしれませんし、将来の行動を正確には予測できないこともあります。まずは、実際にしたこと、しなかったこと、そのときの条件を聞きます。
GOV.UKの面談ガイドは、開かれた中立的な質問と、一般論より実例に焦点を当てることを勧めています。この原則を創業時に使うなら、機能を先に見せず、具体的な出来事をたどった後で必要に応じて提案の評価へ移る方法が考えられます。GOV.UK「Using in-depth interviews」
「なぜ」と聞くこと自体が悪いわけではありません。ただし、「なぜ改善しないのですか」のような問いは、相手の判断を責める響きがあります。「前回、別の方法を検討したことはありましたか」「そのとき何が必要でしたか」と聞き直すと、予算や権限など背景を話してもらいやすくなります。
質問例をそのまま使うより、相手の表現を返す方が正確です。「手間がかかる」と言われたら、「手間というのは、どの作業でしょう」と確かめます。そこで勝手に「入力時間ですね」と要約すると、実は承認待ちが問題だった、という違いを失います。
4.一つの実例を、きっかけから意思決定までたどる
面談を三十分で行う場合の一案は、導入と説明に五分、直近の実例に十五分、残りを補足と確認に使う配分です。これは編集上の例であり、複雑な業務なら時間を延ばすか対象範囲を狭めます。質問を全部消化することより、一つの場面を取り違えずに理解することを優先します。
- 出来事を選ぶ:「最後にその作業をしたのはいつですか」。
- 流れを追う:「何から始め、次に何をしましたか」。
- 対処を確かめる:「止まった場面があれば、どう乗り切りましたか」。
- 影響を聞く:「その結果、ほかの仕事に何が起きましたか」。
- 決定を調べる:「やり方を変えるとき、誰に何を確認しますか」。
金額や時間は、答えが出ないなら無理に精密化しません。「だいたい」「記録で確認した値」を区別し、可能なら後で根拠を確認します。実際の帳票や画面を見せてもらえる場合も、必要な範囲だけにし、社外秘や第三者の個人情報は除いてもらいます。
相手が話し終える前に、自分の解決策を差し込まないようにします。沈黙をすぐ埋めず、曖昧な点は自分の理解を短く返して確かめます。「困らなかった」「別に不満はない」という話も重要です。その条件を知ると、無理に提案しなくてよい顧客層が見えてきます。
5.発言、観察、自分の解釈を分けて記録する
メモに「自動集計が欲しい」とだけ残すと、その言葉を誰が言ったのか、どんな出来事から出たのかが失われます。発言した内容、実際に見た行動、自分の解釈を分け、後から戻れる日時や面談番号を付けます。引用で共有する場合は、逐語記録で確認できる部分だけを引用にします。
GOV.UKの分析ガイドも、見聞きした観察と、それが意味する解釈を分けて整理し、次の行動へつなぐ構成です。最初から機能一覧を作るより、何を根拠に何を変えるのかを追える形にします。GOV.UK「Analyse a research session」
整理は同じ日のうちに短く行い、「予想どおり」「予想外」「まだ不明」の三つを残します。複数人の記録を比べるときは、発言の数だけで順位を決めず、問題が起きる頻度、影響、現在の対処、変える権限がそろう条件を見ると、次の提案につながります。
AIで要約した文は原記録そのものではありません。主語が入れ替わったり、曖昧な発言が断定に変わったりしていないか確認します。一人の強い言葉に引っ張られたと感じたら、その解釈に反する記録を探し、足りなければ次の面談で確かめます。
実演:「集計が大変」を三つの仮説に分ける
以下の発言・回答・記録はすべて教材用に作った架空のものです。実際の顧客の引用や実調査の成果ではありません。最初の回答を「月末の集計が大変で、いつも遅くなります」と置きます。この一言だけでは、入力作業、回答待ち、確認のやり直しのどれが重いか分かりません。
表が収まらない場合は横にスクロールできます →
| 考えられる解釈 | 区別する追加質問 | その解釈を弱める回答 |
|---|---|---|
| 手入力の量が多く、作業そのものが長い。 | 直近1回について、ファイルを受け取ってから提出まで、どの順で何をしましたか。手を動かした時間と待った時間を分けられますか。 | 入力は短時間で、ほとんどが回答待ちだった。 |
| 拠点からの提出や承認を待って締切を超える。 | 最後に届いたものは何で、いつ依頼し、いつ受け取りましたか。それを待つ間は何をしていましたか。 | 必要なものは早く揃っており、受領後の作業が長かった。 |
| 項目の意味が揃わず、差戻しが続く。 | 直近に確認し直した項目は何でしたか。最初と修正後で何が変わりましたか。 | 項目の解釈違いも差戻しもなく、別の工程で止まっていた。 |
三つの解釈は同時に成り立つ場合もあります。選択肢を先に読み上げて一つを選ばせるのではなく、直近の出来事の順序を聞いてから、残った不明点を掘り下げます。正確な時間を覚えていなければ概算と記し、機密の帳票を無理に見せてもらいません。
追加回答から、次の事業判断まで記録する
仮に追加回答が「入力は約20分。二つの拠点に人数の数え方を確認し、回答まで翌日を待った」だったとします。ここから「自動集計ツールが必要」とはまだ結論できません。
表が収まらない場合は横にスクロールできます →
| 発言の記録 | 入力約20分、人数の定義を2拠点に確認、翌日まで回答待ち。いずれも本人の説明で、時間の実測ではない。 |
|---|---|
| 観察できたこと | この設定では画面・作業・ログを見ていない。観察欄は「未確認」。話を聞いたことと、工程を直接観察したことを分ける。 |
| 仮の解釈 | 少なくともその回は、入力速度より項目の定義と受渡しが遅延に関係した可能性がある。 |
| 別の説明 | その月だけ担当者が不在だった可能性、他の月には大量入力がある可能性。1回の記憶だけでは区別できない。 |
| 次の確認 | 別の直近回でも同じ項目で止まったかを聞く。合意が得られれば、個人情報を含まない項目定義の例で確認の流れを確かめる。 |
| いまの判断 | 入力自動化の開発は保留。定義のずれが繰り返されるなら、項目説明を揃える小さな試験を提案する。購入権限・予算は別に確認する。 |
自分の記録も「元の回答→複数の解釈→区別する質問→追加回答→まだ残る説明→次の判断」の順で一段ずつつなげます。追加回答が入力の長さを示したなら、上の結論を使い回さず、入力工程の確認へ戻ります。質問の目的は用意した商品へ誘導することではなく、選ばなかった説明を残しながら次の調査を絞ることです。
同様に、メモに「確認に2日」とだけあっても、2日×8時間=16時間の削減効果とは計算できません。経過日数か実作業時間か、誰の時間かを分け、許可された工程メモや時刻の記録で確かめます。問題が起きなかった直近回も聞くと、例外的な不在と繰り返す工程の問題を区別しやすくなります。待ち時間が減る価値と人件費削減、支払意思はそれぞれ別に検証します。
6.聞き取りだけで、購入や市場規模を決めない
ヒアリングで分かるのは、話を聞けた相手の経験と説明です。記憶違いもあれば、面談だから丁寧に考えてくれることもあります。「欲しい」と言われた数をそのまま販売見込みに置くのは避け、実際の見積もり、試験利用、購入といった別の場面で確認します。
また、人数の多さだけで質が決まるわけではありません。同じ知人経由で似た人を増やすより、購入しなかった人や異なる承認経路の人を加える方が、判断が変わることがあります。少数の調査を市場の割合に一般化しないことと、少数だから何も分からないと諦めないことを両立させましょう。
- 同意が続く:質問に答えを含めていないか、具体例に戻って確認する。
- 要望だけ増える:その機能が必要になった出来事と現行手段を聞く。
- 話が食い違う:どちらが正しいか決める前に、立場と場面の違いを調べる。
- 全員が好意的:断った人や非利用者が、募集段階で消えていないか見直す。
課題の聞き取りから営業へ切り替える場合は、切り替えることを伝えて同意を取ります。「調査だけ」と案内しておいて、最後に購入を強く迫る進め方では、今回の回答も次の協力もゆがめてしまいます。
7.次の面談では、質問よりも判断を一つ用意する
面談の前後に一文ずつ書くと、情報収集が積み上がります。前には「この話を聞いて、何を決めたいか」。後には「何が分かり、何が分からず、次に何を確かめるか」。件数をこなすこと自体を目標にしないための小さな仕組みです。
- 対象となる経験を定義し、異なる募集経路の候補を探す。
- 調べたい問いを絞り、最近の出来事を聞く質問に直す。
- 目的・時間・記録・共有範囲を事前に説明する。
- 当日は実例を追い、解釈が合っているか本人に確かめる。
- 記録を整理し、次の相手か次の試験を一つ決める。
課題と現行手段が分かり、対象条件にも共通点が見えてきたら、次は価格と範囲を示す試験提案です。逆に、誰がいつ困るのかが面談のたびに変わるなら、いったん対象の定義を見直します。良い聞き取りは、答えを増やすだけでなく、いま決めなくてよいことも明らかにします。
次の聞き取りに持っていく空欄メモ
- 今回決めたいこと/対象に合う経験:__/__
- 記録ID・日付/根拠の所在:__/__
- 聞いた説明(原文か要約か明記):__
- 見た行動・資料(未確認ならそのまま):__
- 自分の解釈/別の説明:__/__
- 区別するための質問・確認資料:__
- 未確認/次の質問または小さな試験:__/__
- どの情報があれば判断を変えるか:__
価格付きの提案に進む段階では、需要検証の計画と判断条件を別に置きます。聞き取りで困りごとが分かっても、購入が確認できたことにはなりません。
参考にした一次資料
本文中のリンクとあわせて、判断の前提を確かめるためにご利用ください。制度やサービスの内容は変更されることがあります。
- GOV.UK「Finding participants for user research」参照確認:2026-10-05
- GOV.UK「Getting informed consent for user research」参照確認:2026-10-05
- GOV.UK「Using in-depth interviews」参照確認:2026-10-05
- GOV.UK「Analyse a research session」参照確認:2026-10-05
この記事は一般的な情報の整理を目的としています。個別の税務・法務・金融判断を保証するものではありません。判断に使う制度・条件は、最新の一次資料や専門家にご確認ください。
制作方法・更新方針について