こんにちは。GROOVE Xのビジョンチームの長江です。普段は画像認識の結果とLOVOTの行動を結びつけるお仕事をしております。
先日、社内で「PBI(プロダクトバックログアイテム)の作り方」をテーマにしたワークショップが開催されました。これまでなんとなくPBIを作ってしまっていた自分にとって非常に学びが多かったため、今回はその内容と当日の熱い議論の様子をシェアしたいと思います。
TL;DR
- PBIは「誰のため」「何をするか」「受け入れ条件(AC)」を明確にすることが重要である
- PBI の作成における3つの型:
- 「誰のために何をするか」は「ユーザーストーリー」で記述する
- 「受け入れ条件(AC)」は「アサーション形式(完了状態)」で記述する
- 大きなPBIは、「バーティカルスライス(縦分割)」する → 早期にフィードバックを得られる
- ワークショップは「教えない教え方」に則り、講師が教えるのではなく、参加者が自ら学ぶ形で楽しく進められた
背景:タスク化してしまうPBI
日々の開発業務の中で、皆さんはどのようにPBIを作成しているでしょうか。
私はこれまで、PBIを書いているつもりで、実際にはただの「作業タスク」を登録してしまっていることがよくありました。また、詳細をどこまで書き込めばいいのか悩んだり、開発を進めるうちに「そもそもこのPBIって最終的に誰が嬉しくなるんだっけ?」と目的を見失ってしまったりすることもありました。
今回のワークショップは、そうした「良いPBIとは何か?」という疑問を解消し、適切に価値を届けられるPBIを作れるようになることを目的としていました。
ワークショップの流れ
このワークショップは、講師が一方的に知識を教える講義形式ではなく、「教えない教え方(Training from the Back of the Room)」という手法に基づいて設計されていました。
当日のタイムラインは以下のような、常に参加者が手を動かし、話し合う構成でした。
- 宿題の持ち寄り&ペアワーク(10分):事前に各自が手元に用意してきた「目的のわからなくなった過去のPBI」をベースに、「これって誰が嬉しくなるんだっけ?」を隣の人と議論。
- 「3つの型」の調査(26分):3つのグループに分かれ、「ユーザーストーリー」「アサーション形式」「バーティカルスライス」という3つの型を各チームが別々にWebや社内ツールで調査し、全員に教え合う。
- 実践・ブラッシュアップ(42分):学んだ型をもとに自分のPBIを書き直し、社内AIツール(
/pbi-helper)でレビューを受け、さらに「1スプリントに収まるか?」を検証して縦に分割する。 - 決意表明(8分):次のスプリントから自分の何を変えるかを付箋に書いて共有。
当時はエアコンの設定ミスにより会議室が寒かったこともあり(笑)、多くのメンバーが立ち上がり、終始賑やかにディスカッションが行われました。
ワークショップで学んだ「3つの型」と、なぜ採用するのか
ワークショップの中盤では、良いPBIを形作るための3つの型について、それぞれの特徴と採用するメリットを学びました。
1. ユーザーストーリー
- 概要:誰の、どのような欲求を、なぜ叶えたいのかという要求の構造を示す手法です。
- なぜ採用するのか:実装方法(How)ではなく「何を達成するか」に焦点を当てられるため、関係者間でギャップを埋める対話のきっかけになります。一目で「誰のための価値か」が伝わるため、チームが目的を見失わずにすみます。
2. アサーション形式
- 概要:PBI が達成された時の状態を宣言する形式です。
- なぜ採用するのか:多くのPBIで書かれがちな「〜を実装する」という行動の宣言ではなく、「達成された状態」を定義します。完了が観察可能になるため、スプリント終了時に「この条件は真か偽か」を客観的かつ明確に判定できるようになります。
3. バーティカルスライス
- 概要:PBIを「小さく動く、実行可能な体験単位」で縦に切っていく手法です。
- なぜ採用するのか:調査、設計、実装、テストと「横分割」してしまうと、途中の段階では何も動くものがなく、フィードバックが得られません。貧弱であっても全層がつながった「縦の体験」を作ることで、早く反応を得られます。これにより改善のサイクルが早く回り、リスクを抑えながら優先順位を柔軟に変更できるようになります。
3つの型を組み合わせるメリット
これら3つの型を組み合わせることで、「誰のためか伝わり(ユーザーストーリー)」「Doneが客観的に判断でき(アサーション)」「1スプリントで完結するサイズに収まる(バーティカルスライス)」という、非常に健全で強力なPBIが完成します。
ワークショップで白熱した議論と私なりの答え
ワークショップの中では、綺麗に答えが出るものばかりではなく、メンバー間で議論になったり、答えが出ないまま次に進んだりする場面もありました。そこから私自身が作業を通して至った気づきを紹介します。
「ユーザーストーリー」と「アサーション形式」の矛盾と、私なりの答え
ワークの途中で、あるメンバーから「ユーザーストーリー形式とアサーション形式って、何が違うの? 併用できるの?」という疑問が出ました。
スマホでAIに検索して聞いてみたメンバーが「AIによると、この2つは同時に満たそうとすると相性が悪いらしい。ユーザーストーリーはユーザーの欲求を描くけど、アサーションは既成事実の断言だから、一緒にすると欲求の性質が消えちゃうんだって」と報告。 一同「難しいな……」「結局タイトルとAC、どっちをどう書けばいいの?」と頭を抱えてしまい、その場では明確な結論が出ないまま、モヤモヤを残して一旦次のワークへ進むことになりました。
しかし、ワークショップの後半で実際に自分のPBIを書き直したり、3つの型を組み合わせるワークを進めたりしていく中で、私はハッとさせられる自分なりの答えに行き着きました。
これらは対立する手法としてどちらかを選ぶのではなく、PBIの中でパーツごとに役割分担をすればいいのではないか、ということです。
- Why(目的・価値の方向性):ユーザーストーリー視点で「誰のどんな価値のためか」を明確にする。
- 受け入れ条件(AC):アサーション形式で「どうなったら終わりか」を断言し、完了判定を客観的にできるようにする。
ワークショップ全体としての共通見解が出たわけではありませんでしたが、自分自身の中でこの2つの役割が綺麗に繋がり、PBIにおいて重要な「誰のため」「何をするか」「受け入れ条件」と今回学んだ「ユーザーストーリー」「アサーション形式」の結びつきを納得できた瞬間でした。
結論:良いPBIを作るための3つの型
これらを踏まえ、ワークショップで私が学んだ最終的な到達点がこちらです。
- ユーザーストーリー: 〈誰〉として / 〈何〉したい / なぜなら〈理由〉だから
- アサーション形式: 〈状態になっている〉(作業ではなく達成状態を断言し、完了を判定可能にする)
- バーティカルスライス: 大きすぎるPBIは、早期にフィードバックを得るために「小さく動く縦の体験」に切り出す
本質的に重要なのは、PBIを「やるべき作業(タスク)」ではなく、届けるべき「価値」と「達成されるべき状態(アサーション)」で表現することです。
おわりに
これまではPBIを「作業の備忘録」程度に捉えて適当に登録してしまうこともありましたが、今後は学んだキーワードを意識しつつ、社内の /pbi-helper を賢く活用して「きちんとしたPBI」を作っていきたいと思います。まずは次のスプリントプランニングから、この形式を試してみるつもりです。