スクラムチーム（Scrum Team）はプロダクトバックログ（Product Backlog）というリストの上から順に開発を行います。
Scrum.org のスクラムガイドによると、プロダクトバックログについて次のように書かれています。
プロダクトバックログは、創発的かつ順番に並べられた、プロダクトの改善に必要なものの⼀覧である。これは、スクラムチームが⾏う作業の唯⼀の情報源である。
https://www.scrum.org/resources/scrum-guide
この文章に Scrum チームがどのように「作りたいもの」を管理して、開発を行っていくか？ということが、とても明確に表現されています。ただ（スクラムガイド全般にそうですが）、Scrum を理解してから読まないとピンとこないくらい短い文章になっていますよね。それぞれのポイントについて、もう少し詳しく見てみましょう。
目次
- 1 プロダクトバックログは「プロダクトがどうなっていると良いか？」を書いたリスト
- 2 Azure DevOps Boards に Product Backlog Item を登録する（簡潔なタイトル・本文で）
- 3 プロダクトバックログアイテムの担当者を決めない（プロダクトバックログはタスクではない）
- 4 最優先は本当に「最優先」である（プロダクトバックログを優先順に並べる）
- 5 プロダクトオーナーが Azure DevOps の Backlogs で順番を変える（開発者は順番を変えない）
- 6 創発的＝少しずつ追加する（しかし、スプリントの途中では変えない）
- 7 開発者が作業する 唯一のリスト＝他のリスト（課題管理表やバグ管理表）はない
プロダクトバックログは「プロダクトがどうなっていると良いか？」を書いたリスト
スクラムガイドにある「プロダクトの改善に必要なもの」とはつまり、プロダクトゴールを実現したい将来のプロダクトの状態として、今の状態からその状態になるには、じゃぁ、具体的にどうなっていると良いのか？ということを書いているリストだということを表しています。
もしこれから始めてプロダクトを作成するということであれば、欲しい機能やそれを使っているユーザーの様子（ユーザーストーリー）などを具体的に書いて一覧にします。もしすでにプロダクトが作成されているなら、いくつかの不具合を修正しなければならないかもしれません。そういったバグや改善したい動作（仕様）もプロダクトバックログに追加します。
それらのリストの項目がひとつずつ完成していくと、プロダクトがプロダクトゴールに近づいていく、ということをイメージして記載します。もし、プロダクトゴールに関係ないことや、「やった方がいい」程度のことであればリストに追加しないほうが良いでしょう。必ず、プロダクトゴールを達成するために「絶対にやるべきこと」を記載します。とはいえ、思いついたアイディアが「絶対にやるべきこと」なのか「やった方がいいこと」なのか、なかなか判断がつかない場面が多くあると思います。その場合にはプロダクトオーナー（PO）が判断します。プロダクトバックログのリストは、PO が項目を追加し、PO が責任を持って管理しますが、誰でも項目を追加した方が良いという提案をできます。PO とよく話し合って、最終的に本当に必要なことであればリストに追加して良いでしょうし、必要がなさそうであれば優先度を低くしたりリストに追加しなかったり、追加したものを後で削除したりすれば良いでしょう。
Azure DevOps Boards に Product Backlog Item を登録する（簡潔なタイトル・本文で）
こういったコミュニケーションとプロダクトバックログのリストによって、プロダクトオーナー（PO） はスクラムチームの開発者に、これから作るものとプロダクトゴールの具体的なイメージを伝えます。開発者はプロダクトバックログのそれぞれの項目をどのように実現するか？考えて、詳細を決めたうえで、プログラムを実装して実現していきます。
Azure DevOps などのシステムを使うと、PO が入力したプロダクトバックログと、開発者が作成したソースコードやそれを運用環境にリリースするためのパイプラインなどが全てて関連付けられて保存され、変更履歴も全て残っていて問題が起きてた時にはいつでもさかのぼって確認できるようになります。PO はファイルや口頭で伝えるだけでなく、必ずこういったシステムを使用して、プロダクトバックログを記録するようにします。
Azure DevOps では Boards にプロダクトバックログの項目（PBI : Product Backlog Item）を登録します。Boards の最初の画面ではなく、Backlogs の画面を使用すると良いでしょう。
リスト表示されるときに、例えば「他の項目と似ていて区別がつかない」というようなことがないように、簡潔でわかりやすいタイトルを記載します。また説明を Description に記載できます。最初にタイトルだけ入力して登録しておき、後からアイテムの詳細画面を開いて Description に詳細を入力していくのも良いでしょう。詳細画面では、簡単な書式が Azure DevOps の画面上で扱えるほか、図を貼ったり、他の OneNote や Word ・Excel で記載した表をコピーして貼り付けることが出来ます。必要に応じて、参考資料を引用する URL を記載したり、参考資料のファイルを添付したりできます。PO はこれらを使ってプロダクトバックログの具体的なポイントがわかるように記載します。
また、開発者はわからない点や曖昧な点があるときは、Discussion で PO や他の開発者と相談すると良いでしょう。チャットやメールや電話では、プロダクトバックログアイテムに記録が残るわけではないので、他で会話した内容を転記するときに間違えるかもしれませんし、そのことに気付くのがなかなか難しいです。Discussion で会話しておけばその会話の対象であるプロダクトバックログアイテムそのものに記録が残るので、後で見直すのも容易で、誤解や間違いがあっても気づきやすいです。もし対面で会話が出来ているときには、Discussion に記録を取りながら話すと良いと思います。
プロダクトバックログアイテムの担当者を決めない（プロダクトバックログはタスクではない）
プロダクトバックログはタスクではありません。プロダクトがどうなっているべきか？ということを記載します。Azure DevOps の機能的に担当者を設定できますが、Scrum では設定する必要がない（すべきでない）のでフィールド自体が表示されないようにしてしまうのが良いように思います。
タスクはプロダクトバックログアイテムの子供として登録されます。開発者が、プロダクトバックログをどのように実現するか？ということを計画し、実際に実行するのがタスクです。
タスクは開発者が自分で着手するときに、自分の名前を入れます。それまで（To DO にあるとき）は、スクラムチーム全員のタスクであり、だれかひとりのタスクではありません。
プロダクトオーナー（PO）や開発者がこのプロダクトバックログとタスクの関係を理解していると、プロダクトバックログの内容を考えたり実際に入力するときに迷わずに済むと思います。開発者が行う作業ではなく、プロダクトがどういう使い方でどのように動作していればうれしいのか？ということに注目すると、プロダクトバックログを適切に表現できると思います。逆に「画面を作る」などのタスク＝作業ばかりが思い浮かんでしまう場合には、プロダクトゴールが明確にイメージできていないのかもしれません。
最優先は本当に「最優先」である（プロダクトバックログを優先順に並べる）
スクラムガイドに「順番に並べられた」と表現されていますが、この順番は、リストの項目の優先度のことを言っています。つまり、プロダクトバックログのリストの 1番の項目は、２番の項目よりも先に着手して完成させるということです。
従来のウォーターフォールのプロジェクトでは、大人数で複数の機能を同時並行で開発することが多くありました。また、日本人の多くはこの優先度を決めるのが苦手らしく、「全てが最優先」という発言をよく聞くことがあります。しかし、それは Scrum では認められません。必ず優先順位を決めて、１番のものを最初に実現します。２番のものは必ず、１番のものが完成してリリース可能になったあとに着手します。それまで同時並行で着手したりしません。
複数の機能を同時並行で開発することがコストや手間がかかるのは、開発者の多くが経験しているはずです。ブランチ戦略やマージを工夫するなど、同時並行の開発を実現するために様々な手法やツールを活用するのが重要とされてきました。その感覚からすると、この最優先のものから完成させていくというのは奇妙に見えます。しかし、同時並行での開発をやめる代わりに得られるものが沢山あります。スクラムでは（同時並行開発で得られるメリットよりも）それを重視しています。折角、「全部計画通りに開発が終わってからリリースを１回だけする」という方式ではなく、「小さく作ってリリースするのを何度も繰り返す」という方式を採用しているので、その利点を最大限に活かすためにも、プロダクトバックログの項目は、本当にリリースをしたい優先順に並べておく必要があります。
プロダクトバックログの順番＝優先度は、プロダクトオーナー（PO）が判断して決めます。これは、プロダクトの新しい変更点をリリースすることで得られるビジネス的価値をもとに決定します。
開発者が「こちらを先に作った方が作りやすそう」と思っても、その順番にはしません。これは非常に重要なことです。作りやすい順に作っていたのではプロダクトの価値が最大にならないかもしれません。技術的に作りやすい順番があることは十分に理解できます。そうであっても、できることからやるのではなく、ユーザーが欲しいタイミングで欲しいものを届けることに価値があるはずです。PO は開発者が作りたい順で作りたくなるのを理解したうえで、それでもビジネス的価値として、優先する順番があることを明確に説明して、開発者に納得してもらわなければなりません。次の（最初の）リリースで、ユーザーにがっかりされたくはないのだということを、開発者にも実感としてもってもらわなければなりません。そのうえでどのように優先順に実現するか？を PO と開発者は一緒に考えます。開発者は作りやすい順に作ることを主張する代わりに、このスクラムチームが１スプリトで作れる範囲を PO に明確に伝えて、大きすぎるプロダクトバックログの項目は分割をして、そのうえで並び替えを行ってもらうようにします。ビジネス的価値がいくら高くても最初のスプリントですべてのプロダクトバックログの項目を完成させることはできないのです。順番をきめるということは、最初のスプリントに間に合わないものがなんであるかを決めるということでもあります。PO はその決定に責任をもちます。
また、ステークホルダーの中には従来のウォーターフォールの開発が当たり前だと思っている人が沢山いるかもしれません。そういった人たちは、「全てが最優先だ」「同時に開発しろ」ということを要求してくるかもしれません。それらもすべて話を聞いたうえで、そうはしないのだということ。PO が考える最優先のものから順にリリースをしてその範囲で価値を最大化するのだということを説明し、理解してもらう必要があります。発言の力の大きなステークホルダーが理解しなければ、スクラムはうまく行かないでしょう。PO はスクラムマスタや他のスクラムに詳しい人と一緒に、スクラムがどのように進むのか？などをステークホルダーに丁寧に説明しなければならないかもしれません。なんとしても、最初のスプリントが開始されるまでに、ステークホルダーの理解が得られるようにします。
プロダクトオーナーが Azure DevOps の Backlogs で順番を変える（開発者は順番を変えない）
Azure DevOps の画面では Baclogs でバックログの項目の順番を変えることが出来ます。
マウスで操作するときに、タイトルの文字があるところをクリックしてしまうと、項目の詳細画面を開いてしまってうまく行きません。順番を変えるときには、文字のないところでマウスのボタンを押して、そのままドラッグして移動します。
あくまでプロダクトバックログの順番を決めるのはプロダクトオーナー（PO）です。PO 自身が操作するか、PO から頼まれた人が操作して行うべきです。開発者が自分で勝手に順番を変えないように、「順番に重要に意味があるのだ」ということを全てのスクラムチームの開発者に知っておいてもらう必要があります。
創発的＝少しずつ追加する（しかし、スプリントの途中では変えない）
スクラムガイドになる「創発的」というのは、少しずつ追加するという意味です。
例えば、従来のウォーターフォールの開発では、最初に計画を立てた（契約した）期間で作るものを全てリストアップします。WBS: work breakdown structure として全てのタスクを、漏れなく重複なく洗い出せるか？ということが重要になります。しかしこれは非常に難しいし時間がかかる作業です。スクラムではそうはしないということです。
プロダクトバックログはリストの１番上の最優先のものから実現してリリースしていくということなので、極端なことを言えば２番目より下の項目は、１番目の項目が完成するまでに決まっていれば良いはずです。ただそれだとスプリントの開始時点で、どこまでこのスプリントでは完成されられるのか？が予測・計画できません。また、プロダクトバックログのリストに入れたらすぐ開発に着手できるわけではなく、それが具体的にどういうことか？ということを開発者がプロダクトオーナー（PO）と話して確認したり、技術的にどのように実現するか？を検討して詳細化するためのリファインメントの時間が必要です。そのため、より現実的な話で考えると、プロダクトバックログは次のスプリントで完成されられそうな分と、その次のスプリントまでにリファインメントしておきたい分が、リストに項目が登録されていればよい。それ以外は後で追加していけばよい、ということになります。
これによって開発スタート時点ではまだわからなかったことに対応する、より良い新しいプロダクトバックログを追加して開発をすることが出来ます。
しかし、「少しずつ追加する」と言っても追加できるのは、すでにスタートしている今のスプリントで扱っているプロダクトバックログの項目よりも後に開発をする、次のスプリント以降の分だけです。今のスプリントの途中で、「このバックログもやってね」と差し込んだり、バックログの内容を変更したりすることはできません。新しいプロダクトバックログの項目を、着手中のバックログの下に挿入します。
まだ今のスプリントでやることに決まっていないプロダクトバックログの項目であれば、変更したり優先順を変更したりしてもかまいません。新しく追加したときには、次のスプリントの開始までに、それがどのような内容であるのか？を PO と開発者が十分に話し合って、プロダクトバックログの詳細をリファインメントする時間を、スプリントの間に取っておく必要があります。そのため、やたらめったら「次のスプリントでやりたい」と言って追加するのも現実的ではないと思います。現実的には、ある程度先のスプリントで実現することを想定して、リストに追加・変更していくことになります。
開発者が作業する 唯一のリスト＝他のリスト（課題管理表やバグ管理表）はない
スクラムガイドにある「スクラムチームが⾏う作業の唯⼀の情報源」という表現は、かなり重要なポイントですが、なかなか出来ないところだと思います。これは、プロダクトバックログのリスト以外に、例えば「課題管理表」や「バグ管理表」というような別のリストを作ってはいけない、と言っているのです。そうではなく、開発者が作業をこなう必要があるのであれば、それは全てプロダクトバックログのリストに項目を追加して、実際に作業するかどうか？は、プロダクトオーナー（PO）が優先順を決めてそれに従って実施します。
従来のウォーターフォールの開発では、開発する全ての工程を WBS: work breakdown structure として管理しているはずです。しかし、よく、うまく行っていないところを改善するためのテコ入れとして、課題管理表が別に作られて、それらを対応するように指示がされたりします。これは大抵うまくいきません。なぜなら、WBS に必要な作業がすべて乗っていて、その分の人員と期間が既に割り当てられているはずなのです。それをやらずに、別の課題管理表の作業に手を動かしていたら、WBS の予定通りに進める方の人員・時間が足りなくなるはずです。WBSを修正するのではなく、別の課題管理表を作るという方法では、ウォーターフォールの開発であっても大抵、かえって状況が悪化してしまいます。スプリントの期間が短いスクラムでは、より一層うまく行きません。スクラムでは、プロダクトバックログをどのように実現するか？を計画して実施するので、プロダクトバックログの項目として、開発者が手を動かして解決すべき内容は記載する必要があります。
これはバグについても同様です。ただ、バグについては考え方を少し整理しておく必要があります。
前提として、開発しているプロダクトバックログの内容に合わない動作など不具合が見られた場合は、それはバグではなく、単に「プロダクトバックログが完成していない」だけです。これを「不具合はバグとして記載して、別で管理するので、バックログは完了させますね」というようなことを言って、終わらせてしまってはいけなせん。バックログは不具合（従来のバグ）がすべてなくなるまで完了させられません。
それとは別に、今着手しているバックログとは別で、ユーザーからに指摘などで問題が発見された場合などは、これらをバグとして扱います。このバグは、プロダクトバックログと同様に扱います。
Azure DevOps では、バグをプロダクトバックログと同様に扱う設定（Bugs are managed with requirements）を有効にしておきます。
Backlogs の画面でプロダクトバックログとバグが同じ階層として表示されます。アイコンが違ったり、バグでは再現手順が入力できるなど、扱う項目が少し違ったりしますが、それ以外の部分ではバグとプロダクトバックログを同じように扱います。
コメント
