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

リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ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

FitScaling

実証済み実証済み実証済み実証済み

実証済み

実証済み実証済み実証済み




その課題の解決策は妥当か

顧客発見顧客実証顧客開拓組織構築[ニーズ検証] [売って検証] [リーチ検証] [本格拡大]

実証済み

独自な価値提供を出来ているか

顧客は本当に買ってくれるか

コスト構造に無理がないか


最適な売り方の検証

最適な価格設定の検証


①①②③

①①②③

①①②③

⑤ ④ ⑤ ④⑥⑥

10


Problem Solution

Fit

Product Market

FitScaling


実証済み







実証済み








①①②③

①①②③

①①②③

⑤ ④ ⑤ ④⑥⑥

Retention CAC < LTV最大LTVセグメントの

比率を増やすバイラル係数 > 1

指標値の例

10





10

http://99designs.jp/

10

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

顧客デザイナー（世界100万人）

世界最大のデザイン特化型クラウドソーシングサービス

10

ロゴデザイン

http://99designs.jp/lp/logo-design-oss/

を日本に展開する

やること

を

やること

US市場においてProduct Market Fitし Scalingフェーズに入ったサービス

カスタマーセグメントが異なる非英語圏である日本に展開する


Problem Solution

Fit

Product Market

FitScaling


実証済み





Japan


Problem Solution

Fit

Product Market

FitScaling


実証済み





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

Japan


Problem Solution

Fit

Product Market

FitScaling


実証済み





Japan


Problem Solution

Fit

Product Market

FitScaling


実証済み





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

Japan





実証済み

実証済み

実証済み

実証済み

実証済み

実証済み


Product Market

Japan

売り物に関しては実証済みとして一旦、固定する

まずは売り方のチューニングだけでいけるか確認





実証済み

実証済み

実証済み

実証済み

実証済み

実証済み未実証 (日本市場依存)

Japan

未実証 (日本市場依存)

未実証 (日本市場依存)

Problem/Solution Fitしている前提に立ちプロダクト自体（売り物）をいじらずに

最適なカスタマーへ、最適なチャネル（売り方）でサービスが届き、利用されている状態をつくる

CAC < LTV

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

まず、検証すること

内緒

内緒

Japan

はやく安くクオリティの高いデザインが欲しい人

はやく安くクオリティの高いデザインが手に入る

オンライン広告

世界100万人のデザイナー

在庫コンペ型デザインクラソー

内緒

口コミ

良いデザイナーに出会えない多種多様な提案が欲しい

内緒

内緒

Japan





在庫

良いデザイナーに出会えないコンペ型デザ

インクラソー

内緒

口コミ

トートロジー何か言っているようで何も言っていない。よくありがちなバリュープロポジションとそのカスタマーセグメントの関係（笑）ドメインの理解が浅いとこうなりがち。

多種多様な提案が欲しい


Problem Solution

Fit

Product Market

FitScaling


実証済み







実証済み








①①②③

①①②③

①①②③

⑤ ④ ⑤ ④⑥⑥



指標値の例


Problem Solution

Fit

Product Market

FitScaling


実証済み







実証済み








①①②③

①①②③

①①②③

⑤ ④ ⑤ ④⑥⑥



指標値の例継続して使い続ける人継続して使い続けるセグメント＝Problem Solution Fitしてる人＝サービスはこの人の課題を解決できている＝この人はこのサービスを継続して使う理由を持っている


Problem Solution

Fit

Product Market

FitScaling


実証済み







実証済み








①①②③

①①②③

①①②③

⑤ ④ ⑤ ④⑥⑥




この継続している利用者/継続しているセグメントにインタビューをして、使っている理由を知る

なぜ99designsを選んだのか(UVP) どこに価値を感じたのか(UVP)

どんな課題を解決したのか(Problem/Solution) 今までのやりかたとくらべてどうか(代替手段)

どうやって（誰から）知ったか(chanel) ：：

「過去を振り返って事実のみをきく。」 (使ってくださった直後のユーザーさんとか最高)


Problem Solution

Fit

Product Market

FitScaling


実証済み







実証済み








①①②③

①①②③

①①②③

⑤ ④ ⑤ ④⑥⑥




この継続している利用者/継続しているセグメントにインタビューをして、使っている理由を知る

なぜ99designsを選んだのか(UVP) どこに価値を感じたのか(UVP)

どんな課題を解決したのか(Problem/Solution) 今までのやりかたとくらべてどうか(代替手段)

どうやって（誰から）知ったか(chanel) ：：

「過去を振り返って事実のみをきく。」 (使ってくださった直後のユーザーさんとか最高)

これを何人もにやると共通項（スケーラブルな部分）

「日本国外に通用するデザインのニーズ」の存在が見えてくる

そしていくかのセグメントを見立てることが

できるようになる

内緒

内緒

Japan




グローバルで通用するデザインを手に入れられる。（はやいやすい質が良いは前提）

日本から海外へ国境を越えていくようなカスタマー・オープンソース・ソフトウェアのエンジニア・ウェブサービス/スマホアプリでの起業家・プロダクトをグローバル進出させようとしている企業（食品会社、化粧品会社、etc）・越境ECコンサル・アーティスト、音楽事務所・SNSカバーデザイン　　　：　　　：

海外市場にフィットしたデザインが出来るデザイナに出会えない

コンペ型デザインクラソー


在庫

内緒

日本人デザイナーが海外で好まれるデザインセンスを持ってない

口コミ

✔日本市場におけるカスタマーセグメントを明らかにする □そのカスタマーセグメントの存在を実証する □リーチできれば利用する（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


グローバルで通用するデザインを手に入れられる。（はやいやすい質が良いは前提）

海外市場にフィットしたデザインが出来るデザイナに出会えない

コンペ型デザインクラソー


在庫

内緒

日本人デザイナーが海外で好まれるデザインセンスを持ってない

口コミ

日本から海外へ国境を越えていくようなカスタマー [○]・オープンソース・ソフトウェアのエンジニア [○]・ウェブサービス/スマホアプリでの起業家 [○]・プロダクトをグローバル進出させようとしている企業（食品会社、化粧品会社、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,onFit Product/MarketFit 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

バックエンドエンジニア



顧客Feedback

承認レビュー

仕様確認

API開発 API開発

Front開発

デプロイ待ち待ち

フロー効率をあげていく学ぶ（顧客のフィードバックを得る）までのリードタイム

エンジニア (フロント＆バックエンド）



顧客 Feedback

承認条件

API開発 Front開発デプロイ待ち待ち

待ち

※先に提示された条件をパスすればリリース承認というルールにする等

※フルスタック（）な振る舞いをすることで引き継ぎによる

ムダが減る

※ここにきて手戻りが発生することも

学ぶ(顧客のフィードバックを得る)までのリードタイム

待ち行列理論・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

リリースまでのリードタイム 2w


リリースまでのリードタイム 3wリリースまでのリードタイム 3w


たくさんのことを同時に調整しようとするから仕様の調整の「会議」やら「定例」やらがうまれる

マルチタスクやめる

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



リリースまでのリードタイム 3wリリースまでのリードタイム 3w


たくさんのことを同時に調整しようとするから仕様の調整の「会議」やら「定例」やらがうまれる

（例）ペアプログラミング（フロー効率高め＆再学習のムダ削減効果）モブプログラミング（フロー効率ビンビンッ＆再学習のムダ削減効果）

まとめ

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

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

Small Business & Entrepreneurship