Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
なぜ機能は少ない方がいいのか?
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
somei
January 06, 2026
Business
0
1
なぜ機能は少ない方がいいのか?
somei
January 06, 2026
Tweet
Share
More Decks by somei
See All by somei
アジャイルな見積もりと計画づくり 入門
somei
0
31
PBIを分割して柔軟な意思決定をしよう
somei
0
4
PBI分割のコツ
somei
0
23
認知のゆがみとは!?
somei
0
16
Other Decks in Business
See All in Business
キャリアコンサルティングの継続利用がキャリア自律に及ぼす効果の検証
techtekt
PRO
1
150
経営管理について / About Corporate Planning
loglass2019
0
7.5k
(15枚)NotebookLMのスライド生成機能で「絶対達成」「予材管理」「大量行動」の重要性を解説してもらう
nyattx
PRO
0
190
株式会社EventHub 会社紹介資料
eventhub
1
44k
採用ピッチ資料
s_kamada
0
420
未完成を最強の「通貨」に変える - civicship
hopin
0
190
Lego Agile Testing Workshop
pinboro
0
170
LW_brochure_business
lincwellhr
1
75k
Mercari-Fact-book_en
mercari_inc
2
32k
税理士法人チェスター_事務所紹介資料
mabhr
0
1k
【SBO勉強会】感謝されるAI活用&ツール導入法
sakiyogoro
1
240
ネクストビート 新卒向け会社紹介資料
nextbeat
1
530
Featured
See All Featured
First, design no harm
axbom
PRO
2
1.1k
<Decoding/> the Language of Devs - We Love SEO 2024
nikkihalliwell
1
130
Ten Tips & Tricks for a 🌱 transition
stuffmc
0
72
Marketing to machines
jonoalderson
1
4.7k
Product Roadmaps are Hard
iamctodd
PRO
55
12k
Lessons Learnt from Crawling 1000+ Websites
charlesmeaden
PRO
1
1.1k
Lightning Talk: Beautiful Slides for Beginners
inesmontani
PRO
1
440
The #1 spot is gone: here's how to win anyway
tamaranovitovic
2
950
The Power of CSS Pseudo Elements
geoffreycrofte
80
6.2k
Gemini Prompt Engineering: Practical Techniques for Tangible AI Outcomes
mfonobong
2
280
Game over? The fight for quality and originality in the time of robots
wayneb77
1
120
The Impact of AI in SEO - AI Overviews June 2024 Edition
aleyda
5
740
Transcript
なぜ 機能は少ない方がいい のか?
観点1
2 : 8
2:8の法則 ユーザーの80%は機能の20%しか使わない
ユーザーはコア価値(20%) に金を払う その逆ではない 「ユーザーは火を消すためならバケツに穴が空いてても構わず使う」
ユーザーはコア価値(20%) に金を払う その逆ではない 「ユーザーは火を消すためならバケツに穴が空いてても構わず使う」 「ビタミン剤ではなく痛み止めを作れ」 「髪の毛が燃えているような問題を解決しろ」 とかも言われたりするよね
80%の機能ために20%の機能の提供が遅れるのは本末転倒 あったら嬉しい機能のために、 無くてはならない機能が使えるようになるのが5倍先になるのはつらい 😢
リリースは遅れれば遅れるほど多数の機会損失を生む ユーザーが価値を享受できる 機会の先送り 営業における武器の欠落 CS対応コストの高止まり
コア価値を少しでも早く提供することが肝要
観点2
仮説検証思考
私たちは 「こういった機能があればユーザーは喜ぶのではないか?」 「儲かるのではないか?」 と考えて開発する
しかし、市場に投入されていない価値はすべて仮説(妄想)にすぎない
ユーザーが求めるものを勘違いして失敗したプロダクト
仮説検証サイクル 仮説構築 検証計画 実行 測定 学習 仮説を市場に投入にして実際の価値を検証しまた次の仮説を立てる を繰り返すことにより”正しい”価値にたどり着く可能性を上げる
仮説検証サイクルは数を回すことが重要 リリースあたりの機能セットが小さいほど仮説検証サイクルを多く回せる 仮説構築 検証計画 実行 測定 学習 仮説構築 検証計画 実行
測定 学習 仮説構築 検証計画 実行 測定 学習 仮説構築 検証計画 実行 測定 学習 仮説構築 検証計画 実行 測定 学習 仮説構築 検証計画 実行 測定 学習 仮説構築 検証計画 実行 測定 学習
1リリースあたりの機能を減らし 仮説検証を小さくを繰り返すことで 正しい価値を届ける
観点3
開発スピードと品質
ソフトウェアの機能は裏側で相互に繋がっている 機能が6つで機能間の関係性が1対1だけ(かなり単純)と考えても 6C2 = 15
既存機能が多いと、新しく追加するときに考慮すべき項目が 非線形に増える 6C2 = 15 → 7C2 = 21 →
8C2 = 28 … 100C2 = 4950
その機能って、将来のコア機能を追加する際のコストを上げてまで追加 する必要あるんだっけ?
テストパターンはより深刻 機能ごとの取りうる状態3^機能数3=27 機能 ⋯ 状態 ⋮
テストパターンは機能が取りうる状態の分、累乗されていく ※組み合わせ爆発という 機能ごとの取りうる状態3^(機能数3+1)=81!! 機能 ⋯ 状態 ⋮
その機能って、将来のコア機能の品質を下げるリスクを 上げてまで追加する必要あるんだっけ? 機能 ⋯ 状態 ⋮
機能が少なければ少ないほど 将来の重要な機能の 開発スピードが早くなり品質リスクが低くなる
結論
てなわけで機能は少ない方がよい