ガントチャートを捨てろ(3) バーンダウンチャートとバーンアップチャートを併記する

前回(→こちら)はガントチャートを捨てて、代わりに「バーンダウンチャート」を使うことを提案しました。その具体的メリットと、どんなプロジェクトに向いているかもまとめました。

そこで、バーンダウンチャートの弱点としてグラフの傾きが鈍くなった際に「開発が進んでいない」のか、「開発は進んでいるがタスクの総量が増えてタスク残量が減らなくなった」のかの区別がつかないことを挙げ、それは「バーンアップチャート」を併用することにより克服できると書きました。

ではその「バーンアップチャート」とは何なのか、さっそく以下の図をご覧ください。

これが「バーンアップチャート」です。バーンダウンチャートと同じく横軸に時間を取りますが、縦軸はタスクの量として見積時間合計と完了時間合計の2つのグラフを書きます。

上記の例では赤い線が見積時間合計、すなわち期限までにこなすべきタスク全体の合計量を表しています。青い線は完了時間合計、すなわちその時点までに完了したタスクの合計量を表しています。赤い線と青い線が交わったら完了です。

ちなみに、この赤い線と青い線の距離は残タスクの合計、すなわちバーンダウンチャートになるのですね。

このバーンアップチャートがバーンダウンチャートと違う点は、タスク総量の変化を表現できることです。タスク総量が変化するのは、例えば急な仕様変更が入った場合や、タスクに要する時間の見積りを間違えていて修正した場合などが考えられます。なお、そういうことがなければ見積時間合計の線は横一直線になります。

例えば上記の例は前回用いたの同じく私が実際に仕事で記録した例ですが、1/19に見積時間合計が増加しています。これは、実際に開発を進めたところ、当初のタスク見積よりもタスクが多かったため、見積時間を多く修正したのです。

そして、純粋な開発速度そのものを表現できるのも強みです。完了時間合計の線の傾きを見れば、タスクをこなすスピード自体がわかります。この傾きが一定であれば、同じペースで仕事をこなせているということです。

さて、ここまでお読みになると「バーンダウンチャートとバーンアップチャートを状況に応じて使い分ければいいのかな」と思われるかもしれません。しかし使い分けるよりも、バーンダウンチャートとバーンアップチャートを併記すると面白くなります。例えば以下の図をご覧ください。

左右の図は別の角度から同じ状況を表現したものです。しかしここから、バーンダウンチャートだけではわからなかった事実を次のように読み取ることができます。

• バーンダウンチャートを見ると、1/16～1/19にかけて傾きが鈍くなり、開発スピードが落ちているように見える。特に、1/19は全く開発が進んでいないように見える。
• 一方バーンアップチャートを見ると、1/19には完了時間合計はむしろ急に増えており、開発は進んでいないどころか、頑張ってかなり進めたことが分かる。そしてこの日に見積時間合計がこなしたタスクと同じくらい増えていた。これは甘かった見積りの修正であった。
• つまり途中でつまづいていたわけではなく、この部分で取り掛かっていたタスクの見積りが甘かったことが原因だった、ということが読み取れる。

いかがでしょうか？このようにバーンダウンチャートとバーンアップチャートを併記すれば、後から振り返った場合に、どういう状況だったのか分析しやすくなります。次の開発に向けて反省点を見つけやすくなるのです。

上記で挙げた例は見積りが甘かった例ですが、これがもし仮に仕様変更によるタスク増加だった場合、仕様変更が原因で開発が苦しくなることを明確に説明できるツールになります。なぜなら、バーンダウンチャートの傾きが鈍くなったとき、バーンアップチャートの完了時間合計の傾きが一定で見積時間合計が増えているならば、開発速度は本来落ちていないのに、仕様変更により遅れが発生したことが明確にわかるからです。これは仕様変更に対抗する武器になりえます。

前回と今回にわたってバーンダウンチャートとバーンアップチャートの説明をしたわけですが、これらのグラフを描くには、残タスクの量あるいは完了タスクの量を計測することが必要です。それを計測するためのツール、すなわちバーンダウンチャートとバーンアップチャートを描くためのツールに「タスクボード」があります。タスクボードについての詳細は記事を改めて書こうと思います。（→こちら）