「顧客が本当に必要だったもの」を開発前に知るために『リーン顧客開発』

若手がチームに入るとき、私が必ず見せるのが、これだ。

顧客が本当に必要だったもの

出典 arison.jp

それぞれの立場によって、「作るべきもの」が変わってしまうことを、面白可笑しく描いている。ベテランなら「あるあるｗ」と笑うだろうし、新人なら「まさか！？」と驚くかもしれないが、本当だ。

この絵で重要なのは、「顧客が欲しがったもの（要件）」が最初のコマに描かれており、「顧客が本当に必要だったもの」が最後のコマである点だ。

「顧客が本当に必要だったもの」は、「顧客が説明した要件」ではない。プロジェクトリーダーの理解とも違う。設計とも、コードとも、ましてや、出来上がったものとは似ても似つかない。だが、実際にプロジェクトを動かし、試行と錯誤と怒号と違約金を経て、ようやく「顧客が本当に必要だったもの」が明らかになっている。

顧客が欲しがっているものと、顧客が本当に必要なものは違うのだ。

19世紀にヘンリー・フォードが尋ねたら「もっと早い馬車が欲しい」と言うだろうし、マクドナルドがアンケートをすれば「野菜サラダをメニューに入れて」と言うだろう。スティーブ・ジョブズはいみじくも言った「顧客が何を求めているかについて探すのは、顧客の仕事ではない。あなたの仕事だ」。

では、「本当に必要なもの」をどうやって知るのか？　当の顧客ですら知らないのに、どうやって知り得るのか？

この疑問に具体的に応えたのが、『リーン顧客開発』になる。

リーン（LEAN）とは形容詞で「無駄がなく、引き締まった」という意味になる。顧客開発とは製品開発に対応する概念で、顧客とは誰であり、顧客の問題やニーズを追求して仮説検証をするアプローチになる。

著者曰く、顧客開発に1時間費やすことができれば、設計やコーディングの10時間以上、削減でき、機会損失や無駄なコストを削減できると断言する。

数字はともかく、本当に分かるのだろうか？　半信半疑で読み始めて納得した。私の経験も含めて、本書の通りだと断言できる。というか、このやり方でないと、「顧客が本当に必要なもの」はいつまで経っても分からない。

顧客の「課題」を探す

例を挙げたほうが早い。以下の下線部を埋めるように、ターゲットとなる顧客を想定しろという。

• 顧客は＿＿＿＿についての課題を抱えている

• 顧客は、この課題解決のために＿＿＿＿を投資する容易がある
• この製品の使用／購入に関わるステークホルダーは＿＿＿＿である
• この製品の開発／流通に関わるパートナーは＿＿＿＿である
• の製品を購入／使用しない顧客は＿＿＿＿を購入／使用するだろう
• 顧客の購入決定は＿＿＿＿の影響を受けている
  etc…

もちろん、最初に思いついて空欄を埋めた「顧客像」が正しいとは限らない。だから、想定する顧客を探し出し、アンケートとインタビューを繰り返すべしと説く。その探し方も、近所の隣人から職場の同僚、友人、ネットの向こうの見知らぬ人まで具体的にレクチャーしてくれる。

そして、想定する顧客へのヒアリングのやり方も、微に入り細を穿って説明してくれる。

私にとって大きな学びとなったのは、「聞くべき顧客の声」と「スルーして大丈夫な声」の明確な区別の仕方だ。

聞くべき顧客とは、課題を抱えている人だという。課題による痛みに苦しんでおり、自分で様々な解決を試みようとしている人になる。ヒアリングをすると、その人が試してきた数々のツールや、その課題によりどんなマイナスが生じているか、具体的に情熱的に語ってくれる。

一方、スルーしていい顧客の声は、「〇〇が欲しい」という声だという。この機能が必要だとか、あれがないとダメだという「欲しいものリスト」は耳を傾ける必要は無いという。その代わり、「なぜそれが欲しいのか」という質問を投げかけろと説く。そこで課題を語りだすなら聞くべきだが、そうでないならスルーしていい。

フォードの質問に置き換えるなら、「なぜ早い馬車が欲しいのか？」という問いかけになる。ひょっとすると顧客は「もっと早く職場に着くために」と答えるかもしれない。すると、準備するものは馬車でも自動車でもなく、早く職場に着かないことで起きている課題は何か？という焦点に移るだろう。

制約を取り払う質問「もし魔法の杖を振って…」

顧客は自分の課題には詳しいかもしれないが、解決策が見出せていない。

顧客は、自分が置かれている環境や、できることの限界は分かっている一方で、そうした環境や限界を所与の前提としてしまっている。そして、その制約の中で想像し、できることを考えている。

解決策のない課題は、動かしがたい事実として受け入れてしまっているのではないか？

そんな状況を取り払う質問として、「もし魔法の杖を振って解決できるなら、どうしたいですか？できるかどうかは気にせずに考えてみてください」があるという。

これは私もよく使う手だ。「現実性や実現の是非は後で考えるとして、まずはどうなれば嬉しいか教えてください」と水を向けることがある。

もちろん、突拍子もないアイデアが出ることもあるが、たいていの場合、「その『課題』そのものを解決しないとダメなのか？」という発想になる。そして、課題の抽象度を上げて考えたり、課題をやらなかったらどうなるか？というアプローチで検討できたりする。

他にも、数多くの気づきを得られた。

• いつ、その仮説が検証済みであると言えるのか？　→　インタビューで驚かなくなったとき
• YES/NOで答えられる質問ではなく、「なぜ必要か」「誰が、どのように実施していているのか」「最後にそれをしたのはいつか」といった5W1Hのオープンエンドの質問をすべし
• デモをするときは「顧客の課題」を解くようストーリーテリングしろ。顧客から「それは私たちが対処する状況と違います」という言葉を引き出せたら満点

私が経験的に学んでやってきたことを、体系立てて理由付きで説明してくれる。時間の無い人には、巻末の段取りとインタビューシートが、すぐにそのまま使える。これを実践できれば、試行と錯誤と怒号と軋轢は、かなり回避されるに違いない。

そして、「顧客が本当に必要だったもの」という過去形ではなく、「これから顧客が本当に必要とするもの」を、始める前に知ることができるだろう。

本書は、ふろむださんの面白文章力倶楽部で教わった名著なり。若手がチームに入るとき、本書も併せて薦めるつもり。ふろむださん、ありがとうございます。