フロー効率性とリソース効率性、再入門 #devlove #devkan

フロー効率性
とリソース効
率性、再入門
黒田　樹 @i2key
リクルートテクノロジーズリクルートジョブズ

リソース効率性 - フロー効率性
大事にしたい価値観
How much - How little
タスク管理 - ペース管理
プッシュ型 - プル型
マルチタスク - シングルタスク
Waterfall vs Agile
ではなく
手法論ではなく原理原則に立ち返り目的ベースで考える

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

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
A機能、B機能、C機能の実装それぞれ15人日かかる場合
A
A
A
B B
B B
B B

リソース効率性
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%になるまで分配する
例
・マルチタスク
・大きなウォーターフォール型開発
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
リリースまでのリードタイム約2w
A
A
A
B B
B B
B B
同時にやることをひとつにするとプロダクトがユーザに届くま
でのリードタイムは短くなる。しかし、全員が同じことをやる
ため、一時的に手持ちがなくなる人が出たりするためリソース
の稼働率は下がる。（Aだけでみるとトータル稼働は多い）

A
Resource
流れる対象
流れる対象（タスク）が得られるリソースの時間を最大化する
流れる対象に
フォーカスする
Resource Resource
例
・ペアプログラミング/モブプログラミング
・クロスファンクショナルチーム
・システム障害発生時の動き
フロー効率性

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
「リソース効率性」が良い
（例）稼働率100%、リソースに遊びが無い
「フロー効率性」が良い
（例）機能リリースまでのリードタイムの短さ

A A A A A A A A A AA A A A A
思考停止した「マルチタスクは悪である」信仰。
A A A A A
A A A A A
A A A A A
本質的にはマルチタスクはNGであるが、同じ目的のものを
多重化してリソース効率の優先度をさげ（瞬間コスト増）、
フロー効率（リードタイム短縮）を取る選択肢はある。
※目的の理解とマルチタスクの定義は重要
シングルタスク
組織的なマルチタスク(に見えるなにか)

やることを小さくすることでもLTの短縮はできる。
A A A A A
達成すべき目的が満たせるなら、やることを小さくする。
（かかるコストをさげてリードタイムも短くする）
シングルタスク
やることを小さくする
A A A A A A A A A A

同じリードタイム短縮でもやりかた色々
A A A A A
リードタイム短縮前
やることを小さくして（コスト下げて）リードタイムを短縮
A A A A A A A A A A
A A A A A
A A A A A
A A A A A
コストを増やしてリードタイムを短縮

同じリードタイム短縮でもやりかた色々
A A A A A
リードタイム短縮前
やることを小さくして（コスト下げて）リードタイムを短縮
A A A A A A A A A A
A A A A A
A A A A A
A A A A A
コストを増やしてリードタイムを短縮
目的ではなく手段にフォーカスした
「マルチタスクは悪」信仰の場合、
これはNGになりがち。

http://jp4.scaledagileframework.com/set-based-design/
例）ポイントベース設計
1つの設計戦略を初期に確約するため、締切が迫った際の変更コストがやばい
例）セットベース設計
開発サイクルの中で長い期間、設計の選択肢を複数残し経済合理性を高める

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

リソース効率とフロー効率はトレードオフの関係になりやすい
大規模開発のような大量のものを一括でドン！と
リリースする文脈（リソース効率が支配するパラダイム）
ペアプログラミングしたいです！
（効果：フロー効率アップ）
2人で同じことやったら、
効率半分に落ちるだろ！却下！
（効果：リソース効率ダウン）エンジニア氏
偉い人氏

リソース効率とフロー効率はトレードオフの関係になりやすい
仮説検証型でUI/UX改善を回し、KPIを伸ばしにいく文脈。
現場は学びまでのリードタイムを限りなく最小化したい。
（無意識にフロー効率を重視している）
リリース物はすべて承認が必要だ。
だが、わしは忙しいから
一括でまとめて持ってきなさい。
（フロー効率ダウン）
（効率落ちるだろ！）
ヘイトマッハっすわー
エンジニア氏
偉い人氏

Eﬃciency Paradox
This is Lean https://www.amazon.co.jp/dp/919803930X/The Eﬃciency 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
Variation
例：高級ホテル/旅館
(部屋稼働率:空き部屋あり)
(客数に対する従業員数:多)
例：カプセルホテル
(部屋稼働率:100%)
(客数に対する従業員数:少)

リソース効率
フロー効率
High
HighLow
Low
Variation
我々
例：高級ホテル/旅館
(部屋稼働率:空き部屋あり)
(客数に対する従業員数:多)
例：カプセルホテル
(部屋稼働率:100%)
(客数に対する従業員数:少)

リソース効率
フロー効率
High
HighLow
Low
Variation
WaterFall
SoR
Agile
SoE
小規模・仮説検証
大規模開発
我々

リソース効率
フロー効率
High
HighLow
Low
ココに
行きたい
我々

リソース効率
フロー効率
High
HighLow
Low
ココに
行きたい
我々
流れに着目するほうがムダを炙り出しやすい
こっちから登ったほうが
リソース効率上のムダも発見しやすい

リソース効率
フロー効率
High
HighLow
Low
ココに
行きたい
我々
達成することは不可能。星に到達するためには、組織は2つのことが必要。
・顧客の現在および将来のニーズに関するすべての情報を完全に把握。
・完全に柔軟で信頼性の高いリソースが必要。
リソースの容量、機能、能力をすぐに調整してすべてのタイプのニーズを満たすこと
ここでの鍵は、需要（顧客のニーズ）と供給（組織のリソース）の両方の変化。

リソース効率
フロー効率
High
HighLow
Low
ムラがこの境界を内側に押しこむ
到達不能領域
需要が完全に予測可能でなく、かつ/またはリソースが完全に柔軟で信頼できるものでは
ない場合（需要と供給にムラがある場合）
組織がリソース効率を改善し、それを高いフロー効率とどのくらい組み合わせるかには限
界が発生する。
Eﬃciency Frontier
Eﬃciency Frontier

リソース効率
フロー効率
High
HighLow
Low
Eﬃciency Frontier
病院の緊急医療室
大量の類似製品を製造する製造会社
到達不能領域
Eﬃciency Frontier
到達不能領域

リソース効率
フロー効率
High
HighLow
Low
Eﬃciency Frontier
新規事業、スタートアップ
到達不能領域
Eﬃciency Frontier
到達不能領域
我々

リソース効率とフロー効率の
ビジネス目標に対する
効果・影響

検索条件
入力画面
検索結果
一覧画面
詳細画面予約画面
口コミ
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
A
B
C
0
0.75
1.5
2.25
3
1st week 2nd week 3rd week 4th week 5th week 6th week 7th w
0
0.75
1.5
2.25
3
ビジネス価値とリソース効率性重視の開発スタイル
A
B
C
ビジネス価値とフロー効率性重視の開発スタイル

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
A
B
C
0
0.75
1.5
2.25
3
0
0.75
1.5
2.25
3
A
B
C
学んでいない期間
稼いでいない期間
学んでいない期間
稼いでいない期間
オーバーヘッドで
若干合計稼働は増える
複数の実験を
同時にやると濁る

リクルートの
ビジネスモデルと
エンジニアリング

クライアント
様向け画面
アルバイト先を
探している人
アルバイトを
募集している企業

クライアント
様向け画面
商品開発
サイト改善サイト改善
求人情報に対するコンバージョンレートの向上
UI/UXの継続的改善（仮説検証型）
求人情報の出向枠の追加
掲載期間、掲載形式等の商品に関する開発
（営業広報あるため計画駆動、シッカリカッチリ）

SoR
Bimodal IT Mode1 Mode2
正式名称 System of Record(SoR) System of Engagement(SoE)
適正
基幹系・勘定系、
ミッションクリティカルな機能・システム
(決済システム、顧客管理等)
正解が無い中、柔軟に変化をしながら走り続
ける必要がある機能・サービス
(スマホアプリ、ウェブサービスのフロント)
目的
信頼性、安定性
定めた仕様に従って安定性や品質を担保し
ながら開発していく必要がある
俊敏性、速度
フィードバックに基づいて速やかに改善を加
え、頻繁にリリースする
価値・評価費用対効果、コスト売上、ブランド、UX
アプローチウォーターフォール、V-model、重量IID アジャイル、リーン、カンバン、軽量IID
調達
エンタープライズサプライヤー、
長期的な取引
小さい、新しいベンダー、短期間の取引
メンバ適正従来のプロセス、プロジェクトが得意新しくて不確実なプロジェクトが得意
組織/文化開発部門・計画型ビジネス＆開発混在・探索型
サイクルタイム数ヶ月数日、数週間
SoE
計画型
シッカリカッチリ
探索型
速さ、柔軟さ

クライアント
様向け画面
商品開発
サイト改善サイト改善
求人情報に対するコンバージョンレートの向上
UI/UXの継続的改善（仮説検証型）
求人情報の出向枠の追加
掲載期間、掲載形式等の商品に関する開発
（営業広報あるため計画駆動、シッカリカッチリ）
SoRSoE SoE

SoEとSoRの目的別でチームを分ける
マーケ組織商品企画組織営業組織データ系組織
プロダクト開発組織
プロダクトオーナー
プロジェクト(WF) スクラム or カンバンスクラム or カンバン
アーキテクト
プロキシー
プロキシー
プロジェクトリーダー
スクラムマスター
○○○○○
XXXXXX
△△△△△
○○○○○
プロキシー
○○○○○
XXXXXX
△△△△△
○○○○○
○○○○○
XXXXXX
△△△△△
○○○○○
エンジニア
エンジニア
エンジニア
：エンジニア x N人
UI/UXデザイナー
エンジニア
エンジニア
エンジニア
：
SoR SoE SoE

アーキテクト
プロキシー
プロキシー
○○○○○
XXXXXX
△△△△△
○○○○○
プロキシー
○○○○○
XXXXXX
△△△△△
○○○○○
○○○○○
XXXXXX
△△△△△
○○○○○
エンジニア
エンジニア
エンジニア
エンジニア
エンジニア
エンジニア
：
SoR SoE SoE
リソース効率性フロー効率性フロー効率性

アーキテクト
プロキシー
プロキシー
○○○○○
XXXXXX
△△△△△
○○○○○
プロキシー
○○○○○
XXXXXX
△△△△△
○○○○○
○○○○○
XXXXXX
△△△△△
○○○○○
エンジニア
エンジニア
エンジニア
エンジニア
エンジニア
エンジニア
：
SoR SoE SoE
日経SYSTEMS 6月号に掲載していただきました

フロー効率性を現場への適用

アーキテクト
プロキシー
プロキシー
○○○○○
XXXXXX
△△△△△
○○○○○
プロキシー
○○○○○
XXXXXX
△△△△△
○○○○○
○○○○○
XXXXXX
△△△△△
○○○○○
エンジニア
エンジニア
エンジニア
エンジニア
エンジニア
エンジニア
：
SoR SoE SoE
プランナー
CVR向上
案件
CVR向上
案件
CVR向上
案件
ここの話→

目的を見失いスクラムという手法に目がいった例
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
Sprint#1 Sprint#2
A 担当者
B 担当者
C 担当者
ココ
チケット全部
DONEです!
チケット全部
DONEです!
チケット全部
DONEです!
プロダクト
オーナー
いくら計画したチ
ケット消化が100%
でも、何もリリース
出来なければビジ
ネス上意味ないよ

目的を見失いスクラムという手法に目がいった例
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
Sprint#1 Sprint#2
A 担当者
B 担当者
C 担当者
ココ
チケット全部
DONEです!
チケット全部
DONEです!
チケット全部
DONEです!
プロダクト
オーナー
いくら計画したチ
ケット消化が100%
でも、何もリリース
出来なければビジ
ネス上意味ないよ
ビジネス的にはフロー効率性を重視して
スクラムを運営してほしかったのに、
チケットをすべてDONEすることを
目的としたリソース効率性特化な
スプリントが運営されていた。

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
A
B
C
0
0.75
1.5
2.25
3
0
0.75
1.5
2.25
3
A
B
C
Sprint Sprint Sprint

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
A
B
C
0
0.75
1.5
2.25
3
0
0.75
1.5
2.25
3
A
B
C
リードタイム
リードタイム
Sprint Sprint Sprint

本質の理解を欠いたスクラムをいったん辞め、
タスクボード(notカンバン)へ。
https://speakerdeck.com/poohsunny/devsumi2018
「○○API実装」みたいなタスクがDONEしても1円も生まない。

CVR
±0 ±0 +1 +1 +1+1 +1
±0 ±0 +1 +1+1±0 ±0
±0 ±0 +1±0 ±0 ±0 ±0
売上
or
KPI
0
0.75
1.5
2.25
3
A
B
C
バックエンド
エンジニア
フロント
エンジニア
プロダクト
オーナー
顧客
+1
承認レビュー
仕様確認
API開発 API開発
Front開発
デプロイ待ち待ち待ち
テスト
テスト

CVR
±0 ±0 +1 +1 +1+1 +1
±0 ±0 +1 +1+1±0 ±0
±0 ±0 +1±0 ±0 ±0 ±0
売上
or
KPI
0
0.75
1.5
2.25
3
A
B
C
バックエンド
エンジニア
フロント
エンジニア
プロダクト
オーナー
顧客
+1
承認レビュー
仕様確認
API開発 API開発
Front開発
デプロイ待ち待ち待ち
テスト
テスト
リードタイム
リードタイム短縮
エンジニアリングによってLTを短縮したい

リードタイム
プロセスタイム(PT) ムダ+
顧客への価値を作り出している時間価値を作っていない時間
➡設計
➡コーディング
➡ビルド待ち
➡手戻り
➡承認待ち

ムダを排除する
✓余分な機能のムダ
✓遅れのムダ
✓引き継ぎのムダ
✓再学習のムダ
✓未完成の作業のムダ
✓タスク切り替えのムダ
✓欠陥のムダ
➡使わない機能
➡様々な要因による待ち
➡他部署,メンバへの引き継ぎ
➡標準化されていない
➡同時にたくさん着手
➡不要な作業、遅い作業
➡低品質による手戻り

企画からリリースまでの全工程の
タスクの流れからボトルネックを
浮き彫りにし、ボトルネックに潜
むムダを潰したい

DevelopmentPlanning Design Measure
Ph.1 Ph.2 Ready会 SprintDesign AB Testing
工程別
滞留数
(在庫数)
工程別
スルー
プット 4個/2週 3個/2週 3個/2週 4個/2週 1個/2週 4個/2週
未着手案件の在庫推移を可視化し組織生産性の可視化
1案件あたりのリードタイムを最小化したい

工程別
滞留数
(在庫数)
工程別
スルー
Ready状態の在庫を作る
スループット
在庫を出荷する
スループット
在
庫
量
推
移
Ready化数リリース数
1案件あたりのリードタイムを最小化したい

工程別
滞留数
(在庫数)
工程別
スルー
スループット
スループット
在
庫
量
推
移
① ②
③
① ②
リードタイム
③
③=①-②
　=在庫量
Ready化数リリース数累積フロー図

工程別
滞留数
(在庫数)
工程別
スルー
スループット
スループット
在
庫
量
推
移
① ②
③
③①
②
Ready化数リリース数
Readyにした数とリリースした数在庫数推移

スループット
スループット
>
↑
開発の生産性がボトルネック

開発チーム内のムダをあぶり出す

設計
実装
試験
設計
実装
試験
手戻り
リワークチャートによる手戻りの可視化

XPやDevOpsのプラクティスは
フロー効率性を高める作用が強い
改善目的に合わせて利用させていただく。

リワークチャートによる手戻りの可視化
設計
実装
試験
設計
実装
試験
手戻り
Javascript周りのフロントエンド実
装における技術的負債による手戻り

もろもろ改善していった結果、
最終的にボトルネックが技術的負債に推移。
ここではじめて、
技術的負債によって低下している開発の生産性が
企画ふくめた全体のスループットを決定している状態になる。
となると、技術負債の解消 = ビジネス速度向上。

でも、本当に倒すべきはこれ。

ムダを排除する
✓余分な機能のムダ
✓遅れのムダ
✓引き継ぎのムダ
✓再学習のムダ
✓未完成の作業のムダ
✓タスク切り替えのムダ
✓欠陥のムダ
➡使わない機能
➡様々な要因による待ち
➡他部署,メンバへの引き継ぎ
➡標準化されていない
➡同時にたくさん着手
➡不要な作業、遅い作業
➡低品質による手戻り
これが一番たちが悪い

CVR
±0 ±0 +1 +1 +1+1 +1
±0 ±0 +1 +1+1±0 ±0
±0 ±0 +1±0 ±0 ±0 ±0
売上
or
KPI
0
0.75
1.5
2.25
3
A
B
C
良質玉
価値
(成果)
質低玉ムダ
これを目指したい
高速にムダを作っているだけ

設計実装テスト
課題理
解
仮説構
築
仮説検証
設計
要件定
義
マーケ計測
データか
ら学ぶ
リリース
ユーザCV 仮説実証
ユーザー
ストーリー
設計
エンジニアとして前工程、後工程に染み出していく

改善するリードタイムのスコープを広げる
リードタイム
リードタイム
From 要件定義 to リリース
From 課題設定 to 仮説実証
From コンセプト to キャッシュ

From 課題設定 to 仮説実証
From コンセプト to キャッシュ
データから仮説を
類推できる人
蓄積したデータを可視化し
学びや次の仮説にインプット
するためのデータ基盤
安全に実験出来るテスト基盤
Feature Toggle/
Dark Launch/
DevOps系なアレコレ
From 要件定義 to リリース

DataOps
DevOps※狭義
MarketingOps
SalesOps
DesignOps
最近の潮流：xOpsによるフロー効率性の向上

https://www.slideshare.net/takaumada/xops

課題
理解
会議室で考えて
思い込みで
始めると
仮説
実証
ここで
失敗が発覚
超手戻り
改善するリードタイムのスコープを広げる

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

1st week 2nd week 3rd week 4th week 5th week 6th week 7th wee
仮説検証のバッチサイズを小さくする（MVPを小さくする）
仮説A 仮説B 仮説C
1st week 2nd week 3rd week 4th week 5th week 6th week 7th wee
仮説A 仮説B 仮説C仮説A’ 仮説B’ 仮説C’
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
仮説A 仮説B 仮説C仮説B’仮説A’
1仮説検証を2weeksでやる場合、26回/年
1仮説検証を1weekでやる場合、52回/年
検証結果から、実施不要の検証を省略でき、後続の検証を前倒し出来る
仮説C’

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

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

手戻りのムダや作り過ぎのムダを減らすために、
ニーズに対しMVP（必要最小限の価値のあるもの）をつくる
→ニーズからプルする
情報の流れ
モノの流れ
ニーズ
when
what
amount
when
what
amount
when
what
amount
when
what
amount
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構築
コスト
仮説実証
にかかる
時間
将来のリ
スク/機会
結果、実際の学び
仮説検証を設計する

フロー効率性とリソース効率性、再入門 #devlove #devkan

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

More from Itsuki Kuroda

More from Itsuki Kuroda (17)

Recently uploaded

Recently uploaded (7)

フロー効率性とリソース効率性、再入門 #devlove #devkan