バーンダウンチャートとは？作り方・読み方・活用法を徹底解説
バーンダウンチャートとは
バーンダウンチャートは、スプリント期間中の残作業量の推移を可視化するグラフです。横軸に時間（日数）、縦軸に残りの作業量（ストーリーポイントやタスク数）を取り、スプリント開始から終了までの進捗を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つのチャートは互いを補完します。
スプリントバーンダウン以外のバーンダウンチャートの種類
スプリントバーンダウンが最も一般的な形式ですが、チームによっては状況に応じた専用のバーンダウンビューが必要になることもあります。
個人（担当者別）バーンダウンチャート
個人バーンダウンチャート（担当者別バーンダウンチャートやパーソナルバーンダウンチャートとも呼ばれます）は、スプリント内で特定のチームメンバー1人に割り当てられた残作業量を追跡します。標準的なスクラムのアーティファクトではありません——スクラムは意図的に個人ではなくチームの進捗を追跡するためです——が、特定の状況では有用な場合があります。
担当者別バーンダウンチャートを使うべき場面:
- チームメンバーがスプリント内でほぼ独立した作業ストリームを担当している
- オンボーディング中、新メンバーが自分のペースを可視化する助けにする
- 自己評価や個人の生産性トラッキングのため（マネジメントから強制されるものであってはならない）
- 1人の担当者がチーム目標とは別に固定スコープのコミットメントを持っている場合
仕組み:
このチャートは、1人に割り当てられたストーリーポイントまたはタスクのみをプロットし、理想線はその人の稼働可能時間（会議や非常勤配分などを考慮）に基づいて引かれます。
個人バーンダウン - Alice（スプリント7）
ポイント
12 |*
| ·*
| ·*
| ·**
| · *
| · *
0 |------·--*→ 日数
重要な注意: 個人バーンダウンチャートを、成果評価やチームメンバー間の比較に使用しては絶対にいけません。これはスクラムを機能させる協働の文化を損ないます。このチャートは個人の計画ツールであり、マネジメント向けの報告ツールではありません。
クロスチームバーンダウンチャート
クロスチームバーンダウンチャートは、共通の目標（プロダクトリリースや大規模なイニシアチブなど）に向けて作業する複数のチームの残作業量を集計します。プログラムまたはポートフォリオレベルで使用されます。
使うべき場面:
- 複数のスクラムチームが同じリリースやエピックに貢献している
- プログラムマネージャーが、個々のチームのスプリントに深入りせずに全体進捗を把握する必要がある
- SAFe環境でのPI（プログラムインクリメント）計画
仕組み:
参加する全チームの残ストーリーポイントを合計し、リリースのタイムラインに対してプロットします。各チームのベロシティが全体の消化ペースに寄与します。
クロスチームバーンダウン - Q2リリース
ポイント
200 |*
| ·*
| ·*
| ·**
| · *
| · **
0 |------·----*→ スプリント（1〜6）
チーム: Alpha（ベロシティ: 40）, Beta（ベロシティ: 35）, Gamma（ベロシティ: 45）
合計ベロシティ: 約120ポイント/スプリント
重要な留意点:
- 集計前にチーム間でストーリーポイントを正規化する（チームによって見積もりの基準が異なる場合があるため）
- リリースレベルでのスコープ変更はよくあることです——スコープ変更を明示するクロスチームバーンアップチャートやリリースバーンアップチャートの併用を検討してください（例は本ガイド後半の「レベル別バーンアップチャート例」で紹介します）
- 複数チームによるプログラムでは、エピックの追加・スコープ削減・再見積もりのタイミングが可視化されるため、通常クロスチームバーンダウンよりクロスチームバーンアップの方が好まれます
- 毎日ではなく、各スプリント終了時にチャートを更新する
カンバンバーンダウンチャート
従来のバーンダウンチャートは、タイムボックス制のスプリント向けに設計されています。カンバンでは作業が継続的で、スプリントの境界がありません。しかし、カンバンチームが納期目標や**サービスレベル期待値（Service Level Expectations, SLE）**を設定している場合、修正版のバーンダウンチャートが依然として有用です。
使うべき場面:
- カンバンチームが、特定の項目群を目標日までに納品することにコミットしている
- カンバンで運用するチームが、四半期の目標やマイルストーンに向けた進捗を追跡したい
- カンバンフローで管理される固定スコープのプロジェクト中
仕組み:
スプリントの代わりに、X軸は目標日までのカレンダー期間を表します。Y軸はコミットメント内の残アイテム数（またはストーリーポイント）を示します。理想線は、開始時の総数から目標日の0まで引かれます。
カンバンバーンダウン - 3月納期目標
アイテム数
15 |*
| ·*
| ·**
| · *
| · **
| · *
0 |------·---*→ 週（1〜4）
カンバンの代替案: 多くのカンバン実践者は、バーンダウンチャートよりも**累積フローダイアグラム（CFD）**を好みます。CFDはWIP制限・リードタイム・スループットを同時に可視化できるためです。チームが定期的な納期目標を設定していない場合は、CFDの方が適している可能性が高いです。
レベル別バーンアップチャート例（リリース・カンバン・イニシアチブ・クロスチーム）
バーンアップチャートの構成は、計画のレベルによって適した形が異なります。以下では、チームが実際に使う4種類の代表的なバーンアップチャート例と、それぞれの使用場面を紹介します。
リリースバーンアップチャート例
リリースバーンアップチャートは、リリース全体（通常3〜6ヶ月、または4〜8スプリント）にまたがるもので、アジャイルプログラムの中で最も一般的なバーンアップチャートです。「このリリースはいつ完成するか、開始時からスコープはどれだけ変化したか」という問いに答えます。
リリースバーンアップ — 2026年Q2（6スプリント）
ストーリーポイント
200 | ----- スコープ線（S3後に180 → 200）
| -----
180 |-----
| * ← ここでスコープ追加が確認できる
160 | *
| * * ← 完了線
120 | *
| *
40 |*
0 |————————————————————————————→ スプリント（1〜6）
S1 S2 S3 S4 S5 S6
- スコープ線: リリースのコミット済み総ストーリーポイント。バックログが変わるたびに更新
- 完了線: 累積完了ストーリーポイント。各スプリント終了時に更新
- 重要な気づき: スプリント3でスコープ線が上昇した場合、リリースバーンダウンチャートでは同じ動きが曖昧にしか示されません。リリースバーンアップチャートなら、チームの減速ではなく新規作業が追加されたことが明確にわかります。
リリースバーンアップチャートを使うべき場面:
- 複数スプリントにわたってスコープが変化する長期リリース
- 「作業を追加していないか？」がよく聞かれるステークホルダー向け報告
- ベロシティの推移と残スコープに基づくリリース日の予測
- シンプルなリリースバーンダウンではスコープクリープが隠れてしまうリリース全般
リリースバーンアップチャートを手早く作成するには、バーンダウンチャート生成のデータモデルを拡張し、スプレッドシート上で累積完了ポイントと別建てのスコープ線をプロットする方法があります。
カンバンバーンアップチャート例
カンバンチームにはスプリントがありませんが、目標日までに一定量のアイテムを納品するとコミットしている場合、バーンアップチャートは依然として有用です。例えば、四半期ロードマップのコミットメント、顧客向けローンチ、コンプライアンス期限などです。
カンバンバーンアップ — 3月ローンチ（4週間）
アイテム数
30 | ----- スコープ線（W2後に25 → 30）
| -----
25 |-----
| * ← 完了線
20 |
| *
15 | *
| *
10 | *
| *
5 | *
0 |—————————————————————→ 週（1〜4）
W1 W2 W3 W4
- X軸: スプリントの代わりにカレンダー週（サイクルが短いチームでは日単位の場合も）
- スコープ線: ローンチにコミットしたアイテム数（またはストーリーポイント）。要件が固まるにつれて調整
- 完了線: カンバンボードで「完了」列に移動したアイテム
- CFDとの併用: カンバンチームは、このバーンアップを**累積フローダイアグラム（CFD）**と並べて表示し、WIP制限とリードタイムも同時に確認することがよくあります。
カンバンバーンアップチャートを使うべき場面:
- 厳密な締め切りがある固定スコープのローンチ
- 「残りどれくらいか」を可視化したいステークホルダーがいる顧客向けコミットメント
- スプリントを使わないチームがリリース日に向けたマイルストーン進捗を追跡する場合
- バーンアップチャートに不慣れで、リリースやイニシアチブレベルのバーンアップに進む前にシンプルな入門として使いたいチーム
カンバンチームが日付のコミットメントをしていない場合は、通常は累積フローダイアグラム単体で十分であり、バーンアップチャートは不要です。
イニシアチブバーンアップチャート例
イニシアチブバーンアップチャートは、複数のリリースと複数のチームにまたがる横断的なイニシアチブを追跡します。例えば、プラットフォーム移行、コンプライアンス対応、大規模なSDKアップグレード、戦略的OKRなどです。個々のリリースバーンアップより上位の、ポートフォリオまたはプログラムレベルで運用されます。
イニシアチブバーンアップ — プラットフォーム移行（6ヶ月）
ストーリーポイント
500 | ----- スコープ線（安定）
|--------------------------
400 | *
|
300 | *
| *
200 | * ← 完了線
| *
100 | *
| *
0 |—————————————————————————————→ 月（1〜6）
M1 M2 M3 M4 M5 M6
- 時間単位: スプリントの代わりに月またはプログラムインクリメント（PI）
- スコープ線: イニシアチブの総見積もり工数。ディスカバリー作業で隠れた複雑さが判明するにつれて変化することがある
- 完了線: 参加する全チームの累積完了ストーリーポイント
- 重要な気づき: スコープ線がほぼ横ばいのまま完了線が着実に上昇していれば、イニシアチブは健全な状態です。両者のギャップが広がる、または完了線が横ばいになる場合は、イニシアチブが停滞し経営層の注意が必要なことを示します。
イニシアチブバーンアップチャートを使うべき場面:
- 経営層への可視性が求められる戦略的プログラム（四半期ビジネスレビュー、取締役会向け報告）
- 個々のスプリントバーンダウンでは粒度が細かすぎる、複数チームの調整
- 「進捗率」をデータで裏付ける必要があるOKRや戦略目標の追跡
- 2四半期以上続く移行・モダナイゼーションプロジェクト
イニシアチブバーンアップチャートは、プログラムマネージャーが維持する成果物の中で最上位に位置することが多いです。通常は毎週ではなく、月次またはPIの区切りごとに更新します。
クロスチームバーンアップチャート例
複数のスクラムチームが共通のリリースやプログラムに貢献する場合、クロスチームバーンアップチャートはそれぞれの進捗を集計し、プログラム全体にわたるスコープ変更を可視化します。SAFeのプログラムインクリメント（PI）計画や、単一のクロスチームバーンダウンではスコープクリープが隠れてしまうような複数チームによるリリースで特によく使われます。
クロスチームバーンアップ — PI 2026-Q2（3チーム、6スプリント）
ストーリーポイント
360 | ----- スコープ線（320 → 360）
| --------
320 |--------
|
240 | * ← 完了線
| *
160 | *
| *
80 | *
| *
0 |———————————————————————————————→ スプリント（1〜6）
S1 S2 S3 S4 S5 S6
参加チーム:
Alpha（ベロシティ 約40pt）+ Beta（約35pt）+ Gamma（約45pt）
合計ベロシティ: 約120ポイント/スプリント
- 集計方法: 参加する全チームのコミット済みスコープと完了ポイントの合計
- スコープ線: PIのコミット済み総作業量。PI計画や検査イベントの際に調整
- 完了線: Alpha・Beta・Gammaチームの完了ポイントの合算
- ストーリーポイント正規化の注意点: 各チームの「3ポイント」は、異なる作業量を表している場合があります。集計前に正規化（例えば共通の基準ストーリーに変換）しないと、合算された数値が誤解を招きます。
クロスチームバーンアップチャートを使うべき場面:
- SAFeのPI追跡とプログラムレベルのリリース管理
- 同じリリースやエピックに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、あるいは無料のバーンダウンチャート生成のいずれで作成するにしても、鍵は一貫性です。毎日更新し、スタンドアップで議論し、チーム改善の触媒として使う。決して責任追及のツールにはしないでください。