|
|
請負契約の法的性質
システム開発やｗｅｂ制作などの開発型プロジェクトでは、開発者（受託者）側が受託した仕事を完成させ、注文者（委託者）側がその仕事の結果に対し報酬を支払うという内容の契約が一般的です。このような契約を請負契約といいます（民法632条～642条）。請負契約では、仕事の完成が報酬請求のための要件とされているため、報酬を請求するためには、仕事を完成させなければならないのが原則です（*1）。
|
|
|
|
仕様書の重要性
開発者側として特に注意すべき点は、受託した仕事がどういうものかを特定することです。仕事の範囲が曖昧だと、開発者側が完成させたと思っていても、注文者側から見れば完成したのは一部にすぎないというミスマッチが起こりうるからです。
この「仕事」の内容を特定するものが通常「仕様書」、「要求仕様書」、「要件仕様書」、「要件定義書」等と呼ばれる書類です（以下「仕様書」といいます）。注文者側から提示される「仕様書」には抽象的な内容のものも少なくないので、開発者側としては、受託する仕事の内容を特定するため、なるべく曖昧な要素を排除するとともに、技術的に困難な内容や過分なワークロードを要する内容に解釈される余地を無くすよう、注文者側と協議することが必要です。注文者側と開発者側とが要件仕様について協議し、明確かつ実現可能な要件仕様を特定して仕様書にまとめ、両者がこれに承認の署名をするという方法を採るべきです（承認済仕様書）。
このようなプロセスは、注文者側の広汎な希望をシステムで実現可能な枠組みの中に落とし込んでいくという作業でもあり、開発の成功率を大きく高めるものともいえます。また、このようなプロセスの中で、注文者側の真の目的は当初の要件仕様とは別のところにあることに気づく場合もあり、開発者側から真の目的をもっとも効果的に実現できる要件仕様を逆に提案し、注文者側により高度な満足を与えることができる場合もあります。
|
|
|
|
|
仕様変更についての取り決めの方法
開発型プロジェクトをめぐる紛争の中で典型的なものが、開発途中で仕様変更があり、納期までに仕事が完成できなかったというケースです。注文者側は、仕事を完成できなかった以上報酬は支払わないと主張し、開発者側は、仕事が完成できなかったのは注文者の度重なる（あるいは重大な）仕様変更のせいであると主張して折り合いがつかず、契約の性質、仕様変更の重大性等をめぐって裁判になる場合もあります。
このような事態を回避するためには、仕様変更についての取り決めを予め契約の中で定めておくことが必要です。
|
|
契約において予め取り決めておくべき内容（例） |
| １ |
期限 |
・注文者側が仕様変更をなしうる時期について期限を設ける。
・期限後は、今回の開発ではなく、次回のバージョンアップの作業項目とする。 |
| ２ |
手順 |
・注文者側から仕様変更の申し出があった場合、双方で協議し、変更内容を特定した仕様書を作成し、両者がこれに承認の署名をする。 |
| ３ |
程度 |
・納期内に完成が困難となるような重大な仕様変更はできないこととする。
・仕様変更の程度が重大で、４の代償の合意ができない場合、開発者側は契約を解約できることとする。この場合使用者側は一定額を支払うこととする。 |
| ４ |
代償 |
・開発者側は、仕様変更による作業量の増加に応じた納期の延長、対価の増額等を請求できることとする。 |
|
|
|
| 注１ |
高難度の新規開発型プロジェクトの場合の対処方法
上記のとおり、請負契約では、仕事の完成が報酬請求の要件とされています。
他方、一定の事務を委託する場合を、準委任といいます（民法656条、643条～655条）。準委任契約の場合、報酬の約束をすることは必要となりますが、仕事の完成は報酬請求の要件とはされておらず、委託された事務を履行すれば報酬を請求できることとなります。期間によって報酬を定めることもできます。
仕事の完成が確実とはいえない高難度の新規開発型プロジェクトにおいては、注文者側とこの点のリスクをよく協議し、業務委託契約において、準委任的な要素を契約に盛り込むべきです。たとえば、開発コストに相当する分については仕事の完成を条件とせず人月計算による中間払いとする等のケースもあります。このような対処方法を講じておかないと、仕事が完成できなかった場合、報酬がもらえないのみならず、開発コスト（下請業者や技術者への支払等）まで自腹で持ち出しということになりかねません。
|
|
|
|
|
|
