「基本契約＋個別契約」という方式
規模の大きなシステム開発では、工程ごとに期間と費用と成果物を定めて別々に契約をするケースがあります。区切り方はいろいろですが、要件定義、設計、開発以降などに契約を分け、お金も個々の契約の終了ごとに支払われるケースが多いようです。要件定義書を作ったから2,000万円、設計書を作ったので4,000万円、それ以降システムが完成した分で5,000万円といった感じです。
こういう方式の契約を「システム開発の多段階契約」と呼びます。システム開発では「要件定義を行ったら、設計すべき内容が当初の想定と変わってしまった「設計してみたら、もっと期間や工数がかかることがわかった」など、契約条件を変えざるを得ない事象が発生するのが日常茶飯事です。
そのため、まずは要件定義を行ってから設計に必要な期間や工数を見積もって契約しよう、設計が終わってから開発以降の契約を……と、段階を踏んで契約を結ぶことは、ユーザー、ベンダー双方にとって、ある意味安全な方式です。
この方式は、情報処理推進機構などでも推奨するやり方なのですが、個々の契約をバラバラに結んでしまうと、それぞれの連携が取れなくなってしまいます。そのため、多くの場合個々の契約の上位として基本契約を結びます。
基本契約書には「●●業務を支援するシステム開発を行う」という抽象的な記載をし、「期間、金額、成果物については、工数ごとの個別契約で定める」と取り決めます。そして、それぞれの工程ごとに個別契約を結ぶという方式です。
この基本契約+個別契約というやり方には、前述した通り「安全」というメリットがあります。たとえば、一本の契約で要件定義から完成までを契約してしまうと、様々な状況に応じて、契約変更を行わなければならなくなります。変更できれば、まだよいのですが、悪くするとユーザーとベンダーが契約の内容を巡って争うことにもなりかねません。
「1億円払えば作るっていったじゃないか！」、「いや、こんなところまで作るとは想定していませんでした」そんな言い争いが発生して、最悪は裁判にまで至ってしまうということ
もある訳です。
しかし、開発工程の進捗に応じて、都度、個別契約を結ぶ方式であれば、要件定義の結果を待ってから設計の見積もり等を行い、設計がおおよそできてから以降のスケジュールや工数・金額を定めるので、そうした争いの起こる可能性は減ります。
ユーザーは要件定義の結果で設計費用の手当てをすることができますし、最悪、当初の想定を大きく超えるようなら、その時点で機能の縮減をしたり、開発を中断したりという決断もできます。要件定義や設計の結果をベースとして、過不足のない後続発注ができますし、最悪の場合の傷口も小さく抑え込めるわけです。
