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
Hypothesis on Product Backlog
Search
Miho Nagase
June 15, 2021
Technology
0
240
Hypothesis on Product Backlog
妄想を練り上げてないでさっさと作ってフィードバックもらおうねという話をしました
Miho Nagase
June 15, 2021
Tweet
Share
More Decks by Miho Nagase
See All by Miho Nagase
Commitment vs Harrisonism - Keynote for Scrum Niseko 2024
miholovesq
6
3.1k
『チームトポロジー』と Platform Engineering
miholovesq
15
4.8k
コミュニケーションについて
miholovesq
1
300
F1 Fukuoka GP '23
miholovesq
0
2.3k
小さな「うっ」は成長のチャンス
miholovesq
0
2.4k
F1 Ochanomizu GP '23
miholovesq
0
4.6k
F1 Sapporo GP '22
miholovesq
0
680
F1 Sendai GP '22
miholovesq
0
1.2k
F1 Osaka GP '22
miholovesq
0
380
Other Decks in Technology
See All in Technology
モンテカルロ木探索のパフォーマンスを予測する Kaggleコンペ解説 〜生成AIによる未知のゲーム生成〜
rist
4
1.1k
アプリケーション固有の「ロジックの脆弱性」を防ぐ開発者のためのセキュリティ観点
flatt_security
32
11k
Vision Language Modelを活用した メルカリの類似画像レコメンドの性能改善
yadayuki
9
1.2k
AWS のポリシー言語 Cedar を活用した高速かつスケーラブルな認可技術の探求 #phperkaigi / PHPerKaigi 2025
ytaka23
7
1.5k
サーバシステムを無理なくコンテナ移行する際に伝えたい4つのポイント/Container_Happy_Migration_Method
ozawa
1
100
Agile TPIを活用した品質改善事例
tomasagi
0
310
コード品質向上で得られる効果と実践的取り組み
ham0215
2
200
一人QA時代が終わり、 QAチームが立ち上がった話
ma_cho29
0
290
Tirez profit de Messenger pour améliorer votre architecture
tucksaun
1
140
SaaSプロダクト開発におけるバグの早期検出のためのAcceptance testの取り組み
kworkdev
PRO
0
440
ソフトウェアプロジェクトの成功率が上がらない原因-「社会価値を考える」ということ-
ytanaka5569
0
130
Road to SRE NEXT@仙台 IVRyの組織の形とSLO運用の現状
abnoumaru
0
390
Featured
See All Featured
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
2.9k
Java REST API Framework Comparison - PWX 2021
mraible
29
8.5k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
22
2.6k
Fireside Chat
paigeccino
37
3.3k
Optimizing for Happiness
mojombo
377
70k
Into the Great Unknown - MozCon
thekraken
36
1.7k
What's in a price? How to price your products and services
michaelherold
245
12k
For a Future-Friendly Web
brad_frost
176
9.6k
A Tale of Four Properties
chriscoyier
158
23k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
40
2k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
135
33k
Raft: Consensus for Rubyists
vanstee
137
6.8k
Transcript
プロダクトバックログは妄想の塊
永瀬美穂 / Nagase Miho 2 受託開発の現場でWebアプリケーションエンジニア、プロジェクトマ ネージャーとしての経験を重ね、2009年頃より所属組織でのアジャイ ルの導入と実践を通じ組織マネジメントを行う。現在は顧客へのアジャ イル導入支援、教育研修、コーチングをしながら、大学教育にも力を入 れている。産業技術大学院大学客員教授。
プロダクトバックログは妄想の塊 ✤ あったら嬉しい(はず) ✤ あったら便利(なはず) ✤ ユーザーはこれを欲しがっている(はず) 3
妄想というとカッコ悪いので "仮説"というとそれっぽくなる 4
仮説(妄想)の扱い ✤ 仮説(妄想)を検証する ✤ 仮説(妄想)が実証できる:「〜なはず」が当たった ✤ 仮説(妄想)が棄却される:「〜なはず」が当たらなかった ✤ スプリントレビューでは「どんな仮説(妄想)を検証するのか?」が重要 ✤
仮説(妄想)が実証または棄却できるデモになっているとなおよい → プロダクトバックログアイテムの粒度や定義に関わる ✤ 「ふーん」「すごい」「よさそう(棒読み)」はクソリプ ✤ デモできないのは論外 5
実装にはコストがかかる 妄想のまま実装するのはリスク 6
妄想を膨らませる前にさっさと確認する 7
「建物の外に出よ」 "Get out of the building" - Steve Blank 8
手早くさっさとフィードバックをもらう方法 ✤ インタビュー ✤ ペーパープロトタイピング ✤ モックアップ ✤ etc... 9
顧客はあなたのソリューションに興味はない。 興味があるのは、顧客自信の課題だ。 デイブ・マクルーア、500 Startup社 10 10
ソリューションではなく課題に注目する ✤ ソリューションは仮説(妄想) ✤ 課題は妄想度合いは低そう(≒事実⚠) ✤ 他人の課題 ✤ 自分の課題←圧倒的当事者
⚠ 事実であるかどうかを確認するためには検証が必要 11
基本に立ち戻れ ✤ 「ソフトウェアの分野で最も協力で、最も長続きしている ムーブメント」 ✤ 「小さなソフトウェアチームが小さなプロジェクトをマネジ メントするための小さな規律である」 12
さっさと確認したらさっさと作って見せて検証する 13
留意すること ✤ 棄却されるのは仮説(妄想)であって、あなた自身が否定されるのではない ✤ 完璧主義をこじらせない ✤ かけた時間とアイデアの素晴らしさは比例しない ✤ 研修は安全に失敗できる場である ✤
今後の人生で最高のプロダクトを作るための練習 ✤ 今回の研修で完璧なものを作ることを期待しない(だったら起業してるやろ💰) ✤ とはいえ与えられた環境で最高の結果を出そう(最高とは🤔) 14