Running Lean 第13章 機能の押し売りはやめよう
Tw: @technopreneurjp
Fb: https://www.facebook.com/technopreneurjp
8 July, 2013
第13章の内容
13.1 機能は押しつけずに引っ張ってもらう
13.2 80/20ルールを実施する
13.3 機能の流れを抑制する
13.4 機能要求を処理する
13.5 機能ライフサイクル
2
機能は押しつけずに引っ張ってもらう
機能は作りすぎないこと
プロセスを効率化するとたくさんつくれる
でも注意が必要、方向性は正しいか?
いろいろつくってはいけない理由
追加機能は独自の価値提案(UVP)を薄める
• シンプルな製品はシンプルに理解できる
すぐにMVPに見切りをつけてはだめ
• 新しい機能を追いかける前に、既存機能で解決できないか考え
る
機能には隠れたコストがある
• テスト、スクリーンショット、動画、調整、複雑性、注意散漫
顧客は本当に欲しいものをわかっていない
• 追加機能はとりあえずバックログに
3
p.161
本当の見込み客がいる優れ
た市場では、市場がスター
トアップから製品を引っ張
る。
80/20ルールを実施する
優先順位のつけ方
80/20ルールに従う
重要なところに80%の時間を割く
ローンチ後は
新機能を追いかけるよりも
既存機能の計測と改良を
4
既存の機能 新機能
20%
80%
機能の流れを抑制する
改良するなら、効果のある機能で
そもそも、着手する機能の数は抑える
開発した機能の影響を検証した後で新機能に着手
かんばんボードを使う
機能の追跡に使う
マクロ視点でとらえる
5
バックログ 作業中 完了
・既存機能の改良
・顧客の機能要求
・自分たちの機能要求
(あればうれしい機能)
製品の目標に基づいた
優先順位で上から下に
並べる
機能数 = チーム人数
バケツ
→一定以上の仕事はできない
この機能は役に立つ?
機能要求を処理する
できることはすぐやる
GTD(Getting Things Done)
6
正しい行動で
適切な時期か?
小さな機能
またはバグか?
緊急か?
あとでやる
あとでやる
対応する
タスクボード
かんばんボー
ド
無視する
はい
いいえ
はい いいえ
いいえはい
はじめてのGTD
ストレスフリーの整理術
二見書房
必要性、
優先順位の確認
すぐできるか、
時間が必要かを確認
緊急度を確認 MMF
Minimum Marketable Feature
顧客に価値を提供できる
最小限の部分
今やるべきか、後でもいいのか
機能ライフサイクル
かんばんボードで機能を追跡する
7
バックログ 作業中 完了 検証による学
習
モックアッ
プ
デモ 実装 部分的展開 定性的検証 全面展開 定量的検証
目標: アクティベーション率60%達成
準備
目標に合わせて優先順位をつける
扱える機能はここでは3つが限度
あとはバッファ(下部)に置く
課題を理解する
解決に値する課題か見極める
なぜその機能が必要か?
(顧客に聞く、レビューする)
機能ライフサイクル
かんばんボードで機能を追跡する
8
バックログ 作業中 完了 検証による学
習
モックアッ
プ
デモ 実装 部分的展開 定性的検証 全面展開 定量的検証
目標: アクティベーション率60%達成
ソリューションを決定する
モックアップをつくる
次に進む強いシグナルを受け取るまで反復
モックアップが検証できたら実装に進む
機能ライフサイクル
かんばんボードで機能を追跡する
9
バックログ 作業中 完了 検証による学
習
モックアッ
プ
デモ 実装 部分的展開 定性的検証 全面展開 定量的検証
目標: アクティベーション率60%達成
定性的に検証する
少数の顧客にデプロイする
ユーザビリティインタビュー
機能ライフサイクル
かんばんボードで機能を追跡する
10
バックログ 作業中 完了 検証による学
習
モックアッ
プ
デモ 実装 部分的展開 定性的検証 全面展開 定量的検証
目標: アクティベーション率60%達成
定量的に検証する
定性的検証が終わったら、機能を展開
コンバージョンダッシュボードで検証
(この機能は役に立つか?)
第13章 まとめ
機能の押し売りはやめよう
機能はつくりすぎないこと
新機能を追いかけるよりも、既存機能の計測と改良を
(新機能にかける時間は全体の20%まで)
機能開発の管理はかんばんボードで
11
Backup
12
用語の定義
MVP
Minimum Viable Product
プロダクト全体を指す(ex.車)
MMF
Minimum Marketable Features
ひとつの機能を指す(ex.サンルーフ)
これだけでは価値は生まれない
MVP = Σ MMF
13
用語の定義
スプリットテスト
異なるバージョンのテストを同時並行で顧客に提供する実験
別名 A/Bテスト
カタログ通販の例
• 新デザインの効果を確かめるには、顧客の半分には新し
いデザインのカタログを、残りの半分には古いデザイン
のカタログを送付する
• 2つのグループで売上を比較すればデザインの効果が判断
できる
スプリットテストはマーケティングでのみ利用されると思われ
がちだが、リーン・スタートアップでは製品開発に利用する
エンジニアやデザイナの目には改良と思える機能の多くが、顧
客の行動にどの程度影響するかがわかる
14
更新履歴
15
1
作成日 8 July,
2013
作成者 technopreneurjp
新規作成
2
変更日 変更者
3
変更日 変更者
4
変更日 変更者
5
変更日 変更者
→
変更日 変更者

Running Lean Cp13