結果的に組織がAgileな状態であること #agile #scrum #leanstartup

結果的に組織
がAgileな状
態であること。
黒田　樹 @i2key
～IDEAをCASHに変えるフローの効率化～
リクルートテクノロジーズ

顧客発見
【ニーズ検証】
顧客実証
【売って検証】
組織構築
【本格拡大】
Problem/Solution
Fit
Product/Market
Fit Scaling
Retention CAC < LTV 売上
課題解決可能
な最小限
売り方最適化 / 売上最大化売る
品質
モデル
魅力的品質最低限の性能品質
魅力的品質
当たり前品質
アップセル/クロスセルに向けた性能品質
魅力的品質
当たり前品質
指標値例
検証アク
ション
検証
ポイント
MVP
目標
MVP作って壊す
MVP
品質
最低限の
売れる状態
セグメントに応じて売れる状態
検証が既存ユーザに影響与えない
独自な価値提供を出来ているか
深い課題を抱えた顧客がいるか
その課題の解決策は妥当か
開発
モデル例
顧客は本当に買ってくれるか
コスト構造に無理がないか
顧客開拓
【リーチ検証】
最適な売り方の検証
最適な価格設定の検証
導入期成長期成熟期
【SoE】Agile【SoE】カウボーイ【SoE】Agile 【SoR】WaterFall
利益
CPA最適化
マーケットシェア
CVR最大化等のUI/UX仮説検証
価格設定/商品検討のための仮説検証
クロスセルのためのエンタープライズ個別対応開発
仮説検証済み機能によるマーケット刈り取り開発
納期必達型の商品開発
負債解消ビックリライト(ObjC->Swift化)
ビジネス仮説検証の高速化文化祭前夜感と全能感を味わ
う時期
&
ALL高品質
競合との性能競争(消耗戦)
キードライバー値
最大化
利益最大化
ビジネス
フェーズ

Acquisition
獲得
Retention
継続
Churn
解約
Referral
紹介
Activation
活性化
Revenue
収益
AARRRモデル

Acquisition
獲得
Retention
継続
Churn
解約
Revenue
収益
Activation
活性化
Retention
継続しているということは、
顧客の課題を解決し続けている（と言える）
✔顧客セグメントが存在する
　＆
✔顧客が抱える課題を認識出来ている
　＆
✔それに対する解決策が正しい

Acquisition
獲得
Retention
継続
Churn
解約
Referral
紹介
Activation
活性化
Revenue
収益
CAC < LTV
その上で、顧客獲得コストよりも、
ライフタイムバリューのが高い状態
（ビジネスモデルとして成立）

Acquisition
獲得
Retention
継続
Churn
解約
Referral
紹介
Activation
活性化
Revenue
収益
売上最大化
売り方（チャネル）の最適化、
アップセル、クロスセル、水漏れ防止、
グロースハック、etc

顧客発見
顧客実証
組織構築
【本格拡大】
Problem/Solution
Fit
Product/Market
Fit Scaling
課題解決可能
な最小限
品質
モデル
魅力的品質
当たり前品質
魅力的品質
当たり前品質
指標値例
検証アク
ション
検証
ポイント
MVP
目標
MVP作って壊す
MVP
品質
最低限の
売れる状態
開発
モデル例
顧客開拓
利益
CPA最適化
CVR最大化等のUI/UX仮説検証
価格設定/商品検討のための仮説検証
う時期
&
ALL高品質
最大化
利益最大化
ビジネス
フェーズ
IDEAをCASHに変える
フローの効率化

そもそも「効率が良い」って
どういう意味で使いますか？
IDEAをCASHに変える
フローの効率化

速く作業が出来ること？

「リソース効率性」が良い
（例）稼働率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 B B B
C C C C C
C C C C C
C C C C C
月　火　水　木　金月　火　水　木　金月　火　水　木　金
リリースまでのリードタイム 1w
A機能、B機能、C機能の実装それぞれ15人日かかる場合

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

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

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
リリースまでのリードタイム約2w
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

リソース効率
フロー効率
リソース効率とフロー効率の関係
High
HighLow
Low
稼働率100%のチーム
機能がリリースされるまでの
リードタイム長い
稼働率は100%ではないチーム
リードタイム短い
Variation
This is Lean https://www.amazon.co.jp/dp/919803930X/The Eﬃciency Matrix -

リソース効率
フロー効率
High
HighLow
Low
Variation
This is Lean https://www.amazon.co.jp/dp/919803930X/The Eﬃciency Matrix -
例：高級ホテル/旅館
(部屋稼働率:空き部屋あり)
(客数に対する従業員数:多)
例：カプセルホテル
(部屋稼働率:100%)
(客数に対する従業員数:少)

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

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

リソース効率
フロー効率
High
HighLow
Low
SoR
SoE
大規模開発ココに
行きたい
我々
WaterFall
Agile

リソース効率
フロー効率
High
HighLow
Low
SoR
SoE
行きたい
我々
WaterFall
Agile

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

ビジネスフェーズ毎に、
目的、追うべき目標がある

顧客発見
顧客実証
組織構築
【本格拡大】
Problem/Solution
Fit
Product/Market
Fit Scaling
課題解決可能
な最小限
品質
モデル
魅力的品質
当たり前品質
魅力的品質
当たり前品質
指標値例
検証アク
ション
検証
ポイント
MVP
目標
MVP作って壊す
MVP
品質
最低限の
売れる状態
開発
モデル例
顧客開拓
利益
CPA最適化
う時期
&
ALL高品質
最大化
利益最大化
ビジネス
フェーズ
CVR最大化等のUI/UX仮説検
証
価格設定/商品検討のための仮
説検証

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

検索条件
入力画面
検索結果
一覧画面
詳細画面予約画面
口コミ
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
学んでいない期間
稼いでいない期間
学んでいない期間
稼いでいない期間
オーバーヘッドで
若干合計稼働は増える
複数の実験を
同時にやると濁る

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

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
Scrumの場合
Sprint#1 Sprint#2 Sprint#3
スプリント毎に成果を積み上げていく

個別案件における
さらなるリードタイム削減
20

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
Scrumの場合
バックエンド
エンジニア
フロント
エンジニア
プロダクト
オーナー
顧客
+1
承認レビュー
仕様確認
API開発 API開発
Front開発
デプロイ待ち待ち待ち
テスト
テスト
20

バックエンド
エンジニア
フロント
エンジニア
プロダクト
オーナー
顧客
+1
承認レビュー
仕様確認
API開発 API開発
Front開発
テスト
テスト
クロスファンクショナル
エンジニア
(フロント＆バックエンド）
プロダクト
オーナー
顧客
承認条件（広義のBDD化）
Front&API開発（ペアプロ）テスト＆デプロイ(自動化＆パイプライン上の承認)
待ち
待ち
(手戻りのムダ排除)
(引き継ぎのムダ排除) (手作業のムダ排除)
+1
DevOpsやアジャイル等の各種プラクティス活用
目的：学びまでのリードタイム短縮
　　　（フロー効率性を高める）
20

20

低下するとリードタイムを悪化させる（＝品質下げるという選択肢がそもそも無い）
• プロセス品質下げると手順ミス等により手戻りが発生しデリバリへのリードタイムが長く
なる
• 内部品質さげるとバグの発生、コードレビューの指摘、技術的負債による実装の複雑さな
どにより手戻りや速度低下を招き、デリバリへのリードタイムが長くなる
• 外部品質さげるとUXバグをうみ、本来検証したいことが検証できず学びまでのリードタイ
ムが長くなる。障害発生により、それの対応に終われリソースが枯渇し本来やるべきこと
の足かせになり、リードタイムが長くなる
• 利用時の品質さげると、カスタマーサポートが頻発しその対応に組織のパワーが持って行
かれリードタイムが長くなる
品質 = 速度
品質が悪いと手戻りを生むので速度に跳ね返る。
手戻っている時間＝価値提供しない時間、学び
のない時間
20

バックエンド
エンジニア
フロント
エンジニア
プロダクト
オーナー
顧客
+1
承認レビュー
仕様確認
API開発 API開発
Front開発
テスト
テスト
エンジニア
プロダクト
オーナー
顧客
待ち
待ち
+1
学びまでのリードタイム
20

バックエンド
エンジニア
フロント
エンジニア
プロダクト
オーナー
顧客
+1
承認レビュー
仕様確認
API開発 API開発
Front開発
テスト
テスト
エンジニア
プロダクト
オーナー
顧客
待ち
待ち
+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
Scrumの場合
良質玉
価値
(成果)
質低玉ムダ

エンジニアリングビジネス
PBL
リリー
ス
プランニ
ング
振り返り
MTG
レビュー
デイリー
MTG
Sprint/2weeks 開発タスク/Day
僕の考えた最強
の機能リスト
PBLの質、超重要。
（やる必然性・エビデンスの有無）
どんなに開発チームがフロー効率を高めても、開発チームへのインプット
の質が悪いと、価値を生まないゴミを高速生産する
ことになる
ボトルネックが
開発→ビジネスへ遷移

PBL
リリー
ス
プランニ
ング
振り返り
MTG
レビュー
デイリー
MTG
計測
構築
学習
デー
タ
アイ
デア
ビジネス
仮説リスト
思い込みにより発生する各種ムダを
省くためにビジネスサイド、企画サイドもリーンにやる
※(元)僕の考えた
最強の機能リスト

従来の
開発タスクリスト
仮説検証型の
・仮説A検証用モック作成
・仮説B検証用ダミーボタン実装
・検証済み○○機能本実装
・○○機能実装
わざわざ開発せずに
インタビューやエンジニアリング以外で検証できそう
根拠無し
根拠無し
根拠無し
事前検証
(エビデンス収集)
実証後の実装
使われない機能を作るムダ

使われないものを
作らないようにする例

例）写真加工アプリにフィルター購入機能を作ろう！！やり
たいことの実装工数は3人月くらいかかりそうです。
あなたがこのプロダクトのオーナーならどうしますか？
①フィルター購入機能を3人月かけて実装する
　（一切購入されないリスクそのまま）
②フィルタ購入するボタン（ダミー）を用意して、全体のユー
ザーの10%に表示して確認し、本当に購入ボタンが押された
回数を測定してから開発着手の判断をする。工数は2人日。
（本当に購入されるのかのみを検証）
②のほうが無駄の無い判断
仮説を小さく実証する例

100円で
購入
100円で
購入
現在開発中です！
近日リリース予定です！
＜ポップアップ＞
ユーザー全体の10%にだけ
表示されるボタン

保有リスク量
時間引用: http://www.slideshare.net/clevergirl/ux-jackson-2013-oneday-lean-startup-workshop
①3人月かけて作った場合
あれ？流行らない。
よし、機能追加だ！
もっと豪華な
フィルターを売るぞ！
まだまだ機能が
足らんぞおおお！
マーケットプレイスに
すべきだ！！！！
フィルター購入機能を
つくるぞ！
3人月

時間
②ダミーで仮説検証した場合
保有リスク量
2人日

結果から学ぶ
仮説の実験
結果の計測
時間
保有リスク量
2人日
全体の10%のみに出す
ダミー購入ボタン作る
計測した結果、全然
クリックされていない
需要ないんだね、
あぶなかった・・・
（リスクがゼロになる）

時間
顧客いる？課題あってる？解決策あってる？
保有リスク量

従来の
仮説検証型の
・仮説A検証用モック作成
・仮説B検証用ダミーボタン実装
わざわざ開発せずに
インタビューやエンジニアリング以外で検証できそう
根拠無し
根拠無し
根拠無し
事前検証
(エビデンス収集)
実証後の実装
フィルタ購入機能実装検証用フィルタ購入
ダミーボタン実装

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
事前検証A 事前検証B A実証後の本格実装
仮説の
検証
効果
ありそう
本実装成果

エンジニアリングビジネス
PBL
リリー
ス
プランニ
ング
振り返り
MTG
レビュー
デイリー
MTG
計測
構築
学習
デー
タ
アイ
デア
ビジネス
仮説リスト
※(元)僕の考えた
最強の機能リスト

目的にあった
本当に必要なことだけやる
（玉のサイズを必要最低限：MVP）

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

情報とモノのフローを意識した
リーンスタートアップの正しいやり方
いきなりこの流れでやると
小さくやってもムダを生む
30

①仮説
②何を学ぶのか
③必要なデータは？
④どうやって計測する？
⑤必要なものは？
⑥どう構築するか？
思考プロセス
（情報の流れ）
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設計
①
②
③
④
⑤
⑥
⑫
⑪
⑩
⑨
⑧
⑦

【事例】
フロー効率重視で開発プロセスを
組んだものの、チームが知らず知
らずのうちにリソース効率にフォー
カスした選択をしていった話

Sprint
#N
Sprint
#N+1
Sprint
#N+2
Sprint
#N-1
1Q 2Q 3Q
バックログ
・デザインの改善（CVR向上目的）
・UI/UX改善（CVR向上目的）
・技術負債解消（保守性）
・ログ周りの改善（モニタリング）
開発案件リスト
・Web開発タスク #1
API開発チーム(アウトソース)
3ヶ月周期のWF型の計画駆動開発
アプリ開発チーム(インハウス)
2週間スプリントのスクラム開発
↑
こっちの話

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
1st week 2nd week 3rd week 4th week 5th week 6th week 7th
A
B
C
フロー効率性重視の当初の開発計画
A
B
デザイン改善・UI/IX改善
技術負債解消
C C C
C その他、改善

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
A
B
C
デザイン改善・UI/IX改善
技術負債解消
急遽、ビジネス的に大きな変更が舞い込んできた
商品の変更(営業連携、API連携＝リリース日FIX)
リリース日
C その他、改善
フロー効率性重視の当初の開発計画

リリース日固定だし、他の案件も全部まとめて
やったほうが効率がよい（特に試験とか）
（フロー効率の考えが何処かに行ってしまい、いつのまにかリソース効率で考えるように切
り替わってしまっている）
　　　　　　　　　　　　　　　↓
でも、もともとある案件と全部まとめるとリリー
ス日に間に合わないなあ
（大きなバッチサイズで一括でやることを前提にしてしまっている）
　　　　　　　　　　　　　　　↓
もともとある案件の仕様を調整して一括でリリー
ス出来るようにしよう
（期日に合わせてすべてをまとめてリリースすることが目的になる。結果的に、学びの無い期
間をチームが自ら作り出している。）
　　　　　　　　　　　　　　　↓
もとの案件の劣化版を提案する
（本来の狙ったビジネス効果は得られない）
リソース効率バイアスをかけた選択をチームがとりはじめて、
本来の目的を達成できるかわからない機能仕様になってしまう。

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
リリース日フロー効率性重視の当初の開発計画
CVR ±0 ±0 ±0 ±0 ±0 ±0 +3
売上
or
KPI
release
A
B
C
0
0.75
1.5
2.25
3
リソース効率性重視の大きなバッチサイズ開発リリース日
価値を生んでいない期間を最大化・・・
価値を積み上げていく予定が・・

チームがリリース日という制約を前提としてしまった
- 前提を疑うべき
- 制約をコントロール対象にする
- そのリリース日って本当に固定なの？
- 例えば事前にデプロイしておき、当日に切り替える
- Feature Toggle運用とかやりようはある
- エンジニアリングで制約をコントロール対象にできれ
ば、フロー効率で考えられる。
- デプロイとリリースを切り離す。
【教訓】

【事例】
スクラム等のセレモニーを形骸化
したまま実施しており、本来のビ
ジネス上のリードタイムを意識し
ていないケース
（仕掛中在庫、DONEしないタスク群）

CVR ±0 ±0 ±0 ±0 ±0 ±0 +3
売上
or
KPI
release
A
B
C
0
0.75
1.5
2.25
3
余談（場合によっては、目的にそぐわないケース）
リソース効率に振り切ったスクラム
価値までのリードタイムが長く、中々効果に繋がらない
スクラムという手段に溺れた状態
目的を意識せずに形骸化したセレモニーをやっている状態
【教訓】何のためにアジャイルなのか目的を問うこと

“How Much”どれだけ多くできるかという押し込むバイアス。
制約を前提として、まとめてたくさんのことをやるときのバイアス。
リソース効率性のパラダイムが強い。
VS
“How Little”どれだけ細かく刻めるかを考えると変化に強くなる。
どれだけ小さく価値提供できるか。
フロー効率性のパラダイムが強い。
ビジネスの目的・文脈に合わせて以下を選択すると同時に
その選択によってどのようなバイアスが働くかを考慮すること

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
“How Much”どれだけ多くできるかという押し込むバイアス。
制約を前提として、まとめてたくさんのことをやるときのバイアス。
リソース効率性のパラダイムが強い。
“How Little”どれだけ細かく刻めるかを考えると変化に強くなる。
どれだけ小さく価値提供できるか。
フロー効率性のパラダイムが強い。

IDEAがCASHに変わるまでのバリューストリームにおける
リードタイムを短くする改善活動の末、
結果的にアジャイルな状態になっているのが望ましい。
常に、目的を意識し、
目的からプルして
目的のための手段を選択する

結果的に組織
がAgileな状態
であること。

ご清聴＆ご静聴ありがとうございました

結果的に組織がAgileな状態であること #agile #scrum #leanstartup

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (15)

Similaire à 結果的に組織がAgileな状態であること #agile #scrum #leanstartup

Similaire à 結果的に組織がAgileな状態であること #agile #scrum #leanstartup (20)

Plus de Itsuki Kuroda

Plus de Itsuki Kuroda (15)

結果的に組織がAgileな状態であること #agile #scrum #leanstartup