そのコマは回り続けるかそれとも倒れるか

609 Views

April 17, 16

スライド概要

DevLOVE関ヶ原で使用した背景資料。
仮説検証がデットエンドに陥らないための話、一部始終。

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

関連スライド

各ページのテキスト
1.

そのコマは回り続けるか   それとも倒れるか   〜~  デットエンドに陥らない仮説検証  〜~ @papanda Ichitani  Toshihiro   Toshihiro  Ichitani  All  Rights  Reserved.

2.

問い 新しい企画のスマホアプリ   ユーザーに届きましたか

3.

問い 気がついたら収⽀支が圧迫され   収⽀支計画に追われている

4.

問い 気がついたら収⽀支が圧迫され   収⽀支計画に追われている もっとヒトを⼊入れて営業、開発!

5.

問い 気がついたら収⽀支が圧迫され   収⽀支計画に追われている もっとヒトを⼊入れて営業、開発! 収⽀支計画!⼈人員追加!収⽀支計画!

6.

問い 気がついたら収⽀支が圧迫され   収⽀支計画に追われている もっとヒトを⼊入れて営業、開発! D N E D A 収⽀支計画!⼈人員追加!収⽀支計画! DE

7.

本⽇日のテーマ デットエンドに陥らない仮説検証

8.

50  =>  2

9.

50=>2 2 ある事業創出の活動において、   50本あまりのアイデアから、MVP開発へ⾄至ったのは   2本だけであった。

10.

MVP開発すら遠い 机上検証・擬似環境検証 価値探索索   (仮説検証) ターゲットユーザーに   ニーズがない Photo credit: Ferran. via Visual Hunt / CC BY-NC-ND 事業環境での検証 MVP開発   検証 ターゲットユーザーが   使わない Photo credit: Ferran. via Visual Hunt / CC BY-NC-ND プロダクト   を育てる 検証と開発を繰り返す

11.

MVP開発すら遠い 机上検証・擬似環境検証 価値探索索   (仮説検証) ターゲットユーザーに   ニーズがない Photo credit: Ferran. via Visual Hunt / CC BY-NC-ND 事業環境での検証 MVP開発   検証 ターゲットユーザーが   使わない Photo credit: Ferran. via Visual Hunt / CC BY-NC-ND プロダクト   を育てる 検証と開発を繰り返す

12.

仮説検証の三⼤大疾病 ユーザーに出会えない ⾃自分たちの課題解決が要らない Photo credit: antonychammond via Visual hunt / CC BY-NC-SA やたらと検証が⽌止まる

13.

⽌止める価値 50  =>  2 進むことだけが仮説検証の価値ではない。⽌止めることも価値。   …だが、リソース(ヒト、時間、カネ)が限られているのは常。   ⽌止めるためだけの検証に多⼤大なリソースはかけられない。   前に進むために必要なこととは?

14.

三⼤大疾病対策 ユーザーに出会えない   出会う⼿手段があいまいな   まま進めても後でデッドエンド ⾃自分たちの課題解決が要らない   課題解決感は感じるが   イマの⾏行行動を変える気はない PSfitの前に   PCfitの⾒見見⽴立立   ユーザーの声を聴く   ことでしか課題を   捉えられていない が必要 やたらと検証が⽌止まる   リソースが限りなく乏しい   ⾏行行く⼿手を阻む何かが現れがち ⾃自分たちがやるべき   他ならぬ理理由を   ⾒見見つけられていない …ひとつひとつ取り上げていきます。

15.

私のキャンバス遍歴に沿って Toshihiro  Ichitani  All  Rights  Reserved.

16.

ビジネスモデルキャンバス パートナー 主要活動 価値提案 顧客との関係 リソース チャネル コスト構造 http://businessmodelgeneration.com/ 収益の流流れ 顧客セグメント

17.

ビジネスモデルキャンバス パートナー 主要活動 リソース 価値提案 顧客との関係 顧客セグメント チャネル ・特徴は「パートナー」   ・扱う課題や要望を直接的に表現できない   コスト構造 収益の流れ ・私はすでに⽴立立ち上がっている事業のモデル化に     使ったりしています。 http://businessmodelgeneration.com/

18.

リーンキャンバス 課題 ソリューション 独⾃自の価値提案 圧倒的な優位性 主要指標 チャネル コスト構造 収益の流流れ 顧客セグメント

19.

リーンキャンバス 課題 ソリューション 主要指標 独⾃自の価値提案 圧倒的な優位性 顧客セグメント チャネル ・顧客  -‐‑‒  課題  -‐‑‒  価値提案  -‐‑‒  ソリューションの構造   コスト構造 収益の流れ   「課題解決のストーリー」を扱える   ・第1次⻑⾧長期利利⽤用キャンバス

20.

現象①  やたらと検証がとまる ユーザーに出会えない   出会う⼿手段があいまいな   まま進めても後でデッドエンド ⾃自分たちの課題解決が要らない   課題解決感は感じるが   イマの⾏行行動を変える気はない PSfitの前に   PCfitの⾒見見⽴立立   ユーザーの声を聴く   ことでしか課題を   捉えられていない が必要 やたらと検証が⽌止まる   リソースが限りなく乏しい   ⾏行行く⼿手を阻む何かが現れがち ⾃自分たちがやるべき   他ならぬ理理由を   ⾒見見つけられていない

21.

現象①  やたらと検証がとまる Photo credit: antonychammond via Visual hunt / CC BY-NC-SA ⼈人がいない、⼈人が出せない、やんわりとリジェクト、反対勢⼒力力、、   組織内の「やれない理理由」の⾼高まりは、   裏裏返すと「⾃自分たちがやるべき理理由」が相対的に弱いということ。 “⾃自分たちだけの⽂文脈”をモデルの中で常に⾒見見出しておきたい。   ①組織が動くには使命感が要る  ②何を実現したいのか⾒見見失わないように

22.

仮説キャンバス  ver1 ⽬目的 ビジョン 課題 ソリューション 主要指標 コスト構造/リスク 価値提案 圧倒的な優位性 チャネル 収益の流流れ/嬉しさ 顧客

23.

仮説キャンバス  ver1 ⽬目的 ビジョン 課題 ソリューション 価値提案 圧倒的な優位性 ・課題解決のストーリーを扱える   ・⾃自分たちがやるべき理理由=⽬目的、   主要指標 チャネル   顧客にどうなってもらいたいか=ビジョン     を常に思考の範囲に⼊入れる   ・第2次⻑⾧長期利利⽤用キャンバス コスト構造/リスク 収益の流流れ/嬉しさ 顧客

24.

仮説キャンバス  ver2

25.

仮説キャンバス  ver2 ・提案価値と課題を対応付けたい   ・代替⼿手段を明確に   ・…エリアが多すぎて複雑、思い出せない

26.

現象②  ⾃自分たちの課題解決が要らない ユーザーに出会えない   出会う⼿手段があいまいな   まま進めても後でデッドエンド ⾃自分たちの課題解決が要らない   課題解決感は感じるが   イマの⾏行行動を変える気はない PSfitの前に   PCfitの⾒見見⽴立立   ユーザーの声を聴く   ことでしか課題を   捉えられていない が必要 やたらと検証が⽌止まる   リソースが限りなく乏しい   ⾏行行く⼿手を阻む何かが現れがち ⾃自分たちがやるべき   他ならぬ理理由を   ⾒見見つけられていない

27.

現象②  ⾃自分たちの課題解決が要らない インタビューで、ユーザーの声を聞いて、確からしい課題を捉える。   確からしい課題に則りサービスデザインする。   …ところが、絶望的に利利⽤用されない。なぜ?

28.

その意⾒見見は⾃自分事か、他⼈人事か インタビュー結果では、   あれば使うだろうという意⾒見見 実際には、サイトに訪れても、   カートを使わない(CVしない)

29.

その意⾒見見は⾃自分事か、他⼈人事か インタビュー結果では、   あれば使うだろうという意⾒見見 実際には、サイトに訪れても、   カートを使わない(CVしない) なぜ??   ユーザーテストを実施して、   ユーザーを⽬目の前にして、   分かったこと

30.

その意⾒見見は⾃自分事か、他⼈人事か インタビュー結果では、   あれば使うだろうという意⾒見見 実際には、サイトに訪れても、   カートを使わない(CVしない) なぜ??   ユーザーテストを実施して、   ユーザーを⽬目の前にして、   分かったこと 「あれば使う」  ≠  「⾃自分も使う」   ⾃自分は使わない   なぜなら、◯◯(個々⼈人のささやかな理理由)だから スイッチングコスト  >  プロダクトから得られる価値

31.

ユーザーの世界へ⾃自分も⼊入る ユーザーが新たな⼿手段を利利⽤用開始するためには、   切切り替えするだけの理理由がなければならない。   その理理由を探るためには、ユーザーのいる世界の状況を、   ユーザーと同じように、⾒見見る、聴く、感じる必要がある。 ユーザーの要求に   ただ応えようするのではなく ユーザーの⽂文脈における   傾向(しようとすること)を捉える

32.

ユーザーが⾒見見ている世界、しようとすること どのようにすれば受け⼊入れられるか?   →  普段ユーザーが⽬目にしている世界から逸脱しない。       “⾃自分たち(ユーザー)のモノである”  と思える⾵風景をつくる。

33.

仮説キャンバス  ver3 ⽬目的 ビジョン ソリューション 優位性 評価指標 収益モデル 提案価値 顕在課題 代替⼿手段 状況 潜在課題 チャネル 傾向

34.

仮説キャンバス  ver3 ⽬目的 ビジョン ソリューション 優位性 評価指標 提案価値 顕在課題 代替⼿手段 状況 潜在課題 チャネル 傾向 ・顧客ではなく、状況とそして傾向   ・課題は、顕在課題(状況から)と潜在課題(傾向から)   収益モデル ・第3次⻑⾧長期利利⽤用キャンバス

35.

キャンバスとの付き合い⽅方 ここまで⾒見見てきたとおり、キャンバスは必要に応じて変えていく。   だったらチェックリストではダメなのか?と問われることがある。   私は「⼀一枚絵」にすることに意味を⾒見見出している。   ①全体像がファーストビューで⾒見見渡せる。     つまり、観点(エリア)間のつながりが⾒見見やすい。   ②全部が書けない。     つまり、本当に⼤大事なところに集中しやすい。   ⼀一枚のキャンバスで表現できない観点として「時間軸」がある。   サービスの進展とともに”⼤大事なところ”は移っていく。   それはキャンバス内の他のエリアかもしれないし、   キャンバスの外にあるかもしれない。

36.

最初にあった問い 新しい企画のスマホアプリ   ユーザーに届きましたか

37.

現象③  ユーザーに出会えない ユーザーに出会えない   出会う⼿手段があいまいな   まま進めても後でデッドエンド ⾃自分たちの課題解決が要らない   課題解決感は感じるが   イマの⾏行行動を変える気はない PSfitの前に   PCfitの⾒見見⽴立立   ユーザーの声を聴く   ことでしか課題を   捉えられていない が必要 やたらと検証が⽌止まる   リソースが限りなく乏しい   ⾏行行く⼿手を阻む何かが現れがち ⾃自分たちがやるべき   他ならぬ理理由を   ⾒見見つけられていない

38.

Product  Channel  fit 1 2 3 PCfit PSfit PMfit Product  Channel  Fit Problem  Solution  Fit Product  Market  Fit プロダクトを届けられる   ユーザーの課題を解決する 多くのユーザーに届ける ステージ ⽬目的 仮説です チャネルを⾒見見⽴立立てる   開拓拓する ブースター メインユーザー 提案価値 ブースター=サービスを最初 に⽀支えるユーザー。アーリー アダプターとは異異なるJob  to   be  doneがあり、VPも異異なる 表現となる。それでいてイノ ベーター(⾰革新者)でもない。   アーリーアダプターより届け やすい。(逆にいうとアーリー に⼀一度度に届けられるならば不不 要な概念念) ブースター   向けのVP アーリーアダプター 提供者の意思として届けたい ユーザーの課題解決が可能と なるよう、プロダクトの調整 を⾏行行う。   マジョリティに向けた利利⽤用実 績の確保。 アーリーアダプター   向けのVP コンフリクト(VPが異異なる) マジョリティ 多くのユーザーの課題解決に 進む。マジョリティ向けにVP を補完するべくプロダクトを 調整する。   また、届けることに多くのリ ソースを注⼒力力する。 マジョリティ   向けに補完されたVP キャズム(チャネルも異異なる)

39.

Product  Channel  fit 1 2 3 PCfit PSfit PMfit Product  Channel  Fit Problem  Solution  Fit Product  Market  Fit プロダクトを届けられる   ユーザーの課題を解決する 多くのユーザーに届ける ステージ ⽬目的 仮説です チャネルを⾒見見⽴立立てる   開拓拓する ブースター メインユーザー 提案価値 ブースター=サービスを最初 に⽀支えるユーザー。アーリー アダプターとは異異なるJob  to   be  doneがあり、VPも異異なる 表現となる。それでいてイノ ベーター(⾰革新者)でもない。   アーリーアダプターより届け やすい。(逆にいうとアーリー に⼀一度度に届けられるならば不不 要な概念念) 圧倒的な   ブースター   向けのVP 欲望 アーリーアダプター 提供者の意思として届けたい ユーザーの課題解決が可能と なるよう、プロダクトの調整 を⾏行行う。   マジョリティに向けた利利⽤用実 績の確保。 敏感な   欲求 コンフリクト(VPが異異なる) マジョリティ 多くのユーザーの課題解決に 進む。マジョリティ向けにVP を補完するべくプロダクトを 調整する。   また、届けることに多くのリ ソースを注⼒力力する。 わかり   やすさ キャズム(チャネルも異異なる)

40.

例例えば、ポイントサービス ステージ ⽬目的 仮説です 1 2 3 PCf期 PSf期 PMf期 Product  Channel  Fit Problem  Solution  Fit Product  Market  Fit プロダクトを届けられる   ユーザーの課題を解決する 多くのユーザーに届ける ??? ??? チャネルを⾒見見⽴立立てる   開拓拓する メインユーザー ポイントゲッター お得に敏感な   お買い物客 提案価値 とにかく稼げる お得に買える

41.

問い 気がついたら収⽀支が圧迫され   収⽀支計画に追われている もっとヒトを⼊入れて営業、開発! 収⽀支計画!⼈人員追加!収⽀支計画!

42.

問い 気がついたら収⽀支が圧迫され   収⽀支計画に追われている もっとヒトを⼊入れて営業、開発! ? た い して 始 開 収⽀支計画!⼈人員追加!収⽀支計画! 事業

43.

事業化判断はいつどのようにおこなったのか? ビジネスモデルの検証と   ビジネスの遂⾏行行を混同しない

44.

モデル世界  ⇔  MVP  ⇔  現実世界 ビジネスモデル の世界 ビジネス の世界

45.

モデル世界  ⇔  MVP  ⇔  現実世界 ビジネスモデル の世界 MVP ビジネス の世界 MVPがモデルの世界と現実世界をつなぐ

46.

モデル世界  ⇔  MVP  ⇔  現実世界 ビジネスモデル の世界 MVP ビジネス の世界 フィードバック

47.

モデル世界  ⇔  MVP  ⇔  現実世界 ビジネスモデル の世界 Product もっとフィードバック! ビジネス の世界 MVP  ⇔  現実世界に集中し始めると何かがいっぱいできる   =  ⽬目の前最適化  (ex.  ビジネスを回すために○○が必要)

48.

モデル世界  ⇔  MVP  ⇔  現実世界 ビジネスモデル の世界 Product ビジネス の世界 もっとフィードバック! ? ? 開始 業 事 = ス MVP  ⇔  現実世界に集中し始めると何かがいっぱいできる   ー リ リ P V =  M ⽬目の前最適化  (ex.  ビジネスを回すために○○が必要)

49.

モデル世界  ⇔  MVP  ⇔  現実世界 ビジネスモデル もっと機能!   もっとユーザービリティ! の世界 MVP ビジネス の世界 とはいえ現実世界に出ていかないのはもっとダメ

50.

モデル世界  ⇔  MVP  ⇔  現実世界 フィードバックをモデルに⽴立立ち返らせる   イマ何が分かっていて、何が分かっていないのか問う。 ビジネスモデル の世界 MVP ビジネス の世界 どのように事業化判断を⾏行行なうかを決めておく。   勢いや政治ではなく、事実に基づく判断が⾏行行えるように。

51.

[補⾜足]  問う機会のデザイン 問おうで終わると精神論論になってしまうので、具体的な作戦として   ⾃自分たちの仮説検証の過去と、イマと、理理想を可視化することが   あげられる。   ①  validation  board     https://www.leanstartupmachine.com/validationboard/   ②  javelin  board   このあたりのフレームを真⾯面⽬目に使うことが⽬目的ではないので   参考までに。ロードマップはダメな例例で槍⽟玉にあがったりするが   ⽬目的が果たせるのであればなんだっていい。   時間軸が可視化されると、事業化判断のタイミングと内容を議論論   しやすい。

52.

さて

53.

いま、あなたは   モデルの世界と現実の世界   どちらで、何をしようと   していますか

54.

本当にモデルの検証になっているか?

55.

Photo credit: Shing Yan via Visual hunt / CC BY-NC-SA

56.

Photo credit: pagarneau via Visualhunt / CC BY-NC

57.

そのコマは回り続けるか   それとも倒れるか   〜~  デットエンドに陥らない仮説検証  〜~ Toshihiro  Ichitani  All  Rights  Reserved.

58.

市⾕谷聡啓 ギルドワークス代表 http://guildworks.jp/ DevLOVE  Founder https://devlove.doorkeeper.jp/ 越境をenergizeし続ける https://www.facebook.com/papanda0806 https://twitter.com/papanda http://papanda.hatenablog.com/ Toshihiro  Ichitani  All  Rights  Reserved.