システムやアプリなどのプロダクトをスクラム開発でつくるとき、必ず登場するのがプロダクトバックログです。
プロダクトバックログはいわば、優先順位をつけたやることリストです。スクラム開発では作業が細分化されて開発メンバーが増えるので、プロダクトバックログがないと無駄な作業が発生したり方向性を見失ったりしてしまうでしょう。
この記事では、プロダクトバックログがどのようなもので、なぜスクラム開発ではこれを作成したほうがよくて、これをどのようにつくっていくのか解説します。
アプリ・システム開発のプロが開発のお悩みを解決します
アプリ・システム開発の6割が失敗すると言われています。クライアントのリピート率100%のリレイスにご相談ください。
＼ まずは無料相談！1営業日以内に返信 ／
目次
プロダクトバックログとは
プロダクトとはシステムやアプリなどの最終製品のことです。
バックログには「積み残し」という意味があります。
開発チームのメンバーが自分たちのタスクを把握するために、作業や機能、改善点、フィーチャーを、優先順位をつけてリストにしたものがプロダクトバックログです。
プロダクトバックログは 1 つの開発に 1 つ、または 1 つの開発チームに 1 つ用意します。
そしてプロダクトバックログは、アジャイル開発の一種であるスクラム開発で多用されます。
スクラム開発でプロダクトバックログが必要になる理由
アジャイル開発は、複数の機能を持つプロダクトを開発するときに使われる手法で、 1 つの機能ごとに要件定義・設計・開発・テストを繰り返していきます。
すべての機能を同時に要件定義・設計・開発・テストしていくウォーターフォール型開発とは異なる方法です。
スクラム開発はアジャイル開発の一種で、開発チームを複数のグループにわけ、それぞれのグループにタスクや役割を分担します。
開発チームがグループにわかれて作業が細分化されるスクラム開発では、開発メンバーは自分の仕事や自分が所属しているグループの役割は把握できますが、全体を俯瞰することが難しくなります。
そこで、プロダクトバックログが必要になります。
開発チームに 1 つのプロダクトバックログがあれば、開発メンバーはそれを確認することで全体を把握でき、自分の立ち位置がわかります。もちろん自分に割り当てられた仕事の内容もわかります。
プロダクトバックログはスクラム開発において道標（みちしるべ）や指針になります。
管理者とアイテム
プロダクトバックログは開発メンバーのみんなで作成します。自分や自分のグループがやらなければならない仕事を出し合うわけです。
そしてプロダクトバックログが完成したら、開発の最高責任者であるプロダクトオーナーがこれを管理します。
開発業務に変更があればプロダクトバックログも変更しなければなりませんが、管理者がいれば全員に変更点を周知することができます。
そしてプロダクトバックログに記載されている 1 つひとつのやること（タスク）は、プロダクトバックログアイテムと呼ばれます。
すべてのプロダクトバックログアイテムを処理できたとき、プロダクト（システムやアプリなど）が完成します。
プロダクトバックログに含まれるもの
プロダクトバックログに書き込むアイテム（やること）は具体的には次のものになります。
- プロダクトゴール
- フィーチャー（ユーザーストーリー）
- 不具合への対応
- 改善点
- 優先順位
プロダクトゴールには、ユーザー（クライアント）がこれから開発するプロダクトで実現したいことを設定します。例えば企業の業務システムを開発するのであれば、それによって業務内容がどれだけ簡素化され、生産性がどれくらい上がるのかなどがプロダクトゴールになります。
フィーチャーは、人によってはユーザーストーリーと呼ぶのですが、これはユーザーが価値を見出す機能のことです。プロダクトゴールに到達するには、複数のフィーチャーをそのプロダクトに搭載しなければなりません。
不具合やバグは開発段階で生まれてくるでしょう。それを解決しないで開発を進めてしまうと、最終的に取り返しのつかない事態に陥ることもあります。そのため、不具合やバグが発生したらプロダクトバックログにその対応方法をアイテムとして書き込んでいきます。
改善点はよりよいプロダクトにするために必要なアイテムです。これも開発段階で発見できたらプロダクトバックログに加えていきます。
プロダクトバックログと単なるやることリストを分けるのは優先順位の有無でしょう。優先順位は、緊急度、重要度、作業手順などを加味して決めます。
優先順位が高いタスクを抱えているグループやメンバーは、そのタスクをこなさないと全体のスケジュールを遅らせてしまうことになります。
スクラム開発では、メンバーが自分の仕事だけをすればよいという気持ちになる可能性があります。
しかし全体の中で自分の業務の役割を意識して、すべてのメンバーがプロダクトゴールを意識しながら仕事を進めるのが理想的です。
プロダクトバックログアイテムに優先順位がつけられていることで、各メンバーに連帯感や責任感が生まれるといったメリットがあります。
プロダクトバックログアイテムの粒度
粒度の元の意味は粉を構成する粒子の大きさのことですが、 IT 領域では 1 つひとつの作業の大きさや細かさのことを指します。
プロダクトバックログを作成するときに、アイテム（やること） 1 つひとつに粒度を明記しておくと、それを担当するメンバーが自分の作業負担の大きさや仕事の難易度を把握することができます。
プロダクトバックログとスプリントバックログの違い
プロダクトバックログと似た言葉にスプリントバックログがあります。
スプリントとは、 1 つの作業工程のことです。
どちらもプロダクト開発におけるバックログ（やることリスト）なのですが、両者には次のような違いがあります。
プロダクトバックログを「大きなやることリスト」、スプリントバックログを「小さなやることリスト」ととらえてもよいでしょう。
または、プロダクトバックログをやることリストにして、スプリントバックログを作業手順書にすることもできます。
プロダクトバックログに作業の詳細を書き込むことができないとき、これとは別にスプリントバックログを作成します。
プロダクトバックログを作るメリット
開発チームがプロダクトバックログをつくるメリットには次のようなものがあります。
- 開発メンバー全員が 1 つのゴールを共有できる
- 優先順位がついているので作業効率が上がる
- やるべきタスクや関連する情報を整理できる
- タスクや情報を開発メンバー全員が共有できる
- メンバー 1 人ひとりが自分の役割や立ち位置を確認できる
- トラブルや仕様変更に柔軟に対応できる
一方、プロダクトバックログをつくるデメリットは手間がかかることくらいです。
そのため、スクラム開発では必ずプロダクトバックログをつくったほうが良いと言えるでしょう。
プロダクトバックログの作成方法
プロダクトバックログは次の要領で作成していきます。
- プロダクトゴールまでのロードマップを策定する
- 管理方法や管理ツールを選ぶ
- アイテムをリストアップする
- アイテムの優先順位を決める
- 開発内容の詳細を詰める
- 達成基準を決める
- リファインメント（更新）する
一つ一 つ見ていきます。
プロダクトゴールまでのロードマップを策定する
ロードマップとはゴールまでの道のりのことで、「これとこれをすれば、このようなプロダクトが完成する」といった内容にします。
ロードマップは、開発チームのリーダーやプロダクトオーナーが、ユーザー（クライアント）と打ち合わせをして作成します。開発チームの主要メンバーの意見もロードマップに反映させることもあります。
ロードマップを作成することで、開発チームとユーザーが、実現したい世界観を共有できるようになります。
ロードマップができれば、ベテランの開発者なら自然とやることがみえてきます。その、複数のやることをリスト化したものがプロダクトバックログになります。
管理方法や管理ツールを選ぶ
プロダクトバックログを絵に描いた餅にしないためには、業務の進捗とプロダクトバックログの内容を常にシンクロさせなければなりません。それには管理が欠かせず、管理方法や管理ツールを選ぶ必要があります。
最近は、システム開発の現場でもリモートワークが進んでいるので、デジタルの管理ツールを使ったほうがよいでしょうか。ここでは 3 つのデジタル管理ツールを紹介します。
Trello
Trello は、プロジェクト管理、ミーティング管理、イベント管理、目標設定ができる業務管理ツールです。
Trello の「カード」という機能は個々のタスクの進捗状況を追跡することができるので、誰がどの仕事をどこまで進めているかを参加者全員が把握できます。
グーグルやコストコなどの大企業も Trello を使っているそうです。
Backlog
Backlog は、プロジェクト管理、課題管理、バグ管理、バージョン管理ができます。
カレンダーと課題を紐づけることができるのでガントチャートをつくったり、マイルストーンを設定したりすることができます。
Brabio!
Brabio! の特徴は 、 簡単にガントチャートをつくることができたり、グループ内で情報を管理できるといったことが挙げられます。また、進捗報告機能があるからスムーズに進捗管理できる上、社外の関係者を部分的に参加させることができることも大きなメリットとなっています。
アイテムをリストアップする
ロードマップができて管理ツールが決まったら、開発チームのメンバーにプロダクトバックログアイテムを挙げてもらいます。
このときすでに開発チームを役割ごとにグループ分けをしていたら、グループごとにプロダクトバックログアイテムを出してもらってもよいでしょう。
グループの長はロードマップを念頭に置いてグループがすべきことを考えます。 1 人ひとりのメンバーは自分に与えられた仕事を完遂させるために必要な作業を挙げます。
やることすべてをプロダクトバックログアイテムにしたら、これをリスト化して優先順位をつけていきます。
そしてプロダクトオーナーは、ユーザー（クライアント）から機能の追加や修正の要望が来たら、アイテムに加えていきます。
機能追加や修正では、単にアイテムに加えるだけでなく開発チーム全体にフィードバックする必要があります。フィードバックの内容は、なぜこの機能を追加することになったのか、追加によってスケジュールは延期されるのか、なぜ修正になったのか、修正を繰り返さないためには何をしなければならないのか、などになります。
プロダクトバックログアイテムの優先順位を決める
プロダクトバックログアイテムに優先順位をつけることで、メンバーは迷わず仕事を進めることができます。そして優先順位が適切につけられると、待ち時間や無駄な作業などのロスが減ります。
基本的にプロダクトバックログは優先順位が高いタスクが上の方に位置しているため、基本的に上にあるタスクから着手していきます。
また、肝心の優先順位は、緊急度・重要度・作業順の 3 点を考慮してつけていきます。ではこの 3 点の優先順位はどのようにつければよいのかというと、ケースバイケースになります。
一般的には緊急度が高いタスクのほうが重要度が高いタスクより優先順位は高くなりますが、しかし例えばユーザー（クライアント）が「この機能を先に確認したい」と強く要望すれば、緊急度が高い仕事を差し置いてでも、その機能を完成させる必要があります。
また、重要度が高い仕事であっても、作業手順を考えると後回しにしたほうがスケジュールを短縮できることがあります。例えば、重要度が高い仕事に多くのメンバーが必要な場合は、先に重要度が低い仕事を片づけてしまえば、手の空いたメンバーを集めて重要度の高い仕事に取りかかることができます。
優先順位づけでは作業の段取りも考えなければなりません。
開発内容 の 詳細 を 詰める
一度完成させたプロダクトバックログを最後まで使い続けることはまれです。ユーザー（クライアント）から機能追加や修正指示がきたらそれをプロダクトバックログに盛り込まなければなりませんし、開発途中でより効率的な手法がみつかったら積極的に変えていきます。
また、プロダクトオーナーとメンバー（エンジニア）の間で認識の齟齬が生じたら、アイテムの詳細を追記していきます。
プロダクトバックログは常に進化させていかなければなりません。
受け入れ基準を決める
プロダクトオーナーは、 1 つひとつのプロダクトバックログアイテムの完了を確認します。したがって、何をもってプロダクトバックログアイテムの完了とするか、という達成基準を定めておく必要があります。
達成基準を決めておくことで、メンバーは「このタスクは終わった。次のタスクに取りかかろう」といったように仕事を進めることができます。
また達成基準が決まっていると、プロダクトオーナーがメンバーに「このタスクはまだ十分にパフォーマンスを発揮できていないから完了したとはいえない」と具体的に指摘することができます。
達成基準を定めることによって手抜き作業を防止できるだけでなく、メンバーを正当に評価することができます。
プロダクトバックログのリファインメントを行う
リファインメントとは更新という意味です。
先ほど、プロダクトバックログは一度つくったら終わりではなく、開発を進めながらブラッシュアップしていく必要があると解説しましたが、それがリファメントです。
優先順位の更新とタスクの更新を紹介します。
優先順位の更新
小規模なシステムの開発であれば、リーダーがメンバーに「その作業はあとにして、今はこれを先にやって欲しい」と指示できますが、大規模システムでそれをやってしまうと現場は混乱します。
タスクやプロダクトバックログアイテムの優先順位が変わったら、プロダクトオーナーはプロダクトバックログを変更することで対応していかなければなりません。
プロダクトバックログアイテムの優先順位は簡単に変えるべきではありませんが、だからといって優先順位の更新を躊躇してはいけません。
タスクの更新
プロダクトバックログに書かれたタスクやプロダクトバックログアイテムは、開発途中で増えたり減ったりします。
ユーザー（クライアント）が新しい機能を搭載したいと要望したら、タスクを追加します。
開発コストが膨らみすぎて予算をオーバーしそうになったら、いくつかの機能を削除することになり、そうなればタスクも減ります。
タスクの更新に柔軟に対応することで、よりメンバーが使いやすいプロダクトバックログになっていきます。
プロダクトバックログの失敗例
プロダクトバックログづくりでは、次のような失敗が報告されています。
- 優先順位が不明瞭だったので、プロダクトバックログが機能しなかった
- プロダクトバックログアイテムの記載内容が大雑把だったため現場で判断することが増え、無駄な作業が多発した
- 管理ツールを使わなかったのでグループ間の連絡やメンバー間の連絡が滞り作業効率が悪かった
- リファインメント（更新）がなされず、途中からプロダクトバックログがあてにならなくなった
- プロダクトオーナーから、プロダクトバックログに記載されていない指示が多数出て、メンバーが混乱した
- プロダクトバックログに記載された内容が詳細すぎて、それを読み込むことを面倒に感じるメンバーが多かった
こうした失敗を繰り返さないためには、次のような対策が有効です。
- プロダクトバックログに書かれたことをすべて実行すればプロダクトが完成していて、プロダクトバックログに書かれていないことはしなくてよい状態になっているようにする
- 開発途中でもプロダクトバックログの検証やリファインメントを積極的に行う
- メンバー間、グループ間、開発チーム全体でコミュニケーションを心がける
- 管理ツールを導入し、メンバーにその利用を徹底させる
まとめ
プロダクトバックログは開発の指針であり、やることリストであり、開発メンバーたちの心のよりどころです。
確固たるプロダクトバックログが存在することで、開発チームのメンバーは安心して作業に打ち込めます。
大規模システムでは開発期間が長期化します。そのためメンバーは今自分たちが何合目に到達しているのかを見失うことがあります。また、自分の仕事が全体のどこに当てはまるのかわからなくなることもあります。こうした不安や混乱は仕事のモチベーションを低下させ、プロダクトの品質低下につながってしまいます。
プロダクトバックログがあれば自分の仕事の意義がみえてきます。「今の仕事を納期までに終わらせないと次の工程の人が困る」といったことがみえてくるとチームに連帯感が生まれるはずです。
プロダクトバックログは開発チームを 1 つにするツールにもなるわけです。
