「今週もバーンダウンチャートを共有します。進捗は順調です」。外部ベンダーに開発を任せていると、毎週このような報告とともに右肩下がりのグラフを受け取ることがあります。けれども、そのグラフを見て「本当に順調なのか」「どこかで遅れ始めていないか」を自分の目で判断できている発注者は、決して多くありません。
判断が難しいのには理由があります。バーンダウンチャートの読み方を解説する記事の多くは、線の名前や作り方を説明するところで終わっており、「発注者として、グラフがどうなったら危険信号と捉え、いつベンダーに確認すべきか」という肝心の判断基準まで踏み込んでいないからです。読み方は分かっても、行動に移す目安がなければ、結局は「ベンダーが順調と言うなら順調なのだろう」と受け身になってしまいます。
この記事では、バーンダウンチャートとは何かという基本を非エンジニアにも分かる言葉で押さえたうえで、発注者が自分で遅延の兆候を見抜き、「いつ声を上げるべきか」という意思決定のトリガーを判断できるようになることをゴールに解説します。読み方の知識ではなく、毎週のミーティングで使える判断の物差しを持ち帰っていただくことが目的です。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
バーンダウンチャートとは｜縦軸・横軸と2本の線の読み方
バーンダウンチャートとは、プロジェクトに残っている作業量が時間とともにどう減っていくかを折れ線グラフで可視化したものです。「バーンダウン（burn down＝燃やし尽くす）」という名のとおり、残っている作業を少しずつ消化し、ゼロに向かって減らしていく様子を表します。アジャイル開発やスクラムでの進捗管理に広く使われています。
非エンジニアの方が最初に押さえるべきポイントは、縦軸・横軸が何を表すか、そして2本の線をどう見るか、この2つだけです。
縦軸・横軸が表すもの
- 縦軸: 残っている作業量です。スクラムでは「ストーリーポイント」という作業量の見積もり単位で表すことが多いですが、残タスク数や残工数（時間）で表す場合もあります。発注者としては、単位そのものより「上に行くほど残作業が多い＝ゴールから遠い」という関係だけ理解できれば十分です。
- 横軸: 時間です。1スプリント（区切られた開発期間。通常1〜2週間）の日数や日付を取ります。
グラフは作業が消化されるにつれて右肩下がりになり、横軸の終点（スプリント末）で縦軸がゼロに到達するのが理想的な姿です。
理想線と実績線の違い
チャートには通常2本の線が引かれます。
- 理想線: 作業を毎日均等に消化していった場合の理想的なペースを示す、右肩下がりの直線です。スタート地点の残作業量からスプリント末のゼロまでをまっすぐ結びます。
- 実績線: 実際にどれだけ作業が消化されたかを示す、日々の実績の線です。
この2本を比べることが、進捗判断のすべての出発点になります。実績線が理想線より上にあれば、想定より残作業が多い＝遅れ気味。下にあれば、想定より進んでいる＝前倒し、という関係です（クラウドログ、Asana）。
なお、ツールによっては当初計画を表す「計画線」を加えた3本で表示する場合もありますが、発注者が日常的に見るべきは理想線と実績線の2本で十分です。
理想線と実績線の乖離をどう判断するか
「実績線が理想線より上なら遅れ」という基本だけ覚えても、実は判断には足りません。なぜなら、同じ「線が上にある」状態でも、それがいつの時点で、どれくらい離れているかによって、深刻度がまったく変わるからです。発注者が見るべきは、乖離の「有無」ではなく「大きさ」と「タイミング」の組み合わせです。
上振れ・下振れの基本
まずは基本の対応関係を整理します。
- 実績線が理想線より上: 残作業が想定より多く残っている状態。遅延の兆候です。
- 実績線が理想線より下: 残作業が想定より早く減っている状態。前倒しで進んでいます。
- 2本の線がほぼ重なっている: 計画どおりに進んでいる、最も健全な状態です。
ここまでは多くの解説記事に書かれている内容です。問題はこの先で、「上にある」ことに気づいても、それが許容範囲なのか危険水域なのかを見極められなければ、行動には移せません。
スプリント序盤・中盤・終盤で乖離の意味は変わる
同じ乖離でも、スプリントのどの時点で起きているかで意味が大きく異なります。
- 序盤の乖離: 立ち上がりに時間がかかったり、環境構築や仕様確認に手間取ったりするのは珍しくありません。序盤の小さな上振れは、慌てる必要のないことが多い段階です。
- 中盤の乖離: ここが最重要の観察ポイントです。中盤を過ぎても実績線が理想線から離れ続けている、あるいは離れる一方で縮まる気配がない場合、残り日数で挽回しきれないリスクが現実味を帯びます。Asana や Atlassian の解説でも、中盤で理想線から上に乖離している場合はタスクの再配分やスコープ削減を早めに検討するサインとされています（Atlassian）。
- 終盤の乖離: 終盤になって大きく上に離れていれば、そのスプリント内での完了はほぼ困難です。この段階では「どこまで終わらせ、何を次に回すか」の調整局面に入っています。
つまり、序盤の同じ大きさの乖離は様子見でよくても、中盤以降の同じ乖離は要注意、という時間軸の感覚が判断には欠かせません。
チャートの「形」が示す3つの危険サインと発注者の見方
実績線がどこにあるか（位置）だけでなく、実績線がどんな「形」を描いているかにも、進捗の健康状態が表れます。Atlassian などの解説では崩れたチャートの典型的な形が図解されていますが、その多くは開発チーム自身が自己診断するための視点で書かれています（Atlassian）。ここでは同じ形パターンを、発注者が「何を確認すべきか」という行動に翻訳して整理します。
横ばい（プラトー）が続く — ブロッカーや完了未移行のサイン
実績線がしばらく水平のまま動かない状態です。残作業が減っていない、つまり作業が前に進んでいないことを意味します。原因として多いのは、何らかの障害（外部の回答待ち、依存する作業の未完了、技術的な行き詰まり）でチームが手を止めている、あるいは作業自体は進んでいても「完了」とみなす条件を満たせずステータスが更新できていない、といったケースです。
発注者として確認すべきは「いま止まっている原因は何か」「その解消に発注側の判断や対応が必要か」です。横ばいの裏に発注側の回答待ちが隠れていることは珍しくありません。
後半に急降下する階段状 — タスク粒度・調査偏りのサイン
前半はほとんど減らず、後半になって一気に落ちる、階段状の形です。一見すると「最後に追い上げた」ように見えますが、注意が必要な形でもあります。前半は調査や設計に時間を割いていて成果物が「完了」に乗らなかった、あるいはタスクの分け方が粗く、大きな塊が終わるまで線が動かなかった、という背景が考えられます。
この形が毎スプリント繰り返されるようなら、発注者は「タスクをもう少し小さく分けて、進捗が日々見えるようにできないか」をベンダーに相談する余地があります。後半頼みの進行は、終盤での挽回失敗リスクと隣り合わせだからです。
右肩上がり — スコープ増大・見積もり漏れのサイン
残作業が減るどころか増えて、線が上に向かう形です。スプリントの途中で新しい作業が追加された（スコープの増大）、または当初の見積もりに漏れがあって作業量が膨らんだことを示します。
発注者にとって最も身近なのが、この形です。なぜなら、追加要望や仕様変更を発注側から出した結果としてスコープが増えているケースが多いからです。「この増加は何によるものか」「追加分は今回に含めるべきか、次回に回すべきか」を、発注者自身の意思決定として整理する必要があります。
「遅延確定」と「回復可能」を見分ける
発注者が最も知りたいのは、「この遅れは取り戻せるのか、それとももう確定的なのか」でしょう。ここを見分けられれば、過剰に騒ぐことも、手遅れになるまで放置することも避けられます。判断材料は、乖離の大きさ・線の傾き・残り日数の3つです。
介入を検討すべき乖離の目安
明確な業界標準値があるわけではありませんが、発注者が「確認の声を上げる」目安として、以下のような考え方が実務的です。
- 乖離が残作業全体の1割程度まで: 日々の作業のばらつきの範囲内に収まることが多く、ただちに問題視する必要は薄い水準です。
- 乖離が2〜3割に達し、かつスプリント中盤を過ぎている: 黄信号です。「この遅れの原因は何か」「リカバリの見込みはあるか」をベンダーに確認するタイミングです。
- 乖離が3割を超え、線が縮まる気配がない: 赤信号です。スコープ（実装範囲）の調整や優先順位の見直しを、ベンダーと正面から話し合う段階に来ています。
数値はあくまで目安であり、プロジェクトの性質によって調整すべきものです。重要なのは「何割になったら確認する」という自分なりの基準をあらかじめ持っておくことです。基準があれば、ベンダーの「順調です」という言葉に流されず、根拠を持って質問できます。
傾き（消化ペース）で回復可能性を読む
乖離の大きさと同じくらい大切なのが、実績線の傾きです。傾きは、チームが1日あたりどれだけ作業を消化しているかを表します。
- 実績線の傾きが理想線と同じかそれ以上に急: 上に離れていても、同じペース以上で減り続けているなら、追いつける可能性が残ります。「回復可能」と読める状態です。
- 実績線がほぼ水平（横ばい）になっている: 残作業が減っていない＝作業が止まっている状態で、最も警戒すべきサインです。何らかの障害（依存関係の解消待ち、仕様の手戻り、人員の問題など）でチームが前に進めていない可能性が高く、放置すると遅延が確定します（Asana）。
「線がどこにあるか」（位置＝乖離の大きさ）だけでなく「どう動いているか」（傾き＝消化ペース）を併せて見ることで、回復可能か確定的かの精度が大きく上がります。横ばいが続く実績線を見つけたら、乖離がまだ小さくても早めに状況を確認するのが賢明です。
遅延を見つけたら発注者は何をすべきか
兆候を読み取れても、次の一手が分からなければ意味がありません。発注者が遅延の気配を察知したときに取るべき行動は、大きく「確認する」「判断する」の2段階です。
まず、ベンダーを問い詰めるのではなく、状況を正確に把握するための確認から入ります。次のような質問が有効です。
- 「実績線が理想線から離れていますが、主な原因は何でしょうか」
- 「このペースで、スプリント末までに当初予定の作業は完了する見込みですか」
- 「もし完了が難しい場合、どの作業を優先し、何を次回に回す想定ですか」
- 「遅れを取り戻すために、こちら（発注側）で判断・対応すべきことはありますか」
特に最後の質問は重要です。遅延の原因が、発注側の意思決定の遅れ（仕様確認の返答待ち、追加要件の指示、関係部署の調整など）にあるケースは少なくありません。チャートが横ばいになっている裏で、実はベンダーが発注者からの回答を待っている、ということもあります。
確認の結果を踏まえ、発注者として判断すべきは主に次の3点です。
- スコープ（実装範囲）の調整: すべてを今回で完了させるのか、優先度の低い機能を次回以降に回すのか。発注者にしか決められない判断です。
- 優先順位の見直し: 限られた時間で何を先に仕上げるべきかを、事業上の重要度から伝えます。
- 意思決定の迅速化: 発注側の返答待ちが原因なら、確認のリードタイムを短くするだけで状況が改善することがあります。
遅延の発見は、ベンダーを責める場面ではなく、発注者が舵取りに参加する場面です。早く気づくほど打てる手は多く、選択肢も穏やかなもので済みます。
ベロシティと組み合わせて判断の精度を上げる
バーンダウンチャート単体での判断には、見落としがちな落とし穴があります。それを補うのが「ベロシティ」という指標です。
ベロシティとは、チームが1スプリントで平均してどれだけの作業量（ストーリーポイント）を完了できるかを表す、いわばチームの実力ペースです（Atlassian）。過去数スプリントの実績から算出されます。
なぜベロシティと併せて見ると精度が上がるのか。それは、バーンダウンチャートが「今回のスプリントの中だけ」を映すのに対し、ベロシティは「このチームがそもそもどれくらいのペースで進めるチームなのか」という地力を示すからです。
たとえば、あるスプリントのチャートが理想線どおりに進んでいて一見順調に見えても、そもそも引き受けた作業量がチームのベロシティを大きく上回っていれば、それは「最初から無理のある計画」かもしれません。逆に、今回たまたま遅れていても、ベロシティの範囲内に収まっていれば、次のスプリントで十分挽回できると読めます。
発注者としては、定期報告の際に「今回の計画はチームのベロシティと比べて妥当ですか」と一言確認するだけで、計画の現実味を測る材料が得られます。チャートの線の動きと、チームの実力ペース。この2つを重ねて見ることが、思い込みによる誤判断を防ぐ最も確実な方法です。
まとめ｜バーンダウンチャートを「意思決定の道具」にする
バーンダウンチャートとは、残作業量の推移を可視化し、進捗が計画どおりかを判断するための図です。発注者にとっての価値は、グラフをきれいに読むことではなく、それを「いつ、何を確認すべきか」という意思決定のトリガーとして使えることにあります。
最後に、毎週の確認で使えるチェックポイントを整理します。
- 実績線は理想線より上か下か、そしてどれくらい離れているか（乖離の大きさ）
- それはスプリントのどの時点か（中盤以降の乖離は要注意）
- 実績線の形と傾きはどうか（横ばい・階段状・右肩上がりは、それぞれ別の危険サイン）
- 乖離が2〜3割を超え中盤を過ぎたら、原因とリカバリ見込みをベンダーに確認する
- チームのベロシティと照らして、そもそもの計画が妥当かを確かめる
これらの物差しを持っておけば、「順調です」という報告を鵜呑みにすることも、些細な変動に過剰反応することもなくなります。チャートを受け身で眺める発注者から、数値を根拠にプロジェクトの舵取りに加わる発注者へ。その一歩を、次回の定例ミーティングから踏み出してみてください。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
