ソフトウェア開発における請負契約と準委任契約の違い

現場に広まるソフトウェア契約の誤解

ソフトウェアに関する契約を考えるとき、私が聞いたことがある現場で飛び交った話として、
「世の中のソフトウェア契約は請負契約と準委任契約の２種類しかない」
「要件定義の委託は請負契約だ。なぜなら国の委託業務の契約は請負契約として契約している。」
「いや要件定義の受託は準委任契約だ。なぜなら経産省モデル契約では企画・要件定義段階の契約は準委任型としている。」
「プログラム開発は必ず請負契約になる。」
「準委任契約はかかった工数分の報酬をもらえる。」
「SESって派遣契約でしょ？」
「請負契約で制作したプログラムの著作権は必ず発注者に帰属する。」
など、ちょっと法律を勉強した人にとっては明らかに間違っているとわかる誤解が広まっています。

ただ、面白いのはこういった誤解の中には実は法律の本質的な問題に触れている部分があるものです。その１つ、請負契約と準委任契約の違いを考えてみます。

前置き

最初に言っておくと、世の中の契約は必ず「〇〇契約」とカテゴライズされるものではなく、一見同じ行為をしていても契約の性質は異なることは多々あります。

では請負契約とか準委任契約とか売買契約ってなんなのさ、というと、民法には典型契約という契約の類型が書かれていて、その類型として請負契約、準委任契約、売買契約、というものがあります。
しかしあまり気にされてませんが、民法は、契約の内容は自由であるというのを、典型契約の記述の前に前提条件として述べています。

民法５２１条
２　契約の当事者は、法令の範囲内において、契約の内容を自由に決定することができる。

※「法令の範囲内において」というのが重要ですが、今回は割愛。

「自由に内容を決めていいよ」といっているくせになぜ典型契約なんていうものを定めているかというと、世の中の多くの契約行為のうち、使う頻度の高いものは性質やトラブルになりがちな点は研究が進んでいたので、明文で定めておくことで、トラブルの回避をしようと考えたからです。

※なぜそんな必要があるかというと、契約は当事者の意思によって内容を決定し、成立するという意思主義という大前提があるからです。意思というのは外から見えないので、契約”書”という形にしよう。でも契約書にしても書き忘れることもあるし、言葉の使い方を誤って考えていたのと違う内容になることもあります。じゃあ「普通の人はこういうつもりで契約するよね」という合理的な基準を定めておくと便利だよね（すくなくともジャッジをする裁判官にとっては）、ということです。

さて、現代は民法ができた明治時代から発展し、取引内容も複雑化しています。
もちろん時代の進展とともに民法以外でも一定の法律を作って契約ごとを解決しようとしてきたものはたくさんあります。民法と同時期にできた商法に定められている運送営業、海商や、建設業法、貨物自動車運送事業法、保険業法などの業法です。
なので、そもそも民法で全てを解決しようとはされてません。

しかし業法のような法律は一定規模の業界ができて、法律で規制する必要があるから作られるものです。ソフトウェアは今のところプラットフォーマー規制を除けばそういった動きはありません。

なので、法律で解決しようとすると、当てはめられない法律は除外していき、最後に残るのがすべての私人間の法律事項を規定する民法になります。そしてソフトウェアは明治時代には考えられてもいない典型的なものですので、素直に当てはめられない条文がたくさんあるのが、多くの人にとってソフトウェア契約をややこしくし、誤解を招いている原因です。

本題：請負契約・準委任契約の分かれ目

前置きが長くなりましたが、ソフトウェアに関する契約であろうと契約の中身は自由に決めて構いません。請負契約・準委任契約という枠にとらわれる必要はありません（そもそも家電屋でMicrosoft Officeを手に入れるのは売買契約ですしね）。

とはいえ、あまり特殊な契約内容としてしまうと世間一般の人が考えないような内容は理解されにくいので、色々明快に決めておく必要があります。
それはめんどくさいので、多くのソフトウェア契約の実務では、都度都度複雑な条件を決めるようなことはせず、だいたい請負契約や準委任契約の大枠、デフォルトルールにしたがって決めています。

なので、そもそも請負契約、準委任契約とはなんぞや、という疑問が解決できないと、都度の取引で選択や契約交渉の方向性に悩むことになります。

民法を読めばわかることは割愛して、ソフトウェア契約に当てはめる場合の請負契約・準委任契約について、経産省モデルの解説では以下のように述べています。

・・・請負に馴染むのは、業務に着手する前の段階でベンダにとって成果物の内容が具体的に特定できる場合ということになる。
これに対して、システム化計画や要件定義のフェーズは、ユーザ側の業務要件が具体的に確定しておらず、ユーザ自身にとってもフェーズの開始時点では成果物が具体的に想定できないものであるから、ベンダにとっても成果物の内容を具体的に想定することは通常不可能である。そのため、請負には馴染みにくく、準委任が適切ということになる。

つまり「成果が具体的に特定できるか」がポイントとなりそうです。

次にAIの学習済みモデルを作ることを委託する契約を考えます。

AIのモデル作成は、多くの場合ベンダーがすでに独自に作成し保有しているモデルをスタートに、データを与えて学習させます。
「学習」はAIソフトウェアの本質的な処理（データの入出力の内容、方向性）は変えず、自己のプログラム処理を変えていることになりますので、パッケージソフトウェアのカスタマイズと法的には近しいといえなくもありません。そしてカスタマイズはたいてい請負契約で実施されます。

ではAIの学習済みモデル生成は請負契約とすべきでしょうか？

経産省「AI・データの利用に関する契約ガイドラインーAI編ー」では以下のように述べています。

役務の提供を契約の目的と見るのが適切であるのか（準委任型）、役務の結果を給付することまでを契約の目的と見るのが適切であるのか（請負型）・・・
注記：準委任契約には、委任事務の処理の割合に応じて報酬を支払う「履行割合型」があるところ、前者の類型においては、準委任契約であっても、成果物を想定し、かつ、その完成を契約の内容（報酬の支払条件）とすることが可能である。請負契約との大きな違いとしては、完成義務および瑕疵担保責任の有無が挙げられる。
（中略）
学習済みモデル生成の場合はどの段階においても準委任型の契約が親和的である。
・・・学習済みモデルの特性から、契約締結時までに仕様や検収基準を確定することは難しいことが多く・・・具体的な仕事の完成を目的とし、一定の瑕疵担保責任を伴う請負型の契約にはなじみにくい。
注記：・・・評価条件を適切に設定・限定できるのであれば、・・・学習済みモデルを成果物とする請負契約として構成することになるであろうが、・・・

ここから読み取れることとして、
①契約締結時に
②仕様や検収基準を確定できる
ならば請負契約、と捉えているようです。

請負と準委任の区別の結論

以上から、（今目の前に存在するパッケージソフトウェアを提供するのは売買契約も考えられますが）ソフトウェアを作る契約において請負契約か準委任契約どちらを選択すべきかの基準は、以下になるのではないでしょうか。

①契約時に
②受注者がやらなければならないことが特定されていている
＝やらなければならないことのアウトプット（物であろうと行為であろうと）が具体にあり、かつアウトプットの合格判定（＝お金をもらえる）基準が明確
であるならば請負契約、そうでないならば準委任契約なり他の契約とすべき。

（余談）
経産省モデルでは準委任契約が親和的とされる要件定義が国の委託事業として請負契約であることがまま見られるのは、内容がかなり細かく指定されていて、検収基準が明確だからでしょうね。もしやることが曖昧だとしたら、純粋に価格だけでの決定で質が担保されないので、応札者の選定ができないから入札になじまないのでしょう。あるいは一定額以上は入札方式を取ることが義務付けられることから、質を担保するためにたどり着いた結果なのかもしれません。

余論①：請負か準委任かを判定したあとの話

ここまでの基準で請負契約か準委任契約を判定して、なにが嬉しいの？となると思います。
契約書ですべてのことを規定することは限界があるとは最初に述べました。そのため、契約書に書いていない事態をどう解決するかは、民法なりの法律で判断していくことになりますので、どの条文が当てはめられるかを見極めないと解決ができません。
つまり契約の類型を決定したことで、大筋のトラブル解決の方向性が見えることになります。

では準委任契約と請負契約の違いは何かというと、準委任契約は主に善管注意義務を負い、請負契約は完成義務と瑕疵担保責任を負います。

完成義務と瑕疵担保責任については、システム開発においては
・完成しない→完成責任
・完成して引き渡したが満足行くものではない→瑕疵担保責任
・「完成したか」は「当初予定していた最後の工程（標準的には検収の終了）まで終えているか」で判断
・プログラムにバグが生じることは不可避であるので、発見後すぐ修正・代替措置をとれるならば瑕疵とは評価しない
と過去の裁判上は捉えられています（今後も同様か、すべての事例において踏襲されるかはわかりません）。

また民法の教科書（潮見佳男「民法（全）」）には以下のように述べられています。

成果完成型の委任は、あくまでも成果の完成が債務の内容になっているのではなく、成果の完成に向けて事務処理をすることが債務の内容になっているにとどまる（手段債務）。

※手段債務の対となる言葉に結果債務があります。結果債務はある結果を実現することに義務を負うこと、手段債務はある行為を行う義務を負うことです。

逆説的ですが、仕事を受ける者がやらなければならないこと（責任をもつこと）が手段債務的ならば準委任契約。結果債務的ならば請負契約と判断ができるかもしれない、となります。

これについて千葉地方裁判所平成２１年４月１７日判決は以下のように述べています。

一般に、特定物の引渡債務のように給付行為が確定されている債務は、結果債務であり、診療契約のように給付行為の具体的内容が債務者の裁量に委ねられている債務は、手段債務とされているが、結果実現の確実性に欠ける引渡債務は、手段債務性を帯びるとされていることも併せて考慮すると、給付内容が特定されているか、結果実現の確実性がどの程度であるか等の事情を考慮して、いずれの類型に当たるかを判断するのが相当である。

つまり
①やらなければいけないことが特定されているかが基準
で、特定されているかどうかは
②結果実現の確実性などから判断すべき
ということになります。
※給付内容の特定性と結果実現の確実性がAND・OR条件なのか、私の解釈のように後者は前者の判断要素なのかは意見や解釈がわかれるように思えます。上記の判決文は素直に読むと両者をOR条件のように扱っているように読めます。それとも「給付内容」と「給付行為」は別物と考えられているのでしょうか・・・
（参考元）
http://www.junya-matsushima.net/article/13774246.html

卵が先か、にわとりが先か、といった感じですが、結果的に請負契約か準委任契約かを区別する基準は、それぞれの契約の性質とコインの裏表の関係になるようです。

準委任契約でもっぱら負う義務は善管注意義務ですが、これは非常にわかりにくいものです。
経産省のモデル契約の解説では以下のように述べています。

「善良なる管理者の注意義務を果たした」かどうかは、情報処理技術に関する業界で一般的に要求される専門知識・ノウハウにもとづく注意義務を果たしたかどうかによって決定される。すなわち、ここでの注意義務とは、自らの能力に応じた注意義務の程度という主観的な意味ではなく業界において一般的・客観的に要求される注意義務を意味し、このような注意義務を欠くときは過失が認められる。
　逆に言うと、ベンダは、ユーザに対し、善良な管理者の注意義務をもって本件業務を履行している限り、各業務の内容、結果等について責任を負わない。

つまり「プロフェッショナルな知見を活かす」ことが求められます。弁護士に委任するのを想像してもらえるとわかりやすいと思います。

じゃあイマイチなベンダーに委任してしまったら義務のレベルも落ちるのか？
おそらくモデル契約が参考にしている過去の裁判例も、そういったバラツキを抑えるため、「一般的・客観的」という基準を用いたのだと思います。

あるいはそういうベンダーは委託料が大体安いので、安かろう悪かろう、ということになるかもしれません。

契約の類型がどうであれ、委託先の選定は、あくまでも自己責任です。

余論②：契約内容って自由

一番はじめに書いたように、契約の内容は自由です。
ソフトウェア開発大国のアメリカでは、非常に多種類の契約があるようです。
この点に興味を持たれた方には英繁雄著「揉め事なしのソフトウェア開発契約」をおすすめします。
ただし現状の日本ではアメリカほど柔軟な契約は根付いていないので、受け入れられるかは不透明です（例えば成果物に対し、あらかじめ決めておいた評価指標に基づいたインセンティブを追加で支払う契約など、日本では全くみられません）。
個人的にはアメリカでの流行や常識が遅れて日本にやってくるパターンは多いので、そのうち日本でも流行るかもしれない、でもアメリカと日本の開発文化も違うので、一生来ないかもしれないとも思っています。