なぜ機能は少ない方がいいのか？

Transcript

1. なぜ 機能は少ない方がいい のか？
2. 観点１
3. 2 : 8
4. 2:8の法則 ユーザーの80%は機能の20%しか使わない
5. ユーザーはコア価値（20%） に金を払う その逆ではない 「ユーザーは火を消すためならバケツに穴が空いてても構わず使う」
6. ユーザーはコア価値（20%） に金を払う その逆ではない 「ユーザーは火を消すためならバケツに穴が空いてても構わず使う」 「ビタミン剤ではなく痛み止めを作れ」 「髪の毛が燃えているような問題を解決しろ」 とかも言われたりするよね
7. 80%の機能ために20%の機能の提供が遅れるのは本末転倒 あったら嬉しい機能のために、 無くてはならない機能が使えるようになるのが5倍先になるのはつらい 😢
8. リリースは遅れれば遅れるほど多数の機会損失を生む ユーザーが価値を享受できる 機会の先送り 営業における武器の欠落 CS対応コストの高止まり
9. コア価値を少しでも早く提供することが肝要
10. 観点２
11. 仮説検証思考
12. 私たちは 「こういった機能があればユーザーは喜ぶのではないか？」 「儲かるのではないか？」 と考えて開発する
13. しかし、市場に投入されていない価値はすべて仮説（妄想）にすぎない
14. ユーザーが求めるものを勘違いして失敗したプロダクト
15. 仮説検証サイクル 仮説構築 検証計画 実行 測定 学習 仮説を市場に投入にして実際の価値を検証しまた次の仮説を立てる を繰り返すことにより”正しい”価値にたどり着く可能性を上げる
16. 仮説検証サイクルは数を回すことが重要 リリースあたりの機能セットが小さいほど仮説検証サイクルを多く回せる 仮説構築 検証計画 実行 測定 学習 仮説構築 検証計画 実行 測定 学習 仮説構築 検証計画 実行 測定 学習 仮説構築 検証計画 実行 測定 学習 仮説構築 検証計画 実行 測定 学習 仮説構築 検証計画 実行 測定 学習 仮説構築 検証計画 実行 測定 学習
17. 1リリースあたりの機能を減らし 仮説検証を小さくを繰り返すことで 正しい価値を届ける
18. 観点３
19. 開発スピードと品質
20. ソフトウェアの機能は裏側で相互に繋がっている 機能が6つで機能間の関係性が1対1だけ（かなり単純）と考えても 6C2 = 15
21. 既存機能が多いと、新しく追加するときに考慮すべき項目が 非線形に増える 6C2 = 15 → 7C2 = 21 → 8C2 = 28 … 100C2 = 4950
22. その機能って、将来のコア機能を追加する際のコストを上げてまで追加 する必要あるんだっけ？
23. テストパターンはより深刻 機能ごとの取りうる状態3^機能数3=27 機能 ⋯ 状態 ⋮
24. テストパターンは機能が取りうる状態の分、累乗されていく ※組み合わせ爆発という 機能ごとの取りうる状態3^（機能数3+1）=81！！ 機能 ⋯ 状態 ⋮
25. その機能って、将来のコア機能の品質を下げるリスクを 上げてまで追加する必要あるんだっけ？ 機能 ⋯ 状態 ⋮
26. 機能が少なければ少ないほど 将来の重要な機能の 開発スピードが早くなり品質リスクが低くなる
27. 結論
28. てなわけで機能は少ない方がよい