---

スクラムのプロダクトバックログとは？意外な発見があるかもしれません！

プロダクトバックログ、スクラムバックログ、スクラムプロダクトバックログ は、スクラムのプロダクトに関する、把握しているすべての要求を管理する中心的な要素です。

プロダクトを改善し、ゴールを達成するために必要な、新たに明らかになる作業を順序付けたものです。 要求には、機能・非機能要件や、ユーザー体験とインターフェース設計に関する機能を数えます。

機能の要求と、その大まかなユーザーストーリーを含みます。テスト・開発環境の構築など、前提や補助となる要求も含められます。また、既知のバグの解決、技術的負債の削減、特定機能の改善のためのストーリーも入ります。

プロダクトごとに一つのバックログを持ち、関わるすべてのスクラムチームで共有します。作成、維持、調整の責任は、プロダクトオーナーにあります。 これらの要求を、どのように開発して届けるかには答えませんし、答えるべきでもありません。

それはチームの仕事です。必要なタスクを決め、スプリントバックログに記録します。 プロダクトバックログの項目がスプリントバックログの内容を決めますが、両者は別々の実体であることに注意してください。

この スクラムプロダクトバックログ を所有するのはプロダクトオーナーです。スクラムマスター、チーム、その他の関係者が協力し、成功のための、より幅広いストーリーの一覧を作ります。

プロダクトバックログを使うことは、ほかの作成物を作り、作業の管理に使ってはいけないという意味ではありません。ユーザーの役割の一覧、作業の流れの説明、インターフェースの指針、ストーリーボード、試作品などを使えます。ただし、それらはバックログを置き換えず、内容を補い、詳しくするものです。

プロダクトバックログは、生きた文書です。 ソフトウェアが段階的に改善するように、バックログも時間とともに成長します。 スクラムは、それ自体として、別の変更管理プロセスを必須にしません。プロダクトオーナーは、最初の理解に基づいて、初期のバックログを作ります。

スプリントごとにプロダクトが形になる様子を注意深く観察し、顧客要求についての知識が増える中で、要求を追加、削除、調整します。

プロダクトオーナーが、バックログの要求に優先順位を付けます。 優先度が高い項目ほど、詳しく示す必要があります。チームが理解しやすくなり、実装に必要なタスクを作れます。

また、開発者は必要に応じてアイテムの規模を見積もります。ストーリーポイントは任意の手法の一つです。優先度の高いストーリーの見積もりを調整、改善し、プランニングに向けて準備します。

プロダクトバックログには、単なるやることリストとは異なる、固有の特徴があります。

• 各ストーリーが、顧客、事業の責任者、エンドユーザーに、事業上または技術上の価値を加える。
• すべてのストーリーに優先順位があり、高いものから順に並ぶ。
• ストーリーの詳しさが、バックログ内の位置に応じて変わる。
• 必要に応じ、適切な方法で規模を見積もる。
• 生きた文書である。
• プロダクトの作業を説明する。開発者の詳しい実行計画は、スプリントバックログに置く。

ユーザーストーリーは、顧客、事業、システムに価値を加える

各ストーリーは、何らかの顧客価値を提供する必要があります。 顧客価値がないストーリーはリソースの浪費なので、除くべきです。バックログには、次のためのストーリーを含められます。

• 機能・非機能要件の仕様化。
• ソフトウェア製品の立ち上げに必要な作業の、大まかな分割のまとめ。
• 本番以外の開発・実演環境の構築。
• 不具合の修正。

スクラムプロダクトバックログの例

一部のタスクは、機能や事業の顧客に、直接の価値を加えない場合があります。それでも、品質向上、技術的負債の削減、長期的な保守性の向上によって、価値を加えるべきです。

プロダクトバックログは生きた文書

プロダクトバックログは、プロジェクトの全期間を通じて変化し、進化する、生きた文書です。必要なら新しいストーリーを追加し、既存のものを変更し、詳しくし、削除もします。ウォーターフォールのように、初期に要求を凍結することは、もはやありません。

最終的な要求の集合は、ソフトウェアのインクリメントが形になるのと共に、反復的に作られます。

従来の要求工学とは異なりますが、この方法によって、顧客価値を最大にし、リソースの浪費を最小にできます。

詳しさの違い

バックログの要求は、粒度の深さが異なっていても構いません。 次の数回のスプリントで実装する要求だけを、詳しく定義します。その他のストーリーは大まかなままにし、チームが詳しく知る必要が生じる直前に、「必要なときに」扱います。

実装までに変わったり、なくなったりする要求の仕様化に、時間とリソースを投じる意味はありません。 要求を必要なときに扱うことは、プロジェクトの「何が分からないかも分からないこと」に対処する、スクラムの優れた利点の一つです。

プロダクトバックログに細かなタスクを入れない

プロダクトバックログは、通常、実行のための細かなタスク分割ではなく、プロダクトの作業を説明します。プロダクトオーナーは、リファインメントやプランニングに持ち込む前に、事業の顧客や関係者と要求を定義します。細かなタスク分割と、自分たちの仕事の組織化は、開発者の責任です。

プロダクトバックログは優先順位で並ぶ

すべてのストーリーに優先順位を付け、高い順に並べます。プロダクトオーナーが、チームの支援を受けて行います。顧客の事業への付加価値、費用、リスク、依存関係が、主な考慮点です。これにより、次に何を作り、届けるべきかを決められます。

プロダクトバックログアイテムの規模を見積もる

開発者は、フィボナッチ型のストーリーポイントや、S/M/L/XL/XXLなどの相対的なサイズといった、合意した手法で見積もれます。スクラムは、単一の尺度や、遠い将来の全アイテムの見積もりを必須にしません。詳しくは後で説明します。見積もりは、スプリントのキャパシティ計画、スプリントバックログ、リリース計画に影響します。

バックログを扱う

プロダクトバックログには、定期的な手入れと注意が必要です。丁寧に管理する理由は、 ソフトウェア製品の全体像を理解するための、信頼できる情報源だからです.

。最初は、多数の大まかなストーリーが入り、成功に大きく貢献するものも、そうでないものもあります。 スプリントを重ねる中で、プロダクトオーナーとチームは、より多くを学びます。

それによって、内容は次第に、プロダクトとチームの学びを反映していきます。

最初の準備の後も、維持を続ける必要があります。維持とは、次のことです。

• 新しい要求を見つけたら、説明し、追加する。既存の要求は、必要に応じて変更、削除する。
• 順序付け、つまり優先順位付けを行い、最も重要なストーリーを上に移す。
• 通常はリファインメントで、次のプランニングに向け、優先度の高いストーリーを準備する。
• 通常はリファインメントで、ストーリーを見積もる、または見積もり直す。

常に良い状態を保つ責任はプロダクトオーナーにありますが、維持は協働的なプロセスです。 継続的なリファインメントとスクラムイベントの時間のため、チームのキャパシティを適切に確保する必要があります。

また、共同で維持することで、要求が明確になり、形になっていくプロダクトに対するメンバーの納得と支持が生まれます。