1. プロダクトバックログ Deep Dive 2022/1/6 Regional Scrum Gathering Tokyo 2022 株式会社アトラクタ 吉羽 龍太郎 (@ryuzee)
2. 自己紹介 吉羽龍太郎 / YOSHIBA RYUTARO ▸ アジャイル開発、DevOps、クラウドコンピューティング、 インフラ構築自動化、、組織改革を中心にオンサイトでの コンサルティングとトレーニングを提供。著書訳書多数 2
3. 自己紹介 最新書籍紹介（買ってください!!） 3
4. プロダクトバックログDEEP DIVE 4 「プロダクトバックログ」の登場回数（本文のみ） スクラムガイド 2011 46 スクラムガイド 2013 52 スクラムガイド 2016 58 スクラムガイド 2017 53 スクラムガイド 2020 31 ▸ スクラムガイドではたくさん登場する。それだけ重要だということ
9. プロダクトバックログDEEP DIVE プロダクトバックログとは？（スクラムガイド2020より） ▸ わずかな記述なのに、かなり多くのことが凝縮されている ▸ スクラムガイドを踏まえて、プロダクトバックログを深堀りしていきましょう 9
10. プロダクトバックログDEEP DIVE プロダクトバックログって何なの？ ▸ 創発的かつ順番に並べられた、プロダクトの改善に必要なものの一覧 ▸ スクラムチームが行う作業の唯一の情報源 ▸ プロダクトゴールはプロダクトバックログに含まれる ▸ プロダクトバックログアイテムは、プロダクトゴールを達成する「何か(what)」を定義するもの ▸ プロダクトバックログアイテムには、説明、並び順、サイズなどの要素が含まれる ▸ プロダクトオーナーが管理の責任を持つ（作業自体は委任できる） ▸ スプリントプランニングの時点で、そのスプリント分のアイテムは選択の準備ができている ▸ プロダクトバックログ = プロダクトゴール + プロダクトバックログアイテム 10
11. プロダクトバックログDEEP DIVE プロダクトゴールって何？ ▸ スクラムガイド2020で新たに導入された ▸ 「プロダクトビジョン」はよく聞くけど、「プロダクトゴール」とは何だろうか？ 11
12. プロダクトバックログDEEP DIVE 12 プロダクトビジョンとプロダクトゴールって何が違うの？ ▸ プロダクトビジョン ▸ プロダクトゴール ▸ 抽象的な考えや、プロダクトの開発開始前に顧 客から得たアイデア ▸ プロダクトが達成しなければいけない計測可能 で、持続可能な結果やアウトカム ▸ プロダクトゴールを決める上での根底となる目 的を述べたもの ▸ プロダクトビジョンから導き出された、チームメ ンバーが達成すべきことを述べたもの ▸ プロダクトが達成したいことの全体像を示す ▸ プロダクトビジョンを実現する上で、プロダクト が達成しなければいけない小さな目標 ▸ 特定の期間で評価されるものではない ▸ アイデアを顧客向けに説明したもので、ハイエン ドで抽象的なものになる ▸ 特定の期間で完成させて次のゴールに取り組む ▸ SMART（持続可能、計測可能、達成可能、現実 的、有期）の5つの要素を持つものになる 出典 「Product Vision Vs Product Goal」 https://premieragile.com/product-vision-vs-product-goal/
13. プロダクトバックログDEEP DIVE プロダクトバックログアイテム ▸ 書き方はスクラムでは決めていない ▸ ユーザーストーリーやユースケースを使うことが多い ▸ 最低限、順番、内容、見積りは含まれている必要がある ▸ スクラムガイド2017では価値も含めていた ▸ ユニークなIDがあると扱いやすい 13
14. プロダクトバックログDEEP DIVE 14 プロダクトバックログの例（あくまで例） 【プロダクトゴール】 ホテルの新規開業に向けてオンライン対応を可能にする # プロダクトバックログアイテム 見積り 1 ゲストとしてホテルを予約することができる 3 2 ゲストとしてホテルの予約をキャンセルできる 5 3 ゲストとして予約日時を変更できる 3 ... ... 34 ホテルの従業員として部屋ごとの収支レポートを作成できる 8 15 システム管理者としてエラーログが見れる 8 ... ... 40
15. プロダクトバックログDEEP DIVE プロダクトバックログの管理方法 ▸ スクラムガイドでは何も管理方法を定義していない ▸ 一般的なプラクティスとして ▸ スプレッドシート、情報カード、付箋紙、専用ツールなどで管理する ▸ どんなツールを使うかは状況次第 ▸ ただし、慣れないうちは専用ツール以外が良いことが多い ▸ お勧めはGoogle Spreadsheet ▸ 専用ツールを使う場合、無理に全項目を入れようとしないこと ▸ 複雑な問題に立ち向かうのに、プロセスやツールを複雑にしたくない 15
17. プロダクトバックログDEEP DIVE 17 大原則: スプリントゴールやスプリントレビューから逆算する ▸ スクラムの基本は「フィードバック」サイクルを回すこと ▸ プロダクトに対する定期的なフィードバックは成功の上でとても重要 ▸ つまり適切なスプリントゴールの設定、そのゴールを達成しているインクリメントをスプリントレビュー で見せられることを重視する必要がある ▸ インクリメントを見せられないのは論外 ▸ いま意味があるインクリメントを見せなければいけない ▸ これを踏まえてプロダクトバックログを整備する
18. プロダクトバックログDEEP DIVE 18 スプリントに投入するプロダクトバックログアイテムとスプリントゴールの関係 ▸ スプリントに投入するプロダクトバックログアイテムはスプリントゴールの達成に寄与するものが中心 になる ▸ ただし、現実的にはすべてのプロダクトバックログアイテムがそうなるとは限らない ▸ 将来の準備、バグの修正、セキュリティ対応、各種調査、リファクタリングは対応が必要 ▸ スプリントゴール直結のプロダクトバックログアイテムとそれ以外（上述）のプロダクトバックログアイ テムの比率を7:3程度にすることも多い
19. プロダクトバックログDEEP DIVE 大原則: 準備ができているプロダクトバックログアイテムだけを投入する ▸ 準備ができていないプロダクトバックログアイテムをスプリントに入れてしまうと何が起きる？ ▸ スプリント中に何度もプロダクトオーナーと仕様を確認することになる ▸ 着手したあとに、想像以上に規模が大きいことが分かる ▸ プロダクトオーナーに完成確認をしたときに、認識の相違が見つかる ▸ これらの結果として、選択したプロダクトバックログアイテムが完成しない確率が高まる ▸ スプリントごとの成果の量が不安定になり、予測精度が下がる ▸ つまり「生煮えプロダクトバックログアイテムを食べると腹を壊す」 ▸ これを防ぐために、準備ができているプロダクトバックログアイテムだけを投入する ▸ スクラムチームごとに、どこまで準備をすれば適切なのかは違う 19
20. プロダクトバックログDEEP DIVE 準備完了(READY)の定義を決めるチームもある（必須ではない） ▸ プロダクトバックログアイテムが用意されている ▸ プロダクトバックログアイテムの価値が明確である ▸ 開発を進める上での大きな疑問や決定すべき事項がない ▸ 開発者全員が何をつくればいいか理解できている ▸ 受け入れ基準が明確である ▸ 他のアイテムとの依存関係が明確である ▸ 見積もられている ▸ パフォーマンスなどの非機能要件が明確になっている ▸ デモの手順が明らかになっている 20
21. プロダクトバックログDEEP DIVE 21 スプリントに投入するプロダクトバックログアイテムの構成 XL ✕ L △ M ◯ M M L ◯ ✕ L S S S M S S S S S S 1つのプロダクトバックログアイテムを複数スプリントをまたいで作ることはない S S S S S
22. プロダクトバックログDEEP DIVE 22 ここで問題が見 つかると何1つ完成し ない。スプリントゴール も未達 よくない作業の進め方(ミニウォーターフォール) N-1 スプリントN PBI \ DAY 1 2 3 4 5 6 7 8 9 10 PBI#1 設計 開発 統合 テスト PBI#2 設計 開発 統合 テスト PBI#3 設計 統合 テスト PBI#4 設計 開発 このあたりで遅れる と統合やテストにたどり 着かない 開発 統合 テスト PBI#5 設計 開発 統合 テスト PBI#6 設計 開発 統合 テスト
23. プロダクトバックログDEEP DIVE 23 ここで問題が見 つかると何1つ完成し ない。スプリントゴール も未達 よくない作業の進め方(まとめてテスト) N-1 スプリントN PBI \ DAY PBI#1 PBI#2 PBI#3 PBI#4 PBI#5 PBI#6 1 2 3 設計 4 5 6 7 開発 設計 設計 設計 10 テスト 統合 テスト 統合 テスト 開発 統合 テスト 開発 統合 テスト 統合 テスト 開発 設計 9 統合 開発 設計 8 開発
24. プロダクトバックログDEEP DIVE 24 仕掛りを減らして完成させる N-1 〜事前 準備 (リファイ ンメント) スプリントN PBI \ DAY 1 2 3 4 PBI#1 設計 開発 統合 テスト PBI#2 設計 開発 統合 テスト 5 6 7 8 9 10 この時点でもし かしたらスプリントゴー ルは達成できているか もしれない！ PBI#3 設計 開発 統合 テスト PBI#4 設計 開発 統合 テスト PBI#5 設計 開発 統合 テスト PBI#6 設計 開発 統合 テスト
25. プロダクトバックログDEEP DIVE スプリント中に完成しなかったプロダクトバックログアイテムはどうするの？ ▸ スプリント中に完成しなかったプロダクトバックログアイテムは、単純に「未完成」として扱う ▸ 例えあとすこしで終わる状況でも同じ ▸ 一部分だけを成果として扱ったり、条件付き完成はない。完成は0/1で扱う ▸ デモの対象にもならない ▸ 完成しなかったらスプリント終了時に「再見積もり」してプロダクトバックログに戻す ▸ 次のスプリントで引き続き着手するかどうかはプロダクトオーナーの並べ順の判断に委ねる ▸ 自動的に次のスプリントに持ち越すわけではない ▸ スプリントゴールが達成できていれば、そもそも二度と着手しないかもしれない 25
26. プロダクトバックログDEEP DIVE 26 以上を踏まえると、プロダクトバックログアイテムの粒度には濃淡が必要 ✕ ✕ 全 部 全 部 が 粗 い が 細 か い 〜 ◯ 〜 上 は 細 か く 下 は 粗 い
27. プロダクトバックログDEEP DIVE 27 プロダクトバックログアイテムが全部細かいとムダを産む ▸ プロダクトバックログアイテムが多すぎると ✕ ▸ 全体を見通せない ▸ 並び替えが難しい 全 部 が 細 か い ▸ 変化が起こったときに多くのものがムダになる 〜 ▸ 経験上、未完成のプロダクトバックログアイテムが100個を超えるとメ ンテナンスが大変になってくる印象
28. プロダクトバックログDEEP DIVE 28 プロダクトバックログアイテムが全部大きいとスプリントで完成しない ▸ プロダクトバックログアイテムが大きすぎると ✕ ▸ スプリントで完成しない 全 部 が 粗 い ▸ スプリントが一発勝負になりがち ▸ 結果として、成果の量が不安定になり、予測精度が下がる 〜
29. プロダクトバックログDEEP DIVE 29 プロダクトバックログアイテムは上ほど細かく、下ほど粗い ◯ ▸ 直近のスプリントで着手するものは、1スプリントに十分収まる大きさ ▸ 下に行くに連れて、粒度の大きいものが徐々に増える 上 は 細 か く 下 は 粗 い ▸ 並べ替えで上位に来たときは、適宜手入れをして、1スプリントに収まる サイズにする ▸ つまり、継続的にJust in Timeでお手入れをしていく
31. プロダクトバックログDEEP DIVE プロダクトバックログアイテム（再掲） ▸ 書き方はスクラムでは決めていない ▸ ユーザーストーリーやユースケースを使うことが多い ▸ 最低限、順番、内容、見積りは含まれている必要がある ▸ スクラムガイド2017では価値も含めていた ▸ ユニークなIDがあると扱いやすい 31
32. プロダクトバックログDEEP DIVE 32 ユーザーストーリー（XP由来） ▸ フォーマット ▸ ＜役割＞として ▸ ＜機能や性能＞がしたい（できる）。 ▸ ＜ビジネス価値＞のためだ。 ▸ 要求を自然言語で簡潔に記したもの ▸ 意図的な制約（たくさん書けない） Kent Beck 『Extreme Programming Explained』 (1st edition)
33. プロダクトバックログDEEP DIVE RON JEFFRIESの3C（XP由来） ▸ Card ▸ ストーリーはカードに書き、見積もりやメモ等も一緒に書く ▸ Conversation ▸ ストーリーの背後にある詳細事項はプロダクトオーナーとの会話から引き出される ▸ Con rmation fi ▸ 受け入れテストによってストーリーが正しく実装されているか確認する 33
34. プロダクトバックログDEEP DIVE 34 プロダクトバックログアイテム（ユーザーストーリー）が満たすとよい特性 Independent 互いに独立 ▸ 互いに独立して ▸ いること ▸ ▸ 依存関係や前 後関係はなる ▸ べく排除 ▸ 依存関係が高 いと見積もりが 難しくなる Negotiable 交渉可能 交渉可能 会話のための 道具 Valuable 価値がある ▸ ユーザーにとっ ▸ て価値がある ▸ ▸ ビジネスにとっ て価値がある 一度決めたこと が絶対なわけ ▸ 開発者にとって ではない 価値がある Estimable 見積もれる Sized Right 適切なサイズ 見積もり可能 Testable テスト可能 ▸ 自分たちが扱え ▸ 出来たか出来 る適切な大きさ ていないかを判 見積もりできる 断できる くらいの粒度と ▸ 十分にアイテム 具体性 が分割されて ▸ 受け入れテスト いる を記述できる ▸ 逆に小さすぎる と価値がわかり にくくなること も
35. プロダクトバックログDEEP DIVE プロダクトバックログアイテムの大原則 ▸ フォーマットではなく、本当の課題、規模感、必然性に関する議論を誘発するのが重要 ▸ 会話なしに共通理解は生まれない ▸ 単にユーザーストーリーなどの決まったフォーマットで書けばよいというわけではない ▸ 自分たちのニーズにあわせて記載内容を追加してももちろん構わない ▸ やりすぎ注意 ▸ 重要なのは共通理解 35
36. プロダクトバックログDEEP DIVE あるチームのプロダクトバックログアイテムの例 ▸ ユーザーストーリー ▸ 受け入れ基準 ▸ 解決すべき課題 ▸ プラットフォーム ▸ KPI ▸ リリース希望日 ▸ 規模感 ▸ リスク ▸ 関係者 ▸ 影響のある法令や社内規定 ▸ 参照情報 36
37. プロダクトバックログDEEP DIVE 37 避けたい: 何も説明していないプロダクトバックログアイテム ▸ 「○○機能がほしい。なぜなら○○機能がないからだ」のようなプロダクトバックログアイテム ▸ 実際には何も理由を説明していない ▸ ソリューションが欠如していることは事実だが、それを作る理由は他にある ▸ なんらかの課題を解決したいはずなので、それを理由に示す ▸ エンタープライズ向け製品で、機能の○✗比較に耐えるためだけに機能を作ることはあり得る（ROI が見合えば）。その場合は、それを理由として明示する
38. プロダクトバックログDEEP DIVE 38 避けたい: 画面単位プロダクトバックログアイテム ▸ 画面単位で機能を開発していく形になっているプロダクトバックログアイテム ▸ 従来型の開発に慣れている場合や、初期の段階で画面プロトタイプやモックを作り込んでいる場合に 発生する ▸ これはよくないアプローチ ▸ 画面には多くの要素が含まれており、1スプリントで完成させるには大きすぎる ▸ 画面には通常、必須のものとそうでないものが混在している。一気に作ろうとすると全体が一気通貫 する前に必須でないものを作るのに多くの時間を作ってしまう ▸ 複数の画面によって完結する処理の場合、部分的な完成では何も価値がない ▸ ユースケースが完結する最小単位に切り分ける
39. プロダクトバックログDEEP DIVE 39 避けたい: 「デプロイを自動化したい」のようなプロダクトバックログアイテム ▸ ダメではないが、「デプロイを自動化する」はソリューションを示している ▸ 本当に解決したい課題は何だろうか？ ▸ デプロイにかかる時間が長すぎる？ / デプロイの手順を頻繁に間違える？ / デプロイ職人がいない とデプロイできない？ ▸ これらの問題はフルに自動化しなくても解決できるかもしれない ▸ とはいえフルに自動化するのに大した工数はかからないかもしれない ▸ 会話によって本当に解決すべき課題に対する認識があっているかを確認する
41. プロダクトバックログDEEP DIVE プロダクトバックログリファインメント ▸ 新規のプロダクトバックログアイテムを追加したり見積もったりする ▸ 不要なプロダクトバックログアイテムを削除する ▸ 既存のプロダクトバックログアイテムを見積もり直す ▸ プロダクトバックログの並び順が最新になっていることを確認する ▸ プロダクトバックログの上位の内容を確認する ▸ 直近のスプリントに入りそうなプロダクトバックログアイテムの詳細を確認し、Readyにする ▸ 上位かつ大きなサイズのプロダクトバックログアイテムを着手可能なサイズに分割する 41
42. プロダクトバックログDEEP DIVE よくある悩み ▸ 「時間がなくて、プロダクトバックログの手入れにそんなに時間かけられないんだけど……」 ▸ これは逆で、プロダクトバックログの手入れをしないので時間がなくなる
43. プロダクトバックログDEEP DIVE プロダクトバックログアイテムの分割 ▸ 大きすぎるプロダクトバックログアイテムはスプリントに投入できないので分割する ▸ (例) 利用者としてホテルの予約をキャンセルできる ▸ プレミアムメンバーとしてギリギリまで予約をキャンセルできる ▸ 一般客として24時間前まで予約をキャンセルできる ▸ 宿泊をキャンセルした場合はそれを通知するメールが送られる ▸ 分割によってそれぞれのアイテムがまったく違う順番になることも多い ▸ 分割前のプロダクトバックログアイテムはどうするの？ ▸ 特に用はないので捨てて構わない ▸ プロダクトバックログやプロダクトバックログアイテムの履歴は意味がないことがほとんど 43
44. プロダクトバックログDEEP DIVE 44 やってはいけない分割方法 ▸ 工程面や技術面で分割をしてはいけない ▸ 「設計」、「開発・テスト」 のような工程での分割 ▸ 「UI」、「データベース」、「サーバー側ロジック」のような技術面での分割 ▸ 後続のスプリントでやらなければいけないことが自動で決まってしまい、変化に対応できない ▸ スプリントレビューでフィードバックが貰えない ▸ ただし ▸ 規模やチーム構成によっては、手前のスプリントでAPIを完成させ、後続のスプリントでフロントエンド を実装する、というような分割の可能性はある（スマホアプリの場合） ▸ スプリント内でチームをまたぐ受け渡しがタイムリーに行われることを期待してはいけない
45. プロダクトバックログDEEP DIVE 45 プロダクトバックログアイテムの分割指針 ▸ スパイク（技術検証）と機能実装で分割 ▸ 操作(CRUDなど)で分割 ▸ ワークフローのステップで分割 ▸ 利用者の役割によって分割 ▸ ビジネスルールで分割 ▸ 最適化の度合いで分割 ▸ ハッピーパスとそれ以外で分割 ▸ プラットフォームで分割 ▸ ブラウザや入力デバイスのバージョンによって 分割 ▸ 入力パラメータで分割 ▸ テストシナリオ・テストケースで分割
46. プロダクトバックログDEEP DIVE ワークフローのステップで分割 ▸ 分割前 ▸ ユーザーはホテルを予約することができる ▸ 分割後 ▸ ユーザーは部屋と日程を指定して、ホテルの予約を送信できる ▸ ユーザーはホテルの予約をする際に本人確認が行われる ▸ 予約が終わったら確認メールがユーザーに届く ▸ ポイント ▸ 本人確認や確認メールはあとのスプリントでも良いかもしれない 46
47. プロダクトバックログDEEP DIVE ビジネスルールで分割 ▸ 分割前 ▸ ユーザーはホテルを予約することができる ▸ 分割後 ▸ ユーザーは部屋と日程を指定して、ホテルの予約を送信できる ▸ ホテルの宿泊予定者と部屋の定員が一致していない場合は予約できない ▸ 宿泊予定者に子供が含まれる場合は、料金を変更する ▸ ポイント ▸ ビジネスルールの実装はあとのスプリントでも良いかもしれない 47
48. プロダクトバックログDEEP DIVE ハッピーパスとそれ以外で分割 ▸ 分割前 ▸ 登録済のユーザーはログインして自分の予約を閲覧することができる ▸ 分割後 ▸ 登録済のユーザーはログインして自分の予約を閲覧することができる ▸ ログイン情報を忘れた場合に、パスワードをリセットできる ▸ 3回ログインを間違えた場合は、1時間アカウントをロックする ▸ ポイント ▸ ハッピーパス以外はあとのスプリントでも良いかもしれない 48
49. プロダクトバックログDEEP DIVE プラットフォームで分割 ▸ 分割前 ▸ ホテルの従業員は予約状況を見ることができる ▸ 分割後 ▸ ホテルの従業員はブラウザで予約状況を見ることができる ▸ ホテルの従業員はスマホで予約状況を見ることができる ▸ ホテルの従業員は予約状況を印刷することができる ▸ ポイント ▸ スマホや印刷はあとのスプリントでも良いかもしれない 49
50. プロダクトバックログDEEP DIVE 入力パラメータで分割 ▸ 分割前 ▸ ユーザーはホテルの空き情報を知ることができる ▸ 分割後 ▸ ユーザーは日程を指定して、ホテルの空き情報を知ることができる ▸ ユーザーは部屋のサイズを指定して、ホテルの空き情報を知ることができる ▸ ユーザーは価格の範囲を指定して、ホテルの空き情報を知ることができる ▸ ポイント ▸ 検索項目によっては実装の重要性は変わるかもしれない 50
51. プロダクトバックログDEEP DIVE 操作(CRUDなど)で分割 ▸ 分割前 ▸ ホテルの従業員は宿泊対象の部屋を追加、更新、削除できる ▸ 分割後 ▸ ホテルの従業員は宿泊対象の部屋を追加できる ▸ ホテルの従業員は宿泊対象の部屋を更新できる ▸ ホテルの従業員は宿泊対象の部屋を削除できる ▸ ポイント ▸ フレームワークによっては当然同時にやった方が良いこともある 51
52. プロダクトバックログDEEP DIVE 利用者の役割によって分割 ▸ 分割前 ▸ ユーザーは宿泊候補の部屋の詳細を見ることができる ▸ 分割後 ▸ ユーザーは宿泊候補の部屋の詳細を見ることができる ▸ ホテルの従業員は部屋の詳細を登録・更新することができる ▸ ホテルの管理者は部屋の詳細を削除することができる ▸ ポイント ▸ 管理画面系は最初は手作業でデータを更新してもよいかもしれない 52
53. プロダクトバックログDEEP DIVE 53 最適化の度合いで分割 ▸ 分割前 ▸ ユーザーはホテルの空き情報を知ることができる ▸ 分割後 ▸ ユーザーは条件を指定して検索ボタンを押すとホテルの空き情報を知ることができる ▸ ユーザーが条件を指定すると、それに合致した空き情報がリアルタイムに絞り込まれて表示される ▸ ポイント ▸ 機能の最適化はいくらでもできてしまうが、まずは最低限でも一気通貫を目指したほうがリリースが 早くなるので、最適化を過度に行わない方がよい
54. プロダクトバックログDEEP DIVE 54 ブラウザや入力デバイスのバージョンによって分割 ▸ 分割前 ▸ ユーザーはホテルの空き情報を知ることができる ▸ 分割後 ▸ ユーザーはホテルの空き情報を最新のChromeとFirefoxとSafariとEdgeで知ることができる ▸ ユーザーはホテルの空き情報をIE11で知ることができる ▸ ユーザーはホテルの空き情報をIE8-10で知ることができる ▸ ポイント ▸ 対象ブラウザのバージョンを拡げるほどテストや開発に時間がかかるようになるので、必ずしも最初 から全てのブラウザをサポートするのが良いとは限らない
55. プロダクトバックログDEEP DIVE テストシナリオ・テストケースで分割 ▸ 分割前 ▸ ユーザーはホテルの空き情報を知ることができる ▸ テストケース ▸ 既に予約済の部屋の場合は、選択できない ▸ メンテナンスなどで宿泊不可能な場合は、表示しない ▸ デフォルトでは部屋番号順にソートされている ▸ …… ▸ ポイント ▸ 結果的にはここまでに出てきた分割パターンに収束することが多い 55
57. プロダクトバックログDEEP DIVE プロダクトバックログ並べ替えの原則 ▸ スクラムガイドでは「並べ替えろ」としか言っていない ▸ 全部作るわけではないからこそ並べ替えが必要になる ▸ 一般的には以下のような複数の観点を組み合わせる ▸ 高い価値のものから ▸ 市場投入への時間を短く ▸ リスクを最小化 ▸ 将来の無駄を避ける ▸ 発生するコストや工数によって並び順が変わることもある ▸ 並べ替えのモデルとして、狩野モデル、MOSCOWなどがある 57
58. プロダクトバックログDEEP DIVE 「ログイン機能」は先に作るべきか？ ▸ 完成形を想像すると、ログインなどの導線部分を先に作りたくなる ▸ だが、初期のスプリントレビューを想像すれば、あまり適切ではないかもしれない ▸ ログイン機能を作ると、どんなリスクが低減されるのか？ ▸ ログイン機能を作ると、どんな価値が生まれるのか？ ▸ ログイン機能を作ると、どんなフィードバックがもらえるのか？ ▸ ログイン機能を作らずに、内部的に固定ユーザーにしておけば十分かも ▸ なぜそのスプリントでやるべきなのかを説明できる状態にしよう 58
60. プロダクトバックログDEEP DIVE 初期のプロダクトバックログの作り方 ▸ まずはプロダクトゴールを考えよう ▸ ゴールを決める前に、詳細な「機能」の話をしても無意味 ▸ 誰にどんな価値を提供するのか、その結果どうなってほしいのかの方向性を定める ▸ その上で、みんなでプロダクトバックログの候補を考える ▸ 最初に誰か一人がプロダクトバックログを全部作れるなら、スクラムである必要はないかも ▸ なるべく早くいちばん重要な仮説が検証できるようにする ▸ つまり十分に小さいMVPを特定する ▸ 数はたくさんあっても無意味。どうせ初期のプロダクトバックログアイテムを全部作ることはない ▸ Just in Timeのプロダクトバックログづくり 60
61. プロダクトバックログDEEP DIVE 新しいプロダクトバックログアイテムの見つけ方はたくさんある ▸ スプリントレビュー ▸ サポートへのリクエスト ▸ ペルソナの見直し ▸ ユーザーインタビュー、ユーザー行動モデリング、観察 ▸ メトリクス分析 ▸ ログ解析 ▸ A/Bテスト ▸ 開発者のペイン ▸ …… 61
