今回のテーマは、見積もりリスク回避のためのヒントや注意事項である。要件があいまいな段階で見積もらざるを得ないため、見積もりのリスクは発生する。したがって対策としては、要件のあいまい性が解消されてから見積もるか、後から修正が受け入れられるような見積もり条件をいかに設定するかである。段階契約が定着し、あいまい性の払拭後に見積もれるように、ユーザー、ITベンダーともに努力したいものである。
 |
「見積もり精度が悪すぎたのが、赤字の最大原因でした。今後は見積もり精度の向上に努めます」―。大口赤字を出したプロジェクトの反省会をやると、こう言うプロジェクト・マネジャーが多い。しかし見積もり時にユーザーから要求仕様がはっきり示されるケースは少ないので、そう簡単に見積もり精度など上げることはできない。
金額精度が高い見積もりを目指すよりも、当初想定したシステムの仕様や見積もり条件の明解化を目指すべきである。後から仕様が増えたときに、当初の仕様や条件との差をきちんと言え、値増しを頼めるような見積もり条件の設定こそが大事である。
見積もりに与えられている時間は限られ非常に難しい仕事ではあるが、受注に備え基本設計をやっていると考え、条件設定をあきらめてはならない。
 |
見積もりは、ユーザーから指定された期限までに提出するのが原則である。だが、見積もり要件がかなり詳しく書かれている場合でも、あいまいな部分が多いのだから、積極的に質問を繰り返し、少しでも理解が深まってから見積もることが極めて大事である。質問を繰り返しているうちに、ユーザー側でも要件のあいまい性を強く感じ、見積もり期限自体を延ばしてくれる場合もあるし、何とか延ばしてくれるよう交渉すれば、了解が得られる可能性は意外と高いと思われる。あきらめずに、少しでも要件を明確化してから見積もるように努力したい。
特に、競合相手がいない場合は、安易に見積もって後から何度も再見積もりするよりは、極力仕様が固まってから見積もったほうが、ユーザーにとっても好都合ではなかろうか。
 |
ユーザーから提供されるRFP（提案依頼書）が充実している場合は別として、見積もり条件の中で最も難しいのが業務仕様の定義である。その精度を高めるための手段の1つは、似たようなシステムを探し、その仕様を転記することだ。最終的にどうなるかは分らないにしても、似たような仕様のパッケージがあれば、その仕様を添付することが見積もり仕様の明確化につながる。適当なパッケージがなくても、別のユーザーで同様のシステムを手掛けていれば、その仕様を転記する。
いずれにせよ、よく分からないから「仕様は別途打ち合わせ」と逃げていては、リスクを避けられない時代であるということをしっかり認識すべきである。結果的に大幅に仕様が変わってしまったとしても、あえて見積もりの前提となる業務仕様を極力詳細に定義しておくことが大事なのだ。
 |
似たようなパッケージや既存システムが全く存在せず、流用できる仕様がなければ、新たに仕様を作らなければならない。その時は、ユーザーが提示したRFPの記述の粗さを少しでも補うべく、見積もり期限一杯、想定できる仕様を記述し、契約条件の明確化に努めることが大事である。
この仕様の詳細化は難度の高い仕事であるし、見積もりは基本設計の一部でもあるため、できるだけ経験豊富なベテランにやってもらうべきだ。幸か不幸か見積もりに許される時間はそう長くはない。ベテランを想定仕様の記述に専念させてもせいぜい１週間ほどで、実務には深刻な影響はないだろう。しかも自分で想定仕様や見積もり条件を書けば、その案件が抱える潜在リスクにも気付くだけに、受注後のリスク管理にも役立つはずである。
