先に要点
- 英語の backlog は元々「未処理のもの」「積み残し」という意味。IT 業界では スクラムの用語として「やるべきタスクの順序付きリスト」を指すのが一般的。
- スクラムでは プロダクトバックログ(プロダクト全体の作るもの一覧)と スプリントバックログ(今のスプリントで実際に作るもの)の 2 種類を使い分ける。前者はプロダクトオーナーが管理し、後者は開発チームが管理する。
- 運用で効くのは「やる気」ではなく仕組み。リファインメントを曜日固定にする・優先度を強制的に一意な序列にする・90 日触っていない項目を機械的に閉じる──この 3 つを決めただけで、バックログは「ゴミ箱」から「上から取れば動くリスト」に変わる。
- ツールは Jira / Linear / GitHub Projects / Backlog(株式会社ヌーラボ) など多数。2026 年現在、Jira は 10 ユーザーまで無料・有料は 1 ユーザー 7.91 ドル/月〜、Linear は無料枠が 250 issue までで有料は約 10 ドル/月〜。この「無料枠の壁」が乗り換えの引き金になることが多い。
「アジャイル始めてみたんだけど、バックログって何?」「プロダクトバックログとスプリントバックログ、別物?」「バックログを綺麗に保つコツって?」 ── スクラムやカンバンを始めると、最初に必ず出会う言葉です。
ざっくり言うと、バックログは「これから作るもの・直すもの・調べるもの」を、優先順位付きで並べた一覧です。タスク管理ツールに登録された「未着手チケットの山」が一般的なイメージ。とはいえスクラムの文脈では役割と種類がはっきり決まっているので、そこを揃えると現場で混乱しません。
この記事では、言葉の本来の意味と 2 種類のバックログを押さえたうえで、「運用して実際に効いた具体策」──リファインメントの曜日固定、優先度の強制順位付け、ゴミ箱化したバックログの削り方、そして スクラム 用ツールを Jira と Linear の間で乗り換えるときの判断基準まで、踏み込んで整理します。
「バックログ」の本来の意味
最初に言葉の整理から。
英語の backlog
「未処理の仕事」「受注残」「積み残し」の意味。製造業や物流の文脈では 「処理しきれずに溜まったもの」のニュアンスが強く、ネガティブな響きを持つこともある。
IT での意味
スクラムが普及してから、「これから順番に取り組むタスクの優先順位付きリスト」として使われるようになった。「積み残し」ではなく 「未来の作業計画」に近いポジティブな意味。
日常会話での使い方
エンジニア同士で「バックログに入れておいて」と言えば、「タスク管理ツールの未着手一覧に追加して、優先順位は後で議論」くらいの意味。即対応するわけではないが、忘れずに記録する、という温度感。
「バックログ」 という言葉は文脈で広さが変わるので、スクラム導入チームでは最初に「ここで言うバックログはこれ」と統一しておくと混乱が減ります。
スクラムの 2 種類のバックログ
スクラムでは プロダクトバックログ と スプリントバックログ を別物として扱います。
| 項目 | プロダクトバックログ | スプリントバックログ |
|---|---|---|
| 対象範囲 | プロダクト全体で作る予定のもの | 今のスプリント(1〜2 週間)で作るもの |
| 期間 | 無期限(継続的にメンテ) | 1 スプリントの期間限定 |
| 管理する人 | プロダクトオーナー(PO) | 開発チーム |
| 項目の粒度 | 大きいものから細かいものまで混在 | 1 日 〜 数日で完了するサイズ |
| 優先順位 | PO が決める | チームが決める(取り出し順) |
| 変更タイミング | いつでも追加・削除・並べ替え可 | スプリント中は基本固定 |
| 典型的な記述形式 | ユーザーストーリー / 機能名 | タスク / サブタスク |
要するに、プロダクトバックログは「これから作るかもしれないものの一覧」、スプリントバックログは「今のスプリントで実際に手を動かすものの一覧」。前者から後者に項目を「取り出す」イメージが正解です。
プロダクトバックログ
プロダクト全体の「作るかもしれない / 直すかもしれない」項目を全部入れる場所。
何を入れるか
新機能、改善、バグ修正、技術的負債の解消、調査タスク、ユーザー要望 ── プロダクトに関わるあらゆる作業候補。「いつかやるかもしれない」も含めて入れる。
優先順位
プロダクトオーナー(PO)が決める。上から「次のスプリントでやる候補」「数ヶ月先の候補」「半年〜1年先の候補」のように粒度が変わる。上にあるほど詳細で、下にあるほど大雑把。
サイズ感の例
上位 10 〜 20 件は「次のスプリントですぐ取れる」状態(受け入れ条件まで明文化)。中位は「議論はしたが詳細は未確定」。下位は「アイデアだけメモ」。下に行くほど粗くて OK。
非公開項目との区別
セキュリティ脆弱性・社外秘の戦略は、別のチケット管理(プライベート issue)で扱うことも。プロダクトバックログはチームメンバー全員が見られる場所に置く前提。
「プロダクトの中で これからやる可能性のあるものが、すべて優先順位付きで並んでいる場所」が、健全なプロダクトバックログの状態です。
スプリントバックログ
今のスプリント(1〜2 週間)で「実際に取り組むもの」の一覧。
何を入れるか
スプリントプランニングで「今回のスプリントでこれを完了させる」と合意した項目だけ。プロダクトバックログから取り出してきたユーザーストーリーと、それを実装するためのタスク・サブタスク。
誰が管理するか
開発チーム(プロダクトオーナーではない)。「どの順番で手を付けるか」「誰がどれを担当するか」はチームが決める。
スプリント中の変更
原則として追加しない / 削除しない。途中で「これは間に合わない」となったら、PO と合意の上で次のスプリントに送る。「今のスプリントの約束を守る」 ことが信頼性につながる。
可視化
カンバンボード(To Do / In Progress / Done)で進捗を毎日見える化するのが定番。デイリースクラムで全員が状況を共有する。
スプリントバックログは「短期間の約束」を表す場所で、「ここに入った項目はスプリント末までに必ず完了する」のがチームの合意事項です。
バックログ運用の核 — 3 つの柱
バックログを動く状態に保つためには、3 つの作業が継続的に必要です。
「バックログを並べるだけ」 と 「バックログを動かす」 は別物。優先順位付け・リファインメント・完了の定義の 3 つを回すと、初めて「次に取れば動ける」状態が維持されます。次の章からは、この 3 つを「実際に回すための具体的な運用ルール」に落とし込みます。
運用して効いた具体策 — ルール化しないと続かない
リファインメントも棚卸しも、「気づいたときにやる」では絶対に続きません。カレンダーと数値ルールに落とし込むのが現実解です。ここでは実際に効果のあった運用パターンを 3 つ紹介します。
リファインメントは曜日・時間を固定する
リファインメントが形骸化する最大の原因は「会議の予定がその都度ふわっと入る」ことです。スプリントの直前に詰め込むと、未整理の項目を急いで詰めることになり、結局プランニングが長引きます。対策はシンプルで、曜日と時間を固定すること。
具体的な固定枠の例
2 週間スプリントなら、スプリント中盤の火曜 10:00〜10:45(45 分)を毎回固定。スプリント開始直後でも末でもなく「真ん中」に置くのがコツ。開始直後は今のスプリントに集中したい、末は振り返りで埋まる、その中間に置くと「次の燃料を仕込む」タイミングになる。
扱う件数を絞る
1 回で全件は見ない。「次の 2 スプリントで取りそうな上位 5〜10 件だけ」に絞る。45 分で 1 件 5 分ずつ詰めれば十分。下位 100 件は触らない。磨くのは「もうすぐ取るもの」だけでよい。
出口の基準を決める
リファインメントの「完了」は、その項目が Ready の定義(受け入れ条件あり・見積もり済み・依存先が明確)を満たした状態。満たせない項目は「PO が誰々に確認」というアクション付きで一旦下ろす。曖昧なまま上位に残さない。
時間の目安
スプリントの総工数の 5〜10% 程度がリファインメントの適正レンジとされる。5 人チームの 2 週間スプリント(おおよそ 400 時間)なら、合計 20〜40 時間。45 分の会議 1 回ではこれに届かないので、各自の事前準備(チケット下書き)を込みで設計する。
固定枠にすると「今日はリファインメントだから上位を見ておこう」と各自が事前にチケットを下書きしてくるようになります。会議をイベント化するのではなく、リズムにするのが狙いです。
優先度は「強制的に一意な序列」にする
バックログが死ぬ典型は 「全部 Priority: High」です。ラベル方式(High / Medium / Low)は楽なので誰もが High を付け、半年後には上位 80 件が全部 High になります。これは優先順位が「無い」のと同じです。
対策は ラベルではなく「順位」で管理すること。具体的には次のルールを敷きます。
ポイントは「全部を厳密に順位付けしようとしない」こと。労力をかけるのは上位 20〜30 件だけで、ここさえ一意に並んでいれば「次に何を取るか」で迷うことはなくなります。Jira なら「ランク」フィールド(ドラッグ順)、Linear なら標準のリスト並び順がそのまま順位になるので、ツール側の機能としても素直に実現できます。
ゴミ箱化したバックログをどこまで削るか
「なんでも入れる・誰も消さない」を続けると、バックログはすぐ数百〜数千件に膨らみます。ここからの回復で迷うのが「どこまで削っていいのか」です。経験的に効く基準を示します。
| 判断軸 | しきい値の目安 | アクション |
|---|---|---|
| 最終更新日 | 90 日以上どの欄も更新されていない | 原則クローズ。コメントもラベル変更も付かない項目は実質「誰も必要としていない」 |
| 最終更新日(長期) | 180 日以上更新なし | 議論の余地なく一括クローズ。本当に必要なら誰かがまた起票する |
| 上位の維持件数 | 「Ready 〜 もうすぐ取る」は 30 件以内 | これを超える分は下位区分(Someday)へ降格。上位は常に把握できる量に保つ |
| 全体件数 | 整理後に 50〜150 件へ圧縮 | 500 件超は「誰も全体を把握できない」サイン。半分以下を目標に削る |
| 重複・解決済み | 同じ要望の別チケット / 既に直ったバグ | 即クローズ。代表 1 件に集約する |
実際の棚卸しは、ツールのクエリで対象を機械的に抽出してから一括処理すると速いです。たとえば Jira の JQL なら次のように「90 日触っていない未完了項目」を一発で出せます。
project = ABC AND statusCategory != Done AND updated <= -90d ORDER BY updated ASCこれで出てきた数百件を選択し、ステータスを一括で Closed(理由は Stale / 棚卸し)に変える。削除ではなくクローズにしておけば、後で「あれどこいった?」となっても検索で見つかります。
ためらいがちですが、現場の実感としては 「90 日誰も触っていない項目は、消しても 95% は誰も困らない」です。残りの 5% も、本当に必要なら必ず誰かが再起票します。「消す勇気がない」ことこそがゴミ箱化の真因なので、棚卸しを四半期に 1 回の定例(担当者を 1 人決めて 30 分)に組み込んでしまうのが結局いちばん続きます。
優先順位の付け方 — よくある枠組み
上の「強制順位付け」を支える判断軸として、いくつかのフレームワークがよく使われます。点数化したいときの引き出しとして持っておくと便利です。
RICE スコア
Reach(影響範囲)× Impact(影響度)× Confidence(確信度) ÷ Effort(工数) で計算。数値で並べ替えると、感覚論を避けられる。Intercom が広めた手法。
MoSCoW
Must / Should / Could / Won't の 4 段階で分類。「絶対必要」「あったらいい」「なくてもいい」「やらない」を明示的に分けることで、Must だけ進める運用が可能になる。
Kano モデル
機能を「当たり前品質」「一元的品質」「魅力的品質」「無関心」に分類。差別化要素を意識的に拾う場面で使う。
Cost of Delay
「遅らせると失うもの」をお金で見積もって、ROI で並べる。SAFe など大規模アジャイル文脈で使われる。
単純な相対比較
少人数チームなら、「A と B、どっち先?」を片っ端から比べて並べるだけでも十分。フレームワークに振り回されるより、PO の判断軸を言語化していくほうが実用的なことも多い。
完璧なフレームワークは存在しません。「チームと PO が納得できる根拠で並んでいる」状態を作るのが目的で、手法はそのための道具です。
バックログ管理ツール
バックログを動かすためのツールは多種多様。代表的なものを整理します。料金は 2026 年時点の公開情報に基づく目安です。
| ツール | 得意領域 | 料金感(2026 年) |
|---|---|---|
| Jira(Atlassian) | 本格的なスクラム / カンバン、大規模チーム、エンタープライズ | 無料(10 ユーザーまで)/ Standard 約 7.91 ドル・Premium 約 14.54 ドル(1 ユーザー/月) |
| Linear | モダン SaaS / スタートアップ、軽快な UX、開発者好み | 無料(250 issue まで)/ Basic 約 10 ドル・Business 約 16 ドル(1 ユーザー/月) |
| GitHub Projects | GitHub Issues と連携、OSS / 小〜中規模開発 | 無料(GitHub アカウントに付随) |
| Backlog(ヌーラボ) | 日本企業の SI 系、Wiki / Git / バグ管理を統合 | 有料(スペース単位の月額) |
| Asana | 非エンジニア混在チーム、業務管理寄り | 無料 / 有料 |
| Notion / Notion Projects | ドキュメント中心のチーム、軽量プロジェクト管理 | 無料 / 有料 |
| ClickUp / monday.com | 汎用プロジェクト管理 | 無料 / 有料 |
| Trello | シンプルなカンバン、小規模 / 個人 | 無料 / 有料 |
小規模 / 個人開発
GitHub Projects か Linear が現代的。Trello / Notion でも十分回る。
大企業 / 本格スクラム
Jira が依然として圧倒的シェア。エピック / ストーリー / タスク / バグ / サブタスクの階層、カスタムワークフロー、レポート機能などが揃う。
「ツールはあくまで道具」。バックログの運用ルール(優先順位付け・リファインメント・完了の定義)が固まっていないと、Jira を入れても回らない、というのは現場でよくある失敗です。
Jira と Linear、どちらに乗り換えるか
ツール選びで最も相談が多いのが、この 2 つの行き来です。「なんとなく流行りで」ではなく、乗り換えの引き金になる具体的な事情を整理します。
Linear へ乗り換える理由(Jira / その他 → Linear)
起票・操作が遅いのが我慢できない
最大の動機がこれ。Jira はチケット 1 枚作るのにフィールドが多く、画面遷移も重い。Linear はキーボード主体で 数秒で 1 枚起票でき、開発者が「書くのが面倒だから書かない」を起こしにくい。バックログの鮮度は「起票のしやすさ」に直結する。
設定が増えすぎて誰も管理できない
Jira はワークフロー・カスタムフィールド・権限が際限なくカスタマイズでき、数年運用すると「設定の沼」になる。Linear は思想として設定項目を絞っており、管理コストが小さい。10〜50 人規模で「Jira 管理者を専任で置けない」なら有力。
無料枠の壁(250 issue)を理解しておく
注意点。Linear の無料プランは アクティブ issue 250 件・2 チームまで。毎週リリースするチームは数ヶ月で上限に当たり、超えると新規起票がブロックされる。本格運用ならほぼ確実に有料(Basic 約 10 ドル/月〜)前提になる。
GitHub と密に連携したい
PR とブランチの自動連携・自動クローズなど、開発フローとの結合が滑らか。コードと issue を行き来する開発者中心チームに向く。
Jira へ乗り換える(残る)理由(Linear / 他 → Jira)
非エンジニア部門・全社で使う
営業・サポート・経営まで巻き込んだ大規模運用は Jira の独壇場。細かい権限制御・監査・組織横断レポートが必要なら Linear では届かない。
複雑なワークフローを強制したい
承認フロー・ステータス遷移の制約・必須フィールドなど、「人によってやり方がブレないように縛りたい」要件は Jira が圧倒的に強い。Linear はあえてそこを作り込めない。
既存資産・連携が Atlassian 中心
Confluence・Bitbucket・大量の既存チケットや自動化が Atlassian で動いているなら、移行コストが乗り換えメリットを上回ることが多い。
小規模なら無料枠が広い
10 ユーザーまで無料で、issue 件数の上限がない。少人数でも数百件のバックログを無料で持てるのは、件数で詰まる Linear 無料枠との大きな違い。
ざっくりした判断軸は、「速さと開発者体験を最優先する 10〜50 人の開発組織なら Linear、組織横断の統制と複雑なワークフローが要るなら Jira」です。どちらも無料枠があるので、移行前に代表的なプロジェクト 1 つを 2 週間だけ並行運用して、起票・並べ替え・レポートの実感を比べてから決めるのが安全です。
カンバンとの関係
スクラムとよく混同されるカンバンとバックログの関係も整理しておきます。
スクラムは「スプリント単位」
1〜2 週間のスプリントで一気に複数項目を取り、終わりに振り返る。バックログからスプリントに「取り出す」イメージ。
カンバンは「フロー単位」
スプリントを設けず、常にバックログから上から順に取り続ける。WIP(進行中タスクの数)に上限を設けて、流れを最適化する。
バックログの位置づけ
カンバンでも「これから取り組むタスクのリスト」は必要で、これも広い意味でバックログ。プロダクトバックログに相当するが、スプリントへの「切り出し」がない分シンプル。
運用 / 保守チームに向く
新機能を計画的に作るスクラムに対し、バグ修正や問い合わせ対応中心のチームはカンバンが向く。割り込みが多い運用フェーズでは、スプリントの約束が守りづらいため。
「スクラムなら 2 種類のバックログ、カンバンならフローと優先順位付きの 1 つのバックログ」 という違いです。
バックログ運用の失敗パターン
最後に、よくある運用上のつまずきを 現象 → 原因 → 確認 → 回避 の形で整理します。
バックログがゴミ箱化
現象:数百〜数千件に膨らみ、上から取っても意味が無い。原因:「なんでも入れる・誰も消さない」。確認:「90 日以上更新なし」のクエリで件数を出す。回避:四半期 1 回の棚卸しを定例化し、90 日無更新を一括クローズ。上位は 30 件以内に保つ。
優先順位が「全部最優先」
現象:上位の大半が Priority: High。原因:ラベル方式は誰でも High を付けられる。確認:High の件数を数える。20 件超なら破綻。回避:上位 20〜30 件はラベルを廃止し、一意な並び順を強制する。
リファインメント不足
現象:プランニングで毎回詳細を詰めて長引く。原因:磨き込みが定例化されていない。確認:上位 10 件に受け入れ条件・見積もりがあるか見る。回避:スプリント中盤の固定枠(例:火曜 45 分)で上位だけ磨く。
スプリント中の追加が多すぎ
現象:「これも今すぐ」が頻発し約束が守れない。原因:割り込みの受け皿がない。確認:スプリント中の追加件数を計測。回避:緊急枠を最初から確保するか、カンバンへ切り替える。
「完了」がチームでバラバラ
現象:Done なのに残作業が出る。原因:Definition of Done が未明文化。確認:「テスト・ドキュメント・本番反映」を全員に聞いて答えが揃うか。回避:DoD を 1 枚に書き出しボードに貼る。
PO が忙しすぎて並べられない
現象:優先順位が更新されず滞る。原因:PO の時間が他業務で塞がっている。確認:並び順の最終更新日を見る。回避:PO の稼働を確保し、難しければ代理で決める権限者を 1 人明示する。
「バックログは存在するが、動いていない」 状態が、スクラム導入で最も多い失敗パターンです。
バックログに関するよくある質問
Q. バックログは何件くらいあるのが普通?
A. プロダクトの規模次第ですが、50〜200 件程度が現実的な健全レンジ。500 件を超えると「誰も全部把握できない」状態になりやすく、下位の整理が必要です。「全部把握する」より「上位 20〜30 件が明確で、下位はざっくり」のほうが運用が回ります。
Q. リファインメントはどのくらいの頻度・時間でやればいい?
A. スプリントごとに 1 回、曜日・時間を固定するのがおすすめです。2 週間スプリントなら中盤の 45 分前後を定例枠に。1 回で全件は見ず、「次の 2 スプリントで取りそうな上位 5〜10 件」だけを磨きます。各自が事前にチケットを下書きしてくる前提にすると、会議自体は短くて済みます。
Q. 優先度ラベル(High/Medium/Low)が全部 High になってしまいます。
A. ラベル方式は誰でも High を付けられるので、ほぼ必然的にそうなります。対策は「上位 20〜30 件だけラベルを廃止し、並び順そのものを優先度にする」こと。新規項目は必ず「今ある何番と何番の間か」を決めて挿し込み、同率を認めません。下位はラベルのままで構いません。
Q. ゴミ箱化したバックログ、どこまで削っていい?
A. 経験則として 「90 日以上どの欄も更新がない未完了項目は一括クローズ」で、ほぼ誰も困りません。180 日無更新は議論不要で閉じます。削除ではなくクローズ(理由:Stale / 棚卸し)にしておけば後から検索で見つかるので安全。整理後は上位 30 件以内・全体 50〜150 件を目標に圧縮します。本当に必要なものは誰かが再起票します。
Q. プロダクトオーナーがいません。誰が優先順位を決めればいい?
A. 小規模チームなら「PO 役を兼任」するか、「テックリードと PdM が協議」する形が一般的。重要なのは 「優先順位を決める権限と責任を持つ人が、明確に 1 人いる」こと。複数人で曖昧に決めると、必ず迷走します。
Q. Jira と Linear、どっちを選ぶ / 乗り換えるべき?
A. 速さと開発者体験を最優先する 10〜50 人の開発組織なら Linear、組織横断の統制・複雑なワークフロー・大規模が要るなら Jira。Linear は無料枠が 250 issue までで本格運用なら有料(約 10 ドル/月〜)前提、Jira は 10 ユーザーまで無料・件数無制限という違いも効きます。移行前に代表プロジェクト 1 つを 2 週間並行運用して比べるのが確実です。
Q. スプリント中にどうしても割り込み対応が必要になった場合は?
A. PO と協議の上、スプリント計画を変更します。「今のスプリントから何かを外して新タスクを入れる」「次のスプリントに送る」など、明示的な合意を取る。黙って割り込むのは NG。これが続くなら、そもそもスプリントの長さやチーム構成を見直すサインです。
Q. 個人開発でもバックログは必要?
A. あった方がいいです。頭の中で覚えていられる量を超えると、必ず「やろうと思っていたあれ」を忘れる。GitHub Issues + Projects、Notion、Trello のような軽量ツールで十分。「優先順位を考えて並べておく」だけで、開発の手が止まる時間が大きく減ります。
参考リンク
- スクラムガイド(公式日本語版): scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
- Atlassian: Backlog management
- Jira(料金): atlassian.com/software/jira/pricing
- Linear(料金): linear.app/pricing
- GitHub Projects: docs.github.com/en/issues/planning-and-tracking-with-projects
- Backlog(ヌーラボ): backlog.com
- 関連記事: 枯れた技術を選ぶ価値 / レガシー言語の市場価値