suVeneのアレ

プロジェクト管理の中のひとつ、スケジュール管理、或いは進捗管理についての考え方。
その中でも特に、「納期」について。

はじめに

プロジェクトを遂行していると、必ずといっていいほど「遅れ」が出てくるものである。それは何故なのか。どうすればよいのか。を、個人的な観点で、今の考えを整理。主にソフトウェア開発。

スケジュール管理について

スケジュールは遅れるものである

まず、スケジュールが遅れるのはなぜか。

• 納期・計画がそもそも無理
• 度重なる仕様変更が抑えきれない
• 立ち上げが遅く、各フェーズ開始時には、既に○ヶ月遅れだった

などなど。

このなかで、一番最初の「納期・計画がそもそも無理」は、個人の努力ではなかなか改善しようがない部分が多いが、「ある程度バッファがある」と思っていたプロジェクトですら、いつの間にか「遅れ」が出てくるものである。

これは何故なのか。

それは、従属関係にあるタスクというのは、そのタスクごとの繋がりが密であればあるほど、予定通り開始することが可能な可能性は少なくなっていくからではないか。

例えば、ここに 10個のタスクがあるとする。このタスクはそれぞれ、バッファを見ており、予定通り終わる可能性は 90% ほどだとする。そしてこの 10個 のタスクがそれぞれ「must Finish task to Start task」の関係にあるとするならば、10個のタスクが予定通り終わる可能性は、

90% * 90% * 90% * 90% * 90% * 90% * 90% * 90% * 90% * 90% ≒ 34%

ほどである。

つまり、途中で何も手を打たなければ、7割弱の可能性で予定通り全てのタスクは完了できない。

「遅れ」は伝播し、「進み」は伝播しないものである

従属関係にあるタスクは、従属してることにより「遅れ」は必ず後ろの工程に伝わる。しかし「進み」は後ろの工程に伝わることは少ない。それは何故か。

• 先行着手できるタスクがない(ウォーターフォールなど)
• 10日の期日が設定されていれば、最初から 10日 の期日で終わらせる為の段取りを考える
• 「早く」終わったとしても、すぐに報告しない可能性が高い
• 「早く」終わって余裕ができた時間は、普段溜め込んでいる「スケジュール以外」の時間に割り当てる

などなど。

特に、仕事量に関係なく与えられる報酬が一定であったり、減点方式の評価あったりすれば、「期日どおり」終わっていさえいれば減点されるリスクは少なく、またそれ以上仕事が増やされることもないので、期日前に完了を報告するインセンティブが少ない。

「リスク」の報告は遅れるものである

一つ一つのタスクに「余裕」を見ていると、最初に想定していなかった問題や、予測以上に時間がかかりそうな問題が発生した場合でも、「「個人の裁量」によって何とかできる」と判断してしまい、報告が遅れることがある。これは、当人に悪気や傲慢なところがあるという理由ばかりではなく、「周りに迷惑をかけまい」と気を使う結果であることもある。そういう仕組みになっていることが多い。

「進捗率」は曖昧なものである

経験している人は多いが「90%完了」という報告の後に、なかなか終わらないタスクというものが存在する。これは、何に対する率が曖昧なためである。「機能は 90% 完了している(が、例外処理はまだ完成していない)」、「90%の実績(予定に対しての消化率」など、報告の基準が曖昧だと、個人のレベルによる進捗率の報告がなされる。どちらも 90% の意味は正しいが、欲しい報告ではない。

つまり

上記までのことを前提にして対策を打たねば、プロジェクトのスケジュールというのは遅れが発生するのが当然である。
では「どのように対策をうてばよいのか」については、また今度。

参考書籍

仕事関連 Project Management