前回に続いて、見積もり、および、見積もりに絡む諸問題がテーマである。プロジェクト開始時に適切な見積もりが出ていない限り、失敗は免れない。いくつかのリスク事例を挙げて注意を喚起したい。
 |
「後で困らないように見積もり条件をしっかり書け」というと、「あれはやらない」「これは見積もり範囲外」というような後ろ向きの否定的条件を並べるSEがいるが、これではビジネスにならない。ユーザーから、「一体注文を取る気があるのか、断りに来たのか」と言われてしまうであろう。
筆者はいつも、「見積もり仕様や見積もり条件は極力丁寧に書くべき」と言っているが、実現しようとするプラスの条件は丁寧に書いても、マイナスの条件は、できるだけ少ないほうがよい。
どういう見積もり条件を設定すれば、システム仕様が後で暴れることがないかを考えて、システム規模の膨張を抑え得る最小の本質的条件を求めることが大事である。
 |
全く同じ機能を実現するシステムでも、処理しなければならないトラフィックやデータ量によって設計を変えざるを得ないケースが出てくる。量が質を変えることを十分に認識することが大事である。
これはオンライン処理だけでなく、バッチ処理でも同じだ。例えばバッチ処理量が多く、オフライン時間帯だけではこなせずオンライン時間帯にはみ出す場合には、処理方式を変えざるを得ない。難度の増大はもとより、ソフト量も大幅に増えることがある。
またデータ量が増えると、処理中に問題が発生したときの処理を、どこからやり直せばいいのか、リランポイントの設定にも大きな影響が出てくるであろう。量が質を変える怖さをよく理解しておかなければならない。
 |
かつてハードが中心で、ソフトは大した量にならなかった時代、極端な場合には「仕様は委細打ち合わせ」で済ませた見積もり仕様書がよく見られたようだ。今でも、ユーザーから与えられた見積もり条件がよく分からず、仕方なく「詳細は別途打ち合わせ」と書くケースがある。
「詳細仕様は別途打ち合わせによる」という見積もり条件は、不明確な条件下における逃げの常套手段ではあるが、ITベンダーとユーザーなど、必ずしも対等とはいえない関係者間では、およそ無意味な条件で、「ユーザーのおっしゃることは何でもやります」と言っているにすぎない。別途見積もりができたとしても、ユーザー側が用意できる合計予算金額が、当初見積もり以上に増えることは極めて少ないのである。
 |
大きなプロジェクトでは、同じITベンダーから複数の部門が参画し、それぞれが見積もりを出すことがあるが、見積もり条件については、部門間でよくすり合わせておく必要がある。事業部門間で見積もりの考え方に違いがあると、ユーザーにとって都合のよいほうへと条件の統一を要求されてしまう。例えば、ソフトの開発効率に事業部間で差があれるとすれば、効率の悪いほうは、効率のよいほうに合わせさせられてしまう。
また他社との共同プロジェクトの場合は、会社によって事情が違うことは理解されても、あまりにもITベンダー間の差が大きいとクレームが出るであろう。特に見積もり範囲については、お互いよく調整し、漏れがないようにしておかないと、ユーザーの予算措置も漏れてしまう可能性がある。「これは相手がやるはず」と互いに誤解していると、両社とも見積もりが抜けてしまうことになる。パートナー会社との見積もり条件のすり合わせをきちんとやっておく必要がある。
