今回のテーマは、見積もり、および、見積もりに絡む諸問題である。プロジェクト開始時に適切な見積もりが出ていない限り、失敗は免れない。見積もりが高すぎればプロジェクトは始動しないし、低すぎればユーザーが追加投資を迫られるか、ITベンダーが大赤字になるからだ。そこに、ユーザー要件があいまいな段階で見積もらざるを得ないという難しさが加わる。いくつかのリスク事例を挙げて注意を喚起したい。
 |
IT業界では、「開発実績は通常、見積もり時の2倍には増える」とされる。主たる原因は、見積もり契約時にユーザーから提示されるシステム要件のあいまいさにある。仮に、あいまい性がかなり解消されていても、開発が完了したときに実績と見積もりを比較してみると、常に実績のほうが見積もりより増えている。これが現実である。
従ってソフトの規模を見積もる際は、「ざっと見積もった値を2倍にしておかないと危ない」ということになる。すなわち100％の安全係数を掛けておく必要がある。しかし、顧客から「なぜそんなにかかるのか」と問われれば、とても説明できないだろう。まして、競合他社と厳しい受注合戦を繰り広げているとなれば、説明困難な過大な余裕を持たせた見積もりなど出せるわけがない。
受注後に規模が増えることを想定し、せめて予算追加や機能削減の折衝余地があるように、見積もり条件を明確にする努力が必要だ。
 |
見積もりはプロジェクトの運命を決定するだけに、十分な時間が必要だ。だが現実には、そんなに時間が許されることは少なく、「概算でいいから早く」と急き立てられることが多い。ITベンダーにすれば、長い付き合いがあれば対応せざるを得ないし、競争入札ともなると、ぐずぐずしていてはビジネスに参加することすら許されなくなる。
仕方なく過去の経験をベースに“エイヤッ”と見積もる羽目になるわけだが、この見積もりがユーザーの想定外だと、「どうしてこんなに高くなるのか」と詰め寄られることになる。いい加減な見積もり条件、あいまいなシステム要件で、できるかどうかよく分らないまま“エイヤッ”と見積もったにもかかわらず、ユーザーの期待値より高いと明解な論拠の説明が要求されるという見積もりのパラドックスがある。
 |
時間に急かされて出した検討不足の見積もりでも、出した金額は、あたかも熟考に熟考を重ねてやっとまとまった見積もりと同様にみられ、変えられない“威厳のある数字”として扱われがちだ。従って、後に仕様が明確になり、見積もり値を変える必要が出てきても、なかなか認めてもらえず、散々泣かされたSEも多いのではなかろうか。いったん出した見積もりには想定外の権威付けが行われてしまうのである。
また提出した見積金額を機能ごとに割り振ることを求められ、「この機能とこの機能をやめれば、これだけの金額になるよね」と言われてしまうと、ますます危ない状況になりがちである。
 |
客先によく出入りし厚い信頼を得ているSEは、ユーザーから「こういうシステムなら、いくらでできるか？」という質問を受けたりするが、気楽に回答して、後々後悔する事例が少なくない。たとえゼロ次の概算見積もりであっても金額だけが一人歩きし、そのまま予算化されてしまうことが多いからだ。何とか一日だけでも時間をもらい、可能な範囲の見積もり条件を書類に書いて営業から回答すべきであろう。
ユーザーが概算見積もりを要求する別のケ－スは、ユーザー社内における来期・来年度予算の枠取りのためである。これこそ、最もあいまいな条件であるから、数字が一人歩きすると極めて危なくなる。「○○人月」とか「XXステップ」とかの最低限の歯止め条件を文書で出しておかなければならない。
