バックログの意味とソフトウェア開発での定義
ソフトウェア開発でいうバックログは、プロダクトをよくするためにこれから行う作業を、価値の高い順に並べた一覧です。スクラムの考案者が公開している公式ガイド「スクラムガイド」の2020年版は、プロダクトバックログを「創発的かつ順番に並べられた、プロダクトの改善に必要なものの一覧」と定め、スクラムチームが行う作業の唯一の情報源と位置づけています(スクラムガイド 2020年11月・日本語訳)。
「創発的」とは、開発を進めて分かったことに合わせて中身が増えたり入れ替わったりするという意味で、最初にすべてを決めきる前提には立っていません。多くのチームでは、一覧の上にあるものほど詳しく書き込んですぐ着手できる状態にしておき、下にあるものは粗いメモのまま残しておきます。
同じ「バックログ」の名を持つツールや会計用語との違い
「バックログ」という語は、開発の作業一覧のほかに、株式会社ヌーラボのプロジェクト管理ツール「Backlog」や、受注したまま納品していない注文を指す受注残の意味でも使われます。検索するとツールの機能や料金の記事が多く並びますが、ここで扱うのは、アジャイル開発で使う作業の一覧としてのバックログです。ツールのBacklogも、作業の一覧を管理する道具の一つとして後の節で触れます。
プロダクトバックログとスプリントバックログの違い
プロダクトバックログはプロダクト全体でこれから取り組むことの一覧で、スプリントバックログは1回のスプリントで何をどう進めるかをまとめた計画です。責任を持つ人も分かれており、プロダクトバックログの管理はプロダクトオーナーが、スプリントバックログは開発者が受け持ちます。
項目 | プロダクトバックログ | スプリントバックログ |
|---|
中身 | プロダクトの改善に必要なものの一覧(機能・改善・不具合の修正など) | スプリントゴール(なぜ)、選んだプロダクトバックログアイテム(何を)、届けるための実行可能な計画(どのように) |
責任を持つ人 | プロダクトオーナー | 開発者(開発者による、開発者のための計画) |
確約(目指すもの) | プロダクトゴール | スプリントゴール |
見直すタイミング | リファインメントで継続的に | スプリントの期間を通して随時 |
対象の期間 | プロダクトが続く限り | 1回のスプリント(1か月以内) |
出所: Ken Schwaber・Jeff Sutherland「スクラムガイド」(2020年11月・日本語訳)をもとに編集部が整理。
スプリントバックログは、開発を進めて学んだことに合わせてスプリントの期間を通して更新され、デイリースクラムで進捗を確かめられる程度の細かさが求められます。スプリントの長さを「1〜4週間」と書く解説もありますが、ガイドが定めているのは「1か月以内の決まった長さ」で、前のスプリントが終わるとすぐに次のスプリントが始まる決まりです。
プロダクトバックログアイテムに書く内容
プロダクトバックログアイテム(PBI)は、少なくとも何を作るか・直すかの説明と並び順、作業の大きさ(サイズ)が分かるように書きます。2020年版のガイドは、リファインメントで足す詳細の例として説明・並び順・サイズを挙げ、項目は作業の領域によって異なることが多いという立場です。アイテムの属性についての細かな記述は、2017年版から2020年版への改訂で緩められました。
現場では、説明をユーザーストーリーの形で書き、完了を判断する条件(受け入れ条件)を添えるやり方がよく使われます。ユーザーストーリーの書式はスクラムガイドに定めがなく、チームが選んで使う書き方の一つです。
書く項目 | 書き方の例 |
|---|
説明(ユーザーストーリー) | 購入者として、届く日を見込んで予定を立てるために、注文履歴から配送状況を確かめたい |
受け入れ条件 | 注文履歴に配送状況が表示される/発送前の注文は「準備中」と表示される |
サイズ | チームで決めた相対的な単位での見積もり(ストーリーポイントなど) |
リファインメントでバックログを着手できる状態に保つ
リファインメントは、プロダクトバックログアイテムを小さく分け、説明・並び順・サイズといった詳細を足していく継続的な活動です。スクラムガイド2020年版では5つのイベント(スプリント・スプリントプランニング・デイリースクラム・スプリントレビュー・スプリントレトロスペクティブ)には含まれず、スクラムチームはこの活動を通じて、次のスプリントでアイテムを選ぶのに必要な透明性を得るとされています。
作業の規模を見積もる責任を持つのは、その作業を行う開発者です。開発者がトレードオフを理解して選べるように、プロダクトオーナーが開発者を支援することもできる、とされています。並び順を決めるのはプロダクトオーナー、作業の大きさを見積もるのは開発者という分担があるので、リファインメントは両者が同じアイテムを見ながら話し合う場になります。
リファインメントで確かめておきたいのは次の4点です。
- 1回のスプリントで終わる大きさに分けられているか
- 受け入れ条件が書かれ、開発者が完了を判断できるか
- 並び順の理由(事業の指標・利用者の声・期限)を説明できるか
- 他チームの作業や未決の論点に左右されないか、左右されるならそれが書き出されているか
スクラムのイベントでバックログを使う場面
スクラムでは、1か月以内の決まった長さのスプリントを繰り返し、その中の4つのイベントでバックログを作ったり見直したりします。1か月のスプリントの場合の時間の上限は、スプリントプランニングが8時間、スプリントレビューが4時間、スプリントレトロスペクティブが3時間で、デイリースクラムは毎日15分です(スクラムガイド 2020年11月・日本語訳)。
イベント | 時間の上限 | バックログとの関わり |
|---|
スプリントプランニング | 8時間 | スクラムチーム全体で計画を作り、スプリントバックログにまとめる。なぜ価値があるか(スプリントゴール)はチーム全体で決め、何をやるかは開発者がプロダクトオーナーと話し合って選び、どう進めるかは開発者が決める |
デイリースクラム | 15分 | 開発者がスプリントゴールへの進捗を確かめ、必要に応じてスプリントバックログを組み替える |
スプリントレビュー | 4時間 | スクラムチームとステークホルダーが成果を確かめ、新たな機会に合わせてプロダクトバックログを調整することもある |
スプリントレトロスペクティブ | 3時間 | 改善策を決め、次のスプリントのスプリントバックログに加えることもできる |
出所: Ken Schwaber・Jeff Sutherland「スクラムガイド」(2020年11月・日本語訳)・時間の上限は1か月のスプリントの場合。
スプリントプランニングは、スクラムチーム全体の共同作業として計画を作る場です。プロダクトオーナーが今回のスプリントでプロダクトの価値をどう高められるかを提案し、チーム全体でスプリントゴールを決めたうえで、開発者がプロダクトオーナーとの話し合いを通じてアイテムを選びます。選んだアイテムをどう作業に分けて進めるかは開発者だけの裁量で、多くの場合は1日以内で終わる小さな作業に分けて計画を立てる、というのがガイドの説明です。
2020年の改訂で変わった呼び方と決まりごと
2020年版のスクラムガイドでは、プロダクトオーナー・スクラムマスター・開発者という3つの責任を持つ、1つのスクラムチームとして定義し直されました。旧版の「開発チーム」というチーム内のチームはなくなり、チームの人数は「通常は10人以下」とされています。
同じ改訂で、プロダクトバックログが目指す「プロダクトゴール」が新しく加わり、3つの作成物がそれぞれ確約を持つ形に整理されました。プロダクトバックログにはプロダクトゴール、スプリントバックログにはスプリントゴール、完成したインクリメント(利用できる成果物)には完成の定義が対応します。スプリントプランニングで話し合う内容にも、従来の「何を」「どのように」に「なぜ」が加わりました。
スプリントの中で複数のインクリメントを作ってよく、スプリントの終了を待たずにステークホルダーへ届けてもかまわない点も、1回のスプリントで1回のリリースと決めている現場は知っておくと役立ちます。
カンバンやウォーターフォールでのバックログの扱い
バックログは、スクラムに限らずカンバンやウォーターフォールの開発でも、これから取り組む作業を順に並べた一覧として使われます。違いは、一覧からいつ、どれだけの作業を取り出すかという点です。
Daniel S. Vacanti らが公開しているカンバンのガイド「The Kanban Guide」(2025年5月版)は、着手したがまだ終わっていない作業(WIP)の数を明示的に管理し、余力があるという合図が出てから次の作業に着手する「プル」の進め方を求めています。カンバンにはスクラムのスプリントのような決まった区切りの期間は定められていないため、バックログの上から順に、手が空いたときに作業を取り出していく使い方です。
ウォーターフォール型の開発では、要件定義で作る範囲を先に固めて工程を順に進めます。バックログは計画に入らなかった要望や次のリリースに回す課題をためておく一覧として扱われ、並び順は次の計画を立てる段階でまとめて見直す、という使い方です。
PdM・PO・スクラムマスター・開発者の担当範囲
バックログに対して、プロダクトオーナー(PO)は中身と並び順に、開発者はスプリントバックログと作業の見積もりに責任を持ち、スクラムマスターはプロダクトオーナーが効果的なバックログ管理の方法を見つけるのを手助けする、という分担です。PdM(プロダクトマネージャー)はスクラムガイドに出てくる役割の名前ではなく会社の職名で、スクラムを使うチームではプロダクトオーナーの責任を担う立場に置かれることがあります。
役割 | バックログで責任を持つこと(スクラムガイド2020年版) | 日々の仕事の例 |
|---|
プロダクトオーナー(PdMが担うことがある) | プロダクトゴールを決めて伝える、アイテムを作って明確に伝える、アイテムを並び替える、バックログを見える化して理解されるようにする | 利用者の声や事業の指標から並び順を決め、ステークホルダーに理由を説明する |
スクラムマスター | プロダクトオーナーへの支援として、プロダクトゴールの定義とバックログ管理の方法を探す手助けをする、明確で簡潔なアイテムが必要なことをチームに理解してもらう | リファインメントの進め方を整え、大きすぎるアイテムや曖昧なアイテムを指摘する |
開発者 | スプリントの計画(スプリントバックログ)を作る、作業の規模の見積もりに責任を持つ | アイテムを1日以内で終わる作業に分ける、デイリースクラムで計画を組み替える |
出所: Ken Schwaber・Jeff Sutherland「スクラムガイド」(2020年11月・日本語訳)をもとに編集部が整理(日々の仕事の例は編集部による)。
スクラムガイドは、プロダクトオーナーを「1人の人間であり、委員会ではない」とし、ステークホルダーがプロダクトバックログを変えたいときはプロダクトオーナーを説得する、と定めています。並び順を決める権限が1人に集まるぶん、プロダクトオーナーを担うPdMには、並べた理由を言葉にして関係者の合意を得る仕事が欠かせません。期限のある1つのプロジェクトを完了させる責任者であるプロジェクトマネージャーとPdMの違いは「ITのプロジェクトマネージャーとは|役割・年収・資格」で整理しています。
スクラムやアジャイルの経験はエンジニア職の求人の12.2%が条件に挙げる
Offers に公開されたエンジニア職の正社員求人のうち12.2%は、必須条件か歓迎条件にスクラムかアジャイルの語を挙げています(Offers(株式会社overflow)調べ・タイトルにエンジニア・開発者などを含む正社員求人 n=1,744・2022年3月〜2026年9月公開)。
スクラムやアジャイル開発の経験は、スクラムマスターという職名の求人に限らず、エンジニアの求人の条件としても問われます。スクラムマスターを目指す場合も、まずは開発者やプロダクトオーナーとしてバックログを扱った経験を、今の職場で積み上げておくのが近道です。Offers では、スクラムやアジャイル開発の経験を条件に挙げるIT企業のエンジニア・PdMの正社員求人を探せます。
PdMの求人票はバックログをロードマップと優先順位で書く
Offers に公開されたPdM・プロダクトオーナー職の正社員求人のうち、本文に「バックログ」の語があるものは3.8%にとどまり、同じ仕事は「ロードマップ」(51.9%)や「優先順位・優先度」(39.6%)の語で書かれていました。
求人票の上では、バックログを並べ替える仕事は、ロードマップを作って開発の優先順位を決める仕事として表されています。
PdM・プロダクトオーナー職の求人本文に載る語 | 記載のある求人の割合 |
|---|
要件定義・要求仕様・仕様策定 | 57.5% |
ロードマップ | 51.9% |
優先順位・優先度 | 39.6% |
ステークホルダー | 30.2% |
スクラム | 17.9% |
スプリント | 10.4% |
バックログ | 3.8% |
ユーザーストーリー | 1.9% |
出所: Offers(株式会社overflow)調べ・タイトルにプロダクトマネージャー・PdM・プロダクトオーナーを含む正社員求人 n=106・2022年3月〜2026年9月公開。
「バックログ」の語が載る4件は、いずれもバックログの管理や、要件をプロダクトバックログに落とし込む仕事、スプリント単位でのバックログの整理といった仕事の説明でした。
バックログ管理の経験を職務経歴書で伝える書き方
バックログを扱った経験は、職務経歴書では「バックログを管理した」と書くより、求人票に多い語に置き換え、何を根拠にどう並べて何が変わったかまで書くと伝わります。求人票の語と自分の経験の語がずれていると、書類を読む人が同じ仕事だと気づきにくくなるためです。
- 「プロダクトバックログを管理」は「四半期のプロダクトロードマップを作り、要望と課題の優先順位を利用データと商談の声から決めた」と書く
- 「リファインメントを主導」は「エンジニア・デザイナーと要件定義を詰め、1スプリントで完了する単位に分割した」と書く
- 「スプリントレビューを運営」は「リリースごとにステークホルダーへ成果を報告し、次の開発計画に反映した」と書く
- 並べたアイテムの件数より、優先した施策で動いた指標(利用率・解約率・問い合わせの件数など)を添える
職務経歴書全体の組み立ては「レジュメとは|転職での意味とエンジニアの書き方」と「エンジニアの履歴書・職務経歴書|52人調査と書き方」で解説しました。言い換えの語は、応募したい求人の本文から拾うのが確実で、何件か読み比べると、その会社がエンジニアやPdMのどんな仕事を求めているかが見えてきます。
バックログを管理するツールの選び方
バックログは表計算ソフトや付箋でも管理できますが、チームが同じ一覧を見て並び順と進み具合を共有するには、プロジェクト管理ツールを使うのが手早い方法です。代表的なものに、Atlassian の Jira、株式会社ヌーラボの Backlog、GitHub の Projects などがあります。
選ぶときは、次の3点を確かめておくと導入後のずれを減らせます。
- スクラムのスプリントで区切って使うか、カンバンのように流れで管理するか(ボードの形式が合うか)
- ソースコードの管理(リポジトリ)や、仕様を書く文書のツールとつなげられるか
- エンジニア以外のステークホルダーも、一覧と並び順を見られるか
ツールが受け持つのは一覧を見やすくするところまでで、並び順を決める判断は人の仕事として残る、という線引きです。どのツールを使う場合も、並べた理由をアイテムの説明に残しておくと、リファインメントやスプリントレビューで話がぶれにくくなります。
バックログの要点
バックログは、プロダクトをよくするための作業を価値の高い順に並べた一覧で、スクラムではプロダクトオーナーが責任を持つプロダクトバックログと、開発者が作るスプリントの計画であるスプリントバックログに分かれます。2020年版のガイドでは、リファインメントは継続的な活動とされ、作業の規模の見積もりは開発者が担い、チームは通常10人以下、スプリントは1か月以内です。
Offers のPdM・プロダクトオーナー職の正社員求人では「バックログ」の語は3.8%で、同じ仕事は「ロードマップ」51.9%、「優先順位・優先度」39.6%の語で書かれていました(Offers(株式会社overflow)調べ・PdM・プロダクトオーナー職の正社員求人 n=106・2022年3月〜2026年9月公開)。
バックログを扱ってきた経験を次の職場で活かすなら、求人票がその仕事をどんな言葉で書いているかを確かめるところから始めてください。Offers で、エンジニアやPdM・プロダクトオーナーの正社員求人を探せます。