プロダクトバックログリファインメント Deep Dive

スクラム Deep Diveシリーズ。プロダクトバックログリファインメントとは何か、いつどれくらいやるのか等を細かく解説

Tidy First? ―個人で実践する経験主義的ソフトウェア設計
  • 著者／訳者：Kent Beck、 吉羽 龍太郎、 永瀬 美穂、 細澤 あゆみ
  • 出版社：オライリー・ジャパン
  • 発売日：2024-12-25
  • 単行本（ソフトカバー）：164ページ
  • ISBN-13：9784814400911
  • ASIN：4814400918
脳に収まるコードの書き方 ―複雑さを避け持続可能にするための経験則とテクニック
  • 著者／訳者：Mark Seemann、 吉羽 龍太郎、 原田 騎郎、 Robert C. Martin
  • 出版社：オライリー・ジャパン
  • 発売日：2024-06-18
  • 単行本（ソフトカバー）：312ページ
  • ISBN-13：9784814400799
  • ASIN：4814400799

Transcript

1. プロダクトバックログリファインメント Deep Dive 2026/6/23 fi 株式会社アトラクタ / Certi ed Scrum Trainer (CST) 吉羽 龍太郎 (@ryuzee)
2. 自己紹介 吉羽龍太郎 / Ryutaro YOSHIBA / ryuzee ▸ 株式会社アトラクタCTO /アジャイルコーチ / 翻訳者 ▸ Scrum Alliance 認定スクラムトレーナー （CST） 認定チームコーチ (CTC) ▸ Microsoft MVP （DevOps） ▸ X（Twitter）: @ryuzee ブログ: https://www.ryuzee.com/ 2
3. 自己紹介 最新書籍紹介（買ってください!!） 3
4. プロダクトバックログの基本
5. プロダクトバックログリファインメント DEEP DIVE プロダクトバックログとは？ ▸ スクラムの3つある作成物のうちの1つ ▸ 創発的かつ順番に並べられた、プロダクトの改善に必要なものの一覧 ▸ スクラムチームが行う作業の唯一の情報源 5
6. プロダクトバックログリファインメント DEEP DIVE プロダクトバックログの構成要素 ▸ 2つの要素から構成される ▸ 1つのプロダクトゴール ▸ 複数のプロダクトバックログアイテム ▸ プロダクトバックログ = プロダクトゴール + プロダクトバックログアイテム 6
7. プロダクトバックログリファインメント DEEP DIVE プロダクトゴールとは？ ▸ スクラムガイド2020で新たに導入された ▸ プロダクトが達成しなければいけない計測可能な結果やアウトカム ▸ プロダクトビジョンから導き出された、チームメンバーが達成すべきことを述べたもの ▸ プロダクトビジョンの実現に向けて、次に達成を目指すプロダクトの状態 ▸ 特定の期間（3か月〜1年くらいが多い）で完成させて次のゴールに取り組む ▸ 同時に取り組むのは1つだけ。途中で破棄して新しいゴールを設定することもできる（集中） ▸ SMART（具体的、計測可能、達成可能、現実的、有期）の5つの要素を持つものになることが多い ▸ プロダクトビジョンよりも具体的 7
8. プロダクトバックログリファインメント DEEP DIVE プロダクトバックログアイテムとは？ ▸ プロダクトゴールを達成するための「What」を定義するもの ▸ 説明、順番、サイズなどの要素が含まれる ▸ 書き方はスクラムでは決めていない ▸ ユーザーストーリーを使うことが多いが必須ではない ▸ サイズの単位も決まっていない ▸ ストーリーポイントを使うことが多かったがTシャツサイズなど別の単位を使うこともある 8
9. プロダクトバックログリファインメント DEEP DIVE 9 プロダクトバックログの例（あくまで例） 【プロダクトゴール】 開業後3か月以内に、新規予約の80％を電話対応なしで完結できる ようにする ID プロダクトバックログアイテム サイズ 1 ゲストとしてホテルを予約することができる 3 2 ゲストとしてホテルの予約をキャンセルできる 5 3 ゲストとして予約日時を変更できる 3 ... ... 52 ホテルの従業員として部屋ごとの収支レポートを作成できる 8 35 システム管理者としてエラーログが見れる 8 ... ... 40
10. プロダクトバックログリファインメント DEEP DIVE プロダクトバックログの管理 ▸ プロダクトオーナーは、効果的なプロダクトバックログ管理に対する説明責任を持つ ▸ 以下のような作業をすることが多い ▸ プロダクトゴールを策定し、明示的に伝える ▸ プロダクトバックログアイテムを作成し、明確に伝える ▸ プロダクトバックログアイテムを並び替える ▸ プロダクトバックログに透明性があり、見える化され、理解されるようにする ▸ ただし作業を他の人に委任することもできる ▸ つまり全部を自分でやる必要はないが、プロダクトバックログが適切であることの責任は取る 10
11. プロダクトバックログリファインメント DEEP DIVE プロダクトバックログが適切とは？ ▸ 必要なプロダクトバックログアイテムが含まれている ▸ 不要なプロダクトバックログアイテムが取り除かれている ▸ プロダクトバックログアイテムの並び順が最新になっている ▸ プロダクトバックログアイテムのサイズが明らかになっている ▸ 上位のプロダクトバックログアイテムは、1スプリントに収まるサイズになっている ▸ 上位のプロダクトバックログアイテムの内容について、スクラムチームの認識がおおよそ揃っている 11
12. プロダクトバックログリファインメント DEEP DIVE スプリントプランニング開始時点でのプロダクトバックログ ▸ スプリントプランニングは、プロダクトバックログアイテムを初めて理解する場ではない ▸ プロダクトオーナーは、次のスプリントゴールの元ネタを事前に検討している ▸ 上位のプロダクトバックログアイテムの並び順は、その元ネタにある程度沿っている ▸ 上位のプロダクトバックログアイテムの目的、価値、完成判断について、認識がおおよそ揃っている ▸ 上位のプロダクトバックログアイテムのサイズが明らかで、1スプリントに収まる状態になっている ▸ 大きな不明点、依存関係、制約、リスクが見えている 12
13. プロダクトバックログリファインメント DEEP DIVE 13 プロダクトバックログの準備ができていないと何が起きるか ▸ スプリントプランニングでプロダクトバックログアイテムの説明から始まる ▸ そこから議論が始まる。さらに見積りも行うこともある ▸ スプリントゴールがなかなか決まらない ▸ どのプロダクトバックログアイテムを選ぶべきか判断できない ▸ 結果的に、スプリントプランニングの所要時間がとてつもなく長くなる（タイムボックスを守れないことも） ▸ 基本的にスプリントプランニングが長いのはリファインメント不足 ▸ 着手後に想像より規模が大きいことが分かる ▸ スプリント中にプロダクトオーナーへの確認が頻発したり、完成確認で認識のズレが見つかる ▸ 結果として、スプリントゴールが達成できない
14. プロダクトバックログリファインメント
15. プロダクトバックログリファインメント DEEP DIVE プロダクトバックログリファインメントとは？ ▸ リファインメント = 精製、精錬、純化 = 余分なものを取り除き、純度を上げる ▸ つまり、プロダクトバックログを適切に保つための活動全般のこと ▸ スクラムイベントではない 15
16. プロダクトバックログリファインメント DEEP DIVE プロダクトバックログリファインメントがスクラムイベントではない理由 ▸ スクラムは意図的に不完全なフレームワーク ▸ 必要最小限だけを定義し、残りはチームに委ねる ▸ スクラムイベントは、スプリント内での検査と適応の公式な機会 ▸ 規則的なリズムを作り、他の会議の必要性を最小化するために定義されている ▸ プロダクトバックログリファインメントは準備の活動 ▸ プロダクトバックログは創発的であり、変化の検知にあわせて行うのが自然 ▸ どこまで準備するのか、誰がいつ準備するのか、どれくらい時間をかけるのかはそれぞれ ▸ 自己管理の枠組みのなかで、自分たちでやり方を考えるほうがよいと判断 ▸ 以上より、規則的なイベントの枠に押し込めず、活動として位置づけている 16
17. プロダクトバックログリファインメント DEEP DIVE プロダクトバックログリファインメントの活動を設計する ▸ いつ、誰が、どのように行うかはスクラムチームで設計する（スクラムチームは自己管理） ▸ この活動自体は検査と適応の対象 ▸ リファインメント後やスプリントレトロスペクティブの場で、もっとよいやり方を追求する ▸ 「適切なプロダクトバックログ」を踏まえる 17
18. プロダクトバックログリファインメント DEEP DIVE 18 1. 必要なプロダクトバックログアイテムが含まれている ▸ プロダクトゴールを達成するために必要なアイテムが含まれているか確認する ▸ 顧客やユーザー、ステークホルダー、開発者から得られた学びを反映する ▸ たとえばスプリントレビューのフィードバック、ユーザー調査や観察などの結果、開発中に自分たちが 直面した問題など ▸ 機能追加だけでなく、調査、実験、技術的負債への対応、運用や保守に必要な作業も対象になる ▸ 今後の数スプリントで必要になりそうなアイテムは、先回りして用意しておく ▸ ただし、思いついたものを何でも追加すると、プロダクトバックログはすぐに膨れ上がる ▸ 追加するかどうかは、プロダクトゴールや価値への貢献を踏まえて判断する ▸ いったん別の場所（パーキングロット）に置いてから判断するのがよくある手
19. プロダクトバックログリファインメント DEEP DIVE 2. 不要なプロダクトバックログアイテムが取り除かれている ▸ プロダクトバックログは「いつかそのうちやるかもしれないこと」の置き場ではない ▸ 古くなった仮説、価値が下がったアイテム、目的が曖昧なアイテムは取り除く ▸ 顧客やユーザーの状況、ビジネス環境、プロダクトゴールが変われば、必要なアイテムも変わる ▸ 不要なアイテムを残し続けると、重要なものが見えにくくなり、判断のノイズが増える ▸ 捨てる判断をしないと、プロダクトバックログはゴミ箱になる ▸ 必要になったらまた追加すればよい ▸ 本当に重要なものは捨てたところで何度でも蘇る 19
20. プロダクトバックログリファインメント DEEP DIVE 3. プロダクトバックログアイテムの並び順が最新になっている ▸ プロダクトバックログは単なる一覧ではなく、順番に並べられた一覧 ▸ プロダクトオーナーは、今後の数スプリントでどのように価値を高めたいかを先回りして考えておく ▸ その検討が、スプリントゴールの元ネタになる ▸ プロダクトバックログの並び順は、ある程度その元ネタに沿ったものになる（ならないとおかしい） ▸ もちろん、新しい情報が得られたら、スプリントゴールの候補や並び順は変わってよい ▸ つまり、ステークホルダーの声の大きさの順番ではない ▸ 並び順が古いままだと、スプリントプランニングで何を選ぶべきか判断しづらくなる 20
21. プロダクトバックログリファインメント DEEP DIVE 4. プロダクトバックログアイテムのサイズが明らかになっている ▸ サイズが分からないと、今後の見通しやスプリントで選択できるかを判断しづらい ▸ サイズは精密に当てるためではなく、会話と判断のために使う ▸ 大きすぎるアイテムは、不確実性や認識違いを多く含んでいることが多い ▸ 見積りを通じて、内容の理解不足、前提の違い、依存関係、リスクを見つける ▸ サイズが分からない場合は、先に調査や検証のアイテムを用意することもある ▸ 重要なのは、スプリントプランニングで選べる程度に大きさの感覚が揃っていること 21
22. プロダクトバックログリファインメント DEEP DIVE 22 5. 上位のプロダクトバックログアイテムは、1スプリントに収まるサイズになっている ▸ 上位のアイテムは、近いうちにスプリントで選択される可能性が高い ▸ 1スプリントに収まらない大きさのままだと、インクリメントが届けられない ▸ つまりプロダクトのリスクが何も減らない ▸ 大きすぎるアイテムは、価値を保ったまま小さく分割する ▸ このあと詳細に説明します ▸ 工程や技術要素で分割するのではなく、フィードバックを得られる単位に分割する ▸ 1つのアイテムを完成させることで、何らかの価値や学びが得られる状態を目指す ▸ 下位のアイテムまで細かくしすぎる必要はない
23. プロダクトバックログリファインメント DEEP DIVE 近いうちに選ばれそうなPBI ほど、小さく、具体的な状態 プロダクトバックログアイテムのサイズ感 ✕ ✕ 全 部 が 小 さ い 〜 全 部 が 大 き い ◯ 〜 上 は 小 さ く 下 は 大 き い 23
24. プロダクトバックログリファインメント DEEP DIVE 24 6. 上位のプロダクトバックログアイテムの内容について、認識がおおよそ揃っている ▸ 上位のアイテムは、スクラムチームが内容をおおよそ理解している必要がある ▸ 何を実現したいのか、なぜ必要なのか、どのように完成を判断するのかを確認する ▸ 細かい仕様をすべて事前に決めきることが目的ではない ▸ スプリント中に必要以上の確認や手戻りが発生しない程度に認識を揃える ▸ 認識が揃っていない場合は、例、受け入れ条件、制約、依存関係などを明らかにする ▸ それでも不確実性が高い場合は、すぐに実装せず、調査や実験として扱うことも考える
25. プロダクトバックログリファインメント DEEP DIVE 25 誰がプロダクトバックログリファインメントに関わるのか 観点 主に関わる人 補足 1. 必要なPBIが含まれている PO 開発者、ステークホルダーから得た学びも反映する 2. 不要なPBIが取り除かれている PO 古い仮説や価値の下がったPBIを放置しない 3. PBIの並び順が最新になっている PO スプリントゴールの元ネタに沿って並び順を更新する 4. PBIのサイズが明らかになっている 開発者 POは判断に必要な情報を提供する 5. 上位のPBIが1スプリントに収まる PO・開発者 価値を保ちつつ、実現可能なサイズに分割する 6. 上位のPBIの認識がおおよそ揃っている PO・開発者 何を、なぜ、どこまでやるのかを確認する ※ プロダクトオーナーはプロダクトバックログ管理に対する説明責任を持つが、すべての作業を1人で行うわけではない
26. プロダクトバックログリファインメント DEEP DIVE いつプロダクトバックログリファインメントをするのか？ ▸ 必要なときに、必要な人で、継続的に行う ▸ プロダクトオーナー単独でやることもあれば、一部だけでやることもあれば、全員でやることもある ▸ イベント的に定期的な時間を確保してもよいが、その時間だけに限定しない ▸ 新しい情報を得たとき ▸ スプリントレビュー、ユーザー調査、利用データ、ステークホルダーとの対話など ▸ プロダクトゴール、優先順位、前提、制約が変わったとき ▸ 上位のプロダクトバックログアイテムに不明点、依存関係、リスクが見つかったとき ▸ プロダクトバックログアイテムが大きすぎる、または認識が揃っていないと分かったとき ▸ スプリントプランニングで選択できる状態を継続的に維持する 26
27. プロダクトバックログリファインメント DEEP DIVE プロダクトバックログリファインメントにかける時間 ▸ スクラムでは、プロダクトバックログリファインメントのタイムボックスや時間の割合を定めていない ▸ 過去のスクラムガイドには「開発チームのキャパシティの10％以下」という目安があった ▸ これは会議時間ではなく、リファインメント活動全体に使う労力の目安 ▸ スクラムガイド2020では、この記述は削除された ▸ 必要な時間は、プロダクト、チーム、扱うアイテム、不確実性によって変わる ▸ 上位のプロダクトバックログアイテムを選択できる状態に保つために、必要なだけ行う ▸ 定期的に時間を確保してもよいが、決めた時間を使い切ることが目的ではない ▸ プロダクトバックログリファインメントにかける時間自体も、検査と適応の対象 ▸ 時間の長さではなく、プロダクトバックログの状態で十分かどうかを判断する 27
28. プロダクトバックログリファインメント DEEP DIVE 28 どこまでプロダクトバックログリファインメントすれば十分か ▸ 検査と適応の範囲なので、自分たちでちょうどいいところを見つけるのが基本 ▸ ガイドライン ▸ すべてのプロダクトバックログアイテムを細かくする必要はない ▸ 近いうちに選ばれそうな上位のプロダクトバックログアイテムほど詳しくする ▸ 下位のプロダクトバックログアイテムは粗いままでよい（今やるのは時間のムダ） ▸ スプリントプランニングで選択できる程度に、目的、価値、サイズ、完成判断が分かっていればよい ▸ スプリント中に多少の会話が残るのは自然 ▸ ただし、毎回大きな認識ズレや分割のやり直しが起きるなら不足している
29. プロダクトバックログリファインメント DEEP DIVE プロダクトバックログリファインメントですべてを決めない ▸ 詳細仕様をすべて事前に決める必要はない ▸ 実装方法をプロダクトオーナーが指定する場ではない ▸ 開発者がスプリント中に設計判断する余地を残す ▸ 変更の可能性が高いものを早く細かくしすぎない ▸ 重要なのは、次の判断に使える状態にすること ▸ 決めるべきことと、後で決めてよいことを分ける 29
30. プロダクトバックログリファインメント DEEP DIVE 30 準備完了の定義（De nition of Ready） ▸ スクラムで定義されていないがよく使われるプラクティス。スプリント投入可能状態を明文化する ▸ 価値が明確である ▸ スプリント内では解消できなさそうな大きな不明点がない ▸ 開発者全員が目的と概要を理解している ▸ 受け入れ基準が明確である ▸ 他のアイテムとの依存関係が明確である ▸ パフォーマンスなどの非機能要件が明確になっている ▸ デモの手順が明らかになっている fi ▸ 1スプリントで完成できる大きさと判断できている あくまで例。スクラムチー ムでの実践を繰り返しながら更 新していく
31. プロダクトバックログリファインメント DEEP DIVE 生成AIの影響 ▸ 生成AIによって、設計や実装案、インクリメントを作るコストは下がり、速度は上がった ▸ つまり ▸ 大きめのプロダクトバックログアイテムでも、1スプリントで完成できるようになった ▸ 事前に細かい仕様を詳細に決める価値や必然性が下がった ▸ 一方で、何を達成したいのか、なぜ必要なのか、どうなれば価値があるのかはより重要になる ▸ リファインメントでは、目的、価値、制約、完成判断、分割方針の認識を揃える ▸ 生成AIがあろうと、人間同士の共通理解を省略してよいわけではない 31
32. プロダクトバックログリファインメント DEEP DIVE 32 生成AIの影響（要求・設計・タスク） ▸ Kiroなどのスペック駆動開発では、要求（requirements）、設計（design）、タスク（tasks）を文書化する ▸ 上記3つすべてをスプリント開始前に詳細化する必要はない ▸ 設計は、実装対象や実際のコードを確認することで変化する ▸ 設計とタスク分解は開発作業そのものなので、スプリント内で行う ▸ プロダクトバックログリファインメントでは、目的、価値、主要な要求、制約、完成の判断基準を揃える ▸ 詳細仕様ではなく、スプリントで作り始められるアウトラインでよい ▸ 1スプリントで完成できる見通しがあることがポイント ▸ 詳細な設計やタスク分解まで、スプリントの外で先回りしない
33. プロダクトバックログリファインメント DEEP DIVE 生成AIで速く作れても、プロダクトバックログアイテムを分割する理由 ▸ 大きなものを一気に作ると問題が起こるから ▸ そもそも1スプリント内で完成せず、フィードバックが遅くなるリスクが大きい ▸ レビュー、検証、リリースの負荷が高い。ステークホルダーも巨大なものでは判断できない ▸ 間違っていたときの廃棄コストが大きくなる ▸ 途中での方向転換が難しくなる ▸ スプリントで選択するプロダクトバックログアイテムは、1スプリントで完成できる必要がある 33
34. プロダクトバックログアイテムの分割 (詳細編)
35. プロダクトバックログリファインメント DEEP DIVE プロダクトバックログアイテムの分割 ▸ 大きすぎるプロダクトバックログアイテムはスプリントに投入できないので分割する ▸ (例) 利用者としてホテルの予約をキャンセルできる ▸ プレミアムメンバーとしてギリギリまで予約をキャンセルできる ▸ 一般客として24時間前まで予約をキャンセルできる ▸ 宿泊をキャンセルした場合はそれを通知するメールが送られる ▸ 分割によってそれぞれのアイテムがまったく違う順番になることも多い ▸ 分割前のプロダクトバックログアイテムはどうするの？ ▸ 特に用はないので捨てて構わない ▸ プロダクトバックログの履歴は意味がないことがほとんど（監査などの特殊要件がある場合は除く） 35
36. プロダクトバックログリファインメント DEEP DIVE 36 やってはいけない分割方法 ▸ 工程面や技術面で分割をしてはいけない ▸ 「設計」、「開発・テスト」 のような工程での分割 ▸ 「UI」、「データベース」、「サーバー側ロジック」のような技術面での分割 ▸ 後続のスプリントでやらなければいけないことが自動で決まってしまい、変化に対応できない ▸ スプリントレビューでフィードバックが貰えない ▸ ただし ▸ 規模やチーム構成によっては、手前のスプリントでAPIを完成させ、後続のスプリントでフロントエンド を実装する、というような分割の可能性はある（スマホアプリの場合） ▸ スプリント内でチームをまたぐ受け渡しがタイムリーに行われることを期待してはいけない
37. プロダクトバックログリファインメント DEEP DIVE よい分割とは？ ▸ 1スプリントに十分収まるくらい小さい ▸ 完成したら何らかの価値や学びが得られる ▸ スプリントレビューでフィードバックを得られる ▸ 後続のプロダクトバックログアイテムを自動的にやらなければいけない状態にしない ▸ プロダクトバックログ上で、分割後のプロダクトバックログアイテムを別々の順番に並べられる 37
38. プロダクトバックログリファインメント DEEP DIVE 38 プロダクトバックログアイテムの分割指針 ▸ スパイク（技術検証）と機能実装で分割 ▸ 操作(CRUDなど)で分割 ▸ ワークフローのステップで分割 ▸ 利用者の役割によって分割 ▸ ビジネスルールで分割 ▸ 最適化の度合いで分割 ▸ ハッピーパスとそれ以外で分割 ▸ プラットフォームで分割 ▸ ブラウザや入力デバイスのバージョンによって 分割 ▸ 入力パラメータで分割 ▸ テストシナリオ・テストケースで分割
39. プロダクトバックログリファインメント DEEP DIVE ワークフローのステップで分割 ▸ 分割前 ▸ ユーザーはホテルを予約することができる ▸ 分割後 ▸ ユーザーは部屋と日程を指定して、ホテルの予約を送信できる ▸ ユーザーはホテルの予約をする際に本人確認が行われる ▸ 予約が終わったら確認メールがユーザーに届く ▸ ポイント ▸ 本人確認や確認メールはあとのスプリントでも良いかもしれない 39
40. プロダクトバックログリファインメント DEEP DIVE ビジネスルールで分割 ▸ 分割前 ▸ ユーザーはホテルを予約することができる ▸ 分割後 ▸ ユーザーは部屋と日程を指定して、ホテルの予約を送信できる ▸ ホテルの宿泊予定者と部屋の定員が一致していない場合は予約できない ▸ 宿泊予定者に子供が含まれる場合は、料金を変更する ▸ ポイント ▸ ビジネスルールの実装はあとのスプリントでも良いかもしれない 40
41. プロダクトバックログリファインメント DEEP DIVE ハッピーパスとそれ以外で分割 ▸ 分割前 ▸ 登録済のユーザーはログインして自分の予約を閲覧することができる ▸ 分割後 ▸ 登録済のユーザーはログインして自分の予約を閲覧することができる ▸ ログイン情報を忘れた場合に、パスワードをリセットできる ▸ 3回ログインを間違えた場合は、1時間アカウントをロックする ▸ ポイント ▸ ハッピーパス以外はあとのスプリントでも良いかもしれない 41
42. プロダクトバックログリファインメント DEEP DIVE プラットフォームで分割 ▸ 分割前 ▸ ホテルの従業員は予約状況を見ることができる ▸ 分割後 ▸ ホテルの従業員はブラウザで予約状況を見ることができる ▸ ホテルの従業員はスマホで予約状況を見ることができる ▸ ホテルの従業員は予約状況を印刷することができる ▸ ポイント ▸ スマホや印刷はあとのスプリントでも良いかもしれない 42
43. プロダクトバックログリファインメント DEEP DIVE 入力パラメータで分割 ▸ 分割前 ▸ ユーザーはホテルの空き情報を知ることができる ▸ 分割後 ▸ ユーザーは日程を指定して、ホテルの空き情報を知ることができる ▸ ユーザーは部屋のサイズを指定して、ホテルの空き情報を知ることができる ▸ ユーザーは価格の範囲を指定して、ホテルの空き情報を知ることができる ▸ ポイント ▸ 検索項目によっては実装の重要性は変わるかもしれない 43
44. プロダクトバックログリファインメント DEEP DIVE 操作(CRUDなど)で分割 ▸ 分割前 ▸ ホテルの従業員は宿泊対象の部屋を追加、更新、削除できる ▸ 分割後 ▸ ホテルの従業員は宿泊対象の部屋を追加できる ▸ ホテルの従業員は宿泊対象の部屋を更新できる ▸ ホテルの従業員は宿泊対象の部屋を削除できる ▸ ポイント ▸ フレームワークによっては当然同時にやった方が良いこともある 44
45. プロダクトバックログリファインメント DEEP DIVE 利用者の役割によって分割 ▸ 分割前 ▸ ユーザーは宿泊候補の部屋の詳細を見ることができる ▸ 分割後 ▸ ユーザーは宿泊候補の部屋の詳細を見ることができる ▸ ホテルの従業員は部屋の詳細を登録・更新することができる ▸ ホテルの管理者は部屋の詳細を削除することができる ▸ ポイント ▸ 管理画面系は最初は手作業でデータを更新してもよいかもしれない 45
46. プロダクトバックログリファインメント DEEP DIVE 46 最適化の度合いで分割 ▸ 分割前 ▸ ユーザーはホテルの空き情報を知ることができる ▸ 分割後 ▸ ユーザーは条件を指定して検索ボタンを押すとホテルの空き情報を知ることができる ▸ ユーザーが条件を指定すると、それに合致した空き情報がリアルタイムに絞り込まれて表示される ▸ ポイント ▸ 機能の最適化はいくらでもできてしまうが、まずは最低限でも一気通貫を目指したほうがリリースが 早くなるので、最適化を過度に行わない方がよい
47. プロダクトバックログリファインメント DEEP DIVE 47 ブラウザや入力デバイスのバージョンによって分割 ▸ 分割前 ▸ ユーザーはホテルの空き情報を知ることができる ▸ 分割後 ▸ ユーザーはホテルの空き情報を最新のChromeとFirefoxとSafariとEdgeで知ることができる ▸ ユーザーはホテルの空き情報をスマホのブラウザで知ることができる ▸ ユーザーはホテルの空き情報をアプリ内のWebViewで知ることができる ▸ ポイント ▸ 対象ブラウザのバージョンを拡げるほどテストや開発に時間がかかるようになるので、必ずしも最初 から全てのブラウザをサポートするのが良いとは限らない
48. プロダクトバックログリファインメント DEEP DIVE テストシナリオ・テストケースで分割 ▸ 分割前 ▸ ユーザーはホテルの空き情報を知ることができる ▸ テストケース ▸ 既に予約済の部屋の場合は、選択できない ▸ メンテナンスなどで宿泊不可能な場合は、表示しない ▸ デフォルトでは部屋番号順にソートされている ▸ …… ▸ ポイント ▸ 結果的にはここまでに出てきた分割パターンに収束することが多い 48
49. プロダクトバックログリファインメント DEEP DIVE まとめ ▸ プロダクトバックログリファインメントは会議ではなく、バックログを適切に保つ継続的な活動 ▸ 上位のプロダクトバックログアイテムほど、小さく具体的にする ▸ 詳細仕様をすべて事前に決める必要はない ▸ 目的、価値、制約、完成判断について認識を揃える ▸ 生成AI時代でも、小さく作って早くフィードバックを得る ▸ 詳細な設計とタスク分解はスプリント内で行う ▸ プロダクトバックログリファインメントにかける時間や進め方自体も、検査と適応の対象にする 49

Comment

No comments...