バーンダウンチャート / バックロググラフっていいね。 - 遅れなんか見たくない。いつ終わるかを見たいんだ。
山積みの丸太を一本一本燃やし尽くす。
バーンダウンチャート/バックロググラフ。
アジャイル系ソフトウェア開発マネジメントから出てきたプロジェクト進捗の可視化法だが、これ、いい。
横軸を時間軸とし、縦軸に残作業量をプロットしていく。残作業の減り具合(増え具合)を見る。
この、「増え具合」、がミソ。
計画駆動型ウォーターフォールタイプの進捗管理では、ベースラインからの偏差で進捗を見る。ところが、ベースラインちゅうもんから現実がどんどん離れていくんだ。
外部からの変更、仕様が変わる、もあるし、内部からの変更、要素技術の完成度によりシステム全体に影響を及ぼすこともある。
ところが、初期計画からの偏差で進捗を見られると、すべて遅れとして現れるだけ。
進捗は、(実施作業量/総作業量)なんだが、作業はたくさん実施してるのに、分母の方が増える、丸太が積み増しされている状況で、「遅れてる」と言われる。まったくもって心外なものだ。
増えた作業を含め、残作業を見る! そして、期日に終わらせる!
上位管理者が一番見たいのは、あとどれくらいかかるのか、だ。
「細かい仕様は適切に顧客を満足させればいい、技術的な問題は解決してくれればいい。難しいからどうたらこうたら、なんて言い訳は聞きたくない。リスク? 聞きたくない。対処してよ。」
プロジェクトマネジャーも、やはり一番のキモは、残作業の総量だ。氷山のような根深い課題にあたったり、リスクが顕在化したら、残作業が増える。これを見て、スコープ、リソースをなんとかして、なんとかする。(マネジメントの訳語は[管理]ではない。[なんとかする]、なのだ。)
で、こんな感じ。

◇バックロググラフ、という言葉は、スクラム本(*)に出てくる。
横軸は時間(一ヶ月に小分けしたスプリントでは、日単位、全期間では月単位)
縦軸は見積もり工数。
真面目な会社では、この名前のほうが良いかな。
◇バーンダウンチャート、は、『リーンソフトウェア開発』等。
永和システムマネジメント 平鍋氏(*)、角谷氏(*)が実践発表して、こちらの名称が一般化してきた。
燃やしていく、BURN DOWN 乗りについていける会社ではこちらの名前で。
デイリービルドでがんがん、
一回のイテレーションを5日~10日程度で、縦軸タスク数。(総数70くらい)の例。
- 「見える化」の実践の『見える化』永和システムマネジメント 角谷信太郎
※ 『リーンソフトウェア開発』ではスクラム本と同じく縦軸は見積もり工数。
■ 縦軸に見積もり工数を取った場合、工数ベースのEVMS(*)をひっくり返した形に近い。
つらいのは、見積もり工数を積み上げるところ。ボトムアップ見積もりを完成するのは計画段階ではやりきれない(というのが計画フェーズの矛盾なのだが)ものだし、変更管理も大変。
さらに、大きなプロジェクトを全部積み上げてしまうと、見るからに苦しさが増すだけ、という感じはある。
アジャイルでは、一ヶ月単位等に小分けする。スパイラルタイプとか、あるいは、ウォーターフォール/ステージゲートタイプでは、概算と小分けの運用をうまく工夫する必要はあるだろう。でも、とにかく、あとどれだけの仕事があるのか、を見たいよね。
角谷氏の例では、[ソフトウェアかんばん]タスクカードの数を数えているので、極めてシンプル。
EVMS(Earned Value Management System)のような精密感覚を脱却し、小分けで考えれば使えそう。
※プロット毎に残作業を見積もるということは、過去作業の作業効率から完成時コストを延長推定する(簡易)EVMSよりも本質的には厳密なもの。アジャイル精神、開発チームが作業をコントロールするためのツールとして使うのは楽しいが、超精密管理感覚で上から強制実施すると、むちゃくちゃ苦しくなりそうな、危ないグラフでもある。(※追記:2005.7.26)
■そもそも、EVMSとバックロググラフでは、根本的な発想が違う。
EVMSは、計画(WBS)を絶対視したうえで期間と費用の計画偏差を是正しようとする。ベースライン計画に如何に収束させるか、という発想で、予算化した計画を動かすことはほとんど拒否する。
バックロググラフでは、期間固定で、計画(WBS)が流動するものとする。一定期間内に出来ることでとにかく切りをつけよう、という発想になる。
■完璧なモノを遅らせて出すより、多少の抜けがあってもまずは完成させるほうが、経営発想では、かなり現実的。で、現実にはそんなふうに運用されている。なのに、マネジメントシステムがウォータフォールではまずいよなぁ、やっぱり。
--------
(*)スクラム本1: アジャイルソフトウェア開発スクラム ケン シュエイバー (著), マイク ビードル (著),
(*)スクラム本2: スクラム入門-アジャイルプロジェクトマネジメント ケン・シュエイバー (著)
1のほうは、バックロググラフ。2のほうは、バーンダウンチャートとの記載。
(*) バーンダウンチャートの実例:
- バーンダウンチャートの紹介 永和システムマネジメント 角谷信太郎
- 「見える化」の実践の『見える化』永和システムマネジメント 角谷信太郎
(*) その他、永和システムマネジメント のオブジェクト倶楽部イベントの資料はおもしろい。
2005年夏イベントキーノート
プロジェクト・ファシリテーション~ものづくりからチームづくりへ~ 永和システムマネジメント 平鍋健児
| 固定リンク
「7 プロジェクトマネジメント」カテゴリの記事
- PMPです。(2005.09.03)
- バーンダウンチャート / バックロググラフっていいね。 - 遅れなんか見たくない。いつ終わるかを見たいんだ。(2005.07.24)
- [実績ベースで30日かかる仕事]を[20日で実行する]という目的を立てることの是非(2005.05.30)
- 仕事は、遅れることはあるが、早く終わることは無い。(2004.05.27)
- プロジェクトマネジャーの悩み 権限はないのに、責任だけがある。(2005.01.18)
コメント
「遅れなんか見たくない。いつ終わるかを見たいんだ。」
この見出しの一文に痺れました。
カーナビも、何分遅れ、なんて表示はしないで、淡々と到着予想時刻をupdateしていますよね。
投稿: susatadahiro | 2005.07.26 00:40
susatadahiro さん、コメントありがとうございます。
カーナビのようにスルスルと計画が出来て、渋滞も避けて走れる、といいですねぇ。
プロジェクトを進めるときのアナロジー、プロジェクトナビゲーションのイメージを考えてみるのはおもしろそうです。
ただ、カーナビの凄まじい機能と進化を見ていると、そのソフト開発はオソロシイことになっていそう、、、現場を想像してしまいます。
渋滞にはまりながら、抜け道を探しながら、楽しく地道に淡々とプロジェクトを進めていくことにしましょう。
投稿: 円山貫 | 2005.07.26 08:13