顕在ニーズと潜在ニーズの違い
目次
顕在ニーズは、本人が自覚し、言葉にできる要望や困りごとです。潜在ニーズは、本人がまだ十分に自覚していない、または言葉として整理できていない目的や困りごとを指して使われます。ただし、「顧客が言わなかったこと」をすべて潜在ニーズと呼ぶことはできません。
顧客の発言と実際の行動を手がかりに、背景にあるニーズを仮説として考え、確かめることが大切です。この記事では、両者の区別と、推測を事実に変えずに扱う方法を説明します。調べ方の全体像は顧客ニーズを把握するには？で紹介しています。
- 顕在と潜在は、本人が自覚し、言葉にできているかを手がかりに分ける。
- 発言、観察した行動、そこから考えた仮説を別々に残す。
- 言われていないニーズを断定せず、別の説明も考えて確かめる。
顕在ニーズと潜在ニーズを区別する
本記事では、顕在ニーズを「本人が自覚して表現できるもの」、潜在ニーズを「まだ十分に自覚されていない、または整理されていないもの」として扱います。固定的に人を分類する言葉ではなく、ある場面でニーズがどこまで認識されているかを見るための区別です。
| 観点 | 顕在ニーズ | 潜在ニーズ |
|---|---|---|
| 本人の認識 | 困りごとや欲しい状態を説明できる | 目的や困りごとを十分に整理できていない場合がある |
| 調査で得られる手がかり | 要望、具体的な不満、達成したいことの説明 | 行動の工夫、繰り返す手間、発言と行動の違いなど |
| 扱う際の注意 | 表現された解決案だけで背景まで分かったとしない | 手がかりから考えた内容は、確認前には仮説とする |
「印刷できるようにしてほしい」は、表明された要望です。しかし、なぜ紙が必要なのかまでは、その一文だけでは分かりません。紙の提出が決まりなのか、一覧で確認したいのか、持ち歩きたいのかで、達成したいことは異なります。
背景を尋ねると、本人が以前から分かっていたことが説明される場合もあります。それを聞き手が初めて知ったというだけで、「潜在ニーズを発見した」とする必要はありません。
話に出なかった理由を決めつけない
言葉にされなかった理由には、質問されていない、今回は話題と関係がない、答えにくい、思い出せないなど、さまざまな可能性があります。アンケートの自由記述が空欄でも、ニーズがないとも、隠れたニーズがあるとも判断できません。
反対に、本人が慣れてしまい、手間だと思っていない作業が見つかることもあります。ただし、作業を省けば必ず喜ばれるとは限りません。手作業で確かめることに意味がある場合や、社内の確認手順として必要な場合もあります。
たとえば数字を書き写す行動を見て、「自動化したいはず」と結論づける前に、何のために写しているかを確認します。考えた解決策を欲しがっているという解釈に飛ばないことが重要です。
ユーザーの問題に焦点を当て、思い込みではなく調査の根拠からニーズを整理する考え方は、英国政府のサービス設計ガイド（GOV.UK）の利用者ニーズの説明でも示されています。
発言と観察と仮説を分けて残す
以下は、架空の業務ツールで週次報告を作る人を調べた例です。実在する顧客の発言や、アーコレの機能・実績ではありません。
| 区分 | 記録例 |
|---|---|
| 本人の発言 | 「報告用の数字をまとめて印刷できると助かります」 |
| 観察した行動 | 調査中の作業再現で、三つの画面を順に開き、数字を表計算へ転記した。実際の報告当日は見ていない |
| ニーズの仮説 | 報告の準備で、複数の情報を一度に見比べたいのかもしれない |
| 別の説明 | 紙で提出する決まりがある、転記時に数字を確認している、といった可能性もある |
| 次に確かめること | 報告先が求める形式、転記後の使い方、紙が必要な場面を聞く |
「そう発言した」という事実と、発言の内容が実際に起きたと確認できたことは別です。「毎週同じことをしています」と聞いた場合も、毎週の行動を直接観察したわけではありません。本人の説明として記録します。
また、観察は事実を得る方法の一つですが、見えた行動から気持ちまで分かるわけではありません。「画面を何度も切り替えた」は観察できても、「不安だから切り替えた」は確認が必要な解釈です。
見聞きした内容と、それが何を意味するかを分ける方法は、GOV.UKの調査分析ガイドでも勧められています。正確な発言を残していない場合は引用符で囲まず、「発言の要約」と書きます。
仮説に合わない説明も確かめる
仮説を立てた後は、「やはり一画面にまとめたいですよね」と同意を求めるのではなく、作業の目的を具体的に確認します。架空例では、次のような質問が使えます。
- 最後に報告を作ったとき、転記した表をその後どのように使いましたか。
- 報告を受け取る人から、提出形式について何か指定されていますか。
- 紙を使わずに済んだ場面があれば、そのときはどうしましたか。
- 数字を写している間に、確認していることはありますか。
相手が「会議で違う数字を見比べるため」と答えれば、比較したいという仮説を支える材料になります。一方、「提出先に決まった紙の様式がある」と答えたら、表示を一画面にまとめるだけでは目的を満たせないかもしれません。
ここで「見比べたい」が確かめられても、元から本人が自覚していた目的なのか、話す中で整理された目的なのかは、区別して残せます。ニーズの名前を付けることより、何を達成したいのかを正確に理解することを優先します。
本人に要約を返して認識を確かめることは有効ですが、「はい」と答えた一回だけで原因や解決策が確定したとはしません。必要なら別の場面や、同じ作業を行う別の人にも確かめます。聞き取りの進め方はユーザーインタビューで何を聞く？で説明しています。
ニーズの仮説を検証できる形に書く
記録には「潜在ニーズあり」とだけ書かず、誰が、どの場面で、何を達成したいと考えたのかを残します。次のテンプレートを使うと、確かめる前の推測を見分けられます。
ニーズの仮説のテンプレート
- 対象と場面：［誰が、いつ、何をしているか］
- 発言や行動の根拠：［元の記録と、その確認方法］
- 達成したいことの仮説：［何を、なぜ、できるようにしたいか］
- 別の説明：［ほかに考えられる理由］
- まだ分からないこと：［確認が必要な条件や範囲］
- 確認方法：［誰に何を聞くか／何を試すか］
- 確認後の更新：［支持された内容／修正した内容／未確認点］
解決案を試す場合も、ニーズと案を別に扱います。「数字を見比べたい」という目的が分かっても、印刷、一画面表示、出力用の表のどれが合うかは別の問いです。試作品で作業を行ってもらい、目的を達成できるかを見ます。仮説を試作品などで早く確かめる進め方は、GOV.UKのサービス基準でも示されています。
よくある質問
潜在ニーズは顕在ニーズより優先すべきですか
分類だけでは優先順位を決められません。誰のどの作業に影響するか、根拠はどこまであるか、改善に必要な負担は何かを見て判断します。明確に表明された困りごとでも、影響が大きければ重要です。
AIに顧客の発言を読ませれば潜在ニーズが分かりますか
解釈の候補を考える補助には使えますが、出力は確認済みの顧客の意図ではありません。元の発言にない目的を加えていないかを確認し、必要な検証を行います。顧客情報を入力する際は、利用が認められた環境と情報の範囲を守ります。
まとめ
顕在ニーズと潜在ニーズの違いは、本人がどこまで自覚し、言葉にできているかにあります。言葉にされていないことを決めつけず、発言と観察を残し、仮説を確かめてください。
確かめたニーズを元の声とつなげて扱う手順は、機能要望管理の基本で紹介しています。継続的な管理を検討する際は、アーコレのサービス紹介もご覧ください。
