ガントチャートを捨てろ

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

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

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

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

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

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