25
30

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

「売れるサービス」を作るために調べたことメモ②

Last updated at Posted at 2016-01-20

#はじめに
この記事は「売れるサービス」を作るために調べたことメモ①の続編です。
内容としては、以下の本を自分なりにまとめたものです。

アントレ.jpg
「アントレプレナーの教科書」

RunningLean.jpg
「RunningLean」

Lean顧客開発.jpg
「Lean顧客開発」

知りたいことは
__「売れる製品やサービスを効率的に作る方法」__です。
そのために以下の4つを書いています。

前回は
・サービスの土台となるプランを作る
・顧客を見つける(サービス作る前から)

を書きました。

今回は
・プランの検証と洗練をする
・土台となるプランを決定する

をまとめます。

##プランを検証し、洗練する

文が汚いですが、強引に箇条書きを交えてまとめていきます。
###①アントレプレナーの教科書ではどう書かれているか
この本では、顧客の課題においても、製品コンセプトにおいても検証と洗練の作業を行っています。

####●課題の検証と洗練:何を聞くのか?
#####課題プレゼン
課題のせいで__「現在どのくらいのコストを負担していますか?」__を聞く。
 ・売り上げの喪失
 ・顧客の喪失
 ・時間の無駄
 ・精神的苦痛

課題プレゼンは顧客を説得するために作るのではなく__情報を引き出すように__作成。
もっぱら聞き役に徹する。

#####顧客理解
__「もし魔法の杖で、日々の業務が変えられるとしたらなにを変えますか?」__を
これにより課題の本質と、解決のアイデアを引き出す。
「この質問の答えを手にすれば、スタートアップは上場も夢ではない。」

顧客は日常
 ・どのように動いているか、
 ・業務フロー
など
####市場理解
「展示会やカンファレンスで有識者から知識を得る」
「最低2つはカンファレンスに出席する」
####●誰の反応が重要か?
#####「エバンジェリストユーザー」がもっとも重要
エバンジェリストユーザーの特徴:
課題の仮説について指示しているだけでなく、
課題を解決するために
・予算を取得済み、もしくは取得可能
・製品の寄せ集めで課題解決をすでに試みている

####●製品コンセプトの検証と洗練:何を聞くのか?

#####現実性確認
仮説を、顧客のフィードバックより再検討。
 →リリースに必要な最小限の機能を解明する。
ビジョナリー顧客には、向こう18か月に自社が何を提供する予定であるかを説明する必要がある。
#####さらなる顧客訪問
法人向け:最低でも5件の新規顧客。 一般向け:50人の顧客
→課題と、その重要性に同意を得られるか?
 →Yes:初めて製品のプレゼンを開始。
 ・製品がある場合とない場合の業務フローを見てもらう
 ・話を止めて、導入前と後のフローについて同意を得る
 ・課題を解決できるか聞く
 ・課題解決のために製品を購入するか?
 ・初回リリース時に必ず入っていけないといけないものは?

#####2回目の現実性確認
・顧客は我々の製品に熱を上げている
 →確認のフェーズへ。
・気に入ってはいるが、加えて欲しい機能あれこれ。
 もしくは製品は理解したが、熱意を感じない。
 →戻ってやり直し
###②RunningLeanではどう書かれているか
インタビューを結果につなげるためには、リーンキャンバスの仮説を反証可能な状態にすることが必要とのことです。
####●課題インタビュー:何を聞くのか?
・顧客セグメントはこちらが想定通りか聞いて確認する
・課題を(具体的な例を元に)ストーリーで説明し、共感を得られるか確認する
・課題の上位3つに対して優先順位をつけてもらう
 →課題に対して順番に、対処法を聞く
 →思う存分に語ってもらい、黙って聞く
 →体や声の調子に注目し、「絶対必要」「あれば嬉しい」「必要ない」を見極める。
・別の課題を話し始めたら、それについても聞く

####●誰の反応が重要か?
RunningLeanの中には「エバンジェリストユーザー」は出てきません。
代わりに出てくるのは「アーリーアダプター」です。
アーリーアダプターについて詳細には書きませんが、要するに”新しい製品を好んで使う人”です。IT業界に限っては「ITオタク」などと表現する人もいます。
(アーリーアダプターは「キャズム」理論に出てくる表現なので詳しくはその辺のワードで調べてみてください。)
###③Lean顧客開発ではどう書かれているか
####●何を聞くのか?
まずは「顧客開発の基本的質問」に書かれている5項目
(※しくみ製作所さんがスライドにまとめてます。21ページあたり
http://www.slideshare.net/sikmi/ss-50204181)

もちろん他にも質問するが
「『はい/いいえ』ではない、オープンエンドな質問をする」

これは質問というより「会話を促すための潤滑油」、つまり相手の思っている、考えていることをどんどん引き出させるのが目的。
また、『はい/いいえ』の質問は誘導尋問となりタブー

現実に基づく質問をすべき__とも言っています。
「何をする__つもり__ですか?」を聞いても意味ないわけです。
具体的に言うと「どのていど使うことになると思いますか?」と聞くのではなく
「◯◯のようなものを最後に使ったときのことについて教えて下さい」というふうに聞きます。
「どのくらいの頻度で発生しますか?」と聞くのではなく、
「先月、何度その状況が発生しましたか?」__のように聞きます。
####●誰の反応が重要か?
①と同様、__エバンジェリストユーザーを重視__しています。
(※そもそもこの本の「顧客開発」モデルを提唱したのは、①のアントレプレナーの教科書です。なので、①の本の影響を強く受けています)

ちなみに僕らのチームでは、Lean顧客開発をもとにヒアリングを進めているので__「アーリーアダプター」より「エバンジェリストユーザー」を意識__して製品開発しています。
「アーリーアダプター」はある意味 興味本位で製品を買うこともありますが、「エバンジェリストユーザー」は、課題を解決するために製品を買います。
B2B向け製品を作る場合は、後者の方がターゲットとして本質的だと思います。
コンシューマー向けの製品を作る場合、「面白さ」が重要な場合が多々あるので、「アーリーアダプタ」の存在も重要だと思います。

##・土台となるプランを決定する
###①アントレプレナーの教科書ではどう書かれているか
#####・顧客の確認
少なくとも10〜20の顧客と話をしたはず→
『お金を払ってでも解決したい顧客の課題を特定した』と言える?→
Yesなら「製品確認」へ
#####・製品確認
顧客の上位3つの課題を言う→
上位3つの製品機能を言う→
チームメンバーはショックを受けていない→
Yesなら「ビジネスモデル確認」へ
#####ビジネスモデルの確認
・更新された、販売・売り上げ計画→顧客一人当たりの生涯単価は?
・健全な事業計画
 流通チャネルコストは?
 サポート費用はどれくらい?
 市場規模はどれくらい?
・健全な製品計画
以上がOK→次のステップへ。NGなら繰り返し。

###②RunningLeanではどう書かれているか
課題インタビューと、ソリューションインタビューのどちらも行います。
####課題インタビューの終了条件とは?
最低10人にインタビューして以下のことが可能になれば終了
・アーリーアダプタとなる顧客が特定できた
・「絶対に必要」な課題が見つかった
・現在の顧客の解決方法がわかった
####ソリューションインタビューの終了条件とは?
・アーリーアダプターの顧客情報が特定できた
・「絶対に必要」な課題がわかった
・課題を解決するのに必要な最小限の機能が定義できた
・顧客が支払ってくれる価格がわかった
・(概算で)うまくいきそうなビジネスが構築できた

→MVPの構築へ

###③Lean顧客開発ではどう書かれているか
他の2冊と違う特徴として、課題インタビューによってパターンが出現するので、出現した後の__インタビューではそのパターンの存在を確認するようにする__と言っている。

####インタビューの終了条件とは?
こんな風に表現しています。
「インタビューを十分に行ったかどうかの判断基準は、相手の話に驚かなくなったか否か」
ただ、これでは曖昧なので、幾つか具体的に書かれている部分をピックアップします。

#####●インタビュー回数
5回:アイデアに興奮する相手が1人は見つかる。
 →5回で全員がアイデアに興味を示してくれないのなら、その仮説は棄却されたとみなしていい。
10回:顧客の__パターン__が見え、驚くような話はほとんどなくなる。

#####●パターンについて
__同じ表現__を3回耳にしたら、次回からこのパターンの存在を(Yes/Noではない形で)確かめるようにする。
 →次回からはパターンとは反対のことを言っている人(←実際は存在しない架空の人)の話をして反応をみる
10回インタビューしてもパターンが見えない場合はターゲットが広すぎるので狭める。

この他にも、「インタビューを10回こなした後でMVPの作成に着手することを勧める」や、著者の場合「15〜20回のインタビューをすると、課題とソリューションにポテンシャルがあるかどうかを確認できるようになる」などの具体的な表現が載っています。

###MVPについて
度々、MVPという単語を説明なく使いましたが、これはMinimum Viable Productの略で、「実用最小限の製品」のことです。
「実用」の捉え方が人によって非常に曖昧なので詳細な説明は控えますが、
特徴としては「時間をかけない」ことがります。
(充分に資金がかけられない場合は「お金をかけない」ことも重要な要素だと思いますが)

MVPを作る目的は、売れるかどうかを検証するためです。
ターゲットとなりそうな顧客がお金を出すかどうかを学ぶためです。
どのくらいの時間でMVPを作るのか、参考値として③の著者は__「MVPが機能するかどうかのために1ヶ月以上かかるのはオーバーエンジニアリング」__だと言っています。
③の本ではMVPの作り方なども紹介しているので参考にしてみるといいと思います。

以上です。いかがだったでしょうか。
アプリケーションの開発においてはプロトタイピングがMVP作成に有効な手段だと思っています。
次回はそのあたりをまとめたいと思います。
(2月の1週目あたりの予定)


追記(02/08)
予告してたプロトタイプについて書きました。
http://qiita.com/takamatsu/items/361ff68d68d4bd5badbe

25
30
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
25
30

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?