Burndown Chartとは
アジャイル開発の現場でよく使われる、進捗状況の可視化手段の１つで、
残作業量（残工数や消化したStory Point）と稼働日数をグラフにプロットし、
進捗の進み具合を確認したり、作業完了の目途を把握することに便利なグラフです。
Burndown Chartの優れている点
①導入・管理が容易で、コストが低い
管理対象のプロジェクトチームの残作業量の総計を毎日グラフにプロットするだけです。
そのため導入、管理が簡単で、運営コストが低く、使いやすいものです。
②シンプルな表現なので、分かりやすい
グラフがシンプルなので、進捗の進み具合や遅れを把握しやすいです。
初心者の方や若手チームメンバーにも理解しやすいため、チーム全体での共有に向いており、毎日の朝会や夕会でのBurndown Chartを使った情報共有により、チーム内コミュニケーションの活性化にもつながります。
③リアルタイム性
リアルタイムで残作業量がグラフに反映されるため、プロジェクトの遅れの早期発見や対策実行につながります。
Burndown Chartの苦手な点
①スコープの変化に対応しづらい
Burndown Chartは、プロジェクト中の任意の対象期間（アジャイル開発であれば、スプリントやリリース単位）の進捗状況を把握することに利用されます。ただし、その期間中に発生したスコープの増減に対して、正しく対象期間の進捗状況を表現しにくいです。
例えば、想定外の仕様変更により、そのスプリントの残作業量が急増してしまった場合、正確な進捗の進み・遅れを見分けづらくなってしまいます。
②進捗の誤認を招く可能性
一見、シンプルなグラフなので進捗状況が把握しやすいと思われがちです。 しかし、解像度が粗いために、下記のような誤認を招くリスクが伴います。
- 残作業量の単位を工数で管理した場合、タスクが完了していないのに、進捗が進んでいるかのように急激にグラフが下降します。
- 残作業量をストーリー完成で管理した場合、ストーリーが完了するまでの日々は、タスクとしては進捗しているが、完了になっていないため、進捗が遅れているかのように表現されてしまいます。
- グラフの傾きの急激な下降や鈍化の要因は、Burndown Chartからでは把握できません。
③管理対象のプロジェクトの特性に依存
①、②の通り、進捗管理・可視化の解像度としては精度が粗く見えます。
各タスクの進捗を逐次チェックする必要があるプロジェクトにはBurndown Chartは不向きです。
期限が決められており、スコープの達成責任が厳格なウォーターフォール型のプロジェクト管理には向いていません。
対策術
苦手な点に対しての対策ですが、以下のアイディアはいかがでしょうか？
①スコープの変化への対応
グラフを少し工夫して、積み上げ棒グラフにします。
既存でスコープに入れていたタスクと、追加したタスク、スコープアウトさせたタスクを色分けして表現することで、スコープの変化による進捗への影響を把握しやすくなります。
②適切サイズにタスク分割
タスクの単位が大きすぎると、適切な進捗状況が把握しづらいです。
例えば、2週間毎のスプリントで進むプロジェクトに対して、1タスクの単位が1週間では、
タスクサイズが大きすぎるため、進み具合や遅れが判断しにくいでしょう。
半日、1日分程度に、タスクを細分化するなどして、進捗把握がしやすい単位までタスクを分解しましょう。
③ 他の管理手法との併用
タスクの優先順位管理をするには、カンバンボード、タスクの依存関係やリソース配分を可視化、管理するのであれば、ガントチャートなど、Burndown Chartが苦手な観点に対しては、別の管理手法で補うことも有効です。
最後に
Burndown Chartは、プロジェクトの進捗管理手法としてはとても有用なものと言えます。
管理対象のプロジェクトの実態に合わせて、適宜カスタマイズしたり、
他のプロジェクト管理ツール・手法と組み合わせ、健全なプロジェクト運営を実現しましょう。
以上です。
