ガントチャートを捨てろ(4) タスクボードとバーンダウンチャート

前回(→こちら)はバーンダウンチャートとバーンアップチャートの併記によるメリットについて述べました。じゃあそのバーンダウンチャートとバーンアップチャートはどうやって作ればいいの？ということで、今回はタスクボードについて紹介したいと思います。

ということで早速、実物を見ていただこうと思います。

これがタスクボードです。一部を伏字にしていますが、実際に仕事で使ったものです。

このプロジェクトでは、Redmineのチケットを一つの単位として管理していました。チケット番号を左端に記入し、チケット題名を記入します。このチケット題名ですが、なるべく主語を明確にします。例えば、「サイト訪問者として○○を選択できるようにする」などです。このように主語を明確にして利用者の立場から機能要件を表現したものを「ユーザーストーリー」と呼びます。つまり上の図ではRedmineとの連携を意識して「チケット題名」と書いていますが、ここは「ユーザーストーリー」と書いてもいいのです。

その横の「SP」は「ストーリーポイント」です。「ストーリポイント」とは、ストーリーの大きさを表す相対値です。相対値なので、あるストーリーを5と決めたら、その2倍の大きさのストーリーは10となります。別にこれを10と20にしてもいいわけです。

そして、各チケット（のストーリー）をタスクに分解し、各タスクの時間を見積ります。
上の図では、細かく分解してありますが、実際には最初から詳細にタスク分解する必要はありません。例えば、最初の時点では

・ 仕様・タスクを定義する
・ 実装
・ 調整
・ テスト実施、バグ修正を行う

の4つのみに分解しておき、タスクをこなしながら実装方式検討や実装の細かい分類のタスクなどに細かく分解していけばいいのです。その際、ストーリーごとの見積時間の合計が変わらないようにしておけば、全体として整合性が保たれます。

ここで、ストーリーポイントとそのストーリー中のタスクの見積り時間の合計がほぼ対応するようにします。例えば上の図では、各チケット（のストーリー）のタスクについての見積時間の合計は、「ストーリーポイント×4」になっています。厳密に合わせなければいけないわけではないですが、だいたい合わせるようにします。

例えば上の図でチケット#30は「実装(処理)」が5時間、「実装(権限制御)」が5時間となっていますがもともとは「実装」の1つで10時間と見積もっていたものです。これを作業をしながら前述の2つに分けたのです。

各タスクについて、現在の状態に応じて「未着手」「作業中」「完了」の欄のどれかに印をマークします。また、着手した際には「着手日」に、完了した際には「完了日」に日付を記録します。

「残り時間」「完了時間」「進捗率」はExcelの機能で自動計算することができます（「完了」列にマークされているかどうかを判断して計算します）。

タスクボードの下部には「見積時間」「残り時間」「完了時間」「進捗率」の合計値がExcelの機能で自動的に算出されるようになっています。

タスクボードからのバーンアップ・バーンダウンチャートの作成は簡単です。

1日ごとに「残り時間」の合計を記録すればバーンダウンチャートになります。

また、「見積時間」の合計と「完了時間」の合計を記録すればバーンアップチャートになります。

このタスクボードは、ガントチャートとセットで使われるWBSと以下の点で違いがあります。

• 最初から全てを分解する必要がない
  WBSの場合は、作業を分解すること自体が目的でした。それに対してタスクボードは進捗把握が目的です。分解の粒度は進捗を把握するのに必要なだけなので、作業にとりかかる直前でも構わないのです。
• 順番を意識しなくてよい
  WBSの本来の定義では順番は関係ないのですが、WBSは殆どの場合ガントチャートとセットになるため順番を意識せざるを得ません。タスクボードは残り時間と完了時間の合計値さえ計算出来れば良いので順番は関係ありません。
• 同時並行作業もタスクとして書ける
  WBSの場合、やはりガントチャートに対応させる関係上、分解したタスク同士は同時並行で作業を進める前提にはできません。タスクボードの場合は残り時間と完了時間の合計値が計算できればいいだけなのでタスクを同時並行して進めても一向に構いません。

ということで、4回にわたってお伝えして参りました「ガントチャートを捨てろ」シリーズですがいかがでしたでしょうか。これをお読みの皆様の中で1人でもお役に立てましたら幸いです。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ガントチャートを捨てろ(2) バーンダウンチャートを使う

さて、前回（→こちら）はガントチャートを捨てろと言い出したわけですが、代わりに「バーンダウンチャート」を使っていると書きました。

とりあえず実物を見ていただいたほうが話が早いので、さっそく以下の図をご覧ください。

あれだけガントチャートを批判しておいて、どんな凄い物が出てくるんだと期待した方には拍子抜けするかもしれませんが、至ってシンプルなグラフです。

しかしこの単純なグラフこそ、ソフトウェア開発者にとってガントチャートよりも実践的な、現実に即した進捗管理ツールなのです。

バーンダウンチャートでは縦軸に残タスクの量、横軸に時間を取ります。上記の例では縦軸に残タスクの見積もり所要時間合計、横軸に日付を取っています。

横軸の範囲はプロジェクトの進め方に応じて決めればよいのですが、上の例では次のバージョン（公式リリース用ではなく内部管理用のバージョン）の完成予定日までにしています。

毎日帰る前に、残タスクの見積り時間の合計をグラフに記録していきます。
残り時間合計が減っていき、グラフが一番下まで行って横軸と交わったら完了です。

このバーンダウンチャートを使うと、次のように前回挙げたガントチャートの欠点を回避できます。

• 順番を意識しないでいい
  ガントチャートは作業の順番に依存した描き方でしたが、バーンダウンチャートは残り時間の合計を記録していくので、途中で作業の順番を入れ替えようが関係ありません。
• 見積りの変更に強い
  仕様変更や作業時間の見積もりが間違っていて工数を変更した場合でも、グラフを変更したあとの数値で続けて書いていけばいいだけです。書き直しは発生しません。
• 開発スピードが分かる
  これが一番のメリットでしょう。グラフの傾きで一目で分かります。しかも結構初期の段階で分かります。
  
  そして突発的トラブルで遅れているのか、開発スピード自体に問題があるのかも判別をつけやすいです。突発的トラブルなら、グラフの傾きが突然鈍くなるはずですが、そもそも開発スピード自体が遅いなら、グラフの傾きは最初から鈍いはずです。
  
  グラフの傾きを見ることで、頑張れば挽回できるのか、それとも無理なのかの判断材料にすることが出来るのです。

ちなみに上記のグラフは実際に僕が仕事で記録したデータそのものです。推移を見ていくと、

・1/16(水)～1/18(金)辺りで何らかの事情によりペースが落ち、
・遅れを取り戻すため、やむなく土日出勤し、
・次の週、頑張って追い込みをかけ、
・スパートかけた甲斐あって最後の１日は余裕を持って終了

といった生々しい状況（笑）を読み取ることができます。このような状況をあとから時系列に沿って振り返ることも、ガントチャートでは不可能ですがバーンダウンチャートなら可能です。

また、バーンダウンチャートはExcelで簡単に作れます。こんな感じで表を作ってグラフにしていました。

なお、表とグラフ横軸の土日はもともと存在せず、あとから足しました(もちろんです)。単純に表の行を足せば自動的にグラフに反映されるので変更は簡単でした（Excelグラフのいいところですね）。開発状況の方は大変でしたが（苦笑）。

ちなみにこの「残り時間合計」をどうやって計算するのかというと、実はバーンダウンチャートと組になるもう一つのツール「タスクボード」を使うのです。タスクボードについては別の記事で改めて取り上げます。（→こちら）

さて、色々とメリットがあるバーンダウンチャートですが、もちろん万能ではありません。

• 横軸が一定以上長くなると使いづらい
  例えば横軸を1目盛1日に取る場合、1週間～4週間くらいまでが使いやすい範囲といえるでしょう。それ以上になるとかえって見にくくなってきます。
  
  その意味でバーンダウンチャートはアジャイル開発手法には最適です。アジャイルでは繰り返しの単位を1週間～4週間で設定することが多いからです。そもそも僕はアジャイル開発の書籍でバーンダウンチャートを知りました。
  
  反復型開発やウォーターフォールモデルなどでバーンダウンチャートを使う場合、設計・実装・テストの各工程ごとに別々のグラフを描くと良いでしょう。それでも期間が長いようなら、更に各工程内部で幾つかに分割するなどの工夫が考えられます。
• タスク総量が増加したことと開発が滞っていることの区別がつかない
  前述のように突発的トラブルが発生したこと自体は、グラフの傾きが急に鈍くなることから分かります。しかし、そのトラブルの内容が「開発が進んでいない」のか、「開発は進んでいるがタスクの総量が増えてタスク残量が減らなくなった」のかの区別はつきません。

２点目のタスク総量の変化の読み取りについては、「バーンアップチャート」を併用することにより克服できます。僕も実際はバーンダウンチャートとバーンアップチャートを併用しています。こちらも詳しくは別記事に書こうと思います（→こちら）。

ガントチャートを捨てろ

ソフトウェア開発者は、スケジュール管理の視覚化というとまず「ガントチャート」を思い浮かべる人が多いのではないでしょうか。

では、ガントチャートを選んだ理由は？と聞かれると、「標準的に使われているから」などの理由しかなくて、ガントチャートを使うことの利点を意識していたわけではないと思います。

僕はもう丸1年以上ガントチャートを使っていません。代わりに「バーンダウンチャート」を使っています。（バーンダウンチャートについては、別の記事で改めて書こうと思います→こちら）

ガントチャートを使っていると、次のような点で「ソフトウェア開発にそもそも向いていない」と感じます。

•  順番を意識しすぎる
  ガントチャートはそもそも、建築や製造など、原則後戻りをしない作業工程からなるプロジェクトの進捗状況を把握することに向いています。作業の順番を強く意識した描き方になっているからです。
  
  しかしソフトウェア開発は計画した順番通りに作業を進められる場合ばかりではありません。作業の順番を入れ替えた際にガントチャートは大幅に描き直さなけれなならず、管理の手間が掛かり過ぎます。
  
  逆に作業順序をガントチャート通りにやろうとして却って非効率になってしまっては本末転倒です。
•  見積もりの変更に弱い
  順番だけでなく、それぞれの作業工程の工数が、仕様変更やそもそも見積が間違っていた場合などで変更された時にも、大幅に描き直さなければなりません。
•  開発スピードが分からない
  ソフトウェア開発におけるマネジメントの最大の目的の1つは、期限までに間に合うかどうかを常に把握することです。
  
  ここはソフトウェア開発の難しいところですが、「だいたいこのペースで進む」という「スピード」の予測は非常に立てづらいのです。スピードは仕様や開発環境、メンバーの経験・能力・心理・健康状態など様々な要因を受けて変わりやすく、事前の計画段階で正確に予測するのは事実上不可能と言っていいと思います。
  
  さて、ガントチャートで把握できるのは「遅れているか、進んでいるか」だけです。例えば2日分遅れがあるとしましょう。一日の作業時間を7時間とすれば、14時間分の遅れです。しかし、その遅れが、開発の「スピード」自体が遅くて少しずつ積み重なって現れた14時間なのか、それともスピード自体は問題なかったものの、突発的にトラブルが発生したので現れた14時間なのか区別がつきません。
  
  突発的トラブルならば、その14時間の遅れはプロジェクトの残りの期間も（別のトラブルが発生しない限り）同じであると予想出来ます。
  
  しかし、スピード自体が間に合っていないなら、14時間の遅れはプロジェクトの残りの期間でさらに20時間、30時間と拡大していってしまうかもしれません。
  
  ここを把握できるかどうかはまさに致命的です。突発的トラブルによる遅れなら、頑張れば挽回できるのかもしれません。しかしスピード自体が頑張っても無理なほど足りないなら、すぐに作業分担の変更か、増員か、期限の延長か、仕様の削減を検討するべきでしょう。
  
  しかしガントチャートでは「スピード」を把握することが出来す、遅れにどう対処すべきかの判断材料としては得られる情報が不足しているのです。

このようにガントチャートはそもそもソフトウェア開発に不向きな点があります。僕はより現実的なスケジュール管理視覚化のツールとして「バーンダウンチャート」を使っており、別の記事で改めて書こうと思います(→こちら)。