この記事は、Lavaneesh Gautamさんの「Benefits Of Smaller Product Backlog Items」を翻訳したものです。翻訳はLavaneeshさんの許諾をいただいています。誤訳、誤字脱字がありましたら、ご指摘ください。
プロダクトバックログリファインメント
スクラムでは、プロダクトバックログリファインメントとは、大きなプロダクトバックログアイテム（PBI）を小さなアイテムに分割し、受け入れ基準、価値、サイズ、依存関係などPBIの詳細を理解していく活動である。
しかし、PBIを細かく分割する理由とはなんだろうか
この質問は、トレーニング、コーチング、コンサルティングの仕事においてよく聞かせるものだ。この記事では、PBIを小さくすることでチームが得られる主要なメリットについて、私見を述べていく。
より小さなプロダクトバックログアイテムの主要なメリット
より小さなPBIのメリットは数多くあるだろうが、以下の5つを主要なメリットとして選出した。
- フィードバックループの短縮
- 学びの強化
- フローの改善
- より良い優先順位づけ
- 実験の機会
以下でこれらの解説していく。
1. フィードバックループの短縮
アジャイルな働き方の主なメリットの一つは、ユーザーや顧客にリーチすることで、フィードバックループを短縮することである。フィードバックループとは、想定した価値が提供されたかどうかを知ることを指す。
そのためには次のことが必要となる。
- ビジネス目標を理解し、ユーザーや顧客にサービスを提供することによって、それをどのように実現させるかを理解することにより価値を発見する
- 顧客やユーザーのニーズや問題を満たすソリューションを提供する
- 顧客やユーザーに提供したものから学ぶことで、自分たちが想定していた価値が正しかったかどうかのデータを得る
フィードバックループが短い方がソフトウェア開発にとってより良い
2. 学びの強化
フィードバックループはすべての学びのためにある。より小さなPBIによって作られるより短いフィードバックループがより良い学びになる。
以下について学ぶことができる。
- 真のユーザーと顧客は誰なのか
- そのニーズや問題は存在するのか
- ユーザーや顧客は、そのニーズや問題に価値を感じているか
- これらのニーズや問題が解決されたとき、我々は何らかのビジネス上の恩恵を得ることができるのか
プロダクトマネジメントは学びがすべてである
3. フローの改善
カンバンの概念を知っていれば、価値の流れ（価値フロー）が如何に重要であるかも知っているだろう。
PBIが小さくなれば、ワークフローのステージ（段階、ステップ）をより速く通過できることになる。これはサイクルタイムを短縮し、スループットを向上させるものであり、多くの組織が目指しているものである。
より小さなPBIであれば、フローを妨げているものを容易に見つけ出すことができる。
- 他者の判断を待っているか
- チームにおいてスキルや技術的なギャップがないか
一般的に、このようなギャップはチームの外からの支援で埋められるため、より多くの待ち時間を必要とする - 必要なコラボレーションが取られているか、もしくは、サイロ化していないか
価値フローを妨げているものを特定できれば、改善の機会が得られる。
より良いフローにより、「完成」に到達でき、価値の仮説を検証する機会を得られる。
価値を提供する唯一の方法はリリースすることだ。それ以前は仮説に過ぎない
4. より良い優先順位づけ
なにごとも大きければ重要であるように見えるが、これがプロダクト開発における最大の頭痛の種のひとつを引き起こしている。それは、優先順位づけだ。
PBIを小さく分割し始めると、以下がより明確になっていく。
- ユーザーの役割の違い
- ビジネスルール
- ワークフローのステップ（手順）
- シナリオやユースケース
- 運用方法
すべてのユーザーの役割を同時に満たす必要はない。まずは、いくつかのユーザーの役割を見つけ出すことから始めることができる。
すべてのビジネスルールを同時に満たす必要はない。いくつかは延期することだってできる。
すべてのワークフローのステップを同時に提供する必要はない。例えば、まずオンボーディングに焦点を当て、支払いについては後で考えることだってできる。
すべてのシナリオを一度に開発する必要はない。何回かのプロダクト開発に跨っても構わない。
5. 実験の機会
多くの組織と仕事をしてきたが、そこではリーダーたちは実験をやりたがらないことが多かった。それについてさらに掘り下げてみることにする。彼らは実験をやりたがらないのではなく、失敗のリスクとそれに伴うコストを問題にしていたのだ。
- 新たなユーザーや顧客を開拓するリスク
- 顧客の問題を理解しないリスク
- 顧客やユーザーが何を好むのか、あるいは好まないのかを知らずに開発するリスク
- 同じアウトカムを得るために新しいテクノロジーやソリューションを試すリスク
PBIが大きい場合、これらのリスクも大きくなり、それゆえに潜在的な失敗に関連するコストも大きくなる。
PBIをより小さなPBIに分割できれば、大きなリスクも小さなリスクに分割できることになる。
リーダーやマネジメントの多くは、より小さなリスクを許容できるし、PBIを小さくすることで実験と学びの文化を可能とする。
まとめ
より小さなPBIには、プロダクト開発において計り知れないメリットがある。以下がそのトップ5だ。
- フィードバックループの短縮
- 学びの強化
- フローの改善
- より良い優先順位づけ
- 実験の機会
皆さんの経験をコメントで共有hし、他にどんなメリットがあったかを教えて欲しい（※訳註: コメントは、英語で原文に対して行なっていただくか、Xなどに日本語でおこなって欲しい）。
このトピックについてさらに学びたいならば、Professional Scrum Product Backlog Management (PSPBM) Skills コースを受講して欲しい。
Scrum.org 訳註: 著者のLavaneeshさんの情報はこちら：
本記事の翻訳者:
長沢 智治 - アジャイルストラテジスト
サーバントワークス株式会社 代表取締役。Helpfeel Inc. アドバイザリーボード。DASA アンバサダー/認定トレーナー。
『More Effective Agile』、『Adaptive Code』、『今すぐ実践！カンバンによるアジャイルプロジェクトマネジメント』、『アジャイルソフトウェアエンジアリング』など監訳書多数。『Keynoteで魅せる「伝わる」プレゼンテーションテクニック』著者。
Regional Scrum Gathering Tokyo 2017, DevOpsDays Tokyo 2017, Developers Summit 2013 summer 基調講演。スクー講師。
