# リーン顧客開発（8章,9章）
## 8章　既存顧客がいる場合の顧客開発
これまではスタートアップなどの小規模な企業を対象にしてきたが、この章では大規模な大手企業を対象に顧客開発の実践の方策を見ていく。
### 8.1 MVPの概念を適合させる
小規模なスタートアップでは効果的なことも、大企業では難しい場合が多い。
#### 8.1.1 欠陥のあるものを提示しない
バナー広告（リンク先は設定しない）を用いた消費者の関心を検証する手法は、手軽な商品価値検証の一つである。
しかし、大企業等既に自社製品がある状態で同様の検証を行うため、リンク切れの広告等**実際には機能しないもの**を追加したり、記載すべき事項（プライバシーマーク等）を追加しなかった場合は、顧客に「**欠陥**」とみなされ、**信用度が大きく落ちる可能性がある。**
スタートアップでは、最初のバージョンで恥ずかしい思いをするのは成長・カイゼンへの第一歩だが、**大企業の場合、恥ずかしい思いをした時点で顧客の信頼を失い**、次のバージョンを試すチャンスは巡ってこない。
#### 8.1.2　魅力的だがフェイク
欠陥がある製品は当然誰もが拒むが、逆にデモ製品が完璧すぎて既に完成していると錯覚されるのも良くない。顧客は**次の新しいバージョンを期待するあまり、購入やアップグレードを控える動きをとるためである。** 仮に仮説の棄却などで製品リリースができなかった場合、**完璧な品を待ち望んでいた顧客の失望を招く。**
対策：**見栄えは良いが明らかにフェイクなアプリのスケッチ**や**別のドメイン**でアプリを動かす。
#### 8.1.3 最小限よりも実用性を重視
大企業の場合、スタートアップで重視した最小限のプロダクトよりも、**最小限をわずかに超えて、失望を感じさせない程度に一定の機能性を持たせた、実用性が高いプロダクト**の方が良い。不満はむしろカイゼンに役立つためOK。
基本的に**検証目的を満たす最低限の機能のみ**を搭載し、その他はバッサリと切り捨てる。切り捨てた機能は検証が終わった後に実装する。
プロダクトマネージャーやデザイナーは、職務上機能を最小限度にとどめることが難しいため注意が必要。

### 8.2 適切な顧客を見つける
エバンジェリストユーザー（3章）は、スタートアップが製品開発を軌道に乗せるためには必要不可欠であるが、いつまでも貴重な顧客になるとは限らない。最高の顧客がだれなのかを見直すことは極めて重要である。
#### 8.2.1 不適切な顧客が分かれば適切な顧客が分かる
筆者は新製品アイデアのデモを、保守的思考の顧客に見せてしまう失態を犯した。顧客は新製品のアイデアを押す＝既存製品を撤退させると捉えてしまっていたため、信頼関係に亀裂が生じた。
こうした失敗から、保守的な考え方の顧客は不適切で、逆に**変化に慣れている顧客や積極的に関わってくる顧客、製品の将来性を考えている顧客**が適切であると分かった。
不適切な顧客が分かれば、おのずと適切な顧客も見えてくるのである。
#### 8.2.2 製品がないと生きていけない人を見つける
正しい顧客を見つける基準として、現時点での既存顧客との関係は最適ではない。**最高の顧客＝製品から最大の価値を得ている顧客**である。
これを推し量る検証方法として、アンケートページに「**もしこの製品が使えなくなったらどう感じますか。**」という質問を入れることが挙げられる。この質問に対し「とても失望する」と答えた人は、製品から最大限の価値を得ている、いわば「製品がないと生きていけない」人たちである可能性が高い。
また、こうした顧客は**製品の劇的な変化を嫌う**。課題があってもなんとか解決して現行製品を用いたプロセスを確立しているため、大きく方向性を捻じ曲げると反発を生む恐れもある。

### 8.3 顧客の言葉こそ売り込みに効く
熱狂的な顧客の言葉は、他の顧客も敏感に反応する。彼らは機能よりも、メリットや利用時の感情や状態の変化等を語る。**こうした言葉は他の顧客にも好印象をもたらす。**
こうした状況を語ってもらうために、次の質問が使える。
* あなたは私たちの製品を他の人に勧めますか。
* 勧める場合、**その相手は誰ですか。**
* その相手に対して**具体的に勧める場面を想像してください。** あなたは**どのように説明していますか。**
相手は誰かを尋ねることで、想定ユーザーとの乖離が無いかをチェックする。もし別分野の顧客であれば、その理由を明らかにする。
顧客が言及した機能は、**将来の製品開発での優先順位付け**に役立つ。
そして、顧客が勧める際に話した言葉は、**そのままマーケティングにも役立つ。**
#### 8.3.1 顧客を観察することで市場リスクを低減させる
製品にとって最大のリスクは **「使ってみよう」と思わせるだけの興味を持ってもらえない**ことである。**競合他社製品との差別化**ができていなければ、その製品に魅力は感じない。
素晴らしい製品を売ることと、製品によって顧客を素晴らしい気持ちにさせることは**全く異なる。** 高度な技術や設計等よりも、**製品を使う事で顧客素晴らしい気分になれることの方が顧客にとって大切である。**

### 8.4 顧客を見つけたら、徹底して説明する
顧客には顧客開発プロセスに快適さや楽しさを感じてもらう必要がある。
しかしそのためには、**こちらが何をしていて、どのように顧客に参加してほしいのか、得た情報をどのように活用するのか等を丁寧に説明する必要がある。**
#### 8.4.1 あなたは質問をしている-具体的に何かを作っているわけではない
顧客は製品が方向性を変えたり、質問されることには慣れていない。顧客開発について質問すると、顧客はコミットメントとして解釈してしまうため、「将来実現されるもの」というイメージを持ってしまう。
「顧客から学びを得るための質問」であり、まだ何も変わっていないことを明確に伝える必要がある。
また、製品の仮説は不可逆的に変化し、顧客は悪い点があっても印象低下を避けるために言わない傾向にある。
こうした状況を踏まえ、以下のことを明確にし、**会話の中で何度も伝える**ことが重要である。
また、相手にごく一部の人にインタビューをしていると、**選ばれた印象を持たせる**ことで、深いフィードバックが得やすくなる。
* **あなたが相手から学ぶために話しかけていると明確にする。**
* **会話が探索的なものであると明言する。**：遠い未来を暗示させる。
* **顧客に不満や文句を述べてもいいと伝える。**
#### 8.4.2 目的は調査ですと繰り返す
「この機能はいつから利用できますか？」や、「実際に開発する可能性はどれくらいですか」等の質問には、曖昧な回答はNGである。あくまでインタビューは「**調査目的**」であることを伝え、「あなたが**価値を得られるものでなければ、急いでこれを開発しません。**」と明示する必要がある。
調査目的の旨を繰り返すことで、積極的な顧客調査をしている素晴らしいベンダーであると顧客に思われ、深い関心を示してもらえるのである。
### 8.5 ストーリーテリング・デモ
顧客には具体的な製品を見せないと取り合ってもらえないことも多いが、逆にデモ製品を見せるとそれが現実の製品であると思い込んでしまう。
この両方の課題を解決するのが**ストーリーテリング**である。ある1人の典型的な顧客の立場で製品を捉え、どのように製品を使っているかを説明する。
#### ストーリーテリングのメリット・デメリット
* メリット
* **顧客が機能面や極端なケースの視点からデモを捉えてしまう問題を解決**できる。
* **一つのワークフローを通じて**デモを捉え、判断できる。
* デモが無い説明のみという退屈さを無くすことができる。
* 軽量の製品仕様を提供できる。
* デメリット
* 特定の状況に囚われてしまい、顧客の課題や現在の行動を探れない。
* デモを見た顧客から不満点を言い出しにくくしてしまう。
### 8.6 匿名での顧客開発
会社のブランドや地位、現在の戦略などが、会話にバイアスを掛けてしまう恐れがある。**ブランド評価やイメージによって、人々の印象が持っていかれてしまう「後光効果」をもたらす恐れがある。**
#### 8.6.1 新たなアイデンティティを身にまとう
後光効果によるバイアスを防ぐためには、**自社か顧客のどちらかを「他の誰か」に置き換える必要がある。** Microsoft社のHotmailの全面改修例では、顧客に自社であることを伝えるとまともなフィードバックは得られないと考え、Microsoft社の人間を名乗らずに顧客開発を進めてフィードバックを得た。もっともらしいドメイン名のメールアドレスを使えば、簡単に顧客開発ができる。
#### 8.6.2 顧客でない人と話をする
**あえてターゲットとは異なるステークホルダー**を相手にインタビューする手もある。例えばプロダクトマネージャーやプロジェクトマネージャー、管理部門のアシスタント等が該当する。
また、顧客の顧客にインタビューするのも一手である。銀行向けシステムであれば、銀行のユーザーにインタビューすることで、良いフィードバックを得られる。**顧客企業の顧客のニーズを的確にとらえる**ことで、次への道が開かれる。

### 8.7 製品の使い方を示してもらう
大企業の場合、既存製品と既存顧客が存在している。既存顧客は不満や賞賛などのフィードバックをくれるため、顧客ニーズは分かっていると思われがちだが、実際に顧客の声を形にしたところ、全く顧客の役に立たなかったというケースがよくある。
そこで、**直接対話や画面共有などを用いて、インタビューで顧客から実際の製品の使い方について検証する**のが効果的である。
これまでのインタビューの基本事項は踏襲しつつ、次のポイントを尋ねたり観察したりする。
* 顧客が**製品を使用する頻度**
* 製品を使用した**直後の顧客の様子**
* 製品は**顧客のワークフローに沿っているか**
* **どの程度の機能**が使われているか
* **価値提供の新たな機会を探る**
* 製品が**どの程度代替可能か。**
* 企業や家庭内のどれくらいの人がメリットを得ているか。
* 製品が実際に解決する課題はいくつあるか。

### 8.8 製品の使い方を説明する
8.7とは逆に、**こちらが顧客に対して製品を「使うべき」方法を教える**ことも効果的である。その際、「こちらの前提が間違っていたら伝えてください」と**前提の誤りを顧客が指摘できるようにする**ことが、認識の相違を無くす上で大切である。その上でこちらが断定的に想定を伝えていくことで、**相手が気兼ねなく同意するか否かを判断できる**ようになる。
こうしたインタビューからは次のようなことが学べる。
* 価値提案を明確にできる。
* 制約条件を特定できる。
* 機能が使われていない理由が分かる。

## 9章 継続的な顧客開発
顧客開発は、リリース以後も継続的に実施する必要がある。
顧客開発の知見を吸い上げるには、常に顧客と接している営業担当者やアカウントマネージャー、カスタマーサポート等で働く人々に聞くのが良い。
### 9.1 すでにオフィスを飛び出しているのは誰か
例えば、営業担当者が顧客にヒアリングした情報をもとにプロダクトマネージャーに開発を要求する場合である。
営業担当者はプロダクトマネージャーに顧客からの機能の要求に対しYes・Noで答えることを迫り、険悪な関係に陥りやすい。
そこで**両者が協力して顧客から機能を作る理由（Why）を得るようにする。** 営業担当者は開発チームに正当な理由を説明でき、開発チームも顧客開発ができて納得しやすい。
万が一両者が緊張関係にある場合は、プロダクトマネージャー側は営業担当者の立場も理解したうえで、**両者がWin-Winな関係になる「Whyを尋ねる」提案**を持ちだすようにする。
また、開発チーム側のメンバーを営業に同行させることでも、顧客開発の有効性を実証できる。

### 9.2 ドアをノックするのは誰だ
顧客がカスタマーサポートに電話をする場合、その現場からも良いフィードバックを得やすい。
サポート担当者がイライラしがちな顧客の機能の追加要求や苦情を、開発チームが肌で感じることで顧客のニーズをつかめる。
顧客への質問の際は、問い詰めるような言い方ではなく、好奇心を持っているような言い方で話すことで、きつい印象を和らげることができる。
顧客のニーズを理解しようとしていると顧客側が分かれば、否定的な態度から一転して協力的になってもらえる。
#### 9.2.1 機能追加を要求された時
機能追加を要求された時は、オウム返しにしたうえで**「なぜ望んでいるのか」を尋ね、顧客のWhyを聞き出す。**
これらの質問の回答率はきわめて高くなる。その回答から合理的なソリューションの提案に持って行ける。
但し、複数の顧客が同じ機能を求めていても、それぞれが異なる課題を解決しようとしている場合もある。逆に、異なる要求であっても根底の課題は1つである場合もある。
機能要求だけではなく、**その根底にある課題を明確にする**必要がある。
#### 9.2.2 機能の問題か、デザインの問題か
クレームが来た際は、**4つのA（Apologize：謝る、Admit：非を認める、Ask：質問する、Appreciate：感謝する）** を心掛けた対話を行う。
**自らの責任を認めることで、相手に質問をしやすいトーンを作り出せる。**
この際、影響を受ける人、発生状況、発生頻度、重大度等のフィードバックをもらう質問をもらい、カイゼンに役立てる。
1人の顧客の苦情は**氷山の一角に過ぎない。同じ苦しみを10人以上の顧客が味わっている**と思い、たった1人のクレームにも**感謝の気持ち**を忘れないように。
#### 9.2.3 バグとエラー
バグやエラーの解決のためには、必ずしも顧客からの質問に答えることが、「本当に必要としている質問」に答えることにはならない。
顧客に対し、この機能でどのようなタスクを達成しようとしているかを尋ね、より簡単で優れた方法を見出せるようにする。
#### 9.2.4 今週の質問
週替わりで特定の質問を、カスタマーサポートに届くメールへの返信に書き加える。
1つの質問だけで手軽に回答でき、具体性のある数値や、誰が、何を、どのように、いつ、なぜ、等で回答できる、事実に関する質問が良い。
#### 9.2.5 バイアスを認識する
多くの顧客はそもそも問い合わせをしてこない。大半は苦情も絶賛もしない「サイレントマジョリティー」である。
質問をくれる人の多くは「初心者」か、経営者や管理者等の「パワーユーザー」である。
パワーユーザーからの問い合わせやリクエストは、その要求を実現しても他のユーザが全く触らないような機能になってしまう場合がある。他のユーザが興味を示さなければ、開発をする意味は無い。
逆に初心者のフィードバックには、将来妥当な顧客になりうるか、経験が少ないために価値が得られないのではないか、等の評価を行うと良い。

### 9.3 顧客開発のサイクルを循環させる
チームで貴重な情報を得ても、組織（会社）全体として上手く共有されていない場合がある。
顧客開発を継続的に実施するには、**情報共有プロセスにできる限り「簡単」に参加できるようにする**必要がある。
#### 9.3.1 情報の収集
他の社員の顧客開発メモの収集方法は、社内のツールによって異なる。社内で共有プロセスを回すには、ツールをより簡単で手間のかからないものに変更する必要がある。
例えば、Word等の共用文書、OneNote等の共有ノートブック、専用の電子メールアドレス、Googleフォーム等のツールが挙げられる。
こうした社内でのツールの共有は、同僚にメモ提出を促さなくても良くなり、素早いフィードバックも可能となる。
#### 9.3.2 顧客開発の成果を共有する
**顧客開発による意思決定の結果を、社内で明確に共有する必要がある。**
顧客開発によってリソースを節約できた結果は、大いに祝福すべきである。
こうした成功事例を壁に張ったりオフィスのディスプレイに掲示してみることで、**新しいやり方が徐々に会社の文化として浸透しやすくなる。**
報告はスタートアップで毎週、大企業で毎月あるいは四半期ごとに行うのがよい。
顧客開発について話すことで、さらに質の高い疑問や課題が生まれやすい。**顧客開発の報告も、また一つの顧客開発の実践である。**

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