カネとAgile

黒田　樹 @i2key

Regional Scrum Gathering® Tokyo 2018

カネの話 アジリティを下げる心理バイアス

「儲け」ではなく「燃料」としての

エンタープライズの場合、年次の予算計画があり、 ベースとなるサイクルタイムは年になる。 1年先の未来の状況を事前に予想して計画しないとならない。 そして、それを1年後まで大幅に変更することはない。 計画の実行に固執すると「発見」による変更がきかなくなる

新規事業なのに計画駆動になるバイアス

より多くの予算を確保するために多大な労力をかけて 最高のビジネスプランを計画（予想ｗw）することになる

また、

「発見」による軌道修正が難しい

ゴール3

ゴール4

ゴール5

真のゴール

真のゴール

1年

1年

都度握るゴール1

都度握るゴール2

不確実な情報をもとに 出資者と握ってしまった

現実

理想

資金を溶かしたあとに出資者に「やっぱ目標違いました。」って言えるハートがあれば大丈夫。でも、みんなそんなにハートは強くない。投資に対するリターンの説明責任の話。

デカイ目標

「発見」による軌道修正が難しい

デカイ目標

ゴール3

ゴール4

ゴール5

真のゴール

真のゴール

1年

1年

都度握るゴール1

都度握るゴール2

不確実な情報をもとに 出資者と握ってしまった

現実

理想

資金を溶かしたあとに出資者に「やっぱ目標違いました。」って言えるハートがあれば大丈夫。でも、みんなそんなにハートは強くない。投資に対するリターンの説明責任の話。

要件定義開発

リリース集客

ここらへんで、 ターゲット選定の間違いや、課題設定のミスに

組織として気づく現場のエンジニアとかかが、この機能本当にいるのかなと思いながら開発

が行われる。

理屈ではこっちのが良いのに、そう出来ない心理バイアスが働いているのは何故だろう？

握ってしまった大きな数字を作りに行くための、利用者のことを向いていない要件定義。

カネのリズムが開発のリズムを作っているカネのリズム：投資タイミング サイクルタイム：投資に対するリターンまで

この状況で、仮に表面上アジャイルにうまく回ってても、 ボトルネックを解消し続けていくと、このリズムの問題にぶち当たる。

そして、カネに対する説明責任を果たしている人がかならずいます。 プロダクトオーナーなのかもしれないし、上司なのかもしれない。

構造上の課題から、結果的にどんな心理バイアスを発生させ、 組織上のどういう意思決定の力学を発生させているかを考える必要がある。

目標

ゴール3

ゴール4

ゴール5

真のゴール

真のゴール

1年

1年

都度握るゴール1

都度握るゴール2

不確実な情報をもとに 出資者と握ってしまった

計画駆動にしたくなる心理バイアスが働く。説明責任単位が大きすぎる資金調達をすると開発プロセス上、現場がアジャイルを選択しても

カネと説明責任のレイヤーからアジャイルにする必要がある

¥資金調達

¥資金調達

¥資金調達

¥資金調達

¥資金調達

¥資金調達

¥資金調達

理想

リターン初年度売上XXX （実際は未達）

課題実証

解決策実証

解決策 別案実証

ビジネス モデル実証

集客手段 実証

目標

ゴール3

ゴール4

ゴール5

真のゴール

真のゴール

1年

1年

都度握るゴール1

都度握るゴール2

不確実な情報をもとに 出資者と握ってしまった

¥資金調達

¥資金調達

¥資金調達

¥資金調達

¥資金調達

¥資金調達

¥資金調達

理想

リターン初年度売上XXX （実際は未達）

課題実証

解決策実証

解決策 別案実証

ビジネス モデル実証

集客手段 実証

サイクルタイム 1年

資金調達とリターンのバッチサイズを小さくする

資金調達とリターンのバッチサイズが大きい

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

顧客発見 【ニーズ検証】

顧客実証 【売って検証】

組織構築 【本格拡大】

Problem/Solution Fit

Product/Market Fit Scaling

Retention CAC < LTV 売上

課題解決可能 な最小限

売り方最適化 / 売上最大化売る

指標値例

検証アク ション

検証 ポイント

MVP 目標

MVP作って壊す最低限の

売れる状態セグメントに応じて売れる状態

検証が既存ユーザに影響与えない

独自な価値提供を出来ているか 深い課題を抱えた顧客がいるか その課題の解決策は妥当か

独自な価値提供を出来ているか 顧客は本当に買ってくれるか コスト構造に無理がないか

顧客開拓 【リーチ検証】独自な価値提供を出来ているか 最適な売り方の検証 最適な価格設定の検証

導入期 成長期 成熟期

利益

独自な価値提供を出来ているか CPA最適化 マーケットシェア

キードライバー値 最大化

利益最大化

ビジネス フェーズ

AARRR

①ビジネス 仮説

①② ③

⑤

① ①② ③④⑥ ⑤

① ①② ③ ④

⑥⑦⑦⑦⑦

⑦

仮説検証 実行

顧客の 実証

課題の 実証

解決策の 実証 価値の

実証チャネルの

実証コスト構造売上構造

売上ではなく、継続率

（顧客獲得コスト）（生涯売上）

資金調達条件

顧客発見 【ニーズ検証】

顧客実証 【売って検証】

組織構築 【本格拡大】

Problem/Solution Fit

Product/Market Fit Scaling

Retention CAC < LTV 売上

課題解決可能 な最小限

売り方最適化 / 売上最大化売る

指標値例

検証アク ション

検証 ポイント

MVP 目標

MVP作って壊す最低限の

売れる状態セグメントに応じて売れる状態

検証が既存ユーザに影響与えない

独自な価値提供を出来ているか 深い課題を抱えた顧客がいるか その課題の解決策は妥当か

独自な価値提供を出来ているか 顧客は本当に買ってくれるか コスト構造に無理がないか

顧客開拓 【リーチ検証】独自な価値提供を出来ているか 最適な売り方の検証 最適な価格設定の検証

導入期 成長期 成熟期

利益

独自な価値提供を出来ているか CPA最適化 マーケットシェア

キードライバー値 最大化

利益最大化

ビジネス フェーズ

AARRR

①ビジネス 仮説

①② ③

⑤

① ①② ③④⑥ ⑤

① ①② ③ ④

⑥⑦⑦⑦⑦

⑦

仮説検証 実行 ¥

資金調達¥

資金調達¥

資金調達¥

資金調達

事例

計量資金調達(Metered Funding)

機会の証明 課題定義、 市場サイズの実証

バリュープロポジション テスト済み

ビジネスモデル構築済MVPテスト済 キー仮説実証済 スケーリング

フルマーケットローンチ プロモーション

引用：THE STARTUP WAY エリック・リース

http://i2key.hateblo.jp/entry/2017/12/03/114938

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

スクラムチームプロダクトオーナー

PBLSprint/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回の実験で成果を出す

= ムダなことやってらんない

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

いきなり時計回しで始めるとムダを含むMVPを作りがち仮説検証の精度を上げる（ムダなMVPを作らない）

どんなMVP作ればいいの？

仮説はある！

オーバースペックMVP

作りすぎのムダ

いきなり時計回しで始めるとムダを含むMVPを作りがち仮説検証の精度を上げる（ムダなMVPを作らない）

どう測ればいいんだっけ？ そもそも測れるのだっけ？

この手元にあるデータで 実証できたといえるんだっけ？

仮説はある！これだめだ、 測り直しだ

再学習のムダ

手戻りのムダや作り過ぎのムダを減らすために、 ニーズに対しMVP（必要最小限の価値のあるもの）をつくる →ニーズからプルする

情報の流れ

モノの流れ

ニーズwhenwhat

amount

whenwhat

amount

whenwhat

amount

whenwhat

amount

pullpullpull

push push push

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

①仮説

②何を学ぶのか

③必要なデータは？

④どうやって計測する？

⑤必要なものは？

⑥どう構築するか？

思考プロセス （情報の流れ）

pull

pull

pull pull

pull

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

⑫仮説を実証

⑪学ぶ

⑩データを元に検証

⑨計測する

⑧完成したMVP

⑦構築する

実証プロセス (モノの流れ) push

pushpush

push

push

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

情報の流れ（BMLを逆流）

モノの流れ（BMLの流れ）

ニーズpullpullpull

①仮説②何を学ぶのか③必要なデータ

④計測方法⑤必要な計量器

⑥構築方法

⑫実証⑪学ぶ

⑩データで検証⑨計測する

⑧完成したMVP⑦構築するpush push push

BUILD MEASURE LEARN

BUILD設計 MEASURE設計 LEARN設計

①②③ ④ ⑤

⑥

⑫⑪⑩ ⑨ ⑧

⑦

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

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

仮説検証を設計する

仮説何を学ぶのか

MVP種類 ・紙ペラ ・インタビュー ・動くデモ ・etc

学ぶために何を作るかの詳細

実証に 必要な条件

MVP構築 コスト

仮説実証 にかかる時間

将来のリスク/機会

結果、実際の学び

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

仮説検証を設計する

あとはここらへんを

https://www.slideshare.net/i2key/leanstartup-83991125

https://www.slideshare.net/i2key/xpjug