Slide 1

Slide 1 text

プロダクトバックログは妄想の塊

Slide 2

Slide 2 text

永瀬美穂 / Nagase Miho 2 受託開発の現場でWebアプリケーションエンジニア、プロジェクトマ ネージャーとしての経験を重ね、2009年頃より所属組織でのアジャイ ルの導入と実践を通じ組織マネジメントを行う。現在は顧客へのアジャ イル導入支援、教育研修、コーチングをしながら、大学教育にも力を入 れている。産業技術大学院大学客員教授。

Slide 3

Slide 3 text

プロダクトバックログは妄想の塊 ✤ あったら嬉しい(はず) ✤ あったら便利(なはず) ✤ ユーザーはこれを欲しがっている(はず) 3

Slide 4

Slide 4 text

妄想というとカッコ悪いので "仮説"というとそれっぽくなる 4

Slide 5

Slide 5 text

仮説(妄想)の扱い ✤ 仮説(妄想)を検証する ✤ 仮説(妄想)が実証できる:「〜なはず」が当たった ✤ 仮説(妄想)が棄却される:「〜なはず」が当たらなかった ✤ スプリントレビューでは「どんな仮説(妄想)を検証するのか?」が重要 ✤ 仮説(妄想)が実証または棄却できるデモになっているとなおよい 
 → プロダクトバックログアイテムの粒度や定義に関わる ✤ 「ふーん」「すごい」「よさそう(棒読み)」はクソリプ ✤ デモできないのは論外 5

Slide 6

Slide 6 text

実装にはコストがかかる 妄想のまま実装するのはリスク 6

Slide 7

Slide 7 text

妄想を膨らませる前にさっさと確認する 7

Slide 8

Slide 8 text

「建物の外に出よ」 "Get out of the building" - Steve Blank 8

Slide 9

Slide 9 text

手早くさっさとフィードバックをもらう方法 ✤ インタビュー ✤ ペーパープロトタイピング ✤ モックアップ ✤ etc... 9

Slide 10

Slide 10 text

顧客はあなたのソリューションに興味はない。 
 興味があるのは、顧客自信の課題だ。 デイブ・マクルーア、500 Startup社 10 10

Slide 11

Slide 11 text

ソリューションではなく課題に注目する ✤ ソリューションは仮説(妄想) ✤ 課題は妄想度合いは低そう(≒事実⚠) ✤ 他人の課題 ✤ 自分の課題←圧倒的当事者 
 ⚠ 事実であるかどうかを確認するためには検証が必要 11

Slide 12

Slide 12 text

基本に立ち戻れ ✤ 「ソフトウェアの分野で最も協力で、最も長続きしている ムーブメント」 ✤ 「小さなソフトウェアチームが小さなプロジェクトをマネジ メントするための小さな規律である」 12

Slide 13

Slide 13 text

さっさと確認したらさっさと作って見せて検証する 13

Slide 14

Slide 14 text

留意すること ✤ 棄却されるのは仮説(妄想)であって、あなた自身が否定されるのではない ✤ 完璧主義をこじらせない ✤ かけた時間とアイデアの素晴らしさは比例しない ✤ 研修は安全に失敗できる場である ✤ 今後の人生で最高のプロダクトを作るための練習 ✤ 今回の研修で完璧なものを作ることを期待しない(だったら起業してるやろ💰) ✤ とはいえ与えられた環境で最高の結果を出そう(最高とは🤔) 14