カネとAgile #RSGT2018

カネとAgile #RSGT2018

1. 1. カネとAgile 黒田　樹 @i2key Regional Scrum Gathering® Tokyo 2018
2. 2. カネの話 アジリティを下げる心理バイアス 「儲け」ではなく「燃料」としての
3. 3. エンタープライズの場合、年次の予算計画があり、 ベースとなるサイクルタイムは年になる。 1年先の未来の状況を事前に予想して計画しないとならない。 そして、それを1年後まで大幅に変更することはない。 計画の実行に固執すると「発見」による変更がきかなくなる 新規事業なのに計画駆動になるバイアス より多くの予算を確保するために多大な労力をかけて 最高のビジネスプランを計画（予想ｗw）することになる また、
4. 4. 「発見」による軌道修正が難しい ゴール3 ゴール4 ゴール5 真のゴール 真のゴール 1年 1年 都度握るゴール1 都度握るゴール2 不確実な情報をもとに 出資者と握ってしまった 現実 理想 資金を溶かしたあとに出資者に「やっぱ目標違いました。」って言えるハートがあれば大丈夫。 でも、みんなそんなにハートは強くない。投資に対するリターンの説明責任の話。 デカイ目標
5. 5. 「発見」による軌道修正が難しい デカイ目標 ゴール3 ゴール4 ゴール5 真のゴール 真のゴール 1年 1年 都度握るゴール1 都度握るゴール2 不確実な情報をもとに 出資者と握ってしまった 現実 理想 資金を溶かしたあとに出資者に「やっぱ目標違いました。」って言えるハートがあれば大丈夫。 でも、みんなそんなにハートは強くない。投資に対するリターンの説明責任の話。 要件定義 開発 リリース 集客 ここらへんで、 ターゲット選定の間違い や、課題設定のミスに 組織として気づく現場のエンジニアとかか が、この機能本当にいる のかなと思いながら開発 が行われる。 理屈ではこっちのが良いのに、そう出来ない心理バイアスが働いているのは何故だろう？ 握ってしまった大きな数字を 作りに行くための、利用者の ことを向いていない要件定義。
6. 6. カネのリズムが開発のリズムを作っている カネのリズム：投資タイミング サイクルタイム：投資に対するリターンまで この状況で、仮に表面上アジャイルにうまく回ってても、 ボトルネックを解消し続けていくと、このリズムの問題にぶち当たる。 そして、カネに対する説明責任を果たしている人がかならずいます。 プロダクトオーナーなのかもしれないし、上司なのかもしれない。 構造上の課題から、結果的にどんな心理バイアスを発生させ、 組織上のどういう意思決定の力学を発生させているかを考える必要がある。
7. 7. 目標 ゴール3 ゴール4 ゴール5 真のゴール 真のゴール 1年 1年 都度握るゴール1 都度握るゴール2 不確実な情報をもとに 出資者と握ってしまった 計画駆動にしたくなる心理バイアスが働く。 説明責任単位が大きすぎる資金調達をすると 開発プロセス上、現場がアジャイルを選択しても カネと説明責任のレイヤーからアジャイルにする必要がある ¥ 資金調達 ¥ 資金調達 ¥ 資金調達 ¥ 資金調達 ¥ 資金調達 ¥ 資金調達 ¥ 資金調達 理想 リターン 初年度売上XXX （実際は未達） 課題実証 解決策実証 解決策 別案実証 ビジネス モデル実証 集客手段 実証
8. 8. 目標 ゴール3 ゴール4 ゴール5 真のゴール 真のゴール 1年 1年 都度握るゴール1 都度握るゴール2 不確実な情報をもとに 出資者と握ってしまった ¥ 資金調達 ¥ 資金調達 ¥ 資金調達 ¥ 資金調達 ¥ 資金調達 ¥ 資金調達 ¥ 資金調達 理想 リターン 初年度売上XXX （実際は未達） 課題実証 解決策実証 解決策 別案実証 ビジネス モデル実証 集客手段 実証 サイクルタイム 1年 資金調達とリターンのバッチサイズを小さくする 資金調達とリターンのバッチサイズが大きい
9. 9. 資金調達タイミング 例：追う指標（説明責任単位）が変化するとき
10. 10. 顧客発見 【ニーズ検証】 顧客実証 【売って検証】 組織構築 【本格拡大】 Problem/Solution Fit Product/Market Fit Scaling Retention CAC < LTV 売上 課題解決可能 な最小限 売り方最適化 / 売上最大化売る 指標値例 検証アク ション 検証 ポイント MVP 目標 MVP作って壊す 最低限の 売れる状態 セグメントに応じて売れる状態 検証が既存ユーザに影響与えない 独自な価値提供を出来ているか 深い課題を抱えた顧客がいるか その課題の解決策は妥当か 独自な価値提供を出来ているか 顧客は本当に買ってくれるか コスト構造に無理がないか 顧客開拓 【リーチ検証】 独自な価値提供を出来ているか 最適な売り方の検証 最適な価格設定の検証 導入期 成長期 成熟期 利益 独自な価値提供を出来ているか CPA最適化 マーケットシェア キードライバー値 最大化 利益最大化 ビジネス フェーズ AARRR ①ビジネス 仮説 ①② ③ ⑤ ① ①② ③ ④ ⑥ ⑤ ① ①② ③ ④ ⑥ ⑦⑦ ⑦⑦ ⑦ 仮説検証 実行
11. 11. 顧客の 実証 課題の 実証 解決策の 実証 価値の 実証 チャネルの 実証コスト構造 売上構造 売上ではなく、継続率 （顧客獲得コスト）（生涯売上）
12. 12. 資金調達条件 顧客発見 【ニーズ検証】 顧客実証 【売って検証】 組織構築 【本格拡大】 Problem/Solution Fit Product/Market Fit Scaling Retention CAC < LTV 売上 課題解決可能 な最小限 売り方最適化 / 売上最大化売る 指標値例 検証アク ション 検証 ポイント MVP 目標 MVP作って壊す 最低限の 売れる状態 セグメントに応じて売れる状態 検証が既存ユーザに影響与えない 独自な価値提供を出来ているか 深い課題を抱えた顧客がいるか その課題の解決策は妥当か 独自な価値提供を出来ているか 顧客は本当に買ってくれるか コスト構造に無理がないか 顧客開拓 【リーチ検証】 独自な価値提供を出来ているか 最適な売り方の検証 最適な価格設定の検証 導入期 成長期 成熟期 利益 独自な価値提供を出来ているか CPA最適化 マーケットシェア キードライバー値 最大化 利益最大化 ビジネス フェーズ AARRR ①ビジネス 仮説 ①② ③ ⑤ ① ①② ③ ④ ⑥ ⑤ ① ①② ③ ④ ⑥ ⑦⑦ ⑦⑦ ⑦ 仮説検証 実行 ¥ 資金調達 ¥ 資金調達 ¥ 資金調達 ¥ 資金調達
13. 13. 事例
14. 14. 計量資金調達(Metered Funding) 機会の証明 課題定義、 市場サイズの実証 バリュープロポジション テスト済み ビジネスモデル構築済 MVPテスト済 キー仮説実証済 スケーリング フルマーケットローンチ プロモーション 引用：THE STARTUP WAY エリック・リース http://i2key.hateblo.jp/entry/2017/12/03/114938
15. 15. RECRUIT VENTURES ステージゲート方式による事業開発
16. 16. スクラムチームプロダクトオーナー 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回の実験で成果を出す = ムダなことやってらんない
17. 17. Appendix ムダなMVPを作らないための仮説検証設計
18. 18. いきなり時計回しで始めるとムダを含むMVPを作りがち 仮説検証の精度を上げる（ムダなMVPを作らない） どんなMVP作ればいいの？ 仮説はある！ オーバースペックMVP 作りすぎのムダ
19. 19. いきなり時計回しで始めるとムダを含むMVPを作りがち 仮説検証の精度を上げる（ムダなMVPを作らない） どう測ればいいんだっけ？ そもそも測れるのだっけ？ この手元にあるデータで 実証できたといえるんだっけ？ 仮説はある！ これだめだ、 測り直しだ 再学習のムダ
20. 20. 手戻りのムダや作り過ぎのムダを減らすために、 ニーズに対しMVP（必要最小限の価値のあるもの）をつくる →ニーズからプルする 情報の流れ モノの流れ ニーズ when what amount when what amount when what amount when what amount pullpullpull push push push 仮説検証の精度を上げる（ムダなMVPを作らない）
21. 21. ①仮説 ②何を学ぶのか ③必要なデータは？ ④どうやって計測する？ ⑤必要なものは？ ⑥どう構築するか？ 思考プロセス （情報の流れ） pull pull pull pull pull 仮説検証の精度を上げる（ムダなMVPを作らない）
22. 22. ⑫仮説を実証 ⑪学ぶ ⑩データを元に検証 ⑨計測する ⑧完成したMVP ⑦構築する 実証プロセス (モノの流れ) push pushpush push push 仮説検証の精度を上げる（ムダなMVPを作らない）
23. 23. 情報の流れ（BMLを逆流） モノの流れ（BMLの流れ） ニーズ pullpullpull ①仮説②何を学ぶのか ③必要なデータ ④計測方法 ⑤必要な計量器 ⑥構築方法 ⑫実証 ⑪学ぶ ⑩データで検証 ⑨計測する ⑧完成したMVP⑦構築する push push push BUILD MEASURE LEARN BUILD設計 MEASURE設計 LEARN設計 ① ② ③ ④ ⑤ ⑥ ⑫ ⑪ ⑩ ⑨ ⑧ ⑦ 仮説検証の精度を上げる（ムダなMVPを作らない）
24. 24. 仮説検証の精度を上げる（ムダなMVPを作らない） 仮説検証を設計する
25. 25. 仮説 何を学ぶのか MVP種類 ・紙ペラ ・インタビュー ・動くデモ ・etc 学ぶために何を作るかの詳細 実証に 必要な条件 MVP構築 コスト 仮説実証 にかかる 時間 将来のリ スク/機会 結果、実際の学び 仮説検証の精度を上げる（ムダなMVPを作らない） 仮説検証を設計する
26. 26. あとはここらへんを https://www.slideshare.net/i2key/ leanstartup-83991125 https://www.slideshare.net/i2key/xpjug