プロダクトバックログアイテムの分割方法

みなさんこんにちは。@ryuzeeです。

プロダクトバックログアイテムは、複数スプリントにまたがって1つのものに着手することはありません。必ず、1スプリントで完成できる大きさになっている必要があります。これは、複数にまたがってしまうと変化に柔軟に対応できなくなること、成果の量の把握が難しくなること、大きいものを扱うのはそもそも難しいことなどが理由です。

そのため、プロダクトバックログアイテムがプロダクトバックログのなかで上位になっていくにつれて、リファインメントなどを活用しながら、適切なサイズに分割していきます。最初の段階から細かく分割してしまうと、変化に対応しにくくなったり、数が多くなりすぎて管理しきれなくなったりするので避け、着手が近づいてきたらジャスト・イン・タイムで分割していくのがポイントです。こうすることで、チームの成長にあわせてプロダクトバックログアイテムのサイズを変えていけるようにもなります。

今回は、プロダクトバックログアイテムの分割のやり方について、以下で11個の分割方法を紹介します。ネットを探せばいろいろな分割例が見つかりますが、それらを整理してまとめたものになっています。なお、間違っても技術レイヤー（1. フロントエンドを作る 2. バックエンドを作る……）や工程（1. 設計する 2. 開発する 3. テストする……）で分割してはいけません。

スパイク（技術検証）と機能実装で分割
ハッピーパスとそれ以外で分割
入力パラメータで分割
利用者の役割によって分割
最適化の度合いで分割
プラットフォームで分割
ビジネスルールで分割
ワークフローのステップで分割
操作(CRUDなど)で分割
ブラウザの種類やバージョンによって分割
テストシナリオ・テストケースで分割

なお、どこまで分割すべきかはチームの力量に大きく依存します。力量のあるチームであれば大きなプロダクトバックログアイテムでも1スプリントで実現できますし、逆に力量が足りない場合は自分たちの状況にあわせて小さくしなければいけなくなります。単に機械的に分割するのではなく、1スプリントに入るのかどうかという観点で確認するようにしてください（理想は最低でも3つくらいのプロダクトバックログアイテムをスプリントに投入する感じです）。

1. スパイク（技術検証）と機能実装で分割

分割前
- ユーザーはホテルの空き情報を知ることができる
分割後
- 画面遷移なしで空き情報を表示するための技術要素を検証する
- ユーザーはホテルの空き情報を知ることができる

初めて利用する技術の場合やチームが実装のイメージがつかずに見積りに確証が持てない場合によく行います。まずは見積もれるだけの材料を集めるために、技術的な検証や調査などを別のプロダクトバックログアイテムに切り出して、先行して実施します。その結果をチームでレビューした上で、それに依存するプロダクトバックログアイテムを見積もり直したり、そこで確証が持てればスプリントに投入します。

2. ハッピーパスとそれ以外で分割

分割前
- 登録済のユーザーはログインして自分の予約を閲覧することができる
分割後
- 登録済のユーザーはログインして自分の予約を閲覧することができる
- ログイン情報を忘れた場合に、パスワードをリセットできる
- 3回ログインを間違えた場合は、1時間アカウントをロックする

例として挙げているログインのプロダクトバックログアイテムは通常はよくないアイテムの例になりますが、今回は説明のために利用しています。とくにプロダクト開発の初期段階だと、まずはプロダクト自体が受け入れられるかが大きな関心事になります。つまり細部まで細かく作り込まれていることよりも、全体が一気通貫で動かせることの方が優先になるのが一般的です。そのためハッピーパスと呼ばれる通常ケースを実現して、まずは評価可能な状態にして、そのあとに細部に着手するというのはよくあるシナリオになります。

3. 入力パラメータで分割

分割前
- ユーザーはホテルの空き情報を知ることができる
分割後
- ユーザーは日程を指定して、ホテルの空き情報を知ることができる
- ユーザーは部屋のサイズを指定して、ホテルの空き情報を知ることができる
- ユーザーは価格の範囲を指定して、ホテルの空き情報を知ることができる

検索系の機能などでよく登場する例です。ホテルの空き部屋でもECサイトの商品検索でも、さまざまな切り口から検索できるようにしたいと考えることは多いです。ただし全部の検索を1スプリントで作りきれるかはチームの力量次第ですし、そもそもさまざまな項目で検索できたとして、それらを等しくユーザーが使うかと言うとそんなことはありません。項目によって使われる度合いには差がでるのが普通です。そこで、検索のキーなど入力パラメータの種類に応じて、プロダクトバックログアイテムを分割します。検索項目によって実装の重要性は変わってくるので、分割後の複数のプロダクトバックログアイテムを後回しにできる可能性が高いです。

4. 利用者の役割によって分割

分割前
- ユーザーは宿泊候補の部屋の詳細を見ることができる
分割後
- 宿泊希望者は宿泊候補の部屋の詳細を見ることができる
- ホテルの従業員は部屋の詳細を登録・更新することができる
- ホテルの管理者は部屋の詳細を削除することができる

似たような操作を一般ユーザー、管理者など異なる利用者が行う場合があります。そのような場合に利用者の役割に応じてプロダクトバックログアイテムを分割します。このプロダクトバックログアイテムで言えば、宿泊希望者が部屋の詳細を見るためには何らかの機能が必要になりますが、一方で従業員や管理者による運用の操作については機能を作らなくても手作業で対応できます（頻度が多いと大変ですし、将来的には作らなければいけないかもしれません）。つまり作るべきタイミングは変わってくる可能性があるということになります。

5. 最適化の度合いで分割

分割前
- ユーザーはホテルの空き情報を知ることができる
分割後
- ユーザーは条件を指定して検索ボタンを押すとホテルの空き情報を知ることができる
- ユーザーが条件を指定すると、それに合致した空き情報がリアルタイムに絞り込まれて表示される

理想形はリッチな動作にしたいと思っていても、必ずしも最初からそれが必要とは限りません。例えば、この例のようなフロントエンド側の最適化は、ほかの機能ができておらず一気通貫で動作しない段階で作ってもムダになる可能性があります。機能の最適化はいくらでもできてしまいますが、まずは最低限でも一気通貫を満たしてから、最適化を必要に応じて進めた方が、リリース可能な状態を維持しやすくなります。

6. プラットフォームで分割

分割前
- ホテルの従業員は予約状況を見ることができる
分割後
- ホテルの従業員はブラウザで予約状況を見ることができる
- ホテルの従業員はスマホで予約状況を見ることができる
- ホテルの従業員は予約状況を印刷することができる

さまざまなプラットフォームに最初から対応しなければいけないわけではありません。最近話題のclubhouseではユーザーが利用できる端末はiOSだけになっています。過度にプラットフォームの幅を広げてしまうと貴重な時間や人的資源が分散してしまうことになります。また新たな技術の習得や、新しいチームの立ち上げが必要になってしまうこともあります。プロダクトがマーケットに受け入れられるかが確認できるまでは、幅を拡げず特定のプラットフォームに集中するのは分かりやすい作戦です。

7. ビジネスルールで分割

分割前
- ユーザーはホテルを予約することができる
分割後
- ユーザーは部屋と日程を指定して、ホテルの予約を送信できる
- ホテルの宿泊予定者と部屋の定員が一致していない場合は予約できない
- 宿泊予定者に子供が含まれる場合は、料金を変更する

機能には、なんらかの制約や計算、ロジックなどのビジネスルールが含まれます。どれくらいのルールが含まれるかは機能によって違います。確定申告のWebサイトなんかは、大量のビジネスルールを含んでいる典型例でしょう。そういった大量のルールを1スプリントのなかで実現するのは難しいため、ビジネスルールを軸にしてプロダクトバックログアイテムを分割するのもよくある手です。誰もが適用されるようなビジネスルールの実装を優先し、めったに発生しないようなビジネスルールは実装しないか後回しにするといった選択を行います。

8. ワークフローのステップで分割

分割前
- ユーザーはホテルを予約することができる
分割後
- ユーザーは部屋と日程を指定して、ホテルの予約を送信できる
- ユーザーはホテルの予約をする際に本人確認が行われる
- 予約が終わったら確認メールがユーザーに届く

ユーザーが利用するワークフローのステップで分割します。ただし、分割したあとのプロダクトバックログアイテム単体では意味のなさなくなるような分割の仕方は避ける必要があります。上記の例では、ホテルの予約のワークフローに含まれる要素のうち、ワークフローから取り除いても目的が達成できるものを切り出しています。つまり、予約の際の本人確認はしなくても予約はできますし、予約後の確認メールを送らなくても予約はできます。このようにして、ワークフローに含まれる必須部分を維持した形で分割するのが良いでしょう。当然ながら、分割した結果、それぞれのプロダクトバックログアイテムは異なる実装順になる可能性があります。

9. 操作(CRUDなど)で分割

分割前
- ホテルの従業員は宿泊対象の部屋を追加、更新、削除できる
分割後
- ホテルの従業員は宿泊対象の部屋を追加できる
- ホテルの従業員は宿泊対象の部屋を更新できる
- ホテルの従業員は宿泊対象の部屋を削除できる

これはイメージが付きやすいと思います。 CRUDすべてが同時に必要なこともあれば、削除は後回しにしても構わない場合が結構あります。もちろんRuby on Railsなどのフレームワークを活用することで、CRUDを同時に作るコストは低くなることもあるので、無理にこの観点で分割しなくて良い場合もあります。

10. ブラウザの種類やバージョンによって分割

分割前
- ユーザーはホテルの空き情報を知ることができる
分割後
- ユーザーはホテルの空き情報を最新のChromeとFirefoxとSafariとEdgeで知ることができる
- ユーザーはホテルの空き情報をIE11で知ることができる
- ユーザーはホテルの空き情報をIE8-10で知ることができる

これはプラットフォームの話と似ています。対象ブラウザのバージョンを拡げれば拡げるほどテストや開発に時間がかかるようになるので、必ずしも最初から全てのブラウザをサポートするのが良いとは限りません。ちなみに確定申告では今年からマイナンバーカードとChromeの組み合わせがサポートされるようになりました。最初のうちは主要なブラウザだけをカバーしておいて、多くの利用者がプロダクトを使うようになってから検討しても遅くありません。昔はIE対応だけ別料金貰ってましたね。