2024.07.18
アジャイル開発のなかでも、チームが一丸となって開発を進めていく「スクラム開発」が広く採用されています。
スクラム開発においては、基本要素ともいえる「プロダクトバックログ」の作成が欠かせません。プロダクトバックログの存在自体は知っていても、どのように作ればよいのか疑問に感じている方も多いのではないでしょうか。
今回はプロダクトバックログとは何か、基本からわかりやすくお伝えします。記事の後半では、プロダクトバックログの作り方や書き方のポイントも紹介するため、ぜひ参考にしてみてください。
- もくじ
1．プロダクトバックログとは
プロダクトバックログとは何か、誰が作るのか、スプリントバックログとの違いについて解説します。
1‐1 プロダクトバックログとは
プロダクトバックログは、プロダクト（製品）とバックログ（やり残し、残務）を組み合わせた造語です。つまり、スクラム開発におけるプロダクトバックログとは、プロダクトに対して適用されるべき残件を管理するリストを指します。
スクラム開発では短期間の「スプリント」で開発を区切り、各スプリントでさまざまな開発項目に対応していきます。こうした開発項目に優先順位を付け、全体の対応状況を管理するものがプロダクトバックログです。スクラム開発においては基本要素といえます。
なお、そもそもスクラム開発とは何か、概要を確認しておきたい方は、次の記事をご覧ください。
1‐2 プロダクトバックログは誰が作る？
プロダクトバックログは、スクラム開発における「プロダクトオーナー」が中心となって作成するのが一般的です。プロダクトオーナーは、プロダクトを開発するうえでの責任者であり、プロダクト全体の最終的な意思決定を担います。
プロダクトオーナーは顧客から要求をヒアリングし、その内容をもとにプロダクトバックログに追加すべき開発項目を明確にします。また、それらに優先順位を付けたり、全体の状況を管理したりするのもプロダクトオーナーの役割です。
1‐3 スプリントバックログとの違い
プロダクトバックログと関連する要素に「スプリントバックログ」があります。スプリントバックログとは、1サイクル分のスプリントにおける残件をまとめたリストのことです。
プロダクトバックログは、全スプリントを通して管理します。対してスプリントバックログは、1スプリントの残件だけを管理するのが違いです。
一般的に、スプリントの進行中はスプリントバックログで残件を管理し、スプリント終了時などにプロダクトバックログへ反映します。スクラム開発では、2つのリストを適切に併用しながら、効率的に残件を管理することが大切です。
2．プロダクトバックログを作成する目的
プロダクトバックログを作成する目的は、主に次の3つです。プロダクトバックログの基本的な特徴も交えて解説します。
2‐1 方針決定の効率化
プロダクトバックログの各アイテムには、優先順位やステータス（対応状況）を記載することが一般的です。これにより、「何を優先すべきか」「何が終わっていないか」が可視化されるため、次のスプリントに向けた方針決定の効率化が期待できます。
2‐2 残件の対応漏れ防止
各スプリントの残件をバラバラに管理すると、何を対応すべきかわからなくなりがちです。その点、プロダクトバックログには全スプリントを通しての残件を記載します。プロダクトバックログにスプリントの残件を集約することで、対応漏れの防止につながるでしょう。
2‐3 ステークホルダーとの対話円滑化
プロダクトバックログはスクラムチームのみならず、顧客や運用チーム、経営陣といったステークホルダーとの対話にも活用可能です。
それまでのスプリントにおける残件が集約・可視化されているため、対外的な開発状況の説明にも役立つでしょう。
3．プロダクトバックログに記載する主な項目
プロダクトバックログで管理する「残件」とは、具体的にどのような項目なのでしょうか。プロダクトバックログに記載する主な項目は、次の4つです。
3‐1 追加機能（フィーチャー）
ユーザーに価値を提供するために、文字どおり新しく追加する機能の項目です。アジャイル開発では「フィーチャー」と呼ばれることもあります。ユーザーが必要とし、その価値を認識できる追加機能は全てフィーチャーとして記載しましょう。たとえば、「ファイル出力機能の追加」のように小規模な開発内容であっても記載対象となります。
なお、追加機能を整理する際には「ユーザーストーリー」と呼ばれる手法で言語化することがポピュラーです。ユーザーストーリーについて詳しくは、次の記事をご覧ください。
3‐2 バグ修正
それまでのスプリントを通して判明している、修正すべきバグの項目です。スプリント内で解決できなかった、あるいは次のスプリント以降に持ち越したいバグを記載します。
顧客からフィードバックを受けた問題も含めて、原因がソフトウェアのバグであれば記載しましょう。ただし、問題の指摘時点ではバグなのか判断できない場合も考えられます。この場合、チームによっては後述する「技術的負債」として扱うケースもあります。
3‐3 技術的負債
「技術的負債」とは明確なバグではないものの、技術的に改善の余地がある項目です。たとえば、古いライブラリの更新、暫定対応した箇所の恒久対応などが挙げられます。
顧客やエンドユーザーの目に付く問題は生じないことが多いため、追加機能やバグ修正と比べて優先順位は低くなりがちです。しかし、技術的負債が積み重なると後から「返済」が困難になりやすいため、できる限り早期に対応しましょう。
3‐4 知識獲得
文字どおり、将来（次のスプリント以降）を見据えて知識の獲得が必要となる項目です。たとえば、新機能を実現するための事前調査、新しいライブラリに対応するための事前学習などが挙げられます。
技術的負債と同様、追加機能やバグ修正と比べて優先順位は低くなりやすいでしょう。しかし、いざ必要となったタイミングで必要な知識がないと対応が困難となるため、漏れなく記載しておくことが大切です。
4．プロダクトバックログの作成手順
スクラム開発を正しく進めるために、プロダクトバックログの作成手順を把握しておきましょう。プロダクトバックログの作り方は、大まかに次の6ステップです。
ステップ1 プロダクトゴールの明確化
まずは「プロダクトゴール」を明確化します。プロダクトゴールとは、全スプリントを通して目指す最終的なプロダクトの姿や、提供すべき価値のことです。プロダクトゴールを明確化したうえで、その達成に向けて開発を進めていきます。
プロダクトオーナーが中心となり、プロダクトゴールを明確化します。このとき、ステークホルダーの要求をヒアリングし、正しく反映させることが大切です。対外的なニーズに応えられないプロダクトゴールでは、最終的な成功にはつながりません。
ステップ2 プロダクトバックログアイテムのリストアップ
明確となったプロダクトゴールを踏まえて、「プロダクトバックログアイテム（PBI）」をリストアップします。PBIとは、プロダクトバックログに記載する各項目（追加機能・バグ修正・技術的負債・知識獲得）のことです。プロダクトゴールの達成に必要となるPBIを漏れなくリストアップしましょう。
プロダクトオーナーのみならず、スクラムチームの各メンバーを含めて協議しながらPBIを決めていきます。この段階では漏れなくリストアップすることが重要であり、優先順位はまだケアしなくて構いません。
ステップ3 各アイテムの優先順位付け
ひと通りPBIのリストアップが完了したうえで、各アイテムに優先順位を付けます。顧客の要求度の高さや想定される工数、後回しにすることのリスクなどを考慮し、総合的に優先順位を判断しましょう。ここでもスクラムチーム全体での協議が欠かせません。
なお、各アイテムの工数を見積もる際には「ストーリーポイント」と呼ばれる手法が広く用いられます。ストーリーポイントとは、1つのアイテムを基準として各アイテムの難易度を考え、相対的に評価するものです。たとえば、あるタスクを「1ストーリーポイント」と評価した場合、他のタスクはそのタスクと比べてどれくらい難易度が高いのか、低いのかをストーリーポイントで表します。評価の基準はスクラムチームによります。
ステップ4 スプリントバックログへの落とし込み
各アイテムに優先順位を付けた後は、スプリントバックログへの落とし込みが必要です。プロダクトバックログの中から、次のスプリントで対応すべきPBIをピックアップし、スプリントバックログに記載します。優先順位や工数を考慮しながら実施しましょう。
ただし、プロダクトバックログのアイテム単位だと抽象的で、各メンバーが対応しづらい場合があります。その場合は、PBIを詳細に分割してからスプリントバックログに記載しましょう。完成したスプリントバックログに沿って、開発を進めていきます。
ステップ5 完了確認・プロダクトバックログへの反映
現在のスプリントが終了するタイミングで、スプリントバックログに記載された各アイテムの完了確認を行います。修正が完了していないバグや、追加できなかった機能などがあれば、それらの情報をプロダクトバックログへ反映しましょう。
また、そのスプリント内で完了したPBIがあれば、プロダクトバックログ内の該当項目をクローズします。以降のスプリントでも、「プロダクトバックログからスプリントバックログに落とし込み、プロダクトバックログへ反映する」といった流れで進めていきます。
ステップ6 プロダクトバックログリファインメントの定期実施
「プロダクトバックログリファインメント」を定期的に実施しましょう。プロダクトバックログリファインメントとは、各PBIの優先順位や過不足などを見直すことです。
スプリントを進めていくなかでPBIの優先順位が変わったり、増減したりすることも考えられます。定期的に見直しを行い、全体の整合性を保ちましょう。
5．プロダクトバックログにおける書き方のポイント【例文付き】
プロダクトバックログを有効活用するために、書き方のポイントも押さえておきましょう。ここでは、例文も交えてプロダクトバックログにおける書き方のポイントを3つ紹介します。
5‐1 社内外を問わず伝わるように書く
プロダクトバックログは、社内外を問わず伝わるように書きましょう。内部の事情を知らない顧客や経営陣などにも見せる場合があるため、チーム内にしか伝わらない表現はNGです。
たとえば勤怠管理サービスを開発する場合、「従業員は残業を申請できる」「管理職は従業員の残業申請を承認できる」といった書き方が考えられます。このように、開発に携わっていないステークホルダーでも理解できるレベルの書き方がよいでしょう。
5‐2 各アイテムが詳細すぎるのはNG
プロダクトバックログの各アイテムが詳細すぎるのはNGです。あまりに具体的な内容を入れると対外的に伝わらないばかりか、アイテムが増えて管理が煩雑になってしまいます。
たとえば、「シフトテーブルに備考カラムを追加」「申請用の関数を共通化」のように、設計やプログラムレベルの書き方は適切ではありません。このように詳細なアイテムは、基本的にスプリントバックログで管理すべきです。プロダクトバックログに記載するのであれば、「労務担当者はシフトに備考を追加できる」のように抽象化しましょう。
5‐3 明確な完了条件を盛り込む
プロダクトバックログには、明確な完了条件を盛り込みましょう。完了条件が明確になっていないと、スプリントの終了時に完了確認を正しく行えません。完了条件についても、ステークホルダーに説明しやすいよう、伝わる表現を心がけるべきです。
たとえば、追加機能の場合は「機能テストでNG判定がないこと」「コードレビューが完了していること」といった書き方が考えられます。ある程度は共通化できますが、項目の種類（追加機能やバグ修正など）によって変える必要があるでしょう。
まとめ
スクラム開発におけるプロダクトバックログとは、プロダクトに対して適用されるべき残件を管理するリストのことです。適切にプロダクトバックログを運用することで、残件の対応漏れ防止や方針決定の効率化、ステークホルダーとの対話円滑化につながります。
プロダクトバックログの作り方や書き方のポイントを把握し、より高品質なスクラム開発を実現しましょう。
なお、プロダクトバックログに限らず、IT関連のノウハウに関する理解を深めたい場合は、当サイト「Qbook」をご活用ください。
Qbookの無料会員登録を行えば、イベント情報や業界人のインタビューなど、最新のお役立ち情報をメールマガジンで受信できます。
