SlideShare a Scribd company logo
Toshihiro Ichitani All Rights Reserved.
4つの「戦犯」から考える
サービスづくりの失敗
Ichitani Toshihiro
市⾕聡啓
世の中の理論と失敗体験から
⾃分だけの論を作り出そう
Toshihiro Ichitani All Rights Reserved.
http://about.me/papanda0806
Ichitani Toshihiro
市⾕聡啓
ソフトウェア開発16年
SIer→サービス→受託→起業
仮説検証とアジャイル開発
ギルドワークス株式会社 代表
株式会社 エナジャイル 代表
⼀般社団法⼈ 越境アジャイルアライアンス代表理事
DevLOVE コミュニティ ファウンダ
0 → 1
Toshihiro Ichitani All Rights Reserved.
Toshihiro Ichitani All Rights Reserved.
“アジャイル開発”の理解を深める
具体的な進め⽅を知る
仮説検証型アジャイル開発の考え⽅
越境したい⽅へ失敗パターンで知る
https://www.slideshare.net/papanda/
Toshihiro Ichitani All Rights Reserved.
まずは
のべ200本以上(推定)の
サービスづくりの中で、
よくある失敗パターン(体感)
のおさらい
https://www.slideshare.net/papanda/7-79699560
このお話では問題に対して
「ではどうする?」には触れません。
どうする話はこちらを→
Toshihiro Ichitani All Rights Reserved.
サービスづくりにおける、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.
どうやって、このサービスを
ユーザーに届けるかって?
広告と、⼝コミさ。
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.
良い検証を。

More Related Content

What's hot

心理的安全性を 0から80ぐらいに上げた話
心理的安全性を 0から80ぐらいに上げた話心理的安全性を 0から80ぐらいに上げた話
心理的安全性を 0から80ぐらいに上げた話
Yusuke Hisatsu
 
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
mosa siru
 
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
 
フロー効率性とリソース効率性、再入門 #devlove #devkan
フロー効率性とリソース効率性、再入門 #devlove #devkanフロー効率性とリソース効率性、再入門 #devlove #devkan
フロー効率性とリソース効率性、再入門 #devlove #devkan
Itsuki Kuroda
 
暗号技術の実装と数学
暗号技術の実装と数学暗号技術の実装と数学
暗号技術の実装と数学
MITSUNARI Shigeo
 
シリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのかシリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのか
Atsushi Nakada
 
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
45分間で「ユーザー中心のものづくり」ができるまで詰め込む45分間で「ユーザー中心のものづくり」ができるまで詰め込む
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
Yoshiki Hayama
 
IT系エンジニアのためのプレゼンテーション入門
IT系エンジニアのためのプレゼンテーション入門IT系エンジニアのためのプレゼンテーション入門
IT系エンジニアのためのプレゼンテーション入門
Masahito Zembutsu
 
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
Atsushi Nakamura
 
SIerで幸せな技術キャリアを築くために
SIerで幸せな技術キャリアを築くためにSIerで幸せな技術キャリアを築くために
SIerで幸せな技術キャリアを築くために
Takanari Konishi
 
40歳過ぎてもエンジニアでいるためにやっていること
40歳過ぎてもエンジニアでいるためにやっていること40歳過ぎてもエンジニアでいるためにやっていること
40歳過ぎてもエンジニアでいるためにやっていること
onozaty
 
SQLおじさん(自称)がBigQueryのStandard SQLを使ってみた
SQLおじさん(自称)がBigQueryのStandard SQLを使ってみたSQLおじさん(自称)がBigQueryのStandard SQLを使ってみた
SQLおじさん(自称)がBigQueryのStandard SQLを使ってみた
Kumano Ryo
 
分散システムについて語らせてくれ
分散システムについて語らせてくれ分散システムについて語らせてくれ
分散システムについて語らせてくれ
Kumazaki Hiroki
 
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLiveDXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
Tokoroten Nakayama
 
ネットストーカー御用達OSINTツールBlackBirdを触ってみた.pptx
ネットストーカー御用達OSINTツールBlackBirdを触ってみた.pptxネットストーカー御用達OSINTツールBlackBirdを触ってみた.pptx
ネットストーカー御用達OSINTツールBlackBirdを触ってみた.pptx
Shota Shinogi
 
チケット駆動開発の解説~タスク管理からプロセス改善へ
チケット駆動開発の解説~タスク管理からプロセス改善へチケット駆動開発の解説~タスク管理からプロセス改善へ
チケット駆動開発の解説~タスク管理からプロセス改善へ
akipii Oga
 
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
Tokoroten Nakayama
 
PHPからgoへの移行で分かったこと
PHPからgoへの移行で分かったことPHPからgoへの移行で分かったこと
PHPからgoへの移行で分かったこと
gree_tech
 
Lean coffee
Lean coffeeLean coffee
Lean coffee
Takeshi Arai
 
ユーザーストーリーの分割
ユーザーストーリーの分割ユーザーストーリーの分割
ユーザーストーリーの分割
Arata Fujimura
 

What's hot (20)

心理的安全性を 0から80ぐらいに上げた話
心理的安全性を 0から80ぐらいに上げた話心理的安全性を 0から80ぐらいに上げた話
心理的安全性を 0から80ぐらいに上げた話
 
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
 
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
 
フロー効率性とリソース効率性、再入門 #devlove #devkan
フロー効率性とリソース効率性、再入門 #devlove #devkanフロー効率性とリソース効率性、再入門 #devlove #devkan
フロー効率性とリソース効率性、再入門 #devlove #devkan
 
暗号技術の実装と数学
暗号技術の実装と数学暗号技術の実装と数学
暗号技術の実装と数学
 
シリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのかシリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのか
 
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
45分間で「ユーザー中心のものづくり」ができるまで詰め込む45分間で「ユーザー中心のものづくり」ができるまで詰め込む
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
 
IT系エンジニアのためのプレゼンテーション入門
IT系エンジニアのためのプレゼンテーション入門IT系エンジニアのためのプレゼンテーション入門
IT系エンジニアのためのプレゼンテーション入門
 
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
 
SIerで幸せな技術キャリアを築くために
SIerで幸せな技術キャリアを築くためにSIerで幸せな技術キャリアを築くために
SIerで幸せな技術キャリアを築くために
 
40歳過ぎてもエンジニアでいるためにやっていること
40歳過ぎてもエンジニアでいるためにやっていること40歳過ぎてもエンジニアでいるためにやっていること
40歳過ぎてもエンジニアでいるためにやっていること
 
SQLおじさん(自称)がBigQueryのStandard SQLを使ってみた
SQLおじさん(自称)がBigQueryのStandard SQLを使ってみたSQLおじさん(自称)がBigQueryのStandard SQLを使ってみた
SQLおじさん(自称)がBigQueryのStandard SQLを使ってみた
 
分散システムについて語らせてくれ
分散システムについて語らせてくれ分散システムについて語らせてくれ
分散システムについて語らせてくれ
 
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLiveDXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
 
ネットストーカー御用達OSINTツールBlackBirdを触ってみた.pptx
ネットストーカー御用達OSINTツールBlackBirdを触ってみた.pptxネットストーカー御用達OSINTツールBlackBirdを触ってみた.pptx
ネットストーカー御用達OSINTツールBlackBirdを触ってみた.pptx
 
チケット駆動開発の解説~タスク管理からプロセス改善へ
チケット駆動開発の解説~タスク管理からプロセス改善へチケット駆動開発の解説~タスク管理からプロセス改善へ
チケット駆動開発の解説~タスク管理からプロセス改善へ
 
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
 
PHPからgoへの移行で分かったこと
PHPからgoへの移行で分かったことPHPからgoへの移行で分かったこと
PHPからgoへの移行で分かったこと
 
Lean coffee
Lean coffeeLean coffee
Lean coffee
 
ユーザーストーリーの分割
ユーザーストーリーの分割ユーザーストーリーの分割
ユーザーストーリーの分割
 

Viewers also liked

逆境からのアジャイル
逆境からのアジャイル逆境からのアジャイル
逆境からのアジャイル
toshihiro ichitani
 
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
Kumazaki Hiroki
 
正しいものを正しくつくる
正しいものを正しくつくる正しいものを正しくつくる
正しいものを正しくつくる
toshihiro ichitani
 
とにかく楽してVue.jsでTypeScriptを使いたい
とにかく楽してVue.jsでTypeScriptを使いたいとにかく楽してVue.jsでTypeScriptを使いたい
とにかく楽してVue.jsでTypeScriptを使いたい
さくらインターネット株式会社
 
ネットワーク ゲームにおけるTCPとUDPの使い分け
ネットワーク ゲームにおけるTCPとUDPの使い分けネットワーク ゲームにおけるTCPとUDPの使い分け
ネットワーク ゲームにおけるTCPとUDPの使い分け
モノビット エンジン
 
Redmine4時代のプラグイン開発 redmine.tokyo #13
Redmine4時代のプラグイン開発 redmine.tokyo #13Redmine4時代のプラグイン開発 redmine.tokyo #13
Redmine4時代のプラグイン開発 redmine.tokyo #13
Sho Douhashi
 
Java SE 9の紹介: モジュール・システムを中心に
Java SE 9の紹介: モジュール・システムを中心にJava SE 9の紹介: モジュール・システムを中心に
Java SE 9の紹介: モジュール・システムを中心に
Taku Miyakawa
 
Spring Bootの本当の理解ポイント #jjug
Spring Bootの本当の理解ポイント #jjugSpring Bootの本当の理解ポイント #jjug
Spring Bootの本当の理解ポイント #jjug
Masatoshi Tada
 
失敗を成功に近づけるアブダクションの科学
失敗を成功に近づけるアブダクションの科学失敗を成功に近づけるアブダクションの科学
失敗を成功に近づけるアブダクションの科学
Shigeyuki Kameda
 
宮崎大学キャリア講演20170111微修正版
宮崎大学キャリア講演20170111微修正版宮崎大学キャリア講演20170111微修正版
宮崎大学キャリア講演20170111微修正版
Takayuki Itoh
 
ネットワーク ゲームにおけるTCPとUDPの使い分け
ネットワーク ゲームにおけるTCPとUDPの使い分けネットワーク ゲームにおけるTCPとUDPの使い分け
ネットワーク ゲームにおけるTCPとUDPの使い分け
モノビット エンジン
 
WordPressで作る世界遺産サイト|Instagram API を使って現地フォト取得
WordPressで作る世界遺産サイト|Instagram API を使って現地フォト取得 WordPressで作る世界遺産サイト|Instagram API を使って現地フォト取得
WordPressで作る世界遺産サイト|Instagram API を使って現地フォト取得
Yoshinori Kobayashi
 
研究分野をサーベイする
研究分野をサーベイする研究分野をサーベイする
研究分野をサーベイする
Takayuki Itoh
 
渋谷java−あなたのプロジェクトで気軽にjavaをバージョンアップするために必要なこと
渋谷java−あなたのプロジェクトで気軽にjavaをバージョンアップするために必要なこと渋谷java−あなたのプロジェクトで気軽にjavaをバージョンアップするために必要なこと
渋谷java−あなたのプロジェクトで気軽にjavaをバージョンアップするために必要なこと
Y Watanabe
 
XP祭り関西(2015)資料 : アジャイル導入の価値
XP祭り関西(2015)資料 : アジャイル導入の価値XP祭り関西(2015)資料 : アジャイル導入の価値
XP祭り関西(2015)資料 : アジャイル導入の価値
Hikaru Taniguchi
 
わかばちゃんと学ぶフリーランスのための情報整理術 ー 湊川あい
わかばちゃんと学ぶフリーランスのための情報整理術 ー 湊川あいわかばちゃんと学ぶフリーランスのための情報整理術 ー 湊川あい
わかばちゃんと学ぶフリーランスのための情報整理術 ー 湊川あい
Ai Minatogawa
 
Property-Based Testing for Godly Tests
Property-Based Testing for Godly TestsProperty-Based Testing for Godly Tests
Property-Based Testing for Godly Tests
garbles
 
リンスタしくじり先生〜戦場の舞妓編〜
リンスタしくじり先生〜戦場の舞妓編〜リンスタしくじり先生〜戦場の舞妓編〜
リンスタしくじり先生〜戦場の舞妓編〜
圭 進藤
 
単純ベイズ法による異常検知 #ml-professional
単純ベイズ法による異常検知  #ml-professional単純ベイズ法による異常検知  #ml-professional
単純ベイズ法による異常検知 #ml-professional
Ai Makabi
 
エンジニア向け絶対に挫折しない個人サービスの作り方
エンジニア向け絶対に挫折しない個人サービスの作り方エンジニア向け絶対に挫折しない個人サービスの作り方
エンジニア向け絶対に挫折しない個人サービスの作り方
Atsushi Harada
 

Viewers also liked (20)

逆境からのアジャイル
逆境からのアジャイル逆境からのアジャイル
逆境からのアジャイル
 
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
 
正しいものを正しくつくる
正しいものを正しくつくる正しいものを正しくつくる
正しいものを正しくつくる
 
とにかく楽してVue.jsでTypeScriptを使いたい
とにかく楽してVue.jsでTypeScriptを使いたいとにかく楽してVue.jsでTypeScriptを使いたい
とにかく楽してVue.jsでTypeScriptを使いたい
 
ネットワーク ゲームにおけるTCPとUDPの使い分け
ネットワーク ゲームにおけるTCPとUDPの使い分けネットワーク ゲームにおけるTCPとUDPの使い分け
ネットワーク ゲームにおけるTCPとUDPの使い分け
 
Redmine4時代のプラグイン開発 redmine.tokyo #13
Redmine4時代のプラグイン開発 redmine.tokyo #13Redmine4時代のプラグイン開発 redmine.tokyo #13
Redmine4時代のプラグイン開発 redmine.tokyo #13
 
Java SE 9の紹介: モジュール・システムを中心に
Java SE 9の紹介: モジュール・システムを中心にJava SE 9の紹介: モジュール・システムを中心に
Java SE 9の紹介: モジュール・システムを中心に
 
Spring Bootの本当の理解ポイント #jjug
Spring Bootの本当の理解ポイント #jjugSpring Bootの本当の理解ポイント #jjug
Spring Bootの本当の理解ポイント #jjug
 
失敗を成功に近づけるアブダクションの科学
失敗を成功に近づけるアブダクションの科学失敗を成功に近づけるアブダクションの科学
失敗を成功に近づけるアブダクションの科学
 
宮崎大学キャリア講演20170111微修正版
宮崎大学キャリア講演20170111微修正版宮崎大学キャリア講演20170111微修正版
宮崎大学キャリア講演20170111微修正版
 
ネットワーク ゲームにおけるTCPとUDPの使い分け
ネットワーク ゲームにおけるTCPとUDPの使い分けネットワーク ゲームにおけるTCPとUDPの使い分け
ネットワーク ゲームにおけるTCPとUDPの使い分け
 
WordPressで作る世界遺産サイト|Instagram API を使って現地フォト取得
WordPressで作る世界遺産サイト|Instagram API を使って現地フォト取得 WordPressで作る世界遺産サイト|Instagram API を使って現地フォト取得
WordPressで作る世界遺産サイト|Instagram API を使って現地フォト取得
 
研究分野をサーベイする
研究分野をサーベイする研究分野をサーベイする
研究分野をサーベイする
 
渋谷java−あなたのプロジェクトで気軽にjavaをバージョンアップするために必要なこと
渋谷java−あなたのプロジェクトで気軽にjavaをバージョンアップするために必要なこと渋谷java−あなたのプロジェクトで気軽にjavaをバージョンアップするために必要なこと
渋谷java−あなたのプロジェクトで気軽にjavaをバージョンアップするために必要なこと
 
XP祭り関西(2015)資料 : アジャイル導入の価値
XP祭り関西(2015)資料 : アジャイル導入の価値XP祭り関西(2015)資料 : アジャイル導入の価値
XP祭り関西(2015)資料 : アジャイル導入の価値
 
わかばちゃんと学ぶフリーランスのための情報整理術 ー 湊川あい
わかばちゃんと学ぶフリーランスのための情報整理術 ー 湊川あいわかばちゃんと学ぶフリーランスのための情報整理術 ー 湊川あい
わかばちゃんと学ぶフリーランスのための情報整理術 ー 湊川あい
 
Property-Based Testing for Godly Tests
Property-Based Testing for Godly TestsProperty-Based Testing for Godly Tests
Property-Based Testing for Godly Tests
 
リンスタしくじり先生〜戦場の舞妓編〜
リンスタしくじり先生〜戦場の舞妓編〜リンスタしくじり先生〜戦場の舞妓編〜
リンスタしくじり先生〜戦場の舞妓編〜
 
単純ベイズ法による異常検知 #ml-professional
単純ベイズ法による異常検知  #ml-professional単純ベイズ法による異常検知  #ml-professional
単純ベイズ法による異常検知 #ml-professional
 
エンジニア向け絶対に挫折しない個人サービスの作り方
エンジニア向け絶対に挫折しない個人サービスの作り方エンジニア向け絶対に挫折しない個人サービスの作り方
エンジニア向け絶対に挫折しない個人サービスの作り方
 

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

Trust Based Development
Trust Based DevelopmentTrust Based Development
Trust Based Development
toshihiro ichitani
 
良い感じの状況をつくる
良い感じの状況をつくる良い感じの状況をつくる
良い感じの状況をつくる
toshihiro ichitani
 
逆境から新規事業をスタートアップする「仮説検証型アジャイル開発」の実践
逆境から新規事業をスタートアップする「仮説検証型アジャイル開発」の実践逆境から新規事業をスタートアップする「仮説検証型アジャイル開発」の実践
逆境から新規事業をスタートアップする「仮説検証型アジャイル開発」の実践
toshihiro ichitani
 
プロダクトオーナーが知るべき97のこと
プロダクトオーナーが知るべき97のことプロダクトオーナーが知るべき97のこと
プロダクトオーナーが知るべき97のこと
toshihiro ichitani
 
多様な働き⽅のチームでどうやって アジャイルにやるの?(雁行陣開発)
多様な働き⽅のチームでどうやって アジャイルにやるの?(雁行陣開発)多様な働き⽅のチームでどうやって アジャイルにやるの?(雁行陣開発)
多様な働き⽅のチームでどうやって アジャイルにやるの?(雁行陣開発)
toshihiro ichitani
 
越境・ジャーニー
越境・ジャーニー越境・ジャーニー
越境・ジャーニー
toshihiro ichitani
 
拝啓、プロダクトオーナー様。
拝啓、プロダクトオーナー様。拝啓、プロダクトオーナー様。
拝啓、プロダクトオーナー様。
GuildWorks
 
拝啓、プロダクトオーナー様。
拝啓、プロダクトオーナー様。拝啓、プロダクトオーナー様。
拝啓、プロダクトオーナー様。
toshihiro ichitani
 
チーム仕事のはじめ方 〜「チームビルド」から「チームマージ」へ
チーム仕事のはじめ方 〜「チームビルド」から「チームマージ」へチーム仕事のはじめ方 〜「チームビルド」から「チームマージ」へ
チーム仕事のはじめ方 〜「チームビルド」から「チームマージ」へ
toshihiro ichitani
 
価値探索 -仮説検証の実践-
価値探索 -仮説検証の実践-価値探索 -仮説検証の実践-
価値探索 -仮説検証の実践-
toshihiro ichitani
 
越境アジャイル
越境アジャイル越境アジャイル
越境アジャイル
toshihiro ichitani
 
時を超えた越境への道
時を超えた越境への道時を超えた越境への道
時を超えた越境への道
toshihiro ichitani
 
我々に越境できない境界は無い。
我々に越境できない境界は無い。我々に越境できない境界は無い。
我々に越境できない境界は無い。
toshihiro ichitani
 
身体化する組織
身体化する組織身体化する組織
身体化する組織
toshihiro ichitani
 
越境する開発 -Seek Right Things-
越境する開発 -Seek Right Things-越境する開発 -Seek Right Things-
越境する開発 -Seek Right Things-
GuildWorks
 
越境する開発 -Seek Right Things-
越境する開発 -Seek Right Things- 越境する開発 -Seek Right Things-
越境する開発 -Seek Right Things-
toshihiro ichitani
 
[Track3-1] ビジネスで役立つAIリテラシーから機械学習エンジニアリングまで実践形式で学ぶ課題解決型AI人材育成とは?〜国内最大AIコンペサイトの...
[Track3-1] ビジネスで役立つAIリテラシーから機械学習エンジニアリングまで実践形式で学ぶ課題解決型AI人材育成とは?〜国内最大AIコンペサイトの...[Track3-1] ビジネスで役立つAIリテラシーから機械学習エンジニアリングまで実践形式で学ぶ課題解決型AI人材育成とは?〜国内最大AIコンペサイトの...
[Track3-1] ビジネスで役立つAIリテラシーから機械学習エンジニアリングまで実践形式で学ぶ課題解決型AI人材育成とは?〜国内最大AIコンペサイトの...
Deep Learning Lab(ディープラーニング・ラボ)
 
ユーザーストーリー駆動開発で行こう。
ユーザーストーリー駆動開発で行こう。ユーザーストーリー駆動開発で行こう。
ユーザーストーリー駆動開発で行こう。
GuildWorks
 
もし友、学ぶ会 120218
もし友、学ぶ会 120218もし友、学ぶ会 120218
もし友、学ぶ会 120218
Arata Suehira
 
大きな組織にスクラムの輪を広げていくために
大きな組織にスクラムの輪を広げていくために大きな組織にスクラムの輪を広げていくために
大きな組織にスクラムの輪を広げていくために
Tomonori Fukuta
 

Similar to 4つの戦犯から考えるサービスづくりの失敗 (20)

Trust Based Development
Trust Based DevelopmentTrust Based Development
Trust Based Development
 
良い感じの状況をつくる
良い感じの状況をつくる良い感じの状況をつくる
良い感じの状況をつくる
 
逆境から新規事業をスタートアップする「仮説検証型アジャイル開発」の実践
逆境から新規事業をスタートアップする「仮説検証型アジャイル開発」の実践逆境から新規事業をスタートアップする「仮説検証型アジャイル開発」の実践
逆境から新規事業をスタートアップする「仮説検証型アジャイル開発」の実践
 
プロダクトオーナーが知るべき97のこと
プロダクトオーナーが知るべき97のことプロダクトオーナーが知るべき97のこと
プロダクトオーナーが知るべき97のこと
 
多様な働き⽅のチームでどうやって アジャイルにやるの?(雁行陣開発)
多様な働き⽅のチームでどうやって アジャイルにやるの?(雁行陣開発)多様な働き⽅のチームでどうやって アジャイルにやるの?(雁行陣開発)
多様な働き⽅のチームでどうやって アジャイルにやるの?(雁行陣開発)
 
越境・ジャーニー
越境・ジャーニー越境・ジャーニー
越境・ジャーニー
 
拝啓、プロダクトオーナー様。
拝啓、プロダクトオーナー様。拝啓、プロダクトオーナー様。
拝啓、プロダクトオーナー様。
 
拝啓、プロダクトオーナー様。
拝啓、プロダクトオーナー様。拝啓、プロダクトオーナー様。
拝啓、プロダクトオーナー様。
 
チーム仕事のはじめ方 〜「チームビルド」から「チームマージ」へ
チーム仕事のはじめ方 〜「チームビルド」から「チームマージ」へチーム仕事のはじめ方 〜「チームビルド」から「チームマージ」へ
チーム仕事のはじめ方 〜「チームビルド」から「チームマージ」へ
 
価値探索 -仮説検証の実践-
価値探索 -仮説検証の実践-価値探索 -仮説検証の実践-
価値探索 -仮説検証の実践-
 
越境アジャイル
越境アジャイル越境アジャイル
越境アジャイル
 
時を超えた越境への道
時を超えた越境への道時を超えた越境への道
時を超えた越境への道
 
我々に越境できない境界は無い。
我々に越境できない境界は無い。我々に越境できない境界は無い。
我々に越境できない境界は無い。
 
身体化する組織
身体化する組織身体化する組織
身体化する組織
 
越境する開発 -Seek Right Things-
越境する開発 -Seek Right Things-越境する開発 -Seek Right Things-
越境する開発 -Seek Right Things-
 
越境する開発 -Seek Right Things-
越境する開発 -Seek Right Things- 越境する開発 -Seek Right Things-
越境する開発 -Seek Right Things-
 
[Track3-1] ビジネスで役立つAIリテラシーから機械学習エンジニアリングまで実践形式で学ぶ課題解決型AI人材育成とは?〜国内最大AIコンペサイトの...
[Track3-1] ビジネスで役立つAIリテラシーから機械学習エンジニアリングまで実践形式で学ぶ課題解決型AI人材育成とは?〜国内最大AIコンペサイトの...[Track3-1] ビジネスで役立つAIリテラシーから機械学習エンジニアリングまで実践形式で学ぶ課題解決型AI人材育成とは?〜国内最大AIコンペサイトの...
[Track3-1] ビジネスで役立つAIリテラシーから機械学習エンジニアリングまで実践形式で学ぶ課題解決型AI人材育成とは?〜国内最大AIコンペサイトの...
 
ユーザーストーリー駆動開発で行こう。
ユーザーストーリー駆動開発で行こう。ユーザーストーリー駆動開発で行こう。
ユーザーストーリー駆動開発で行こう。
 
もし友、学ぶ会 120218
もし友、学ぶ会 120218もし友、学ぶ会 120218
もし友、学ぶ会 120218
 
大きな組織にスクラムの輪を広げていくために
大きな組織にスクラムの輪を広げていくために大きな組織にスクラムの輪を広げていくために
大きな組織にスクラムの輪を広げていくために
 

More from toshihiro ichitani

アジャイル開発は世界を変える夢を見るか
アジャイル開発は世界を変える夢を見るかアジャイル開発は世界を変える夢を見るか
アジャイル開発は世界を変える夢を見るか
toshihiro ichitani
 
ナラティブ・プロトタイピング
ナラティブ・プロトタイピングナラティブ・プロトタイピング
ナラティブ・プロトタイピング
toshihiro ichitani
 
組織にアジャイルの構造を作る
組織にアジャイルの構造を作る組織にアジャイルの構造を作る
組織にアジャイルの構造を作る
toshihiro ichitani
 
組織でアジャイルの ”回転” を繋ぐ
 組織でアジャイルの ”回転” を繋ぐ 組織でアジャイルの ”回転” を繋ぐ
組織でアジャイルの ”回転” を繋ぐ
toshihiro ichitani
 
組織アジャイルをはじめる
組織アジャイルをはじめる組織アジャイルをはじめる
組織アジャイルをはじめる
toshihiro ichitani
 
デジタルトランスフォーメーション・ジャーニー・デッキ
デジタルトランスフォーメーション・ジャーニー・デッキデジタルトランスフォーメーション・ジャーニー・デッキ
デジタルトランスフォーメーション・ジャーニー・デッキ
toshihiro ichitani
 
Digitaltransformation Journey
Digitaltransformation JourneyDigitaltransformation Journey
Digitaltransformation Journey
toshihiro ichitani
 
Agile again
Agile againAgile again
Agile again
toshihiro ichitani
 
伝統的な組織で始めるアジャイル
伝統的な組織で始めるアジャイル伝統的な組織で始めるアジャイル
伝統的な組織で始めるアジャイル
toshihiro ichitani
 
アジャイルブリゲード 〜対立する二項を組織の構造と仕組みによって繋ぐ〜
アジャイルブリゲード 〜対立する二項を組織の構造と仕組みによって繋ぐ〜アジャイルブリゲード 〜対立する二項を組織の構造と仕組みによって繋ぐ〜
アジャイルブリゲード 〜対立する二項を組織の構造と仕組みによって繋ぐ〜
toshihiro ichitani
 
私がのこすだろうたった1つの言葉
私がのこすだろうたった1つの言葉私がのこすだろうたった1つの言葉
私がのこすだろうたった1つの言葉
toshihiro ichitani
 
13年かけたら、言えること
13年かけたら、言えること13年かけたら、言えること
13年かけたら、言えること
toshihiro ichitani
 
正しいものをともに考え、正しくともにつくる
正しいものをともに考え、正しくともにつくる正しいものをともに考え、正しくともにつくる
正しいものをともに考え、正しくともにつくる
toshihiro ichitani
 
チーム・ジャーニー・デッキ
チーム・ジャーニー・デッキチーム・ジャーニー・デッキ
チーム・ジャーニー・デッキ
toshihiro ichitani
 
自分のハンドルは自分で握れ
自分のハンドルは自分で握れ自分のハンドルは自分で握れ
自分のハンドルは自分で握れ
toshihiro ichitani
 
チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで
チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまでチーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで
チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで
toshihiro ichitani
 
ISHII SPRINT
ISHII SPRINTISHII SPRINT
ISHII SPRINT
toshihiro ichitani
 
ともに考え、ともにつくる 〜リーン・ジャーニー・スタイル〜
ともに考え、ともにつくる 〜リーン・ジャーニー・スタイル〜 ともに考え、ともにつくる 〜リーン・ジャーニー・スタイル〜
ともに考え、ともにつくる 〜リーン・ジャーニー・スタイル〜
toshihiro ichitani
 
正しいものを正しくつくるへ至る道
正しいものを正しくつくるへ至る道正しいものを正しくつくるへ至る道
正しいものを正しくつくるへ至る道
toshihiro ichitani
 
プロダクト開発を繋げる
プロダクト開発を繋げるプロダクト開発を繋げる
プロダクト開発を繋げる
toshihiro ichitani
 

More from toshihiro ichitani (20)

アジャイル開発は世界を変える夢を見るか
アジャイル開発は世界を変える夢を見るかアジャイル開発は世界を変える夢を見るか
アジャイル開発は世界を変える夢を見るか
 
ナラティブ・プロトタイピング
ナラティブ・プロトタイピングナラティブ・プロトタイピング
ナラティブ・プロトタイピング
 
組織にアジャイルの構造を作る
組織にアジャイルの構造を作る組織にアジャイルの構造を作る
組織にアジャイルの構造を作る
 
組織でアジャイルの ”回転” を繋ぐ
 組織でアジャイルの ”回転” を繋ぐ 組織でアジャイルの ”回転” を繋ぐ
組織でアジャイルの ”回転” を繋ぐ
 
組織アジャイルをはじめる
組織アジャイルをはじめる組織アジャイルをはじめる
組織アジャイルをはじめる
 
デジタルトランスフォーメーション・ジャーニー・デッキ
デジタルトランスフォーメーション・ジャーニー・デッキデジタルトランスフォーメーション・ジャーニー・デッキ
デジタルトランスフォーメーション・ジャーニー・デッキ
 
Digitaltransformation Journey
Digitaltransformation JourneyDigitaltransformation Journey
Digitaltransformation Journey
 
Agile again
Agile againAgile again
Agile again
 
伝統的な組織で始めるアジャイル
伝統的な組織で始めるアジャイル伝統的な組織で始めるアジャイル
伝統的な組織で始めるアジャイル
 
アジャイルブリゲード 〜対立する二項を組織の構造と仕組みによって繋ぐ〜
アジャイルブリゲード 〜対立する二項を組織の構造と仕組みによって繋ぐ〜アジャイルブリゲード 〜対立する二項を組織の構造と仕組みによって繋ぐ〜
アジャイルブリゲード 〜対立する二項を組織の構造と仕組みによって繋ぐ〜
 
私がのこすだろうたった1つの言葉
私がのこすだろうたった1つの言葉私がのこすだろうたった1つの言葉
私がのこすだろうたった1つの言葉
 
13年かけたら、言えること
13年かけたら、言えること13年かけたら、言えること
13年かけたら、言えること
 
正しいものをともに考え、正しくともにつくる
正しいものをともに考え、正しくともにつくる正しいものをともに考え、正しくともにつくる
正しいものをともに考え、正しくともにつくる
 
チーム・ジャーニー・デッキ
チーム・ジャーニー・デッキチーム・ジャーニー・デッキ
チーム・ジャーニー・デッキ
 
自分のハンドルは自分で握れ
自分のハンドルは自分で握れ自分のハンドルは自分で握れ
自分のハンドルは自分で握れ
 
チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで
チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまでチーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで
チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで
 
ISHII SPRINT
ISHII SPRINTISHII SPRINT
ISHII SPRINT
 
ともに考え、ともにつくる 〜リーン・ジャーニー・スタイル〜
ともに考え、ともにつくる 〜リーン・ジャーニー・スタイル〜 ともに考え、ともにつくる 〜リーン・ジャーニー・スタイル〜
ともに考え、ともにつくる 〜リーン・ジャーニー・スタイル〜
 
正しいものを正しくつくるへ至る道
正しいものを正しくつくるへ至る道正しいものを正しくつくるへ至る道
正しいものを正しくつくるへ至る道
 
プロダクト開発を繋げる
プロダクト開発を繋げるプロダクト開発を繋げる
プロダクト開発を繋げる
 

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

  • 1. Toshihiro Ichitani All Rights Reserved. 4つの「戦犯」から考える サービスづくりの失敗 Ichitani Toshihiro 市⾕聡啓 世の中の理論と失敗体験から ⾃分だけの論を作り出そう
  • 2. Toshihiro Ichitani All Rights Reserved. http://about.me/papanda0806 Ichitani Toshihiro 市⾕聡啓 ソフトウェア開発16年 SIer→サービス→受託→起業 仮説検証とアジャイル開発 ギルドワークス株式会社 代表 株式会社 エナジャイル 代表 ⼀般社団法⼈ 越境アジャイルアライアンス代表理事 DevLOVE コミュニティ ファウンダ 0 → 1
  • 3. Toshihiro Ichitani All Rights Reserved.
  • 4. Toshihiro Ichitani All Rights Reserved. “アジャイル開発”の理解を深める 具体的な進め⽅を知る 仮説検証型アジャイル開発の考え⽅ 越境したい⽅へ失敗パターンで知る https://www.slideshare.net/papanda/
  • 5. Toshihiro Ichitani All Rights Reserved. まずは のべ200本以上(推定)の サービスづくりの中で、 よくある失敗パターン(体感) のおさらい https://www.slideshare.net/papanda/7-79699560 このお話では問題に対して 「ではどうする?」には触れません。 どうする話はこちらを→
  • 6. Toshihiro Ichitani All Rights Reserved. サービスづくりにおける、3つの「戦犯」 怠惰 短気 傲慢 本当は考慮しておくべきことなのに、やっていない。 仮説検証そのものをやっていない。 判断が早計すぎる。 「早く進める」が絶対的な価値基準になっている。 ⾃分の都合の良いように解釈して事を進めてしまう。 現実に⽬をむけようとしない。
  • 7. Toshihiro Ichitani All Rights Reserved. 事業を始めてしまう チャネル検証を やってない 体験の検証を やってない 検証結果を都合良く 解釈してしまう アテンションにあたる価値 がない 優位性と つながっていない 想像だけで 始めてしまう 7つの失敗パターン 怠惰 短気 傲慢
  • 8. Toshihiro Ichitani All Rights Reserved. 事業を始めてしまう チャネル検証を やってない 体験の検証を やってない 検証結果を都合良く 解釈してしまう アテンションにあたる価値 がない 優位性と つながっていない 想像だけで 始めてしまう 7つの失敗パターン 怠惰 短気 傲慢
  • 9. Toshihiro Ichitani All Rights Reserved. こういうサービスを必要とする ユーザーは必ずいる!
  • 10. Toshihiro Ichitani All Rights Reserved. こういうサービスを必要とする ユーザーは必ずいる! 想像だけで始めてしまう。 既にプロダクトをつくるという意思決定が 終わっているが、その根拠が特にない。 (担当のたぶんこうなんじゃないかという勘)
  • 11. Toshihiro Ichitani All Rights Reserved. よくあるケース 予算のムダ使いは取り返しがつくが、時間は取り返せない。 過ぎ去った時間は、環境の変化となって返ってくる。 環境の変化には、期待の劣化や倦怠感という⼈間の感情も 含まれる。(チームがダメになったら本当に何も残らない)
  • 12. Toshihiro Ichitani All Rights Reserved. 事業を始めてしまう チャネル検証を やってない 体験の検証を やってない 検証結果を都合良く 解釈してしまう アテンションにあたる価値 がない 優位性と つながっていない 想像だけで 始めてしまう 7つの失敗パターン 怠惰 短気 傲慢
  • 13. Toshihiro Ichitani All Rights Reserved. これでユーザーの問題は解決できる! (…でも、何かピリッとしない感じ?)
  • 14. Toshihiro Ichitani All Rights Reserved. アテンションにあたる価値がない。 想定ユーザー、顧客の課題を解決できる仕組みは 構想できたし、何なら検証の結果もまずまず。 しかし、検証では「ユーザーが⾶びつくほどの 感じ」ではない。本当にこれで良いのか? アテンション(=注⽬)にあたる価値が⽋けている かもしれない。 これでユーザーの問題は解決できる! (…でも、何かピリッとしない感じ?)
  • 15. Toshihiro Ichitani All Rights Reserved. 問題はなに? 「使ってもらえたら、(価値を感じてもらえる)」 という仮定。その仮定はたいてい成⽴しない。 「使ってもらえたら、」という仮定を満たすために 「チャネル」獲得にいくらリソースを投⼊しても できるのは「届ける」こと。 「届く」と「⽬を引く」は違う。 (届けるのは「チャネル」、⽬を引くのは「価値」) 「アテンションにあたる価値がない」
  • 16. Toshihiro Ichitani All Rights Reserved. ウーバー版◯◯をつくりたい。 (Uberのモデルに乗っかろう)
  • 17. Toshihiro Ichitani All Rights Reserved. ウーバー版◯◯をつくりたい。 (Uberのモデルに乗っかろう) 優位性とつながっていない。 モデルを転⽤するのは良いが、転⽤先の領域に 何かしら⾃社の競争優位性があるわけではない。 いくらでも思いついちゃって(◯◯の部分)、 ⼀つも前に進められない。
  • 18. Toshihiro Ichitani All Rights Reserved. 問題はなに? 「われわれはなぜここにいるのか?」他ならぬ ⾃分たちがこのテーマを取り組む理由は何か? に答えられない段階でも、意思決定してしまう。 結果、判断としては ・「優位性はつくりこむ」→ コスト度外視? ・「先⾏することが優位性」→ 先⾏≠参⼊障壁 になりがち。スタートはできても継続する⼒が不⾜。 「優位性とつながっていない。」
  • 19. Toshihiro Ichitani All Rights Reserved. 事業を始めてしまう チャネル検証を やってない 体験の検証を やってない 検証結果を都合良く 解釈してしまう アテンションにあたる価値 がない 優位性と つながっていない 想像だけで 始めてしまう 7つの失敗パターン 怠惰 短気 傲慢
  • 20. Toshihiro Ichitani All Rights Reserved. 課題の仮説も、ソリューションの仮説も 検証できた。あとは機能を開発!
  • 21. Toshihiro Ichitani All Rights Reserved. 課題の仮説も、ソリューションの仮説も 検証できた。あとは機能を開発! 体験の検証をやっていない インタビューやモックアップでの検証を通じて 仮説の構造を成り⽴たせるところまで来た。 ⾔葉や絵、イメージで想定ユーザーとの コミュケーションは取れているかもしれない。 でも、UserはまだはUseしていないけど⼤丈夫?
  • 22. Toshihiro Ichitani All Rights Reserved. 問題はなに? 想定ユーザーの利⽤体験を成り⽴たせることが 出来るのか、まったく検証しないままつくり はじめてしまう。 MVPの検証の⽬的が分かれるところ。 何のためにプロダクトをつくるのか? ① 体験の検証のために ② あくまで最初の市場投⼊のために → ②の場合「つくりすぎのムダ」になる可能性が⾼い。 「体験の検証をやっていない」
  • 23. Toshihiro Ichitani All Rights Reserved. 何の検証を⾏っているのか? そもそも仮説とは何か?仮説には3つの側⾯を捉えることができる。 「利⽤者の課題についての仮説」「サービスの機能についての仮説」 「ユーザーインターフェースについての仮説」なのか。 それぞれ、提供サービスの「本質」「実体」「形態」にあたる。 それぞれが検証の対象。 か かた かたち 本質 実体 形態 課題の仮説 機能の仮説 UIの仮説 どんな状況の⼈たちの、 どんな問題を解決するのか = 本質的な価値 本質的な価値が利⽤者に もたらされるために必要な 機能とは何か=機能性 利⽤者が機能を使えるために 適したUIとは何か = ユーザビリティ https://www.amazon.co.jp/dp/4395012086参考「代謝建築論―か・かた・かたち」
  • 24. Toshihiro Ichitani All Rights Reserved. どうやって、このサービスを ユーザーに届けるかって? 広告と、⼝コミさ。
  • 25. Toshihiro Ichitani All Rights Reserved. どうやって、このサービスを ユーザーに届けるかって? 広告と、⼝コミさ。 チャネルの検証をやっていない 開発がほぼ終わりを迎える頃に、チャネルの検討を 本格的に始める。 構想段階では「広告と⼝コミ」という置きの想定 しかない。結果、実現段階では「広告」頼み。 ユーザーにどうやって知ってもらうの戦いの開幕。
  • 26. Toshihiro Ichitani All Rights Reserved. 問題はなに? ユーザーにどうやって届けるかの算段が初期の 段階では、後回しになりがち。 後になって「届けるコスト」が現実的ではない ことに気付く。 そもそも、インタビューでの検証を⾏なう時に 「インタビュー相⼿が確保できない」という状況から 学びを得なければならない。インタビューもできないのに どうやってユーザーに届けるのか? 「チャネルの検証をやっていない」
  • 27. Toshihiro Ichitani All Rights Reserved. 事業を始めてしまう チャネル検証を やってない 体験の検証を やってない 検証結果を都合良く 解釈してしまう アテンションにあたる価値 がない 優位性と つながっていない 想像だけで 始めてしまう 7つの失敗パターン 怠惰 短気 傲慢
  • 28. Toshihiro Ichitani All Rights Reserved. 検証で結果が出た! Aさんのインタビュー結果はダメだった けど、この⼈はユーザーではない。
  • 29. Toshihiro Ichitani All Rights Reserved. 検証で結果が出た! Aさんのインタビュー結果はダメだった けど、この⼈はユーザーではない。 検証結果を都合良く解釈してしまう この⼈はユーザーではない、 10⼈中7⼈がOKだったから、OK この機能がまだ無かったから、ダメだっただけ… ⾃分の⾒⽅に偏り(バイアス)があることに、 ⽣まれていることに、気づけていない。
  • 30. Toshihiro Ichitani All Rights Reserved. 問題はなに? 都合の良い解釈で、誤った意思決定してしまう。 また、想定ユーザー側が事実を語っておらず、 解釈は正しいが、データが誤っている場合もある。 (定量的な数値判断が出来ない段階ではこの⼿の誤りが起きやすい) 集団で解釈しようとすると、安易な解釈と過度な同調が ⽣まれることも多い。 「ここまでやったんだから…」→ 批判したくない。 「検証結果を都合良く解釈してしまう」
  • 31. Toshihiro Ichitani All Rights Reserved. 事業を始めてしまう チャネル検証を やってない 体験の検証を やってない 検証結果を都合良く 解釈してしまう アテンションにあたる価値 がない 優位性と つながっていない 想像だけで 始めてしまう 7つの失敗パターン 怠惰 短気 傲慢
  • 32. Toshihiro Ichitani All Rights Reserved. MVPが完成した! さて、どうやって売ろうか。
  • 33. Toshihiro Ichitani All Rights Reserved. MVPが完成した! さて、どうやって売ろうか。 事業を始めてしまう 分かりやすい動くモノがまとまって得られると、 組織的な圧⼒、また関係者(当事者含む)の期待が ⾼まり「どうやって売るか、どのくらい売れるか」 の議論と活動が始まってしまう。
  • 34. Toshihiro Ichitani All Rights Reserved. 問題はなに? MVPで検証したいのはビジネスモデル。 事業を始めてしまうと、モデルの検証ではなく ビジネス⾃体が始まってしまう。 結果、「達成すべき収益計画」へのコミット圧が ⾼まり、体制が構築され、コストを抑える議論が 早期に始まり、検証が進まないまま、突き進んで しまう。(まさに顧客開発モデルの問題意識の再現) 「事業を始めてしまう」
  • 35. Toshihiro Ichitani All Rights Reserved. 事業を始めてしまう チャネル検証を やってない 体験の検証を やってない 検証結果を都合良く 解釈してしまう アテンションにあたる価値 がない 優位性と つながっていない 想像だけで 始めてしまう 7つの失敗パターン 怠惰 短気 傲慢
  • 36. Toshihiro Ichitani All Rights Reserved. 8つ⽬の失敗。 それは、「盲信」によるもの。
  • 37. Toshihiro Ichitani All Rights Reserved. まずはアーリーアダプターを 攻略しよう!マジョリティは後! 採⽤者数 時間 イノベーター アーリー アダプター アーリー マジョリティ レイト マジョリティ ラガート キャズム
  • 38. Toshihiro Ichitani All Rights Reserved. 本当に「世の中の理論」をあなたの事業に 適⽤して⼤丈夫か? 「世の中の理論」が根拠としている「事例」や「状況」は 本当に⾃分のプロダクトや状況にもあてはまるだろうか? ⾃分の⼿元の事業の判断に、Amaz◯nやAp◯leの意思 決定⼿法や基準を持ってきて本当に合うのか? アーリーアダプターを攻略した後に、マジョリティに 向かっていく作戦に勝算はつくれるのか? ユーザー体験を磨いて…ホールプロダクトに仕⽴てて… で、本当に届くのか?
  • 39. Toshihiro Ichitani All Rights Reserved. それって理論を捨てるってこと? (何を信じたらいいの…)
  • 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をつくって 検証を進める判断 プロダクトを 本格的に作って 検証を進める判断 検証は続くよ
  • 44. Toshihiro Ichitani All Rights Reserved. そんな早く追随者の検証して⼤丈夫? 追随者の意⾒に引きづられない?
  • 45. Toshihiro Ichitani All Rights Reserved. そんな早く追随者の検証して⼤丈夫? 追随者の意⾒に引きづられない? 遅かれ早かれ追随者に向き合うことになる だから、先駆者と追随者の識別が⼤事(先駆者と追随者 向けでキャンバスを分ける)。 初期の段階では、誰が先駆者で誰が追随者なんて、仮説 でしかない。後から、気付く。ただし判断を誤らない よう、「早く」気付くために、検証を「素早く」繰り返す。
  • 46. Toshihiro Ichitani All Rights Reserved. 盲信 怠惰 短気 傲慢 事業を始めてしまう チャネル検証を やってない 体験の検証を やってない 検証結果を都合良く 解釈してしまう アテンションにあたる価値 がない 優位性と つながっていない 想像だけで 始めてしまう 4つの戦犯、8つの失敗パターン 世の中の 理論を 鵜呑みに する
  • 47. Toshihiro Ichitani All Rights Reserved. 他⼈の話は、あくまでその⼈の旅のお話。 あなたの旅に適しているかは、⾃分で判断しなければならない。 そう、もちろん、この話だって。
  • 48. Toshihiro Ichitani All Rights Reserved. 良い検証を。