リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkan

リーンスタートアッ
プと顧客開発と
アジャイル開発
を一気通貫するッ
Recruit Technologies Co.,Ltd.
ITM Dev2部 DevOps推進
黒田樹 @i2key

本スライドは、下記イベントのために
@i2key の過去講演資料を悪魔合体させたものになります。
https://devlove-kansai.doorkeeper.jp/events/57834
DevLOVE関西主催
リンスタ関ヶ原（新大阪の変）
2017/03/17
#DevKan #DevLove
https://www.slideshare.net/i2key/devsumibhttps://www.slideshare.net/i2key/bp-leanstartup
https://www.slideshare.net/i2key/
lean-startup-overview-51898723
https://www.slideshare.net/i2key/
leanstartup-devlove-leanstartup
＋
＋＋
配合レシピ

仮説検証型でやっていく勘所
(リーンスタートアップや顧客開発の概念説明)
ビジネスモデル上の
ムダを減らすための仮説検証
(リーンキャンバス＆BMLループ)
学びまでのリードタイムを減
らすエンジニアリング
(アジャイル、リーンソフトウェア開発)

ビジネスアイデア全てを仮説と捉えて、
それらを小さく分割して検証すること
ビジネスモデル上のボトルネックを
効率よく発見し効率よく解消する
ビジネスモデルのムリ・ムダ・ムラを省く

ビジネスアイデア全てを仮説と捉えて、
それらを小さく分割して検証すること
ビジネスモデル上のボトルネックを
効率よく発見し効率よく解消する
ビジネスモデルのムリ・ムダ・ムラを省く
全部仮説
全部思い込み

・思い込みを排除し全てを仮説と捉える
・コストに対する学びを最大化する
・失敗による損失を最小化する
思い込みで打席にたって
フルスイング怖くない？

ファイル同期がいかに便利か、どのように動作す
るのかのプロモーション動画を作成し、Youtube
にアップロード。HackerNewsに流して、
事前登録者数をモニタリングでニーズを実証。
仮説を小さく実証する例①

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

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

あくまで事例。
テクニックではない。
何でもダミーボタン等で検
証するべきとかではない。
価値観を学ぶことが大事。

製品コン
セプト作り
製品開発評価試験
発売/リ
リース
製品開発プロセス
（ウォーターフォール型プロセス）
作れるかのリスクよりも
作ったものが売れるかのリスク

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

顧客発見顧客実証顧客開拓組織構築
顧客開発モデルによるプロセス
（仮説検証型プロセス）
「ヒト・モノ・カネを散々投じた挙げ句誰も欲しがらないものを開発して
しまう」という新規事業・新商品の典型的失敗を避けるためのプロセス
顧客相手に仮説検証を繰り返し、リスクを潰していく
[ニーズ検証] [売って検証] [リーチ検証] [本格拡大]

時間
保有リスク量
2人日

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

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

開発タスク管理リスト
10個ひらめいた！
事業責任者・PO
10個のエンジニアタスク
従来のタスク管理あるある
シャワー浴びながら・・
トイレに入りながら・・
ktkr!!!!
いやいやいや・・・
フィルタを売って
売上をあげる！
フィルタ購入機能実装

Lean Canvas
＜ビジネス仮説＞
仮説検証
MVPの設計
開発タスク管理リスト
＜MVP構築タスク＞
10個の仮説 3個のMVP構築
（エンジニアタスク）
10個のMVP設計
7個のGetOutOfBuilding
※別に開発しなくても仮説検証できる
仮説検証型タスク
エンジニアリング必要
エンジニアリング不要
フィルタが本当に
購入されるのか
ダミー x
10%のユーザで
検証
検証用フィルタ購入
ダミーボタン実装
どんなフィルターがウケるか
街頭インタビューしよう

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

LEAN CANVAS
顧客は誰？課題は何？
解決策は？
価値は何？
圧倒的優位性は何？
コスト構造は？売り上げは？
顧客にリーチするための
チャネルは
何を測る？

LEAN CANVAS
Product
（サービス）
Market
（顧客）

LEAN CANVAS
解決策は？
価値は何？
チャネルは
何を測る？
① ①②
③
不確実性が高い順に検証していく

LEAN CANVAS
解決策は？
価値は何？
チャネルは
何を測る？実証済み
実証済み
実証済み
実証済み
実証済み
実証済み
実証済み
目指す状態

深い課題を抱え
た顧客がいるか
Problem
Solution
Fit
Product
Market
Fit
Scaling
実証済み実証済み実証済み
実証済み
実証済み
実証済み実証済み
実証済み
実証済み
実証済み
その課題の解決
策は妥当か
実証済み
独自な価値提供
を出来ているか
顧客は本当に買っ
てくれるか
コスト構造に無
理がないか
最適な売り方の
検証
最適な価格設定
の検証
①①
②③
①①
②③
①①
②③
⑤ ④ ⑤ ④
⑥⑥
10

Problem
Solution
Fit
Product
Market
Fit
Scaling
実証済み
実証済み
実証済み
実証済み
実証済み
策は妥当か
実証済み
てくれるか
理がないか
検証
の検証
①①
②③
①①
②③
①①
②③
⑤ ④ ⑤ ④
⑥⑥
Retention CAC < LTV
最大LTVセグメントの
比率を増やす
バイラル係数 > 1
指標値の例
10

仮説検証型でやっていく勘所
(リーンスタートアップや顧客開発の概念説明)
ビジネスモデル上の
ムダを減らすための仮説検証
(リーンキャンバス＆BMLループ)
学びまでのリードタイムを減
らすエンジニアリング
(アジャイル、リーンソフトウェア開発)
10

出資先海外スタートアップの日本展開支援

顧客
デザイナー
（世界100万人）
世界最大のデザイン特化型クラウドソーシングサービス
10

ロゴデザイン
http://99designs.jp/lp/logo-design-oss/

リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkan

を日本に展開する
やること

を
やること
US市場においてProduct Market Fitし
Scalingフェーズに入ったサービス
カスタマーセグメントが異なる
非英語圏である日本に展開する

Problem
Solution
Fit
Product
Market
Fit
Scaling
実証済み
実証済み
実証済み
実証済み
実証済み
Japan

Problem
Solution
Fit
Product
Market
Fit
Scaling
実証済み
実証済み
実証済み
実証済み
実証済み
カスタマーが英語圏から日本語文化
圏になるため、既存サービスに手を
いれずにProduct/Market Fitするの
かを見極める必要がある
Japan

Problem
Solution
Fit
Product
Market
Fit
Scaling
実証済み
実証済み
実証済み
実証済み
実証済み
課題を解決できていない場合、
Solution（サービス/商材）を日本顧
客（日本文化）に合わせてチューニ
ングする必要がある。
Japan

解決策は？
価値は何？
チャネルは
何を測る？
実証済み
実証済み
実証済み
実証済み
実証済み
実証済み
実証済み

Product Market
Japan
売り物に関しては
実証済みとして
一旦、固定する
まずは売り方の
チューニングだけ
でいけるか確認

解決策は？
価値は何？
チャネルは
何を測る？
実証済み
実証済み
実証済み
実証済み
実証済み
実証済み
未実証
(日本市場依存)
Japan
未実証
未実証

Problem/Solution Fitしている前提に立ち
プロダクト自体（売り物）をいじらずに
最適なカスタマーへ、最適なチャネル（売り方）で
サービスが届き、利用されている状態をつくる
CAC < LTV

□日本市場におけるカスタマーセグメントを明らかにする
□そのカスタマーセグメントの存在を実証する
□リーチできれば利用する（P/S FIT）することを実証する
□リーチするためのチャネルの検証をする
　　　　　　　　　　　　　：
まず、検証すること

内緒
内緒
Japan
はやく安く
クオリティの
高いデザイン
が欲しい人
はやく安く
クオリティの
高いデザイン
が手に入る
オンライン
広告
世界100万人
のデザイナー
在庫
コンペ型デザ
インクラソー
内緒
口コミ
良いデザイナー
に出会えない
多種多様な提
案が欲しい

内緒
内緒
Japan
はやく安く
クオリティの
高いデザイン
が欲しい人
はやく安く
クオリティの
高いデザイン
が手に入る
オンライン
広告
世界100万人
のデザイナー
在庫
良いデザイナー
に出会えないコンペ型デザ
インクラソー
内緒
口コミ
トートロジー
何か言っているようで何も言っていない。
よくありがちなバリュープロポジションと
そのカスタマーセグメントの関係（笑）
ドメインの理解が浅いとこうなりがち。
多種多様な提
案が欲しい

Problem
Solution
Fit
Product
Market
Fit
Scaling
実証済み
実証済み
実証済み
実証済み
実証済み
策は妥当か
実証済み
てくれるか
理がないか
検証
の検証
①①
②③
①①
②③
①①
②③
⑤ ④ ⑤ ④
⑥⑥
Retention CAC < LTV
比率を増やす
指標値の例

Problem
Solution
Fit
Product
Market
Fit
Scaling
実証済み
実証済み
実証済み
実証済み
実証済み
策は妥当か
実証済み
てくれるか
理がないか
検証
の検証
①①
②③
①①
②③
①①
②③
⑤ ④ ⑤ ④
⑥⑥
Retention CAC < LTV
比率を増やす
指標値の例
継続して使い続ける人
継続して使い続けるセグメント
＝Problem Solution Fitしてる人
＝サービスはこの人の課題を解決できている
＝この人はこのサービスを継続して使う理由を持っている

Problem
Solution
Fit
Product
Market
Fit
Scaling
実証済み
実証済み
実証済み
実証済み
実証済み
策は妥当か
実証済み
てくれるか
理がないか
検証
の検証
①①
②③
①①
②③
①①
②③
⑤ ④ ⑤ ④
⑥⑥
Retention CAC < LTV
比率を増やす
指標値の例
この継続している利用者/継続しているセグメント
にインタビューをして、使っている理由を知る
なぜ99designsを選んだのか(UVP)
どこに価値を感じたのか(UVP)
どんな課題を解決したのか(Problem/Solution)
今までのやりかたとくらべてどうか(代替手段)
どうやって（誰から）知ったか(chanel)
：
：
「過去を振り返って事実のみをきく。」
(使ってくださった直後のユーザーさんとか最高)

Problem
Solution
Fit
Product
Market
Fit
Scaling
実証済み
実証済み
実証済み
実証済み
実証済み
策は妥当か
実証済み
てくれるか
理がないか
検証
の検証
①①
②③
①①
②③
①①
②③
⑤ ④ ⑤ ④
⑥⑥
Retention CAC < LTV
比率を増やす
指標値の例
この継続している利用者/継続しているセグメント
にインタビューをして、使っている理由を知る
なぜ99designsを選んだのか(UVP)
どこに価値を感じたのか(UVP)
どんな課題を解決したのか(Problem/Solution)
今までのやりかたとくらべてどうか(代替手段)
どうやって（誰から）知ったか(chanel)
：
：
「過去を振り返って事実のみをきく。」
(使ってくださった直後のユーザーさんとか最高)
これを何人もにやると
共通項（スケーラブルな部分）
「日本国外に通用するデザインのニーズ」
の存在が見えてくる
そして
いくかのセグメントを見立てることが
できるようになる

内緒
内緒
Japan
はやく安く
クオリティの
高いデザイン
が欲しい人
はやく安く
クオリティの
高いデザイン
が手に入る
オンライン
広告
グローバルで
通用するデザ
インを手に入
れられる。（は
やいやすい質
が良いは前提）
日本から海外
へ国境を越え
ていくような
カスタマー
・オープンソース・ソフト
ウェアのエンジニア
・ウェブサービス/スマホア
プリでの起業家
・プロダクトをグローバル
進出させようとしている企
業（食品会社、化粧品会社、
etc）
・越境ECコンサル
・アーティスト、音楽事務
所
・SNSカバーデザイン
　　　：
　　　：
海外市場に
フィットした
デザインが出
来るデザイナ
に出会えない
コンペ型デザ
インクラソー
世界100万人
のデザイナー
在庫
内緒
日本人デザイ
ナーが海外で
好まれるデザ
インセンスを
持ってない
口コミ

✔日本市場におけるカスタマーセグメントを明らかにする
□そのカスタマーセグメントの存在を実証する
□リーチできれば利用する（P/S FIT）することを実証する
　　　　　　　　　　　　　：
20

①仮説
②何を学ぶのか
③必要なデータは？
④どうやって計測する？
⑤必要なものは？
⑥どう構築するか？
思考プロセス
20

⑫仮説を調整する
⑪学ぶ
⑩データを元に検証
⑨データを計測する
⑧完成したMVP
⑦構築する
実証プロセス
20

②何を学ぶのか
・コンバージョンする
セグメントの存在有無
③必要なデータは？
セグメントに対する
一定量のCV
④どうやって計測する？
セグメント毎に分けて
CVページで計測
⑤必要なものは？
セグメント毎に
集客する装置
うーむ
思考プロセス①仮説
・○○○なユーザセグメントが
存在するか
20

(MVP案1)セグメント単位に少量のオンライン広告
を流してCV検証
(MVP案2)セグメント単位に営業をかけてCV検証
(MVP案3)セグメント単位にオーガニックにまつ
もっとも効果的に学びが得られるMVPはどれか選択する
・費用対効果
・期間
・工数
・この検証方法により回避できる将来のリスク
・この検証方法により逆に発生する将来のリスク
思考プロセス

Acquisition
獲得 Retention
継続
Churn
解約
Referral
紹介
Activation
活性化 Revenue
収益
セグメント毎にいったん少量の水を流して
水漏れをみる(CVするか、PSFitするか)
広告

OSSエンジニア向けLP
ターゲティング広告

起業家向けLPターゲティング広告

カスタマーセグメント毎にLPを作成

⑫仮説を調整する
⑪学ぶ
⑩データを元に検証
⑨広告を少量流しデータを計測する
⑧完成したMVP
⑦構築する
少量広告＋セグメント特化LP
実証プロセス

内緒
内緒
Japan
オンライン
広告
グローバルで
通用するデザ
インを手に入
れられる。（は
やいやすい質
が良いは前提）
海外市場に
フィットした
デザインが出
来るデザイナ
に出会えない
コンペ型デザ
インクラソー
世界100万人
のデザイナー
在庫
内緒
日本人デザイ
ナーが海外で
好まれるデザ
インセンスを
持ってない
口コミ
日本から海外
へ国境を越え
ていくような
カスタマー
[○]・オープンソース・ソ
フトウェアのエンジニア
[○]・ウェブサービス/スマ
ホアプリでの起業家
[○]・プロダクトをグロー
バル進出させようとしてい
る企業（食品会社、化粧品
会社、etc）
[○]・越境ECコンサル
[×]アーティスト、音楽事務
所
[×]SNSカバーデザイン
　　　：
　　　：

✔日本市場におけるカスタマーセグメントを明らかにする
✔そのカスタマーセグメントの存在を実証する
✔リーチできれば利用する（P/S FIT）することを実証する
　　　　　　　　　　　　　：
以後省略

リスクを最小化する価値観でやらなかったら
どうなってるか

保有リスク量
時間引用: http://www.slideshare.net/clevergirl/ux-jackson-2013-oneday-lean-startup-workshop
製品開発モデルによるプロセス
あれ？誰も使わない。
もっと広告をフカセ！
だめだ、
イベントやるぞ！
ドカーンとやるぞ！
PRすっぞ！！！
バーンと広告うつぞ！
数週間準備

時間
保有リスク量

結果から学ぶ
仮説の実験
結果の計測
時間
保有リスク量
リピートユーザに
会ってヒアリング
同じような
利用シーンが
ありそう
セグメントの発見

結果から学ぶ
仮説の実験
結果の計測
時間
保有リスク量
リピートユーザから
把握できたセグメントに
広告を少量あてる
全然コンバージョン
しない
そのセグメントの存在は
幻だったのか。
あぶなかった・・・

結果から学ぶ
仮説の実験
結果の計測
時間
保有リスク量
広告のあてかたが
悪いリスクがある
広告をチューニング
それでも全然
コンバージョン
しない
やっぱなかった

エンジニアリングビジネス
PBL
リリー
ス
プランニ
ング
振り返り
MTG
レビュー
デイリー
MTG
Sprint/2weeks 開発タスク/Day
計測
構築
学習
デー
タ
アイ
デア
ビジネス
仮説リスト
※スクラムについての説明省きます

従来の
プロダクトバックログ
仮説検証型の
プロダクトバックログ
・仮説A検証用モック作成
・仮説B検証用ダミーボタン実装
根拠無し
根拠無し
根拠無し
事前検証
(エビデンス収集)
実証後の実装

エンジニアリングビジネス
PBL
リリー
ス
プランニ
ング
振り返り
MTG
レビュー
デイリー
MTG
計測
構築
学習
デー
タ
アイ
デア
ビジネス
仮説リスト
PBLに入ってからリリースされるまでの
リードタイムを最小化する
（学びまでの待ちを最小化する）

エンジニアリング
ビジネス
PBL
リリー
ス
プランニ
ング
振り返り
MTG
レビュー
デイリー
MTG
計測
構築
学習
デー
タ
アイ
デア
ビジネス
仮説リスト
セールス / マーケ
プランニ
ング
実行
学習

PBLに入ってからリリースされるまでの
リードタイムを最小化する
（学びまでの待ちを最小化する） 30

余分な機能のムダ
引き継ぎのムダ
再学習のムダ
未完成な作業のムダ
遅れのムダ
タスク切り替えのムダ
欠陥のムダ
30

余分な機能のムダ
目的にそぐわない過剰品質
使われない機能の実装
↓
コードベースの肥大化
メンテコスト増加
バグ混入率増加
30

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

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

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

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

引き継ぎのムダ
アーリーステージは
やることの母数が小さいのに、
役割分担をしすぎるとスイッチングコスト増加
母数が小さいなら1人でやったほうが早い
↓
クロスファンクショナルチーム
フルスタックエンジニア
マルチロールエンジニア

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

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

100%
%me

Scale

MySQL

MVP

iOS
iOS

KPI

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

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

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

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

バックエンド
エンジニア
フロント
エンジニア
プロダクト
オーナー
顧客
Feedback
承認レビュー
仕様確認
API開発 API開発
Front開発
デプロイ待ち待ち
フロー効率をあげていく
学ぶ（顧客のフィードバックを得る）までのリードタイム
エンジニア
(フロント＆バックエンド）
フロント
エンジニア
プロダクト
オーナー
顧客
Feedback
承認条件
API開発 Front開発デプロイ待ち
待ち
待ち
※先に提示された条件をパスすれば
リリース承認というルールにする等
※フルスタック（）な振る舞い
をすることで引き継ぎによる
ムダが減る
※ここにきて手戻りが
発生することも
学ぶ(顧客のフィードバックを得る)までのリードタイム

再学習のムダ
仮説検証型で実施したとしても、
結果を正しく計測し、学びにつなげていないと
同じ学習がまた必要になる
↓
複数の検証をしても濁りなく学べる分析基盤
検証設計時のゴール設定

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

仮説検証基盤要件方法
既存のユーザへの影響
を最小化
ユーザーを任意の属性
でセグメントする機能
管理コンソールの実装
(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系プラクティス見れば基本ソレ

活動基準会計
仮説検証、ひとつひとつに対して何を学ぶのか、検証するため
に何が必要なのか、どのように計測するのか、いくらかかるの
かを設計する。学びに対するムダの無い投資をする。
http://www.slideshare.net/i2key/45-developers-summit-2015-devsumi-devsumib#141

未完成な作業のムダ
遅れのムダ
タスク切り替えのムダ
大量のことを同時にやろうとすると仕掛中の作業の滞留が増える
一つひとつやるよりも、個々のリードタイムは増加する
↓
マルチタスクやめる
一個流し

リソース効率
フロー効率
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
リソース効率
（例）稼働率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

待ち行列理論
・100%の利用率の高速道路は、駐車場といっしょ
・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 B B B
C C C C C
C C C C C
C C C C C
月　火　水　木　金月　火　水　木　金月　火　水　木　金
リリースまでのリードタイム 1w
たくさんのことを同時に調整しようとするから
仕様の調整の「会議」やら「定例」やらがうまれる

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
たくさんのことを同時に調整しようとするから
仕様の調整の「会議」やら「定例」やらがうまれる
（例）
ペアプログラミング（フロー効率高め＆再学習のムダ削減効果）
モブプログラミング（フロー効率ビンビンッ＆再学習のムダ削減効果）

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

リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkan

Recommended

More Related Content

What's hot (20)

Similar to リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkan (20)

More from Itsuki Kuroda (14)

リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkan