プロダクトバックログとは、チームおよびプロダクトで定めている目標を達成するために必要なタスクリストのことです。主にアジャイル開発におけるスクラムで利用され、高品質な成果物を作り込む上で重要なものとなります。今回は、そんなプロダクトバックログの概要や目的、実際に作成する流れを解説・紹介します。【開発チームを探すならテックユニット】月額契約で貴社専属の開発チームをご用意し、スプリントレトロスペクティブを含めてプロジェクトを推進します。従来の開発スタイル（一括請負）の課題を解決し、テック部門をすぐに設立できるテックユニットで、新しいプロジェクトから既存システムの改修まで対応できます。テックユニットは、下記のような方におすすめできるサービスです。お気軽にご相談ください。・開発リソースの確保に困っている方・企業の新規事業ご担当者様・保守運用を移管したい方・開発の引き継ぎを依頼したい方＞＞テックユニット（月額制アジャイル開発）の詳細はこちらプロダクトバックログとはプロダクトバックログとは、開発チームが定めている目標を達成するために必要な「アイテム」「タスク」などに、優先順位または緊急性の高いものなどの順位をつけてリスト化したものです。プロダクト（成果物）のバックログ（積み残し・残務・未処理分）という意味で使われ、開発においては以下のものを残します。作業機能改善点 など例えば、アジャイル開発のスクラムの場合に、スプリント計画の段階で作成するといった形で用いられます。プロダクトバックログの役割スクラムにおけるプロダクトバックログは、スプリントの期間中に取り組むべき作業タスク（アイテム）を特定・整理する役割を持ちます。こうした役割を持つことで、完成度の高いプロダクトバックログを完成させられると以下のメリットが得られます。チームとゴールを共有できる何をすべきか明確化できるリストに基づいてプロジェクトを滞りなく進められる結果として、プロダクトバックログによって開発効率や完成度を高めることができ、より成果物は洗練されてニーズにマッチしたものができあがりやすくなることにも繋がります。プロダクトバックログの要素プロダクトバックログには、以下に挙げた4つの要素があります。フィーチャー（ユーザーストーリー）バグ修正技術的負債知識獲得プロダクトバックログにはこれらの項目が含まれており、明確に分割されているものの「割り当てられていない作業内容」として保管されます。フィーチャー（ユーザーストーリー）フィーチャー（ユーザーストーリー）は、顧客から求められている製品における機能を指します。複雑なもの（エピック）や、単純なものまで含まれており、これらに基づいてどのような機能を制作すべきかを判断します。なお、ユーザーストーリーはスクラムにおける要件定義のような形として機能していることも特徴です。【関連記事】ユーザーストーリーとは｜概要や書き方・おすすめテンプレートを解説 バグ修正バグ修正は、リリースした機能やコードなどにおけるバグを直す作業を指します。迅速に対応し、インテグリティ（誠実・真摯・高潔などの意）を維持するためにも重要な項目です場合によってはスプリントを中断してでも実施することもあり、チームが忘れないようにプロダクトバックログの上部で保管されるケースが多くあります。技術的負債技術的負債とは、開発チームが技術的な作業を整理し、蓄積を防ぐために残されるものを指します。プロダクトバックログにおいて蓄積は非常に簡単ですが、溜め込み過ぎればいずれ「返済できない」状態に陥るのは明白です。技術的負債をプロダクトバックログで明示的にし、それらを適切な感覚でチームが整理・対応することで、プロジェクトを滞りなく進められることから重要な項目として用意されます。知識獲得知識獲得は、将来発生するであろうタスクに対し、必要な情報を集める作業を指します。フィーチャーにおいて、情報収集および調査が必要で進められないものである場合には、知識獲得としてタスクを作成します。さらに細かく分類される場合には、プロトタイプ・実験（概念実証）といったカテゴライズを行うこともあるのが特徴です。プロダクトバックログとスプリントバックログとの違いプロダクトバックログとスプリントバックログとの違いは、その対象範囲と焦点です。プロダクトバックログは、プロダクトオーナーがコントロールし、製品全体のビジョンを対象に焦点を当てて作成されます。一方で、スプリントバックログはスプリントの期間中に開発チームで用いられるもので、その間に達成すべき目標に焦点が当てられているのも特徴でしょう。また、プロダクトバックログは完了までの制限時間を明確に決めないものですが、スプリントバックログは期間内という制限があります。さらには、スプリントバックログは製品完成まで変化し続けるプロダクトバックログに内包される形ですから、明確にタスクとして定義された細かい作業が記述されているのも大きな違いでしょう。プロダクトバックログの作成方法プロダクトバックログの作成方法は、以下のとおりです。プロダクトゴールの決定ロードマップの策定管理方法・管理ツールの選択プロダクトバックログアイテムの作成アイテムの優先順位を選定優先順位が高いものを細分化受け入れ基準の決定リファインメントの実施プロダクトゴールの決定まず、プロダクトバックログではロードマップを作成するためにゴールを決定します。このゴールには、顧客がこれから開発するとしたプロダクトで実現したいことを設定します。例として、顧客を管理するシステムを検討しているのであれば、解決したい課題や向上予定の生産性、業務内容の効率化指数などをプロダクトゴールとして定めるといった形です。ロードマップの策定プロダクトゴールを決定したら、ゴールから逆算しながらロードマップを策定します。策定の際には、プロダクトオーナーに限らず顧客および開発チームのリーダーが打ち合わせに参加し、どのようなものが必要なのかを打ち合わせるのが一般的です。ロードマップの作成は、開発チームおよびステークホルダー（顧客）において、実現したい世界観や価値観を共有することにも繋がります。また、ロードマップによって複数のやるべきことを細かく決め、プロダクトバックログへリスト化できるのも利点です。管理方法・管理ツールの選択作成したプロダクトバックログを活用するためにも、管理方法（デジタルかアナログ）や管理ツールを選択しておきます。リモートワーク等を実施している場合には、遠方からでも確認できるものが好ましいですし、顧客に共有することもあるものですからデジタルツールを基本として選びます。デジタル化する必要がない場合には、アナログ管理として何かしらの紙やホワイトボード等にまとめておきます。ただし、更新の際に煩雑になりやすく、また保管場所も明確に決めておかなければならないデメリットには注意が必要です。おすすめの管理ツール参考までに、おすすめの管理ツールをまとめました。ツール名機能特徴Trelloタスク管理ツールカード機能でタスクを管理できるBacklogプロジェクト管理ツールカレンダーと課題を紐づけてガントチャートを作成できるBrabio!ガントチャート作成ツール情報をグループで管理できる【関連記事】プロがBacklog（バックログ）の使い方を活用マニュアルとしてまとめてみたプロダクトバックログアイテムの作成プロダクトバックログのロードマップを確認しながら、管理ツールにアイテム（タスク）の作成を実施します。役割ごとにチーム分けが行われている場合には、それぞれで出してもらうとより意見を出しやすくなります。やることをすべて列挙できれば、リスト化して優先順位を選定するプロセスに移ります。なお、プロダクトオーナーは顧客から機能追加および修正の依頼が届いた場合に、アイテムへ加える役割も担います。開発チームへのフィードバックと同時に実施し、「何がダメ」で「何が良かったのか」、さらには「繰り返さないために何が必要なのか」まで細かく伝えられるとチーム力を向上できるでしょう。アイテムの優先順位を選定プロダクトバックログに作成したアイテムには、優先順位を選定して迷わずチームが仕事を遂行できる状態を作ります。待ち時間や無駄な作業のロスを減らせますし、基本的には優先順位の高いものから着手することでその重要度に応じた柔軟な対応を実施できるのが利点です。また、優先順位は以下の3つを基準につけておくとさらに精度を高められます。緊急性重要性作業順序顧客から優先してほしいアイテムの要望があれば作業順序を変更できますし、素早く対応しなければならないものは緊急性が高いので優先順位を上げます。また、重要度の指針があれば、メンバーを多く確保するために「重要度の低いタスクから素早く済ませておく」といった行動もできるでしょう。なお、優先順位は定期的に見直し、作業の段取りという大枠も含めて細かく検討すると失敗を減らせます。優先順位をつける方法優先順位をつける方法は、MoSCoW法と狩野モデルが代表的です。MoSCoW法は、以下の4つから分類して評価する方法です。Must（対応が必須である）Should（対応すべきである）Could（できれば対応すべきである）Won’t（対応は不要である）一方で狩野モデルは、以下の基準から評価します。当たり前品質（やって当然である）一元的品質（ないと不満である・あれば嬉しいものである）魅力的品質（あったら嬉しいものであってなくても困らないものである）無関心品質（いくら満たしても意味のないものである）逆品質（満たすほど逆効果となるものである）いずれも汎用性の高いフレームワークなのでぜひ活用してください。優先順位が高いものを細分化プロダクトバックログで優先順位が高いと評価したものに関しては細分化し、共通認識およびアイテムの詳細を追加しておきます。常に進化させ続ける必要があることから、機能追加や修正指示が入った場合にも同様に細かく書き込みます。細分化することで、認識の齟齬を減らして、優先順位がなぜ高く何に必要なのかまでチームに伝わり、目的意識を高めてプロジェクトの成功率も向上できるといった利点が得られます。なお、プロダクトバックログを作成した際に技術的な検証等が求められる場合は、スパイクと呼ばれるタイムボックスを決めた検証期間を用意します。検証しなければタスクを実施できない場合は、リスク項目として優先順位を高めておく必要もあるでしょう。受け入れ基準の決定プロダクトバックログが細かく作りこめたら、受け入れ基準（いわゆる完了および達成基準）を決めておきます。この基準を定めておくことで、プロダクトオーナーがアイテムの完了を判断・確認できる状態を明確化できるためです。また、受け入れ基準を作っておくと、チームのメンバーがタスクの終了を明示的に確認でき、次に移るまでのロスを減らせます。なお、指摘の際にもどのように基準を満たしていないのかを説明するだけとなるため、より具体的なブラッシュアップに繋がるのも利点です。リファインメントの実施プロダクトバックログは、作って活用したらそれで完了ではありませんから、リファインメント（いわゆる更新）を実施します。開発を進めながらブラッシュアップを続けますし、顧客からの要望も細かく盛り込みます。リファインメントでは、更新に加えて優先順位まで見直しておきましょう。プロダクトバックログの失敗例プロダクトバックログの失敗例は、以下が代表的です。優先順位が不明瞭で活用できなかった大雑把で内容を把握できなかった管理ツールの未使用によって確認の連絡が増えて作業も滞ったリファインメントの未実施によって役立たなかった共有項目が追加されずメンバーにロスが発生した簡潔でまとめられておらずに理解に時間がかかり無駄も増えたいずれもプロダクトバックログを「作ること」に意識した結果、利活用においての問題点を考慮できなかったというケースが多くあります。作ることが目的ではなく、作ってからが本来注力すべきプロセスです。プロダクトを進めるための指針となり、更新を何度も繰り返して良いものに仕上げていくためにも、こうした失敗例を考えながらシンプルにわかりやすく、過不足なく作成しましょう。失敗しないための対策プロダクトバックログの作成で失敗しないための対策は、以下が挙げられます。タスクを実行すればプロダクトが完成する状況にする（それ以外はしなくても良い）バックログの検証やリファインメントを定期的に実施するコミュニケーションを多く取るよう心がける管理ツールを用いて常に利用を徹底する作るだけではなく更新が重要なプロセスであることを忘れないまとめプロダクトバックログとは、開発チームが定めている目標を達成するために必要な「アイテム」「タスク」などに、優先順位または緊急性の高いものなどの順位をつけてリスト化したものです。以下の流れで実施し、成果物を作り上げられるようリファインメントを継続しましょう。プロダクトゴールの決定ロードマップの策定管理方法・管理ツールの選択プロダクトバックログアイテムの作成アイテムの優先順位を選定優先順位が高いものを細分化受け入れ基準の決定リファインメントの実施なお、開発チームの用意が間に合わない、アジャイル開発で構築したいものがあるといったご相談はぜひお気軽にお問い合わせください。