事業が対峙する現実からエンジニアリングを俯瞰する #devlove

新規事業が対峙
する現実から
エンジニアリン
グを俯瞰する
リクルートテクノロジーズ
黒田　樹 @i2key
DevLOVE200 Bridge

文脈により事情は大きく変わると思うので、
正解はないと思います。
考え方の取っ掛かりにしていただければ。
※注意
想定読者
・ビジネスに対峙するエンジニアリーダー的な人
・ビジネスに価値貢献するとか、価値を作るといいつつ、
それ以上具体的に言語化できない人
・よかれと思う改善提案がビジネス側の理解を得られず悶々
としている人
・各種方法論(リーンスタートアップ、スクラム、etc)の説明
はしません。実践者対象です。
・ニッチ向け。

越境の契機
見えてきた勘所
現場に還る

エンジニアリングビジネス
PBL
リリー
ス
プランニ
ング
振り返り
MTG
レビュー
デイリー
MTG
Sprint/2weeks 開発タスク/Day
僕の考えた最強
の機能リスト

PBL
リリー
ス
プランニ
ング
振り返り
MTG
レビュー
デイリー
MTG
【あるある】
・プロダクトオーナーが施策のコスト責任を終えていない
・各施策単位で効果測定が出来ていない（やりっぱなし
・各施策単位での費用対効果の説明責任を果たせない
僕の考えた最強
の機能リスト
PBLの質、超重要。
（やる必然性・エビデンスの有無）
どんなに開発チームがスペシャルでも、チームに　　をインプットすると
結局、価値をうまない　　がチームからアウトプットされる
ボトルネックが
開発→ビジネスへ遷移

PBL
リリー
ス
プランニ
ング
振り返り
MTG
レビュー
デイリー
MTG
計測
構築
学習
デー
タ
アイ
デア
ビジネス
仮説リスト
全部、思い込みだと前提におく
思い込みにより発生する各種ムダを
省くためにリーンにやる
http://www.slideshare.net/i2key/45-developers-summit-2015-devsumi-devsumib
http://www.slideshare.net/i2key/devsumi-natsumic7
※(元)僕の考えた
最強の機能リスト

従来の
プロダクトバックログ
仮説検証型の
プロダクトバックログ
・仮説A検証用モック作成
・仮説B検証用ダミーボタン実装
・検証済み○○機能本実装
・検証済み○○機能本実装
・リファラル向上改善
・登録ファネル改善
・計測基盤実装
・コホートに対するプッシュ実装
・○○機能実装
わざわざ開発せずに
インタビューやエンジニアリング以外で検証できそう
根拠無し
根拠無し
根拠無し
事前検証
(エビデンス収集)
実証後の実装

国内x企業内新規事業→海外xスタートアップ
出資先海外スタートアップ
の日本市場グロース支援
www.slideshare.net/i2key/bp-leanstartup/42

NINTENDOの国から
やってきた男として
やってみせる
デブサミ2011【18-B-1】
プログラマが知るべき、たったひとつの大事なことがら
@t_wada 氏（現、弊社技術顧問氏）の原体験
https://www.slideshare.net/t_wada/the-only-
one-big-thing-every-programmer-should-know

エンジニアリング
ビジネス
PBL
リリー
ス
プランニ
ング
振り返り
MTG
レビュー
デイリー
MTG
計測
構築
学習
デー
タ
アイ
デア
ビジネス
仮説リスト
セールス / マーケ
プランニ
ング
実行
学習
役割の視野を広げる売上、KPIを上げるためになんでもやる

http://www.slideshare.net/i2key/leanstartup-devlove-leanstartup
http://l-orem.com/lean-startup-18-anti-patterns/
多くの新規事業の現場から
見えてきたアンチパターン集
エンジニアなのに・・・
膨大な量のビジネス企画のシャワーを浴びる
RECRUIT VENTURES、リクルートグループ各社での布教活動（いっ
ぱい）/各種審査員/新規事業アイデアの壁打ちメンター（大量）/etc

1. キャンバス依存パターン
2. そもそもFounder/Market Fit、Founder/Product Fitして
いないパターン
3. MVPでシンプルにやらなきゃだめだよ！だって、ネットの
記事にそうかいてあるしパターン
4. 石橋叩きすぎパターン
5. シングルタスクパターン
6. 誰そのペルソナ、本当にいるのパターン
7. その人お金払わないよねパターン
8. 何か言っているようで何も言っていないパターン
9. キャバクラでの我々パターン
16. 性能競争パターン
17. 解決策ありきパターン
18. ○○がそれやったらどーすんのパターン

経験した各フェーズの立ち回り
から、時間軸の視野を広げる

この視界から
エンジニアリングを見てみる
これ

ビジネスモデルから
エンジニアリングを見る

ビジネスモデル
↓
エンジニアリングの座組

とっかかりポイント
どこで売上が発生しているか
・エンジニアの書いたコード上で売上がたつ
・エンジニアの書いたコード上で売上がたたない

コード上で売上がたつ場合

検索条件
入力画面
検索結果
一覧画面
詳細画面予約画面
口コミ
SEO
SEM
ETC
サービス
トップ
画面
if(isBooked){
}
口コミ
SEO
SEM
ETC
成果課金型
広告枠検索サービス
¥0
利用者クライアント
マッチング
サービス
CVR改善＝売上直結
エンジニアの書いたコード上で売上がたつ例
CPA改善＝売上直結
流入数

検索条件
入力画面
検索結果
一覧画面
口コミ
SEO
SEM
ETC
サービス
トップ
画面
if(isBooked){
}
口コミ
SEO
SEM
ETC
成果課金型
¥0
マッチング
サービス
水漏れ補修水漏れ補修水漏れ補修水漏れ補修
流入数
エンジニアによるプロダクト改善が売上目標に直接寄与
= エンジニアが成長のエンジン（になりやすい）
= エンジニアのビジネス貢献が可視化しやすい
= 数値目標を持ったプロダクトチームが
　じゃんじゃん改善サイクルを回すとよいパターン
= アジャイルとか超導入しやすい座組（結果が売上で出る）
= 内製化はじめるとかもここらへんが成果を出しやすい
(憧れのエンジニア文化がある会社はこのモデル多め)

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

Acquisition(獲得)
Retention(継続)
Churn(解約)
Referral(紹介)
Activation(活性化)
Revenue(収益)
AARRRモデル
マーケ
営業プロダクト

検索条件
入力画面
検索結果
一覧画面
口コミ
SEO
SEM
ETC
サービス
トップ
画面
if(isBooked){
}
口コミ
SEO
SEM
ETC
成果課金型
¥0
マッチング
サービス
水漏れ補修水漏れ補修水漏れ補修水漏れ補修
流入数
パワーバランスこうなりがち（逆もあるがほぼイコール）
売上(CVR)・QCD ≧ 流入数・CV数
　　　　　　(プロダクト)　　　　　(マーケ)
売上 CVR・QCD
流入数
CV数
マーケ
プロダクト

コード上で売上がたたない場合

検索条件
入力画面
検索結果
一覧画面
口コミ
SEO
SEM
ETC
サービス
トップ
画面
if(isBooked){
}
口コミ
SEO
SEM
ETC
純広告枠
（営業商品）検索サービス
¥0
マッチング
サービス
CVR改善＝次回発注への信頼獲得 = 売上直結ではない
営業
エンジニアの書いたコード上で売上がたたない例
CV数
流入数

検索条件
入力画面
検索結果
一覧画面
口コミ
SEO
SEM
ETC
サービス
トップ
画面
if(isBooked){
}
口コミ
SEO
SEM
ETC
純広告枠
¥0
マッチング
サービス
営業
CV数
流入数
売上
CVR・QCD
流入数
CV数
マーケ
プロダクト
営業
パワーバランスこうなりがち
売上 > 流入数・CV数 > CVR・QCD
(営業)　　　　　(マーケ)　　　　　　　(プロダクト)

Acquisition(獲得)
Retention(継続)
Churn(解約)
Referral(紹介)
Revenue(収益)
AARRRモデル
マーケ
営業
プロダクト
営業

検索条件
入力画面
検索結果
一覧画面
口コミ
SEO
SEM
ETC
サービス
トップ
画面
if(isBooked){
}
口コミ
SEO
SEM
ETC
純広告枠
¥0
マッチング
サービス
営業
CV数
流入数
売上
CVR・QCD
流入数
CV数
マーケ
プロダクト
営業
営業が売上に直接的に寄与
= 営業が成長エンジン（売上○○円/人予測可能）
エンジニアは顧客単価を上げるための商品開発で寄与
＆安定運用（QCD）
＆改善（CVR向上）
顧客単価UP貢献
・イケイケアルゴリズム
・競合を凌駕する技術優位

検索条件
入力画面
検索結果
一覧画面
口コミ
SEO
SEM
ETC
サービス
トップ
画面
if(isBooked){
}
口コミ
SEO
SEM
ETC
純広告枠
¥0
マッチング
サービス
営業
CV数
流入数
売上
CVR・QCD
流入数
CV数
マーケ
プロダクト
営業
顧客単価UP貢献
営業が売上に直接的に寄与
= 営業が成長エンジン（売上○○円/人予測可能）
エンジニアは顧客単価を上げるための商品開発で寄与
＆安定運用（QCD）
＆改善（CVR向上）
ビジネス貢献が
可視化しにくい場合

検索条件
入力画面
検索結果
一覧画面
口コミ
SEO
SEM
ETC
サービス
トップ
画面
if(isBooked){
}
口コミ
SEO
SEM
ETC
純広告枠
¥0
マッチング
サービス
営業
エンジニアのビジネス貢献が可視化しにくい場合
= トラブルだけが目立つようになる
= できて当たり前（減点主義）のパラダイム
= エンジニアはコスト削減や生産性向上のようなビジネス指標
から程遠い目標設定になる
= QCDSの制約の雁字搦めになるので、エンジニア側は壁を作
りディフェンシブになりだす
= 本来、俊敏に開発したい目的に反して、組織がスローダウン
していく

放置していると組織としての慣性は、
ビジネス部門と開発部門
の社内受発注な関係に向かいやすい

・エンジニアの書いたコード上で売上がたつ
　→攻めのエンジニアリング要素強め
　　→でも、その中にも守りの要素はある。
・エンジニアの書いたコード上で売上がたたない
　→守りのエンジニアリング要素強め
　　→でも、その中にも攻めの要素はある。
ひとつの塊として扱うのではなく
適材適所で攻め/守りの目的に合わせた
エンジニアリングが必要

ビジネス戦略、
プロダクト戦略から

ビジネス戦略
プロダクト戦略
↓
エンジニアリング戦略
6
のぼり方・戦略

エンジニアがビジネス貢献すると思ってやっていることが、
実はそこまで重要ではない場合もある。
一般的に正しいとされている方法論を実施したときに、
いずれかのハレーションが生まれるような場合、
前提の置き方を間違っていることが多い。
（間違った原理主義に陥っている可能性）

アジャイルにやりたい（はずだ）。
本当にそうだろうか？

リリースサイクルを高速化したい（はずだ）。

仮説検証型にしたい（はずだ）。

仮説検証型にしたい（はずだ）。
目的意識は持っているものの、
目的をエンジニアが決めつけていて、
ビジネスと目的がすりあっていない可能性

ビジネス「側」はエンジニアのことを理解してくれない
とかいうのではなく、
まずは、膝を突き合わせて語りお互いを理解すること。
ビジネス戦略を正しく捉えた上での
戦略に合わせた開発手法なり技術選定なりが必要
本当の目的にあわせて開発のやりかたを決める。
まずは目的を問う。

我々が忠誠を誓うのは、開発手法ではない。
目的である。
目的を問い、目的からはじめる。
そこからズレると現場が不幸になる。

https://www.slideshare.net/papanda/ss-72221454
時を越えた越境への道　@papanda 氏
ここで世界線が交差する

https://www.youtube.com/watch?v=-WTZ2frEiZU
https://www.youtube.com/watch?v=QKgBsEISAbM
https://www.youtube.com/watch?v=DVVQGdcYY88
Geoﬀrey Moore Keynote:
The Future of Enterprise IT (part 1,2,3)
http://www.gartner.com/it-glossary/bimodal/
System of Engagement Bimodal IT
目的に対するIT戦略の一般論

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

BusinessCapabilityCentric
https://martinfowler.com/bliki/BusinessCapabilityCentric.html
Agile IT Organization Design:
For Digital Transformation and Continuous Delivery
Bi modal IT戦略は、SoEかSoRかの二極化の議論になりがち
なので、そうではなく実際のビジネスケーパビリティによって
チームを組んでそれぞれで適した開発（手法・技術）をしましょ
う。そのほうがチームを長期間存続させることができます。と
いう話。広義なマイクロサービスの組織論サイドにも近い。

方法論や考え方は、真理に対して、
それぞれ別の角度から光を当てているため、
1つの方法論に固執すると視野が狭まり、
本質を見失い、
過度な原理主義に陥る恐れがある。

真理
バイモーダル戦略
BusinessCapabilityCenrticIT
SoRとSoEの
二極化で整理できる
わけないだろ
特定の位置から光をあてると
影の部分に対してヤジがとんでくる
だから、
SoRとSoEは
グラデーションだ
っていってんだろ

真理
ビジネス能力だけで
開発手法決まるわけ
ないだろ！！！
特定の位置から光をあてると
影の部分に対してヤジがとんでくる

影になる部分を補うように、それぞれの方向から光を当ててみる
真理

Business Capability Centric IT
SoE
SoR
入稿業務予約業務課金業務分析業務
UI/UX
UI/UX
UI/UX
予約登録API
検索API
入稿API 決済API
システム間
連携処理
参照API
参照API
カスタマー社内担当者カスタマー社内担当者
アプリ
UI/UX
ブックマーク
予約機能
検索機能
カスタマー
俊敏
アジャイル
仮説検証
売上・KPI
安定
計画駆動
仕様通り
ROI・QCD
利用者
Business
Capability
俊敏なKPI改善俊敏なKPI改善トラブル0件トラブル0件
使いやすさ
正確な集計目的
BiModalIT
UI/UX
参照API
検索API
集計処理

SoE
SoR
UI/UX
UI/UX
UI/UX
UI/UX
予約登録API
検索API
入稿API 決済API
システム間
連携処理
参照API
参照API
集計処理
アプリ
UI/UX
ブックマーク
予約機能
検索機能
カスタマー
俊敏
アジャイル
仮説検証
売上・KPI
安定
計画駆動
仕様通り
ROI・QCD
利用者
Business
Capability
使いやすさ
BiModalIT
アジャイルアジャイルアジャイル
ウォーター
フォール
ウォーター
フォール
ウォーター
フォール
参照API
検索API

SoE
SoR
UI/UX
UI/UX
UI/UX
UI/UX
予約登録API
検索API
入稿API 決済API
システム間
連携処理
参照API
参照API
参照API
検索API
集計処理
アプリ
UI/UX
ブックマーク
予約機能
検索機能
カスタマー
俊敏
アジャイル
仮説検証
売上・KPI
安定
計画駆動
仕様通り
ROI・QCD
利用者
Business
Capability
使いやすさ
BiModalIT
ウォーター
フォール
ウォーター
フォール
ウォーター
フォール
重要な
プロジェクト
型案件
Objective-C
↓
Swiftへ
フルリライト
新機能の
実装前に
仮説検証
価格設定
のための
仮説検証
学び最大化学び最大化

SoE
SoR
UI/UX
UI/UX
UI/UX
UI/UX
予約登録API
検索API
入稿API 決済API
システム間
連携処理
参照API
参照API
参照API
検索API
集計処理
アプリ
UI/UX
ブックマーク
予約機能
検索機能
カスタマー
俊敏
アジャイル
仮説検証
売上・KPI
安定
計画駆動
仕様通り
ROI・QCD
利用者
Business
Capability
使いやすさ
BiModalIT
ウォーター
フォール
ウォーター
フォール
ウォーター
フォール
重要な
プロジェクト
型案件
Objective-C
↓
Swiftへ
フルリライト
新機能の
実装前に
仮説検証
価格設定
のための
仮説検証
アジャイルアジャイル
ウォーター
フォール
ウォーター
フォール

SoE
SoR
UI/UX
UI/UX
UI/UX
UI/UX
予約登録API
検索API
入稿API 決済API
システム間
連携処理
参照API
参照API
参照API
検索API
集計処理
アプリ
UI/UX
ブックマーク
予約機能
検索機能
カスタマー
俊敏
アジャイル
仮説検証
売上・KPI
安定
計画駆動
仕様通り
ROI・QCD
利用者
Business
Capability
使いやすさ
BiModalIT
ウォーター
フォール
ウォーター
フォール
ウォーター
フォール
重要な
プロジェクト
型案件
Objective-C
↓
Swiftへ
フルリライト
新機能の
実装前に
仮説検証
価格設定
のための
仮説検証
ウォーター
フォール
ウォーター
フォール
戦略・各種優先度に応じて
SoEチームと
SoRチームに分けるか、
優先度をつけて1チームでやるか
チームの能力、戦略、財務、
各種文脈に応じて判断する。

ビジネスフェーズから

ビジネスフェーズ
↓
求められる
プロダクト品質

充足
不充足
満足
不満足
顧客の満足感
物理的な充足度
魅力品質
当たり前品質
アーリーアダプターには
ここ弱めにするか。とか
マネタイズ検証時には
必要だね。とか
Minimum Sellable Product
性能品質
魅力品質
性能品質
当たり前品質
不充足でも不満には思わないが、
充足されれば満足
<例>
ハイレゾ音源（あれば良いが、なくても
不満ではない）、曲面液晶など
不充足だと不満、充足されると満足
<例>
バッテリーの持ち（稼働時間が長ければ
満足、短いと不満）、重量など
不充足だと不満、充足されて当たり前
<例>
通話音声（音が良くて当たり前、聞き
取りづらいと不満）
狩野モデル一般論

深い課題を抱えた顧客がいるか
その課題の解決策は妥当か
顧客発見顧客実証顧客開拓組織構築
[ニーズ検証] [売って検証] [リーチ検証] [本格拡大]
独自な価値提供を出来ているか
顧客は本当に買ってくれるか
コスト構造に無理がないか
最適な売り方の検証
最適な価格設定の検証
Problem
Solution
Fit
Product
Market
Fit
Scaling
Retention CAC < LTV 最大LTVセグメントの比率
課題解決可能
な最小限
売り方最適化 / 売上最大化売る
ビジネス
フェーズ
狩野
モデル
魅力的品質最低限の性能品質
魅力的品質
当たり前品質
アップセル・クロスセルに
向けた性能品質
魅力的品質
当たり前品質
指標値例
検証アク
ション
検証
ポイント
MVP
目標
MVP作って壊す
MVP
品質
最低限の
売れる状態
セグメントに応じて売れる状態
検証が既存ユーザに影響与えない

充足
不充足
満足
不満足
顧客の満足感
物理的な充足度
魅力品質
当たり前品質
アーリーアダプターには
ここ弱めにするか。とか
マネタイズ検証時には
必要だね。とか
Minimum Sellable Product
性能品質
魅力品質
性能品質
当たり前品質
不充足でも不満には思わないが、
充足されれば満足
<例>
ハイレゾ音源（あれば良いが、なくても
不満ではない）、曲面液晶など
不充足だと不満、充足されると満足
<例>
バッテリーの持ち（稼働時間が長ければ
満足、短いと不満）、重量など
不充足だと不満、充足されて当たり前
<例>
通話音声（音が良くて当たり前、聞き
取りづらいと不満）
狩野モデル

ビジネスフェーズ
↓
求められる
エンジニア像

ビジネスフェーズからエンジニア像を俯瞰してみる
（ユニークなValuePropositionが技術ではない場合の例）
Problem / Solu,on Fit Product / Market Fit Scaling

100%
%me

Scale

MySQL

MVP

iOS
iOS

KPI

検証用のMVPを
高速に実装
ビジネス文脈を意識した
品質担保＆成長貢献
セグメントに応じた
性能向上
顧客発見顧客実証顧客開拓

検証を設計する
（実証条件/実証方法/etc）
効果を計測する
KPI（数値目標）を設定する
リリースする
ユーザがコンバージョンする
仮説をたてる
仕様にする
設計する
ユーザーに届く
ユーザーが使う
ユーザーが気づく
KPI（数値目標）達成
指標：ベロシティ/デプロイ回数/性能値/品質/コスト/etc
エンジニアのコミットと目標
データから学ぶ
（仮説を修正する
　　打ち手を変える）
エンジニアが直接結果を
コントロール出来る範囲
（コードのみに対峙してる）
コントロール出来ない範囲
（ユーザーの判断という不確実性が介在）
テストする
実装する
指標：MAU/継続率/○○率/売上/etc

リリースする
仮説をたてる
仕様にする
設計する
テストする
実装する
マルチロールに
しみ出す

リリースする
仮説をたてる
仕様にする
設計する
テストする
実装する
それぞれのプロ

ビジネス仮説検証プロセス
から

仮説検証プロセス
↓
エンジニアリングによる
仮説検証基盤構築

仮説検証基盤要件方法
既存のユーザへの影響
を最小化
ユーザーを任意の属性
でセグメントする機能
管理コンソールの実装
(Firebase …etc)
既存のユーザへの影響
を最小化
ユーザーセグメントに
対して機能の出し分け
を可能にする
事業フェーズが進めば進むほど、
既にたくさん使われているプロダ
クトで仮説検証をすることになる
ため必要最低限の影響範囲で仮説
検証をする
Feature Flag、A/Bテス
ト、Private Beta Test、
Dark Launch、etc
(Leanplum, Firebase, Optimizely, etc)
検証結果が濁らないこ
と
仮説や施策単位に各種
数値を計測出来る機能
(例)CV数が目標の場合、マーケの
頑張りなのか、プロダクト改善に
よるCVR向上なのか切り分けがで
きない
コホート分析
(Localytics, Google Analytics,
Firebase …etc)
検証方法の改善が出来
ること
検証ポイントまでユー
ザが漏れずに到達でき
ていること
UI上の問題で検証ポイントまでユ
ーザが到達していないのに、検証
失敗とする事案がある
ファネル分析
(Localytics, Google Analytics, etc)
：：：
DevOps系プラクティス見れば基本ソレ

予算計画のリズムから

1年 1年 1年
予算のリズム
↓
開発のリズム（ほんとに？？？？？）
答え持っていないのでここは
誰かご教授願いたいです
（課題提起プレゼン）
次年度予算計画次年度予算計画次年度予算計画

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

エンタープライズの場合、年次の予算計画があり、
ベースとなるサイクルタイムは年になる。
1年先の未来の状況を事前に予想して計画しないとならない。
そして、それを1年後まで大幅に変更することはない。
計画の実行に固執すると「発見」による変更がきかなくなる
1年 1年 1年
新規事業なのに年次計画駆動になるバイアス
予算：目的のために確保する資金の合計（活動に費やせる金額の上限）
戦略：実際にやることを定義するもの
予算は戦略をどのように実現するべきか計画するのもではない
顧客に価値を届けるこのと成否を予測したり評価したりするのもではない。
課題：年次プロセス以外で資金調達する方法がない

課題：年次プロセス以外で資金調達する方法がない
→「発見」による軌道修正が不可能
→より多くの予算を確保するために多大な労力をかけて最高のビジネスプ
ランを計画（予想ｗ）しないとならない
解決策事例1：新規事業組織部門としてバジェットは年次固定
で持ちつつ、それを部門内で資金調達型で各新規事業へ配分し
ていく。各事業にステージ(調達額上限)を設定。同時に撤退の
ルールも決め予算の「選択と集中」を行う。
http://www.slideshare.net/i2key/bp-leanstartup#94

解決策事例2：活動基準会計を行う。前述の新規事業単位での
資金調達よりも、細かい現場での機能追加レベルでの資金調達
法。仮説検証の学びに対するコストの説明責任を設ける。仮説
検証、ひとつひとつに対して何を学ぶのか、検証するために何
が必要なのか、どのように計測するのか、いくらかかるのかを
設計する。優先付をして学びに対するムダの無い投資をする。
http://www.slideshare.net/i2key/45-developers-summit-2015-devsumi-devsumib#141

行動様式
現場で得られた数々の経験から
汎化し自分なりの
勘所(原理原則)を導き出し、
またそれを経験や疑似体験に
照らし合わせ補正していく

顧客発見
【ニーズ検証】
顧客実証
【売って検証】
組織構築
【本格拡大】
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高品質
競合との性能競争(消耗戦)
キードライバー値
最大化
利益最大化
ビジネス
フェーズ
■既存のユーザへの影響を最小化
ユーザーを任意の属性でセグメントする機能
ユーザーセグメントに対して機能の出し分けを可能にする
事業フェーズが進めば進むほど、既にたくさん使われているプロダクトで仮説
検証をすることになるため必要最低限の影響範囲で仮説検証をする
■検証結果が濁らないこと
仮説や施策単位に各種数値を計測出来る機能
(例)CV数が目標の場合、マーケの頑張りなのか、プロダクト改善によるCVR向上なのか切り分けができない
■検証方法の改善が出来ること(ファネル分析)
検証ポイントまでユーザが漏れずに到達できていること
UI上の問題で検証ポイントまでユーザが到達していないのに、結果指標
のみを見て検証失敗とする誤判断することがある
■利用開始日別ユーザ単位の分析(コホート分析)
日々の流入イベント毎にユーザーの継続率を分離して計測
ユーザーインタビュー時に使い始めてもらった人の継続率を図る。特定
の日だけアドを少額流して、アドを当てたセグメントの継続率を見る等
リリース日単位の追加機能別のユーザーの継続率を分離して計測
どの機能追加が継続率にヒットしたかを確認する等
Feature Flag、A/Bテスト、Private Beta Test、Dark Launch、etc
(Leanplum, Firebase, Optimizely, LaunchDarkly , etc)、独自インフラ手段 Localytics, Google Analytics, Firebase …etc

顧客発見
【ニーズ検証】
顧客実証
【売って検証】
組織構築
【本格拡大】
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高品質
競合との性能競争(消耗戦)
キードライバー値
最大化
利益最大化
ビジネス
フェーズ
■既存のユーザへの影響を最小化
ユーザーを任意の属性でセグメントする機能
ユーザーセグメントに対して機能の出し分けを可能にする
事業フェーズが進めば進むほど、既にたくさん使われているプロダクトで仮説
検証をすることになるため必要最低限の影響範囲で仮説検証をする
■検証結果が濁らないこと
仮説や施策単位に各種数値を計測出来る機能
(例)CV数が目標の場合、マーケの頑張りなのか、プロダクト改善によるCVR向上なのか切り分けができない
■検証方法の改善が出来ること(ファネル分析)
検証ポイントまでユーザが漏れずに到達できていること
UI上の問題で検証ポイントまでユーザが到達していないのに、結果指標
のみを見て検証失敗とする誤判断することがある
■利用開始日別ユーザ単位の分析(コホート分析)
日々の流入イベント毎にユーザーの継続率を分離して計測
ユーザーインタビュー時に使い始めてもらった人の継続率を図る。特定
の日だけアドを少額流して、アドを当てたセグメントの継続率を見る等
リリース日単位の追加機能別のユーザーの継続率を分離して計測
どの機能追加が継続率にヒットしたかを確認する等
Feature Flag、A/Bテスト、Private Beta Test、Dark Launch、etc
(Leanplum, Firebase, Optimizely, LaunchDarkly , etc)、独自インフラ手段 Localytics, Google Analytics, Firebase …etc
これは原理原則のとある特定のビジネス文脈における
1インスタンス。
その雛形は自分の中にアップデートし続ける。
※すべての文脈に対応しようとすると文章化できない

リーンスタートアップ
制約理論
デザインシンキング
顧客開発
トヨタ生産方式
アジャイル
スクラム
XP
リーンソフトウェア開発
真理
モダンアジャイル
TDD
Flow Eﬃciency
KANBAN
ペアプログラミング
ゆとりの法則

フロー効率性とリソース効率性のパラダイムを
効果的に使い分けて現場を推進すること
SoEでもSoRでもそれは変わらない。
http://i2key.hateblo.jp/entry/2017/05/15/082655

リソース効率性とフロー効率性
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人日かかる場合

リソース効率性とフロー効率性
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
A機能、B機能、C機能の実装それぞれ15人日かかる場合
リソース効率が良い
（例）稼働率100%
フロー効率が良い
（例）機能リリースまでのリードタイムの短さ

リソース効率
フロー効率
This is Lean
The Efficiency Matrix
①
② ③
④
Efficient islands
効率的な島々
Wasteland
荒廃した地
Efficient ocean
効率的な海
The perfect state
High
HighLow
Low
https://www.amazon.co.jp/dp/919803930X/
①あなたはここにいると思っている
②実際には多分ここ
③まずはフロー効率化からはじめて
④その後にリソース効率化をしていく
例）稼働率100%のチーム
　　機能がリリースされるまでのリードタイム長い
例）稼働率は100%ではないチーム
　　機能がリリースされるまでのリードタイム短い
Variation

リソース効率性フロー効率性
1つのリソースを稼働率が
100%になるまで分配する
フローユニットが享受できる
リソースを最大化する
This is Lean https://www.amazon.co.jp/dp/919803930X/
例：マルチタスク例：ペアプログラミング
This is Leanの P21
The Eﬃciency Matrix

わたし
あなた
彼
「ゆとりの法則」より
各従業員の机に一時置き場がなければ、組織の
全従業員が常に100％忙しいということはありえない。

わたし
あなた
彼
書類受け
書類受け
書類受け
全員の机に一時置き場（書類受け）を用意すると、
全員が常に忙しくなるような仕事の流れを作ることができる

わたし
あなた
彼
書類受け
書類受け
書類受け
稼働率100%
稼働率100%
稼働率100%
待ちタスク
いっぱい
待ちタスク
いっぱい
待ちタスク
いっぱい
リードタイムが
生まれる
生まれる
生まれる
リソースの効率性は高まるが、副作用として仕事が組織の中で
処理されるのにかかる時間が長くなる（組織の速度低下）

待ち行列理論
・100%の利用率の高速道路は、駐車場といっしょ
・CPU100%利用率のパソコンは？
・稼働率100%のチームは？
スループットを最大化ではなくチームに最適化する
・処理中のもの量の最小化
・処理中のもののサイズを最小化
チームへの負荷を調整
・たくさんのこと同時にしない
・タスク管理ではなく、チームのペースを管理する
仕事の許容量を制限する
・スコープボックスではなくタイムボックス
・プッシュ型ではなくプル型でやる
フロー効率を高めるために
（顧客へ価値が届くまでのリードタイムを短くする）

事例：学びの回数の最大化

事業が対峙する現実からエンジニアリングを俯瞰する #devlove

提案
サービス
¥0
クライアント
企業従業員クライアント
BtoB
従業員向け
SaaS型
サービス
営業
time (月)
：
：
：
受注率
継続率
継続率
BtoBのSaaSモデル

Acquisition(獲得)
Retention(継続)
Churn(解約)
Referral(紹介)
Revenue(収益)
マーケ
営業プロダクト

xxx画面 xxx画面 xxx画面 CV画面
サービス
トップ
画面
if(isConverted){
}
営業

最適な売り方、
最適な価格設定の
検証フェーズ

・営業が獲得と初回売上立てるモデル
　　↓
・月額課金における継続率は
　プロダクトで担保しつつ、
　最適な価格設定の検証を走らせる
　　↓
・仮説検証の学びの回数最大化
　　↓
・仮説検証の速度の最大化
　（本番デプロイ回数/日）
　　※リリースまでのリードタイム最小化
検証フェーズ

・フェーズ的に売り物を使って
　仮説検証していく
　　↓
・MVPは当たり前品質、性能品質必要
　（競合同等の機能品質がないと買ってもらえない
　　→検証したい価格設定の検証ができない）
　　↓
・仮説検証の質を最大化
　　↓
・プロダクト品質
・既存ユーザに仮説検証で
　迷惑をかけない仕組み
・濁らない計測
検証フェーズ

仮説検証トライ回数最大化仮説検証トライ品質最大化
（デプロイ回数/日）

仮説検証トライ回数最大化仮説検証トライ品質最大化
（デプロイ回数/日）
プロセス品質向上
= 手戻り防止
= フロー効率あげる
リードタイム削減
=フロー効率あげる
プロセスタイムの削減
＝フロー効率あげる
仮説品質向上
= 手戻り防止
計測品質向上
= 手戻り防止
実装品質向上
= 手戻り防止

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
・マルチタスクやめる
・ペアプログラミング
・モブプログラミング
・カンバン＆WIP制限
・デザインスプリント
・同期するようなタスクを減らす
　　　：

事例：特定の部分では仮説検証を
回しつつ、プロジェクト型の案件
も行う両立型

SoE
SoR
UI/UX
UI/UX
UI/UX
UI/UX
予約登録API
検索API
入稿API 決済API
システム間
連携処理
参照API
参照API
参照API
検索API
集計処理
アプリ
UI/UX
ブックマーク
予約機能
検索機能
カスタマー
俊敏
アジャイル
仮説検証
売上・KPI
安定
計画駆動
仕様通り
ROI・QCD
利用者
Business
Capability
使いやすさ
BiModalIT
ウォーター
フォール
ウォーター
フォール
ウォーター
フォール
重要な
プロジェクト
型案件
Objective-C
↓
Swiftへ
フルリライト
新機能の
実装前に
仮説検証
価格設定
のための
仮説検証
ウォーター
フォール
ウォーター
フォール
重要な
プロジェクト
型案件

マーケ組織商品企画組織営業組織分析組織
プロダクト開発組織
プロダクトオーナー
プロジェクト(WF) スクラム1 スクラム2
ガーディアン
アーキテクト
プロキシー
プロキシー
プロジェクトリーダー
スクラムマスター
○○○○○
XXXXXX
△△△△△
○○○○○
プロキシー
○○○○○
XXXXXX
△△△△△
○○○○○
○○○○○
XXXXXX
△△△△△
○○○○○
エンジニア
エンジニア
エンジニア
：エンジニア x N人
UI/UXデザイナー
エンジニア
エンジニア
エンジニア
：
SoR SoE SoE
アプリフロントチーム

ガーディアン
アーキテクト
プロキシー
プロキシー
○○○○○
XXXXXX
△△△△△
○○○○○
プロキシー
○○○○○
XXXXXX
△△△△△
○○○○○
○○○○○
XXXXXX
△△△△△
○○○○○
エンジニア
エンジニア
エンジニア
エンジニア
エンジニア
エンジニア
：
SoR SoE SoE
リソース効率
＆
フロー効率
例：CCPM

ガーディアン
アーキテクト
プロキシー
プロキシー
○○○○○
XXXXXX
△△△△△
○○○○○
プロキシー
○○○○○
XXXXXX
△△△△△
○○○○○
○○○○○
XXXXXX
△△△△△
○○○○○
エンジニア
エンジニア
エンジニア
エンジニア
エンジニア
エンジニア
：
SoR SoE SoE
フロー効率
例：一個流し

ビジネスのことを考えて提案しているのに
受け入れられない場合、
前提の置き方を間違っていることが多い。
（間違った原理主義に陥っている可能性）

我々が忠誠を誓うのは、開発手法ではない。
目的である。
目的を問い、目的からはじめる。

事業が対峙する現実からエンジニアリングを俯瞰する #devlove

More Related Content

事業が対峙する現実からエンジニアリングを俯瞰する #devlove