受託開発ビジネスの法的留意点（契約書文例付き）

多くの会社が、主たる事業として、あるいは主たる事業とは別に、何らかの受託開発を業務として行っています。本稿では、受託開発の法的留意点を解説します。

契約の法的性質

請負か準委任か

一般に、システム開発契約は、請負契約の性質を有するものとして、契約書が作成されます。
しかしながら、あらゆるシステム開発契約において請負契約という整理が適切であるわけではありません。

例えば、独立行政法人情報処理推進機構が公表しているアジャイル型開発のモデル契約では、法的性質は準委任契約とされています。
https://www.ipa.go.jp/files/000081484.pdf

また、経産省が公表しているAI技術を利用したシステム開発のモデル契約も、準委任契約と整理されています。
https://www.meti.go.jp/press/2019/12/20191209001/20191209001-3.pdf

請負と準委任の根本的な違いは、「仕事の完成」を目的としているか、言い換えれば、あるシステムを契約時に決めた仕様に従って完成させる義務を負うか（負う場合は請負、負わない場合は準委任）、という点です。
一般的に請負契約であるとされているのは、原則としてウォーターフォール型開発が想定されています。ウォーターフォール型開発では、当初に仕様を取り決めて、それを作っていくという作業ですから、まさに、仕事の完成を目的としており、請負契約であると言えます。
他方、アジャイル型開発の場合、仮で作ってみて、発注者のフィードバックを得て修正していくという作業を繰り返すことで、システムの完成を目指すことになります。よって、契約時点では、特定の「仕事の完成」を約束することができないため、準委任契約が適切ということになります。また、AIソフトウェア開発においても、AI学習の結果どのようなシステムが出来上がるかは、やってみないと分からず、ベンダにおいて特定の性能を持ったシステムの作成を約束することが困難です。よって、これもまた、準委任契約が適切ということになります。

このように、システム開発と一口に言っても、その具体的な内容によって、契約の法的性質は変わってくるのであり、それを意識して契約書を作成することが重要であるということになります。

なお、誤解を避けるため付言すると、アジャイル型開発・AI開発なら当然に準委任を採用すべきということではありません。これらであっても、一定の機能要件を保証することができる場合はあり得るため、請負形態を採用することは可能です。
場合によっては、発注者側のオーダーで請負とせざるを得ないことも多いでしょう。重要なのは、そういった場合に、どこまでの機能を保証するかを明確に定めておくということです。

契約不適合責任／善管注意義務について

「仕事の完成」を目的としているか否かが請負と準委任の区別基準であると述べましたが、請負と準委任とでどのような違いがあるのでしょうか。
これについては、色々なサイト等で解説されていますので、調べればすぐ分かると思いますが、ここでは、もっとも重要な、「完成義務の有無」に焦点を当てて解説します。

請負契約の場合、完成義務を負いますから、その帰結として、契約不適合責任が生じます。
しかし、準委任の場合、完成義務は負いません。では何の義務もないのかというと決してそうではなく、準委任の場合、善管注意義務を負います。たまに、契約書で、準委任契約としつつも契約不適合責任を定めている例がありますが、理論的に誤りですので注意しましょう。

とはいえ、準委任の場合でも、善管注意義務の水準を定めつつ、それに違反した場合の効果を契約書で定めた場合、契約不適合責任類似の責任を設けることは可能です。
よく、請負契約とするか準委任契約とするかで、契約締結段階で揉めているケースがありますが、契約自由の原則から、準委任契約とする場合でも、善管注意義務を具体化することで、対処できる場合が多いです。

準委任契約としつつ、契約不適合責任類似の責任を定める場合の文例は以下のとおりです。

偽装請負のリスク

システム開発においては、多重請負の構造となっている場合が多く、また、受注者が発注者の作業場で業務を行う形態（SES）が珍しくありません。しかし、これには、偽装請負のリスクが常に存在しています。偽装請負は、労働力を受け入れた側（発注者側）にも、提供した側（開発会社側）にも、刑事罰のリスクがあるため、場合によっては発注者と連携して、偽装請負にならないよう防止する体制を構築する必要があります。

偽装請負の問題及び回避策については、本サイト内の以下の記事で解説しています。

偽装請負回避のポイント
https://techlawlab.biz/counterfeit-contract-avoidance-points/

著作権の取り扱い

そもそも、著作権とは、著作物を創作した者に帰属するのが原則です。すなわち、受託者に所属する従業員個人です。ただし、例外的に、職務上なした著作については、「職務著作」として、当該個人が属する企業に帰属します。すなわち、受託者たる会社です。

ここまでで、成果物の著作権が、受託者たる会社に帰属するのが原則であることを確認しました。
しかしながら、実務上は、さらに、受託者から発注者に、契約で譲渡することが一般的です。特に、多重請負の場合であって、1次商流でそういった契約がなされていると、それ以降の商流においては、発注者に移転させることに従わざるを得ないのが通常でしょう。

しかしながら、受託会社が、成果物の一部を他案件に流用したい場合（成果物に使ったノウハウ、モジュール、ルーチン等）や、成果物の一部に、元々自社が持っていた著作物（ソースコード等）を使った場合、成果物全体の著作権を譲渡してしまうと、他案件での開発に支障が生じることがあります。

このような事態を防止したい場合には、成果物の著作権は譲渡するけれども、元々受託会社が持っていた著作権や、汎用的に利用可能なノウハウ、モジュール、ルーチン等については、受託会社に権利を留保する、という対応が考えられます。この場合の文例は以下の通りです。

下請法の活用

受託開発会社にとって、強い味方になるのが下請法です。

受託開発の場合、上流に別の発注者がいる場合、多くはプログラム作成委託か情報成果物作成委託に該当すると考えられますので、発注者の資本金が1000万円超、開発会社の資本金が1000万以下の場合に適用可能性が出てきます。

下請法の適用がある場合には、開発会社は、下請法に基づいて、例えば以下のような事項が主張できます。

• 成果物の仕様を明確にするよう求めること（3条書面記載事項のため）
• 代金支払期日を納品から60日以内とすること
• 不当な減額の禁止、返品の禁止
• 一方的な仕様変更（不当な給付内容の変更）、やり直しの禁止
• 発注者が指定する物・役務を強制的に購入・利用させることの禁止（購入・利用強制の禁止）

下請法は、強行法規のため、発注者には、下請法を遵守しないという選択肢はありません。
よって、下請法は時に開発会社の強い味方になるのです。

多い紛争類型とその予防策

契約未了のまま先行作業してしまい代金が支払われないケース

発注者サイドの都合で厳しい納期を要望され、正式に契約締結する前に開発作業に着手してしまったものの、最終的に正式発注を受けられず、代金が支払われない、というのはよくある紛争類型の一つです。

この手の紛争の場合、①契約成立の有無、②契約成立を期待させる言動の有無、がポイントになります。

①については、契約は必ずしも書面を取り交わさなければ成立しないというものではありませんから、契約の主要条件（成果物の仕様、代金額、納期等）が煮詰まっており、かつ発注のメールももらっているなどの状況であれば、契約成立が認定されることもあります。

②については、契約成立が認定できない場合でも、契約成立を期待させる言動が発注者側にある場合、「契約締結上の過失」として、損害賠償請求ができることがあります。

受注者サイドとしては、紛争リスクを感じた際には、上記の観点から、エビデンスを残していくことが重要になります。

仕様変更があったのに追加報酬が払われないケース

追加作業を求められ対応した場合に、当初の契約金額内であるなどとして、追加報酬が支払われない場合があります。

この手の紛争の場合、①当初の仕様の内容、②追加発注の有無、が争点になります。

①については、アジャイル開発の場合には決まっておらず立証が困難ということもあろうかと思いますが、ウォーターフォール開発であれば、ちゃんと仕様書を作成しておくことが予防策になります。

②については、発注者との連絡協議会などを開催し（契約書で、連絡協議会について記載することも少なくありません）、都度議事録を残すことが予防策となります。なお、追加発注の代金額まで明確な合意ができていなかったとしても、商法512条に基づく相当額の報酬請求ができる可能性もあります。

契約不適合責任を追及されるケース

納品後に、契約不適合責任を追及されるケースがあります。この手の紛争の場合、仕様を明確にしておくことが何よりの予防策になります。

ウォーターフォール開発の場合はもちろん、アジャイル開発の場合であっても、連絡協議会の議事録を都度残すことなどにより、「どのような仕様の成果物を納品することになっていたか」を事後的に立証できるようにしておくことが肝要です。

本記事に関する留意事項
本記事は掲載日現在の法令、判例、実務等を前提に、一般的な情報を掲載するのみであり、その性質上、個別の事案に対応するものではありません。個別の事案に適用するためには、本記事の記載のみに依拠して意思決定されることなく、具体的事案をもとに適切な専門家にご相談ください。