バックログアイテムを工程で切るのをやめる。価値を保ったまま小さくする5つの軸
スプリントプランニングで「このアイテムは大きすぎるので分割しましょう」と言ったものの、出てきた案が「設計」「実装」「テスト」の3つだった。あるいは分割しようとして手が止まり、結局そのまま大きなアイテムを積んだ。どちらもよくある場面です。
この記事では、工程での分割が行き詰まる理由を整理したうえで、価値を保ったまま小さくするための具体的な軸と、分割できたかどうかを判定する基準を扱います。
大きいまま積むと、間違いに気づく日が遅れる
分割の理由としてよく挙がるのは、スプリントに収まらない、レビューで見せるものがない、1人の作業に固定される、の3つです。どれも実害ですが、症状の列挙であって、なぜ小さくするのかの答えにはなっていません。
本質は1つです。**アイテムの大きさは、間違いに気づけるまでの時間を決めます。**作っているものが違っていた、と分かるのは動くものを見せた瞬間です。大きいアイテムは、その瞬間を後ろへずらします。2週間かかるアイテムを積むことは、2週間分の作業を「合っているかどうか不明」のまま積み上げると決めることと同じです。
スクラムが短いスプリントを刻むのは、この「不明のまま進む距離」に上限を付けるためです。分割は、同じ操作をアイテムの単位で行うことに当たります。だから分割の良し悪しは、作業が細かくなったかではなく、確かめられる瞬間が早まったかで判定します。
この基準から見れば、冒頭の3つの症状は同じことの現れです。スプリントに収まらないとは1スプリントでは確かめられないということで、レビューで見せられないとは確かめる材料がないということです。1人の作業に固定されるのも、確かめる目が1人分しか通らないという形で同じ場所に行き着きます。
進捗が見えない原因も同じです。デイリースクラムで「まだ続けています」という報告が同じアイテムについて3日以上続いているなら、報告の仕方より先に粒度を疑う価値があります。
工程で切ると行き詰まる理由
最初に思いつくのは、設計・実装・テストという工程での分割です。作業としては確かに分かれますが、これは分割としては機能しません。
理由は単純で、どれ1つとして単独では完成しないからです。設計だけが終わってもレビューで見せられません。テストを含む完成の定義であれば、実装だけが終わった状態でも満たせません。
つまり、作業は3つに分かれたのに、確かめられる瞬間は1日も早まっていません。最後のテストが終わるまで、動くものはどこにも存在しないためです。前のセクションの基準に照らせば、これは分割ではなく、大きいアイテムに区切り線を書き込んだだけです。
工程に手が伸びるのは、技術の問題というより、既にそこに線が引かれているからです。設計・実装・テストは日々の分業の単位として現に存在しています。一方で価値の単位は、誰かが言葉にするまでチームの中に存在しません。手近にある線を使うのは自然な反応です。
必要なのは、その線とは別の方向に切ることです。工程は縦、価値は横と置くと整理しやすくなります。分割は横に切ります。
価値を保ったまま小さくする5つの軸
実務で使いやすい順に挙げます。上から順に当てて、切れた時点で止めます。5つとも当てはまらない作業もあるため、その場合は後半の「無理に分割しなくてよい場合」に進みます。
1. 流れを細く通す
利用者が行う一連の流れがあるとき、最初のステップだけを切り出したくなります。「商品を検索して、絞り込んで、並べ替えて、詳細を見る」なら、まず「検索して結果が出る」だけを作る形です。
これは半分だけ正解です。検索結果は出ても、詳細にたどり着けなければ、利用者は目的(欲しい商品を見つけて確かめる)を果たせません。画面が出ることは確かめられても、この流れで価値が成立するのかという一番大きい不確かさは、最後のステップがつながるまで残り続けます。
そこで、流れを途中で切るのではなく、最初から最後までを最も細い形で通します。検索はキーワード一致だけ、絞り込みと並べ替えは省略、詳細画面は最低限の項目だけ。この状態でも利用者は目的を果たせるので、流れ全体が成立するかを最初のスライスで確かめられます。絞り込みや並べ替えは、通った流れを太くする後続アイテムになります。切り落とすのはステップではなく、各ステップの中の贅肉です。
省いた機能を必ず作ると決めてしまわないほうが、選択肢が残ります。細い流れが動いた時点で、後続の優先度が下がることは珍しくありません。分割の利点の1つは、途中でやめる判断ができるようになることです。
2. 業務ルールで切る
正常系だけを先に作り、例外や特殊なルールを別のアイテムに送ります。
「注文をキャンセルできる」であれば、まず発送前のキャンセルだけを扱い、発送後の返品処理は分けます。例外処理は往々にして本体より大きいので、この軸は効果が大きくなります。
この軸を使うときは、対象外にしたケースが起きたらどうなるかをプロダクトオーナーと確認しておいてください。画面に出さない、エラーとして弾く、運用で回す、といった選択肢があります。ここを決めずに正常系だけ作ると、リリースの直前で差し戻されます。
3. 扱うデータで切る
対象とするデータの種類や範囲を絞ります。
「すべての支払い方法に対応する」を、まずクレジットカードだけにする、といった切り方です。種類が増えても仕組みが同じなら、2件目以降は最初の1件よりずっと小さくなります。
4. 見た目で切る
まず最小限の画面で成立させ、洗練は別のアイテムにします。一覧を装飾なしのテーブルで出し、デザインの適用を後続に回す、といった形です。
この軸は反発を受けやすい軸です。未完成品を見せられたと受け取られると、次から協力を得にくくなります。「見た目は次のスプリントで整えます。今日は流れが成立しているかを見てください」と、レビューの前に伝えておきます。
5. 品質特性で切る
性能、多言語対応、権限制御といった横断的な要求を、後続のアイテムに分けます。
「1万件でも3秒以内に表示する」を最初から満たそうとすると、本体の実装が終わりません。まず件数を限定して動かし、性能は別アイテムで扱います。ただし、後回しにすると作り直しになる種類の要求もあるので、この軸は開発者の判断を必ず入れてください。
分割できたかどうかの判定
切ったあとに、次の2つを確認します。どちらも満たしていなければ、それは工程での分割になっている可能性があります。
- 単独でレビューできるか。そのアイテムだけが完成した状態を、誰かに見せて意見をもらえるか
- 順序を入れ替えられるか。1番目と3番目を入れ替えても、それぞれ独立して完成できるか
2つ目は厳密である必要はありません。実際には依存関係が残ることもあります。ただ、すべてのアイテムが一直線にしか進められないなら、それは1つの作業を並べ替えただけです。
判定に迷ったときは、そのアイテムが完成したら何を確かめられるかを考えてみてください。答えられないなら、確かめられる瞬間は早まっておらず、価値の単位で切れていません。
分割はリファインメントで行い、プランニングの場では行わないほうがうまくいきます。プランニングは時間の制約が強く、その場で分割を考えると工程で切る案に流れがちです。リファインメントで切っておけば、プランニングでは並べ方と量の判断に集中できます。リファインメントの時間が取れていないなら、プランニングの冒頭に分割だけの枠を先に切っておくと、工程で切る案に流れにくくなります。
無理に分割しなくてよい場合
すべてのアイテムが価値の単位で切れるわけではありません。次のような作業は、無理に切ると不自然になります。
- データベースの移行や基盤の入れ替えなど、途中の状態が存在しない作業
- 調査そのものが目的の作業(何が必要かを調べないと分割の軸も決まらない)
前者は、切るのではなくスプリントに収まる規模まで対象範囲を絞るほうが現実的です。移行対象のテーブルを限定する、といった形になります。
後者については、時間を区切った調査を1つのアイテムとして扱い、その結果をもとに次のスプリントで分割します。調査に上限時間を設けておかないと、際限なく広がります。調査の完了条件は「分かったこと」ではなく「次に何を作るかが決まった状態」と定義しておくと、締めやすくなります。
分割の型を覚えると、すべてを型に当てはめたくなります。ただし目的は小さくすること自体ではなく、スプリント内で完成させてフィードバックを得ることです。
明日からの一歩
次のリファインメントで、一番大きいアイテムを1つ選び、上の5つの軸を順に当ててみてください。まず1番目の「流れを細く通す」を当て、切れなければ2番目、3番目と試します。
切ったあとは、必ず「このアイテムだけ完成したら誰かに見せられるか」を確認してください。見せられないなら、まだ工程で切っています。