極端に言えば,見積もりがプロジェクトの成否を決定する。見積もり作業のプロセスを通して,スコープやコスト,スケジュールといったマネジメントの基準となる「ベースライン」が作られるからである。一般的な見積もりの流れは,図の通りである。
図●見積もり作業の流れ |
見積もりをチェックしていると,見積もりを単なる計算ととらえている人を見かける。社内に生産性ガイドラインなどがあって,平均的な生産性指標(Ks/人月やFP/人月など)が設定されている場合,ステップ数(Ks)やファンクション・ポイント(FP)などで開発規模を算出し,生産性指標を単純にかけ算して工数や費用を求めるような人だ。
見積もり≠計算
プロジェクト・マネージャ(PM)は,見積もりは単なる計算ではないことを理解しなければならない。プロジェクトには複雑性やリスクが必ず伴う。前提条件やプロジェクトの成功シナリオのほか,ユーザーやプロジェクト特性が加味されてはじめてまともな見積もりとなる。
顧客ニーズを十分把握しないまま開発規模を決めてしまおうとするPMもいる。要件が不明確なまま見積もり,前提条件も不明確なまま見積書を顧客へ提出してしまう。要件が確定していくにつれ,仕様追加や変更が多発し,会社に大きな損失を与えたプロジェクトは世の中に数多い。
ベンダーの立場では,引き合い時点(提案時)の見積もりは,アバウトな概算見積もりしかできない。しかし,実際に提案時の見積もりを後で変更することは,ほとんど不可能に近いのが現実である。従って,プロジェクトを成功へ導くためには「要件が不明確なまま見積もらない」という原則を持たなければならない。
要件があまりにも不明確であれば「これでは見積もれない」ということをユーザーに伝えるべきである。それでも見積もらなくてはいけない場合は,フェーズを分けて,まず要件定義工程のみの見積もりを提出する。要件定義工程以降は別途見積もりとする。これでリスクは最小限に抑えられる。
あるいは,前提条件(仮の要件や決定)を列挙する。これだけ不明確な要素があるということをユーザーと十分合意した上で,見積もりを提出するなどの対策が必要である。
プロジェクトには不確実性や複雑性が伴うため,放っておいても計算で算出した見積もり通りに遂行できるということはまずない。見積もりの工数や金額は,PMの意思表示である。PMは,見積もった工数や金額の範囲にプロジェクトが収まるように,マネジメントする必要があるのだ。見積もる人とプロジェクト責任者(PM)が違う場合があるが,これでは見積もりが単なる計算となってしまう可能性が高いため,好ましくない。
|