1 バーンダウンの概要
1.1 定義と目的
1.1.1 残作業量の可視化という考え方
バーンダウンは、一定期間の進捗を「残作業量」が時間経過とともにどれだけ減少しているかで表す手法である。ここでいう残作業量は、未完了の作業を何らかの尺度（見積り単位やストーリポイント等）に換算した総量として扱われる。理想的には時間とともに残量が下がり、現実の進み具合が折れ線や推移として読み取れる。
1.1.2 進捗管理と意思決定への活用
進捗の可視化により、計画との差異を早期に把握し、次の意思決定につなげることが狙いとなる。たとえば、残量の減りが鈍い場合は、優先順位の再整理、支援体制の追加、スコープの調整などを検討できる。逆に減りが速い場合は、追加の取り込みを行うか、品質確保を優先して現状維持にするかといった判断材料になる。
1.2 関連概念との違い
1.2.1 ベロシティとの関係
ベロシティは主に「過去の実績から推定される、チームが一定期間に処理できる作業量」を表す指標として用いられる。一方バーンダウンは「期間内における残作業量の減少の経時的推移」に重きを置く。そのため、ベロシティは計画の見積りや予測に使われやすく、バーンダウンは計画との差の発見や調整の判断に向きやすい。
1.2.2 チャートと指標の役割分担
バーンダウンチャートは、残作業量の時系列を示す可視化手段である。指標としての残作業量の定義、更新ルール、目標ラインの置き方といった運用要素が、チャートの意味を左右する。チャートだけを見て判断してしまうと、定義の違いや更新漏れの影響を取り違える恐れがあるため、背景にある測定設計も合わせて理解する必要がある。
1.2.3 バーンアップやカンバンとの対比
バーンアップは「完了した作業量」を累積で示す方式で、バーンダウンとは逆の見せ方になる。カンバンは一般にフロー（滞留、処理速度、WIP制限）を中心に扱い、バーンダウンのように特定期間の残量を基準にした計画線を明示しない場合がある。したがって、アプローチの中心は「期間の残量推移」か「流れの状態」かで異なることが多い。
2 バーンダウンチャートの種類
2.1 スプリント・バーンダウン
2.1.1 個人レベル／チームレベルの扱い
2.1.1.1 見積り単位（ストーリポイント等）と残作業の更新
スプリント単位のバーンダウンでは、残作業量は通常、計画時に配分された見積りの合計から出発し、完了に応じて減少させる。見積り単位としてはストーリポイント、チケット数、理想労働時間などが用いられうる。重要なのは、計測単位と減算の根拠が一貫していること、さらに「完了したとみなす条件」が事前に定められていることである。これにより、更新時のブレが抑えられる。
2.1.2 日次更新の運用
日次更新では、各更新時点で「未完了として残っている作業」を再集計し、その総量を折れ線に反映する。実務では、更新担当が固定される場合と、担当が分散される場合がある。いずれの場合も、残作業の集計手順と反映タイミングを明文化し、更新が止まらない運用設計を行うことが望ましい。更新が欠けると、グラフの形が事実ではなく集計遅延の結果になる。
2.2 リリース・バーンダウン
2.2.1 複数スプリントをまたぐ進捗把握
リリース・バーンダウンは、単一スプリントではなく、リリースまでの複数期間を対象として残作業量の推移を追う。期間が伸びる分、途中の再計画や変更の影響をどう反映するかが重要になる。スプリント単位の学習を積み上げつつ、リリース全体の見通しを把握するために、残量の集計や目標線の再調整が必要になることがある。
2.2.2 長期計画との整合
長期計画との整合では、「リリースの残量」をどの粒度の作業に紐づけるかが焦点になる。たとえば、上位概念（機能やエピック）を単位に換算して残作業量を保持する設計は、計画側の粒度と噛み合いやすい。ただし、上位単位に換算する過程で見積りの意味が薄れると、バーンダウンの判断精度が下がるため、換算の根拠を明示する必要がある。
2.3 プロジェクト・バーンダウン（総残作業）
2.3.1 エピックや機能単位での表現
プロジェクト全体のバーンダウンは、総残作業の推移を捉える目的で利用されることがある。ここでは、細かなタスクではなくエピックや機能などのまとまりで残量を扱う設計が多い。粒度を上げると情報量は減るが、関係者全体で理解しやすい形になりやすい。逆に、粒度が粗すぎると変化の原因が見えにくくなるため、意思決定のために必要な解像度を見極めることが重要である。
2.3.2 スコープ変更時の扱い
スコープが追加・削除される場合、残作業の再計算方法がチャート解釈に直結する。たとえば、新規要素を期中に追加するなら、残量の増加としてグラフに反映するのが基本となる。逆に削除されたものは、残量の減少として扱う。さらに、既存要素の見積りが再評価された場合は、増減の理由が「消化」か「見積りの変更」かを切り分けて記録し、意思決定のための説明責任を果たす必要がある。
3 作成の基本手順
3.1 残作業量の定義
3.1.1 作業の粒度（課題、タスク、ストーリー）
残作業量は、どの単位の作業を合算対象にするかで決まる。課題、タスク、ユーザーストーリーなどの粒度があり、対象を細かくするとより多くの変化が見えるが、更新負荷が増える。粒度を大きくすると運用は軽くなるが、減りの理由が曖昧になりやすい。運用負荷と判断の必要性のバランスで選定することが求められる。
3.1.2 完了条件（定義・品質基準）
残作業量の減算は「完了」に基づく。完了条件は、コード品質、レビュー、テスト、ドキュメント、運用準備など、組織が定める品質基準を含むことがある。完了の定義があいまいだと、グラフが先行して下がるのに実態が追いつかないといった混乱が起きる。逆に、完了が厳格すぎると消化が遅れて見えやすくなるため、目的に応じた現実的な基準設定が必要である。
3.2 目標ライン（理想進捗）の設定
3.2.1 線形進捗と現実の差
理想の目標ラインは、しばしば線形(時間に対して一定の減少)として置かれる。ただし実際の作業は、初期に設計・着手が多く後半に統合・検証が集中しやすいなど、一定速度にならないことが一般的である。そのため、目標ラインは「達成すべき正解」ではなく、差異の大きさを視覚化する基準として扱う姿勢が有効である。
3.2.2 期首時点の基準化
基準化では、期間開始時点での総残量を起点に目標ラインを作る。ここで期中に計画が変わる場合は、目標ラインをどう更新するかも論点となる。目標線を固定するのは、スコープ変化があればその影響も含めて見える化できる利点がある。更新する場合は、差異の意味が変わるため、ルールを明確にすることが欠かせない。
3.3 データの更新頻度と責任範囲
3.3.1 更新担当の明確化
更新担当が曖昧だと、チャートは「気が向いたときに動く」状態になり、信頼性が下がる。責任範囲の明確化では、誰が集計し、誰が完了ステータスを付与し、最終的にチャートを公開するかを定義する。分担する場合でも、手順が重複しないように線引きを行う。
3.3.2 計測の一貫性（見積りや換算のルール）
計測の一貫性は、見積り単位の換算や再評価の扱いに現れる。たとえば、ストーリポイントで計画したものをプロジェクト全体で集計する際に、どの段階でどの比率や換算を用いるかを統一する必要がある。また、見積りの見直しを行うタイミング（期中の変更頻度）もルール化しておくと、グラフの変形が「実行」か「再計算」かを判別しやすくなる。
4 読み解きと判断基準
4.1 よくあるパターン
4.1.1 当初想定より順調に減る場合
残量が目標ラインより速く減る場合、作業の前倒しや論点の少なさが反映されている可能性がある。一方で、完了の基準が緩い、あるいは未完了を残作業から除いてしまっているなど、測定設計の問題もあり得る。判断では、減少の理由が「確実な完了の増加」であるかを裏取りするのが重要である。
4.1.2 減りが鈍化する場合
減少速度が落ちる場合は、調査・依存関係の待ち、品質対応の増加、阻害要因の顕在化などが考えられる。加えて、着手済みだが完了していない中間状態が増えると、残量の見かけは止まりやすい。チームが抱える詰まりを別の情報（阻害カード、待ち時間、テスト合格率等）で補足すると、解釈が精密になる。
4.1.3 完了が遅れて急に減る場合
後半で急に残量が減る形は、レビューや統合、リリース工程など「まとめて完了に至る」流れを示すことがある。これは必ずしも悪いとは限らないが、途中で問題が解消されていないのに後で帳尻合わせしている場合もある。急減が品質やリードタイムの悪化と結びついていないかを確認する必要がある。
4.1.4 増減が激しくブレる場合
残量が上下に大きく振れる場合、スコープ変更が頻繁、あるいは見積りの再評価が多い可能性がある。更新頻度の遅れや、完了ステータスの運用不統一でも、ブレは増幅される。判断の前に、チャート上の変動が「実態の変化」か「集計方法の揺れ」かを切り分けることが望ましい。
4.2 差異の原因分析
4.2.1 見積りの誤差と再計算
見積りは不確実性を含む。差異が出た際に最初に疑うべきは、見積りの当たり外れだけでなく、再計算のルール違反である。見積り更新が頻繁だと、残量の意味が変わるため、実行の進み具合と混同しやすい。差の説明には、「消化量の不足」か「見積り尺度の変更」かを分けて記録する。
4.2.2 スコープの追加・削除の影響
スコープが増えれば残量は増えるし、削除すれば減る。ここで重要なのは、スコープ変更を透明に追跡し、チャートの増減がどの変更によるものかを対応づけることである。変更点が記録されていないと、判断は「いつ」「なぜ」ブレたのか説明できなくなる。
4.2.3 ボトルネック（品質・依存関係・技術負債）
ボトルネックは、品質担保の工程、外部チームや部品への依存、技術負債の清算など多様である。残量が落ちない状態が続くと、タスクの進行が詰まっている可能性が高い。原因分析では、完了に到達するまでに時間を要している工程を洗い出し、対処の種類（支援、順序変更、解消投資）を決める材料にする。
4.3 アクションの決め方
4.3.1 優先度調整と受け入れ可能なトレードオフ
差異が判明したら、優先順位を再設定する。たとえば、価値が高い要素に集中するために、低優先の項目を後ろ倒しする判断があり得る。トレードオフでは、納期、品質、範囲のどれを動かせるのかを合意し、バーンダウン上の調整が「目標達成のための選択」であることを示すのが重要である。
4.3.2 チームの働き方改善（計画の見直し等）
技術的な詰まりがなくても、計画や進め方が要因になる場合がある。たとえば、見積りの粒度が大きすぎて着手状態が見えない、レビュー待ちの導線が弱い、WIPが膨らんで停滞が起きるなどである。チームは、計画の立て方、更新の運用、レビュー・テストのリードタイム改善といった実践を通じて、残量の減少が安定する環境を整える。
5 運用上の注意点
5.1 見積りに依存しすぎない設計
5.1.1 見積り単位の妥当性
見積り単位は、バーンダウンの尺度そのものになるため、妥当性が問われる。ストーリポイントのような相対尺度でもよいが、チーム内で意味づけが揃っていないと、残作業の比較が難しくなる。理想労働時間のような量的尺度は、見積り精度への要求が高い場合がある。いずれにせよ、単位の性格を理解した上で運用することが必要である。
5.1.2 早期に見積りを固定しない工夫
見積りを固定してしまうと、学習による調整機会を失う。とはいえ、再見積りを無制限に行うとチャートが揺れる。工夫として、変更の上限や時点（たとえばスプリント開始後の変更は例外扱い）を定め、必要な場合だけ更新する運用が挙げられる。これにより、計測と学習のバランスを取りやすくなる。
5.2 残作業の計上漏れ・ダブルカウント
5.2.1 完了ステータス運用
計上漏れは、未完了として残すべきものが残量に含まれない状態を指す。逆にダブルカウントは、同じ要素が複数の集計対象に重複して入る状態を指す。完了ステータスの運用では、作業単位とステータス更新の責任を明確にし、完了の判定がチームの共通理解に基づいていることを確保する。
5.2.2 状態遷移の整合性
状態遷移は、未着手から進行、完了へ至る過程を定義する。遷移の定義が崩れると、残量の扱いが場当たりになる。たとえば「レビュー中」は残作業か、「完了」はどのタイミングかといった境界を整合させることが求められる。必要なら、状態マシンや簡潔なガイドを整備して、更新者が迷わない仕組みにする。
5.3 チャートの“見せ方”に関する誤解
5.3.1 進捗をよく見せるための運用禁止
残量を意図的に減らす（実質未完を完了にする、集計から外すなど）行為は、測定の信頼性を壊す。バーンダウンは透明性を前提とするため、「見栄え」の改善は本質的価値につながらない。運用上は、正確性を優先し、差異が出た場合は説明可能な形で扱うことが望ましい。
5.3.2 合意形成のための透明性
チャートは意思決定の材料であり、解釈の前提が共有されている必要がある。残作業の定義、更新時点、目標ラインの扱いがチーム外にも理解可能な形で示されていると、会議での対話が建設的になる。透明性は、数値の正当性と、差異が生じたときの協働による対処を促進する。
6 改善と学習（レトロスペクティブ活用）
6.1 データから学ぶ観点
6.1.1 予測と実績のギャップの要因
レトロスペクティブでは、目標ラインと実績のギャップを分解して捉える。主な論点は、見積りの難しさ、着手開始までの遅延、完了までの品質工程、依存関係による滞留などである。単に「予測が外れた」で終えると学習が薄くなるため、どの工程で差が生まれたかを具体化することが重要である。
6.1.2 再発防止の具体策
再発防止は、次のスプリントの運用に落とし込む形で提案する。たとえば、着手前の調査時間を確保する、レビューの枠を先に押さえる、依存先との連携を早める、完了条件を明文化して誤判定を減らすなどがある。改善策は測定指標（更新の正確性、完了リードタイム、差異の説明率）とセットにして追跡すると効果が見えやすい。
6.2 チャート更新ルールの改善
6.2.1 定義変更の影響評価
定義を変更すると、過去データと比較できなくなる場合がある。そのため、定義変更を行うときは影響範囲を評価し、必要なら期間を区切って扱う。たとえば残作業の対象を広げた場合、グラフの総量が増え、従来の傾向との見かけの差が生まれる。評価により、誤った結論を避けられる。
6.2.2 計測方法の標準化
計測方法の標準化は、担当者が変わっても同じ結果が得られるようにする作業である。集計手順、換算の基準、ステータス判定の境界を文書化し、例を添えると運用のブレが減る。標準化は、バーンダウンが「人の勘」ではなく「チームの合意した測定」になるための基盤となる。
6.3 チーム文化とモチベーション
6.3.1 進捗の共有と安心感の作り方
バーンダウンは不調の指摘に使われがちだが、安心感を作るためにも用いられる。重要なのは、「数値の悪さを責める」より、「状況を早く共有して助け合う」方向に会話を導くことである。差異が出たときに原因を共同で特定し、支援や調整に結びつける運用が、データ利用への心理的安全性を高める。
6.3.2 “残作業を燃やす”発想の健全な運用（冗談としての扱い方）
軽い比喩として「残作業を燃やす」などの表現が用いられることがある。冗談として留めるなら、緊張を和らげつつ行動の合意を促せる。一方で、完了条件の無視や品質の低下を正当化する方向に行くと危険である。健全な運用では、比喩が実態を置き換えないよう、測定の規律と品質の基準を守る前提を共有する。
7 具体例とテンプレート
7.1 スプリントでの典型シナリオ
7.1.1 途中でスコープが増えたケース
スプリント途中で新しい要素が追加されると、残作業量は通常増加する。運用上は、追加した分をいつ、どの作業として計上したかを明記し、目標ラインとの関係を説明する。会議では、「追加したから遅れた」という単純化より、追加分が既存優先度に与えた影響を整理して、次の意思決定（後ろ倒し、優先順位の変更、作業の分割）につなげる。
7.1.2 途中でリファクタリングが発生したケース
リファクタリングは価値の可視化が難しいため、残作業の扱いに迷いが出やすい。残作業量に含めるなら、完了条件（テスト、レビュー、品質基準）を明確にし、見積りの換算も統一する。外した場合は、バーンダウン上は変化が小さく見えても、体感として遅延が起きる可能性がある。したがって、リファクタリングの計上方針を事前に定めることが実務的である。
7.2 実務で使う情報設計
7.2.1 背景説明（前提・変更点）の書き方
チャートに添える説明は、数値の意味を補う役割を持つ。前提として、残作業の定義、計測単位、完了の判断条件を短く書く。変更点として、スコープの増減、見積りの更新、目標ラインの扱いをいつ・何が・どのように変わったかの順に整理する。これにより、読み手がグラフの形だけで推測せずに済む。
7.2.2 チャートに添える補助指標の例
補助指標として、完了までのリードタイム、未完了の作業が待っている工程、レビュー待ちの件数、欠陥の発生率などが挙げられる。残作業が減らないときに、どこで滞留しているかを示す材料になるため、単独では難しい原因分析を補完できる。補助指標は多すぎると逆効果になりうるため、判断に必要なものに絞るのが実用的である。
7.3 トラブルシューティング
7.3.1 チャートが信用されない時の対処
信用を失う原因は、更新漏れ、定義の不統一、完了判定の曖昧さが多い。対処として、残作業の集計手順を再点検し、対象作業の一覧と完了根拠を監査可能にする。さらに、過去の誤差を修正する場合は、どの期間でどのように扱いを変えたかを明確にし、読み手が再解釈できる状態を作る。
7.3.2 更新が滞る時の運用見直し
更新が止まる場合、作業負担が高い、担当が曖昧、データ入力が煩雑などが背景にある。見直しでは、更新頻度の現実的な範囲を設定し、担当の導線を短縮する。加えて、更新に必要な情報がどこにあるか（チケット管理、状態タグ、完了証跡）を整備し、集計作業が属人化しないようにする。更新の停滞を減らすことが、チャートの意味を守る第一歩となる。