法務・税務・労務などの問題解決エンジン
some system placed here.

ソフトウェア開発契約と契約の法的性質

  • このエントリーをはてなブックマークに追加

はじめに

 今回は、ソフトウェア開発契約と契約の法的性質について考察してみました。
 契約実務で一般的になっていない部分もあるかと思いますが、私見として読んで頂ければ幸いです。

 ソフトウェア開発契約は一つの契約として締結される場合が多いと思いますが、ソフトウェア開発の工程は複数あり、その各工程によって法的性質は異なってくる可能性があります。そのため、契約書においても各工程の法的性質に従った手当をした方がよいのではないかというのが、今回の記事の概要です。

 

ソフトウェア開発は複数の工程からなる

 伝統的なソフトウェア開発モデルとしては、いわゆる「ウォータフォール型開発モデル」というソフトウェア開発モデルがあります。

 この「ウォータフォール型開発モデル」は、開発工程を下記のように工程を時系列的に配置して、前工程を完了した後に次工程に進むというソフトウェア開発モデルです。

waterfall

※ソフトウェア開発と似た要素のあるものとして建物の建築があります。建物の建築では、設計・工事・監理・保守という工程あり、各工程が別個の契約として締結されることが多いようです。

 

工程によって異なる可能性のある契約の法的性質

 上記のように複数の工程を含むソフトウェア開発ですが、各工程の目標とするところや業務の内容によって、法的にはそれぞれ請負(民法632条以下)または準委任(民法652条)の性質を持つことになると考えられます。

 現在の一般的なソフトウェア開発契約では、各工程を特段区別せずに「業務委託契約」として締結している事例が多いと思いますが、民法が定める請負のルール、準委任のルールは異なっており、各工程の業務内容の特色によって適用されるルールが異なるため、各工程の法的性質を理解した上で契約条件を決めていくことが必要と考えられます。

※民法が定める請負・準委任のルールは任意規定であり当事者が契約で条件を定めている場合には、その条件が優先します。契約で条件を定めていない場合には民法の定める請負・準委任のルールがデフォルトルールとして適用される関係にあるので、請負・準委任のルールを理解したうえで、契約条件を決めておくことが重要です。

 

請負と準委任 それぞれの特徴

 それでは請負と準委任、それぞれの特徴はどのようなものになるのでしょうか。

~請負~
 請負契約は仕事の完成を目的とする契約です。完成目標がある程度具体的に定まっている業務について、事務・業務の委託を内容とする契約です。受託者の専門性・属人性がそれほど重視されていないために下請負も原則事由となっています。建築工事契約などが典型例です。

~準委任~
 準委任契約は(法律事務以外の)事務の委託を目的とする契約です。受託者の専門性・属人性が重視される契約であり、受託者は善管注意義務をもって事務を遂行することになります。弁護士との委任契約などが典型例です。

法的な効果の違いを簡単にまとめると以下になります。デフォルトルールですので、当事者で別途契約条件を定めている場合にはそれに従うことになります。

・報酬の受取時期
 請 負:仕事の完成後
 準委任:途中で終了しても受任者に帰責性がなければ履行割合に応じて報酬請求できる。

・責任等
 請 負:履行遅滞責任、瑕疵担保責任等を負う。
 準委任:善管注意義務を果たさない場合に責任を負う。

・解除
 請 負:注文主のみ仕事完成前に解除できる。完成後の解除は制限される(建物その他の土地工作物以外のものについて仕事の目的物に瑕疵があるため契約目的を達成できない場合に限定されます)。
 準委任:各当事者がいつでも解除できる。

・再委託
 請 負:原則として事由(特約で制限される場合が多いです。)
 準委任:原則として委任者の承諾が必要。

・その他
 準委任では事務処理に必要な費用の前払請求権・償還請求権等があります。

 

各工程の法的性質

 それでは、各工程はそれぞれ請負・準委任のどちらの法的性質を持つでしょうか。注意して頂きたいのは、下記はあくまで一般的な分析で、法的性質の判断は契約の実態を見て裁判所が判断することになるということです。

要件定義
 どのような機能が必要とされているか、実現可能か、工期がどの程度かかるかという事項を決定していくフェーズのため、受託者にはコンサルタント的な役割が求められるように思います。専門性・裁量性が必要であり、準委任に親和的なように考えます。

外部設計・内部設計
 前工程の要件定義でどの程度具体的に定まっているかにも拠りますが、ある程度完成目標は具体的になっているはずのフェーズであり、請負に親和的なように考えます。

開発
 要件定義・外部設計・内部設計で定まっている内容を具体的なプログラムとして製造していく段階のため請負に親和的なように考えます。

運用・保守
 契約内容にもよります。稼働時間により報酬が決まる形式になっている事情等があれば準委任に近い性質を有していると判断される可能性がありますが、機能追加等が保守内容に含まれており、報酬支払条件として検収が必要とされているなどした場合には請負と判断される可能性もあります。(参考判例:東京地裁平成24年4月25日判決)

 

本記事は、2016年05月17日公開時点での情報です。個々の状況によっては、結果や数値が異なる場合があります。特別な事情がある場合には、専門家にご相談ください。
ご自身の責任のもと安全性・有用性を考慮してご利用いただくようお願い致します。


この記事のアドバイザー

prof Kasiko編集部

編集チーム

  • 所属:Kasiko

関連記事


新着記事
公式Facebookページ 公式Facebookページ
誰に何と相談していいかわからない方へ
050-7576-0762
[日本法規情報]
  • 平日10:00~20:00
  • 土日祝終日、受付のみ対応

誰に何と相談していいかわからないあなた。
私達が相談相手探しのお手伝いをいたします。

無料相談・全国対応 050-7576-0762 お電話ボタン