コラム

  • 2021.09.15
  • アジャイル開発
  • #基礎知識
  • #開発手法

プロダクトバックログのつくり方やメンテナンス方法を解説

今日、ソフトウェア開発手法の主流ともいえる「アジャイル開発」のなかで、多くの企業が採用するフレームワークが「スクラム」です。当社にも、「スクラムで開発してみたい」、「スクラム開発を導入してみたが結果が出ない」、「スクラム開発に切り替えてからソフトウェアの品質が悪くなってしまった」というようなお問い合わせをいただく機会が増えてきています。
さて、多くの方が注目するスクラムのなかでも、一番結果に差がつきやすく、開発全体に影響を与えるのが、プロダクトバックログといえます。プロダクトバックログはスクラム開発のプロセスにおける、はじまりと終わりに関わるもっとも重要な部分であり、プロジェクトの成功を支える生命線のようなものでもあるからです。
そこで、本コラムでは、プロダクトバックログについて、SHIFTでの現場視点を踏まえつつ、まとめてみることにします。

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

プロダクトバックログとは、機能や改善が必要なものについて優先順位をつけ、記述したものです。優先順位をつけることで、今回のスプリントで対応する機能、次回のスプリントで対応する必要がある機能といったことを明確にできます。また、プロダクトバックログは、ステークホルダーがプロダクトの状況を把握することにも用いられます。

スクラム開発の概念とプロダクトバックログ

上記のような概要だけではプロダクトバックログのイメージがつきにくいという方も多いでしょう。内容については以降で詳しく説明をしていきますが、その前に、プロダクトバックログに深く関係するスクラム開発の概念について、まずはみなさまと確認しておきたいと思います。

スクラム開発では、その名称から想像ができるラグビーのスクラムのように「チームメンバー同士でがっちりと肩を組み」、ゴールに向かい、メンバーが一丸となって動くことを非常に重要視しています。その具体的な内容は、スクラムを行ううえでよく参照される「スクラムガイドブック」のなかに、「スクラムの理論における3本の柱」(「透明性」、「検査」、「適応」)や「スクラムの価値基準」(「確約」、「集中」、「公開」、「尊敬」、「勇気」)として記されています。(出典:「スクラムガイドブック」内「スクラムガイド-スクラムの理論」、「スクラムの価値基準」)

このように、スクラムとはそもそもどのような概念であり、何を大切にしているのかといったことを理解しておくことで、これから説明するプロダクトバックログについてより深く理解することができるでしょう。

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

さて、本題に入ります。スクラム開発におけるプロダクトバックログの役割は何でしょうか?
こたえは、プロダクトバックログを見れば、「誰でも今後のプロダクトがどのように変わるかがわかるようになる」ことです。つまり、プロダクトバックログは、スクラムチームの情報源であり、ロードマップのようなモノとして役割を果たすものといえます。

プロダクトバックログ概要

では、そのような役割を担うプロダクトバックログはどのような姿をしているのでしょうか?
まず「バックログ」とは、わかりやすくいえば「積み残しのリスト」のことです。つまり、「プロダクトバックログ」は、「プロダクトの積み残しリスト」と理解することができます。そして「リスト」というだけあって、このリストのなかには「アイテム」が「並んで」いるはずです。
スクラム開発では、この「アイテム」のことを「プロダクトバックログアイテム」(以下、PBIと略します)とよびます。PBIはスクラムチームメンバーであれば全員作成することが可能で、そこには、プロダクトの改善事項が適切な粒度で記載されています。また、そのPBIはただ並んでいるのではなく、実現の優先度順に並べられています。

以上をまとめると、プロダクトバックログとは、プロダクトの改善に必要なアイテムが優先度順に並んでいる積み残しリストのことだといえます。

アジャイル開発の実態調査

プロダクトバックログのつくり方

次に、実際のプロダクトバックログのつくり方について、まず、前提としておさえておきたいプロダクトオーナーについて簡単に説明し、そのあとで、具体的なつくり方として4つのSTEPをご紹介します。

前提 : プロダクトオーナーについての理解

プロダクトバックログを作る前提として、まずスクラムチームにおけるプロダクトオーナーについて理解しておく必要があります。

プロダクトオーナーの人数

原則として1つのスクラムチームにはプロダクトオーナーは1名のみです。しばしば複数のプロダクトオーナーがチームにいる場合がありますが、残念ながらそれではスクラムチームとしては成立していないといえます。なぜならば、1つのプロダクトを素早く、ぶれずに完成させるためには、最終的な意思決定者を1人にしておく方がよいからです。したがって、スクラム開発を行う際には、必ず、明確にプロダクトに対して責任をもつ人を決め、会社組織としてもプロダクトオーナーが1人でプロダクトに向き合える環境を用意することが非常に大切だといえます。

プロダクトオーナーの役割

プロダクトオーナーの役割としては、おおむね次の4つがあげられます。

・プロダクトゴールを示す
・誰もが理解することができるPBIを作成する
・PBIの優先順位を決定する
・プロダクトバックログをメンテナンスする

このような役割を果たすプロダクトオーナーは、スクラムにおいて重要な人物といえます。決してほかの役割や業務と兼務してこなせる役割ではないということを、プロダクトオーナー自身も周囲の関係者も理解しておくことが何よりも重要です。

さて、プロダクトオーナーについてはおおむねご理解いただけたかと思いますので、次にプロダクトバックログのつくり方のSTEPについて説明していきます。

STEP1 : プロダクトゴールの策定

プロダクトバックログを作成するにあたり、まずは、プロダクトバックログの基になるプロダクトゴールを策定することが必要です。プロダクトのゴールとは、プロダクトをとおして世界で実現したい「ビジョン」や「ミッション」のことです。これらについては、プロダクトにかかわるステークホルダーやプロダクトオーナーがなんとなく頭のなかで考えているというケースもないとはいえませんので、そういった場合は実現したいことを分解し、明確に表現する必要があります。
ゴールの明確化のために、今日では次のようなフレームワークがありますので、それらを用いることもオススメです。

<フレームワークの例>
リーンキャンバス
9つの要素から事業に関わる要素を整理するためのフレームワーク。1枚の紙で表現し、全体を俯瞰しながら見ることができることが最大のメリット。
PRD(Product Requirements Document)
プロダクト要求仕様書。プロダクトに関わるさまざまな事柄を定義しておき、意思決定の際や方向性の再確認を行う際に利用するドキュメント。
インセプションデッキ
用意されている10の質問に答えることで、プロダクトのドキュメントを作成することが出来るフレームワーク。
OnePager
まるでパンフレットのような形で、製品・サービス・ビジネスの概要をあらわすことができる1ページのドキュメント。
ゴールデンサークル
物事を「Why」「How」「What」という構成要素に分解し、本質を説明するためのフレームワーク。

もちろん、チームの構成やプロダクトの解像度などに応じてプロジェクトが置かれている状況は異なると思いますので、まずはいずれかのフレームを利用してみて、明確化ができるかどうかを試してみるとよいでしょう。もし、試したフレームの使いづらさを感じたら、すぐに別のフレームワークに切り替えたり、フレームワークから要素のみ抽出し独自の手法に昇華させたりなど、変化を恐れずにプロジェクトを前に進めていくことが大切です。

STEP2 : PBIの作成

STEP1でプロダクトのゴールを策定したら、次にそれを実現するためのPBIを作成し、プロダクトバックログに追加していきます。追加作業は、プロダクトオーナーだけではなく、スクラムチームに参加しているすべての人が行います。
このSTEPは、まずPBIを追加することを念頭におきます。優先順位づけは次のSTEPにおいて行いますので、優劣をつけるような詳細はここでは書かず、PBIの意味を明確にしていきます。そのためには、例えば、XP(Extreme Programming)の概念から派生して利用されている、次のようなユーザーストーリーのテンプレートを用いて作成されていることが多いようです。

ユーザーストーリーのテンプレート
[Who(ユーザー・顧客)] として、[What(達成したいゴール)] をしたい。なぜなら[Why(理由) ] だから。

ここで気をつけるべきポイントは、How(方法)を書かないことです。というのも、Howについては、ユーザーストーリーを実現するためのタスクを開発者がスクラムチームに対して検討・整理する際に議論すべきことだからです。また、そのほかにも、誰でも理解できる言葉を用いて記載する(=専門用語を利用しない)ことを意識することもここでは重要なポイントだといえます。

STEP3 : PBIに優先順位をつける

STEP3では、STEP2で作成したPBIに対して優先順位をつけていきます。
優先順位がつけられないという場合は、作成したPBIのサイズが大きすぎることが理由として考えられますので、PBIを分割します。もし分割しても優先順位をつけることがむずかしい場合は、STEP4に記載している詳細化を先に進めるのも有効です。

優先順位をつけるにあたり、その基準を整理する考え方や手法はさまざまですが、下記にその例をご紹介しておきます。

<PBIの優先順位づけを行う考え方や手法の例>
狩野モデル
顧客満足度に影響を与える品質要素を分類して、それぞれの特徴を記述したモデル。
MoSCoW法
要件をMust、Should、Could、Won’tに分類する。特にMustを決めることが非常に重要。
アイゼンハワー・マトリクス
縦軸を重要度・横軸を緊急性とし、それぞれ高と低に分け、全部で4つに分類する方法。重要度高×緊急性高に振り分けられたものが一番重要。
CD3(Cost of Delay Divided by Duration)
その名の通り、遅延のコストを期間で割ったものをスコアとして用いるもの。経済性で優先度を決める手法。

もちろん、これらの方法を無理に使う必要はありません。状況によってビジネスの価値の最大化を最優先にするためにトップダウンに従い優先度を決めることもありえます。

しかし、どのように順位づけをするにせよ、一番やってはいけないことは、「優先順位を決めた基準をプロダクトオーナーが説明できない」状態になることです。仮にプロダクトオーナーがなんとなく優先順位を決めた場合でも、そこには必ず基準はあります。それが明示化できていないと、優先順位を再び見直す際のコストの増大や、スクラムチームでの意思統一を図ることが非常に困難になり、プロジェクトにズレが発生しやすい状況になります。したがって、優先順位の基準を明確にしてプロダクトバックログを理解し、スクラムチームが利用できる状態を実現することが、このSTEPでもっとも欠かせないことだといえます。

STEP4 : 優先順位高のPBIの詳細化

最後にSTEP3でつけられた優先順位が高いPBIに対して詳細化を行い、スプリントバックログに渡せるような状態(=開発者が開発することができる状態)にします。

詳細化については次の3つを実行する必要があります。
・ストーリーをINVESTで満たすようにする
・プロダクトオーナーによる受け入れ基準を作成する
・完了条件を定義し、スクラムチーム全員が意味を理解する

ここでは、それぞれについて少しだけ説明しておきます。

ストーリーをINVESTで満たすようにする

STEP2で作成したストーリーをBill Wake氏によって作成されたINVESTを満たすように修正・確認をします。

<INVEST>
Independent 独立している
ほかのプロダクトバックログアイテムと依存関係がなく、どのような順序でも実行できるように独立している必要がある。
Negotiable 交渉可能
詳細は会話して決めていくため、Howが書かれていないこと。
Valuable 価値がある
タスク内容が書かれているのではなく、価値について書かれている必要がある。
Estimable 見積可能
見積が可能な状態になっている必要がある。
Small 小さい
Estimableとも関連。大きすぎると見積もりが困難かつストーリーを把握することがむずかしいため、適切な大きさである必要がある。
Testable テスト可能
ストーリーを達成しているか否かを確認するテストが実施できる。

出典:INVEST in Good Stories, and SMART Tasks

プロダクトオーナーによる受け入れ基準を作成する

受け入れ基準とは、プロダクトオーナーが個々のPBIに対して設けている、何をもってPBIが完成したかを確認するための基準です。1つのPBIに対して複数の基準があり、個々が「前提条件を満たしたうえでのアクションに対する結果」を具体的にあらわした形になっているため、これを受入テストの基準として開発者が利用することが可能です。つまり、確実に受入OKかNGが判断できる形、かつ誰でも確実にわかる形で表現されています。

完了条件を定義し、スクラムチーム全員が意味を理解する

完了条件とは、すべてのPBIに対して共通で設けられており、PBIを完了状態にするための条件のことです。また、完了状態とはいつでもリリースしてもよい状態であることを意味しています。

代表的な完了条件の定義としては、
・受け入れ条件を満たしている
・コードレビューが実施されている
・結合テストを完了している
・自動テストのカバレッジが〇〇%を超えている
などの非機能的要件があげられます。

完了条件はすべてのPBIに対して共通で設けられていることから、スクラムチーム全員が完了条件を理解、認識している必要があり、全員で議論してチューニングする必要があります。

アジャイル開発の実態調査

プロダクトバックログのメンテナンス

プロダクトバックログのメンテナンスのイメージ

これまでご紹介した4つのSTEPを経て、プロダクトバックログは完成します。しかしながら、プロダクトバックログは一度完成して終わりではありません。プロダクトが関わるさまざまな環境変化の流れは早く、しかもビジネスの不確実性が高いのが今日です。そのため状況に合わせてプロダクトバックログを常にメンテナンスしなければ、意味のないプロダクトバックログになってしまいます。

さて、メンテナンスの重要性についてはご理解いただけたかと思いますので、つづけてメンテナンス方法について簡単に説明していきます。

メンテナンスについては、大きく次の2つの部分に着目して行うと非常に効果的です。
1. 優先順位のメンテナンス
2. PBIのメンテナンス

1. 優先順位のメンテナンス

まず意外におろそかになりがちなのが、優先順位の見直しです。これはプロダクトオーナーが責任をもって実施する必要があり、基本的には常に行う必要があります。しかし、プロダクトオーナーは往々にして時間に追われていることが多いのが実情です。効率的に優先順位のメンテナンスを行うための実践的なオススメの方法としては、明示化されている優先順位の基準のメンテナンスを実施し、その変更の影響範囲内で優先順位を修正することです。こうすることである程度、効率的に優先順位をメンテナンスすることができます。

2. PBIのメンテナンス

PBIのメンテナンスは非常にわかりやすく、シンプルに、PBI自体の追加・更新・削除を行うことで実現できます。具体的にはそれぞれ次のように行います。

追加

PBIを追加するタイミングは常にあります。プロダクトに対してユーザーが新しい価値を求めた時、会社が新しいビジネス価値を求めた時、開発チームが新しい価値を求めた時です。PBIを追加した際にはどこかの場でスクラムチーム全体に共有することが大切です。

更新

PBIの更新は優先順位の高い順番で行います。プロダクトバックログは優先順位が高ければ内容が詳細にされ、逆に優先順位が低ければ内容があいまいになるという特徴があるため、優先順位が高い方の更新は考えるべきことが多く、非常に大変です。また更新時は、更新する背景・更新する内容をスクラムチーム全体に伝えたうえで、優先順位をプロダクトオーナーに判断してもらう必要があります。

削除

削除は一見簡単に見えますが、一番勇気のいる行為であり重要な行動です。プロダクトバックログは往々にしてアイテム数が膨大になりがちです。膨大であることはスクラムの概念的にはあまり問題ありませんが、実践的にはアイテム数が膨大になるにつれて、必要コストも増え、対応可能な時間も少なくなっていきます。したがって、ユーザーやビジネスの状況の変化や開発チーム体制の変更が行われた際は、ぜひ合わせてPBIの削除も検討してください。

アジャイル開発の実態調査

まとめ

いかがでしたでしょうか?プロダクトバックログがスクラム開発において、とても大事な要素でプロジェクトの成功に大きく影響を与えることがご理解いただけたかと思います。

最後になりますが、プロダクトバックログの運用を成功に導くために一番大事なことをお伝えしておきたいと思います。大切なこととは、スクラムチーム全体が同じゴールを目指して、自分たちで作業を管理・推進していくといった責任に対してどれくらい向き合えているかということです。いかに優れたプロダクトバックログをつくっても、プロジェクトオーナーがその役割をまっとうしても、チーム全体が同じ方向を向かなければプロジェクトはうまく進まない可能性があります。チーム全体がプロジェクトに向き合うためには、プロダクトバックログを用いたコミュニケーションの促進ということも、あるいは重要になってくるのかもしれません。いずれにしても、いまいちどスクラムの概念を思い出し、何が大切なのかを心に留めておいていただければと思います。

スクラム開発はプロダクト成長をドライブさせる後押しになりますので、このコラムを参考に、是非みなさまも取り組んでみてください。

資料ダウンロード/動画視聴

アジャイル開発の実態調査

ソフトウェアテスト入門動画

SHIFTサービス資料

テストサービス導入事例集

関連サービス