フレームワーク活用ガイドひとことで言うと#
完了した作業量と総作業量（スコープ）の2本の線を時系列でプロットするグラフ。バーンダウンチャートでは見えない「スコープが増えたのか、進捗が遅れたのか」を区別でき、スコープクリープの影響と実際の進捗を同時に把握できる。
押さえておきたい用語#
- 完了線（Work Done Line）
- 累積の完了作業量を表す右肩上がりの線。ストーリーポイント、タスク数、機能数などで計測する。
- スコープ線（Total Scope Line）
- プロジェクト全体の総作業量を表す線。スコープが変わらなければ水平だが、追加があれば右肩上がりになる。
- スコープクリープ（Scope Creep）
- プロジェクト進行中に要件や機能が少しずつ追加され、総作業量が膨らむ現象。バーンアップチャートではスコープ線の上昇として明確に可視化される。
- 予測線（Forecast Line）
- 過去のベロシティを延長して描く将来の完了予測。完了線とスコープ線が交差する点がリリース予測日になる。
バーンアップチャートの全体像#
こんな悩みに効く#
- バーンダウンチャートで「残作業が減っていない」とき、スコープが増えたのか進捗が遅れたのか区別できない
- スコープ変更が頻繁に起き、リリース予測日がまったく信用できない
- ステークホルダーに「あとどれくらいで終わるか」を根拠をもって説明できない
- スコープクリープの影響を定量的に示し、スコープ凍結の交渉材料がほしい
基本の使い方#
プロジェクト開始時にバックログの全アイテムを見積もり、合計をスコープ線の初期値にする。
- ストーリーポイント、タスク数、機能数など計測単位はチームで統一する
- 見積もりが粗い段階でもOK。精度はスプリントごとに改善される
- スコープ線は「計画時点の約束」ではなく「現時点の全体像」を表す
各スプリント終了時に、完了量（累積）とスコープ総量を記録し、グラフにプロットする。
- 完了線: 前スプリントまでの累積 + 今スプリントの完了量
- スコープ線: 前回のスコープ + 今スプリントで追加されたアイテム − 削除されたアイテム
- 記録に5分以上かからないよう、JiraやNotionから自動集計する仕組みを作ると継続しやすい
直近3〜5スプリントのベロシティ平均を使い、完了線を延長する。
- 完了線の延長がスコープ線と交差する点が予測リリース日
- スコープ線も上昇トレンドなら、スコープの延長線も引いて「追いつかないシナリオ」を可視化する
- 楽観（最高ベロシティ）と悲観（最低ベロシティ）の2本を引くと幅のある予測が出せる
グラフのパターンから具体的なアクションを導く。
- 完了線がスコープ線に近づいている: 順調。現行ペースを維持
- 2本の線が平行に進んでいる: 追加と消化が均衡。このままではリリースできないのでスコープ凍結を検討
- スコープ線が急上昇: スコープクリープ。追加の優先度を見直し、低優先度のアイテムをバックログの外に出す
- 完了線の傾きが鈍化: ベロシティ低下。ブロッカーの特定と解消に集中する
具体例#
7名のスクラムチームがECサイトのリニューアルを進めていた。当初のスコープは180SP、ベロシティは平均30SP/スプリントで、6スプリント（12週）でのリリースを計画。
スプリント3終了時点のバーンアップチャート:
| スプリント | 完了（累積） | スコープ |
|---|---|---|
| S1 | 28 | 180 |
| S2 | 60 | 195 |
| S3 | 88 | 220 |
完了線は順調だが、スコープ線がS1から40SP増加していた。POに「3スプリントで40SP追加されています。このペースだとリリースはS8（16週）になります」とチャートを見せた。
POは「追加した機能はどれも重要」と主張したが、チャートで「完了線の傾きとスコープ線の傾きが平行に近い」ことを示し、「スコープを凍結するか、リリース日を延期するか、どちらかの判断が必要です」と伝えた。
結果、POが低優先度の30SP分をフェーズ2に移動。リリースはS7（14週）で完了し、当初計画から2週間の遅延で収まった。チャートがなければ「なんとなくギリギリ」のまま突き進んでいた。
社内基幹システムの移行プロジェクトで、経営層から毎月「いつ終わるのか」と聞かれていた。PMが口頭で「あと3か月くらい」と答えるたびに、翌月も「あと3か月」が続き、信頼を失っていた。
バーンアップチャートを導入し、月次報告にグラフを添付する形に変更。
報告内容（S6時点）:
- 完了線: 126SP（S1-S6の累積）
- スコープ線: 240SP（当初200SP + 追加40SP）
- ベロシティ平均: 21SP/スプリント
- 予測完了: S11.4（楽観S10、悲観S13）
経営層は「スコープが200から240に増えたこと」をグラフで初めて理解し、「追加分を削れば予定通りに戻るのか」という建設的な議論に転換した。
3回の月次報告でバーンアップチャートを使った結果、経営層からの問い合わせ頻度が月5回 → 月1回に減少。「グラフを見ればわかる」という信頼が生まれた。
Web制作会社がクライアント向けに150万円固定の小規模開発案件を受注した。契約時のスコープは60SP。しかし開発中にクライアントから機能追加が相次いだ。
バーンアップチャートを共有ドキュメントで更新し、クライアントと毎週確認する運用にしていた。
S4終了時点:
- 完了: 38SP
- スコープ: 85SP（当初60SP + 追加25SP）
- ベロシティ: 10SP/スプリント
- 当初見込み: S6完了 → 現在見込み: S8.5完了
チャートを見せながら「追加された25SPは当初契約の42%に相当します。このまま進めると2.5スプリント分の追加工数が発生し、約65万円の追加費用が必要です」と説明した。
クライアントは3つの選択肢から判断できた:
- 追加費用を支払って全機能を実装（65万円追加）
- 追加機能の一部をフェーズ2に回す（追加費用20万円）
- 元のスコープに戻す（追加費用なし）
クライアントは選択肢2を選び、チャートのおかげで「言った言わない」の紛争を回避できた。受注後のスコープ変更トラブルが年間4件 → 0件に減少した。
やりがちな失敗パターン#
- 完了線だけ描いてスコープ線を省略する — それはただの累積フローグラフであり、バーンアップチャートの最大の利点である「スコープ変更の可視化」が失われる
- ベロシティを最高値で予測する — 楽観的な予測線はステークホルダーに誤った期待を与える。悲観・楽観の幅を持たせるか、直近3スプリントの平均を使う
- スコープ変更を記録せずに総量を書き換える — スコープ線が「突然動いた」ように見えると、いつ何が追加されたかが追えない。変更履歴を添える
- チャートを更新する人が一人だけ — 属人化すると更新が止まる。Jiraなどのツールから自動生成する仕組みを構築する
まとめ#
バーンアップチャートは、完了量とスコープ総量の2本の線で「どれだけ進んだか」と「ゴールがどれだけ動いたか」を同時に可視化するツールである。バーンダウンチャートでは区別できない「進捗の遅れ」と「スコープの膨張」を分離できるのが最大の強みであり、ステークホルダーとの交渉材料として極めて有効。大切なのはスコープ線の変動を隠さず見せることで、追加と削減の判断を全員で行える透明性がプロジェクトの健全性を支える。