Regional Scrum Gathering Tokyo 2018 セッション「Panel - 実感駆動でものづくり ー 協調学習過程としてのスクラム。欲しいものを、どうやって知るか。」にて使用したスライドです。（補足情報を追記しております） https://confengine.com/regional-scrum-gathering-tokyo-2018/proposal/5132/panel-

1. カネとAgile
黒田 樹 @i2key
Regional Scrum Gathering® Tokyo 2018

2. カネの話
アジリティを下げる心理バイアス
「儲け」ではなく「燃料」としての

3. エンタープライズの場合、年次の予算計画があり、
ベースとなるサイクルタイムは年になる。
1年先の未来の状況を事前に予想して計画しないとならない。
そして、それを1年後まで大幅に変更することはない。
計画の実行に固執すると「発見」による変更がきかなくなる
新規事業なのに計画駆動になるバイアス
より多くの予算を確保するために多大な労力をかけて
最高のビジネスプランを計画（予想ｗw）することになる
また、

4. 「発見」による軌道修正が難しい
ゴール3
ゴール4
ゴール5
真のゴール
真のゴール
1年
1年
都度握るゴール1
都度握るゴール2
不確実な情報をもとに
出資者と握ってしまった
現実
理想
資金を溶かしたあとに出資者に「やっぱ目標違いました。」って言えるハートがあれば大丈夫。
でも、みんなそんなにハートは強くない。投資に対するリターンの説明責任の話。
デカイ目標

5. 「発見」による軌道修正が難しい
デカイ目標
ゴール3
ゴール4
ゴール5
真のゴール
真のゴール
1年
1年
都度握るゴール1
都度握るゴール2
不確実な情報をもとに
出資者と握ってしまった
現実
理想
資金を溶かしたあとに出資者に「やっぱ目標違いました。」って言えるハートがあれば大丈夫。
でも、みんなそんなにハートは強くない。投資に対するリターンの説明責任の話。
要件定義
開発
リリース
集客
ここらへんで、
ターゲット選定の間違い
や、課題設定のミスに
組織として気づく現場のエンジニアとかか
が、この機能本当にいる
のかなと思いながら開発
が行われる。
理屈ではこっちのが良いのに、そう出来ない心理バイアスが働いているのは何故だろう？
握ってしまった大きな数字を
作りに行くための、利用者の
ことを向いていない要件定義。

6. カネのリズムが開発のリズムを作っている
カネのリズム：投資タイミング
サイクルタイム：投資に対するリターンまで
この状況で、仮に表面上アジャイルにうまく回ってても、
ボトルネックを解消し続けていくと、このリズムの問題にぶち当たる。
そして、カネに対する説明責任を果たしている人がかならずいます。
プロダクトオーナーなのかもしれないし、上司なのかもしれない。
構造上の課題から、結果的にどんな心理バイアスを発生させ、
組織上のどういう意思決定の力学を発生させているかを考える必要がある。

7. 目標
ゴール3
ゴール4
ゴール5
真のゴール
真のゴール
1年
1年
都度握るゴール1
都度握るゴール2
不確実な情報をもとに
出資者と握ってしまった
計画駆動にしたくなる心理バイアスが働く。
説明責任単位が大きすぎる資金調達をすると
開発プロセス上、現場がアジャイルを選択しても
カネと説明責任のレイヤーからアジャイルにする必要がある
¥
資金調達
¥
資金調達
¥
資金調達
¥
資金調達
¥
資金調達
¥
資金調達
¥
資金調達
理想
リターン
初年度売上XXX
（実際は未達）
課題実証
解決策実証
解決策
別案実証
ビジネス
モデル実証
集客手段
実証

8. 目標
ゴール3
ゴール4
ゴール5
真のゴール
真のゴール
1年
1年
都度握るゴール1
都度握るゴール2
不確実な情報をもとに
出資者と握ってしまった
¥
資金調達
¥
資金調達
¥
資金調達
¥
資金調達
¥
資金調達
¥
資金調達
¥
資金調達
理想
リターン
初年度売上XXX
（実際は未達）
課題実証
解決策実証
解決策
別案実証
ビジネス
モデル実証
集客手段
実証
サイクルタイム 1年
資金調達とリターンのバッチサイズを小さくする
資金調達とリターンのバッチサイズが大きい

9. 資金調達タイミング
例：追う指標（説明責任単位）が変化するとき

10. 顧客発見
【ニーズ検証】
顧客実証
【売って検証】
組織構築
【本格拡大】
Problem/Solution
Fit
Product/Market
Fit Scaling
Retention CAC < LTV 売上
課題解決可能
な最小限
売り方最適化 / 売上最大化売る
指標値例
検証アク
ション
検証
ポイント
MVP
目標
MVP作って壊す
最低限の
売れる状態
セグメントに応じて売れる状態
検証が既存ユーザに影響与えない
独自な価値提供を出来ているか
深い課題を抱えた顧客がいるか
その課題の解決策は妥当か
独自な価値提供を出来ているか
顧客は本当に買ってくれるか
コスト構造に無理がないか
顧客開拓
【リーチ検証】
独自な価値提供を出来ているか
最適な売り方の検証
最適な価格設定の検証
導入期 成長期 成熟期
利益
独自な価値提供を出来ているか
CPA最適化
マーケットシェア
キードライバー値
最大化
利益最大化
ビジネス
フェーズ
AARRR
①ビジネス
仮説
①② ③
⑤
① ①② ③
④
⑥ ⑤
① ①② ③
④
⑥
⑦⑦
⑦⑦
⑦
仮説検証
実行

11. 顧客の
実証
課題の
実証
解決策の
実証 価値の
実証
チャネルの
実証コスト構造
売上構造
売上ではなく、継続率
（顧客獲得コスト）（生涯売上）

13. 資金調達条件
顧客発見
【ニーズ検証】
顧客実証
【売って検証】
組織構築
【本格拡大】
Problem/Solution
Fit
Product/Market
Fit Scaling
Retention CAC < LTV 売上
課題解決可能
な最小限
売り方最適化 / 売上最大化売る
指標値例
検証アク
ション
検証
ポイント
MVP
目標
MVP作って壊す
最低限の
売れる状態
セグメントに応じて売れる状態
検証が既存ユーザに影響与えない
独自な価値提供を出来ているか
深い課題を抱えた顧客がいるか
その課題の解決策は妥当か
独自な価値提供を出来ているか
顧客は本当に買ってくれるか
コスト構造に無理がないか
顧客開拓
【リーチ検証】
独自な価値提供を出来ているか
最適な売り方の検証
最適な価格設定の検証
導入期 成長期 成熟期
利益
独自な価値提供を出来ているか
CPA最適化
マーケットシェア
キードライバー値
最大化
利益最大化
ビジネス
フェーズ
AARRR
①ビジネス
仮説
①② ③
⑤
① ①② ③
④
⑥ ⑤
① ①② ③
④
⑥
⑦⑦
⑦⑦
⑦
仮説検証
実行 ¥
資金調達
¥
資金調達
¥
資金調達
¥
資金調達

14. 事例

15. 計量資金調達(Metered Funding)
機会の証明 課題定義、
市場サイズの実証
バリュープロポジション
テスト済み
ビジネスモデル構築済
MVPテスト済
キー仮説実証済
スケーリング
フルマーケットローンチ
プロモーション
引用：THE STARTUP WAY エリック・リース
http://i2key.hateblo.jp/entry/2017/12/03/114938

16. RECRUIT VENTURES
ステージゲート方式による事業開発

17. スクラムチームプロダクトオーナー
PBL
Sprint/2weeks
開発タスク/Day
ビジネス
仮説リスト
構築
計測
学習
IDEA
DATA
計画
リリース
振り返り
Daily
MTG
REVIEW
解決策の
実証
1Sprint = 200万ギル
1ヶ月100万ギルのエンジニア4人
0
250
500
750
1000
#1 #2 #3 #4 #5 #6
1000万ギル調達
Sprint#6までの
5回の実験で成果を出す
= ムダなことやってらんない

18. Appendix
ムダなMVPを作らないための仮説検証設計

19. いきなり時計回しで始めるとムダを含むMVPを作りがち
仮説検証の精度を上げる（ムダなMVPを作らない）
どんなMVP作ればいいの？
仮説はある！
オーバースペックMVP
作りすぎのムダ

20. いきなり時計回しで始めるとムダを含むMVPを作りがち
仮説検証の精度を上げる（ムダなMVPを作らない）
どう測ればいいんだっけ？
そもそも測れるのだっけ？
この手元にあるデータで
実証できたといえるんだっけ？
仮説はある！
これだめだ、
測り直しだ
再学習のムダ

21. 手戻りのムダや作り過ぎのムダを減らすために、
ニーズに対しMVP（必要最小限の価値のあるもの）をつくる
→ニーズからプルする
情報の流れ
モノの流れ
ニーズ
when
what
amount
when
what
amount
when
what
amount
when
what
amount
pullpullpull
push push push
仮説検証の精度を上げる（ムダなMVPを作らない）

22. ①仮説
②何を学ぶのか
③必要なデータは？
④どうやって計測する？
⑤必要なものは？
⑥どう構築するか？
思考プロセス
（情報の流れ）
pull
pull
pull pull
pull
仮説検証の精度を上げる（ムダなMVPを作らない）

23. ⑫仮説を実証
⑪学ぶ
⑩データを元に検証
⑨計測する
⑧完成したMVP
⑦構築する
実証プロセス
(モノの流れ)
push
pushpush
push
push
仮説検証の精度を上げる（ムダなMVPを作らない）

24. 情報の流れ（BMLを逆流）
モノの流れ（BMLの流れ）
ニーズ
pullpullpull
①仮説②何を学ぶのか
③必要なデータ
④計測方法
⑤必要な計量器
⑥構築方法
⑫実証
⑪学ぶ
⑩データで検証
⑨計測する
⑧完成したMVP⑦構築する
push push push
BUILD MEASURE LEARN
BUILD設計 MEASURE設計 LEARN設計
①
②
③
④
⑤
⑥
⑫
⑪
⑩
⑨
⑧
⑦
仮説検証の精度を上げる（ムダなMVPを作らない）

25. 仮説検証の精度を上げる（ムダなMVPを作らない）
仮説検証を設計する

26. 仮説
何を学ぶのか
MVP種類
・紙ペラ
・インタビュー
・動くデモ
・etc
学ぶために何を作るかの詳細
実証に
必要な条件
MVP構築
コスト
仮説実証
にかかる
時間
将来のリ
スク/機会
結果、実際の学び
仮説検証の精度を上げる（ムダなMVPを作らない）
仮説検証を設計する

27. あとはここらへんを
https://www.slideshare.net/i2key/
leanstartup-83991125
https://www.slideshare.net/i2key/xpjug