フレームワーク活用ガイドひとことで言うと#
横軸に日数、縦軸に残作業量を取り、理想線と実績線の比較でスプリントの進捗を一目で把握するグラフ。残作業が「燃え尽きる（バーンダウンする）」ように右下がりになるのが理想。
押さえておきたい用語#
- 理想線（Ideal Line）
- スプリント開始時の残作業量からゼロまで均等に減少する直線のこと。「この通りに進めば期日通りに完了する」という基準として使う。
- 実績線（Actual Line）
- 実際の残作業量の推移を日々プロットした折れ線を指す。理想線との乖離でスプリントの健全性を読み取る。
- ブロッカー（Blocker）
- 作業の進行を完全に止めてしまう障害や依存関係のこと。バーンダウンチャートが平坦になる主な原因。
- スコープクリープ（Scope Creep）
- スプリント中に作業が予定外に追加される現象。バーンダウンチャートが上方に跳ね上がるパターンとして現れる。
バーンダウンチャートの全体像#
こんな悩みに効く#
- スプリントの途中で進捗が遅れているのか順調なのかわからない
- 「進捗80%」と言われてもピンとこない
- チーム全体で進捗を直感的に共有したい
基本の使い方#
横軸と縦軸を定義する。
- 横軸: スプリントの日数（例：Day 1〜Day 10）
- 縦軸: 残作業量（ストーリーポイント、タスク数、または時間）
- スプリント開始時点の合計作業量を左上の起点にする
ポイント: 単位はチームで統一する。ストーリーポイントが最もポピュラー。
「毎日均等に作業が消化されたら」という理想線を直線で引く。
- 起点（初日の残作業量）から終点（最終日のゼロ）を直線で結ぶ
- この線は「この通りに進めば期日通りに完了する」という基準線
ポイント: 理想線は**「ガイドライン」であって「必ず沿うべき線」ではない**。参考として使う。
デイリースタンドアップのタイミングで、残作業量をプロットする。
- 完了したアイテムのポイントを差し引いた残りを記録する
- 実績線を日々つないでいく
- ツール（Jira, Azure DevOps等）を使えば自動で更新される
ポイント: 手動更新の場合は、担当者と更新タイミングを決めておくこと。
実績線と理想線のギャップからスプリントの状態を読み取る。
- 実績線が理想線の上 → 遅延している。原因を分析して対策を打つ
- 実績線が理想線の下 → 前倒しで進んでいる。追加アイテムの取り込みを検討
- 実績線が平坦 → 作業が完了していない。ブロッカーを確認する
ポイント: 初日から数日は平坦になりがち（作業中で未完了）。中盤以降の傾向が重要。
具体例#
状況: 6名の開発チーム。2週間スプリント（10営業日）で合計30ptのアイテムに取り組む。
実績推移:
| Day | 残pt | 理想pt | 差分 | 状態 |
|---|---|---|---|---|
| 1 | 30 | 27 | +3 | 着手直後で未完了 |
| 3 | 25 | 21 | +4 | やや遅延 |
| 5 | 25 | 15 | +10 | 平坦化（異常） |
| 6 | 20 | 12 | +8 | ブロッカー解消 |
| 8 | 7 | 6 | +1 | 一気にバーンダウン |
| 10 | 0 | 0 | 0 | 完了 |
Day 4-5の平坦化の原因: 外部APIの仕様変更がブロッカーと判明。デイリースタンドアップで検知し、Day 6に代替実装方針を決定。
Day 4の平坦化をDay 4当日に検知できたことで、翌日には対策を打てた。バーンダウンチャートがなければ「なんとなく進んでいる」と思い込んだまま、Day 8頃に「間に合わない」と気づいていたはずだ。毎日5分の更新が2日分のリカバリー時間を生んだ。
状況: 従業員25名のWeb制作会社。ECサイトリニューアル案件（3週間・45タスク）でクライアントへの進捗報告にバーンダウンチャートを活用。
導入の工夫: タスク数ベース（ストーリーポイントではなく完了タスク数）でバーンダウンを運用。クライアントにとって「残り○タスク」の方が直感的にわかりやすいため。
運用結果:
- 第1週末: 45タスク中17完了（理想15）→ 前倒し
- 第2週央: 45タスク中22完了（理想27）→ デザイン修正の差し戻しで遅延
- 第2週末: 危機対応 → デザイナーを1名追加投入
- 第3週末: 全45タスク完了
クライアントへの効果: 毎週のバーンダウンチャート共有により、「進捗が見えない」というクレームがゼロに。第2週の遅延時も「グラフを見ればわかるので、対策をお任せします」と信頼を獲得。
バーンダウンチャートは社内用だけでなく、クライアントとの信頼構築ツールにもなる。「進捗が見えない」というクレームがゼロになったことが何よりの成果だった。
状況: 従業員500名の精密機器メーカー。DX推進室（8名）が初めてスクラムを導入し、社内ワークフローシステムの開発に着手。初スプリント（2週間・35pt）のバーンダウンを追跡。
初スプリントのバーンダウン推移:
- Day 1-3: 残35pt→35pt→34pt → ほぼ動かない
- Day 4: デイリーで「完了の定義が曖昧で、どこまでやれば完了か判断できない」と判明
- Day 5: 完了の定義（DoD）を急遽策定。「レビュー済み・テスト合格・ドキュメント更新」の3条件
- Day 6-10: 残30pt→22pt→15pt→8pt→3pt → 一気にバーンダウン
| 区間 | 1日あたり消化pt | 原因 |
|---|---|---|
| Day 1-4 | 0.25pt | DoDが曖昧で完了判断できず |
| Day 5-10 | 5.4pt | DoD策定後、判断基準が明確化 |
バーンダウンチャートの「動かない」パターンが、完了の定義の不在というプロセスの問題を可視化した。ウォーターフォール時代は「進捗90%」が何週間も続く報告に慣れていたチームが、バーンダウンの正直さにカルチャーショックを受けたのは興味深い対比だ。
やりがちな失敗パターン#
- 途中で作業が追加される — スプリント中にアイテムが追加されると、バーンダウンチャートが上に跳ねる。スプリント中の追加は最小限にし、追加された場合はチャートにも反映する
- 「完了」の基準が曖昧 — テスト未完了でも「完了」にすると、バーンダウンは順調に見えるが実際は未完成。完了の定義（DoD）を厳密に守ること
- チャートを更新しない — 更新が止まると「ただの絵」になる。毎日のデイリースタンドアップとセットで更新するルールにする
- 平坦区間を見て見ぬふりをする — バーンダウンが2日以上平坦なら何かが詰まっている。即座にブロッカーを特定し、解消のアクションを取る
まとめ#
バーンダウンチャートは、残作業量の推移を可視化してスプリントの健全性を一目で把握するシンプルなツール。理想線と実績線の比較で「遅れている」「順調」がひと目でわかる。毎日更新を続け、乖離が見えたらすぐに原因を探ることで、スプリントの成功率が大幅に向上する。