# リーン顧客開発（5章～7章）
## 5章　オフィスから飛び出せ
### 5.1 模擬インタビュー
初めての顧客インタビューの前に、**模擬インタビュー**を行い手順を確認すると良い。
相手はできるだけ事情を理解している会社の同僚に設定し、緊張感を失わないよう友達や配偶者は避ける。
### 5.2 記録すべきかせざるべきか
インタビューに慣れないと、メモが追い付かない心配がある。
そこで、**会話を録音する**ことが一つの選択肢となる。
相手の話がそのまま記録されるため、**会話にも集中しやすくなる。**
また、メモ時のバイアスがかからず、相手の抑揚なども後から把握しやすい。
但し、インタビュー相手の事前許可は必須である。また、録音の前だと**発言に慎重になりやすい**ため、相手に多く話してもらえなくなる可能性がある。
### 5.3 適切なメモの取り方
5.2にメモ時のバイアスとあるが、これは、要約やポイントの省略・凝縮の結果、**相手はこう言おうとしていたという主観的解釈が加わる**ことを指す。
こうしたバイアスがあると、正確な回答を得たことにはならない。
**相手の発言の詳細や感情、強調した点に恣意的な判断を加えず、ありのままに記録することが重要である。**
とはいえ、全てをまるごと記録するのも難しいため、**特に正確なメモが求められる言動**で適用する。
また、話が脱線する可能性も高いため、**重要な質問はあらかじめテンプレートを作っておく。**
#### 特に正確な記述が必要な言動
* 仮説を支持する言動
* 仮説を棄却する言動
* 意外だと感じた言動
* 強い感情が伴っている言動

#### 5.3.1 書記役をメンバーに加える
インタビュアーとは別に書記役を設けたペアインタビューも効果的である。
負担が軽減されるほか、部分横断的にメンバーを顧客に触れさせることができ、チーム全体にインタビューに関与してもらいやすい。
また、メンバー全体のインタビュー技術の向上にもつながる。
### 5.4～5.13 インタビューの流れ
#### 5.4 事前準備
* 相手について、質問に必要な最低限のことは調べておく。（相手の勤務先・業界・既婚か否か等）
* お手洗い等の体調面、メモやノートを取るPC等の設備面で事前準備を万端にする。
#### 5.5 最初の1分間
相手にとって好意的な印象を持ってもらうべく、以下の3つを行う。
* **相手に「自分の話が役立つものになる」と確信してもらう。**
* **相手に主体的に話をしてほしいとはっきり伝える。**
* **相手に話をさせる。**

以下、会話のポイントを挙げる。
* **くだけた調子を保つ**：**相手が心を許した時に放つ言葉や方策こそが、重要な情報となる。** 堅苦しくない、相手が安心して話せる状況を作る。
* **一個人として接する**：「弊社」「我々」等の会社目線ではなく、**「私」を主語にした個人のやりとり**を行うことで、相手が話しやすくなる。
* **相手を個人として尊重する**：相手が **「自分は価値のある存在」だと思えるよう、個人として尊重** し、詳細な回答を引き出しやすくする。
#### 5.6 次の1分間
こちらが必要な質問をしたら、**少なくとも1分間は相手の話を聞くことに徹する。** 相手は一言二言の浅い回答に終始しがちなため、気まずくても沈黙を保ち、相手の解答を待つ。
また、最初に聞き役に徹すると明言し、態度でも示しておけば、相手の長話の抵抗感も和らぐ。
#### 5.7 会話の流れを保つ
インタビューの質疑応答時に最も大切なのは、**相手に気持ちよく話し続けてもらう**ことである。そのために、なるべくオープンエンドな質問を挟んで長く続けられるよう工夫する。また、質問で回答のトーンを根本から変えることもできる。
以下、会話のポイントを挙げる。
* **誘導尋問をしない**：誘導尋問は失敗インタビューの典型例である。**誘導尋問はオープンエンドな質問ではなく、Yes/No型の質問である。** 「～だと思いませんか？」「～に同意しますか？」等の質問は避ける。また、話をしてくれないケースでは、無理やり答えを引き出さない方が良い。
* **掘り下げる**：一通りの質問を終え、答えの実感を得られたとしても、そこで満足してはいけない。要約を確認し、今一度説明してもらうことで、**抜け漏れが無いか確認したり、解釈の誤りを訂正してもらったり**できる。また、そこから相手の新たな課題が浮上することもある。
* **「5つのなぜ」を用いる**：トヨタで開発された「5つのなぜ」手法を用いて、問題を掘り下げていくことが可能である。
#### 5.8 脱線は生じる
オープンエンドな質問の性質上、話の脱線は仕方ない面がある。しかし、その背景を考えることで、**新たな前提条件やインタビュー対象の見極めに役立つ。** また、多くの人が同じ脱線を繰り返した場合、**仮説自体を見直すきっかけにもなる。** 無理に話を戻そうとせず、続けてもらう方が良い。
#### 5.9 「欲しいものリスト」は避ける
時に相手側から一方的に欲しいものを挙げてくることがあるが、何らメリットは無く取り合うだけ時間の無駄である。顧客が欲しがるソリューションよりも課題の方に焦点を当てるべきである。その方策として次の2点があげられる。
* 機能から離れる：相手が機能の話をしてきたら、話を聞くだけ聞いて、課題に立ち返る。
* 魔法の杖の質問：相手が知っていることの制約を取っ払うための魔法の質問で、課題を語るよう仕向ける。
#### 5.10 製品仕様の話も避ける
製品の仕様をインタビュー途中に見せてしまうと、回答がその仕様に影響されてしまい、インタビューの目的を果たさなくなってしまうため避ける。
#### 5.11 話が長引いたとき
予定された時間をオーバーして相手が話し続ける場合、30分超を目安に打ち切る。また、45分を超えると、時間当たりの効果は減り、相手の厚意を使い切るリスクも生じるため避ける。
この場合、適宜再インタビューを申し込んで対応する。仮説検証が成熟した段階で行えば、より効果的である。
#### 5.12 最後の数分間
インタビューを締めくくる際には、相手と良好な関係を気づくための3つのメッセージが欠かせない。
* 自分も相手のために時間を共有できると伝える。
* インタビューが大いに役立ったことを伝える。
* 時間を費やしてくれたことに感謝の意を述べる。
なお、インタビューを通じて「お客様」という言葉は避ける。知らず知らずのうちに「顧客」との交渉モードに入ってしまうため、オープンな会話を心掛ける。
#### 5.13 インタビュー後
インタビューは反復的に行うので、カイゼンの余地がある。誘導尋問やバイアス、その他避けるべき言動が無かったかを振り返り、次に生かす。また、どの質問が効果的だったか等のデータも集めることで、より良いインタビューが可能となる。
くれぐれも振り返りを放置しないこと。直後にしか覚えていないことも多くある。

## 6章　検証済みの仮説はどのように見えるのか
### 6.1 健全な懐疑主義を保つ
顧客開発インタビューは、主観的になりがちなところに難しさがある。
人は意識しないと、自分に都合の良いものばかりを見ようとするからである。
#### 6.1.1 相手は「あなたが聞きたいこと」を語っていませんか？
相手は時に**インタビュアーを喜ばせたいと気を遣い、** 実際にはそうでないのに「課題に直面している」等と言うことがある。
また、企業向けのインタビューの場合、**相手はインタビュアーに忖度することで、取引上の貸しを作ることができる**と考えることがある。
こうした場合は、**インタビュアーに都合の良すぎる回答が返ってきがちである。**
こちらの仮説を余りにも多く肯定した場合は、これらの振る舞いを疑うべきである。
**「多分」を多用する**などの目印を見つけて、早めに対処するべきである。
#### 6.1.2 顧客は本気で欲しがっているのか、それとも願望なのか。
相手が製品を本気で欲しがっているのかを見極めるためには、**あえてYes/Noの質問をぶつけてみる**のも一手である。
相手が受け身で「はい」と答えた場合、**重要度は低い。**
その後のオープンエンドな質問で、**信頼のある回答が得られるかどうか**が一つの見極めポイントとなる。
ただ、顧客になる可能性が低い人でも、信頼のある回答をする場合がある。こうした人の見極め方は、**これまで経験しているか、はたまた願望に過ぎないのか**である。
顧客になる人は**能動態を多用し、過去の経験から課題や目標を明確に把握しており、製品への評価にも説得力がある。** 一方で顧客にならない人は**受動態を多用**し、～してみたい。計画している。いずれ…等、**形にすらなっていない願望を語るだけで、製品を使おうとする意欲は見られない。**
**実際に行動したことを示す証拠**がなければ、仮説が検証されたことにはならない。
こうした仮説の検証（棄却）の判断は**できる限り素早く行い、タイムロスを無くすこと。**

### 6.2 メモの管理
1人で多くの情報を管理する際は注意する必要がある。
#### 6.2.1 一つの電子ファイルでメモを管理する
PC上のメモは、1つのファイル形式（word等）で全てのメモを管理する。統一することで、管理や検索が行いやすくなる。
複数人での共有はGoogleドライブなどの共有ドライブを用いると良い。
#### 6.2.2 要約版を作成する
メモ本体とは別に、**要約したものを用意**しておくと、チームメンバーとの共有時に最適な粒度で簡潔に会話が可能となる。
要約は、単に相手の話した内容を短くするのではなく、**次のステップに向けた結論と提案**となる必要がある。
**チームを重要なタスクに集中させ、非効率的な活動に時間を費やすことを回避する**効果がある。
また、ペアインタビューを行っている場合、仮説に顧客が同意していない（同意した）という証拠をペアの人が証明してくれるようにする。

### 6.3 チームを招集して新情報を共有する
チームが正しい方向にエネルギー向けるためには、顧客の視点で世界を見て必要な修正を行うよう誘導しなければならない。
最も良い方法は顧客開発のチームメンバーを多くすることで、多くのメンバーに顧客との接点が生まれ、一人で行うよりもはるかに効果的である。
たとえそうならなくとも、インタビューから得た学びの重要性をチームに報告する必要がある。
チームメンバーは顧客が置かれている背景を知らないため、丁寧に説明することが必要である。ただ、インタビューを重ねていくと「置かれている状況を知らなかった時に何を考えていたかを思い出しにくくなり、背景を説明しにくいため注意が必要である。
また、いきなり提案を仕掛けるのではなく、チームメンバーに質問や議論を促す必要がある。また、報告は意思決定のミーティングで行うべきである。

### 6.4 どのくらいの回数のインタビューが必要か。
既に終えたインタビュー回数により異なる。
#### 6.4.1 2回の場合
回数が少ない場合、顧客検証の目的に立ち帰って「**学ぶべきことが学べているか**」を確認する必要がある。
* **顧客が課題の存在を明確に認識しているか。**
* **顧客は課題を解決可能（解決すべき）と捉えているか。**
* **顧客は既に課題解決の取り組みを行っているか。**
* **顧客が課題解決の妨げとなる状況に置かれていないか。**
インタビューからは、**相手の抱える課題の深さと、解決したい動機の強さ**を十分理解しなければならない。
そのために、以下の質問に自身をもって答えられる必要がある。
* **顧客の課題を完全に解決可能な製品があっても、それを妨げてしまう要因はあるのか。**
* **顧客がこの製品をどのように日常生活に取り入れるか。**
* **製品はこれまで使っていた何を置き換えるものになるか。**
* **顧客が製品を購入しない場合、具体的な理由は何か。**
自身を持てないならインタビュー質問を修正する。経験をフィードバックに質問をカイゼンしていく。
多くの場合、2件程度では確証が持てることは無い。
#### 6.4.2 5回の場合
5回程度こなすと、1人ほどはアイデアに興奮してくれる熱心な顧客に出会う。
ここで着目すべきは、**仮説の棄却**である。以下の場合が該当する。
* インタビューすべき相手を間違っている。
5人の多くがソリューションを否定した場合、そもそも見込み顧客では無い可能性が高い。
インタビュー相手を見直すところから再スタートすべきである。
* 課題と仮定しているものが実は課題でない。
仮説自体が間違えており、設定した課題が全く見当違いである場合は、仮説から見直す必要がある。
いずれにしても、**早く誤りに気付き、素早く棄却できるほど、ピボットが素早く行える。**
一方で、一人でも興奮してくれる人に出会えたなら、MVPを作り始めても良い。
真意は実際にローンチして、顧客になってもらわないと分からないので、無駄に先延ばしする必要はないからである。
#### 6.4.3 10回の場合
10回こなすと、**顧客行動の共通点**が見いだせるようになってくる。
3回同じような表現を耳にしたら、パターンと捉えていくべきである。
パターンが判然としない時は、「他の人たちは（パターンに否定的な行動）をしていますが、あなたはどうですか。」と、
他の人たちがパターンを否定していると仮定して話を持ち出すと良い。熱心な人は他の人たちとの違いを説明してくれる。
一方で10回やっても一向にパターンが見いだせない場合、インタビュー範囲が広すぎる可能性がある。範囲を狭めるとパターンが現れやすくなる。
#### 6.4.4 何回インタビューをすれば十分か
時と場合による。
* **顧客開発の経験と業界経験**：経験の数が多いほど、行動パターンや業界にある背景等がつかみやすくなり、インタビュー回数も減る。
* **ビジネスモデルの複雑さと当事者間の依存関係の数**：ビジネスモデルが複雑だったり、他の業者に依存していたりすると、仮説検証の数は増加しやすい。
* **MVPの作成と検証に必要な投資額**：MVPが機能するために必要なリソースが多いと、仮説検証数も多くなる。一般的に1ヶ月を超える検証はオーバーエンジニアリングである。
#### 6.4.5 インタビューを十分に実施すると相手の発言に驚かなくなる
インタビューを十分に行ったかどうかの判断基準として、**相手の発言に驚かなくなったかどうか**が挙げられる。
**驚く要素が無くなれば、顧客について十分に理解が深まり課題を確信している証となる。**
筆者の場合、15~20回のインタビュー（約2週間）で確信できるようになる。
こうして確信した情報に基づき、「顧客の真の課題につながるリクエスト」と「開発しない機能」が明確になる。

### 6.5 検証済みの仮説はどのように見える？
別の仮説についてのインタビューから、検証済みの仮説に対する課題が浮かぶことがある。
興味深い脱線話から良いアイデアが生まれ、そこからそのアイデアに関する新たな仮説検証を経て、新たな製品につながる。

## 7章　実用最小限の製品をどのように開発すべきか
### 7.1 MVPはどのように活用すべきか
MVPの目的は、**リスクや投資を最小限に抑えながら、学びを最大化**することである。
このため、MVPの目的は**仮説の想定や検証のみ**にするべきである。そのためならば、コードを書く必要性が無い場合もある。
#### MVPが答えられる最も重要な質問
* ターゲット顧客の目の前にこの製品を差し出せるか。
* 顧客はこの製品が約束する価値のために積極的に支払いをするか。
* 製品から得た価値を顧客はどのように測定しているか。
* 顧客価値と顧客の支払い能力には、どのような価格設定モデルが適切か。
### 7.2 MVPの種類
MVPは、**実用性があり（顧客に十分な価値を提供する＋仮説の証明・棄却に十分な情報を提供する）かつ最小限な製品**である必要がある。
そのようなMVPには、いくつかのパターンがある。
### 7.3 プレオーダーMVP
予定しているソリューションを説明し、その利用開始前にサインアップして注文するよう潜在顧客を勧誘するMVPである。
**製品に対する関心よりも、お金を支払うコミットメントを重視する。**
多くの場合、リリース前の課金は発生しないようにした上で、クレジットカード情報を求める。
これらの動向と開発に必要な費用を吟味し、一定のプレオーダーがある場合のみ開発を続行する。
支払い額が最終的な製品価値より小さくても、**開発中の製品に支払いの意思を示したことに大きな意味がある。**
このMVPによって、**顧客が間違いなく購入してくれる製品**を開発していることが証明できる。
☆使用例：大規模ソリューション、開発続行の最低限のユーザ量が必要であるソリューション
### 7.4 オーディエンス開発型MVP
製品を開発する前に**顧客基盤を開発しておく**MVPである。
見込み客のセグメントを明確にしたうえで、**顧客が集まって意見交換する場を構築する。**
これを観察することで、どのようなコンテンツや機能、人々と最も熱心に関わっていけるかを測定できる。
**リリース時には顧客基盤が完成している**ため、宣伝や流通の心配は無くなる。
このMVPによって、**顧客の維持と参加を測定できる。**
☆使用例：無料またはソーシャルな性質を持った製品、オンライン製品、お金よりも時間を重視するオーディエンス等
### 7.5 コンシェルジュMVP
顧客の課題解決に**手作業を用いる**MVPである。
手作業できめ細やかな対処を行う事と引き換えに、多くのフィードバック提供に同意してもらう。
**開発を始める前に、顧客に製品を体感してもらえる。**
コストを大幅に削減しつつ、集中的な仮説検証が必要な場合に効果的である。
このMVPによって、製品の需要があるかどうか、また流通や機能の想定が妥当かどうかを検証できる。
☆使用例：オーディエンスがオフライン、流通予測が困難なソリューション等
### 7.6 オズの魔法使いMVP
完全に機能が実装しているように見せかけているが、内部的な処理は手作業で行っているMVPである。
スケーラビリティは無いが、**実際に動く製品を見せることで、品質や支払に対し実際の製品に近い評価を得ることができる。**
このMVPによって、**顧客の行動を実際の環境で**検証できる。
☆使用例：洗練されたアルゴリズムや自動化が必要なソリューション、デリケートな領域の課題、二面市場（顧客が2サイド存在する）等
### 7.7 シングルユースケースMVP
1つの課題のみに焦点を当てたMVPである。
1**つの機能だけに絞ることで、その機能の優先順位を見極めることができる。**
不完全であるが故に顧客の不満の声から、さらに多くの機能を提供できるようになる。逆に不満がない場合は仮説の転換を行うサインである。
このMVPによって、迅**速な開発が可能となり、見込み客への説明も簡単になる。**
☆使用例：方向転換やスピンオフ製品の検証を必要とする場合、大規模、複雑、高価な製品が支配的な市場に参入する場合、自社製品の最適化を目指す場合等
### 7.8 他社製品MVP
アイデアの検証のために、既存の製品やサービスの一部を利用するMVPである。
**迅速な学習とアイデア検証が可能となり、リソースの消費を最小限に抑えられるメリットがある。**
このMVPによって、**競合についての詳細を学び、自社の利点を明らかにできる。**
☆使用例：競合他社により確立された市場への参入、流通の予測が困難なソリューション、エンジニアリングリソースの節約

###### tags: `読書`