キーニーズ法ヒアリング＆分析スキル

このスキルは、梅澤伸嘉氏の「キーニーズ法」に沿って、ユーザー（インタビュイー）から潜在ニーズを引き出すヒアリングを行い、そのやり取りを会話ログとして保存し、最後に「強さ×未充足度」の2軸で分析してキーニーズ候補を提示するためのものである。ヒアリングと分析を1つの流れとして連続実行することを基本とする。

0. 開始時の確認

• ヒアリングのテーマ（対象の商品・サービス・業務・生活シーンなど）が既に指定されていればそのまま開始する。未指定の場合のみ、テーマを1つ確認する質問をする（この確認は具体的な候補を添えてよい。これは対象範囲を絞るための中立的な選択肢の提示であり、ユーザーの発言内容を先回りして決めつける第1節の推測禁止事項とは異なるため、その例外には当たらない）。
• テーマが決まったら、ログファイルを作業ディレクトリに作成する（ファイル名の目安: key-needs-log_<テーマ>_<YYYYMMDD-HHMM>.md）。ファイル名に使うテーマ文字列は、/・\・..・OSで使用できない記号などを除去または安全な文字に置換してから使用し、作業ディレクトリ外への書き込みや意図しないパスの生成を防ぐ（第5節の分析レポートのファイル名でも同じサニタイズ規則を適用する）。以降、ユーザーの発言とこちらの質問をターンごとに、要約せずできるだけそのまま追記していく。このログが後の分析の唯一の根拠になるため、省略や言い換えをしない。

1. ヒアリングの基本構造（1つの生活シーン／場面ごとに繰り返す）

必須・厳守事項: 質問を投げる際、ユーザーが回答する前にこちらの予想・想定・仮説（「〇〇ということですか」「おそらく〇〇だと思いますが」等）を先に述べてはならない。理由は、こちらの推測を先に提示すると、その内容がユーザーの思考の枠を決めてしまい、ユーザー本来の言葉・潜在ニーズが引き出せなくなるためである。質問は常にオープンな問いかけそのものとして投げ、答えの方向性を誘導する前置きを付けない（ただし第0節に定める「テーマ確認時の中立的な候補提示」と第3節に定める「ユーザーが回答に困ったとき」の選択肢提示は、いずれもユーザーの発言内容を先回りして決めつけるものではなく、対象範囲を絞る／会話を止めないための足場作りであり、この禁止事項には該当しない）。

梅澤理論のCAS的な深掘りに沿って、1つの場面につき次の3段階を意識して質問する。ただし段階を機械的に告げる必要はなく、自然な会話の中でこの順序を辿る。

1. Q1: 生活ニーズの把握 — 「〇〇について、どんな時にどうありたいですか」「そもそも何のためにそれをしますか」など、まず場面と欲求を大きく開いた質問で引き出す。
2. Q2: 現状の行動の深掘り — 「実際には今どうしていますか」「なぜそのやり方をしているのですか」「その時どう感じますか」を2〜3往復繰り返し、行動の背景・理由・感情を掘り下げる。
3. But: 問題点／不満の抽出 — 「そのやり方で困っていることは何ですか」「本当はどうしたいですか」「我慢していることはありますか」で、現状とのギャップ（未充足ニーズの種）を引き出す。

2. 視野を広げる工夫（必須）

• 質問は基本的にオープンクエスチョンにする（はい/いいえで終わる質問は避ける）。
• 1つの場面が掘り尽くされたと感じたら、話題転換で視野を広げる。「では別の場面ではどうですか」「逆に時間がたっぷりある時は？」「もし〇〇が使えなかったら？」など。
• 別の視点の提案も積極的に行う。「家族や同僚から見るとどうですか」「もし専門家だったらどう考えると思いますか」など、立場や状況を変えた問いかけでアイデアの幅を広げる。
• 深掘りと話題転換はバランスを取る。同じ場面を深掘りしすぎない一方、広げすぎて浅くならないよう、1場面につき最低でもQ1→Q2→Butの一巡はしてから転換する。

3. ユーザーが回答に困ったときの対応（必須）

• 「わからない」「うまく言えない」「特にない」といった反応があった場合、同じ抽象度のオープン質問を重ねて詰まらせない。
• その場合は、それまでの発言から推測できる具体的な選択肢を2〜4個提示し、選んでもらう形に切り替える（例:「例えば、A:時間がかかるのは嫌、B:やり方が分かりにくい、C:仕上がりが不安、のどれかに近いですか？それとも別の理由がありますか」）。
• 選択肢から選んでもらったら、そこを起点に再びオープンな深掘り質問（なぜそう感じるか等）に戻す。選択肢はあくまで会話を止めないための足場であり、選ばせて終わりにしない。

4. ログの保存（必須）

• ヒアリング中は発言のたびにログファイルへ追記する（ターン単位でまとめて記録してもよいが、セッション終盤にまとめて書き起こすことは避ける＝欠落・記憶違いを防ぐため）。
• ログには最低限、質問と発言をそのままのテキストで記録する。可能であれば場面・段階（Q1/Q2/But）のラベルを添えると後の分析がしやすい。
• ヒアリングが一区切りついたら、ログを保存済みであることをユーザーに伝えてから分析フェーズに進む。
• ログには氏名・連絡先・勤務先など個人を特定できる情報や機密情報を含む場合がある。そうした情報が話題に出た場合は、ログ・レポートに含めてよいかをユーザーに確認し、含めない、または伏字にすると回答された内容は忠実にその通り扱う。ログとレポートの保存場所・保持期間・削除方法は、プロジェクト側に既存のルールがあればそれに従い、なければユーザーに確認する。

5. 分析フェーズ

ヒアリングが一通り終わったら（または既存のログを分析してほしいと言われたら）、次の手順で分析する。

1. ログ全体を読み返し、発言の中から「潜在ニーズ」を抽出する。各ニーズには根拠となる発言を短く引用して添える（推測で終わらせず、必ずログに根拠を持たせる）。
2. 抽出した各ニーズについて、以下の2軸を5段階程度で推定する。
   • 強さ: 発言の頻度、感情の強さ、生活・業務への影響度から推定。
   • 未充足度: 現状の代替手段への満足度の低さ、我慢・妥協の度合いから推定。
3. 「強さ×未充足度」のマトリクス表（または簡易な散布図）を作成し、両方が高い領域にあるニーズを「キーニーズ候補」として明示する。可視化が有効な場合はdataviz skillを使って散布図にしてもよい（必須ではない）。
4. 分析結果を分析レポート（key-needs-analysis_<テーマ>_<YYYYMMDD-HHMM>.md）としてまとめる。構成の目安:
   • ヒアリング概要（テーマ、対象、実施日）
   • 抽出ニーズ一覧（発言引用付き）
   • 強さ×未充足度マトリクス
   • キーニーズ候補とその根拠
   • 次のアクション案（コンセプト仮説の方向性など、あれば）

6. 成果物の受け渡し

• 会話ログと分析レポートの両方をファイルとして保存し、ユーザーに届ける。ヒアリングログは1回性の記録、分析レポートも都度の成果物として扱ってよい（継続的に更新・共有するものでなければ、通常のファイル納品でよい）。

7. 注意点

• 【最重要・厳守】ユーザーが回答する前に、こちらの推測や想定を口にしない。 ヒアリング中の質問はもちろん、雑談的なやり取りの中でも「たぶん〇〇ですよね」「〇〇という理由ではないですか」のような先回りの決めつけ・仮説の提示を、ユーザー自身が言葉にする前に行ってはならない。理由は、そうした先回りの発言がユーザーの思考を誘導・限定してしまい、キーニーズ法が本来引き出すべき「ユーザー自身の言葉による潜在ニーズ」を歪めるためである。第3節で定める選択肢提示（ユーザーが詰まった場合の例外的な足場作り）のみがこの原則の例外であり、それ以外の場面では常にオープンな問いかけに徹する。
• 推測（潜在ニーズ、強さ、未充足度の見積もり）には必ずログ中の発言を根拠として添える。根拠のない断定はしない。
• ユーザーの発言を歪めたり過度に一般化したりせず、忠実に記録・引用する。
• オープンクエスチョンでの深掘りを基本としつつ、ユーザーが詰まった時だけ選択肢を出す、というメリハリを毎ターン意識する。