 |
見積もりの段階で要求事項や仕様が確定していることはほとんどない。だから，ベンダーがユーザーから完全なRFP（提案依頼書）を提示されることは少ない。
だが「こんな感じの機能（業務）を実現してほしい」というユーザーからの要求に対し，前提条件もなく，見積もりの根拠も提示しないで概算見積もりを提出したプロジェクト・マネージャ（PM）は，私の知る限り，例外なく不採算プロジェクトへと導いている。
なぜ，不採算プロジェクトとなるのか。それはベンダー，ユーザーお互いが，見積もりに明示されていない前提条件を都合よく解釈するからである。
勤務表のシステム開発を例に挙げてみよう。ベンダーは，当月の就業時間の集計処理（バッチ処理）までを実装できればよいと考える。ところが，ユーザーは人件費を計算する基幹システムへの伝送処理までが見積もりに含まれていると解釈する。その結果，開発が終わった後でユーザーは「既存システムへの伝送処理が含まれるのは当たり前だ！」とクレームを付ける。
「その作業は見積もりに入っていると思った」「こんな性能や操作性では仕事にならない」といった会話が交わされる現場は，残念ながら少なくない。そうした事態は，開発のスコープやシステムの性能，操作性，信頼性，移行，日程，作業分担，責任範囲などが不明確，すなわち前提条件として列挙されていないために起こる。
では，どうすればよいか。要件があいまいな部分や決定していない事項については，仮の要件を設定して見積もればよい。仮の部分を「前提条件」として明文化し，前提条件が変われば見積もりも変わることをユーザーとベンダーが合意しておくことがポイントである（表）。
| 表●前提条件の例 |
 |
見積もりは，システムのイメージがわきやすい形で提示しなければならない。重要なことは，これから開発するシステムのイメージをユーザーとベンダーとの間で共有することである。プロジェクトの間，常に「前提条件」をお互いに意識できれば，後でもめるという事態は減る。
そのためには，例えば変更管理委員会（CCB：Change Control Board）のような組織を設置する。そこに，ユーザーにも参加してもらう。仕様変更が発生したら，常に前提条件と照らし合わせて判断できるよう変更の手順を明確にし，意識し続けるようにするのである。
|
