大企業アジャ
イルの勘所
黒田 樹 @i2key
#DevLoveX

若干、愛ゆえにアジャイルをDisりますが、アジャイルの精神は大好きです。
色々なグラデーションがあるなかですべての事情を網羅することは不可能なので
コントラスト強めにスライドを構成しています。解釈は読みてのリテラシーにお任せします。
いろいろ語弊を恐れずいっています。ご了承ください。
期待値調整

https://www.slideshare.net/aratafuji/ss-132895977藤村さんのスライド「プラクティス厨から始めるアジャイル開発」

課題感

課題感：「アジャイル」へのイメージ（大きな企業目線）
• 座組が整う前に初めても基本うまくいかない。開発チームの
問題ではないところで問題が起こり、頓挫する。
• 本に書いてあるようなスモールチームの状況を作ることが難
しく、どうしても、現場と本の世界の間に乖離が生まれる。

課題感：「アジャイル」へのイメージ（大きな企業目線）
• 制約のない理想のキレイな状態（制約が少ない世界の話）で語られがちであり、実際の現
場との乖離が激しすぎてどう登っていいのか困る初見殺し感とそれによる死に覚えゲー感
• 現実的にはこんがらがった状態から改善が始まる事が多い。新規開発でうまくやれるのは
そりゃそうだろ感。「なぜ、こうなるまで放置してたの？」とか「こんな状態になること
に問題がある」みたいに正論を言っても何も「今」を変えることは出来ない。それぞれ事
情がある。現実の課題から出発していない「べき」論が多い。
• 海外のほげほげ大企業でも出来てます。といわれても遠い世界の話にしか聞こえない。
• アウトカムにフォーカスしていない。ビジネス目的やKPIベースで語られずに、「価値」あ
るソフトウェアみたいな表現の解像度で止まっていて、説明責任を果たせない。果たすの
が難しい。で、どういう構造でビジネスに寄与するの？が大切なのにプラクティスに終始
しがち
• Be Agileという割には、Do Agileの話をよく見かける。本質が見えにくい。

本では制約や前提を整えてアジリティ高い状態に持っていく座組づくりについては触れられていない
制約や前提の存在しないコンテキスト 制約や前提のが大量に存在するコンテキスト
スモールチーム
アジャイルな状態
スモールチーム
アジャイルな状態
できない制約・前提
できない制約・前提
難しい制約・前提
難しい制約・前提
本に書いてある世界
前提の破壊の仕方
はあまり語られない

本では制約や前提を整えてアジリティ高い状態に持っていく座組づくりについては触れられていない
制約や前提の存在しないコンテキスト 制約や前提のが大量に存在するコンテキスト
スモールチーム
アジャイルな状態
スモールチーム
アジャイルな状態
できない制約・前提
できない制約・前提
難しい制約・前提本に書いてある世界
前提の破壊の仕方
はあまり語られない
達人「場合による」
難しい制約・前提
Be Agile

本では制約や前提を整えてアジリティ高い状態に持っていく座組づくりについては触れられていない
制約や前提の存在しないコンテキスト 制約や前提のが大量に存在するコンテキスト
スモールチーム
アジャイルな状態
スモールチーム
アジャイルな状態
できない制約・前提
できない制約・前提
難しい制約・前提本に書いてある世界
前提の破壊の仕方
はあまり語られない
難しい制約・前提
いやいや、こここそ大事でしょ
Be Agile

結論
自分の頭で考える
✓前提を意識する
✓眼の前の現実を起点に考える（べき論からはじめない）
✓振る舞いが安定してから名前を付ける
✓アウトカムにフォーカスする
✓決定を遅らせる

ビジネス構造の理解
大企業における既存事業の場合

既存事業におけるビジネス構造の理解

クライアント
様向け画面
アルバイト先を
探している人
アルバイトを
募集している企業
既存事業におけるビジネス構造の理解

クライアント
様向け画面
商品開発
サイト改善 サイト改善
求人情報に対するコンバージョンレートの向上
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

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

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

タウンワーク
FromA Navi
はたらいく
とらばーゆ
入稿システム
応募管理
システム

これを目の前にしたときに、それでも「正論」を言えるのか？
Be Agile
10

タウンワーク
FromA Navi
はたらいく
とらばーゆ
入稿システム
応募管理
システム
ここらへんは
アジリティ高くやる必要ある
10

検索条件
入力画面
検索結果
一覧画面
詳細画面 予約画面
口コミ
SEO
SEM
ETC
サービス
トップ
画面
if(isBooked){
}
口コミ
SEO
SEM
ETC
掲載枠検索
¥0
利用者 クライアント
広告
ビジネス
CVR改善 ＝ 売上直結
例：CVR最大化に向けたUI/UX仮説検証
流入数
10

検索条件
入力画面
検索結果
一覧画面
詳細画面 予約画面
口コミ
SEO
SEM
ETC
サービス
トップ
画面
if(isBooked){
}
口コミ
SEO
SEM
ETC
掲載枠検索
¥0
利用者 クライアント
CVR改善 ＝ 売上直結
タウンワークにおけるUI/UX仮説検証
流入数
アウトカム
アウトカム
掲載料
10

1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
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 week
0
0.75
1.5
2.25
3
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
複数のことをまとめて開発したときのビジネス上の実利
A
B
C
１つずつ開発してリリースしていくときのビジネス上の実利
10

複数のことをまとめて開発したときのビジネス上の実利
１つずつ開発してリリースしていくときのビジネス上の実利
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
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 week
0
0.75
1.5
2.25
3
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
A
B
C
学んでいない期間
稼いでいない期間
学んでいない期間
稼いでいない期間
オーバーヘッドで
若干合計稼働は増える
複数の実験を
同時にやると濁る
10

1つのリソースを稼働率が100%になるまで分配する
例
・マルチタスク
・大きなウォーターフォール型開発
A B C
Resource
流れる対象
30%
30% 40%
リソース稼働率：100%
(作業時間を絞り出す量を最大化)
1リソースに
フォーカスする
流れる対象 流れる対象
リソース効率性
10

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

リソース効率性とフロー効率性
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

1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
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 week
0
0.75
1.5
2.25
3
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
リソース効率を重視して開発した場合
A
B
C
フロー効率を重視して開発した場合

リソース効率
フロー効率
リソース効率とフロー効率の関係
High
HighLow
Low
Variation
一度に沢山
SoR
一個ずつ
SoE
小規模・仮説検証
大規模開発
我々
This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix -

自治権を持ったスモールチームを
作るために予算ポートフォリオ毎
にチームを分ける
大企業における既存事業の場合

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

マーケ組織 商品企画組織 営業組織 データ系組織
プロダクト開発組織
プロダクトオーナー
プロジェクト(WF) スクラム or カンバン スクラム or カンバン
アーキテクト
プロダクトオーナー
プロキシー
プロダクトオーナー
プロキシー
プロジェクトリーダー
スクラムマスター
○○○○○
XXXXXX
△△△△△
○○○○○
プロダクトオーナー
プロキシー
○○○○○
XXXXXX
△△△△△
○○○○○
○○○○○
XXXXXX
△△△△△
○○○○○
エンジニア
エンジニア
エンジニア
：エンジニア x N人
UI/UXデザイナー
スクラムマスター
エンジニア
エンジニア
エンジニア
：
SoR SoE SoE
カンバン
○○○○○
XXXXXX
△△△△△
○○○○○
エンジニア
エンジニア
エンジニア
：
安定稼働、アーキ
(組織的ゆとり)
グロースハックチーム商品開発チーム

障害対応/SRE
マーケ・プロモ
法令・要請
商品開発(掲載枠等)
グロースハック
（UI/UX改善）
4月 7月 10月 1月
予算
Time
投資ポートフォリオとエンジニアチーム構成の関係
年次の予算計画
1年分の活動予算

障害対応/SRE
マーケ・プロモ
法令・要請
商品開発(掲載枠等)
グロースハック
（UI/UX改善）
4月 7月 10月 1月
予算
Time
投資ポートフォリオとエンジニアチーム構成の関係
責務：コンバージョン率UP
予算ロック & 納期柔軟
責務：売上 + α
予算ロック & 納期コミット
責務：安定稼働 + アーキテクト
予算ロック & 納期柔軟

障害対応/SRE
マーケ・プロモ
法令・要請
商品開発(掲載枠等)
グロースハック
（UI/UX改善）
4月 7月 10月 1月
予算
Time
投資ポートフォリオとエンジニアチーム構成の関係
責務：コンバージョン率UP
予算ロック & 納期柔軟
責務：売上 + α
予算ロック & 納期コミット
責務：安定稼働 + アーキテクト
予算ロック & 納期柔軟
グロースハックチーム
商品開発チーム
安定稼働チーム

障害対応/SRE
マーケ・プロモ
法令・要請
商品開発(掲載枠等)
グロースハック
（UI/UX改善）
4月 7月 10月 1月
予算
Time
投資ポートフォリオとエンジニアチーム構成の関係
責務：コンバージョン率UP
予算ロック & 納期柔軟
責務：売上 + α
予算ロック & 納期コミット
責務：安定稼働 + アーキテクト
予算ロック & 納期柔軟
グロースハックチーム
商品開発チーム
安定稼働チーム
調
整
ネ
ジ

障害対応/SRE
マーケ・プロモ
法令・要請
商品開発(掲載枠等)
グロースハック
（UI/UX改善）
4月 7月 10月 1月
予算
Time
投資ポートフォリオとエンジニアチーム構成の関係
責務：コンバージョン率UP
予算ロック & 納期柔軟
責務：売上 + α
予算ロック & 納期コミット
責務：安定稼働 + アーキテクト
予算ロック & 納期柔軟
グロースハックチーム
商品開発チーム
安定稼働チーム
予算枠 目的&責任
チーム
予算：目的：責任：チームが1対1の状態
投資側からすれば目
的が達成できればよ
いのでHOWは自由。
あとは任せた！
→チームに自治権
→現場裁量で推進
→精神論ではなく構
造的アプローチによ
る自己組織化

障害対応/SRE
マーケ・プロモ
法令・要請
商品開発(掲載枠等)
グロースハック
（UI/UX改善）
4月 7月 10月 1月
予算
Time
投資ポートフォリオとエンジニアチーム構成の関係
責務：コンバージョン率UP
予算ロック & 納期柔軟
責務：売上 + α
予算ロック & 納期コミット
責務：安定稼働 + アーキテクト
予算ロック & 納期柔軟
グロースハックチーム
商品開発チーム
安定稼働チーム
予算枠 目的&責任
チーム アーキテクチャ
（余談）マイクロサービス
予算：目的：責任：チームが1対1の状態

障害対応/SRE
マーケ・プロモ
法令・要請
商品開発(掲載枠等)
グロースハック
（UI/UX改善）
4月 7月 10月 1月
予算
Time
投資ポートフォリオとエンジニアチーム構成の関係
責務：コンバージョン率UP
予算ロック & 納期柔軟
責務：売上 + α
予算ロック & 納期コミット
責務：安定稼働 + アーキテクト
予算ロック & 納期柔軟
グロースハックチーム
商品開発チーム
安定稼働チーム
予算枠 目的&責任
チーム
予算：目的：責任：チームが1対1の状態
予算枠 目的&責任
チーム
予算枠
目的&責任
チーム

障害対応/SRE
マーケ・プロモ
法令・要請
商品開発(掲載枠等)
グロースハック
（UI/UX改善）
4月 7月 10月 1月
予算
Time
投資ポートフォリオとエンジニアチーム構成の関係
予算枠
目的① チーム
例えば、予算枠とチームが目的単位でない場合
目的②
投資目的が混ざるの
で、優先順位付けにお
いて、一つ上位レイ
ヤーの意思決定お伺い
が発生するかもしれな
い。
→現場で決めれない
→現場に自治権がない

障害対応/SRE
マーケ・プロモ
法令・要請
商品開発(掲載枠等)
グロースハック
（UI/UX改善）
4月 7月 10月 1月
予算
Time
投資ポートフォリオとエンジニアチーム構成の関係
責務：コンバージョン率UP
予算ロック & 納期柔軟
責務：売上 + α
予算ロック & 納期コミット
責務：安定稼働 + アーキテクト
予算ロック & 納期柔軟
グロースハックチーム
商品開発チーム
安定稼働チーム
=>フロー効率重視
=>リソース効率重視
=>組織的「ゆとり」

障害対応/SRE
マーケ・プロモ
法令・要請
商品開発(掲載枠等)
グロースハック
（UI/UX改善）
4月 7月 10月 1月
予算
Time
投資ポートフォリオとエンジニアチーム構成の関係
責務：コンバージョン率UP
予算ロック & 納期柔軟
責務：売上 + α
予算ロック & 納期コミット
責務：安定稼働 + アーキテクト
予算ロック & 納期柔軟
グロースハックチーム
商品開発チーム
安定稼働チーム
=>フロー効率重視
=>リソース効率重視
=>組織的「ゆとり」

リソース効率
フロー効率
High
HighLow
Low
Variation
目指す場所
組織的ゆとり枠でリソース効率とフロー効率の両面張り
納期コミット業務を持っていないため、
ニーズ発生時にJUST IN TIMEでアサインできる
納期コミットしていない改善系
業務、アーキテクト系業務を普
段行うので高稼働率を維持。
意図的に納期コミットしない仕
事をさせている。
開発現場に発生するボラティリティに組織の「ゆとり」で対応する

障害対応/SRE
マーケ・プロモ
法令・要請
商品開発(掲載枠等)
グロースハック
（UI/UX改善）
4月 7月 10月 1月
予算
Time
投資ポートフォリオとエンジニアチーム構成の関係
責務：コンバージョン率UP
予算ロック & 納期柔軟
責務：売上 + α
予算ロック & 納期コミット
責務：安定稼働 + アーキテクト
予算ロック & 納期柔軟
グロースハックチーム
商品開発チーム
安定稼働チーム
=>フロー効率重視
=>リソース効率重視
=>組織的「ゆとり」
複数のことをまとめてV字
モデルでやる
（ウォーターフォール？）
一個ずつV字モデルでやる
（アジャイル？カンバン？
スクラム？それ系のやつ）
「ゆとり」を投資して効率
化で「ゆとり」をつくる

マーケ組織 商品企画組織 営業組織 データ系組織
プロダクト開発組織
プロダクトオーナー
プロジェクト(WF) スクラム or カンバン スクラム or カンバン
アーキテクト
プロダクトオーナー
プロキシー
プロダクトオーナー
プロキシー
プロジェクトリーダー
スクラムマスター
○○○○○
XXXXXX
△△△△△
○○○○○
プロダクトオーナー
プロキシー
○○○○○
XXXXXX
△△△△△
○○○○○
○○○○○
XXXXXX
△△△△△
○○○○○
エンジニア
エンジニア
エンジニア
：エンジニア x N人
UI/UXデザイナー
スクラムマスター
エンジニア
エンジニア
エンジニア
：
リソース効率 フロー効率 フロー効率
カンバン
○○○○○
XXXXXX
△△△△△
○○○○○
エンジニア
エンジニア
エンジニア
：
安定稼働、アーキ
(組織的ゆとり)
グロースハックチーム商品開発チーム

スモールチーム
アジャイルな状態
できない制約・前提
できない制約・前提
難しい制約・前提
難しい制約・前提
結果的に特定の数値に責任と権限を持ったスモールチームになる
ここからが本に書いてある世界
ここからアジャイルコーチ的な人の出番？
ここまで座組を整えないと、ただ現場でもがくだけになり非効率
SoEを対象とする
根雪構造でビジネス
成果が積み上がる部分を
スコープとする
予算と目的と責任と権限
とチームを1:1にして、
チームに自治権を与える

スモールチーム
アジャイルな状態
できない制約・前提
できない制約・前提
難しい制約・前提
難しい制約・前提
結果的に特定の数値に責任と権限を持ったスモールチームになる
ここからが本に書いてある世界
ここからアジャイルコーチ的な人の出番？
ここまで座組を整えないと、ただ現場でもがくだけになり非効率
SoEを対象とする
根雪構造でビジネス
成果が積み上がる部分を
スコープとする
予算と目的と責任と権限
とチームを1:1にして、
チームに自治権を与える
あとはアジリティ高めで
V字モデルをやるだけ

ビジネス上の目的に合わせて開
発プロセスをチューニングする
大企業における既存事業の場合
20

1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
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 week
0
0.75
1.5
2.25
3
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
ビジネス価値とリソース効率性重視の開発スタイル
A
B
C
ビジネス価値とフロー効率性重視の開発スタイル
20

1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
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 week
0
0.75
1.5
2.25
3
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
ビジネス価値とリソース効率性重視の開発スタイル
A
B
C
ビジネス価値とフロー効率性重視の開発スタイル
1個ずつV字モデル開発
複数まとめてV字モデル開発
20

1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
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 week
0
0.75
1.5
2.25
3
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
ビジネス価値とリソース効率性重視の開発スタイル
A
B
C
ビジネス価値とフロー効率性重視の開発スタイル
リードタイム
リードタイム
20

1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
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 week
A
B
C
バックエンド
エンジニア
フロント
エンジニア
プロダクト
オーナー
顧客
+1
承認レビュー
仕様確認
API開発 API開発
Front開発
デプロイ待ち 待ち待ち
テスト
テスト
ビジネス価値とフロー効率性重視の開発スタイル
20

1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
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 week
A
B
C
バックエンド
エンジニア
フロント
エンジニア
プロダクト
オーナー
顧客
+1
承認レビュー
仕様確認
API開発 API開発
Front開発
デプロイ待ち 待ち待ち
テスト
テスト
ビジネス価値とフロー効率性重視の開発スタイル
リードタイム
リードタイム短縮
エンジニアリングによってLTを短縮したい 20

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

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

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

DevelopmentPlanning Design Measure
Ph.1 Ph.2 Ready会 SprintDesign AB Testing
工程別
滞留数
(在庫数)
工程別
スルー
プット 4個/2週 3個/2週 3個/2週 4個/2週 1個/2週 4個/2週
Ready状態の在庫を作る
スループット
在庫を出荷する
スループット
在
庫
量
推
移
① ②
③
① ②
リードタイム
③
③=①-②
=在庫量
Ready化数 リリース数累積フロー図
未着手案件の在庫推移を可視化し組織生産性の可視化

DevelopmentPlanning Design Measure
Ph.1 Ph.2 Ready会 SprintDesign AB Testing
工程別
滞留数
(在庫数)
工程別
スルー
プット 4個/2週 3個/2週 3個/2週 4個/2週 1個/2週 4個/2週
Ready状態の在庫を作る
スループット
在庫を出荷する
スループット
在
庫
量
推
移
① ②
③
③①
②
Ready化数 リリース数
Readyにした数とリリースした数 在庫数推移
未着手案件の在庫推移を可視化し組織生産性の可視化

ビジネス構造の理解
大企業における新規事業の場合

新規事業＝アジャイルでやるべきというのは思考停止
大企業という文脈においては新規事業＝アジャイルでやる
「べき」というのはある種の思考停止ではある。
参入市場や事業の登り方に合わせた開発スタイルを選ぶこ
とが大切。

参入市場 戦略 プロダクト要件 競争種別 開発スタイル 開発体制
新規市場 オーソドックスな
顧客開発
作るものがわからな
い
競争なし 探索型 柔軟さに特化した開
発体制
既存市場 競合と戦う
・フォロワー戦略
・同質化戦略
作るものが明確
当たり前品質の期待
値高い
競合で実証された機
能の実装
性能競争になる
ため、経営資源
の投下量勝負に
なる
（経営のコミッ
ト大事）
競合劣位解消の
ための機能開発
を計画的になり
やすい
高品質
高機能
計画駆動に特化した
開発体制で、いっき
に全部盛りを作った
ほうが効率が良い
既存市場 競合と戦わない
市場の再セグメント化
・ニッチ化(例:サカゼン)
・低コスト化(例:LCC)
からの顧客開発
作るものがうっすら
みえている
競争なし
競争あっても勝
者はいない
探索型 柔軟さに特化した開
発体制
クローン
市場
コピーキャット 作るものが明確 競争なし 機能を計画的に 計画駆動に特化した
開発体制
参入市場におけるビジネス不確実性と開発スタイル

参入市場 戦略 プロダクト要件 競争種別 開発スタイル 開発体制
新規市場 オーソドックスな
顧客開発
作るものがわからな
い
競争なし 探索型 柔軟さに特化した開
発体制
既存市場 競合と戦う
・フォロワー戦略
・同質化戦略
作るものが明確
当たり前品質の期待
値高い
競合で実証された機
能の実装
性能競争になる
ため、経営資源
の投下量勝負に
なる
（経営のコミッ
ト大事）
競合劣位解消の
ための機能開発
を計画的になり
やすい
高品質
高機能
計画駆動に特化した
開発体制で、いっき
に全部盛りを作った
ほうが効率が良い
既存市場 競合と戦わない
市場の再セグメント化
・ニッチ化(例:サカゼン)
・低コスト化(例:LCC)
からの顧客開発
作るものがうっすら
みえている
競争なし
競争あっても勝
者はいない
探索型 柔軟さに特化した開
発体制
クローン
市場
コピーキャット 作るものが明確 競争なし 機能を計画的に 計画駆動に特化した
開発体制
参入市場におけるビジネス不確実性と開発スタイル
大きな企業はこの戦い方が多い

参入市場 戦略 プロダクト要件 競争種別 開発スタイル 開発体制
新規市場 オーソドックスな
顧客開発
作るものがわからな
い
競争なし 探索型 柔軟さに特化した開
発体制
既存市場 競合と戦う
・フォロワー戦略
・同質化戦略
作るものが明確
当たり前品質の期待
値高い
競合で実証された機
能の実装
性能競争になる
ため、経営資源
の投下量勝負に
なる
（経営のコミッ
ト大事）
競合劣位解消の
ための機能開発
を計画的になり
やすい
高品質
高機能
計画駆動に特化した
開発体制で、いっき
に全部盛りを作った
ほうが効率が良い
既存市場 競合と戦わない
市場の再セグメント化
・ニッチ化(例:サカゼン)
・低コスト化(例:LCC)
からの顧客開発
作るものがうっすら
みえている
競争なし
競争あっても勝
者はいない
探索型 柔軟さに特化した開
発体制
クローン
市場
コピーキャット 作るものが明確 競争なし 機能を計画的に 計画駆動に特化した
開発体制
参入市場におけるビジネス不確実性と開発スタイル
大きな企業はこの戦い方が多い
1個ずつV字モデル開発
複数まとめてV字モデル開発
1個ずつV字モデル開発
複数まとめてV字モデル開発

不確実性をちょっと分解してみる
高 × 高 低 × 高
低 × 低高 × 低
技術不確実性
ビ
ジ
ネ
ス
不
確
実
性
高い
高
い
低
い
低い

不確実性
大
不確実性
中
不確実性
小
正しいものを探索する
（作る対象の不確実性）
正しいものを正しくつくる
（作り方の不確実性）
正しくつくる
正しいもの
原型
不確実性の推移（不確実性のコーン）
こっから始まる場合もあれば
こっから始まる場合もある

組織力学
大企業は新規事業において間違った力学が発生しがち
大企業における新規事業の場合

ビジネスや開発における判断でどんな力学が発生して最終的に現場で何が
起こるかまで可能な限り想像力を張り巡らさないとならない。そして、こ
の想像力において、どれだけ解像度を高くできるかこそが現場感。経験が
ないと何がおこるか想像すら出来ない。

参入市場 戦略 プロダクト要件 競争種別 開発スタイル 開発体制
新規市場 オーソドックスな
顧客開発
作るものがわからな
い
競争なし 探索型 柔軟さに特化した開
発体制
既存市場 競合と戦う
・フォロワー戦略
・同質化戦略
作るものが明確
当たり前品質の期待
値高い
競合で実証された機
能の実装
性能競争になる
ため、経営資源
の投下量勝負に
なる
（経営のコミッ
ト大事）
競合劣位解消の
ための機能開発
を計画的になり
やすい
高品質
高機能
計画駆動に特化した
開発体制で、いっき
に全部盛りを作った
ほうが効率が良い
既存市場 競合と戦わない
市場の再セグメント化
・ニッチ化(例:サカゼン)
・低コスト化(例:LCC)
からの顧客開発
作るものがうっすら
みえている
競争なし
競争あっても勝
者はいない
探索型 柔軟さに特化した開
発体制
クローン
市場
コピーキャット 作るものが明確 競争なし 機能を計画的に 計画駆動に特化した
開発体制
参入市場におけるビジネス不確実性と開発スタイル

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

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

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

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

Problem/Solution
Fit
Product/Market
Fit Scaling
Retention CAC < LTV 売上
課題解決可能
な最小限
売り方最適化 / 売上最大化売る
アップセル/クロスセルに向けた性能品質
指標値例
検証アク
ション
検証
ポイント
MVP
目標
MVP作って検証
最低限売れる
当たり前品質
独自な価値提供を出来ているか
深い課題を抱えた顧客がいるか
その課題の解決策は妥当か
独自な価値提供を出来ているか
顧客は本当に買ってくれるか
コスト構造に無理がないか
売り物（プロダクト）を磨くフェーズ
独自な価値提供を出来ているか
最適な売り方の検証
最適な価格設定の検証
導入期 成長期 成熟期
利益
独自な価値提供を出来ているか
CPA最適化
マーケットシェア
キードライバー値
最大化
利益最大化
ビジネス
フェーズ
バケツの水漏れを塞ぐ バケツに水を流す バケツに流す水を増やす
売り方を磨くフェーズ
30

社内新規事業のアーリーステージにおいて
過度な売上目標をチームに持たせようとした場合
（アジャイルぽくやろうとして
結果的に重厚長大な計画駆動開発になっていく流れ）
30

Problem/Solution
Fit
Product/Market
Fit Scaling
Retention CAC < LTV 売上
課題解決可能
な最小限
売り方最適化 / 売上最大化売る
アップセル/クロスセルに向けた性能品質
指標値例
検証アク
ション
検証
ポイント
MVP
目標
MVP作って検証
最低限売れる
当たり前品質
独自な価値提供を出来ているか
深い課題を抱えた顧客がいるか
その課題の解決策は妥当か
独自な価値提供を出来ているか
顧客は本当に買ってくれるか
コスト構造に無理がないか
売り物（プロダクト）を磨くフェーズ
独自な価値提供を出来ているか
最適な売り方の検証
最適な価格設定の検証
導入期 成長期 成熟期
利益
独自な価値提供を出来ているか
CPA最適化
マーケットシェア
キードライバー値
最大化
利益最大化
ビジネス
フェーズ
バケツの水漏れを塞ぐ バケツに水を流す バケツに流す水を増やす
売り方を磨くフェーズ
toC向け
新規サービス
30

Problem/Solution
Fit
Product/Market
Fit Scaling
CAC < LTV 売上
課題解決可能
な最小限
売り方最適化 / 売上最大化売る
アップセル/クロスセルに向けた性能品質
指標値例
検証アク
ション
検証
ポイント
MVP
目標
MVP作って検証
最低限売れる
当たり前品質
独自な価値提供を出来ているか
深い課題を抱えた顧客がいるか
その課題の解決策は妥当か
独自な価値提供を出来ているか
顧客は本当に買ってくれるか
コスト構造に無理がないか
売り物（プロダクト）を磨くフェーズ
独自な価値提供を出来ているか
最適な売り方の検証
最適な価格設定の検証
導入期 成長期 成熟期
利益
独自な価値提供を出来ているか
CPA最適化
マーケットシェア
キードライバー値
最大化
利益最大化
ビジネス
フェーズ
バケツの水漏れを塞ぐ バケツに水を流す バケツに流す水を増やす
売り方を磨くフェーズ
売上目標の圧
デカい売上はよ
Retention
toC向け
新規サービス
事業成長を加速させ
るために強めの売上
目標をもたせよう！
30

Problem/Solution
Fit
Product/Market
Fit Scaling
売上CAC < LTV
課題解決可能
な最小限
売り方最適化 / 売上最大化売る
アップセル/クロスセルに向けた性能品質
指標値例
検証アク
ション
検証
ポイント
MVP
目標
MVP作って検証
最低限売れる
当たり前品質
独自な価値提供を出来ているか
深い課題を抱えた顧客がいるか
その課題の解決策は妥当か
独自な価値提供を出来ているか
顧客は本当に買ってくれるか
コスト構造に無理がないか
売り物（プロダクト）を磨くフェーズ
独自な価値提供を出来ているか
最適な売り方の検証
最適な価格設定の検証
導入期 成長期 成熟期
利益
独自な価値提供を出来ているか
CPA最適化
マーケットシェア
キードライバー値
最大化
利益最大化
ビジネス
フェーズ
バケツの水漏れを塞ぐ バケツに水を流す バケツに流す水を増やす
売り方を磨くフェーズ
売上目標の圧
デカい売上はよ
Retention
顧客単価の高いtoB
サービスにしたくなる
toC向け
新規サービス
30

Problem/Solution
Fit
Product/Market
Fit Scaling
売上CAC < LTV
課題解決可能
な最小限
売り方最適化 / 売上最大化売る
アップセル/クロスセルに向けた性能品質
指標値例
検証アク
ション
検証
ポイント
MVP
目標
MVP作って検証
最低限売れる
当たり前品質
独自な価値提供を出来ているか
深い課題を抱えた顧客がいるか
その課題の解決策は妥当か
独自な価値提供を出来ているか
顧客は本当に買ってくれるか
コスト構造に無理がないか
売り物（プロダクト）を磨くフェーズ
独自な価値提供を出来ているか
最適な売り方の検証
最適な価格設定の検証
導入期 成長期 成熟期
利益
独自な価値提供を出来ているか
CPA最適化
マーケットシェア
キードライバー値
最大化
利益最大化
ビジネス
フェーズ
バケツの水漏れを塞ぐ バケツに水を流す バケツに流す水を増やす
売り方を磨くフェーズ
売上目標の圧
デカい売上はよ
Retention
顧客単価の高いtoB
サービスにしたくなる
toC向け
新規サービス
実際は・・・
toC向けの実験レベル
のプロダクト品質
ただし、このまま
売っても、全く売れ
ない・・・
30

Problem/Solution
Fit
Product/Market
Fit Scaling
売上CAC < LTV
課題解決可能
な最小限
売り方最適化 / 売上最大化売る
アップセル/クロスセルに向けた性能品質
指標値例
検証アク
ション
検証
ポイント
MVP
目標
MVP作って検証
最低限売れる
当たり前品質
独自な価値提供を出来ているか
深い課題を抱えた顧客がいるか
その課題の解決策は妥当か
独自な価値提供を出来ているか
顧客は本当に買ってくれるか
コスト構造に無理がないか
売り物（プロダクト）を磨くフェーズ
独自な価値提供を出来ているか
最適な売り方の検証
最適な価格設定の検証
導入期 成長期 成熟期
利益
独自な価値提供を出来ているか
CPA最適化
マーケットシェア
キードライバー値
最大化
利益最大化
ビジネス
フェーズ
バケツの水漏れを塞ぐ バケツに水を流す バケツに流す水を増やす
売り方を磨くフェーズ
売上目標の圧
デカい売上はよ
Retention
顧客単価の高いtoB
サービスにしたくなる
toB向け機能が必要に
なる。要件も高品質高
性能になる。
toC向け
新規サービス
実際は・・・
toC向けの実験レベル
のプロダクト品質

Problem/Solution
Fit
Product/Market
Fit Scaling
売上CAC < LTV
課題解決可能
な最小限
売り方最適化 / 売上最大化売る
アップセル/クロスセルに向けた性能品質
指標値例
検証アク
ション
検証
ポイント
MVP
目標
MVP作って検証
最低限売れる
当たり前品質
独自な価値提供を出来ているか
深い課題を抱えた顧客がいるか
その課題の解決策は妥当か
独自な価値提供を出来ているか
顧客は本当に買ってくれるか
コスト構造に無理がないか
売り物（プロダクト）を磨くフェーズ
独自な価値提供を出来ているか
最適な売り方の検証
最適な価格設定の検証
導入期 成長期 成熟期
利益
独自な価値提供を出来ているか
CPA最適化
マーケットシェア
キードライバー値
最大化
利益最大化
ビジネス
フェーズ
バケツの水漏れを塞ぐ バケツに水を流す バケツに流す水を増やす
売り方を磨くフェーズ
売上目標の圧
デカい売上はよ
Retention
顧客単価の高いtoB
サービスにしたくなる
toB向け機能が必要に
なる。要件も高品質高
性能になる。
toC向け
新規サービス
実際は・・・
toC向けの実験レベル
のプロダクト品質
売上計画から逆算した
計画駆動開発が始まる
（かもしれない）

売れるために、
ちょっとこの機能を
増やしたいんだけど
計画どおり作らねばなら
ないので、変更は受け付
けません！
開発「側」は計画通り作り上げることが目標になり、柔軟な変更を弾き返すようになります。
プランニング「側」は目標に向けた計画を遂行したいがために、仕様を押し込みたくなるし、開発「側」はそれをディ
フェンスしたくなる。ギスギスしだす。
開発「側」は「仕様が決まってないので作れません」となる。更に開発「側」は計画を守るために、バッファを計画
上にたくさん盛り込みだす。つまりは、やれることをバッファ分だけ自ら減らしていく構造を作り上げる。そして、
基本的にバッファは使い切ってリリースを迎えることになる。結果的に自分たちのできる総量を、自ら低下させ成長
をスローダウンさせていくことになる。（パーキンソンの法則：バッファはあるだけ使い果たす）
（感じ悪いなあ・・）
（計画どおりやれって
いってんのお前だろ）
（計画達成するために、
バッファいっぱい積んで
おこう）
開発「側」 プランニング「側」
←目的がすり替わる（）

Problem/Solution
Fit
Product/Market
Fit Scaling
CAC < LTV 売上
課題解決可能
な最小限
売り方最適化 / 売上最大化売る
アップセル/クロスセルに向けた性能品質
指標値例
検証アク
ション
検証
ポイント
MVP
目標
MVP作って検証
最低限売れる
当たり前品質
独自な価値提供を出来ているか
深い課題を抱えた顧客がいるか
その課題の解決策は妥当か
独自な価値提供を出来ているか
顧客は本当に買ってくれるか
コスト構造に無理がないか
売り物（プロダクト）を磨くフェーズ
独自な価値提供を出来ているか
最適な売り方の検証
最適な価格設定の検証
導入期 成長期 成熟期
利益
独自な価値提供を出来ているか
CPA最適化
マーケットシェア
キードライバー値
最大化
利益最大化
ビジネス
フェーズ
バケツの水漏れを塞ぐ バケツに水を流す バケツに流す水を増やす
売り方を磨くフェーズ
売上目標の圧
デカい売上はよ
Retention
toC向け
新規サービス
事業成長を加速させ
るために強めの売上
目標をもたせよう！
終わりの
はじまり

ビジネスにおける意思決定で発生したフォースは徐々に伝搬し、最終的にエンジニア
の現場に流れ込んできます。このフォースがどのように伝搬してくるかを見る能力が
とても大事であり、これが無いと、本来、事業を加速させようとした意思決定も現
場に伝わるころには、まったく逆のフォースを発生させてしまい、スピード感を失っ
たディフェンシブなものにすり替わってしまったりします。

フォースの流れを読み、
それを間接的にコントロールすることが重要

アジリティ高くやるために、社内のとある新規事業開発でプロダクトの役員と握ったスライド

アジリティ高くやるために、社内のとある新規事業開発でプロダクトの役員と握ったスライド

スモールチーム
アジャイルな状態
できない制約・前提
できない制約・前提
難しい制約・前提
難しい制約・前提
アーリーステージで
売上目標を持たせない
ステージゲート等で、
ビジネスフェーズにあった
予算への説明責任
アーリーステージにおける
納期コミットは、出来ることを
逆に減らすことになる
結果的にフェーズに合わせた目標を持ったスモールチームになる
ここからが本に書いてある世界。
ここからアジャイルコーチ的な人の出番？
ここまで座組を整えないと、ただ現場でもがくだけになり非効率

スモールチーム
アジャイルな状態
できない制約・前提
できない制約・前提
難しい制約・前提
難しい制約・前提
アーリーステージで
売上目標を持たせない
ステージゲート等で、
ビジネスフェーズにあった
予算への説明責任
アーリーステージにおける
納期コミットは、出来ることを
逆に減らすことになる
結果的にフェーズに合わせた目標を持ったスモールチームになる
ここからが本に書いてある世界。
ここからアジャイルコーチ的な人の出番？
ここまで座組を整えないと、ただ現場でもがくだけになり非効率
あとは顧客開発やリーンス
タートアップすればよい

前提を意識する
自分の頭で考える

うまく行っている仕組み、取り組み、文化、制度にはそれが成立する前提があるが、意外にそこは共有され
ていないものである。
しかしながら、その前提こそが大切であり、その前提を作り上げている構造を理解して初めて本質的な座組
を作ることができるようになる。
色々な先進的な事例
・Joy incやモブプロで有名なハンター社の文化を成立させている前提条件はなんだろうか？
・Web系企業のエンジニア文化が重宝されるのはなぜだろうか？
ビジネスモデルは？成長のエンジンはエンジニア or 営業？上場していないから？
雇用形態が日本と違うから？終身雇用でも成立する？人事制度は？
表面の心地よい部分のみを見てしまい、憧れで終わってしまうのは思考停止。それが成立している前提条件
を自分の頭で構造として捉えることが大事。それをクリアしてるのであれば、やるだけ。
エンジニアなのであれば、構造として捉えることが得意であるはずで、
構造を把握できれば、コントロール出来るので、さあ、あとはやるだけだ。
前提を意識する

前提を意識する
例えば、前述のタウンワークのスループット最大化の取り組みは以下の条件だから成立してたので、そこらへんすっ
飛ばしてHOWのみフォーカスしコピーすると、○○プラクティスはクソみたいな感じになりがち。で、自分たちのミ
スによってその手法論は（笑）化していく。それにより、その組織内においての○○プラクティスという名前は死ぬ。
以下が前提と言われているやつ。もしくは、
「場合による」と回答されるときの「場合」。
✓事業のキードライバーが明確になっていること
✓キードライバーをグロースさせるための案件を継続的に用意
できること
✓案件のサイズにブレが少ないこと
✓目的に対して体制がロックされていること
✓ビジネス効果が根雪構造的に生まれるもの
この背後に隠れた条件を見抜く力が必要であり、
自分の頭で考える部分。

眼の前の現実を起点に考える
（べき論からはじめない）
振る舞いが安定してから
名前を付ける
自分の頭で考える

名前が先にあると強引に合わせにいってしまう。
現実を歪めて型に当てはめにいってしまう。
現実を起点に考える/ 振る舞いが安定してから名前を付ける

例えば参考書から、自分たちの中には存在しないプロダクトオーナーを作り上げると、ロール名あり
きで進みロール名と役割の話ばかりになる。守破離の守だと言われたらそれまでだが、
眼の前の現実から考えていなくて、一足飛びにべき論をベースにしているため、何か違和感を感じる。
そして、「プロダクトオーナーの役割定義とは？」みたいな役割の議論に終
始してしまう。これは本質的ではない。そんな議論するくらいならはやくリリースしたほうがいいし、バグ
を一つでも治したほうがいい。
動きが良い人がいたときに、その動き永続化するためにロール名を付与したほ
うが現場感がある。
「○○さんの動きかたをプロダクトオーナーとしましょう」とか。
現実を起点に考える/ 振る舞いが安定してから名前を付ける

POの例は極端ではあるが、
ポイントとしては振る舞いが明確になるまで、命名はしない。
（まずは無名関数としてあつかう。by @bash0C7）
組織としてその機能をスケールさせたくなったら命名する。
組織名も同じ。
現実を起点に考える/ 振る舞いが安定してから名前を付ける

組織構造を先にいじるか、あとから組織構造をいじるか
結果的にうまくいったことを永続化するために、組織の形に落とし込む。
例えば、ネットワーク構造の文化になったものを意図的に永続化させるために大部
屋化とか。
兆しがない状態、組織がReadyじゃない状態でいきなりやっても混乱まねくだけで
あり組織が壊れる。
つまりは、いきなり型を当てはめに行くのではなく、結果的にその状態になってい
るようにする。
結果的になったその状態を固定化しスケールさせるために、組織化する。組織に名
前をつける
現実を起点に考える/ 振る舞いが安定してから名前を付ける

アウトカムに
フォーカスする
自分の頭で考える

“How Much”どれだけ多くできるかが価値。
制約を前提として、まとめてたくさんのことをやると
きのバイアス。リソース効率性のパラダイムが強い。
or
“How Little”どれだけ細かく刻めるかを考えると変化に強くなる。
どれだけ小さく価値提供できるか。フロー効率性のパ
ラダイムが強い。
リソース効率
フロー効率
High
HighLow
Low
Variation
我々
目指す場所どう登る？
こっち？
ビジネス文脈でどの価値観でやるかを考えるのが大事

1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
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 week
0
0.75
1.5
2.25
3
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
ビジネス価値とリソース効率性重視の開発スタイル
A
B
C
ビジネス価値とフロー効率性重視の開発スタイル

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

決断を遅らせる
自分の頭で考える

不確実性
大
不確実性
中
不確実性
小
正しいものを探索する
（作る対象の不確実性）
正しいものを正しくつくる
（作り方の不確実性）
正しくつくる
正しいもの
原型
不確実性に対してどう対応していくのか

不確実性
大
不確実性
中
不確実性
小
正しいものを探索する
（作る対象の不確実性）
正しいものを正しくつくる
（作り方の不確実性）
正しくつくる
正しいもの
原型
ポイントベース(最初に決定、うまく行けば最小コスト)
・うまくいけば最短LT最小コストで走れる
・変更が入る度に手戻りが発生し、リードタイムが伸びる
・変更が入る度にコストがかかる
例：年次法改正対応のような確定している要件
あ、違った最初に決定
また違った

不確実性
大
不確実性
中
不確実性
小
正しいものを探索する
（作る対象の不確実性）
正しいものを正しくつくる
（作り方の不確実性）
正しくつくる
正しいもの
原型
判
断
ポ
イ
ン
ト
判
断
セットベース（決定を遅らせ手戻りを最小化）
・情報がそろうまで決定をおくらせる
・複数案並走させることでコストかかる
・複数案走ることで手戻りを無くしリードタイムを最短にする
例：リスクがあるアーキテクチャ候補の並走検討

不確実性
大
不確実性
中
不確実性
小
正しいものを探索する
（作る対象の不確実性）
正しいものを正しくつくる
（作り方の不確実性）
正しくつくる
正しいもの
原型
判
断
ポ
イ
ン
ト
判
断
セットベース（決定を遅らせ手戻りを最小化）
・情報がそろうまで決定をおくらせる
・複数案並走させることでコストかかる
・複数案走ることで手戻りを無くしリードタイムを最短にする
例：リスクがあるアーキテクチャ候補の並走検討
オフショア
国内
国内
オフショア
オフショア

結論
自分の頭で考える
✓前提を意識する
✓眼の前の現実を起点に考える（べき論からはじめない）
✓振る舞いが安定してから名前を付ける
✓アウトカムにフォーカスする
✓決定を遅らせる