契約にも色んな種類が！

システム開発における契約の方法は、過去の失敗から、発注者・受注者双方がWin-Winとなり得る様、変化してきました。
特にWebアプリケーションの開発では、仕様の変更が随時発生する性質から、今までのやり方では通用しなくなってきたためです。

委任？請負？？

「要件が確定するまでは契約形態を請負にしないこと」
システム開発の世界では、こんな事が昔から言われてきました。なぜでしょうか？

そもそも委任と請負の違いはなんでしょうか？

委任：当事者の一方が一定の法律行為の事務処理を委託し、受任者がこれを受諾することによって成立する契約。

請負：当事者の一方（請負人）がその仕事を完成することを約し、相手方がその仕事の結果に対して報酬を与えることを約する契約。請負契約。
大辞林（三省堂・infoseek）より

違いを一言でいうと、完成する事を目的としているかどうか？という事です。
委任の場合は、システムを完成させる必要はなく、求められた作業を一生懸命やる事、履行する事が目的です。
請負は、方法は決められていないが、とにかく完成させる事が目的です。

要件が定まらない案件では、期限内に予算内でプロジェクトを遂行出来る可能性が低いという事から、要件が確定するまでは
成果物を出せる状態ではないと判断し、請負にしない方が無難だ・・という意味だったのです。
また請負契約では、成果物の瑕疵や、プロジェクトの遅延なども、原則無過失で制作業者が責任を負う事になります。
委任契約は、無過失であれば瑕疵責任は負わないとされています。

フェージング契約とは

システム開発における契約には、最初から最後まで一括で請負契約を結ぶ場合もありますが、要件定義とシステム開発の契約を完全に分離して考える事フェージング契約も最近では採用されています。
この契約の利点としては、要件定義まで、または基本設計までを一つの契約とすることにより、発注側、受注側双方にとって手戻りのリスク回避に効果がある所です。
設計フェーズでは、制作業者の努力だけでなく、発注側にも協力を仰がなくてはいけないという理由から委任(正確には準委任）契約が、反対に仕様決定後のシステム開発契約では、請負契約が向いていると言われています。

グリニッジではウォータフォール開発、特に規模が大きい物に関しては、契約を次の様に3段階に分けています。

第一段階⇒【計画】
要求仕様の事前調査のための契約。要求仕様をリストアップし、凍結。

第二段階⇒【設計】
仕様設計のための契約。
凍結された要求仕様の変更が発生したら、業者は追加コストを請求出来る。
顧客が仕様をレビューし、それらの検収・署名捺印後に、業者は見積もりを作成。

第3段階⇒【製造】
業者が仕様どおりに製品を作り上げることを約束する。
業者は要求書、設計書に変更が入り、その結果コーディングし直さなければならない場合、追加の費用を請求出来る。

(社)情報サービス産業協会（JISA）では、現在の委託取引の問題点を整理し、それに対する考え方として、モデル契約書を公表しています。
「新しいソフトウェア開発委託モデル契約書」における主要条項の策定趣旨について
以下のような項目に対し、JISAの回答が載っておりますので、ご一読下さい。

・ベンダが再委託をする場合、ユーザの事前の承諾を得る必要性があるか
・ユーザに開発成果のプログラムの著作権を移転させるべきか
・瑕疵修補の請求期間はどのように設定すべきか
・ソフトウェア開発上ユーザに求められる役割は何か
・ユーザが提供した資料等に起因する納入物の瑕疵等の結果について、ベンダはその責任を免れるか
・ユーザはどのような検査を行うべきか

JISAソフトウェア開発委託契約書（平成14年5月版）では、主に以下のような項目について、契約条件が書かれています。
どういう条件で契約をすればいいのか迷った時など、参考になるかと思います。

・契約の目的
・業務の内容
・役割分担
・納入物
・委託料の支払時期及び支払方法
・作業期間及び納入期限

・ソフトウェア作成業務の実施
・中間成果のユーザ確認
・再委託
・第三者ソフトの利用
・フリーソフトの利用
・検査仕様書の作成及び承認
・本件プログラムの検収

・保証及び責任の範囲
・セキュリティ
・保守等

・システム仕様書の変更
・損害賠償

【参考サイト】

社団法人情報サービス産業協会(JISA)
「新しいソフトウェア開発委託モデル契約書」における主要条項の策定趣旨について

ITpro 第1回 契約にかかわる法律を知る

トラックバックURL