最近のシステム開発委託契約では、一般に、要件定義、外部設計（基本設計）、開発、運用テスト（導入支援）等の各工程を一つの契約で規律する一括請負契約方式、又は、各工程毎に、個別契約を締結し、ある工程が完了したら、次の工程に関する契約を締結するという形でプロジェクトを進行させる多段階契約方式が採用されています。

　この２つの契約方式を使い分けることが求められているわけですが、この点を理解するためには、前提として請負契約と準委任契約の違い、ソフトウェア開発における各工程の概要を把握する必要があります。

 

１．請負契約と準委任契約の相違

   請負契約とは、「請負は、当事者の一方がある仕事を完成することを約し、相手方がその仕事の結果に対してその報酬を支払うことを約することによって、その効力を生ずる。」（民法６３２条）と規定されているように、仕事の完成を目的とする契約です。民法は、２０２０年４月に新しい民法（以下「現行民法」といいます。）が施行されていますが、現行民法でも改正前民法でもこの点は同じです。

　これに対し、準委任契約とは、「法律行為ではない事務の委託」（民法６５６条）をする契約であり、仕事の完成義務を負うものではありません。また、現行民法では、労務の提供に対して対価が支払われる履行割合型と、成果に対して対価が支払われる成果報酬型（成果完成型）の２つの契約形態が明文化されました。

　以下、現行民法における請負契約、履行割合型の準委任契約、成果報酬型の準委任契約を比較してみると、以下のような違いがあります。

 

表１　請負契約と準委任契約の比較

契約類型	請負契約	準委任契約　 　（履行割合型）	準委任契約 （成果報酬型）
ベンダの義務	仕事の完成義務 （結果債務）	善管注意義務	善管注意義務 成果の達成に向けて事務処理をすることが債務の内容（手段債務）
報酬を請求するための 要件（原則）	「完成」と「引渡し」が要件（現行民法632条）	「委任事務を履行した後」に請求可（現行民法648条2項）	「成果の引渡し」が要件（現行民法648条の2・1項）
ユーザの帰責事由以外の理由で履行不能となっている、又は、完成前に契約解除されている場合	可分な部分の給付によってユーザが受ける利益の割合に応じて請求（現行民法634条）	既にした履行の割合に応じて報酬を請求（現行民法648条）	可分な部分の給付によってユーザが受ける利益の割合に応じて請求（現行民法634条、648条の２・２項）

 

　上記の表１のとおり、請負契約と成果報酬型の準委任契約は、成果物の引渡しが報酬請求の要件となるという点で類似しますが、請負契約では結果債務を負うのに対し、成果報酬型の準委任契約では手段債務を負うことになるため、以下のとおり、債務不履行の判断方法に違いがあります。

表２　請負契約と成果報酬型の準委任契約の比較

契約類型	請負契約	成果報酬型の準委任契約
債務の内容	結果債務	手段債務
債務不履行の判断方法	仕事が完成していないこと自体が債務不履行となり、請負人（ベンダ）の帰責事由が推定され、請負人（ベンダ）が帰責事由の不存在を立証しない限り、債務不履行責任を免れない。	成果が達成されていないというだけでは債務不履行とはならず、請負人（ベンダ）の帰責事由によって成果が達成されていないことを委任者（ユーザ）側で立証することが必要である。

 

　このように、請負契約と準委任契約には、ベンダ側に課せられる義務に差があるため、必ずしも、システム開発・ソフトウェア開発の各工程を請負契約で締結することが適切であるとは限りません。

 

２.システム開発・ソフトウェア開発の各工程と契約形態の対応関係について

　システム開発の工程について、その概要をまとめると、概ね、以下の表のとおりになります。

 

表３　システム開発・ソフトウェア開発の工程　

工程の名称	実施する作業	主体（主な例）
要件定義	システムで実現したい業務要件を決定し、ベンダ企業がその支援を行う工程。	ユーザ
外部設計 （基本設計）	要件定義工程で作成された要件定義書に基づいて、表示画面、業務で使用する帳票、周辺システムのインタフェース、データベースの方式等を決定する工程。	ベンダ 又は ユーザ
開発	プログラムやデータベースの詳細な仕様を決定してプログラミングを実施し、単体テスト、結合テスト、システムテストを実施する工程。	ベンダ
運用テスト （導入支援）	システムテストまで完了したプログラムの引渡しを受け、ユーザ企業が主体となって行うテスト工程であり、ベンダ企業はユーザ企業が運用するための支援を行う。	ユーザ

 

　この表３で注意しなければならないのは、開発工程以外の工程については、ベンダ企業ではなくユーザ企業が主体となって行われる工程が存在するということです。ベンダ企業は、請負契約の場合、仕事の完成義務を負いますが、ユーザ企業が主体となって実施する工程についてまで完成義務を負うという方式は、ベンダ企業の立場からは受け入れることが困難でしょう。同様の理由で、成果の引渡しが要件となる成果報酬型の準委任契約についても、ベンダ企業の立場からは受け入れることが困難でしょう。このような事情もあり、大規模なシステム開発においては、工程毎に履行割合型の準委任契約と請負契約を使い分ける多段階契約方式が採用されているのです。

 

３.一括請負契約方式と多段階契約方式

　一括請負契約方式と多段階契約方式を、「進捗管理」「見積りの難易度」「全体スケジュールの把握」「契約形態の選択」「ユーザ企業によるプロジェクトの中止」「契約手続きの手間」という視点で比較すると以下のような相違があります。

 

表４　一括請負契約と多段階契約の比較

工程の名称	一括請負契約方式	多段階契約方式
進捗管理	ユーザ企業（発注者）が、工程毎に検収することが予定されていないことが多いため、進捗を客観的に判断しにくい。	ユーザ企業（発注者）が、工程毎に検収するため、進捗を客観的に判断しやすい。
見積りの難易度	開発対象が不明瞭な時点で見積りをすることになるため、ベンダ企業（開発企業）による見積りが困難。	工程毎に見積りをするため、ベンダ企業（開発企業）よる見積もりが、一括請負契約よりも容易。
全体スケジュールの把握	契約書上は、全体のスケジュールや予算が確定するが、後から追加費用が発生したり、納期が遅延することも多い。	一定の工程まで進まないと、最後の工程までに必要となる費用の総額や、本稼働の時期が不明。
契約形態の選択	原則として請負契約。	工程毎に、請負契約と準委任契約を使い分けることができる。
ユーザ企業によるプロジェクトの中止	ユーザ企業がプロジェクトを中止することは想定していない。	要件定義や外部設計等の結果、開発工程以後の見積りが高額となる場合、又は、時間の経過に伴いシステムが不要となった場合、ユーザ企業がプロジェクトを中止することも想定されている。
契約手続の手間	原則として１回で済む。	工程毎に実施する。

 

　 いずれの契約方式を採用するのかは、個々のプロジェクトの特徴や、どのような視点を重視するのかという点に依存することになりますが、大規模なシステム開発プロジェクトでは、多段階契約方式が主流になっています。

 

４.提案書は契約の内容となるのか

　 訴訟では、ユーザ企業が、ベンダ企業の提出した提案書の記載内容が契約の内容になると主張することがあります。これは、ユーザ企業がベンダ企業に対して提出するRFP（Request For Proposal）に対する提案書の提出を「契約の申込み」、これに対する採用通知書の送付を「契約の承諾」と捉える考え方ですが、名古屋地裁平成１６年１月２８日判決では否定されています。

　この判決では、提案書の内容が、具体的なものではないことを理由に、採用通知書を送付する意味について、「本件採用通知の送付は、今後本件総合システムの導入を委託する業者として交渉していく相手方をベンダに決定したことを意味するに止まるものと解するのが相当である。」としています。