進捗率

ITプロジェクトのみならず、プロジェクトはよく「進捗率」というもので管理される。しかし、進捗率というものこそがITプロジェクト管理を失敗に導いているのではないか？と思えるようになってきた。
当初、IT業のプロジェクトの進め方は、どうやら建設業をモデルにしたようだ。そりゃ、一から方法論を作り上げるよりはずっといい。しかし、ITと建設の大きな違いがいくつかあり、そのために進捗率という概念がITにはなじまないものなのではないか？という気がしている。
異なるところを思いつくままに挙げると
・成果物が目に見える（物理的）／目に見えない（論理的）
・設計がほぼ完璧に行われている／設計が甘いことが非常に多い
・設計通りに勧めればよい／設計通りに作ると問題が多い
・成果物検査の標準がある／標準化はされていない
・作業に対して標準工数や標準単価がある／ない

成果物が目に見えず、設計が甘くて製造工程で問題が多発し、という状態であるので、当初見積もっていても「製造工程以外が原因」で工数が膨らんだり、遅延することもよくある。そういう場合、「進捗率」はどのようにすればいいだろうか？現場の担当者はおそらく、苦肉の策として「今まで１０％きざみにしていたのを１％きざみで進捗を上げておく」というような対処療法的なことを行うのではないだろうか？
管理、というのは計画を立てたことを実行する、というだけではない。問題（進捗の遅れも含む）を確認し必要な対策を立てることを求められる。しかし、遅れかどうかをキャッチアップするための指標が上記で書いたような報告のされ方であればどうだろうか？プロジェクトの遅れをキャッチアップできるはずもないだろうことは少し経験のある人なら分かるだろう。

見たいのは「進捗の遅れがないかどうか」であり、「進捗率」ではないはずだ。進捗率は割り算を使って求める。これは、母数が変われば変えるべきなのか、別のタスクとして切り出すのか、考え方がいろいろあり、いわば相対的な値、といえる。ならば確実にキャッチアップできる絶対値を用いる方がよいのではないだろうか。
予定に対して「この仕事はあと何日で終わるか」をヒアリングすれば遅れているのか進んでいるのか、ごまかしがきかなくなるうえ、「遅れた原因は何か」を確認することで「外部要因で遅れている」ことを拾い上げ、それを解消するべくプロジェクトの内部／外部に働きかけることができるのではないか。

確かに上層部に報告する等の場合に数字が求められることは多い。が、そこも変えなければならないだろう。

ご存じの方は「岸良さんの受け売り」と解釈なさるかもしれないが、自分のアタマのなかでよく咀嚼したつもりなので、若干言っている事が違うつもりではある。

過剰管理の処方箋 自然にみんながやる気!になる/金井 壽宏

￥1,680
Amazon.co.jp