leanstartupをリーンにヤル #リーンスタートアップ

LEAN STARTUPをリーンにヤル黒田　樹 @i2key

フロー効率性を意識した仮説検証

リクルートテクノロジーズ

顧客発見【ニーズ検証】

顧客実証【売って検証】

組織構築【本格拡大】

Problem/Solution Fit

Product/Market Fit Scaling

Retention CAC < LTV 売上

課題解決可能な最小限

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

指標値例

検証アクション

検証ポイント

MVP 目標

MVP作って壊す最低限の

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

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

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

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

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

導入期成長期成熟期

利益

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

キードライバー値最大化

利益最大化

ビジネスフェーズ

AARRR

①ビジネス仮説

①② ③

⑤

① ①② ③④⑥ ⑤

① ①② ③ ④

⑥⑦⑦⑦⑦

⑦

仮説検証実行









指標値例


検証ポイント

MVP 目標








利益



利益最大化


AARRR


①② ③

⑤

① ①② ③④⑥ ⑤

① ①② ③ ④

⑥⑦⑦⑦⑦

⑦

仮説検証実行ここを効率よくすすめる話

稼働率が100%？

効率が良いとは

速く作業が出来ること？

効率が良いとは

「リソース効率性」が良い（例）稼働率100%、リソースに遊びが無い

「フロー効率性」が良い（例）機能リリースまでのリードタイムの短さ

リソース効率性とフロー効率性

A A A A A A A A A A A A A A A

B

C

B

C

B

C

B

C

B

C

B

C

B

C

B

C

B

C

B

C

B

C

B

C

B

C

B

C

B

C

A A A A A

A A A A A

A A A A A

B B B B

B B B B

B B B B

C C C

C C C

C C C

月　火　水　木　金月　火　水　木　金月　火　水　木　金

月　火　水　木　金月　火　水　木　金月　火　水　木　金リリースまでのリードタイム 1w

リリースまでのリードタイム約2w

リリースまでのリードタイム 3wリリースまでのリードタイム 3w

リリースまでのリードタイム 3w

A機能、B機能、C機能の実装それぞれ15人日かかる場合

A

A

A

B B

B B

B B

10



B

C

B

C

B

C

B

C

B

C

B

C

B

C

B

C

B

C

B

C

B

C

B

C

B

C

B

C

B

C

A A A A A

A A A A A

A A A A A

B B B B

B B B B

B B B B

C C C

C C C

C C C







A

A

A

B B

B B

B B

10



リソース効率性


B

C

B

C

B

C

B

C

B

C

B

C

B

C

B

C

B

C

B

C

B

C

B

C

B

C

B

C

B

C




複数のことを同時にやるとプロダクトがユーザに届くまで・検証を開始するまでのリードタイムが長くなる。ただし、皆に仕事が割り振られるため、また時間の余る限り複数の仕事を持つためリソースあたりの稼働率は高くなる。

1つのリソースを稼働率が100%になるまで分配する例・マルチタスク・大きなウォーターフォール型開発（SOR的）

A B C

Resource

流れる対象

30% 30% 40%

リソース稼働率：100% (作業時間を絞り出す量を最大化)

1リソースにフォーカスする

流れる対象流れる対象

リソース効率性

フロー効率性

A A A A A

A A A A A

A A A A A

B B B B

B B B B

B B B B

C C C

C C C

C C C




A

A

A

B B

B B

B B

同時にやることをひとつにするとプロダクトがユーザに届くまでのリードタイムは短くなる。しかし、全員が同じことをやるため、一時的に手持ちがなくなる人が出たりするためリソースの稼働率は下がる。（総生産量は期間のとり方によっては下がる）

A

Resource

流れる対象

流れる対象（タスク）が得られるリソースの時間を最大化する

流れる対象にフォーカスする

Resource Resource

例・ペアプログラミング/モブプログラミング・クロスファンクショナルチーム（SOE的）・システム障害発生時の動き

フロー効率性



B

C

B

C

B

C

B

C

B

C

B

C

B

C

B

C

B

C

B

C

B

C

B

C

B

C

B

C

B

C

A A A A A

A A A A A

A A A A A

B B B B

B B B B

B B B B

C C C

C C C

C C C







A

A

A

B B

B B

B B

10



B

C

B

C

B

C

B

C

B

C

B

C

B

C

B

C

B

C

B

C

B

C

B

C

B

C

B

C

B

C

A A A A A

A A A A A

A A A A A

B B B B B

B B B B B

B B B B B

C C C C C

C C C C C

C C C C C










10

リソース効率とフロー効率の関係

10

リソース効率とフロー効率はトレードオフの関係になりやすい

大規模開発のような大量のものを一括でドン！とリリースする文脈（リソース効率が支配するパラダイム）

ペアプログラミングしたいです！（効果：フロー効率アップ）

2人で同じことやったら、効率半分に落ちるだろ！却下！（効果：リソース効率ダウン）エンジニア氏

偉い人氏 10

リソース効率とフロー効率はトレードオフの関係になりやすい仮説検証型でUI/UX改善を回し、KPIを伸ばしにいく文脈。現場は学びまでのリードタイムを限りなく最小化したい。（無意識にフロー効率を重視している）

リリース物はすべて承認が必要だ。だが、わしは忙しいから

一括でまとめて持ってきなさい。（フロー効率ダウン）

（効率落ちるだろ！）ヘイトマッハっすわー

エンジニア氏

偉い人氏

10

Efficiency Paradox

This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix -

リソース効率

フロー効率


High

HighLow

Low

効率的な島々

効率的な海


荒廃した土地

完全な状態

リソース効率

フロー効率


High

HighLow

Low

効率的な島々

効率的な海


荒廃した土地

完全な状態

・それぞれの島の中において資源効率が高く、島毎に個別最適化された状態。・フォーカスは資源であり、独自の資源を効率的に活用することによって、　各部門は生産される商品やサービスのコスト削減に貢献・製造業において、各コンポーネントや製品が在庫として費やしている時間の割合が　大半を占める。・結果的に、顧客に価値が届くまでの時間を長くする待機時間を作り出している。

リソース効率

フロー効率


High

HighLow

Low

効率的な島々

効率的な海


荒廃した土地

完全な状態

・効率が高いが資源効率が低い状態。・フォーカスは顧客にあり、可能な限り効率的にニーズを満たすこと。・フロー効率を最大限にするには、組織のリソースに空き容量が必要。　リソースの効率的な使用を犠牲にしてフローを効率的にする。・効率的な海を作り流れを作り出すには、独立した効率的な島だけではなく、　全体像をよく理解する必要がある。

リソース効率

フロー効率


High

HighLow

Low

効率的な島々

効率的な海


荒廃した土地

完全な状態

・組織はそのリソースを効率的に使用することも、　効率的なフローを作成することもできていない状態。・リソースの浪費 & 顧客への提供価値が低い状態

リソース効率

フロー効率


High

HighLow

Low

効率的な島々

効率的な海


荒廃した土地

完全な状態

・完璧な状態・この状態を達成する組織は、高いリソース効率と　高いフロー効率の両方を備えている。・完璧な状態に到達することは困難である・完全な状態に到達することの難しさの鍵は、Variation(ムラ)。

リソース効率

フロー効率


High

HighLow

Low

稼働率100%のチーム機能がリリースされるまでのリードタイム長い

稼働率は100%ではないチーム機能がリリースされるまでのリードタイム短い

Variation


リソース効率

フロー効率


High

HighLow

Low


稼働率は100%ではないチーム機能がリリースされるまでのリードタイム短い

Variation


例：高級ホテル/旅館 (部屋稼働率:空き部屋あり) (客数に対する従業員数:多)

例：カプセルホテル (部屋稼働率:100%)

(客数に対する従業員数:少)

リソース効率

フロー効率


High

HighLow

Low

Variation

我々


稼働率は100%ではないチーム機能がリリースされるまでのリードタイム短い例：高級ホテル/旅館

(部屋稼働率:空き部屋あり) (客数に対する従業員数:多)

例：カプセルホテル (部屋稼働率:100%)

(客数に対する従業員数:少)


リソース効率

フロー効率


High

HighLow

Low

VariationWaterFallSoR

AgileSoE

小規模・仮説検証

大規模開発

我々


リソース効率

フロー効率


High

HighLow

Low

ココに行きたい

我々


リソース効率

フロー効率


High

HighLow

Low


我々

流れに着目するほうがムダを炙り出しやすいこっちから登ったほうが

リソース効率上のムダも発見しやすいThis is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix -

リソース効率

フロー効率


High

HighLow

Low


我々


達成することは不可能。星に到達するためには、組織は2つのことが必要。

・顧客の現在および将来のニーズに関するすべての情報を完全に把握。・完全に柔軟で信頼性の高いリソースが必要。リソースの容量、機能、能力をすぐに調整してすべてのタイプのニーズを満たすこと

ここでの鍵は、需要（顧客のニーズ）と供給（組織のリソース）の両方の変化。

リソース効率

フロー効率


High

HighLow

Low


需要と供給のムラがこの境界を内側に押しこむ到達不能領域

需要が完全に予測可能でなく、かつ/またはリソースが完全に柔軟で信頼できるものではない場合（需要と供給にムラがある場合）組織がリソース効率を改善し、それを高いフロー効率とどのくらい組み合わせるかには限界が発生する。

Efficiency Frontier

Efficiency Frontier

リソース効率

フロー効率


High

HighLow

Low


Efficiency Frontier

病院の緊急医療室

大量の類似製品を製造する製造会社

到達不能領域Efficiency Frontier

到達不能領域

需要と供給のムラがこの境界を内側に押しこむ

リソース効率

フロー効率


High

HighLow

Low


Efficiency Frontier

新規事業、スタートアップ


到達不能領域

我々

（大量の類似製品を製造する仕事ではないため両方取りが難しい）

需要と供給のムラがこの境界を内側に押しこむ

リソース効率とフロー効率のビジネスKPIに対する

効果・影響

検索条件入力画面

検索結果一覧画面詳細画面予約画面

口コミ

SEO

SEM

ETC

サービストップ画面

if(isBooked){

}

口コミ

SEO

SEM

ETC

成果課金型広告枠検索サービス

¥0利用者クライアント

マッチングサービス

CVR改善＝売上直結

例：CVR最大化に向けたUI/UX仮説検証

流入数

1st week 2nd week 3rd week 4th week 5th week 6th week 7th we


CVR

CVR

±0 ±0 ±0 ±0 ±0 ±0 +3

±0 ±0 +1 +1 +1+1 +1±0 ±0 +1 +1+1±0 ±0±0 ±0 +1±0 ±0 ±0 ±0

売上 or

KPI

売上 or

KPI

release

ABC

00.751.5

2.253

1st week 2nd week 3rd week 4th week 5th week 6th week 7th w

00.75

1.52.25

3


ビジネス価値とリソース効率性重視の開発スタイル

ABC

ビジネス価値とフロー効率性重視の開発スタイル



CVR

CVR

±0 ±0 ±0 ±0 ±0 ±0 +3

±0 ±0 +1 +1 +1+1 +1±0 ±0 +1 +1+1±0 ±0±0 ±0 +1±0 ±0 ±0 ±0

売上 or

KPI

売上 or

KPI

release

ABC

00.751.5

2.253


00.75

1.52.25

3


ABC

学んでいない期間稼いでいない期間

学んでいない期間稼いでいない期間

オーバーヘッドで若干合計稼働は増える

ビジネス価値とリソース効率性重視の開発スタイル

ビジネス価値とフロー効率性重視の開発スタイル複数の実験を

同時にやると濁る

Build-Measure-Learnにフロー効率を注入する









指標値例


検証ポイント

MVP 目標








利益



利益最大化


AARRR


①② ③

⑤

① ①② ③④⑥ ⑤

① ①② ③ ④

⑥⑦⑦⑦⑦

⑦

仮説検証実行









指標値例


検証ポイント

MVP 目標








利益



利益最大化


AARRR


①② ③

⑤

① ①② ③④⑥ ⑤

① ①② ③ ④

⑥⑦⑦⑦⑦

⑦


仮説検証の学びまでのリードタイムを長くするマルチタスクをやめる

1st week 2nd week 3rd week 4th week 5th week 6th week 7th week

仮説Aの検証

仮説Bの検証仮説Cの検証



仮説Aの検証仮説Bの検証仮説Cの検証

1st week 7th week

学習コスト失敗時の損失不確実さリスク


仮説検証をマルチタスクでやる場合

仮説検証をシングルタスク（WIP制限1）でやる場合


仮説Aの検証

仮説Bの検証




1st week 7th week





学んでいない期間

学びを次のインプットへ (軌道修正し易い）

失敗の手戻りがでかい

短期間で学ぶ失敗の痛みが小さい

仮説Cの検証


軌道修正が早期に出来る

仮説

Resource

流れる対象

1つの仮説にメンバ全員が

フォーカスする

Resource Resource



1st week 2nd week 3rd week 4th week 5th week 6th week 7th wee




短期間で学ぶ失敗の痛みが小さい軌道修正が早期に出来る


仮説検証のバッチサイズを小さくする（MVPを小さくする）

仮説A 仮説B 仮説C


仮説A 仮説B 仮説C仮説A’ 仮説B’ 仮説C’


仮説A 仮説B 仮説C仮説B’仮説A’

1仮説検証を2weeksでやる場合、26回/年

1仮説検証を1weekでやる場合、52回/年

検証結果から、実施不要の検証を省略でき、後続の検証を前倒し出来る

仮説C’

いきなり時計回しで始めるとムダを含むMVPを作りがち

30

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

どんなMVP作ればいいの？

仮説はある！

オーバースペックMVP

作りすぎのムダ

いきなり時計回しで始めるとムダを含むMVPを作りがち

30


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

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

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

再学習のムダ

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

情報の流れ

モノの流れ

ニーズwhenwhatamount

whenwhatamount

whenwhatamount

whenwhatamount

pullpullpull

push push push


①仮説

②何を学ぶのか

③必要なデータは？

④どうやって計測する？

⑤必要なものは？

⑥どう構築するか？

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

pull

pull

pull pull

pull

30


⑫仮説を実証

⑪学ぶ

⑩データを元に検証

⑨計測する

⑧完成したMVP

⑦構築する

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

pushpush

push

push

30


情報の流れ（BMLを逆流）

モノの流れ（BMLの流れ）

ニーズpullpullpull

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

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

⑥構築方法

⑫実証⑪学ぶ⑩データで検証

⑨計測する⑧完成したMVP⑦構築する

push push push

BUILD MEASURE LEARN

BUILD設計 MEASURE設計 LEARN設計

①②③④ ⑤

⑥

⑫⑪⑩⑨ ⑧

⑦



仮説検証を設計する

仮説何を学ぶのか

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

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

実証に必要な条件

MVP構築コスト

仮説実証にかかる時間

将来のリスク/機会

結果、実際の学び


仮説検証を設計する

PBL

リリース

プランニング

振り返り MTG

レビュー

デイリー MTG

2weeks 開発タスク/Day

ビジネス仮説リスト

※(元)僕の考えた最強の機能リスト

BUILD

MEASURE

LEARN

IDEA

DATA

① Ready化数

②リリース数

学びまでのリードタイムを削減する

① ②

① ②

リードタイム

③③=①-② 　=在庫量

Ready化数リリース数累積フロー図

BuildPlanning Measure

工程別滞留数

(在庫数)

在庫量推移

Learn

③

累積Ready数累積リリース数

：MVP学びまでのリードタイムを削減する（まずは開発効率化）

③①

②

Readyにした数とリリースした数在庫数推移

① ②Ready化数リリース数

BuildPlanning Measure

工程別滞留数

(在庫数)

在庫量推移

Learn

③：MVP

学びまでのリードタイムを削減する（まずは開発効率化）

リソース効率

フロー効率

リソース効率を高める（単位時間あたりの実証ロット数を上げる）

High

HighLow

Low

Efficiency Frontier


到達不能領域

我々

さらに、リソースの効率性も上げる

仮説B’

最初に一つの仮説に絞らない/決定を遅らせる/決定時の選択肢を最大化する

仮説A 仮説A’

仮説B

仮説C 仮説C’

仮説D 仮説D’

仮説D”


仮説E 仮説E’

仮説F

仮説G

解決策案の実証① 解決策案の実証② 解決策案の実証③

仮説F’

仮説G’

こんな感じ？ Scaling Leanの GOLEAN感

リソース効率を高める（単位時間あたりの実証ロット数を上げる）

まとめ









指標値例


検証ポイント

MVP 目標








利益



利益最大化


AARRR


①② ③

⑤

① ①② ③④⑥ ⑤

① ①② ③ ④

⑥⑦⑦⑦⑦

⑦


リソース効率

フロー効率


High

HighLow

Low


需要と供給のムラがこの境界を内側に押しこむEfficiency Frontier



到達不能領域

我々


仮説Aの検証

仮説Bの検証




1st week 7th week





学んでいない期間


失敗の手戻りがでかい

短期間で学ぶ

失敗の痛みが小さい

仮説Cの検証



仮説検証のバッチサイズを小さくする（MVPを小さくする）

仮説A 仮説B 仮説C


仮説A 仮説B 仮説C仮説A’ 仮説B’ 仮説C’


仮説A 仮説B 仮説C仮説B’仮説A’

1仮説検証を2weeksでやる場合、26回/年

1仮説検証を1weekでやる場合、52回/年

検証結果から、実施不要の検証を省略でき、後続の検証を前倒し出来る

仮説C’

情報の流れ（BMLを逆流）

モノの流れ（BMLの流れ）

ニーズpullpullpull

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

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

⑥構築方法

⑫実証⑪学ぶ⑩データで検証

⑨計測する⑧完成したMVP⑦構築する

push push push

BUILD MEASURE LEARN

BUILD設計 MEASURE設計 LEARN設計

①②③④ ⑤

⑥

⑫⑪⑩⑨ ⑧

⑦


ご静聴・ご清聴ありがとう

ございました

leanstartupをリーンにヤル #リーンスタートアップ

Small Business & Entrepreneurship