4つの戦犯から考えるサービスづくりの失敗

2. Toshihiro Ichitani All Rights Reserved. http://about.me/papanda0806 Ichitani Toshihiro 市⾕聡啓ソフトウェア開発16年 SIer→サービス→受託→起業仮説検証とアジャイル開発ギルドワークス株式会社代表株式会社エナジャイル代表⼀般社団法⼈越境アジャイルアライアンス代表理事 DevLOVE コミュニティファウンダ 0 → 1

14. Toshihiro Ichitani All Rights Reserved. アテンションにあたる価値がない。想定ユーザー、顧客の課題を解決できる仕組みは構想できたし、何なら検証の結果もまずまず。しかし、検証では「ユーザーが⾶びつくほどの感じ」ではない。本当にこれで良いのか？アテンション(=注⽬)にあたる価値が⽋けているかもしれない。これでユーザーの問題は解決できる！ (…でも、何かピリッとしない感じ？)

15. Toshihiro Ichitani All Rights Reserved. 問題はなに？「使ってもらえたら、(価値を感じてもらえる)」という仮定。その仮定はたいてい成⽴しない。「使ってもらえたら、」という仮定を満たすために「チャネル」獲得にいくらリソースを投⼊してもできるのは「届ける」こと。「届く」と「⽬を引く」は違う。 (届けるのは「チャネル」、⽬を引くのは「価値」) 「アテンションにあたる価値がない」

18. Toshihiro Ichitani All Rights Reserved. 問題はなに？「われわれはなぜここにいるのか？」他ならぬ⾃分たちがこのテーマを取り組む理由は何か？に答えられない段階でも、意思決定してしまう。結果、判断としては・「優位性はつくりこむ」→ コスト度外視？・「先⾏することが優位性」→ 先⾏≠参⼊障壁になりがち。スタートはできても継続する⼒が不⾜。「優位性とつながっていない。」

22. Toshihiro Ichitani All Rights Reserved. 問題はなに？想定ユーザーの利⽤体験を成り⽴たせることが出来るのか、まったく検証しないままつくりはじめてしまう。 MVPの検証の⽬的が分かれるところ。何のためにプロダクトをつくるのか？ ① 体験の検証のために ② あくまで最初の市場投⼊のために → ②の場合「つくりすぎのムダ」になる可能性が⾼い。「体験の検証をやっていない」

23. Toshihiro Ichitani All Rights Reserved. 何の検証を⾏っているのか？そもそも仮説とは何か？仮説には3つの側⾯を捉えることができる。「利⽤者の課題についての仮説」「サービスの機能についての仮説」「ユーザーインターフェースについての仮説」なのか。それぞれ、提供サービスの「本質」「実体」「形態」にあたる。それぞれが検証の対象。かかたかたち本質実体形態課題の仮説機能の仮説 UIの仮説どんな状況の⼈たちの、どんな問題を解決するのか = 本質的な価値本質的な価値が利⽤者にもたらされるために必要な機能とは何か=機能性利⽤者が機能を使えるために適したUIとは何か = ユーザビリティ https://www.amazon.co.jp/dp/4395012086参考「代謝建築論―か・かた・かたち」

26. Toshihiro Ichitani All Rights Reserved. 問題はなに？ユーザーにどうやって届けるかの算段が初期の段階では、後回しになりがち。後になって「届けるコスト」が現実的ではないことに気付く。そもそも、インタビューでの検証を⾏なう時に「インタビュー相⼿が確保できない」という状況から学びを得なければならない。インタビューもできないのにどうやってユーザーに届けるのか？「チャネルの検証をやっていない」

30. Toshihiro Ichitani All Rights Reserved. 問題はなに？都合の良い解釈で、誤った意思決定してしまう。また、想定ユーザー側が事実を語っておらず、解釈は正しいが、データが誤っている場合もある。 (定量的な数値判断が出来ない段階ではこの⼿の誤りが起きやすい) 集団で解釈しようとすると、安易な解釈と過度な同調が⽣まれることも多い。「ここまでやったんだから…」→ 批判したくない。「検証結果を都合良く解釈してしまう」

34. Toshihiro Ichitani All Rights Reserved. 問題はなに？ MVPで検証したいのはビジネスモデル。事業を始めてしまうと、モデルの検証ではなくビジネス⾃体が始まってしまう。結果、「達成すべき収益計画」へのコミット圧が⾼まり、体制が構築され、コストを抑える議論が早期に始まり、検証が進まないまま、突き進んでしまう。(まさに顧客開発モデルの問題意識の再現) 「事業を始めてしまう」

38. Toshihiro Ichitani All Rights Reserved. 本当に「世の中の理論」をあなたの事業に適⽤して⼤丈夫か？「世の中の理論」が根拠としている「事例」や「状況」は本当に⾃分のプロダクトや状況にもあてはまるだろうか？⾃分の⼿元の事業の判断に、Amaz◯nやAp◯leの意思決定⼿法や基準を持ってきて本当に合うのか？アーリーアダプターを攻略した後に、マジョリティに向かっていく作戦に勝算はつくれるのか？ユーザー体験を磨いて…ホールプロダクトに仕⽴てて… で、本当に届くのか？

40. Toshihiro Ichitani All Rights Reserved. それって理論を捨てるってこと？ (何を信じたらいいの…) 他⼈の理論を元に、⾃分の理論をつくる他⼈がこれまで検証してきた論を、踏み台にしよう。例えば、「ユーザーには特徴によるグループがある (イノベーター理論)」「早期採⽤者とそれ以降で⼤きな隔たりがある (キャズム理論)」を踏み台に、⾃分のこれまでの経験(=分かっていること) を加えて、論を⽴ててみる (次⾴からは「私の論」)。

41. Toshihiro Ichitani All Rights Reserved. 先駆者と追随者を識別、把握する。「先駆者」を新しいプロダクトへの感度が⾼い顧客、「追随者」を対象課題がまだ潜在的な顧客とする。 (先駆者が何%、追随者が何%なんて、対象のテーマ次第なのでどうでも良い) 追随者先駆者先進的なサービスへの反応代替製品があるサービスへの反応対象の課題が顕在化しており、先進的なサービスへの反応感度も⾼い。課題への関⼼が既に低くなっている。対象の課題が潜在化している。ゆえに、⾃分から解決に動かない。先進的なサービスへの反応速度は⾼くない。課題が顕在化しており、サービスを理解できる。代替製品との⽐較によって、対象の価値を判断する。

42. Toshihiro Ichitani All Rights Reserved. 本当に検証のフェーズ分けをするべきか？問題は、 ①先駆者向け検証フェーズ ②プロダクト開発／事業⽴ち上げフェーズ ③追随者向け検証フェーズという順序にある。「事業としてやるだけの値打ちがある」と判断するのに求められるボリュームは、先駆者の獲得だけではダメ。追随者に受け⼊れられないと、たいてい事業継続はできない。上記の順番だと、③のときにたいてい挫折する。

43. Toshihiro Ichitani All Rights Reserved. 追随者の検証を後回しにしない。ビジネスの進捗意思決定の順序(検証の割合) 主に先駆者向けのプロダクト開発先駆者向けの事業展開主に追随者向けのプロダクト開発追随者向けの事業展開先駆者向け検証追随者向け検証先駆者向け検証追随者向け検証追随者向け検証先駆者向け検証つくらない検証 MVP検証プロダクト検証 MVPをつくって検証を進める判断プロダクトを本格的に作って検証を進める判断検証は続くよ

45. Toshihiro Ichitani All Rights Reserved. そんな早く追随者の検証して⼤丈夫？追随者の意⾒に引きづられない？遅かれ早かれ追随者に向き合うことになるだから、先駆者と追随者の識別が⼤事(先駆者と追随者向けでキャンバスを分ける)。初期の段階では、誰が先駆者で誰が追随者なんて、仮説でしかない。後から、気付く。ただし判断を誤らないよう、「早く」気付くために、検証を「素早く」繰り返す。

4つの戦犯から考えるサービスづくりの失敗

toshihiro ichitani

4つの戦犯から考えるサービスづくりの失敗