はじめに
先日、チームのMTGでスクラムマスターからPBIの書き方について共有がありました。その中で、自分が学んだことを整理する感覚で書きます。
僕は「PBIってタスクを書く？」くらいの認識でした。スクラムマスターの方のPBIの書き方についてなどの話を聞いて、ふと思いました。
「これって刺身みたいやな」
- 鮮度が命（放置されると価値は薄れる←飲み会などで刺身が最後の方まで残ってたらなかなか食べる気が起きない。）
- 扱い方を間違えると価値がなくなる
（ブロックみたいな切られ方の刺身はあまりそそられない） - 誰が見ても「美味しそう」とわかる状態で出す
この記事でわかること（学んだことベースで書きます。理解が間違えていたら🙇♂️）
- PBIは「タスク」ではなく「価値」
- 良いPBIの書き方（タイトル、着手条件、受入条件）
- なぜPBIには「鮮度」があるのか
- 「必要な機能」でも、先にPBIを作って放置したら意味がない
結論：PBIは刺身みたい。鮮度が命。（肉系の刺しも含む。）
PBIはタスクではなく「実現する価値」である。
| 刺身 | PBI |
|---|---|
| 見た目で「美味しそう」とわかる | タイトルで「価値」が伝わる |
| 鮮度が落ちると価値がなくなる | 時間が経つと価値が薄れる |
| 扱い方を間違えると台無し | 書き方を間違えると誰も触れない |
| 食べきれる量だけ買う・注文する | 1〜2スプリント分だけ持つ |
一番の学びは 「鮮度が落ちると価値がなくなる」 という点でした。
左の画像美味しそうではない
一番の学び：必要な機能でも「先に作って放置」は意味がない
これ確かに大事だなと認識した内容です。
よくある勘違い
「この機能、いずれ絶対必要だから、先にPBI作っておこう」
僕はこういう認識でした。でもあまり良くないということを学びました。
なぜダメなのか
「PBIに書かれている『価値』は、作成時点の瞬間的なものでしかない」
PBIを作成した時点では確かに価値があった。でも時間が経つと：
- プロダクトの価値やユーザーの状況が変わる
- 放置されすぎると優先度が落ちてしまう
- 着手するときに「なんでこれやるんだっけ？」となる
- 作成した人以外、忘れていたり他の人がキャッチアップできない
たとえ「絶対に必要な機能」であっても、PBIを先に作って誰も着手しなかったら意味がない。
正しいアプローチ
その機能を実現しなくてはいけないタイミングで、初めてPBIを作成して着手する。
新鮮なうちに消費する。食べきれる量だけ買う。大量の刺身を注文して食べきれなかったら無駄だし、時間かかるがかかるからベストの美味しい状態で食べれない。鳥刺しだと食中毒すらあり得る。
「PBIは溜め込まない。多くても1〜2スプリント分が目安」
PBIの書き方① タイトル
基本：価値が伝わる内容にする
「価値が伝わらないタイトルのPBIを完了させても、スプリントレビューで完了させたことの意義が説明できない」
刺身で例えるなら、「マグロ」とだけ書かれたパックと「本日水揚げ 大間産本マグロ中トロ」と書かれたパック、どっちが価値わかります？という話。
書き方の例
「誰に、どのような価値を提供するか」を明確に
❌ 「検索機能」
⭕ 「（ユーザーは）キーワードで記事を検索できる」
「なぜ（将来のどの価値のため）何をする」を明確に
❌ 「API調査」
⭕ 「決済機能のためのX社API技術検証」
注意点
「〜のため」を書く時、「機能要件を満たすため」みたいな広い言葉はNG。
以下のどちらかを書く
- それが可能にする「未来の機能名」
- それが改善する「具体的な課題（例：遅い、不安定）」
PBIの書き方② 着手条件
「意外と本来は必要なインプットに気づかずに着手してしまうことは多い」
書くべきこと
- 着手前に最低限知っておくこと/解決しておくこと
- 他のPBIとの依存関係
注意点
「完璧に記載することに拘りすぎると、着手するハードルが上がる風潮が生まれる」
チーム内で良い塩梅を見つけていくものという認識で学びました。
PBIの書き方③ 受入条件
「タイトルをそのまま『〜出来ること』と書き換えるのはあまり意味がない（それなら書かなくて良い）」
これは、今回学んだので意識していきたいです。
書くべきこと
基本的にはテスト観点を記載する。
- タイトルの内容を実現するために必要な要素に分解
- 可能な限り具体的に（ふわっとすると人によって定義がブレる）
❌ 「検索できること」
⭕ 「キーワードを入力して検索ボタンを押すと、該当する記事の一覧が表示されること」
「該当する記事がない場合、『記事が見つかりませんでした』と表示されること」
INVEST原則
良いPBIの指針。
| 原則 | 意味 |
|---|---|
| Independent | 他のPBIと依存関係をなくす |
| Negotiable | 詳細は対話で交渉できる余地を残す |
| Valuable | 価値が明確 |
| Estimable | 見積もれる程度に情報が揃っている |
| Small | 1スプリント内で完了できるサイズ |
| Testable | テスト可能 |
特に重要なのは Valuable。
「価値がある → Whyを明確に記載すること と 新鮮さ（時間が経つほど価値は薄れる）が重要！」
腐ったPBIがチームを停滞させる
「作成した人しか価値がわからないと、作成した人しか説明できない」
これが「腐った刺身」状態。
共感してくださる人がいると嬉しいんですが、放置されすぎてごはん会などで最後の方まで余ってる刺身は、やはり美味しくないし肉系の刺身だと危険。尚更他の人も食べようとしない。余ってるから「どうぞどうぞ」もちょっと嫌な状況だし、勿体無いと思ってしまいます。それと似たように、チーム内で作成者以外が触れないPBIの存在は、チームを停滞させる要因になる。
まとめ
今回わかったこと
- PBIはタスクではなく「実現する価値」
- 「必要な機能」でも、先にPBIを作って放置したら意味がない
- 必要なタイミングで作成して着手するのが正しい
- PBIは溜め込まない（1〜2スプリント分が目安）
- 作成者しか触れないPBIはチームを停滞させる
刺身に学ぶPBI管理
- 新鮮なうちに消費する（鮮度）
- 食べきれる量だけ買う（溜め込まない）
- 見た目で価値が伝わるように盛り付ける（タイトル）
- 誰が見ても同じものだとわかる状態にする（受入条件）
チーム内のスクラムマスターの方からの共有で学び個人的にも考え方が変わり成長しました。ありがとうございます。