 |
プロジェクトには「リスク（不確実性）」や「複雑性」が伴う。ベンダーが過去に経験した業種・業務のシステム開発であっても，ユーザーが違えばリスクも変わる。プロジェクト・マネージャ（PM）にいくら経験があっても，ユーザーの仕様決定や取りまとめの能力次第でリスクは増減する。前提条件やシナリオ，WBSの作り方によってもリスクは変わるのである。
そもそも，見積もりの段階で要件が確定していることは少ない。プロジェクトが進むに連れて段階的に詳細化されるケースがほとんどである。見積もり段階では予期しないことが起きるのは，ある意味，当たり前のことである。ユーザーの業務経験・知識や仕様決定能力を考慮せずに契約したために，仕様確定に時間がかかり，さらに仕様が膨らみ不採算となったプロジェクトをいくつも見てきた。
ユーザー（発注者）にせよベンダー（受注者）にせよ，PMは要件を基に算出した見積もりをそのまま契約に反映してはいけない。リスクを考慮して契約内容を詰める必要がある。ユーザーに業務経験・知識や仕様決定能力が少ない場合は，要件定義の工程とそれ以降の工程にフェーズ分けする。その上で，要件定義の工程は準委任契約などで作業を進め，それ以降の工程は一括請負契約にするといった契約を検討したい。
契約形態によって，ユーザーのリスクとベンダーのリスクは変わってくる（図）。PMは，それを十分理解したうえで，プロジェクトのリスクを考慮し，どのような契約内容や契約形態にすべきなのかを吟味することが大切である。
契約の内容は，プロジェクト完了を判断する重要な要素でもある。契約の内容を履行したかを判断し，履行していなければプロジェクトは完了とならない。ベンダーのPMが契約内容を十分に認識していなかったために，責務不履行によって賠償を求められたり，プロジェクトが完了できずに不採算プロジェクトに陥ったりしたケースもいくつか見てきた。
 |
| 図●コストとリスクの関係 |
PMは，プロジェクトの間ずっと，契約の内容を念頭において仕事をしなければならない。せっかくリスクを考慮し契約しても，作業に追われ，手続きを怠ってしまったがために本来請求できるはずの追加費用を請求できないプロジェクトも多く見かける。契約でユーザーとベンダーそれぞれの役割を明確にして，ユーザーに参画意識を持ってもらうことも，プロジェクトを成功させるための重要な要素の一つである。
|
