01 契約法務, 民法・商法

今回からは, ソフトウェア開発委託契約について解説します。今回はソフトウェア開発委託契約の意味, 法的性質, 関連法規制等の総論について解説します。　

【目　　次】

(各箇所をクリックすると該当箇所にジャンプします)

Q1： ソフトウェア開発委託契約とは?

Q2： ソフトウェア開発に関する業務とその実施主体・責任は?

Q3： ベンダへの委託の契約類型・方式・長短は?

Q4： ユーザからベンダへの委託が再委託である場合は?

Q5： ソフトウェア開発等の業務委託は下請法の対象?

Q6： 業務委託の実態が単なる人材派遣の場合は?

Q1：ソフトウェア開発委託契約とは?

A1: 「ソフトウェア開発委託契約」(または「ソフトウェア開発契約」)は, 企業(以下「ユーザ」)がソフトウェア(コンピュータプログラムやその設計書等)の開発等に関する業務を第三者(以下「ベンダ」)に委託する契約の一般的名称です。

ソフトウェアは, 一般的に, 以下のQ2で説明する段階を経て開発・導入・運営されますが, 独立行政法人情報処理推進機構(IPA)・経済産業省の「情報システム・モデル取引・契約書(受託開発(一部企画を含む), 保守運用)〈第二版〉2020年12月」(以下「モデル契約」)(こちらから入手可能)では, 一連の業務の委託の契約条件を「ソフトウェア開発委託基本契約」にまとめて規定し, 各業務の委託はその基本契約に基づき契約(「個別契約」)を締結して行う契約形式が推奨されています。Q2で解説する通り, この「モデル契約」では, ソフトウェアの開発段階だけでなく, その上流フェーズ(工程)の企画段階, その下流フェーズの運用段階, 保守段階の業務委託をカバーできるようにしています。

ソフトウェアの開発内容としては, 一からソフトウェアを開発する場合の他, ベンダがユーザ向けに開発・納入済みのソフトウェアや第三者またはベンダのパッケージソフトウェアの改修や追加ソフトウェアの開発等, 様々な内容のものがあります。

page top

Q2：ソフトウェア開発に関する業務とその実施主体・責任は?

A2: 「モデル契約」によれば, ソフトウェアは, 一般的に次のような業務段階を経て開発・導入・運用されます。

I. 企画段階： システム化の方向性/システム化計画/要件定義

II. 開発段階：システム設計(システム外部設計)/システム方式設計(システム内部設計)/ソフトウェア設計/プログラミング/ソフトウェアテスト/システム結合/システムテスト/受入・導入

III. 運用段階：運用テスト/運用

IV. 保守段階：保守

上記のように, ウォーターフォール(滝)のように上流フェーズから下流フェーズに順次工程を進めていく開発手法は「ウォーターフォールモデル」と呼ばれ, 一般的な開発手法と言えます。本シリーズでも「ウォーターフォールモデル」によるソフトウェア開発の委託契約を取扱います。[１]

以下に「モデル契約」の記載(p. 14, 40～)等を参考に, 各フェーズを簡単に説明します。

・「システム化の方向性」は, ユーザが, 一定の業務の処理をソフトウェアとハードウェア, ネットワーク等から成る情報システム(「システム」)により実現すること(「システム化」)の対象業務, システム化のニーズと課題等を分析し, システム化の方向性を決定するフェーズです。「システム化計画」は, システム化の方向性をより具体化するフェーズです。

・「システム化の方向性」および「システム化計画」は, ユーザがどのようなシステムを開発したいかという点についての方向性を決めその計画を作成するフェーズなので, ユーザの責任で確定・作成しなければなりません。

但し, 一般のユーザは, 通常, システム化についての十分な技術的・専門知識がないことも多いので, 「システム化の方向性」確定・「システム化計画」作成のため, ベンダ等から, 利用可能な既存ソフトウェア(パッケージソフトウェアを含む)やクラウドサービス(例：SaaS), 必要なハードウェアやネットワーク, システム化に要する総費用の試算額, 当該方向性・計画の技術的・経済的合理性・現実性等について提案やコンサルティングを受ける場合が多いでしょう。「モデル契約」では「システム化の方向性」確定・「システム化計画」作成に係る(有償)コンサルティングのための契約類型として「準委任」(ユーザが主体・責任/ベンダはユーザを支援)を推奨しています。

・「要件定義」は, 上記のシステム化計画を受けて, 実装すべきシステムの機能要件(ユーザの要求を満足するためにソフトウェアが実現しなければならない機能に係る要件)・非機能要件(レスポンスタイム/セキュリティ等機能要件以外の要素に係る要件)(それぞれ詳しくは脚注[２]参照)を定義するフェーズです。契約類型として「モデル契約」では「準委任」を推奨しています。

・「システム設計(システム外部設計)」は, ソフトウェア完成後に, ユーザの従業員等がそのソフトウェアを使用する際にパソコン上に表示される操作画面や出力する帳票等のインターフェースを決定し, システムの機能を大まかに具体化するフェーズです。契約類型として「モデル契約」では「準委任」と「請負」(ベンダが主体・責任)のいずれかを選択するようにしています。

・「システム方式設計(システム内部設計)」から「システム結合」までのフェーズについては, 契約類型として, 「モデル契約」では「請負」を推奨し, 「システムテスト」については「準委任」と「請負」のいずれかを選択するようにしています。

・「受入・導入」は, 開発されたソフトウェアを, ユーザがソフトウェアを使用する環境に導入するフェーズです。契約類型として「モデル契約」では「準委任」を推奨しています。

・「運用テスト/運用」は, 開発されたソフトウェアを, ユーザが実際に利用・運用するフェーズです。契約類型として「モデル契約」では「運用テスト」について「準委任」を推奨し, 「運用」について「準委任」と「請負」のいずれかを選択するようにしています。

・「保守」は, 開発されたソフトウェアの維持管理を行うフェーズです。契約類型として「モデル契約」では「準委任」と「請負」のいずれかを選択するようにしています。

page top

Q3：ベンダへの委託の契約類型・方式・長短は?

A3: 大まかに言うと, 特にソフトウェア開発段階の業務の委託について, ①全部一括して請負契約として契約する方式(以下「一括請負方式」)と, ②各フェーズごとに別々に準委任契約または請負契約として契約する方式(以下「多段階契約方式」)があります。

Q1でも言及した通り, 「モデル契約」は, 多段階契約方式を前提に, 全てのフェーズをカバーする契約条件を規定した「ソフトウェア開発委託基本モデル契約書」のもとで, 各フェーズ別に, ユーザとベンダ間で, 具体的作業内容(範囲, 仕様等), 契約類型(請負・準委任) , 作業期間または納期その他その委託の個別条件を定めるための「個別契約」を締結する方式をとっています。

各方式について考えられるユーザ/ベンダの主なメリット・デメリットは以下の通りです。[３]

契約方式

ユーザのメリットまたはデメリット

ベンダのメリットまたはデメリット

一括

請負方式

<メリット>

・社内で承認されたソフトウェアの完成までの総予算の範囲内でソフトウェアの完成まで委託可能。

・ソフトウェアが完成しない限り報酬を支払う必要がない。

<デメリット>

契約時に開発すべきソフトウェアがある程度具体的に定まっていない場合, 期待したソフトウェアが完成せずまたは完成・納入が遅延するリスクがある。

<メリット>

最初から, ソフトウェア完成までの報酬がユーザから保証される。

<デメリット>

契約時に開発すべきソフトウェアがある程度具体的に定まっていない場合, ①工数・納期, コスト・報酬の見積もりが困難, また, ②契約で定めた金額, 納期等の範囲内でソフトウェアを完成できず, また, その結果, 報酬を受けられないリスクがある。(＊)

多段階

契約方式

<メリット>

・ユーザが, 各工程ごとに成果の内容およびそれに対する満足度を確認することにより, 期待するソフトウェアの完成により確実に近づいていける。

<デメリット>

・最初の段階ではソフトウェアの完成までの開発総費用が確定しない。

・ソフトウェア完成までの全体予算でなければ社内承認が得られない場合は, この契約方式によることができない。

・完成の途中段階までの予算承認を得てその段階までの契約ができた場合でも, ①その後完成までのコストが増大し予算を得られないリスクがある, また, ②初期段階ではベンダにソフトウェアの完成およびその開発スケジュール・納期について責任を負わせることができない。

・契約を各工程ごとに細分化して締結することで, ①損害賠償額の上限等を含めベンダの契約違反時の責任追及が制限される, また, ②最終的にソフトウェアが完成しなくてもそれ以前の締結・履行済みの工程分の報酬は支払う必要がある。

<メリット>

・各工程ごとに委任と請負が選択可能なので, 開発すべきソフトウェアがある程度具体的に定まり, コスト・納期を正確に見積可能となるまで(例：要件定義確定まで)準委任契約とすることにより, 上記(＊)のリスクを回避できる。

・契約を各工程ごとに細分化して締結することにより, ①損害賠償額の上限等を含め契約違反時のリスクを分散し易い, また, ②最終的にソフトウェアが完成しなくてもそれ以前の締結・履行済みの工程分の報酬は確保できる。

<デメリット>

実際に個別契約を締結したフェーズより後のフェーズの受注は保証されていない。

【請負契約とした場合と準委任契約とした場合の法的効果の比較】

請負と準委任では, 民法等法律上の相違[４]は多くありますが, 実際の契約では法律上の原則と異なる定めも可能です。例えば, 準委任では, 原則として, ソフトウェアが完成・納入されなくてもベンダがユーザに対する支援等の委託業務を履行している限りユーザは報酬を支払う義務があります(民法648(2))が, 契約上はソフトウェアの引渡しを条件として報酬を支払うこととすることも可能です(民法648の2(1)参照)

従って, 請負契約とした場合と準委任契約とした場合で必ず生じる重要な相違は, 請負を選択した場合には, ソフトウェアが納期までに完成・納入されないときは, ベンダの契約違反(債務不履行)となり, ベンダの損害賠償責任やユーザの契約解除権が生じるのに対し, 委任を選択した場合には, 特約のない限りベンダには完成責任がないためにこれらが生じないことです。

【二段階契約方式】

ユーザ側の立場から, 契約を各工程ごとに細分化して締結することを批判し, 可能な限り一括請負方式にすべきとし, 基幹系システム等大規模で複雑なシステムの開発等で要件定義前にベンダがソフトウェア完成までの見積もりが困難な場合等, 一括請負方式が適切でない場合でも, 以下のように二段階で発注すべきとする考え方もあります(脚注[５]資料参照)。

①要件定義開始の際, システム開発に関する基本契約および要件定義に関する個別契約(請負契約または準委任契約)を締結する(第一段階)。

②要件定義完了後, 外部設計から運用テストまでの工程について一括して請負契約(個別契約)により発注する(第二段階)。

【本稿の考え方】

本稿では, ユーザとベンダー両方の利益の調整の観点から, 以下のような契約方式がよいのではないかと考えます。

１．原則

①要件定義の工程については準委任契約とする。

②要件定義以後のソフトウェア完成までの業務については一括して請負契約とする。

契約形式としては, 以下が考えられ, そのいずれでもよい。

(a) ①と②それぞれ別々の独立単独の契約とする。(例)「要件定義支援委託契約」＋「ソフトウェア開発委託契約」

(b) 基本契約＋①・②の個別契約とする。(例)「ソフトウェア開発基本契約」＋「(要件定義支援)個別契約」/「(ソフトウェア開発委託)個別契約」

２．例外

開発内容が, 小規模で複雑でないこと, 開発期間が短いこと, ベンダが過去に何度も同種システムの開発経験があること, ベンダのシステム提案書(大まかな基本機能・システム構成を記載したもの)等を通じユーザの期待とベンダの想定がほぼ合致していること等から, ベンダが相当程度の精度・確度で必要な総費用(またはその最大額)・開発期間(またはその最長期間)を見積りかつソフトウェアの要件定義を作成できると予想される場合には, そのシステム提案書等に基づきソフトウェアを開発するという内容の一括請負契約を締結してもよい。

契約形式としては, そのような内容の独立単独の契約としても, 基本契約＋請負の個別契約, どちらでもよい。

page top

Q4：ユーザからベンダへの委託が再委託である場合は?

A4: 下図のように, ユーザ自身が第三者(エンドユーザ)からソフトウェアの開発を受注しベンダに再委託(再外注)する場合には, エンドユーザ/ユーザ間の契約と, ユーザ/ベンダ間の契約の間で整合性をとること, ユーザ/ベンダ間の契約に下請代金支払遅延等防止法(以下「下請法」)の適用がある場合には下請法を遵守する必要があること等が必要となります。

[エンドユーザ] ＝(委託)⇒ [ユーザ] ＝(再委託)⇒ [ベンダ]

【解　説】[６]

この場合, 例えば, ユーザは, エンドユーザ/ユーザ間の契約上, ソフトウェアの著作権をエンドユーザに譲渡することとなっている場合にはユーザ/ベンダ間の契約でその著作権をユーザが譲り受けることとなっていなければなりません。また, エンドユーザへのソフトウェアの納入期限の前にベンダからの納入期限を定めなければなりません。更に, ユーザ/ベンダ間の契約不適合責任の期間がエンドユーザ/ユーザ間のそれより短い場合は, 残りの期間については, ユーザが自己の責任・費用で対応しなければなりません。

一方, ユーザからベンダへの業務委託に下請法の適用がある場合(Q5で解説)には, エンドユーザからユーザへの支払期限がソフトウェア検収後3か月以内であっても, ユーザからベンダへの支払期限は受領日から60日(または2か月)以内にしなければなりません。

また, ユーザが, エンドユーザからの仕様変更に応じる場合には, 事前にベンダから同意を得る必要があり, ユーザ/ベンダ間の契約に下請法の適用がある場合には, その仕様変更が下請法上禁止される不当な変更・やり直しに該当しないようにしなければなりません。

page top

Q5：ソフトウェア開発等の業務委託は下請法の対象?

A5: ソフトウェアの開発等の業務の委託が以下のいずれかの【取引の類型】に該当しかつ両当事者が以下の【親事業者と下請事業者の関係】にある場合には下請法が適用され, その場合, ユーザは以下の【義務・禁止事項】を遵守しなければなりません。[７]

【取引の類型】

(1)情報成果物の作成の委託(2(3))

(*)「情報成果物」(2(6))＝(コンピュータ)プログラム/設計図/デザイン/コンサルティングレポート等

(類型1)自社が顧客に提供する情報成果物の作成の委託(例：ソフトウェア開発業者が消費者に販売するソフトウェアの作成を他のソフトウェア開発業者に委託すること)

(類型2)自社が顧客から作成を請け負う情報成果物の作成の委託(例：ソフトウェア開発業者がユーザーから開発を請け負うソフトウェアの一部の開発を他のソフトウェア開発業者に委託すること。要するにソフトウェア開発の再委託)

(類型3)自社で使用する情報成果物を自社で作成している場合におけるその情報成果物の作成の委託(例：事務用ソフトウェア開発業者が自社で使用する会計用ソフトウェアの一部の開発を他のソフトウェア開発業者に委託すること)。

(2)役務提供の委託(2(4))

(*)「役務」：サービス全般。

(類型)顧客に提供する役務の提供の委託(例：保守業務の再委託)。

【親事業者と下請事業者の関係】親事業者(ここではユーザ)が左欄でかつ下請事業者(ここではベンダ)が同じ列の右欄の関係(2(7),(8))

(a)プログラム作成に係る情報成果物作成委託／情報処理に係る役務提供委託

親事業者

下請事業者

資本金3億円超の法人事業者

資本金3億円以下の法人事業者(又は個人事業者)

資本金1千万円超3億円以下の法人事業者

資本金1千万円以下の法人事業者(又は個人事業者)

(b)プログラム以外の情報成果物作成委託／情報処理等以外に係る役務提供委託

親事業者	下請事業者
資本金5千万円超の法人事業者	資本金5千万以下の法人事業者(又は個人事業者)
資本金1千万円超5千万円以下の法人事業者	資本金1千万円以下の法人事業者(又は個人事業者)

【親事業者の義務・禁止事項】

(親事業者の義務)取引条件等を記載した書面の交付義務(第3条)／支払期日を定める義務(情報成果物・役務(役務)受領日から60日(または2か月)以内)(第2条の2)／書類の作成･保存義務(第5条)／遅延利息の支払義務(第4条の2).

(親事業者の禁止事項)(第4条)受領拒否／下請代金の支払遅延／下請代金減額／返品／買いたたき／購入･利用強制／報復措置／有償支給原材料等の対価の早期決済／割引困難な手形交付／不当な経済上の利益の提供要請／不当な給付内容の変更・やり直し

—　従って, 例えば, ユーザがベンダに対し, 自らの都合でまたは再委託の場合にはエンドユーザの都合で, ソフトウェアや支援業務の受領日から60日超の支払期日を定めること／これらを受領拒否すること／当初代金から減額すること／契約通りに支払わないこと(支払遅延)／不当に仕様変更すること・開発をやり直させること等は下請法に違反する可能性があります。

page top

Q6：業務委託の実態が単なる人材派遣の場合は?

A6:　ベンダの要員がユーザの事務所に常駐し実体的にユーザの指揮下で業務を行う等の場合, 契約の名称・当事者が定めた契約類型(請負・準委任)にかかわらず, 労働者派遣法上の「労働者派遣」に該当し, 派遣元(受託者：ここではベンダ)は, 厚生労働大臣からの派遣事業許可の事前取得(5(1)), 派遣期間の制限(40条の2)その他の義務を負い, 派遣先(委託者：ここではユーザ)も, 派遣先責任者の選任(41)その他の義務を負います。

実態は労働者派遣であるのにこれら義務・制約を免れるため, 請負契約や業務委託契約を締結し偽装することは, 一般に「偽装請負」と呼ばれ取締りの対象となります。より詳しくは第24回(業務委託契約(総論))のQ5(労働者派遣法との関係は?)を参照して下さい。

今回はここまでです。

page top

「QAで学ぶ契約書作成/審査の基礎」シリーズ：過去の回

^[８] 　　　　　　

【注】

[１] 【ウォーターフォールモデル以外の開発方式の契約】ウォーターフォールモデル以外に, 近年, アジャイル方式と呼ばれる開発方式も提唱され, 『アジャイル開発版「情報システム・モデル取引・契約書」』が, IPAより2020年3月に公開されている。これは, 準委任契約を前提としている。

[２]【機能要件】ユーザの要求を満足するために, ソフトウェアが実現しなければならない機能に係る要件。システム機能及びデータにより定義される。〈例〉システム機能：業務フロー, 業務処理定義, システム機能(階層, 体系等)等。データ：データ構造(階層, 関係等), データ項目定義等。【非機能要件】　機能要件以外のすべての要素に係る要件。業務内容及びソフトウェアの機能と直接的な関連性を有さない品質要件, 技術要件, 移行要件, 運用要件, 操作性及び付帯作業等からなり, それぞれに対する目標値及び具体的事項により定義される。(例)品質要件：効率性(平均レスポンスタイム, ピーク時性能等), 信頼性(平均故障間隔, 平均復旧時間等), 保守性(解析, 変更等), 操作性(処理時間, 処理容易性, 操作理解性など), セキュリティ要件等。技術要件：実現方式(処理方式, 通信プロトコル等), システム構成(ネットワーク構成, ソフトウェア構成, ハードウェア構成等), 開発方式(開発言語等)等。移行要件：移行対象業務, 移行対象データ, 移行時期, 移行体制等。運用要件：運用体制, 運用形態, 運用スケジュール, 運用管理方式(監視, バックアップ等), 災害対策等。付帯作業：ハードウェア展開, ソフトウェア展開, ユーザ教育等。(以上「モデル契約」p. 5脚注)

[３] (参考) 阿部・井窪・片山法律事務所 (編集)「契約書作成の実務と書式 -- 企業実務家視点の雛形とその解説　第2版」2019/9/24(2021/2/20補訂) (p. 391)

[４] 【民法等法律上の請負と準委任の相違】「QAで学ぶ契約書作成・審査の基礎第24回業務委託契約(総論)」Q3の表参照。

[５] 【二段階契約方式】西本強「ユーザを成功に導くシステム開発契約―クラウドを見据えて〔第2版〕」 2016/7/8, p. 99-104

[６] 伊藤雅浩・久礼美紀子・高瀬亜富「ITビジネスの契約実務〔第2版〕」商事法務, 2021/10/18 (p. 37-39)を参考にした。

[７] (参考) (1)「下請取引適正化推進講習会テキスト」. (2) 経産省「情報サービス・ソフトウェア産業における下請適正取引等の推進のためのガイドライン」(2019年3月改訂). (3) 公取委「下請代金支払遅延等防止法に関する運用基準」

[８]

【免責条項】

本コラムは筆者の経験にもとづく私見を含むものです。本コラムに関連し発生し得る一切の損害等について当社および筆者は責任を負いません。実際の業務においては, 自己責任の下, 必要に応じ適宜弁護士のアドバイスを仰ぐ等してご対応ください。

【筆者プロフィール】

浅井敏雄 (あさいとしお)

企業法務関連の研究を行うUniLaw企業法務研究所代表／一般社団法人GBL研究所理事

1978年東北大学法学部卒業。1978年から2017年8月まで企業法務に従事。法務・知的財産部門の責任者を日本・米系・仏系の三社で歴任。1998年弁理士試験合格 (現在は非登録)。2003年Temple University Law School (東京校) Certificate of American Law Study取得。GBL研究所理事, 国際商事研究学会会員, 国際取引法学会会員, IAPP (International Association of Privacy Professionals) 会員, CIPP/E (Certified Information Privacy Professional/Europe)

【発表論文・書籍一覧】

https://www.theunilaw2.com/

メルマガ会員登録