プロダクトバックログとは、チームおよびプロダクトで定めている目標を達成するために必要なタスクリストのことです。

主にアジャイル開発におけるスクラムで利用され、高品質な成果物を作り込む上で重要なものとなります。

今回は、そんなプロダクトバックログの概要や目的、実際に作成する流れを解説・紹介します。

プロダクトバックログとは

プロダクトバックログとは、開発チームが定めている目標を達成するために必要な「アイテム」「タスク」などに、優先順位または緊急性の高いものなどの順位をつけてリスト化したものです。

プロダクト（成果物）のバックログ（積み残し・残務・未処理分）という意味で使われ、開発においては以下のものを残します。

• 作業

• 機能

• 改善点 など

例えば、アジャイル開発のスクラムの場合に、スプリント計画の段階で作成するといった形で用いられます。

プロダクトバックログの役割

スクラムにおけるプロダクトバックログは、スプリントの期間中に取り組むべき作業タスク（アイテム）を特定・整理する役割を持ちます。

こうした役割を持つことで、完成度の高いプロダクトバックログを完成させられると以下のメリットが得られます。

• チームとゴールを共有できる

• 何をすべきか明確化できる

• リストに基づいてプロジェクトを滞りなく進められる

結果として、プロダクトバックログによって開発効率や完成度を高めることができ、より成果物は洗練されてニーズにマッチしたものができあがりやすくなることにも繋がります。

プロダクトバックログの要素

プロダクトバックログには、以下に挙げた4つの要素があります。

• フィーチャー（ユーザーストーリー）

• バグ修正

• 技術的負債

• 知識獲得

プロダクトバックログにはこれらの項目が含まれており、明確に分割されているものの「割り当てられていない作業内容」として保管されます。

フィーチャー（ユーザーストーリー）

フィーチャー（ユーザーストーリー）は、顧客から求められている製品における機能を指します。複雑なもの（エピック）や、単純なものまで含まれており、これらに基づいてどのような機能を制作すべきかを判断します。

なお、ユーザーストーリーはスクラムにおける要件定義のような形として機能していることも特徴です。

【関連記事】ユーザーストーリーとは｜概要や書き方・おすすめテンプレートを解説

バグ修正

バグ修正は、リリースした機能やコードなどにおけるバグを直す作業を指します。迅速に対応し、インテグリティ（誠実・真摯・高潔などの意）を維持するためにも重要な項目です

場合によってはスプリントを中断してでも実施することもあり、チームが忘れないようにプロダクトバックログの上部で保管されるケースが多くあります。

技術的負債

技術的負債とは、開発チームが技術的な作業を整理し、蓄積を防ぐために残されるものを指します。プロダクトバックログにおいて蓄積は非常に簡単ですが、溜め込み過ぎればいずれ「返済できない」状態に陥るのは明白です。

技術的負債をプロダクトバックログで明示的にし、それらを適切な感覚でチームが整理・対応することで、プロジェクトを滞りなく進められることから重要な項目として用意されます。

知識獲得

知識獲得は、将来発生するであろうタスクに対し、必要な情報を集める作業を指します。フィーチャーにおいて、情報収集および調査が必要で進められないものである場合には、知識獲得としてタスクを作成します。

さらに細かく分類される場合には、プロトタイプ・実験（概念実証）といったカテゴライズを行うこともあるのが特徴です。

プロダクトバックログとスプリントバックログとの違い

プロダクトバックログとスプリントバックログとの違いは、その対象範囲と焦点です。

プロダクトバックログは、プロダクトオーナーがコントロールし、製品全体のビジョンを対象に焦点を当てて作成されます。一方で、スプリントバックログはスプリントの期間中に開発チームで用いられるもので、その間に達成すべき目標に焦点が当てられているのも特徴でしょう。

また、プロダクトバックログは完了までの制限時間を明確に決めないものですが、スプリントバックログは期間内という制限があります。

さらには、スプリントバックログは製品完成まで変化し続けるプロダクトバックログに内包される形ですから、明確にタスクとして定義された細かい作業が記述されているのも大きな違いでしょう。

プロダクトバックログの作成方法

プロダクトバックログの作成方法は、以下のとおりです。

1. プロダクトゴールの決定

2. ロードマップの策定

3. 管理方法・管理ツールの選択

4. プロダクトバックログアイテムの作成

5. アイテムの優先順位を選定

6. 優先順位が高いものを細分化

7. 受け入れ基準の決定

8. リファインメントの実施

プロダクトゴールの決定

まず、プロダクトバックログではロードマップを作成するためにゴールを決定します。このゴールには、顧客がこれから開発するとしたプロダクトで実現したいことを設定します。

例として、顧客を管理するシステムを検討しているのであれば、解決したい課題や向上予定の生産性、業務内容の効率化指数などをプロダクトゴールとして定めるといった形です。

ロードマップの策定

プロダクトゴールを決定したら、ゴールから逆算しながらロードマップを策定します。策定の際には、プロダクトオーナーに限らず顧客および開発チームのリーダーが打ち合わせに参加し、どのようなものが必要なのかを打ち合わせるのが一般的です。

ロードマップの作成は、開発チームおよびステークホルダー（顧客）において、実現したい世界観や価値観を共有することにも繋がります。また、ロードマップによって複数のやるべきことを細かく決め、プロダクトバックログへリスト化できるのも利点です。

管理方法・管理ツールの選択

作成したプロダクトバックログを活用するためにも、管理方法（デジタルかアナログ）や管理ツールを選択しておきます。リモートワーク等を実施している場合には、遠方からでも確認できるものが好ましいですし、顧客に共有することもあるものですからデジタルツールを基本として選びます。

デジタル化する必要がない場合には、アナログ管理として何かしらの紙やホワイトボード等にまとめておきます。ただし、更新の際に煩雑になりやすく、また保管場所も明確に決めておかなければならないデメリットには注意が必要です。

おすすめの管理ツール

参考までに、おすすめの管理ツールをまとめました。

【関連記事】プロがBacklog（バックログ）の使い方を活用マニュアルとしてまとめてみた

プロダクトバックログアイテムの作成

プロダクトバックログのロードマップを確認しながら、管理ツールにアイテム（タスク）の作成を実施します。役割ごとにチーム分けが行われている場合には、それぞれで出してもらうとより意見を出しやすくなります。

やることをすべて列挙できれば、リスト化して優先順位を選定するプロセスに移ります。

なお、プロダクトオーナーは顧客から機能追加および修正の依頼が届いた場合に、アイテムへ加える役割も担います。開発チームへのフィードバックと同時に実施し、「何がダメ」で「何が良かったのか」、さらには「繰り返さないために何が必要なのか」まで細かく伝えられるとチーム力を向上できるでしょう。

アイテムの優先順位を選定

プロダクトバックログに作成したアイテムには、優先順位を選定して迷わずチームが仕事を遂行できる状態を作ります。

待ち時間や無駄な作業のロスを減らせますし、基本的には優先順位の高いものから着手することでその重要度に応じた柔軟な対応を実施できるのが利点です。また、優先順位は以下の3つを基準につけておくとさらに精度を高められます。

• 緊急性

• 重要性

• 作業順序

顧客から優先してほしいアイテムの要望があれば作業順序を変更できますし、素早く対応しなければならないものは緊急性が高いので優先順位を上げます。また、重要度の指針があれば、メンバーを多く確保するために「重要度の低いタスクから素早く済ませておく」といった行動もできるでしょう。

なお、優先順位は定期的に見直し、作業の段取りという大枠も含めて細かく検討すると失敗を減らせます。

優先順位をつける方法

優先順位をつける方法は、MoSCoW法と狩野モデルが代表的です。

MoSCoW法は、以下の4つから分類して評価する方法です。

• Must（対応が必須である）

• Should（対応すべきである）

• Could（できれば対応すべきである）

• Won’t（対応は不要である）

一方で狩野モデルは、以下の基準から評価します。

• 当たり前品質（やって当然である）

• 一元的品質（ないと不満である・あれば嬉しいものである）

• 魅力的品質（あったら嬉しいものであってなくても困らないものである）

• 無関心品質（いくら満たしても意味のないものである）

• 逆品質（満たすほど逆効果となるものである）

いずれも汎用性の高いフレームワークなのでぜひ活用してください。

優先順位が高いものを細分化

プロダクトバックログで優先順位が高いと評価したものに関しては細分化し、共通認識およびアイテムの詳細を追加しておきます。常に進化させ続ける必要があることから、機能追加や修正指示が入った場合にも同様に細かく書き込みます。

細分化することで、認識の齟齬を減らして、優先順位がなぜ高く何に必要なのかまでチームに伝わり、目的意識を高めてプロジェクトの成功率も向上できるといった利点が得られます。

なお、プロダクトバックログを作成した際に技術的な検証等が求められる場合は、スパイクと呼ばれるタイムボックスを決めた検証期間を用意します。検証しなければタスクを実施できない場合は、リスク項目として優先順位を高めておく必要もあるでしょう。

受け入れ基準の決定

プロダクトバックログが細かく作りこめたら、受け入れ基準（いわゆる完了および達成基準）を決めておきます。この基準を定めておくことで、プロダクトオーナーがアイテムの完了を判断・確認できる状態を明確化できるためです。

また、受け入れ基準を作っておくと、チームのメンバーがタスクの終了を明示的に確認でき、次に移るまでのロスを減らせます。なお、指摘の際にもどのように基準を満たしていないのかを説明するだけとなるため、より具体的なブラッシュアップに繋がるのも利点です。

リファインメントの実施

プロダクトバックログは、作って活用したらそれで完了ではありませんから、リファインメント（いわゆる更新）を実施します。開発を進めながらブラッシュアップを続けますし、顧客からの要望も細かく盛り込みます。

リファインメントでは、更新に加えて優先順位まで見直しておきましょう。

プロダクトバックログの失敗例

プロダクトバックログの失敗例は、以下が代表的です。

• 優先順位が不明瞭で活用できなかった

• 大雑把で内容を把握できなかった

• 管理ツールの未使用によって確認の連絡が増えて作業も滞った

• リファインメントの未実施によって役立たなかった

• 共有項目が追加されずメンバーにロスが発生した

• 簡潔でまとめられておらずに理解に時間がかかり無駄も増えた

いずれもプロダクトバックログを「作ること」に意識した結果、利活用においての問題点を考慮できなかったというケースが多くあります。

作ることが目的ではなく、作ってからが本来注力すべきプロセスです。プロダクトを進めるための指針となり、更新を何度も繰り返して良いものに仕上げていくためにも、こうした失敗例を考えながらシンプルにわかりやすく、過不足なく作成しましょう。

失敗しないための対策

プロダクトバックログの作成で失敗しないための対策は、以下が挙げられます。

• タスクを実行すればプロダクトが完成する状況にする（それ以外はしなくても良い）

• バックログの検証やリファインメントを定期的に実施する

• コミュニケーションを多く取るよう心がける

• 管理ツールを用いて常に利用を徹底する

• 作るだけではなく更新が重要なプロセスであることを忘れない

ぜひ、試してみてください。

TechUnit（テックユニット）は、月額制で開発支援を行うサービスです。

• ✔ 開発が進まない
• ✔ 要件が決まっていないので柔軟に進めたい
• ✔ 今依頼している開発会社に不満がある

費用が発生しないご相談の段階で、コンサルティングを行い、プロジェクト毎に最適なチームをご提案しております。

プランに応じて柔軟な開発体制を構築いたします。もちろん、開発状況に応じたメンバーの増減も可能です。

無料相談も承っております。まずはお気軽にお問い合わせください！

お問い合わせはこちら

まとめ

プロダクトバックログとは、開発チームが定めている目標を達成するために必要な「アイテム」「タスク」などに、優先順位または緊急性の高いものなどの順位をつけてリスト化したものです。

以下の流れで実施し、成果物を作り上げられるようリファインメントを継続しましょう。

1. プロダクトゴールの決定

2. ロードマップの策定

3. 管理方法・管理ツールの選択

4. プロダクトバックログアイテムの作成

5. アイテムの優先順位を選定

6. 優先順位が高いものを細分化

7. 受け入れ基準の決定

8. リファインメントの実施

なお、開発チームの用意が間に合わない、アジャイル開発で構築したいものがあるといったご相談はぜひお気軽にお問い合わせください。