バーンダウンチャートとは？作り方・読み方・活用法を徹底解説
バーンダウンチャートとは
バーンダウンチャートは、スプリント期間中の残作業量の推移を可視化するグラフです。横軸に時間（日数）、縦軸に残りの作業量（ストーリーポイントやタスク数）を取り、スプリント開始から終了までの進捗を1本の折れ線で表します。
「バーンダウン（burn down）」は「燃え尽きる」という意味で、作業が消化されていく様子を火が燃え尽きるイメージで表現しています。
バーンダウンチャートは、スクラムやアジャイルプロジェクト管理で最も広く使われるアーティファクトの1つです。作成が簡単で、読み方もシンプルでありながら、チームが計画通りに進んでいるかを即座に客観的にフィードバックしてくれます。
誰が使うのか
- スクラムチーム：デイリースクラムでスプリントの進捗を確認する
- プロジェクトマネージャー：リリースバーンダウンで複数スプリントにわたる全体進捗を追跡する
- プロダクトオーナー：スプリント中のスコープ判断の材料にする
- ステークホルダー：詳細なレポートなしでプロジェクトの状況を把握する
なぜ重要なのか
バーンダウンチャートがなければ、チームは感覚やステータスミーティングに頼って進捗を判断することになります。バーンダウンチャートは「感覚」を「データ」に置き換えます。
- スプリントの進捗を一目で把握できる（ステータスミーティング不要）
- 問題を早期に検知し、軌道修正する時間を確保できる
- チームの実際のペースと計画を客観的に比較できる
- デイリースクラムに具体的で視覚的な議論材料を提供する
- 将来のスプリント計画を改善するための履歴データが蓄積される
チャートの基本構造
バーンダウンチャートは、同じ軸上にプロットされた2つの主要な線で構成されます。
理想線（計画線）
スプリント開始時の総ポイントから最終日の0に向かって直線的に引かれる線です。毎日均等に作業が消化される「理想的なペース」を表します。
例: 2週間スプリント、総ポイント40の場合
1日あたりの消化量 = 40 ÷ 10営業日 = 4ポイント/日
Day 0: 40 ポイント
Day 1: 36 ポイント
Day 2: 32 ポイント
...
Day 10: 0 ポイント
理想線はあくまで参照であり、目標ではありません。実際の作業が直線的に進むことは稀です。ストーリーはまとめて完了し、日によって生産性も変わります。理想線の価値は、そのズレを「見える化」することにあります。
実績線
実際の残作業量を日ごとにプロットした線です。ストーリーやタスクが**完了の定義（Definition of Done）**を満たすたびに残りのポイントが減り、線が下がります。
2本の線の関係を読む
理想線と実績線のギャップが、スプリントの健全性を一目で示します。
| 実績線の位置 | 意味 | 推奨アクション |
|---|---|---|
| 理想線よりかなり下 | 予定より早く進んでいる | バックログから追加のアイテムを引き込むことを検討 |
| 理想線と重なる | 予定通り | 現在のペースを維持 |
| 理想線よりやや上 | 軽微な遅れ | スタンドアップでブロッカーを議論。大きな変更は不要 |
| 理想線よりかなり上 | 大幅に遅れている | 障害をエスカレーション。スプリントスコープの縮小を検討 |
作成手順
ステップ1: スプリントデータを用意する
スプリント計画で確定した以下の情報を揃えます。
| 項目 | 例 |
|---|---|
| スプリント期間 | 2週間（10営業日） |
| 開始日 | 2026-03-09（月曜日） |
| 終了日 | 2026-03-20（金曜日） |
| 総ストーリーポイント | 40ポイント |
| スプリントに含むストーリー | 8ストーリー |
| 非稼働日 | 土日 |
ポイント: コミットしたストーリーのみをカウントします。ストレッチゴールを含めると初期値が膨らみ、チャートが誤解を招く基準線になります。
ステップ2: 理想線を引く
開始日の総ポイントから最終日の0ポイントまで、直線を引きます。土日祝日を除いた営業日ベースで引くのが一般的です。
Day 0 → 40ポイント（開始）
Day 10 → 0ポイント（終了）
傾き → -4ポイント/日
ステップ3: 毎日の残作業量を記録する
毎日一定の時刻（通常はデイリースクラムの直前または直後）に、残りのストーリーポイントを記録します。完了の定義を満たしていないストーリーのポイント合計が残作業量です。
Day 0 (月): 40 ← スプリント開始
Day 1 (火): 40 ← まだ完了ストーリーなし
Day 2 (水): 35 ← 5ptのストーリーが完了
Day 3 (木): 35 ← 完了なし
Day 4 (金): 27 ← 8ptのストーリーが完了
Day 5 (月): 27 ← 週末明け
Day 6 (火): 22 ← 5ptのストーリーが完了
Day 7 (水): 17 ← 5ptのストーリーが完了
Day 8 (木): 10 ← 7ptのストーリーが完了
Day 9 (金): 5 ← 5ptのストーリーが完了
Day 10 (月): 0 ← 最後のストーリーが完了
重要: ストーリーが完了の定義を完全に満たした場合のみ「完了」としてカウントします。部分的に完了したストーリーは残作業量に含め続けます。
ステップ4: 実績線をプロットする
記録した値を折れ線グラフとしてプロットします。バーンダウンチャートジェネレーターを使えば即座に可視化できます。スプレッドシートで作成する方法は後述します。
グラフパターンの読み方
バーンダウンチャートには、チームの状態を示す典型的なパターンがあります。このパターンを読み取る力は、スクラムマスターやアジャイルコーチにとって最も価値のあるスキルの1つです。
パターン1: 理想的な進捗
実績線が理想線に沿って、ほぼ直線的に下がっていくパターンです。
ポイント
40 |*
| *·
| ·*
| *·
| ·*
| *·
| ·*
0 |-------*→ 日数
理想線(·) と実績線(*) がほぼ重なる
意味: チームが安定したペースで作業を消化できています。スプリント計画が適切で、ストーリーのサイズも増分的な完了に適しています。
対応: 不要。この状態が目標です。条件を再現できるよう振り返りましょう。
パターン2: 階段状の下降
数日間フラット（横ばい）が続き、突然大きく下がる階段状のパターンです。
ポイント
40 |****
| ·
| ****
| ·
| ***
| *
0 |-------→ 日数
意味: ストーリーの粒度が大きく、完了までに数日かかっています。作業は日々進んでいますが、ストーリー全体が完了するまで「完了」として計上されません。
対策:
- ストーリーを1〜2日で完了できるサイズに分割する
- 水平分割（バックエンド全部→フロントエンド全部）ではなく、垂直分割（薄いエンドツーエンドの機能）を使う
- サブタスクを導入し、より細かい粒度で進捗を可視化する
- 完了の定義が人為的なボトルネックを生んでいないか見直す
パターン3: 前半フラット → 後半急降下
スプリント前半は残作業量がほとんど減らず、後半に一気に消化されるパターンです。
ポイント
40 |*********
| ·
| *
| *
| *
| *
0 |-------→ 日数
意味: スプリント前半で設計や環境構築、技術調査に時間を費やしています。または、完了の定義が厳しく、全てが揃うまで中間成果物が計上されません。
対策:
- スプリント前に技術的な事前調査（スパイク）を完了させる（バックログリファインメントの段階で実施）
- 受け入れ条件を明確にし、出荷可能な増分を部分的に追跡できるようにする
- フロントエンドとバックエンドなど、レイヤーごとにストーリーを分割して増分的な完了を可能にする
- このパターンが持続する場合、スプリント期間がチームのワークフローに対して短すぎる可能性がある
パターン4: 右肩上がり（スコープクリープ）
スプリント中に残作業量が増えるパターンです。
ポイント
40 |*
| *
| **
| ***
| **** ← 増加
|
0 |-------→ 日数
意味: スプリント中にスコープが追加されているか、見積もりが楽観的すぎて隠れた複雑さが発見されています。
対策:
- スプリント中のスコープ変更を制限する（事前にプロダクトオーナーと合意）
- 追加要件はプロダクトバックログに記録し、次のスプリントに回す
- 見積もりが膨らむ場合は、黙って吸収するのではなく即座にフラグを立てる
- レトロスペクティブで実績を振り返り、見積もり精度を改善する
パターン5: 最終日に大量の残作業
スプリント最終日になっても大量のポイントが残っているパターンです。
ポイント
40 |*
| ·*
| ·*
| ·*
| ·*
| ·*
20 | ·* ← 最終日に20pt残
0 |-------→ 日数
意味: チームの実際のキャパシティを超えた計画になっています。過去のベロシティを超える量のストーリーをコミットしています。
対策:
- 過去3〜5スプリントの平均ベロシティに基づいてスプリント容量を決める（ベロシティ計算ツールで計算できます）
- 計画外の作業や割り込みに備えて、平均ベロシティの80%程度を目安にする
- ベロシティの推移を追跡し、低下傾向がある場合は根本原因（技術的負債、チーム変更、要件の不明確さ）を調査する
スプリントバーンダウン vs リリースバーンダウン
バーンダウンチャートには、異なる計画の視野に対応する2つの種類があります。
スプリントバーンダウン
- 対象範囲: 単一のスプリント（1〜4週間）
- 縦軸: スプリント内の残ストーリーポイントまたはタスク数
- 更新頻度: 毎日
- 主な対象者: 開発チームとスクラムマスター
- 目的: スプリントゴールが達成可能かを確認する
リリースバーンダウン
- 対象範囲: リリース全体またはプロジェクト（複数スプリント）
- 縦軸: リリースバックログの残ストーリーポイント合計
- 更新頻度: 各スプリント終了時
- 主な対象者: プロダクトオーナーとステークホルダー
- 目的: リリースがいつ完了するかを予測する
リリースバーンダウンは「現在のペースで、全ての計画機能はいつ完成するか」という問いに答えるのに役立ちます。スプリントではなく締め切りで考えるステークホルダーへの進捗報告に特に有用です。
重要な違い: スプリントバーンダウンはスプリント終了時に0に向かうべきです。リリースバーンダウンは複数スプリントを通じて0に向かい、チームのベロシティが安定したりスコープが変更されたりすると傾きが変わります。
バーンダウンチャート vs バーンアップチャート
「バーンダウンとバーンアップ、どちらを使うべきか」は頻出の質問です。答えは、プロジェクト中のスコープ変更の頻度によります。
バーンダウンチャート
- 残作業量を追跡する（高い値から始まり、0に向かう）
- シンプルで直感的
- 制限: 残作業量が減った時、タスクが完了したのか削除されたのか区別できない
バーンアップチャート
- 完了済み作業量を1本の線で、総スコープをもう1本の線で追跡する
- 2本の線: スコープ線（総作業量）と完了線（完了済み作業量）
- 利点: スコープの変更が見える。スコープ線が上がれば、新しい作業が追加されたことが一目でわかる
使い分けの基準
| 状況 | 推奨チャート |
|---|---|
| スコープが安定したスプリント（途中変更なし） | バーンダウン |
| スコープ変更が頻繁 | バーンアップ |
| アジャイルに不慣れなステークホルダーへの報告 | バーンダウン（シンプル） |
| 要件が変化するリリースレベルの追跡 | バーンアップ |
| デイリースクラムでの議論 | どちらでも可 |
実用的なヒント: 多くのチームが、スプリントバーンダウン（シンプル、毎日更新）とリリースバーンアップ（スコープ変更を捕捉）を併用しています。2つのチャートは互いを補完します。
スプレッドシートでの作成方法
専用ツールがなくても、スプレッドシート（Google スプレッドシート、Excel）で簡単に作成できます。
データテーブルの構成
4列のテーブルを設定します。
| 日付 | 営業日 | 理想残 | 実績残 |
|---|---|---|---|
| 3/9 | Day 0 | 40 | 40 |
| 3/10 | Day 1 | 36 | 40 |
| 3/11 | Day 2 | 32 | 35 |
| 3/12 | Day 3 | 28 | 35 |
| 3/13 | Day 4 | 24 | 27 |
| 3/16 | Day 5 | 20 | 27 |
| 3/17 | Day 6 | 16 | 22 |
| 3/18 | Day 7 | 12 | 17 |
| 3/19 | Day 8 | 8 | 10 |
| 3/20 | Day 9 | 4 | 5 |
| 3/21 | Day 10 | 0 | 0 |
計算式
理想残列には以下の計算式を使用します（セルB1に総ポイント、B2に営業日数がある場合）:
理想残 = 総ポイント - (総ポイント / 営業日数) × 日番号
Google スプレッドシート: =$B$1 - ($B$1 / $B$2) * A3（A3が日番号のセル）
グラフ化の手順
- 「営業日」「理想残」「実績残」の列を選択する
- 折れ線グラフを挿入する
- 理想線を点線、実績線を実線で表示する
- 縦軸の最小値を0、最大値を総ポイントに固定する
- グラフタイトルを追加する:「スプリントバーンダウン - Sprint [番号]」
- 必要に応じて実績線にデータラベルを表示する
スプレッドシートの設定をスキップしたい場合: バーンダウンチャートジェネレーターを使えば、スプリントデータを入力するだけで即座にチャートを作成・ダウンロードできます。
主要ツールでのバーンダウンチャート
Jira
Jiraはスクラムボードにバーンダウンチャートを標準搭載しています。ボードからレポート→バーンダウンチャートを選択します。ストーリーポイントフィールドとスプリント割り当てに基づいて残作業量が自動計算されます。
設定のポイント:
- スプリント開始前に全ストーリーにストーリーポイントの見積もりを設定する
- タスクレベルの追跡には「残りの見積もり」フィールドを使用する
- ストーリーが「完了」に移動すると、Jiraのバーンダウンがリアルタイムで更新される
Azure DevOps
Azure DevOpsのAnalyticsビューにスプリントバーンダウンウィジェットが含まれています。チームダッシュボードに追加し、ストーリーポイント、タスク、または残り時間で追跡するよう設定します。
Trello（Power-Up使用）
Trelloにはネイティブのバーンダウンチャートはありませんが、CorrelloやBurndown for TrelloなどのPower-Upがカード完了の追跡によりこの機能を追加します。
無料オンラインツール
専用のプロジェクト管理ツールを使っていないチームには、バーンダウンチャートジェネレーターで数秒でバーンダウンチャートを作成・ダウンロードできます。スプリント日程、総ポイント、日次実績を入力するだけで即座にグラフが可視化されます。
デイリースクラムでの活用
バーンダウンチャートは、デイリースクラム中に見える場所に表示すべきです。共有スクリーンやTVダッシュボードに表示し、チームが進捗を議論しながら参照できるようにします。
チャートを見ながら確認すること
- 実績線 vs 理想線: 実績線が理想線より上なら、遅延の原因を議論する。ブロッカーか？見積もりより大きいストーリーか？
- 長期間のフラット: 2日以上のフラットはブロッカーか、増分的に完了できないほど大きなストーリーの兆候
- 急激な低下: 大きなストーリーの完了を示す。完了の定義を満たしているか確認
- 上昇: スコープクリープの兆候。即座に対処が必要
チャート使用のグラウンドルール
- チャートはチームの健康診断であり、個人のパフォーマンス指標ではない
- 遅れている場合は「何ができるか」を議論し、「誰が悪いか」を議論しない
- チャートの更新はチーム全体の責任とする（1人に任せない）
- チャートを使って品質を犠牲にさせるプレッシャーをかけることは絶対に避ける
よくある失敗と対策
失敗1: チャートの更新が不定期
数日おきにしか更新しない、または完全に忘れてしまうケース。チャートの信頼性が失われ、目的を果たせなくなります。
対策: 更新の具体的なタイミングを決める（例:「デイリースクラムの直前」）。プロジェクト管理ツールを使っている場合は自動更新を活用する。
失敗2: ストーリーポイントの代わりに時間を追跡する
残り時間の追跡はマイクロマネジメントにつながりやすく、知識労働の非線形な性質を反映しません。
対策: ストーリーレベルではストーリーポイントを追跡する。時間レベルの追跡が必要な場合は、ストーリー内のタスクに限定し、バーンダウンの主要メトリクスにはしない。
失敗3: チームキャパシティの変動を考慮しない
メンバーが休暇や本番障害対応で離脱した場合、チームの実効キャパシティは低下します。バーンダウンがこれを反映しないと、理想線が非現実的になります。
対策: スプリント計画時にスプリントカレンダーを使って、祝日・休暇・予定された不在を考慮してコミットポイントを調整する。
失敗4: チャートが問題を示しているのに無視する
チャートを毎日更新するものの、実際には議論や対処をしないケース。バーンダウンが形式的な儀式になってしまいます。
対策: バーンダウンをスタンドアップの議論の中心に据える。ギャップが広がっているとチャートが示したら、「後で対処する」のではなく即座の問題解決のきっかけとして扱う。
失敗5: チーム間でバーンダウンチャートを比較する
バーンダウンチャートは単一チームの自分自身の計画に対する進捗を反映します。異なるコンテキスト、キャパシティ、ストーリーサイジングを持つチーム間のバーンダウンチャートを比較するのは誤解を招きます。
対策: バーンダウンチャートはチーム内の改善に使う。チーム横断の報告には、ベロシティ推移やデリバリー予測可能性などの正規化されたメトリクスを使用する。
バーンダウンチャートの限界
バーンダウンチャートは有用ですが、チームが理解しておくべき本質的な限界があります。
スコープ変更が見えにくい
残作業量の推移だけでは、「タスクが完了して減った」のか「スコープが削除されて減った」のかが区別できません。同様に、スコープの追加は上向きのバンプとしてのみ見え、新しい作業と再見積もりを区別できません。スコープ変更が頻繁なプロジェクトでは、スコープと完了を別々に追跡するバーンアップチャートの併用を検討してください。
品質を反映しない
チャートが順調に下がっていても、品質が低いコードで「完了」としている可能性があります。品質ゲートを含む明確な**完了の定義（Definition of Done）**と常にセットで運用することが重要です。
進捗の「なぜ」は分からない
チャートは何が起きているか（先行、遅延、予定通り）を示しますが、なぜ起きているかは示しません。チャートが問題を示したら、チームは対話を通じて根本原因を特定する必要があります。チャートは議論の出発点であり、議論の代わりではありません。
個人の貢献は見えない
バーンダウンチャートはチームレベルの進捗のみを示します。誰が何を完了したかは意図的に表示しません。これはバグではなく機能です。チーム全体での所有権を強化します。個人の追跡が必要な場合は、別のツールを使い、バーンダウンとは分離してください。
よくある質問
バーンダウンチャートとベロシティチャートの違いは？
バーンダウンチャートは単一のスプリント内の残作業量を追跡し、「このスプリントは予定通りに完了するか？」に答えます。ベロシティチャートは複数スプリントにわたる完了ストーリーポイントの合計を追跡し、「このチームは通常1スプリントでどれくらいの作業を完了するか？」に答えます。両方を使いましょう。バーンダウンは日々のスプリント管理に、ベロシティは長期計画に。チームのベロシティはベロシティ計算ツールで計算できます。
スプリント中にストーリーが追加された場合はどうする？
ストーリーが追加されると、残作業量の合計が増加し、バーンダウンの実績線が上に動きます。これは正しい動作です。スコープ変更を可視化するためです。チャートが誤解を招かないよう、スプリント中の追加を最小限にするポリシーを設けましょう。追加が避けられない場合は、同量の未着手の作業を削除することを検討してください。
バーンダウンチャートはストーリーポイント、タスク、時間のどれで追跡すべき？
ストーリーポイントが最も一般的です。作業の相対的なサイズを表し、特定の期間を暗示しないためです。タスク数はストーリーポイントを使わないが、小さく一貫したサイズの作業に分割するチームに適しています。時間は最も推奨されません。マイクロマネジメントを助長し、正確な見積もりが困難だからです。スプリント計画で既に使っている単位を選んでください。
バーンダウンチャートが常に階段状になるのはなぜ？
階段状パターンが持続する場合、ストーリーが常に日次完了には大きすぎることを意味します。対策はストーリー分割の改善です。1〜2日で完了できるストーリーを目指しましょう。垂直分割（薄いエンドツーエンド機能）や受け入れ条件による分割を使って、独立して完了可能な小さな単位を作ります。
リモートチームでのバーンダウンチャートの読み方は？
チャートの読み方はチームが同じ場所にいてもリモートでも同じです。重要な違いは可視性です。ログインが必要なツールの中に隠すのではなく、共有のデジタルダッシュボードに表示しましょう。リモートスタンドアップでは画面共有でチャートを見せ、簡単にウォークスルーします。SlackやTeamsチャンネルへの自動日次更新送信も有効です。
カンバンチームでもバーンダウンチャートを使える？
従来のバーンダウンチャートは、固定スコープのタイムボックス制スプリント向けに設計されています。カンバンでは作業が継続的でスコープが流動的なため、**累積フローダイアグラム（CFD）**の方が通常適しています。ただし、カンバンチームがWIP制限を設け、定期的なデリバリー目標に向かって作業している場合は、修正版バーンダウンチャートも有用です。
バーンダウンチャートの適切な更新頻度は？
毎日が標準であり推奨される頻度です。頻度を下げる（例: 2〜3日ごと）と、問題を早期に発見するというチャートの主目的が損なわれます。毎日の更新が負担に感じる場合は、頻度を減らすのではなく、プロジェクト管理ツールによる自動化を活用してください。
まとめ
バーンダウンチャートは、アジャイルプロジェクト管理における最もシンプルかつ効果的なツールの1つです。残作業量を時間に対してプロットすることで、チーム全員（そして外部の関係者）にスプリントの進捗を即座に明確にします。理想線がベンチマークを設定し、実績線が真実を語り、その間のギャップがアクションを促します。
5つの典型パターンを読み取れるようになりましょう。順調な下降（健全）、階段状（ストーリーが大きすぎる）、前半フラットの後半急降下（事前調査が必要）、スコープクリープ（右肩上がり）、過剰コミット（最終日に大量の残作業）。各パターンは具体的な改善アクションを示しています。
スプリントレベルの追跡にはバーンダウンチャートを。スコープが変化するプロジェクトにはバーンアップチャートを併用してください。スプレッドシート、Jira、あるいは無料のバーンダウンチャートジェネレーターのいずれで作成するにしても、鍵は一貫性です。毎日更新し、スタンドアップで議論し、チーム改善の触媒として使う。決して責任追及のツールにはしないでください。