ガントチャートの光と影

プロジェクト管理といえば、ガントチャート。
ガントチャートの良い部分と悪い部分についてメモ。

【参考】
下記の連載記事は、初心者向けのガントチャートの記事で読みやすい。

初めてのガントチャート（1）：ガントチャートって何ですか？ - ＠IT

初めてのガントチャート（2）：いまさら聞けない8つのガントチャート基礎用語＆タスクを洗い出すときの注意点 (1/2) - ＠IT

初めてのガントチャート（2）：いまさら聞けない8つのガントチャート基礎用語＆タスクを洗い出すときの注意点 (2/2) - ＠IT

初めてのガントチャート（3）：Excelガントチャート作成の基本＆関数とグラフで負荷状況を「見える化」する (1/2) - ＠IT

初めてのガントチャート（3）：Excelガントチャート作成の基本＆関数とグラフで負荷状況を「見える化」する (2/2) - ＠IT

【1】ガントチャートは、作業が予測しやすく、工場のラインのような流れ作業では威力を発揮すると思う。
最初に、計画時点で、バシッとタスクをすべて洗い出し、タスクの先行・後続の関係、タスクの詳細化ができれば、すごく扱いやすい。

ガントチャートの利点は、予実管理が一目で分かることだ。
MSProjectのように、ガントバーが予定、実線が実績を表すから、イナズマ線を表示すれば、どのタスクが凹んで遅れているのか、がすぐに分かる。

また、ガントバー＝WBSなので、担当者をアサインしておけば、プロジェクトの負荷状況も自動計算できる。
上記の連載記事では、日付別・タスク別に、担当者が作業する点をプロットしておけば、「=COUNTA（F4:F:44）」という計算式で簡単に負荷状況を計算できる。
MSProjectならもっと綺麗に表示してくれる。

作業の負荷状況は、プロジェクトリーダーにとって重要なビューの一つだ。
PJ別、週別、担当者別に作業予定表を事前に作成しておくことで、今引合中の案件に誰をアサインできるか、これから開発・テスト工程でたくさんのメンバーが必要になるプロジェクトにどれだけのリソースを確保すべきか、を予測したいからだ。

【2】しかし、ガントチャートはソフトウェア開発の作業に向いているようで向いていない部分が多いように思う。
理由はいくつかあると思う。

【2-1】一つは、見積もり時や受注直後では、プロジェクトの作業全てを洗い出せない場合、ガントチャートが作りにくくなることだ。
ソフトウェア開発では、初めて取り扱うアーキテクチャやフレームワークとか、初めての顧客の開発では、どうしても不明点が多い。
全てのリスクを洗い出せないし、リスクの広さや深さも正直分からない。
エイヤーで見積り、スケジュールを大まかに引いて、作業を始める。
そして、ズルズルと作業が延びてしまい、納期間近になって、火を噴くことがすべての関係者に知れ渡る。

本来、ガントチャートは、製品組立ラインのように、たとえば、旋盤→組み立て→梱包のように各工程がオーバーラップしない場合は扱いやすい。
特に製造業では、各工程の作業時間そのものを全て統一化することで、流れ作業をやりやすくし、作業効率を高める手法を取る。
いわゆるラインバランシングだ。

しかし、実際のソフトウェア開発はもっと汚くてドロドロしている。
顧客や上司に見せるときには有効だが、実際の開発では、タスクかんばんのように、チケット単位で作業する方が開発者は作業しやすいように思う。

【2-2】もう一つは、作業の粒度が小さくなるほど、ガントチャートが保守しづらく、ガントチャートの精度が逆に悪くなることだ。

PMBOKでは、一つのWBSの単位は約2週間位の粒度を勧めていた。
それ以上小さいと逆に細かすぎて管理しにくくなる。
また、顧客や上司の観点では、そんな詳細レベルの進捗ではなく、機能(フィーチャ)単位の進捗が知りたいのだ。

しかし、実際の開発では、週レベル、日レベルにもっと細分化しないと、開発者は作業しにくい。
すると、WBSを5階層くらい細かく階層化して詳細化していく。
そうすれば、作業しやすくなるが、WBSの変更や最新化が非常に大変になる。
WBSに先行・後続の依存関係をつけていれば、なおさら、一つの変更が他のWBSにも影響してしまい、整合性が取れなくなる。

たとえば、50人月や100人月の案件では、WBSは簡単に数千行くらいに膨れ上がってしまう。
Excelで管理しようとすると、とても把握しきれない。

だから、週末に必ず、Excelのガントチャートに予定と実績を開発者に入力させ、その後に、ガントチャートのExcelを集計する担当者がExcelマクロを使って、綺麗なガントチャートを出力したり、予定・実績工数を集計したりする運用をやっている。
今時、そんな運用をしているの？と思ってしまうが、大規模案件では、進捗管理のためだけの要員を確保するコストも確保できるから、実際にやっている場合が多い。
毎週または毎月、バーンダウンチャートを綺麗に作るために、PMOが頑張っている案件を見たこともある。
そんな作業は正直、コストの無駄遣いだろうと思う。

個人的には、綺麗なWBSを作って管理するよりも、2週間～1ヶ月くらいのマイルストーン単位で区切って作業する方が、進捗管理も楽だし、開発者もゴールが見えやすいと思う。

【2-3】さらに、ガントチャートでは、QAや障害などの管理が漏れやすいことだろう。

仕様書の文言の不備、あいまいな要件、テストで突然発覚したバグなどは、当初の計画からは予測できない。
WBSで1つずつ行を追加していくと、管理できそうな気がするが、どれが完了していて、どれが優先すべきなのか、が分かりにくい。
さらに、QAは何度もやり取りしてFixされるものだから、進捗率もコロコロ変わる。
QAや障害は、進捗率よりもステータスで管理すべきものだ。

すると、ガントチャート以外のExcel管理表に記載して、まとめて管理するようになってくる。
Excelのガントチャート、QAのExcel管理表、Excelの障害管理表と、どんどんExcelの管理書類が増殖していく。
しかも、Excelの管理表を開かないと、実際の進捗状況も分からない。

@sakaba37さんが提唱されている「アダプタブルWF」では、WF型開発から漏れているこれらの課題管理・障害管理こそ、チケット管理すべきだ、という発想になる。
チケット管理は、作業よりも、QAや障害の管理の方が相性はいい。

【3】個人的には、ガントチャートが悪いのではなく、ガントチャートはプロジェクト管理で必要なビューの一つに過ぎない、という点を見落としているだけだと思う。
ガントチャートだけで、プロジェクト管理が全て可能である、と思い込むこと自体が間違っているのだ。

ガントチャート、リソースヒストグラム、EVM、信頼度成長曲線、かんばん、バーンダウンチャート、累積フロー図(CFD)など、色んなビューがあるが、それらはチケット集計という機能にすべて置き換えて、必要なタイミングでビューをそれぞれ切り替えれば、もっと管理作業は楽になるだろうと思う。
作業はチケットに置き換えれば、チケット集計で多様なビューを表現できればいい。
ガントチャートは、所詮、チケット集計における1個のビューにすぎないのだ。

Redmineでは、ガントチャートがデフォルト機能だが、それ以外のビューももっとあったらいい、と思う。
そして、どのビューがどんな時に有用であるか、をもっと整理してみたい。
その考えは、チケット駆動において有用なメトリクスとは何か、という問題につながると思っている。

【追記】
参考になるつぶやきを見つけたのでメモ。

三浦　元さんはTwitterを使っています: "@akipii ガントチャートは現場での管理に向いているが、立案や変更検討には向いていない。そちらはPERTがはるかに使いやすい。僕はPERTで立案してガントで現場展開することをやっていたが、問題はまともなPERTツールが三菱ソフト製を除いて市場から消えてしまったこと。"

三浦　元さんはTwitterを使っています: "@akipii ガントでもPERTでも、ステータス管理となるタスクを表現・管理しづらいのは同意。最遅終了日を設定して完了かどうかで管理することになるだろうな。"