バックログとは — プロダクトバックログとスプリントバックログの違い、運用方法

英語の backlog

「未処理の仕事」「受注残」「積み残し」の意味。製造業や物流の文脈では 「処理しきれずに溜まったもの」のニュアンスが強く、ネガティブな響きを持つこともある。

IT での意味

スクラムが普及してから、「これから順番に取り組むタスクの優先順位付きリスト」として使われるようになった。「積み残し」ではなく 「未来の作業計画」に近いポジティブな意味。

日常会話での使い方

エンジニア同士で「バックログに入れておいて」と言えば、「タスク管理ツールの未着手一覧に追加して、優先順位は後で議論」くらいの意味。即対応するわけではないが、忘れずに記録する、という温度感。

スクラム用語としての厳密な意味

スクラムガイドでは 「プロダクトバックログ」と「スプリントバックログ」を明確に定義している。次の章で詳しく見る。

何を入れるか

新機能、改善、バグ修正、技術的負債の解消、調査タスク、ユーザー要望 ── プロダクトに関わるあらゆる作業候補。「いつかやるかもしれない」も含めて入れる。

優先順位

プロダクトオーナー(PO)が決める。上から「次のスプリントでやる候補」「数ヶ月先の候補」「半年〜1年先の候補」のように粒度が変わる。上にあるほど詳細で、下にあるほど大雑把。

サイズ感の例

上位 10 〜 20 件は「次のスプリントですぐ取れる」状態(受け入れ条件まで明文化)。中位は「議論はしたが詳細は未確定」。下位は「アイデアだけメモ」。下に行くほど粗くて OK。

非公開項目との区別

セキュリティ脆弱性・社外秘の戦略は、別のチケット管理(プライベート issue)で扱うことも。プロダクトバックログはチームメンバー全員が見られる場所に置く前提。

何を入れるか

スプリントプランニングで「今回のスプリントでこれを完了させる」と合意した項目だけ。プロダクトバックログから取り出してきたユーザーストーリーと、それを実装するためのタスク・サブタスク。

誰が管理するか

開発チーム(プロダクトオーナーではない)。「どの順番で手を付けるか」「誰がどれを担当するか」はチームが決める。

スプリント中の変更

原則として追加しない / 削除しない。途中で「これは間に合わない」となったら、PO と合意の上で次のスプリントに送る。「今のスプリントの約束を守る」 ことが信頼性につながる。

可視化

カンバンボード(To Do / In Progress / Done)で進捗を毎日見える化するのが定番。デイリースクラムで全員が状況を共有する。

RICE スコア

Reach(影響範囲)× Impact(影響度)× Confidence(確信度) ÷ Effort(工数) で計算。数値で並べ替えると、感覚論を避けられる。Intercom が広めた手法。

MoSCoW

Must / Should / Could / Won't の 4 段階で分類。「絶対必要」「あったらいい」「なくてもいい」「やらない」を明示的に分けることで、Must だけ進める運用が可能になる。

Kano モデル

機能を「当たり前品質」「一元的品質」「魅力的品質」「無関心」に分類。差別化要素を意識的に拾う場面で使う。

Cost of Delay

「遅らせると失うもの」をお金で見積もって、ROI で並べる。SAFe など大規模アジャイル文脈で使われる。

単純な相対比較

少人数チームなら、「A と B、どっち先?」を片っ端から比べて並べるだけでも十分。フレームワークに振り回されるより、PO の判断軸を言語化していくほうが実用的なことも多い。

技術的負債の扱い

機能追加と技術的負債の返済は、同じバックログに並べて優先度を比較する。「機能追加を続けて 1 年後にメンテ不能」になるのを防ぐため、リファクタや基盤改善も上位に入れる枠組みを作る。

小規模 / 個人開発

GitHub Projects か Linear が現代的。Trello / Notion でも十分回る。

スタートアップ / 中規模

Linear が人気。UX が速く、開発者文化に合う。Notion と組み合わせて「仕様は Notion、タスクは Linear」が定番。

大企業 / 本格スクラム

Jira が依然として圧倒的シェア。エピック / ストーリー / タスク / バグ / サブタスクの階層、カスタムワークフロー、レポート機能などが揃う。

日本の SI 業界

Backlog(ヌーラボ)が定着している。日本語サポート、Wiki / Git / Gantt が一体で、SIer の現場で長年使われている。

スクラムは「スプリント単位」

1〜2 週間のスプリントで一気に複数項目を取り、終わりに振り返る。バックログからスプリントに「取り出す」イメージ。

カンバンは「フロー単位」

スプリントを設けず、常にバックログから上から順に取り続ける。WIP(進行中タスクの数)に上限を設けて、流れを最適化する。

バックログの位置づけ

カンバンでも「これから取り組むタスクのリスト」は必要で、これも広い意味でバックログ。プロダクトバックログに相当するが、スプリントへの「切り出し」がない分シンプル。

運用 / 保守チームに向く

新機能を計画的に作るスクラムに対し、バグ修正や問い合わせ対応中心のチームはカンバンが向く。割り込みが多い運用フェーズでは、スプリントの約束が守りづらいため。

バックログがゴミ箱化

「なんでも入れる」「誰も整理しない」を放置すると、数百〜数千件の未整理項目になり、上から取っても意味のない状態に。定期的な棚卸し(古い項目の削除)を運用に組み込む。

優先順位が「全部最優先」

すべてが「Priority: High」になると、優先順位が機能しなくなる。強制的に序列を付ける(必ず 1 位 / 2 位 / 3 位 ... を決める)ことで、「次に何をやるか」 が明確になる。

リファインメント不足

項目の中身が雑なまま放置されていると、スプリントプランニングで毎回詳細を詰めることになる。週 1〜2 時間のリファインメント会を定例化するのが対策。

スプリント中の追加が多すぎ

「これも今すぐやって」がスプリント中に頻発すると、スプリントの約束が守れない。割り込みが多いなら、そもそもカンバンに切り替えるか、緊急対応枠を最初から確保しておく。

「完了」がチームでバラバラ

誰かにとってはコードが書けたら完了、誰かにとっては本番デプロイまで。Definition of Done を明文化していないと、進捗が嘘になる。

PO が忙しすぎて優先順位を決められない

プロダクトオーナーが他の仕事で塞がっていると、バックログの優先順位が滞る。PO の時間確保はスクラム運用の前提条件で、ここが崩れると全体が崩れる。