ソフトウェア開発でガントチャートを使うってどうなんだ

ふと、ソフトウェア開発におけるガントチャートは本当に適した使い方なのかと思った。

ガントチャートは作業同士の依存関係が強く、また、リードタイムを順守することが重要なプロジェクトにおいて、その進捗と予定・実績状態を可視化するのに有効であるというのが私の理解だ。それが有効なプロジェクトとは、たとえば家の建築であるとか、大規模構造物の建設であるとか、製造ラインの立ち上げとか、そういうものを思い浮かべる。

ソフトウェア開発においても、種々の作業に依存関係はあり、また、ウォーターフォールモデル開発では特に個々のリードタイムを管理するという事は重要かもしれない。ただ、それが先に述べたような例ほど重要なことだとは思わない。依存関係のあるモジュールの開発はとりあえずモックさえあれば進められる。そもそも最近は依存関係を無くそうという運動が盛んであり、そのための種々の仕組みが整っている。テスタビリティを考えたコードは自然に独立して動作させやすくなる。

これが、先に述べたように例えば建築であれば「基礎はモックで良いから二階の内装を早く仕上げよう」なんてことはできない。作業には強い依存関係がある。であるからガントチャートで依存関係を管理し、クリティカルパスがどれか調べるのも有益だろう。しかし、ソフトウェア開発ではそこまで強い依存関係があることは少ない。

ウォーターフォールモデルについても、最近ではアジャイルやスクラムなどと言った別種の開発スタイルが登場し始めている。アジャイルやスクラムではリードタイムを管理しないのかと言うと、そういうわけでは無い(そもそもスクラムは約二週間でサイクルを回す)が、ガントチャートで管理するのに適しているというほどの強い縛りは無い。

となると、ガントチャートを使うメリットは薄い。しかも、私の経験上はガントチャートを使うのはひどくわかりにくいことが多い。数多の作業をWBSで小分けするのは良いが、それぞれに予定開始・完了日時を設定しなければガントチャートとして書けないため、これを一つ一つに設定することになる。しかも、ソフトウェア開発ではこの作業工数の見積もりというのが非常に難しい。ソフトウェア開発では普通、まったく同じものを何度も作るという事はしない。常に新しいものを作る作業だ。だから、作業工数自体の見積もりも本質的に正確でない。

先に述べたようにソフトウェア開発はそれぞれのモジュールにそこまで依存があるわけでは無いので、ぶっちゃけ順序などどうでも良い。原理上はビジネス上定められたキーデートに間に合えばそれで良いはずだ。

それぞれが実装を始めると、リソースやステークホルダーの要望などの関係上、ガントチャート上の作業順序を変えたほうがいいというケースがでてきたり、また特に理由は無くともガントチャート上の作業順序と実際の作業順序が合致しなくなってくることは良くある。すると、ガントチャート上は極端な進みや遅れとして報告されてしまう。これでは本当の進捗率が分からない。

私が思うに、多くのソフトウェア開発プロジェクトにおいて進捗を管理する仕組みと言うのは、単にTODOリストとその消化率(件数/日のような)程度で十分である気がする(TODOタスクの粒度がバラバラだとこの指標は意味をなさないので、そこは何らかの合意が必要か)。そして、現在の消化率で残りのTODOタスクがキーデートまでに消化できればオンスケジュール、そうでなければ遅れとなる。

その他の利点として私が重要だと思うのは、管理のためのコストがガントチャートに比べてずっと小さい事だ。ガントチャートは書くのも更新するのも手間がかかる。その代り、EVMだったり原価管理だったりさまざまな指標を計算することが出来るというメリットもあるが、これらを有効に使えている組織というのは果たしてどれだけあるだろうか。言い換えれば、管理能力がそこまで高く無い組織ではTODOリストの方が向いているということかもしれない。

ここでまたふと思ったのが、スクラム開発におけるバックログやスプリントログは上記のような発想とよく似ているのかも。