ブログ

ryuzeeによるブログ記事。不定期更新

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

みなさんこんにちは。@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対応だけ別料金貰ってましたね。

11. テストシナリオ・テストケースで分割

  • 分割前
    • ユーザーはホテルの空き情報を知ることができる
  • テストケース
    • 既に予約済の部屋の場合は、選択できない
    • メンテナンスなどで宿泊不可能な場合は、表示しない
    • デフォルトでは部屋番号順にソートされている
    • ……

これはここまで紹介した例とちょっと毛色が違います。 大きなプロダクトバックログアイテムがあって、分割が必要だけれども分割の仕方が難しいような場合に、テストケースを洗い出してそれを元に分割します。 分割した結果は、ここまでに出てきた分割パターンの組み合わせに収束することになります。

それでは。

アジャイルコーチングやトレーニングを提供しています

株式会社アトラクタでは、アジャイル開発に取り組むチーム向けのコーチングや、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください。

詳細はこちら
  • スクラム実践者が知るべき97のこと
  • 著者/訳者:Gunther Verheyen / 吉羽龍太郎 原田騎郎 永瀬美穂
  • 出版社:オライリージャパン(2021-03-23)
  • 定価:¥ 2,640
  • スクラムはアジャイル開発のフレームワークですが、その実装は組織やチームのレベルに応じてさまざまです。本書はスクラムの実践において、さまざまな課題に対処してきた実践者が自らの経験や考え方を語るエッセイ集です。日本語書き下ろしコラムを追加で10本収録
  • プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける
  • 著者/訳者:Melissa Perri / 吉羽龍太郎
  • 出版社:オライリージャパン(2020-10-26)
  • 定価:¥ 2,640
  • プロダクト開発を作った機能の数やベロシティなどのアウトプットで計測すると、ビルドトラップと呼ばれる失敗に繋がります。本書ではいかにしてビルドトラップを避けて顧客に価値を届けるかを解説しています。
  • SCRUM BOOT CAMP THE BOOK 【増補改訂版】
  • 著者/訳者:西村直人 永瀬美穂 吉羽龍太郎
  • 出版社:翔泳社(2020-05-20)
  • 定価:¥ 2,640
  • スクラム初心者に向けて基本的な考え方の解説から始まり、プロジェクトでの実際の進め方やよく起こる問題への対応法まで幅広く解説。マンガと文章のセットでスクラムを短期間で理解できます。スクラムの概要を正しく理解したい人、もう一度おさらいしたい人にオススメ。
  • みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた
  • 著者/訳者:Matt LeMay / 吉羽龍太郎、永瀬美穂、原田騎郎、有野雅士
  • 出版社:オライリージャパン(2020-3-19)
  • 定価:¥ 2,640
  • アジャイルで本当の意味での成果を出すには、開発チームだけでアジャイルに取り組むのではなく、組織全体がアジャイルになる必要があります。本書にはどうやってそれを実現するかのヒントが満載です
  • レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス
  • 著者/訳者:David Scott Bernstein / 吉羽龍太郎、永瀬美穂、原田騎郎、有野雅士
  • 出版社:オライリージャパン( 2019-9-18 )
  • 定価:¥ 3,132
  • レガシーコードになってから慌てるのではなく、日々レガシーコードを作らないようにするにはどうするか。その観点で、主にエクストリームプログラミングに由来する9つのプラクティスとその背後にある原則をわかりやすく説明しています。
  • Effective DevOps ―4本柱による持続可能な組織文化の育て方
  • 著者/訳者:Jennifer Davis、Ryn Daniels / 吉羽 龍太郎、長尾高弘
  • 出版社:オライリージャパン( 2018-3-24 )
  • 定価:¥ 3,888
  • 主にDevOpsの文化的な事柄に着目し、異なるゴールを持つチームが親和性を高め、矛盾する目標のバランスを取りながら最大限の力を発揮する方法を解説します
  • ジョイ・インク 役職も部署もない全員主役のマネジメント
  • 著者/訳者:リチャード・シェリダン / 原田騎郎, 安井力, 吉羽龍太郎, 永瀬美穂, 川口恭伸
  • 出版社:翔泳社( 2016-12-20 )
  • 定価:¥ 1,944
  • 米国で何度も働きやすい職場として表彰を受けているメンローの創業者かつCEOであるリチャード・シェリダン氏が、職場に喜びをもたらす知恵や経営手法、より良い製品の作り方などを惜しみなく紹介しています
  • アジャイルコーチの道具箱 – 見える化の実例集
  • 著者/訳者:Jimmy Janlén / 原田騎郎, 吉羽龍太郎, 川口恭伸, 高江洲睦, 佐藤竜也
  • 出版社:Leanpub( 2016-04-12 )
  • 定価:$14.99
  • この本は、チームの協調とコミュニケーションを改善したり、行動を変えるための見える化の実例を集めたものです。96個(+2)の見える化の方法をそれぞれ1ページでイラストとともに解説しています。アジャイル開発かどうかに関係なくすぐに使えるカタログ集です
  • カンバン仕事術 ―チームではじめる見える化と改善
  • 著者/訳者:原田騎郎 安井力 吉羽龍太郎 角征典 高木正弘
  • 出版社:オライリージャパン( 2016-03-25 )
  • 定価:¥ 2,138
  • チームの仕事や課題を見える化する手法「カンバン」について、その導入から実践までを図とともにわかりやすく解説した書籍。カンバンの原則などの入門的な事柄から、サービスクラス、プロセスの改善など、一歩進んだ応用的な話題までを網羅的に解説します。
  • Software in 30 Days スクラムによるアジャイルな組織変革“成功"ガイド
  • 著者/訳者:Ken Schwaber、Jeff Sutherland著、角征典、吉羽龍太郎、原田騎郎、川口恭伸訳
  • 出版社:アスキー・メディアワークス( 2013-03-08 )
  • 定価:¥ 1,680
  • スクラムの父であるジェフ・サザーランドとケン・シュエイバーによる著者の日本語版。ビジネス層、マネジメント層向けにソフトウェア開発プロセス変革の必要性やアジャイル型開発プロセスの優位性について説明
  • How to Change the World 〜チェンジ・マネジメント3.0〜
  • 著者/訳者:Jurgen Appelo, 前川哲次(翻訳), 川口恭伸(翻訳), 吉羽龍太郎(翻訳)
  • 出版社:達人出版会
  • 定価:500円
  • どうすれば自分たちの組織を変えられるだろう?それには、組織に変革を起こすチェンジ・マネジメントを学習することだ。アジャイルな組織でのマネージャーの役割を説いた『Management 3.0』の著者がコンパクトにまとめた変化のためのガイドブック