自然体PMのススメ：進捗管理（4/n）ガントと進捗線が破綻に導く

進捗管理の作業の１つは実績管理ですが、実績を評価する時に何を基準に評価し、その結果次のアクションをどのように決定するか？に焦点を当てます。そして、多くのプロジェクトで取り入れられているガントチャートと進捗線による実績評価が、なぜプロジェクトを破綻させてしまうかを見ていきます。

ガントチャートは継続できない

ガントチャートとは以下のような表で、WBS項目ごとにStart/Endが設定され、１つ以上のEndが次の項目のStartタイミングになっているものです。そのEnd-Startの繋がっている作業は、成果物または担当者などで繋がっていて依存性があります。

この考え方は非常にわかり易く理にかなっているのですが、ガントチャートは管理も実行も継続することが非常に困難です。前のエントリーで書いたようにシステム開発では常に予定が変わり、先になるほど詳細が見えにくくなります。このような中では、２つの別々の作業がいつどのように接続するか予想することは不可能です。WBSは通常担当者1人の作業まで詳細化しますが、僅か5人・3ヶ月のプロジェクトでさえ、変化する作業を逐次反映させながらガントチャートを維持し続けることはできないでしょう。

維持の難しさを軽減する方法としては、１つの作業スケジュールを変更すると、次の作業を自動で変更してくれるツールもあります。これは一見管理を軽減してくれそうですが、実のところ事態は変わらないか悪化します。なぜなら、前工程と後工程が強い依存性を持つこと自体が、問題の本質だからです。１つの作業が予定から遅れたら、その次の作業開始そして作業完了を遅らせることができるでしょうか？新しい作業が出てきたら、どこの線と接続させ、アサインをどのように変更すればよいのか？１つの作業が予定より早く終わったら、次の作業はいつ開始すべきか？

前後作業に強い依存性を持たせるほど、その予定表が精密に作られているほど、これを維持することは困難です。ここで思い出したいことは、ソフトウェアはそれほど工程間の依存性がないということです。画面ができなくてもバッチが作れたり、DB設計が90%でもロジックが組めたり、アプリケーションができて無くてもインフラ構築ができたりします。この自在な手順選択できることがシステム開発の長所であり、技術力の高さを発揮する場面であり、これを活かさない手はありません。そして実際のプロジェクト現場は、常にこれを利用しているはずです。つまり、ガントチャートはシステム開発には向きません。

進捗線（イナズマ線）は必ず遅れる

下図がいわゆる進捗線（イナズマ線）ですが、ガントチャートなどの各作業予定線上に現在進捗地点をプロットしてこれを繋いだものです。今日の日付で直線に下に引いた線との積分値で実績評価します。

これも考え方は非常にわかり易く受け入れ易いのですが、予定より進んでいる進捗線を見ることは稀です。これには訳があり、常にDelay（遅れ）になるようになっているのです。システム開発には常に予定外のことが起きます。UT完了のモジュールに顧客から些細な文言変更が入れば、すぐに反映作業をし、UTを行い、ソース管理を更新し、顧客テスト環境に入れなおして、報告をする。これは当然の作業ですがWBS上には無い作業です。テスト中１つのデータバグが発見され、そのことでこれまでのテストの信憑性に問題が生じ、これを報告し、正しいデータを作り、チェックし、再テストする。これも当然の作業です。つまり、WBSには書けない作業が無数に発生し、これは防ぐことのできない必然の事象です。

常にWBSに無い作業もしているので、当然WBSにある作業は遅れ、この為に、進捗線は必ずDeleyとなります。ここでガントチャートの特性である、維持管理できない特性が合わさると、時間が経過するにつれ、計画線が変更されずにDelayの積分値が雪達磨のように、どんどん膨らんでいくようになります。その時、実は遅れが膨張していることよりも、進捗管理が不能になっているという大きな問題が発生しています。なぜなら決して到達しない計画線（10/15時点で、未着手項目「ログイン画面作成」10/10完了予定みたいな）の上に進捗線を引いているので、実績の指標となる計画が崩壊していて、WBSに無い項目の作業もしているとすれば、進捗把握が不可能になっていると言ってよいでしょう。つまりこの時点では本当に大幅なDelay状態であるのか、実はそれほどではないのか、評価することができなくなっているのです。故に、もしかしたら順調なのかもしれない（もしかしたら更に悪い状態である）進捗に対して、間違った対策を打ってしまう確率が高いことになります。

キャッチアッププランから破綻に至る

Delayが言い訳できないくらいに膨らんでくると、キャッチアッププランという名目で、様々なプロジェクトリソースがこれを解消する為に動員されます。Catch-Up（追いつく）できるという前提のもとで、一時的（のつもりで）な長時間労働や新規リソース投入を行うことになります。ところが、キャッチアッププランはその名の通り、本来の計画（ガントチャート）はそのままに、ある時点までに追いつく計画なので、これはガントチャートの考えそのものであり、残念ながらうまくいきません。

キャッチアッププランはガントチャートをより複雑に硬直化します。キャッチアッププランを2度3度作り変えていくと、さらにガントチャートが複雑化し、進捗線を引くことさえ困難になってきます。こうなると、昨日はオンスケと言っていたのに今日は1週間の遅れだとか、一人が何人分もの作業担当者だったり、1ヶ月もスケジュール表を見ていないとか、そんな状態になってきます。ここまでくると、進捗管理は破綻していて、プロジェクトが悪い方向に行っていることは明白です。

ずっと泊って開発しても、ずーと会議をして良い方法を議論しても、なかなか効率は上がりません。プロジェクト遂行中は、このプロジェクトは終わりそうだと思える状態を維持しなくてはなりません。開発者は、ちゃんと終わりそうだと思えないと、力を発揮できません。どうせ終わらない、いつ終わるか分からないまま長時間働いても、生産性が非常に低い働きしかできないでしょう。

今回のまとめと次回の予定

ガントチャートを作る→進捗線を引く→必ず遅れが発見される→キャッチアッププランを追加する（元に戻る）。という、戻ってこない再帰のようなプロジェクト管理は、プログラムと同様にハングアップを誘発し易いものです。一旦負のスパイラルに入ってしまうと、抜け出すのは非常に困難なので、現場はいつも必死です。しかし、多くの場合、見積りが正しいのであれば、それほど必死にやらなくてもきちんと終わるはずです。

それはきっと無駄なことを多くやっていて、非効率になってしまうために起きていると考えるのが自然です。次回は、効率的に進捗管理をする方策を書きます。残念ながら、簡単で手軽で誰でもできて失敗しない魔法ではありません。ただ、少なくとも管理手法をより単純にしているので、より多くの人が実践できる方法ではあります。