とりあえずα版です。みなさまのご意見を参考にして、次はβにします。

1. 【課題仮説検証 完全マニュアル】
○インタビュー（検証）の必要性理解
■インタビューの有効性
ユーザの本音を聞き出す手段（つまり仮説の検証手段）として、インタビューが有効な理
由をまず理解する。
仮説の検証手段としてインタビューが必要な理由は３つ
１．最初からユーザの本音を上手に聞き出すようなインタビューを実施することは非常に
難しい。よって、インタビューを重ねるごとにヒアリング能力を上げていく効果がある。
２．
「アンケート」 質問を作成した段階で
は、 「自分たちはすでに正しい質問を用意できた」
と勘違いさせる効果があるとともに、質問する前から「ある種の回答」を期待してしまう
という弊害が多く発生する。また、ユーザに直接対面する機会がないため、正しい相手か
ら回答を得ようとしているのかを確認する手段が存在しない。よって、結果的にアンケー
トの回答はスタートアップが必要なフィードバックを得る機会としては不適切な場合が多
いことを理解する。
３．また、「グループインタビュー」でも参加者には微妙なバイアスがかかることが多く、
ユーザの本音とはかけ離れた回答しか得られない。グループインタビューで得られるのは
あくまで「グループ討議の結論」であり、ユーザの本音ではない。
ただし、インタビューを重ねて「何をどう聞くか？」が洗練され、かつ質問する際に特定
の回答を期待しないようになれたあとは、アンケートは回答の量を増やすためには有効な
手段となる。
つまり、初期のスタートアップにとってインタビューが有効なのは、スタートアップ自身
のヒアリング能力を向上させる効果が最も高いということである。
■デモではなくまずインタビューから始める
ユーザの本音を引き出すには、デモ版の提示は有効な手段となる。しかし、デモ版の提示
が有効なのは、ソリューション仮説に対するインタビューのタイミングからであり、課題
インタビューの実行段階ではデモ版は提示しないほうが有効である。

2. その理由は２つ
１．デモ版を作成する時間が無駄になる
課題仮説が間違っていた場合、当然、ソリューション仮説も崩壊する。よって、時間を有
効に活用するためには、課題仮説はインタビューのみで実施するのが最も時間がかからな
い手段となる。
２．デモ版は答えを誘発したり、インタビューを間違った方向へ進ませる
課題インタビューを実施する際にデモ版を提示すると、デモ版の出来次第では、必ず同じ
答えを誘発したり、ユーザの興味がデモ版の出来栄えに集中する可能性が高い。
課題仮説の検証を行っている際に、ユーザから「ここはこんなインターフェースのほうが
いいのでは？」という答えは必要ない。
■ランディングページから得られる情報とは
ランディングページでのユーザの反応から、課題仮説検証を行うということは基本的にで
きない。ランディングページの統計から得られるのは「ユーザが気に入ったかどうか？」
という１点だけであり、どちらの結果であったとしても、その理由をユーザは残してくれ
ない。
■「自分が欲しいプロダクトを作れば、インタビューは不要？」
よく議題になることであるが、これは、取り組む課題を自ら経験し、かつ自分が代替手段
を常に実行し、そのためにお金も使っている場合に限られる。
また、一見すると自分が抱えている課題は、多くの人も抱えているように思えるが、ユー
ザのセグメント次第ではその発生原因が大きく異なるため、結果として有効なソリューシ
ョンが大きく変化する場合がある。
課題インタビューをスキップすると、こうした違いに気づく機会を失い、結果として時間
と資源の大きなロスに繋がる可能性が高い。
☆教訓まとめ
・課題の仮説検証は対面インタビューで実施する
・課題インタビューは、自分のヒアリング能力を向上させる手段だと思って実施する
・デモ版の構築は課題仮説検証の完了後に着手する
・自分がほしいと思うプロダクトであっても、課題インタビューは必ず実施する

3. ★Ash 師匠のアドバイス
・課題仮説インタビューは最低でも 10 人に実施しろ
・最初はとにかく相手を選ばず実施しろ
・協力者に報酬は出すな
・インタビューの実施を他人に任せるな
・ただしインタビュー計画はアウトソースを検討しろ
○準備編
■インタビューの目的
課題仮説に対するインタビューを行う目的を理解する。
課題インタビューは、以下の４つの情報収集を目的に実施する。
１．課題仮説の検証
⇒ユーザの抱える課題が仮説通りであるかを検証する
２．課題のレベル特定
⇒「ぜったいに解決策が必要」なのか「解決してくれたらラッキー」なのかを特定す
る
３．代替手段のヒアリング
⇒ユーザは現時点で課題に対してどのような代替手段を利用しているかを聞き出す
４．初期ユーザとなるべきセグメントの検証
⇒ヒアリングしたユーザの属性情報を収集し、セグメント化する
■インタビューの完了条件
仮説の検証が完了したと判断可能な条件を理解する。
仮説の検証を繰り返していると、異なる協力者から同じフィードバックが返るなどの「強
いシグナル」を感じる瞬間がある。こうしたシグナルの内容が、課題仮説に対する同じ感
想と同じユーザセグメントとして現れたら、課題仮説の完了と判断してもよい可能性が高
い。
少なくとも、バラバラな回答しか得られていないのに、アポイントを取った人たちへのイ
ンタビューが終了したからおしまい！などということをしてはいけない。
■協力者の要請とアポイント
インタビュー協力者を要請する際と、協力者の数を増やすポイントは２つ。
１．自分が取り組んでいる課題を簡潔に表現する（3 行以内）

4. ２．営業ではないことを明言する（製品はまだないと伝える）
３．30 分以内で完結することを伝える（本当にそうする）
４．正しいセグメントの協力者には、更に協力者を紹介してもらう
■仮説を「検証可能」な表現にして、主要な３つを選択する
「モバイルユーザは使えるアプリを探しているはずである」
などという表現のままでは、せっかく対面によるインタビューを実施してもまったく意味
はない。
「はい、探してます」
という答えが返って来ておしまいになるのは目に見えている。
仮説の検証を行う際には、返ってきたフィードバックに対するアクションが可能なレベル
に落としこみ、さらにそこから主要な３つまで絞り込む。
これを、ターゲットするセグメントごとに設定する。
■インタビューシナリオの作成
課題インタビューのシナリオは以下の構成で作成する。
１．welcome
・自分がどのような課題に対して取り組んでいるかを簡単に説明する（10 秒ぐらい）
・自分がどうしてそのような課題に取り組むようになったのかを簡単に説明する（10 秒ぐ
らい）
・インタビューがどのように進むかを説明する
・営業目的でないことを再度説明する（自分への言い聞かせも含めて）
２．ユーザセグメントの確認
・インタビュー対象者が初期ユーザとなりえるかをセグメントで判断可能にするために、
ユーザの立場や状態を確認する。
３．課題をストーリーで語る
・取り組んでいる課題の背景を、３つの主要な課題ストーリーで説明する
では私たちが取り組んでいる課題についてお話させて頂きます。
４．課題をランク付けして説明する

5. ・課題の重要度をランク付けして説明する。
ここで質問：
説明した課題に共感したかを聞き、さらに重要度があっているか確認する。
もし他にも重要だと思う課題があれば、それもヒアリングする。
５．ユーザの現在の取り組みを聞く（メインパート）
・課題に共感いただいた場合、以下を話ししていただく
・その課題はどうしても解決しなければならない問題か？
・もしそうなら、いま現在はどのような取り組みを行っているか（代替手段）
６．ラップアップ
・インタビュー対象者に興味を持ってもらうために、再度コンセプト説明
・ソリューション仮説検証への協力依頼
・他のインタビュー候補の紹介依頼
○実行編
■最大厳守事項！！
課題インタビュー実施中に、ソリューションを提示しない！！！
あせる気持ちは重々わかるが、課題の検証中には絶対にソリューションを提示どころか示
唆もしてはいけない。回答は常に誘導される。
どうしても聞きたいという場合、課題インタビューが完全に終了して一呼吸おいてからに
すること。
また、その際にも決して製品案を説明してはいけない。
あくまで示唆するのは「ソリューション案」にすること。
例：NG パターン「SNS の提供を検討しています」
OK パターン「ソーシャルのチカラを利用できないかと考えています」
理由
１．スタートアップ自身が「まだ製品案は決まっていない」と自覚できる
２．製品案を提示すると、協力者からは「YES/NO」の答えしか得られないが、ソリューシ
ョン案を提示すると更に詳しい課題がフィードバックされる可能性が高い。
■インタビュー内容のまとめ

6. 聞いた内容は、協力者と別れてから５分以内に書き始めること！
インタビュー中にとったメモも、５分以内にすぐに読み返し、書き漏らしていることがな
いかをチェックする！