--- title: "バーンダウンチャートとは：見方と作り方（Excel・Jira）、発注者が遅延を見抜く読み方" url: "https://www.issoh.co.jp/column/details/19802/" published: 2026-11-15 updated: 2026-11-15 categories: ["自動化"] publisher: "株式会社一創" --- # バーンダウンチャートとは：見方と作り方（Excel・Jira）、発注者が遅延を見抜く読み方 バーンダウンチャートは、スプリントの残作業を縦軸、稼働日を横軸に取り、作業が減っていく様子を1本の線で追うグラフです。この記事では、理想線と実績線の読み方、実績線の形から分かる遅延・停滞・作業追加の5パターン、ExcelやGoogleスプレッドシートで土日祝を除いた理想線を引く数式を順に説明します。JiraとAzure DevOpsで表示したときの集計の違いと、受託開発の発注者がベンダーから受け取ったバーンダウンチャートで遅延を見抜く確認項目も扱います。 ## まとめ：バーンダウンチャートは理想線との差より傾きとスコープの増減で読む バーンダウンチャートで見るべきなのは、実績線が理想線の上か下かだけではありません。残り日数で残作業を割った「必要な消化速度」が、ここ数日の実績の傾きより速いかどうかを見ます。必要な速度が実績の1.5倍を超えたら、スプリント内での挽回は難しい状態です。 実績線が途中で上がったら、作業の追加なのか見積もりの誤りなのかを切り分けます。残作業の線だけではこの2つを区別できないため、総作業量（スコープ）の線を一緒に描くか、バーンアップチャートを併用します。 受託開発の発注者がベンダーから報告を受けるときは、スコープの線・完了の定義・縦軸の単位・最終更新日時の4点を必ず添えてもらいます。この4点が無いバーンダウンチャートは、順調に見えても遅延を隠せてしまうからです。 ## バーンダウンチャートの定義と、理想線・実績線・縦軸と横軸が示すもの ### 残作業を縦軸、稼働日を横軸に取るグラフと、スクラムガイド2020での位置づけ バーンダウンチャートの縦軸は「まだ終わっていない作業の量」、横軸は日付です。スプリント初日に残作業の合計から始まり、最終日にゼロへ届く直線が理想線、毎日記録した残作業をつないだ線が実績線になります。 スクラムの公式ガイドである[The 2020 Scrum Guide](https://scrumguides.org/scrum-guide.html)は、スプリントの節で「進捗を予測する手法として、バーンダウン、バーンアップ、累積フローなどがある」と述べたうえで、「有用ではあるが、経験主義の重要性に取って代わるものではない」と書いています。つまり、バーンダウンチャートはスクラムの必須成果物ではありません。チームが選んで使う補助の道具です。 スクラムのイベントや役割の全体像は[スクラム開発の3つの役割・5つのイベントと進め方](https://www.issoh.co.jp/column/details/2336/)で扱っています。本記事はその中で進捗を見る道具の1つ、バーンダウンチャートに絞ります。 ### スプリントバーンダウンとリリースバーンダウンの期間・更新頻度・見る人の違い バーンダウンチャートには、対象期間が異なる2種類があります。 | 種類 | 横軸の範囲 | 更新頻度 | 主に見る人 | | ----------- | ------------- | ------- | ------ | | スプリントバーンダウン | 1スプリント（1〜4週間） | 毎日 | 開発チーム | | リリースバーンダウン | リリースまでの全スプリント | スプリントごと | PO・発注者 | スプリントの長さは、スクラムガイドで「1か月以内の固定の長さ」とされています。スプリントバーンダウンは日単位で残作業の減り方を追い、デイリースクラムで「今日どこを手当てするか」を決める材料になります。リリースバーンダウンは横軸の1目盛りが1スプリントで、リリース日に間に合うかを予測する用途です。発注者が定例会で見るのは、多くの場合リリースバーンダウンのほうです。 ### バーンアップチャートとの違いと、スコープが増える案件で2本の線を併用する理由 バーンアップチャートは、完了した作業の累計を下から積み上げるグラフです。Microsoft Learnの[バーンダウンとバーンアップのガイダンス](https://learn.microsoft.com/ja-jp/azure/devops/report/dashboards/burndown-guidance)では、バーンダウンは途中で作業が追加されると上向きの線になり、バーンアップは完了に合わせて常に右肩上がりになると説明しています。 差が出るのはスコープが変わったときです。残作業が10ポイント減り、同時に10ポイントの機能が追加されると、バーンダウンの実績線は横ばいになります。チームが働いていないのか、作業が増えたのか、線1本では見分けられません。バーンアップなら完了の線は10ポイント上がり、総作業量の線も10ポイント上がるので、両方の事実が読み取れます。仕様変更が起きやすい受託開発では、バーンダウンを使うなら総作業量の線を重ねるか、バーンアップを並べて表示します。 ## 実績線の形で分かる遅延・停滞・作業追加の5パターンと次の打ち手 ### 実績線の形5パターンを、進捗上の意味と次に取る打ち手で比べた早見表 実績線の形は、おおむね次の5つに分かれます。上から順に、見かける頻度が高いものです。 | 実績線の形 | 考えられる原因 | 次の打ち手 | | ------------ | ------------- | ---------- | | 理想線の上を平行に推移 | 初日の計画が多すぎた | スコープを減らす協議 | | 数日横ばい→最終日に急落 | 更新漏れ・完了の定義が曖昧 | 毎日の更新と完了基準 | | 途中で上向きになる | 作業追加・見積もり誤り | スコープ線で切り分け | | 理想線の下を推移 | 見積もりが大きすぎた | 次回の計画量を増やす | | 理想線とぴったり重なる | 数字を合わせている疑い | 完了した項目を確認 | 最後の「ぴったり重なる」は見落とされがちです。毎日の残作業が理想線と一致し続けることは、実際の開発ではまず起きません。担当者が理想線に合わせて数字を書いている可能性があり、完了した項目の一覧と突き合わせる必要があります。 ### 理想線の上で平行に推移する遅延と、残り日数から必要な消化速度を出す計算 実績線が理想線の上にあっても、傾きが理想線と同じなら、遅れの幅は広がっていません。初日に積んだ作業が多すぎただけで、遅れの量は初日から変わらない状態です。 判断には、残り日数から必要な消化速度を出します。例として、10稼働日のスプリントで6日目終了時点の残作業が24ポイント、直近3日の実績が1日あたり3ポイントだったとします。残り4日で24ポイントを終えるには1日6ポイントが必要で、実績の2倍です。この時点でスプリント内の挽回は見込めないため、プロダクトオーナーと相談して、優先度の低いバックログ項目を次のスプリントへ戻す判断をします。 逆に、必要な速度が実績の1.2倍程度なら、残りの作業の中に分割できる大きな項目がないかを先に確かめます。大きな項目が1つ終わるだけで、実績線は一気に下がることがあるからです。 ### 数日間の横ばいと最終日の急落が示す、完了の定義の曖昧さと更新漏れ 実績線が数日横ばいになり、スプリント最終日に大きく落ちる形は、作業が止まっていたとは限りません。多くは、残作業の更新が完了時にまとめて行われているか、「レビュー待ち」「テスト待ち」の項目が完了扱いになっていないことが原因です。 Microsoft Learnの[スプリント バーンダウンの構成と監視](https://learn.microsoft.com/ja-jp/azure/devops/report/dashboards/configure-sprint-burndown)も、担当者が週に1回や数日おきにしか作業項目を更新しないため、階段状のバーンダウンになるのが普通だと書いています。同じページの推奨事項は、タスクを1日以内で終わる大きさに分けることと、残作業を毎日または週に数回更新することです。 横ばいが3日続いたら、デイリースクラムで「何が完了に届いていないのか」を項目単位で確認します。完了の定義（コードレビュー済み、結合テスト済みなど）がチームで揃っていないと、同じ項目を人によって完了とも未完了とも数えてしまいます。 ### 途中で実績線が上がる作業追加と見積もり誤りを、スコープ線で切り分ける方法 実績線の上昇には、原因が3つあります。Microsoft Learnのガイダンスは、タスクの見積もりの誤り、スプリント計画で見込んでいなかった作業の発見、チームが合意していない作業の追加（スコープクリープ）を挙げています。 切り分けには、総作業量の線を使います。総作業量が増えていれば、項目の追加です。総作業量が変わらずに残作業だけが増えていれば、既存項目の見積もりを上方修正したことになります。前者は発注者やプロダクトオーナーとの合意の問題、後者はチームの見積もり精度の問題で、話し合う相手が違います。 スプリントのふりかえりでこの2つを分けて記録しておくと、次のスプリントで計画量を調整する根拠になります。ふりかえりの進め方は[レトロスペクティブの進め方と材料の集め方](https://www.issoh.co.jp/tech/details/17577/)で扱っています。 ## Excelとスプレッドシートでバーンダウンチャートを作る手順と理想線の数式 ### 縦軸の単位をストーリーポイント・タスク数・残時間から選ぶときの判断基準 最初に決めるのは縦軸の単位です。選択肢は3つあり、迷ったらストーリーポイントを選びます。 | 単位 | 向いている場面 | 弱点 | | --------- | ----------- | ------------- | | ストーリーポイント | 見積もりの習慣がある | 項目の完了時にしか減らない | | タスク数 | 見積もりをしていない | 大小の差が線に出ない | | 残時間 | タスクを時間で見積もる | 毎日の入力の手間が大きい | ストーリーポイントは項目が完了したときにまとめて減るので、線は階段状になります。タスク数は手軽ですが、半日の作業と3日の作業が同じ1として数えられます。ストーリーポイントの付け方とベロシティの計算は[ストーリーポイントの見積もり方とベロシティの使い方](https://www.issoh.co.jp/column/details/2570/)を参照してください。スプリントの途中で単位を変えると線がつながらなくなるため、単位は1スプリント単位で固定します。 ### 日付・理想線・実績の列を作り、NETWORKDAYS関数で土日祝を除く理想線の数式 理想線を開始日から終了日まで均等に下げると、土日にも作業が減る前提になり、月曜の朝には必ず遅れて見えます。Excelの[NETWORKDAYS関数](https://support.microsoft.com/ja-jp/excel/functions/networkdays-function)は、開始日から終了日までの稼働日数を、土日と指定した祭日を除いて数えます。これを使えば、休みの日の理想線は、作業量が減らない水平な形です。 2026年11月16日（月）から27日（金）までの2週間のスプリントで、23日（月）の勤労感謝の日を除く9稼働日、開始時の総量40ポイントとした場合のセル配置と数式は次のとおりです。 ``` F1: 2026-11-16 ← スプリント開始日 F2: 2026-11-27 ← スプリント終了日 F3: 40 ← 開始時点の総ストーリーポイント H2: 2026-11-23 ← 祭日（H2:H10 に並べる） A5: 開始時点 B5: =$F$3 A6: 2026-11-16 B6: =$F$3*(1-NETWORKDAYS($F$1,A6,$H$2:$H$10)/NETWORKDAYS($F$1,$F$2,$H$2:$H$10)) A7: =A6+1 B7: B6をコピー（A17の2026-11-27まで下へ） C列: 各日の終業時点の残ポイントを手入力 D列: 各日の総ポイント（追加分を含む）を手入力 ``` B6の値は40×(1−1/9)で約35.6、土曜の21日から祭日の23日まではNETWORKDAYSの結果が5のまま変わらないため、理想線は17.8で水平になります。数式が正しく入っているかどうかの確認基準は、最終日の27日に0へ届くことです。GoogleスプレッドシートにもNETWORKDAYS関数があり、同じ数式で動きます。 ### 折れ線グラフにする手順と、毎日同じ時刻に残作業を記録する運用ルール 表ができたら、次の順でグラフにします。 1. A5からD17までを選択し、挿入タブから「折れ線」グラフを選ぶ 2. B列（理想線）を点線に、C列（実績）を太い実線に、D列（総量）を細い実線に変える 3. 縦軸の最小値を0に固定し、最大値を開始時点の総量の1.2倍程度にする 4. グラフタイトルに単位（ポイント）と最終更新日時を入れる 運用で決めておくのは記録の時刻です。「毎日のデイリースクラム直前」のように時刻を固定し、その時点の値を入れます。入力を忘れた日は空欄のまま残し、前日の値を写さないでください。写すと横ばいに見え、更新漏れと作業の停滞の区別がつかなくなります。 ## JiraとAzure DevOpsでバーンダウンチャートを表示するときの集計仕様の違い ### Jiraのバーンダウンはスクラムボード限定で、サブタスクのポイントを数えない仕様 Atlassianのヘルプ[View and understand the burndown chart](https://support.atlassian.com/jira-software-cloud/docs/view-and-understand-the-burndown-chart/)によると、Jiraのバーンダウンチャートは企業管理型（company-managed）スペースのスクラムボードでのみ使えます。カンバンボードを使っているチームでは表示されません。 集計の仕様にも注意点があります。ストーリーポイントは親の作業項目のものだけが数えられ、サブタスクに付けたポイントは含まれません。また、チャートの対象はボードの保存済みフィルターに一致する項目で、「To Do」と「Done」の判定はボードの列の割り当てで決まります。「レビュー中」の列をDoneに割り当てていれば、レビュー前の項目も完了として線が下がります。 サブタスクにポイントを付けて運用しているチームは、Jiraのバーンダウンが実際より減らずに見えるので、ポイントは親の項目に付ける運用へ揃えます。 ### Azure DevOpsの件数・数値フィールド別の集計仕様とスコープ増加の表示 Azure DevOpsのスプリントバーンダウンは、作業項目の件数か、Story Points・Effort・Remaining Workなど数値フィールドの合計で描けます。前述のMicrosoft Learnのページ（英語版の更新日は2026年3月23日）によると、理想線（Ideal Trend）の計算に使われるのは、作業項目の数、スプリントの日数、稼働日です。「Show non-working days」を有効にすると、チームの稼働日と休暇の設定が非稼働日として灰色で表示されます。 Jiraとの違いとして、ウィジェットの「Show total scope」を有効にすると総作業量の線が重なり、チャート上部に「Total Scope Increase」として開始時点からの増加量が出ます。前の章で説明した作業追加と見積もり誤りの切り分けが、設定だけでできる仕組みです。 GitLabのマイルストーンやIssue期日で進捗を追う方法は[GitLabのスケジュール管理とガントチャート](https://www.issoh.co.jp/tech/details/19641/)、ツールを既製品で揃えるか自作するかの判断軸は[プロジェクト管理ツールの選び方](https://www.issoh.co.jp/column/details/15248/)で整理しています。 ## 受託開発の発注者がベンダーのバーンダウンチャートで進捗遅延を見抜く確認項目 ### 報告に含めてもらう4点：スコープの線・完了の定義・縦軸の単位・最終更新日時 アジャイルで受託開発を進めると、ベンダーの定例報告にバーンダウンチャートが入ることがよくあります。発注者がこれを受け取ったときに、最初に確かめるのは次の4点です。 - 総作業量（スコープ）の線が描かれているか。無ければ、作業の追加で減りが相殺されていても分からない - 完了の定義が文書で共有されているか。「実装済み」と「受け入れテスト済み」では、同じ線でも進捗の意味が違う - 縦軸の単位が前回の報告と同じか。ポイントから件数に変わると、線の傾きは比べられない - 最終更新日時はいつか。報告の前日に一括更新していれば、横ばいと急落の形が作られる この4点が揃っていない報告は、実績線が理想線の下にあっても順調とは判断できません。報告様式に4点を入れることを、契約後のキックオフで合意しておくのが確実です。発注側の体制だけでベンダーの報告を読み解くのが難しい場合は、[要件定義・RFP作成・PMO支援](https://www.issoh.co.jp/service/system/pmo/)として、報告様式の設計や進捗の第三者確認をご相談いただけます。 ### 再見積もりで残作業が増えたときに、遅延と仕様追加を分けて協議する進め方 ベンダーから「残作業が20ポイント増えました」と報告されたら、増えた分の内訳を項目単位で出してもらいます。内訳は、発注者からの追加・変更の依頼で増えた分と、ベンダーの見積もりの見直しで増えた分の2つに分かれます。 前者は、発注者が優先度を決める話です。追加を受け入れるなら、同じ量の既存項目を後ろへ回すか、リリース日を動かすかを選びます。後者は、ベンダーの見積もり精度の問題で、同じ増え方が2スプリント続くなら、残りの項目全体を見積もり直してもらう根拠になります。 この切り分けをしないまま「遅れている」とだけ伝えると、ベンダーは増員か残業で吸収しようとし、品質のほうが崩れます。リリースバーンダウンを見る定例では、まず総作業量の変化から話し始める順番にしておきます。 ### バーンダウンチャートを進捗報告に使わないほうがよい契約形態と案件規模の条件 バーンダウンチャートが役に立たない場面もあります。結論から言うと、次の2つの条件では使いません。 1つ目は、要件を固めて一括で請け負うウォーターフォール型の契約です。工程ごとの成果物（設計書、テスト結果）で進捗を測る契約に残作業のポイントを持ち込んでも、検収の基準と結びつかず、報告が二重になります。この場合に合うのは、工程別の予定と実績を並べたガントチャートや、出来高で見る管理です。契約形態と開発手法の組み合わせは[ウォーターフォールとアジャイル・スクラムの違いと契約形態の選び方](https://www.issoh.co.jp/column/details/1348/)で整理しています。 2つ目は、開発者が1〜2人で、作業項目がスプリントあたり5件を下回る規模の案件です。項目が1件終わるたびに線が大きく段差を作り、傾きから何も読み取れません。この規模なら、完了した項目と残りの項目の一覧を毎週共有するほうが、発注者にも状況が伝わります。 ## よくある質問 バーンダウンチャートの作り方と読み方について、実務で多い質問に答えます。 ### バーンダウンチャートとベロシティはどう関係しますか？ ベロシティは、1スプリントで完了したストーリーポイントの合計です。スプリントバーンダウンの実績線が最終日にどこまで下がったかを見れば、そのスプリントのベロシティが分かります。逆に、過去数スプリントのベロシティの平均を使うと、リリースバーンダウンの残作業がゼロになる時期を予測できます。ただし、ベロシティはチームごとの見積もりの尺度に依存するため、別のチームと比べる指標には使えません。 ### 土日や祝日は横軸に入れるべきですか？ 横軸に日付として入れたうえで、理想線を水平にする方法を勧めます。土日を横軸から外す方法では、カレンダーとの対応が分かりにくくなるのが難点です。ExcelやGoogleスプレッドシートならNETWORKDAYS関数で稼働日を数え、休みの日は理想線が下がらないようにします。Azure DevOpsではチームの稼働日と休暇の設定を非稼働日として表示できます。祝日を祭日リストへ入れ忘れると、休み明けに遅れて見えるので、スプリント開始前に確認してください。 ### 実績線が理想線より下なら、順調と判断してよいですか？ 線の位置だけでは判断できません。理想線より下にあっても、作業の追加分を総量に入れずに残作業から外していれば、線は下がります。完了の定義が「実装済み」までで、テストが終わっていない項目を完了として数えている場合も同じです。総作業量の線が開始時点から変わっていないこと、完了した項目が完了の定義を満たしていることの2つを確かめてから、順調と判断します。 ### バーンダウンチャートとガントチャートはどう使い分けますか？ ガントチャートは、作業ごとの開始日と終了日、作業間の依存関係を横棒で示す計画の図です。バーンダウンチャートは、作業の順番を持たず、残りの量の減り方だけを追います。工程の順序と依存関係が決まっているウォーターフォール型の案件に向くのはガントチャート、スプリントの中で作業の順番をチームが入れ替えるアジャイル型の案件に向くのはバーンダウンチャートです。両方を混ぜる場合は、リリースまでの大日程をガントで、スプリント内をバーンダウンで見ます。 ### スクラム以外の業務や個人の作業でも使えますか？ 使えます。期限と作業の総量が決まっていて、作業を同じ尺度で数えられるものなら、記事の更新本数、月末の経理作業の件数、試験勉強のページ数などにも当てはめられます。条件は、期間の途中で総量が大きく変わらないことです。総量が頻繁に増える業務では、バーンアップチャートか、完了件数と残件数を並べた一覧のほうが状況を正しく伝えます。 ## 関連記事 - [プロジェクト進捗管理とは？遅延を防ぐ見える化の方法と会議運用の実務](https://www.issoh.co.jp/column/details/15672/)：バーンダウン以外の見える化の方法と、進捗会議の運用 --- 出典: [バーンダウンチャートとは：見方と作り方（Excel・Jira）、発注者が遅延を見抜く読み方]()（株式会社一創）