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

4つの「戦犯」から考える サービスづくりの失敗 世の中の理論と失敗体験から ⾃分だけの論を作り出そう Ichitani Toshihiro Toshihiro Ichitani All Rights Reserved. 市⾕聡啓

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

• http://about.me/papanda0806

Toshihiro Ichitani All Rights Reserved.

仮説検証型アジャイル開発の考え⽅ “アジャイル開発”の理解を深める https://www.slideshare.net/papanda/ 失敗パターンで知る 越境したい⽅へ Toshihiro Ichitani All Rights Reserved. 具体的な進め⽅を知る

• https://www.slideshare.net/papanda/

まずは のべ200本以上(推定)の サービスづくりの中で、 よくある失敗パターン(体感) のおさらい このお話では問題に対して 「ではどうする？」には触れません。 どうする話はこちらを→ https://www.slideshare.net/papanda/7-79699560 Toshihiro Ichitani All Rights Reserved.

• https://www.slideshare.net/papanda/7-79699560

サービスづくりにおける、3つの「戦犯」 怠惰 本当は考慮しておくべきことなのに、やっていない。 仮説検証そのものをやっていない。 短気 判断が早計すぎる。 「早く進める」が絶対的な価値基準になっている。 傲慢 ⾃分の都合の良いように解釈して事を進めてしまう。 現実に⽬をむけようとしない。 Toshihiro Ichitani All Rights Reserved.

7つの失敗パターン 想像だけで 始めてしまう 怠惰 短気 アテンションにあたる価値 優位性と がない つながっていない 体験の検証を チャネル検証を やってない やってない 検証結果を都合良く 傲慢 解釈してしまう 事業を始めてしまう Toshihiro Ichitani All Rights Reserved.

7つの失敗パターン 想像だけで 始めてしまう 怠惰 短気 アテンションにあたる価値 優位性と がない つながっていない 体験の検証を チャネル検証を やってない やってない 検証結果を都合良く 傲慢 解釈してしまう 事業を始めてしまう Toshihiro Ichitani All Rights Reserved.

こういうサービスを必要とする ユーザーは必ずいる！ Toshihiro Ichitani All Rights Reserved.

こういうサービスを必要とする ユーザーは必ずいる！ 想像だけで始めてしまう。 既にプロダクトをつくるという意思決定が 終わっているが、その根拠が特にない。 (担当のたぶんこうなんじゃないかという勘) Toshihiro Ichitani All Rights Reserved.

よくあるケース 予算のムダ使いは取り返しがつくが、時間は取り返せない。 過ぎ去った時間は、環境の変化となって返ってくる。 環境の変化には、期待の劣化や倦怠感という⼈間の感情も 含まれる。(チームがダメになったら本当に何も残らない) Toshihiro Ichitani All Rights Reserved.

7つの失敗パターン 想像だけで 始めてしまう 怠惰 短気 アテンションにあたる価値 優位性と がない つながっていない 体験の検証を チャネル検証を やってない やってない 検証結果を都合良く 傲慢 解釈してしまう 事業を始めてしまう Toshihiro Ichitani All Rights Reserved.

これでユーザーの問題は解決できる！ (…でも、何かピリッとしない感じ？) Toshihiro Ichitani All Rights Reserved.

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

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

ウーバー版◯◯をつくりたい。 (Uberのモデルに乗っかろう) Toshihiro Ichitani All Rights Reserved.

ウーバー版◯◯をつくりたい。 (Uberのモデルに乗っかろう) 優位性とつながっていない。 モデルを転⽤するのは良いが、転⽤先の領域に 何かしら⾃社の競争優位性があるわけではない。 いくらでも思いついちゃって(◯◯の部分)、 ⼀つも前に進められない。 Toshihiro Ichitani All Rights Reserved.

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

7つの失敗パターン 想像だけで 始めてしまう 怠惰 短気 アテンションにあたる価値 優位性と がない つながっていない 体験の検証を チャネル検証を やってない やってない 検証結果を都合良く 傲慢 解釈してしまう 事業を始めてしまう Toshihiro Ichitani All Rights Reserved.

課題の仮説も、ソリューションの仮説も 検証できた。あとは機能を開発！ Toshihiro Ichitani All Rights Reserved.

課題の仮説も、ソリューションの仮説も 検証できた。あとは機能を開発！ 体験の検証をやっていない インタビューやモックアップでの検証を通じて 仮説の構造を成り⽴たせるところまで来た。 ⾔葉や絵、イメージで想定ユーザーとの コミュケーションは取れているかもしれない。 でも、UserはまだはUseしていないけど⼤丈夫？ Toshihiro Ichitani All Rights Reserved.

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

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

• https://www.amazon.co.jp/dp/4395012086

どうやって、このサービスを ユーザーに届けるかって？ 広告と、⼝コミさ。 Toshihiro Ichitani All Rights Reserved.

どうやって、このサービスを ユーザーに届けるかって？ 広告と、⼝コミさ。 チャネルの検証をやっていない 開発がほぼ終わりを迎える頃に、チャネルの検討を 本格的に始める。 構想段階では「広告と⼝コミ」という置きの想定 しかない。結果、実現段階では「広告」頼み。 ユーザーにどうやって知ってもらうの戦いの開幕。 Toshihiro Ichitani All Rights Reserved.

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

7つの失敗パターン 想像だけで 始めてしまう 怠惰 短気 アテンションにあたる価値 優位性と がない つながっていない 体験の検証を チャネル検証を やってない やってない 検証結果を都合良く 傲慢 解釈してしまう 事業を始めてしまう Toshihiro Ichitani All Rights Reserved.

検証で結果が出た！ Aさんのインタビュー結果はダメだった けど、この⼈はユーザーではない。 Toshihiro Ichitani All Rights Reserved.

検証で結果が出た！ Aさんのインタビュー結果はダメだった けど、この⼈はユーザーではない。 検証結果を都合良く解釈してしまう この⼈はユーザーではない、 10⼈中7⼈がOKだったから、OK この機能がまだ無かったから、ダメだっただけ… ⾃分の⾒⽅に偏り(バイアス)があることに、 ⽣まれていることに、気づけていない。 Toshihiro Ichitani All Rights Reserved.

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

7つの失敗パターン 想像だけで 始めてしまう 怠惰 短気 アテンションにあたる価値 優位性と がない つながっていない 体験の検証を チャネル検証を やってない やってない 検証結果を都合良く 傲慢 解釈してしまう 事業を始めてしまう Toshihiro Ichitani All Rights Reserved.

MVPが完成した！ さて、どうやって売ろうか。 Toshihiro Ichitani All Rights Reserved.

MVPが完成した！ さて、どうやって売ろうか。 事業を始めてしまう 分かりやすい動くモノがまとまって得られると、 組織的な圧⼒、また関係者(当事者含む)の期待が ⾼まり「どうやって売るか、どのくらい売れるか」 の議論と活動が始まってしまう。 Toshihiro Ichitani All Rights Reserved.

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

7つの失敗パターン 想像だけで 始めてしまう 怠惰 短気 アテンションにあたる価値 優位性と がない つながっていない 体験の検証を チャネル検証を やってない やってない 検証結果を都合良く 傲慢 解釈してしまう 事業を始めてしまう Toshihiro Ichitani All Rights Reserved.

8つ⽬の失敗。 「盲信」によるもの。 それは、 Toshihiro Ichitani All Rights Reserved.

まずはアーリーアダプターを 攻略しよう！マジョリティは後！ アーリー マジョリティ 採⽤者数 レイト マジョリティ アーリー アダプター ラガート イノベーター キャズム Toshihiro Ichitani All Rights Reserved. 時間

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

それって理論を捨てるってこと？ (何を信じたらいいの…) Toshihiro Ichitani All Rights Reserved.

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

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

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

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

そんな早く追随者の検証して⼤丈夫？ 追随者の意⾒に引きづられない？ Toshihiro Ichitani All Rights Reserved.

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

4つの戦犯、8つの失敗パターン 想像だけで 盲信 始めてしまう 怠惰 アテンションにあたる価値 優位性と がない つながっていない 世の中の 短気 体験の検証を チャネル検証を やってない やってない 検証結果を都合良く 傲慢 解釈してしまう 事業を始めてしまう Toshihiro Ichitani All Rights Reserved. 理論を 鵜呑みに する

他⼈の話は、あくまでその⼈の旅のお話。 あなたの旅に適しているかは、⾃分で判断しなければならない。 そう、もちろん、この話だって。 Toshihiro Ichitani All Rights Reserved.

良い検証を。 Toshihiro Ichitani All Rights Reserved.