妄想を練り上げてないでさっさと作ってフィードバックもらおうねという話をしました
プロダクトバックログは妄想の塊
View Slide
永瀬美穂 / Nagase Miho2受託開発の現場でWebアプリケーションエンジニア、プロジェクトマネージャーとしての経験を重ね、2009年頃より所属組織でのアジャイルの導入と実践を通じ組織マネジメントを行う。現在は顧客へのアジャイル導入支援、教育研修、コーチングをしながら、大学教育にも力を入れている。産業技術大学院大学客員教授。
プロダクトバックログは妄想の塊✤ あったら嬉しい（はず）✤ あったら便利（なはず）✤ ユーザーはこれを欲しがっている（はず）3
妄想というとカッコ悪いので"仮説"というとそれっぽくなる4
仮説（妄想）の扱い✤ 仮説（妄想）を検証する✤ 仮説（妄想）が実証できる：「〜なはず」が当たった✤ 仮説（妄想）が棄却される：「〜なはず」が当たらなかった✤ スプリントレビューでは「どんな仮説（妄想）を検証するのか？」が重要✤ 仮説（妄想）が実証または棄却できるデモになっているとなおよい → プロダクトバックログアイテムの粒度や定義に関わる✤ 「ふーん」「すごい」「よさそう（棒読み）」はクソリプ✤ デモできないのは論外5
実装にはコストがかかる妄想のまま実装するのはリスク6
妄想を膨らませる前にさっさと確認する7
「建物の外に出よ」"Get out of the building" - Steve Blank8
手早くさっさとフィードバックをもらう方法✤ インタビュー✤ ペーパープロトタイピング✤ モックアップ✤ etc...9
顧客はあなたのソリューションに興味はない。 興味があるのは、顧客自信の課題だ。デイブ・マクルーア、500 Startup社10 10
ソリューションではなく課題に注目する✤ ソリューションは仮説（妄想）✤ 課題は妄想度合いは低そう（≒事実⚠）✤ 他人の課題✤ 自分の課題←圧倒的当事者 ⚠ 事実であるかどうかを確認するためには検証が必要11
基本に立ち戻れ✤ 「ソフトウェアの分野で最も協力で、最も長続きしているムーブメント」✤ 「小さなソフトウェアチームが小さなプロジェクトをマネジメントするための小さな規律である」12
さっさと確認したらさっさと作って見せて検証する13
留意すること✤ 棄却されるのは仮説（妄想）であって、あなた自身が否定されるのではない✤ 完璧主義をこじらせない✤ かけた時間とアイデアの素晴らしさは比例しない✤ 研修は安全に失敗できる場である✤ 今後の人生で最高のプロダクトを作るための練習✤ 今回の研修で完璧なものを作ることを期待しない（だったら起業してるやろ💰）✤ とはいえ与えられた環境で最高の結果を出そう（最高とは🤔）14
miholovesq
line_developers
doradora09
hirosatogamo
iseki
orgachem
devops_vtj
visional_engineering_and_design
hayatokudou
arthur1
ybrliiu
ikuyamada
lmi
sstephenson
eileencodes
morganepeng
sugarenia
chriscoyier
tanoku
bkeepers
erikaheidi
mclloyd
mongodb
zenorocha