前回に続いて、見積もりリスク回避のためのヒントや注意事項がテーマである。段階契約が定着し、あいまい性の払拭後に見積もれるように、ユーザー、ITベンダーともに努力したいものである。
 |
情報システムは、受注後にとかく仕様が増えることが多いだけに、仕様が膨張した際に予算増額なり、仕様削減なりを交渉できるように、見積もり条件を極力明確化する必要がある。
しかし見積もり時間の制約から、完全な条件定義ができないことも多い。せめて、画面数、出力帳票数、端末台数、テーブル数、データベース容量など、システム全体を概観できそうなキー・パラメータを考え、その量を見積もりに明記したい。その仮定値が間違っていたとしても、見積もり時に量を定義しておけば、仕様が膨張した際も予算増額折衝のよりどころになる。
そのためにも、業種・業務ごとに、キー・パラメータが何であるかを組織として検討するとともに、経験値を蓄積する仕掛けを作ることが大切だ。
 |
一度オンライン・システムを経験すればすぐ気付くことであるが、開発しなければならないソフト量の大半は障害処理と例外処理である。これを見過ごすと大きな見積もりミスを犯す。しかもこの大きさを感覚的に分かっているユーザーは極めて少ない。実例を示し、障害処理・例外処理の怖さを分かってもらう努力が必要であろう。
優れたSEや設計者は見積もりや基本設計時から例外処理を十分読み切るといわれる。こうした見積もり能力を身に付けるためには、ソフトを開発するたびに異常処理・例外処理がどの程度あるかを想定し、出来上がった結果と比べ反省するという経験を、きちんと積み上げる努力が不可欠である。
 |
難しい見積もりのときは、担当者からの見積もり案を上位者が審査・承認するだけでなく、上位者も独自に概算を見積もり、両者を比較しないと、大きな見積もりミスや見積もり漏れに気付かない恐れがある。経験に基づく上位者のマクロな規模感覚を活用しなければ、もったいないとも言えよう。プロジェクト損益の大半は見積もりで決まってしまうだけに、上位者も自らの重要な仕事として真剣に対応する必要がある。見積もりミスを部下のせいだけにするのは犠牲が大きすぎる。
ただ、担当者の見積もりよりも上位者の見積もりが小さい場合は注意が必要だ。上位者が担当者の見積もりを批判したり理由を追求したりすると、全貌が見えていない段階だけに、担当者は上位者に反論する理由を見つけられず、ついつい上位者の見積もりに合わそうとしてしまうリスクがある。
 |
システム構築ビジネスにおいて、ユ ーザーの不満、ITベンダーの不幸を生む最大の理由が、見積もりと契約時の要件のあいまい性である。
この問題を抜本的に解決するためには、ユーザーとITベンダーの間にある、要件に関する認識差を排除し、仕様が確定するまでは「仕様確定のための要員派遣契約」を結ぶことである。仕様確定後に、開発請負のための正式見積もりを行い、請負契約に切り替えることが望ましい。いわゆる段階契約だ。過去はなかなか認めてもらえなかったが、最近は段階契約を採り入れるユーザーも増えてきたので、段階的見積もり・契約プロセスが当たり前であるような社会を早く実現できるよう、各社の努力が何より重要である。
段階的見積もり・契約方式では、単に仕様を明確にできるだけでなく、ユ ーザーの「予算に合う適切なシステム」を一緒に検討し、合理的なシステム案をまとめられるため、ユーザーにとってもリスクが減るはずだ。
