PowerPoint プレゼンテーション...2015/12/16 · H26.7 H26.10 H28.3 低所開発完了 高所・上部開発開始 低所開発開始 高所・上部開発完了 (予定)
リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ...
-
Upload
itsuki-kuroda -
Category
Small Business & Entrepreneurship
-
view
1.717 -
download
0
Transcript of リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ...
本スライドは、下記イベントのために @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ループ)
学びまでのリードタイムを減らすエンジニアリング (アジャイル、リーンソフトウェア開発)
仮説検証型でやっていく勘所 (リーンスタートアップや顧客開発の概念説明)
ビジネスモデル上の ムダを減らすための仮説検証
(リーンキャンバス&BMLループ)
学びまでのリードタイムを減らすエンジニアリング (アジャイル、リーンソフトウェア開発)
ビジネスアイデア全てを仮説と捉えて、 それらを小さく分割して検証すること
ビジネスモデル上のボトルネックを 効率よく発見し効率よく解消する
ビジネスモデルのムリ・ムダ・ムラを省く
全部仮説全部思い込み
ファイル同期がいかに便利か、どのように動作するのかのプロモーション動画を作成し、Youtubeにアップロード。HackerNewsに流して、 事前登録者数をモニタリングでニーズを実証。
仮説を小さく実証する例①
例)写真加工アプリにフィルター購入機能を作ろう!!やりたいことの実装工数は3人月くらいかかりそうです。
あなたがこのプロダクトのオーナーならどうしますか?
①フィルター購入機能を3人月かけて実装する (一切購入されないリスクそのまま) ②フィルタ購入するボタン(ダミー)を用意して、全体のユーザーの10%に表示して確認し、本当に購入ボタンが押された回数を測定してから開発着手の判断をする。工数は2人日。 (本当に購入されるのかのみを検証)
②のほうが無駄の無い判断
仮説を小さく実証する例②
保有リスク量
時間引用: http://www.slideshare.net/clevergirl/ux-jackson-2013-oneday-lean-startup-workshop
製品開発モデルプロセス
あれ?流行らない。 よし、機能追加だ!
もっと豪華な フィルターを売るぞ!
まだまだ機能が 足らんぞおおお!
マーケットプレイスに すべきだ!!!!
フィルター購入機能を つくるぞ!
3人月使われない機能を作るムダ
使われない機能を作るムダ
顧客発見 顧客実証 顧客開拓 組織構築
顧客開発モデルによるプロセス (仮説検証型プロセス)
「ヒト・モノ・カネを散々投じた挙げ句誰も欲しがらないものを開発してしまう」という新規事業・新商品の典型的失敗を避けるためのプロセス
顧客相手に仮説検証を繰り返し、リスクを潰していく
[ニーズ検証] [売って検証] [リーチ検証] [本格拡大]
結果から学ぶ
仮説の実験結果の計測
時間
保有リスク量
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
顧客は誰?課題は何?解決策は?
価値は何?圧倒的優位性は何?
コスト構造は? 売り上げは?
顧客にリーチするための チャネルは何を測る? 実証済み
実証済み実証済み
実証済み
実証済み実証済み
実証済み
目指す状態
深い課題を抱えた顧客がいるか
Problem Solution
Fit
Product Market
FitScaling
実証済み 実証済み実証済み 実証済み
実証済み
実証済み 実証済み実証済み
実証済み 実証済み
実証済み実証済み
実証済み 実証済み
その課題の解決策は妥当か
顧客発見 顧客実証 顧客開拓 組織構築[ニーズ検証] [売って検証] [リーチ検証] [本格拡大]
実証済み
独自な価値提供を出来ているか
顧客は本当に買ってくれるか
コスト構造に無理がないか
独自な価値提供を出来ているか
最適な売り方の検証
最適な価格設定の検証
独自な価値提供を出来ているか
①①②③
①①②③
①①②③
⑤ ④ ⑤ ④⑥⑥
10
深い課題を抱えた顧客がいるか
Problem Solution
Fit
Product Market
FitScaling
実証済み 実証済み実証済み 実証済み
実証済み
実証済み 実証済み実証済み
実証済み 実証済み
実証済み実証済み
実証済み 実証済み
その課題の解決策は妥当か
顧客発見 顧客実証 顧客開拓 組織構築[ニーズ検証] [売って検証] [リーチ検証] [本格拡大]
実証済み
独自な価値提供を出来ているか
顧客は本当に買ってくれるか
コスト構造に無理がないか
独自な価値提供を出来ているか
最適な売り方の検証
最適な価格設定の検証
独自な価値提供を出来ているか
①①②③
①①②③
①①②③
⑤ ④ ⑤ ④⑥⑥
Retention CAC < LTV最大LTVセグメントの
比率を増やすバイラル係数 > 1
指標値の例
10
仮説検証型でやっていく勘所 (リーンスタートアップや顧客開発の概念説明)
ビジネスモデル上の ムダを減らすための仮説検証
(リーンキャンバス&BMLループ)
学びまでのリードタイムを減らすエンジニアリング (アジャイル、リーンソフトウェア開発)
10
顧客発見 顧客実証 顧客開拓 組織構築
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
顧客は誰?課題は何?解決策は?
価値は何?圧倒的優位性は何?
コスト構造は? 売り上げは?
顧客にリーチするための チャネルは何を測る?
実証済み
実証済み
実証済み
実証済み
実証済み
実証済み
実証済み実証済み 実証済み
顧客は誰?課題は何?解決策は?
価値は何?圧倒的優位性は何?
コスト構造は? 売り上げは?
顧客にリーチするための チャネルは何を測る?
実証済み
実証済み
実証済み
実証済み
実証済み
実証済み 未実証 (日本市場依存)
Japan
未実証 (日本市場依存)
未実証 (日本市場依存)
Problem/Solution Fitしている前提に立ち プロダクト自体(売り物)をいじらずに
最適なカスタマーへ、最適なチャネル(売り方)で サービスが届き、利用されている状態をつくる
CAC < LTV
□日本市場におけるカスタマーセグメントを明らかにする □そのカスタマーセグメントの存在を実証する □リーチできれば利用する(P/S FIT)することを実証する □リーチするためのチャネルの検証をする :
まず、検証すること
内緒
内緒
Japan
はやく安く クオリティの 高いデザインが欲しい人
はやく安く クオリティの 高いデザインが手に入る
オンライン 広告
世界100万人のデザイナー
在庫コンペ型デザインクラソー
内緒
口コミ
良いデザイナーに出会えない多種多様な提案が欲しい
内緒
内緒
Japan
はやく安く クオリティの 高いデザインが欲しい人
はやく安く クオリティの 高いデザインが手に入る
オンライン 広告
世界100万人のデザイナー
在庫
良いデザイナーに出会えない コンペ型デザ
インクラソー
内緒
口コミ
トートロジー 何か言っているようで何も言っていない。 よくありがちなバリュープロポジションと そのカスタマーセグメントの関係(笑) ドメインの理解が浅いとこうなりがち。
多種多様な提案が欲しい
深い課題を抱えた顧客がいるか
Problem Solution
Fit
Product Market
FitScaling
実証済み 実証済み実証済み 実証済み
実証済み
実証済み 実証済み実証済み
実証済み 実証済み
実証済み実証済み
実証済み 実証済み
その課題の解決策は妥当か
顧客発見 顧客実証 顧客開拓 組織構築[ニーズ検証] [売って検証] [リーチ検証] [本格拡大]
実証済み
独自な価値提供を出来ているか
顧客は本当に買ってくれるか
コスト構造に無理がないか
独自な価値提供を出来ているか
最適な売り方の検証
最適な価格設定の検証
独自な価値提供を出来ているか
①①②③
①①②③
①①②③
⑤ ④ ⑤ ④⑥⑥
Retention CAC < LTV最大LTVセグメントの
比率を増やすバイラル係数 > 1
指標値の例
深い課題を抱えた顧客がいるか
Problem Solution
Fit
Product Market
FitScaling
実証済み 実証済み実証済み 実証済み
実証済み
実証済み 実証済み実証済み
実証済み 実証済み
実証済み実証済み
実証済み 実証済み
その課題の解決策は妥当か
顧客発見 顧客実証 顧客開拓 組織構築[ニーズ検証] [売って検証] [リーチ検証] [本格拡大]
実証済み
独自な価値提供を出来ているか
顧客は本当に買ってくれるか
コスト構造に無理がないか
独自な価値提供を出来ているか
最適な売り方の検証
最適な価格設定の検証
独自な価値提供を出来ているか
①①②③
①①②③
①①②③
⑤ ④ ⑤ ④⑥⑥
Retention CAC < LTV最大LTVセグメントの
比率を増やすバイラル係数 > 1
指標値の例継続して使い続ける人 継続して使い続けるセグメント =Problem Solution Fitしてる人 =サービスはこの人の課題を解決できている =この人はこのサービスを継続して使う理由を持っている
深い課題を抱えた顧客がいるか
Problem Solution
Fit
Product Market
FitScaling
実証済み 実証済み実証済み 実証済み
実証済み
実証済み 実証済み実証済み
実証済み 実証済み
実証済み実証済み
実証済み 実証済み
その課題の解決策は妥当か
顧客発見 顧客実証 顧客開拓 組織構築[ニーズ検証] [売って検証] [リーチ検証] [本格拡大]
実証済み
独自な価値提供を出来ているか
顧客は本当に買ってくれるか
コスト構造に無理がないか
独自な価値提供を出来ているか
最適な売り方の検証
最適な価格設定の検証
独自な価値提供を出来ているか
①①②③
①①②③
①①②③
⑤ ④ ⑤ ④⑥⑥
Retention CAC < LTV最大LTVセグメントの
比率を増やすバイラル係数 > 1
指標値の例継続して使い続ける人 継続して使い続けるセグメント =Problem Solution Fitしてる人 =サービスはこの人の課題を解決できている =この人はこのサービスを継続して使う理由を持っている
この継続している利用者/継続しているセグメントにインタビューをして、使っている理由を知る
なぜ99designsを選んだのか(UVP) どこに価値を感じたのか(UVP)
どんな課題を解決したのか(Problem/Solution) 今までのやりかたとくらべてどうか(代替手段)
どうやって(誰から)知ったか(chanel) : :
「過去を振り返って事実のみをきく。」 (使ってくださった直後のユーザーさんとか最高)
深い課題を抱えた顧客がいるか
Problem Solution
Fit
Product Market
FitScaling
実証済み 実証済み実証済み 実証済み
実証済み
実証済み 実証済み実証済み
実証済み 実証済み
実証済み実証済み
実証済み 実証済み
その課題の解決策は妥当か
顧客発見 顧客実証 顧客開拓 組織構築[ニーズ検証] [売って検証] [リーチ検証] [本格拡大]
実証済み
独自な価値提供を出来ているか
顧客は本当に買ってくれるか
コスト構造に無理がないか
独自な価値提供を出来ているか
最適な売り方の検証
最適な価格設定の検証
独自な価値提供を出来ているか
①①②③
①①②③
①①②③
⑤ ④ ⑤ ④⑥⑥
Retention CAC < LTV最大LTVセグメントの
比率を増やすバイラル係数 > 1
指標値の例継続して使い続ける人 継続して使い続けるセグメント =Problem Solution Fitしてる人 =サービスはこの人の課題を解決できている =この人はこのサービスを継続して使う理由を持っている
この継続している利用者/継続しているセグメントにインタビューをして、使っている理由を知る
なぜ99designsを選んだのか(UVP) どこに価値を感じたのか(UVP)
どんな課題を解決したのか(Problem/Solution) 今までのやりかたとくらべてどうか(代替手段)
どうやって(誰から)知ったか(chanel) : :
「過去を振り返って事実のみをきく。」 (使ってくださった直後のユーザーさんとか最高)
これを何人もにやると 共通項(スケーラブルな部分)
「日本国外に通用するデザインのニーズ」の存在が見えてくる
そして いくかのセグメントを見立てることが
できるようになる
内緒
内緒
Japan
はやく安く クオリティの 高いデザインが欲しい人
はやく安く クオリティの 高いデザインが手に入る
オンライン 広告
グローバルで通用するデザインを手に入れられる。(はやいやすい質が良いは前提)
日本から海外へ国境を越えていくようなカスタマー ・オープンソース・ソフトウェアのエンジニア ・ウェブサービス/スマホアプリでの起業家 ・プロダクトをグローバル進出させようとしている企業(食品会社、化粧品会社、etc) ・越境ECコンサル ・アーティスト、音楽事務所 ・SNSカバーデザイン : :
海外市場にフィットしたデザインが出来るデザイナに出会えない
コンペ型デザインクラソー
世界100万人のデザイナー
在庫
内緒
日本人デザイナーが海外で好まれるデザインセンスを持ってない
口コミ
✔日本市場におけるカスタマーセグメントを明らかにする □そのカスタマーセグメントの存在を実証する □リーチできれば利用する(P/S FIT)することを実証する □リーチするためのチャネルの検証をする :
まず、検証すること
20
②何を学ぶのか ・コンバージョンする セグメントの存在有無③必要なデータは? セグメントに対する 一定量のCV
④どうやって計測する? セグメント毎に分けて
CVページで計測
⑤必要なものは? セグメント毎に 集客する装置
⑥どう構築するか? うーむ
思考プロセス①仮説 ・○○○なユーザセグメントが 存在するか
20
⑥どう構築するか? (MVP案1)セグメント単位に少量のオンライン広告を流してCV検証 (MVP案2)セグメント単位に営業をかけてCV検証 (MVP案3)セグメント単位にオーガニックにまつ
もっとも効果的に学びが得られるMVPはどれか選択する ・費用対効果 ・期間 ・工数 ・この検証方法により回避できる将来のリスク ・この検証方法により逆に発生する将来のリスク
思考プロセス
Acquisition
獲得 Retention
継続Churn
解約
Referral
紹介
Activation
活性化Revenue
収益
セグメント毎にいったん少量の水を流して 水漏れをみる(CVするか、PSFitするか)
広告
内緒
内緒
Japan
オンライン 広告
グローバルで通用するデザインを手に入れられる。(はやいやすい質が良いは前提)
海外市場にフィットしたデザインが出来るデザイナに出会えない
コンペ型デザインクラソー
世界100万人のデザイナー
在庫
内緒
日本人デザイナーが海外で好まれるデザインセンスを持ってない
口コミ
日本から海外へ国境を越えていくようなカスタマー [○]・オープンソース・ソフトウェアのエンジニア [○]・ウェブサービス/スマホアプリでの起業家 [○]・プロダクトをグローバル進出させようとしている企業(食品会社、化粧品会社、etc) [○]・越境ECコンサル [×]アーティスト、音楽事務所 [×]SNSカバーデザイン : :
✔日本市場におけるカスタマーセグメントを明らかにする ✔そのカスタマーセグメントの存在を実証する ✔リーチできれば利用する(P/S FIT)することを実証する □リーチするためのチャネルの検証をする :
まず、検証すること
以後省略
保有リスク量
時間引用: http://www.slideshare.net/clevergirl/ux-jackson-2013-oneday-lean-startup-workshop
製品開発モデルによるプロセス
あれ?誰も使わない。 もっと広告をフカセ!
だめだ、 イベントやるぞ!
ドカーンとやるぞ!
PRすっぞ!!! バーンと広告うつぞ!
数週間準備
結果から学ぶ
仮説の実験結果の計測
時間
保有リスク量リピートユーザから
把握できたセグメントに 広告を少量あてる
全然コンバージョン しない
そのセグメントの存在は 幻だったのか。
あぶなかった・・・ (リスクがゼロになる)
顧客開発モデルによるプロセス
結果から学ぶ
仮説の実験結果の計測
時間
保有リスク量広告のあてかたが 悪いリスクがある
広告をチューニング
それでも全然 コンバージョン
しない
やっぱなかった (リスクがゼロになる)
顧客開発モデルによるプロセス
仮説検証型でやっていく勘所 (リーンスタートアップや顧客開発の概念説明)
ビジネスモデル上の ムダを減らすための仮説検証
(リーンキャンバス&BMLループ)
学びまでのリードタイムを減らすエンジニアリング (アジャイル、リーンソフトウェア開発)
エンジニアリングビジネス
PBL
リリース
プランニング
振り返り MTG
レビュー
デイリー MTG
Sprint/2weeks 開発タスク/Day
計測
構築
学習
データ
アイデア
ビジネス仮説リスト
※スクラムについての説明省きます
従来の プロダクトバックログ
仮説検証型の プロダクトバックログ
・仮説A検証用モック作成 ・仮説B検証用ダミーボタン実装 ・検証済み○○機能本実装 ・検証済み○○機能本実装
・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装
根拠無し
根拠無し
根拠無し
事前検証 (エビデンス収集)
実証後の実装
エンジニアリングビジネス
PBL
リリース
プランニング
振り返り MTG
レビュー
デイリー MTG
Sprint/2weeks 開発タスク/Day
計測
構築
学習
データ
アイデア
ビジネス仮説リスト
PBLに入ってからリリースされるまでの リードタイムを最小化する
(学びまでの待ちを最小化する)
エンジニアリングビジネス
PBL
リリース
プランニング
振り返り MTG
レビュー
デイリー MTG
Sprint/2weeks 開発タスク/Day
計測
構築
学習
データ
アイデア
ビジネス仮説リスト
セールス / マーケ
プランニング
実行
学習
充足不充足
満足
不満足
顧客の満足感
物理的な充足度
魅力品質
当たり前品質 アーリーアダプターには ここ弱めにするか。とか マネタイズ検証時には
必要だね。とか Minimum Sellable Product
性能品質
魅力品質
性能品質
当たり前品質
不充足でも不満には思わないが、 充足されれば満足 <例> ハイレゾ音源(あれば良いが、なくても不満ではない)、曲面液晶など
不充足だと不満、充足されると満足 <例> バッテリーの持ち(稼働時間が長ければ満足、短いと不満)、重量など
不充足だと不満、充足されて当たり前 <例> 通話音声(音が良くて当たり前、聞き取りづらいと不満)
狩野モデル一般論
深い課題を抱えた顧客がいるか
その課題の解決策は妥当か
顧客発見 顧客実証 顧客開拓 組織構築[ニーズ検証] [売って検証] [リーチ検証] [本格拡大]独自な価値提供を出来ているか
顧客は本当に買ってくれるか
コスト構造に無理がないか
独自な価値提供を出来ているか
最適な売り方の検証
最適な価格設定の検証
独自な価値提供を出来ているか
Problem Solution
Fit
Product Market
Fit Scaling
Retention CAC < LTV 最大LTVセグメントの比率
課題解決可能 な最小限
売り方最適化 / 売上最大化売る
ビジネス フェーズ
狩野 モデル
魅力的品質 最低限の性能品質魅力的品質
当たり前品質アップセル・クロスセルに
向けた性能品質魅力的品質
当たり前品質
指標値例
検証アク ション
検証 ポイント
MVP 目標
MVP作って壊す
MVP 品質
最低限の 売れる状態
セグメントに応じて売れる状態 検証が既存ユーザに影響与えない
充足不充足
満足
不満足
顧客の満足感
物理的な充足度
魅力品質
当たり前品質 アーリーアダプターには ここ弱めにするか。とか マネタイズ検証時には
必要だね。とか Minimum Sellable Product
性能品質
魅力品質
性能品質
当たり前品質
不充足でも不満には思わないが、 充足されれば満足 <例> ハイレゾ音源(あれば良いが、なくても不満ではない)、曲面液晶など
不充足だと不満、充足されると満足 <例> バッテリーの持ち(稼働時間が長ければ満足、短いと不満)、重量など
不充足だと不満、充足されて当たり前 <例> 通話音声(音が良くて当たり前、聞き取りづらいと不満)
狩野モデル
充足不充足
満足
不満足
顧客の満足感
物理的な充足度
魅力品質
当たり前品質 アーリーアダプターには ここ弱めにするか。とか マネタイズ検証時には
必要だね。とか Minimum Sellable Product
性能品質
魅力品質
性能品質
当たり前品質
不充足でも不満には思わないが、 充足されれば満足 <例> ハイレゾ音源(あれば良いが、なくても不満ではない)、曲面液晶など
不充足だと不満、充足されると満足 <例> バッテリーの持ち(稼働時間が長ければ満足、短いと不満)、重量など
不充足だと不満、充足されて当たり前 <例> 通話音声(音が良くて当たり前、聞き取りづらいと不満)
狩野モデル
充足不充足
満足
不満足
顧客の満足感
物理的な充足度
魅力品質
当たり前品質 アーリーアダプターには ここ弱めにするか。とか マネタイズ検証時には
必要だね。とか 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
検証を設計する (実証条件/実証方法/etc)
効果を計測する
KPI(数値目標)を設定する
リリースする
ユーザがコンバージョンする
仮説をたてる
仕様にする
設計する
ユーザーに届く
ユーザーが使う
ユーザーが気づく
KPI(数値目標)達成
指標:ベロシティ/デプロイ回数/性能値/品質/コスト/etc
エンジニアのコミットと目標
データから学ぶ (仮説を修正する
打ち手を変える)
エンジニアが直接結果を コントロール出来る範囲
(コードのみに対峙してる)エンジニアが直接結果を
コントロール出来ない範囲 (ユーザーの判断という不確実性が介在)
テストする
実装する
指標:MAU/継続率/○○率/売上/etc
マルチロールに しみ出す
検証を設計する (実証条件/実証方法/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リリースまでのリードタイム 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
リリースまでのリードタイム 2w
リリースまでのリードタイム 3w
リリースまでのリードタイム 3wリリースまでのリードタイム 3w
リリースまでのリードタイム 3w
たくさんのことを同時に調整しようとするから 仕様の調整の「会議」やら「定例」やらがうまれる
(例) ペアプログラミング(フロー効率高め&再学習のムダ削減効果) モブプログラミング(フロー効率ビンビンッ&再学習のムダ削減効果)