プロジェクト・・・遅延という必然

そもそも普通のやり方をしたら、プロジェクトは必ず遅れる。

普通のやり方というのは、
１．大日程計画を作る
２．仕事をWBS（Work Breakdown Structure：要するに細かなタスク)に分割する
３．納期を設定し、担当を設定する
４．週次（くらいが一般的）で進捗を管理する
という方式を指すことにしよう。

プロジェクトが遅れ始めると、大抵３．の箇所が問題になる。
つまりは、タスクに対する納期の設定が、槍玉にあがる。
担当者は、「そもそもこんな工期でできるわけね〜んだよ！！」と、必ず言う。
そして、管理者は（特にその工程が直接の責任がない他社がやっている場合）、
担当者の能力の問題にしてしまう。


では、そもそも「妥当な見積」が、計画策定時点で可能なのだろうか？
そんなことはありえない、ということは、少しでも経験のある人ならわかるだろう。
プロジェクトを進めて行くうちに、わかってくること、というのは多くなる。
それに対する対応が、当初の見込みと変わるのは、当たり前なのである。
また、「妥当な見積」が仮にあったとしても、担当者の細かなスキルの違いによるゆらぎ、
またプロジェクト中の体調や、積雪・台風などによる稼動日数の低下まで考慮に入れる、
などという、神様のようなことができるわけがない。


つまり、「完全に妥当な見積」というのは不可能である、という事実を、
受け入れるところから、すべてははじめなければいけない。
プロジェクトが遅れる原因の多くは、３．にあるわけではない。


断っておくが、「見積」ひいては「計画」が必要ではない、と、言っているわけではない。
それ自体がなくては、プロジェクトが進んでいるのか、遅れているのか、まったくわからない。
ただ、問題は、進捗確認というのは、一般に「遅れていないか」ということのみを
測定しようとするため、決してプロジェクトは前倒しにならない、ということである。


「見積が外れる」のは、本来だと、見積の工数以下でできてしまった、というのと、
見積の工数以上かかってしまった、という二つのパターンがある。
品質のよい見積というのは、その幅が小さいものである。
ところが、「見積の工数以下でできてしまった」という事実は、通常の進捗確認では隠れてしまう。


なぜか？
人は「品質を上げる」という名目のもと、期限一杯まで使って、仕事をしてしまうものだからだ。
誰も必要としていない細かな仕様書を作り、サーバのスペックがよければ隠れてしまう
抽出ロジックの最適化をして、期限を一杯まで使ってしまうのだ。
（しかも、それを「よくやった」とする風潮がある・・・困ったものだ。費用対効果こそが大事なのに・・・）


結果として、「見積の工数以下でできてしまった」が隠れて、「見積の工数以上かかった」のみが、顕在化する。
そして、プロジェクトの仕事は、前後関係が必ずあるから、「見積の工数以上かかった」事実は、
その箇所のみではなく、後続の待ち時間として増幅される。
つまり、「前の人がまだできていないからできません」という人が多ければ多いほど、
プロジェクトは加速度的に遅れていくのだ。


ではどうするのか？
それはまた、日をあらためて書くことにしよう。