狠狠撸

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

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

“アジャイル開発”の理解を深める
具体的な進め?を知る
仮説検証型アジャイル開発の考え?
越境したい?へ失敗パターンで知る
/papanda/

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

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

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

こういうサービスを必要とする
ユーザーは必ずいる！

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

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

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

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

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

ウーバー版??をつくりたい。
(Uberのモデルに乗っかろう)

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

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

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

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

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

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

どうやって、このサービスを
ユーザーに届けるかって？
広告と、?コミさ。

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

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

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

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

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

MVPが完成した！
さて、どうやって売ろうか。

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

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

8つ?の失敗。
それは、「盲信」によるもの。

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

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

それって理論を捨てるってこと？
(何を信じたらいいの…)

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

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

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

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

そんな早く追随者の検証して?丈夫？
追随者の意?に引きづられない？

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

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

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

良い検証を。

狠狠撸

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

Recommended

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to 4つの戦犯から考えるサーヒ?スつ?くりの失败 (20)

More from toshihiro ichitani (20)

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