バーンダウンチャートとは？見方や活用のコツ、つくり方をわかりやすく解説

バーンダウンチャートとは、プロジェクトにおける「残作業量の推移」を可視化するためのグラフです。アジャイル開発を背景に広く知られるようになった管理手法のひとつですが、現在ではアジャイル開発に限らず、ウォーターフォール型開発におけるテストケースの残数管理や、各種プロジェクトの進捗管理にも活用されています。時間の経過とともに作業がどれだけ減っているかを一目で把握できる点が特徴です。

縦軸には「残っている作業量（タスク数や工数）」、横軸には「時間（日付）」を取り、プロジェクト開始時点から終了時点に向かって、作業量がゼロに近づいていく様子を表します。

バーンダウンチャートでは、作業の完了によって残作業量が減少していくだけでなく、追加作業の発生、見積もりの見直し、手戻り、作業範囲の変更などによって数値が変動することも前提に管理します。

そのため、単に「理想的な右肩下がり」を目指すためのものではなく、実態に即した現実的な数値をもとに、進捗状況やリスクを把握するために用いられます。作業内容の見直し状況によっては、残作業量が一時的に増加するだけでなく、大きく減少する場合もあります。

企業経営の視点でみると、バーンダウンチャートは単なる開発ツールではなく、進捗の透明性を高める経営管理ツールとしても有効です。従来の報告では「順調です」といった主観的な表現に頼りがちでしたが、このチャートを使えば、進捗の遅れや問題を客観的に把握できます。

実際に活用されるシチュエーションとしては、以下のようなものがあります。

・システム開発やプロダクト開発の進捗管理
・アジャイル開発におけるスプリント単位の管理
・ウォーターフォール型開発におけるテストケースやタスクの残数管理
・チーム全体での作業状況の共有
・プロジェクトの遅延リスクの早期発見

特にアジャイル開発では、短い期間（スプリント）ごとに成果を出すことが求められるため、日々の進捗変化を可視化できるバーンダウンチャートは非常に重要な役割を担います。

▽あわせて読みたい▽
＞＞アジャイル開発とは？概要や進め方、ウォーターフォール型開発との違いやスクラムについて解説のページへ
＞＞ウォーターフォールモデルとは？メリット・デメリット・特徴をわかりやすく解説のページへ
＞＞システム開発とは？工程や手法、依頼時のポイントまでわかりやすく解説のページへ
＞＞スプリントとは？アジャイル開発での重要性や体制、作業プロセスを解説のページへ

バーンダウンチャートと似た管理手法として、「バーンアップチャート」と「ガントチャート」があります。それぞれ目的が異なるため、違いを理解しておくことが重要です。

まずバーンアップチャートは、「どれだけ作業が完了したか」を累積で表現するグラフです。バーンダウンが「減っていく量」を見るのに対し、バーンアップは「積み上がっていく成果」を可視化します。

バーンダウンチャートは、決められた期限に向けて残作業を減らしていく管理に適しており、期限内にどこまで作業を完了できるかを判断しやすい点が特徴です。一方、バーンアップチャートは、作業量が積み上がっていく過程を確認しやすく、スコープが追加されるようなプロジェクトにおいて、作業量の増加に応じて期限や計画を見直す際に役立ちます。

一方のガントチャートは、タスクごとの開始日・終了日を時系列で整理するスケジュール管理ツールです。どの作業をいつ実施するかを把握するのに適しており、プロジェクト全体の計画を俯瞰するのに向いています。

経営判断の観点では、ガントチャートで全体計画を確認しつつ、バーンダウンチャートやバーンアップチャートで日々の進捗をチェックするという使い分けが有効です。これにより、「計画と実行のズレ」を早期に発見し、迅速な意思決定につなげることができます。

▽あわせて読みたい▽
＞＞プロジェクト管理に有用なダッシュボードとは？メリットや設計のコツを紹介のページへ
＞＞プロジェクト遅延の原因とリカバリ方法は？初動対応や再発防止の対策を解説のページへ

バーンダウンチャートを正しく活用するためには、その構成要素を理解することが重要です。単にグラフを見るだけではなく、「どの数値が何を意味しているのか」「期限時点で残作業をゼロにできる見込みがあるのか」を把握することで、より精度の高い意思決定が可能になります。

ここでは、バーンダウンチャートを構成する要素について解説します。

バーンダウンチャートにおける横軸には、日付や経過日数を設定します。アジャイル開発のスプリント管理であれば「1日目、2日目、3日目…」のように、スプリント内の時間の流れを表します。ウォーターフォール型開発におけるテスト工程などでは、テスト期間中の日付を横軸に設定することもあります。

一方、縦軸は「残作業量」を表します。残作業量の単位は、管理対象に応じて変わります。たとえば、以下のような単位が使われます。

・タスク数
・工数
・ストーリーポイント
・テストケース数
・未解決の課題数

アジャイル開発では、ストーリーポイントが使われることがあります。ストーリーポイントとは、タスクの難易度や作業量を相対的に見積もった指標です。時間そのものではなく、「どれくらい大変か」をチーム内で共通認識としてもつために使われます。

ただし、バーンダウンチャートで必ずストーリーポイントを使う必要はありません。重要なのは、チームやプロジェクト内で単位を統一し、残作業量の増減を継続的に比較できるようにすることです。

バーンダウンチャートの中核となるのが、「理想線」「計画線」「実績線」です。

理想線は、プロジェクト開始時点の総作業量から、終了時点でゼロになるように引かれる直線です。これは「このペースで進めば予定通り完了する」という基準を示します。

計画線は、実際のプロジェクト計画に基づいて引かれる線です。理想線と同じく終了時点で残作業をゼロにするための基準ですが、必ずしも直線になるとは限りません。たとえば、立ち上がり時は作業の消化ペースが遅く、中盤で大きく進み、終盤に確認や調整が集中する場合は、プロジェクトの特性に合わせた曲線で描かれることもあります。

実績線は日々の進捗や作業内容の見直しを反映して描かれる線です。完了した作業によって残作業量が減少するだけでなく、追加作業、見積もりの見直し、手戻り、スコープ変更などによって増減することがあります。作業範囲の見直しによって、残作業量が一時的に大きく減少する場合もあります。

これらの線を比較することで、以下のような判断が可能になります。

・実績線が理想線または計画線より上：想定より残作業が多く、進捗が遅れている
・実績線が理想線または計画線より下：想定より残作業が少なく、進捗が早い
・実績線が横ばい：残作業量が減っておらず、作業が進んでいない

つまりバーンダウンチャートは、単に「遅れている・進んでいる」を判断するためだけのものではありません。期限時点で残作業をゼロにするために、残作業量の変化を把握し、必要に応じて優先順位や実施範囲を見直すためのツールです。

バーンダウンチャートにはいくつかの種類がありますが、特にアジャイル開発の現場でよく使われるのが「スプリントバーンダウンチャート」です。

これは、1〜2週間程度の短い期間（スプリント）における進捗を管理するためのチャートです。日々の変化を細かく追うことで、問題の早期発見が可能になります。

一方で「アジャイルバーンダウンチャート」という言葉は、より広い意味で使われることがあります。たとえば、プロジェクト全体（リリースまで）の進捗を管理するためのチャートを指す場合もあります。

ただし経営判断や現場改善において重要なのは、短期間での変化を捉えることです。そのため、本記事では基本的にスプリントバーンダウンチャートを前提に解説します。

バーンダウンチャートを活用する最大のメリットは、期限時点で残作業をゼロにするために、作業量や進め方を調整しやすくなることです。単に進捗状況を見える化するだけでなく、期限までに完了すべき作業量を継続的に把握し、必要に応じて実施範囲や優先順位を見直せる点に大きな価値があります。

特に経営層にとっては、複雑な報告資料を読み込むことなく、期限に対して残作業がどの程度残っているのか、計画どおりにゼロへ近づいているのかを短時間で把握できる点がメリットです。

ここでは、代表的なメリットを整理して解説します。

■期限内に完了すべき作業量を調整しやすい
バーンダウンチャートは、終了時点で残作業をゼロにすることを前提に、日々の残作業量を可視化します。そのため、現在の作業量のまま期限までに完了できるのか、あるいは作業範囲や優先順位の見直しが必要なのかを判断しやすくなります。

たとえば、途中で新たな作業が追加された場合、単に残作業量が増えたことを確認するだけでは不十分です。期限内に完了させるためには、追加作業の重要度を見極めたうえで、別の作業を削減する、優先順位を変更する、対応範囲を調整するなどの判断が必要になります。

バーンダウンチャートを使えば、こうした調整の必要性を早い段階で把握でき、期限に向けて実施すべき範囲をコントロールしやすくなります。

■進捗の遅れを早期に発見できる
バーンダウンチャートは、理想線と実績線の差分によって進捗状況を可視化します。そのため、計画からのズレが発生した場合、すぐに気づくことができます。

たとえば、実績線が理想線よりも上に位置している場合は、作業が予定より遅れている状態です。この段階で対策を講じることで、大きな遅延に発展する前に軌道修正が可能になります。

従来のプロジェクト管理では、問題が表面化するのは終盤になりがちでした。しかしバーンダウンチャートを使えば、初期段階でリスクを検知し、期限時点で残作業をゼロにするための判断につなげられます。

■チーム内で現状を共有しやすい
バーンダウンチャートは視覚的にシンプルなため、直感的に理解できます。これにより、以下のような効果が生まれます。

・チーム内で共通認識を持ちやすくなる
・認識のズレによるコミュニケーションロスを防げる
・会議や報告の時間を短縮できる
・期限までに何を完了させるべきかを確認しやすくなる

特に複数部門が関わるプロジェクトでは、「同じ情報を同じように理解すること」が重要です。バーンダウンチャートは、その基盤となる共通言語として機能します。

■見積もりや進め方の改善につながる
バーンダウンチャートを継続的に活用することで、過去の進捗データが蓄積されます。このデータを分析することで、見積もりの精度や作業の進め方を改善できます。たとえば、以下のような気づきを得られます。

・毎回特定の工程で遅れが発生している
・想定した作業量と実際の作業量にずれがある
・作業追加や仕様変更が発生しやすいタイミングがわかる
・チームの作業消化ペースを把握できる

これらをもとに改善を繰り返すことで、プロジェクト運営の精度が高まり、結果として成功率の向上につながります。

バーンダウンチャートは、基本的な考え方さえ理解すればExcelなどの表計算ソフトでも簡単に作成できます。ただし正しく活用するためには、作成手順と運用ルールを明確にしておくことが重要です。ここでは、実務で使える手順を6つのステップにわけて解説します。

なお、バーンダウンチャートは基本的に計画線と実績線で進捗把握をします。計画線を細かく設定するのがむずかしい際に理想線で代用するのが一般的なため、ここからは計画線を利用する前提で解説します。

まず、バーンダウンチャートに必要な項目と運用ルールを整理します。ここが曖昧なままだと、後からデータの整合性が取れなくなり、正しい判断ができなくなります。具体的には、以下のような項目を定義します。

・日付（横軸）
・総作業量（初日時点のタスク数や工数）
・各日時点の残作業量
・計画線の数値
・実績線の数値

あわせて、以下のような運用ルールも決めておきます。

・更新のタイミング（例：毎日終業時）
・更新担当者（誰が入力するか）
・「完了」の定義（どの状態をもって完了とするか）
・作業追加や作業範囲の変更が発生した場合の扱い

特に「完了の定義」は非常に重要です。定義が曖昧だと、チームごとに判断がブレてしまい、チャートの信頼性が低下します。また、途中で作業が追加された場合に、そのまま積み増すのか、別の作業を削減・先送りするのかといった判断ルールも決めておくと、期限内に完了すべき範囲をコントロールしやすくなります。

次に、管理対象となる期間と、開始時点の総作業量を決定します。

アジャイル開発では、通常「スプリント」と呼ばれる短期間（1〜2週間程度）を単位として設定します。この期間内に完了すべきタスクを洗い出し、総作業量として確定します。また、ウォーターフォール型開発におけるテストケースの残数管理などでは、テスト期間や工程の終了日を対象期間として設定することもあります。

ここでのポイントは、期限時点で残作業をゼロにできるよう、現実的かつ達成可能な範囲に収めることです。過大な計画を立ててしまうと、最初から遅延が前提となり、チャートの意味が薄れてしまいます。

また、総作業量は「タスク数」でも「工数」でも構いませんが、チーム内で統一することが重要です。多くの場合は、ストーリーポイントを用いて相対的に見積もります。

バーンダウンチャートでは、残作業量の推移を比較する基準として、計画線を作成します。

計画線は、プロジェクト開始時点の総作業量から、終了時点で残作業がゼロになるように引く線です。実績線と比較することで、「予定通りに作業が進んでいるか」「期限までに完了できそうか」を判断するための基準になります。

実務上の計画線は、必ずしも直線になるとは限りません。実際のプロジェクトでは、立ち上がり時に作業の消化ペースが遅くなったり、中盤で作業が進みやすくなったり、終盤に確認や調整が集中して再びペースが落ちたりすることがあります。そのため、計画線はプロジェクトの特性に応じて、前半と終盤はゆるやかに減り、中盤で大きく減るような曲線で描かれることもあります。

ここで重要なのは、計画線を「その通りに進めるための絶対的な基準」として扱うのではなく、期限時点で残作業をゼロにするための比較基準として活用することです。途中で作業追加や見積もりの見直しが発生した場合は、実績線との差分を確認しながら、優先順位や作業範囲を調整します。

また、計画線をつくる際は、以下のどちらを基準にするかも決めておきます。

・営業日ベース（作業日だけをカウント）
・カレンダーベース（休日も含める）

実務では、実際に作業を行う日を基準にした「営業日ベース」が一般的です。これにより、より現実に即した進捗管理が可能になります。

日々の進捗を記録していきます。具体的には、毎日の終了時点で「残っている作業量」を入力します。ここで重要なのは、以下の3点です。

・完了した作業だけでなく、追加された作業も反映する
・作業範囲の削減や見直しがあった場合も反映する
・実態に基づいた正確な数値を入力する

プロジェクトでは、途中で仕様変更や追加作業が発生することがあります。これを無視すると、実態と乖離したチャートになってしまいます。

一方で、追加作業が発生したからといって、すべてを無条件に積み増すわけではありません。期限時点で残作業をゼロにするためには、追加作業の重要度を確認し、必要に応じて別の作業を削減する、優先順位を変更する、次回以降に回すといった調整も必要です。

データが揃ったら、計画線と実績線を同じグラフ上にプロットし、折れ線グラフとして可視化します。これにより、以下のような状況が一目で分かるようになります。

・期限に向けて残作業が減っているか
・予定よりも残作業が多い状態になっていないか
・作業追加や範囲変更の影響がどの程度あるか
・期限時点で残作業をゼロにできる見込みがあるか

可視化する際のポイントは、シンプルで見やすいグラフにすることです。情報を詰め込みすぎると、かえって判断しづらくなります。

最後に、計画線と実績線の差分を確認し、改善活動につなげます。たとえば、以下のようなアクションが考えられます。

・残作業が多い場合：リソースの再配分や優先順位の見直し
・作業が追加された場合：別の作業の削減、先送り、対応範囲の調整
・想定より早く進んでいる場合：品質確認の強化や次工程への前倒し
・進捗が停滞している場合：ボトルネックの特定と解消

重要なのは、チャートを「見るだけ」で終わらせないことです。バーンダウンチャートは、期限までに残作業をゼロにするために、現状を把握し、必要な調整を行うための管理手法です。実績線が基準から外れた場合も、単に遅れや前倒しと捉えるのではなく、作業量、優先順位、対応範囲を見直す判断材料として活用することで、価値が発揮されます。

バーンダウンチャートは非常に有効なツールですが、使い方を誤ると、かえって現場の混乱や誤った意思決定を招く可能性があります。

特に重要なのは、バーンダウンチャートを単なる進捗確認のグラフとして見るのではなく、期限内に完了すべき作業範囲を調整するための判断材料として活用することです。途中で作業が追加された場合には、すべてをそのまま積み増すのではなく、何を実施し、何を実施しないかを見直す必要があります。

ここでは、実務でバーンダウンチャートを使う際に注意すべきポイントを整理して解説します。

■チャートだけで進捗を判断しない
バーンダウンチャートは、残作業量の推移を可視化するためのグラフであり、プロジェクトのすべての状況を表すものではありません。

たとえば、以下のようなケースでは、チャート上では残作業の減り方が遅く見えることがあります。

・作業の技術的な難易度が高い
・品質確保のために確認や修正に時間をかけている
・将来の手戻りを防ぐための対応をしている
・関係者との調整や確認に時間がかかっている

このような状況は、チャート上では「遅れている」と見える場合があります。しかし実際には、プロジェクトを期限内に確実に完了させるために必要な対応を行っていることもあります。

そのため、バーンダウンチャートの数値だけで判断するのではなく、作業の内容、品質、リスク、チームの状況などの定性的な情報とあわせて確認することが重要です。

■完了件数だけを追いすぎない
バーンダウンチャートでは、「どれだけ作業が減ったか」に注目しがちですが、完了件数だけを重視しすぎると、本質を見失うリスクがあります。たとえば、以下のような問題が起こり得ます。

・簡単なタスクばかり優先して処理する
・本来重要な作業が後回しになる
・品質よりスピードが優先される
・本来必要な確認やレビューが省略される

短期的には残作業量が順調に減っているように見えても、重要な作業が残っていたり、品質面の問題が後から発覚したりすれば、結果的に手戻りや遅延につながる可能性があります。

バーンダウンチャートを見る際は、作業量の減少だけでなく、期限内に完了すべき重要な作業が適切に進んでいるかもあわせて確認することが大切です。

■作業追加時は実施範囲を見直す
プロジェクトでは、途中で要件追加、仕様変更、見積もりの見直し、手戻りなどが発生することがあります。このとき、追加された作業をすべてそのまま積み増すと、期限時点で残作業をゼロにすることがむずかしくなる場合があります。

バーンダウンチャートの基本的な考え方は、期限内に残作業をゼロにすることです。そのため、作業量が増えた場合には、単に「残作業が増えた」と記録するだけでなく、期限内に何を実施し、何を実施しないかを見直す必要があります。具体的には、以下のような判断が求められます。

・追加作業を今回の対象に含めるか
・優先度の低い作業を削減するか
・一部の作業を次回以降に回すか
・対応範囲や完了条件を見直すか
・リソースや進め方を変更するか

このように、バーンダウンチャートは作業追加を記録するためだけのものではなく、期限内に実施すべき範囲をコントロールするためのツールとして活用することが重要です。

■スコープ変更時の扱いを明確にする
プロジェクトでは、途中で要件追加や仕様変更が発生することが珍しくありません。このとき、バーンダウンチャートの扱いを曖昧にすると、正しい進捗が分からなくなります。たとえば、以下のような対応方針を事前に決めておくことが重要です。

・追加作業をどのタイミングで反映するか
・総作業量を更新するかどうか
・削減した作業をどのように記録するか
・今回の対象外とした作業をどこで管理するか
・変更理由をどのように残すか

特に、作業を追加する場合には、同時に削減・先送り・優先順位変更の判断も行うことで、期限内に完了すべき範囲を明確にできます。

スコープ変更の扱いをあらかじめ決めておけば、残作業量の増減が発生しても、実態に即した形で進捗を管理できます。

■個人の責任追及に使わない
バーンダウンチャートは、チームやプロジェクト全体の状況を把握し、改善につなげるためのツールです。個人の責任追及を目的に使うと、正確な情報が共有されにくくなる可能性があります。

たとえば、チャートの数値が評価や責任追及に直結すると、以下のような問題が起こり得ます。

・遅れや課題が報告されにくくなる
・見積もりや残作業量が実態より小さく見積もられる
・問題の発見が遅れる
・チーム内の信頼関係が損なわれる

ただし、これはバーンダウンチャート特有の問題というよりも、マネジメント全般に関わる注意点です。バーンダウンチャートを運用する際も、個人を評価・追及するためではなく、チームで現状を共有し、必要な調整を行うために活用することが大切です。

■過度に細かく管理しすぎない
バーンダウンチャートを細かくつくりすぎると、運用負荷が高まり、現場の負担になってしまいます。たとえば以下の状況は、かえって生産性を下げる要因になります。

・タスクを細分化しすぎる
・更新頻度を過度に高くする
・指標を増やしすぎる
・入力や報告のための作業が増えすぎる

バーンダウンチャートは、継続的に使ってこそ価値を発揮します。運用が複雑すぎると、更新が滞ったり、形だけの管理になったりする可能性があります。

重要なのは、シンプルで継続しやすい運用にすることです。必要な情報を過不足なく記録し、期限時点で残作業をゼロにするための判断につなげられる形で活用しましょう。

バーンダウンチャートは、単に「遅れているかどうか」を確認するためのものではありません。実績線の動き方から、残作業量の変化、作業追加の有無、ボトルネック、見積もりの妥当性などを読み解き、期限時点で残作業をゼロにするための判断につなげることが重要です。

ただし、バーンダウンチャートの見方には、大きく分けて2つの時間軸があります。

・期中の運用管理：進行中に実績線の変化を確認し、作業範囲や優先順位を調整する
・期間終了後の振り返り：実績線の推移を分析し、次回以降の見積もりや進め方を改善する

期中の運用管理では、実績線が理想線や計画線から外れたときに、すぐに原因を確認し、必要に応じて対応します。一方、期間終了後の振り返りでは、全体の推移を見て「なぜそのような線の動きになったのか」を分析し、次回以降の改善につなげます。

ここでは、現場マネジメントやプロジェクト管理の視点から、代表的なパターンと読み解き方を整理します。

理想線または計画線と実績線がほぼ一致して推移している状態です。期限に向けて残作業量が順調に減少しており、現時点では大きな遅れや作業量の増加は見られません。

期中の運用管理では、基本的に現在の進め方を維持します。ただし、線が順調に見えていても、後半に難易度の高い作業や確認作業が残っている場合があります。そのため、以下の点を確認しておくことが重要です。

・重要な作業が後回しになっていないか
・後半にリスクの高い作業が集中していないか
・作業の完了条件が適切に満たされているか

期間終了後の振り返りでは、計画が現実的だったか、作業量の見積もりや進め方に無理がなかったかを確認します。うまく進んだ要因を整理しておくことで、次回以降の計画づくりにも活かせます。

前半は実績線が計画線または理想線より上にあり、残作業量の減り方が遅いものの、後半にかけて急速に作業が進むパターンです。いわゆる「後半追い込み型」の進み方です。

考えられる要因は以下のとおりです。

・初期段階で作業理解や準備に時間がかかった
・環境構築や関係者調整に時間を要した
・タスクの粒度が大きく、完了として記録されるまで時間がかかった
・後半にチームの習熟が進み、作業ペースが上がった

期中の運用管理では、前半の段階で実績線が計画線より上に離れはじめた時点で、原因を確認することが重要です。単に「後半で取り戻せる」と判断するのではなく、期限時点で残作業をゼロにできる見込みがあるかを確認し、必要に応じて優先順位や作業範囲を見直します。

期間終了後の振り返りでは、なぜ前半に進捗が停滞したのかを分析します。立ち上がり時の準備不足、見積もりの甘さ、タスク分解の粗さなどが原因であれば、次回は開始前の準備やタスク設計を改善することが有効です。

序盤で大きく進捗が進み（実績線が理想線より下）、後半は緩やかになるパターンです。一見理想的に見えますが、以下のケースもあるため注意が必要です。

・簡単なタスクから先に完了している
・難易度の高い作業や確認作業が後半に残っている
・品質確認やレビューに時間がかかっている
・完了条件が曖昧で、後から手戻りが発生している

期中の運用管理では、前半の進捗が良く見える場合でも、残っている作業の中身を確認することが重要です。残作業量が少なく見えていても、難易度や重要度の高い作業が残っていれば、期限内に完了できないリスクがあります。

期間終了後の振り返りでは、タスクの順序や分解方法が適切だったかを確認します。簡単な作業だけが先に進み、重要な作業が後半に集中していた場合は、次回以降、優先順位付けや作業計画の立て方を見直す必要があります。

一定期間、実績線がほぼ横ばいになる状態です。つまり、作業がほとんど進んでいません。

このパターンは、明確な問題が発生している可能性が高いです。主な原因としては、以下が考えられます。

・技術的な課題で作業が止まっている
・意思決定待ちや確認待ちが発生している
・外部要因によって作業を進められない
・タスクの粒度が大きく、完了として記録されていない
・担当者のリソースが不足している

期中の運用管理では、横ばいの状態が続いた時点で、早めにボトルネックを特定することが重要です。放置すると、期限直前に大きな遅れとして表面化する可能性があります。

具体的には、以下のような対応が考えられます。

・作業を止めている要因を特定する
・必要な意思決定や確認を前倒しする
・タスクを分割して進捗を把握しやすくする
・担当者やリソースを調整する
・期限内に実施すべき作業範囲を見直す

期間終了後の振り返りでは、停滞が発生した原因を確認し、次回以降に同じボトルネックが起きないように改善策を整理します。

途中で実績線が上昇する（残作業が増える）パターンです。これは、作業が進んでいないというよりも、管理対象となる作業量そのものが増えたことを示している場合があります。

考えられる要因は以下のとおりです。

・仕様変更や追加要件が発生した
・見積もりの見直しにより作業量が増えた
・手戻りが発生した
・当初は見えていなかった作業が明らかになった

このパターンで重要なのは、作業が増えた事実を把握するだけで終わらせないことです。バーンダウンチャートは、期限時点で残作業をゼロにすることを前提に運用するため、作業量が増えた場合には、期限内に何を実施し、何を実施しないかを見直す必要があります。

期中の運用管理では、以下のような判断が求められます。

・追加作業を今回の対象に含めるか
・優先度の低い作業を削減するか
・一部の作業を次回以降に回すか
・対応範囲や完了条件を見直すか
・リソースや進め方を変更するか

期間終了後の振り返りでは、なぜ作業量が増えたのかを分析します。要件定義の不足、見積もりの甘さ、変更管理の不備などが原因であれば、次回以降の計画やスコープ管理の改善につなげます。

終始、実績線が理想線より上にあり、遅れが解消されない状態です。期限時点で残作業をゼロにできないリスクが高く、注意が必要です。

考えられる要因は以下のとおりです。

・開始時点の総作業量が多すぎた
・見積もりが実態と合っていなかった
・リソースやスキルが不足している
・優先順位が不明確になっている
・作業追加が発生しているにもかかわらず、範囲調整ができていない

期中の運用管理では、遅れが継続していることが分かった時点で、早めに対策を検討します。単に「頑張って取り戻す」だけではなく、期限内に残作業をゼロにするために、作業量、優先順位、対応範囲を見直すことが重要です。

具体的には、以下のような対応が考えられます。

・優先度の高い作業に集中する
・優先度の低い作業を削減または先送りする
・リソースを再配分する
・作業の進め方や分担を見直す
・必要に応じて期限やスコープを再調整する

期間終了後の振り返りでは、計画時点の見積もり、実行中の変更管理、チーム体制、意思決定プロセスなどを確認します。遅れが継続した原因を明確にすることで、次回以降のプロジェクト計画の精度を高められます。

バーンダウンチャートのパターンを見る際は、線の形だけで良し悪しを判断しないことが重要です。同じ線の動きでも、背景にある原因はプロジェクトによって異なります。

期中の運用管理では、以下の観点で確認します。

・期限時点で残作業をゼロにできる見込みがあるか
・残っている作業の重要度や難易度はどうか
・作業追加や仕様変更が発生していないか
・必要に応じて、実施する作業と実施しない作業を見直せているか

期間終了後の振り返りでは、以下の観点で分析します。

・見積もりは妥当だったか
・作業の分解や優先順位付けは適切だったか
・ボトルネックはどこで発生したか
・作業追加やスコープ変更を適切に管理できていたか
・次回以降の計画に反映すべき学びは何か

このように、バーンダウンチャートは「期中に調整するための管理ツール」としても、「期間終了後に改善点を見つけるための分析ツール」としても活用できます。読み解く際は、対象読者や目的に応じて、日々の判断に使うのか、次回以降の改善に使うのかを分けて考えることが大切です。

バーンダウンチャートは、プロジェクトの残作業量を時系列で可視化し、期限時点で残作業をゼロにするために、作業量や実施範囲を調整しやすくする管理手法です。アジャイル開発におけるスプリント管理で広く知られていますが、ウォーターフォール型開発におけるテストケースの残数管理など、残作業量を継続的に把握したい場面でも活用されています。

本記事では、バーンダウンチャートの基本的な考え方から構成要素、メリット、つくり方、注意点、そしてパターン別の読み解き方までを解説しました。重要なのは、単にグラフをつくることではなく、実績線の変化から作業追加、見積もりの見直し、手戻り、ボトルネックなどを把握し、期限内に完了すべき作業範囲を適切にコントロールすることです。

また、理想線は一定のペースで作業が消化されると仮定した平均的な目安であり、実務上の計画線はプロジェクトの特性によって直線とは限りません。理想線や計画線と実績線の差分を見る際も、数値だけで判断するのではなく、作業内容や優先順位、品質、リスクなどの背景をあわせて確認することが大切です。

バーンダウンチャートを正しく理解し、期中の運用管理と期間終了後の振り返りの両方で活用することで、プロジェクトの成功確率を高め、組織全体の生産性向上につなげていけるでしょう。

「市場のニーズにすばやく対応したい」、「アジャイル開発に切り替えたいがノウハウがなくうまくいかない」などとお悩みの場合には、SHIFTにご相談ください。

SHIFTの「アジャイルコンサルティングサービス」は、開発体制から企業カルチャーまで、組織アジャイルでの変革をフルスコープで支援するコンサルティングサービスです。SHIFTのアジャイル支援ナレッジから編み出したアジャイル成功のための8要素「Eight Keys」に基づき、経営層、マネジメント層、プロジェクト現場など階層ごとのお悩み解決に貢献します。アジャイル開発なら、実績が豊富なSHIFTにお任せください。

＞＞お問い合わせページへ
＞＞料金についてページへ

大手IT会社にて、17年間ソフトウェア製品の開発に従事し、ソフトウェアエンジニアリングを深耕。SE支援部門に移り、システム開発の標準化を担当し、IPAのITスペシャリスト委員として活動。また100を超えるお客様の現場の支援を通して、品質向上活動の様々な側面を経験。その後、人材育成に従事し、4年に渡り開発者を技術とマインドの両面から指導。2019年、ヒンシツ大学の講師としてSHIFTに参画。

担当講座

・コンポーネントテスト講座
・テスト自動化実践講座
・DevOpsテスト入門講座
・テスト戦略講座
・設計品質ワークショップ
など多数

――――――――――
ヒンシツ大学とは、ソフトウェアの品質保証サービスを主力事業とする株式会社SHIFTが展開する教育専門機関です。
SHIFTが事業運営において培ったノウハウを言語化・体系化し、講座として提供しており、品質に対する意識の向上、さらには実践的な方法論の習得など、講座を通して、お客様の品質課題の解決を支援しています。
https://service.shiftinc.jp/softwaretest/hinshitsu-univ/
https://www.hinshitsu-univ.jp/
――――――――――