契約の法的性質と作業内容の紛争～ソフトウェア開発紛争の解説③～

前回（開発中途終了時にベンダーが負う責任）、前々回（「仕事の完成」とは？）と、ソフトウェア開発に関する紛争について解説いたしました。
　今回は、多くのソフトウェア開発契約関連紛争で共通して問題となる、契約の法的性質と作業内容の確定について解説します。

１　契約の法的性質の問題
２　作業内容の確定の問題
３　まとめ

１　契約の法的性質の問題

まず、ソフトウェア開発契約から生じる紛争は、「契約がどのような法的性質を有するものなのか」を明らかにすることで解決できる問題がいくつかあります。

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

一口にソフトウェア開発契約と言っても、その内容は様々ありますが、大きく分けると次の法的性質を有するものに分類できます。

①仕事の完成を目的とする契約＝請負契約
②仕事の完成を目的としない契約＝準委任契約

仕事の完成を目的とする契約の場合、受注者（ベンダー）は発注者（ユーザー）に対して仕事の完成品（成果物）を納品することまでが契約により定められたベンダーの義務であるとされます。
これに対し、ベンダーが成果物を完成させることが契約上の義務ではないといえる場合には、民法上の準委任契約であるとされます。

第六百三十二条　請負は、当事者の一方がある仕事を完成することを約し、相手方がその仕事の結果に対してその報酬を支払うことを約することによって、その効力を生ずる。
第六百四十三条　委任は、当事者の一方が法律行為をすることを相手方に委託し、相手方がこれを承諾することによって、その効力を生ずる。

「準」委任契約というのは、法律事務以外の行為を委任する場合の契約のことをいいますが、法律的な効果は委任契約と同じです（民法６５６条）。

なお、ソフトウェア開発契約が上記の請負契約と準委任契約のどちらかに必ず分類されるわけでもありません。これら以外の契約（労働者派遣など）の場合もありますし、１つの契約の中で請負部分と準委任部分が混ざっている場合もあります（この点は後述します）。
ただ、実務上やはり多いのは請負契約か準委任契約のどちらかですので、以下では両契約を取り上げます。

１－２　請負契約と準委任契約はどこが違うのか？

上記の請負契約と準委任契約は、一般に、次の点が異なると考えられています。

・ベンダーは報酬を当然に請求できるか
・ユーザーはいつでも自由に契約を解除できるか
・成果物や事務の内容に問題があった場合のベンダーの責任
・ベンダーは再委託や下請を使えるか

まず、請負契約は、当事者が①完成させる仕事の内容と②その報酬金額を合意することで成立する契約です（民法６３２条）。そのため、請負契約では、報酬を請求できることが契約内容に当然に含まれています。
一方、準委任契約の場合、民法上は原則として無償とされるので（民法６４８条１項）、当事者が報酬の合意をしない限り、基本的には受任者であるベンダーは報酬を請求できません。ただし、契約書上で明確に合意していなかったとしても「黙示の合意」がある場合や、商法５１２条の適用がある場合には、「相当な報酬」を請求できる可能性があります。
さらに、委任が受任者の責めに帰すべき事由によらず（委任者に原因があったり、天災などの不可抗力などにより）中途で終了した場合には、受任者は、それまでの履行割合に応じた報酬を請求することができます（民法６４８条３項）。

次に、解除の可否については、請負契約では発注者は受注者に損害賠償しなければ契約を解除できません（民法６４１条）。
これに対し、準委任契約では、両当事者がいつでも契約を自由に解除することができます（民法６５１条１項）。ただし、相手方の不利な時期に解除することはできません。

さらに、請負契約では、仕事の成果物に瑕疵があった場合、受注者であるベンダーは自己の過失の有無に関係なく瑕疵担保責任を負い、契約の解除や損害賠償請求を発注者であるユーザーからされることになります（民法６３４条１項）。
ですが、準委任契約の場合には、委任事務の遂行の過程で生じた成果物に瑕疵があったとしても瑕疵担保責任を負うことはありません。ただし、受任者は委任者から委託された事務をきちんと行わなければならない義務（善管注意義務）を負っているので（民法６４４条）、事務の遂行態様等に問題があるために委任者に損害を与えた場合には、債務不履行責任として、損害賠償請求や契約解除をされる可能性があります。

そして、請負契約の場合には、仕事を完成させるために下請を使うことができます。
しかし、準委任契約の場合には、委任者の許諾等がないかぎり原則として再委託はできないと考えられています。これは、準委任契約が、当事者同士の信頼関係を基礎とする契約であって、勝手に再委託できるとすると委任者に不利益が生ずることが理由とされています。

１－３　契約認定のポイント

上記のとおり、請負契約と準委任契約は、契約の効果に異なる点があります。そのため、報酬請求権があるかどうかや瑕疵担保責任の有無などが争われるケースでは、今回紛争になっているソフトウェア開発契約の法的性質が請負契約なのか準委任契約なのかを認定する作業が必要となります。

当事者が締結した契約がどのような契約であるかを認定するためには、一般的に次のような事情が重要視されます。

請負か準委任かの判断要素

・ソフトウェア完成までのスケジュールを記載した工程表が作成されていたかどうか
・ソフトウェア開発業者の開発歴において、同程度以上のソフトウェアを開発したことがあったかどうか
・代金支払時期
・報酬の決め方が単価方式であるかどうか
・完成物の具体的な内容が確定していたかどうか
・瑕疵担保責任や成果物に対する保証条項の有無
・検収に関する規定の有無
・契約書の表題

これらの事情を踏まえ、当該ソフトウェア開発契約が「仕事の完成」を契約の目的としたかどうかによって請負契約か準委任契約かを判断していくことになります。
もっとも、小さな成果物が予定されているにすぎない場合には、請負契約ではなく準委任契約であると認定されることもあります。

１－４　作業内容ごとに法的性質を検討することもある

１つのソフトウェアを開発するまでには、成果物の完成を予定しない作業工程もあります。そして、成果物の有無で請負と準委任を分類できるのであれば、各作業工程も請負と準委任のいずれかの性質を有していることになります。

なお、経産省のHP では、各作業工程の性質を踏まえたモデル契約書が公開されており、契約書を作成するときに参考になります。

１－５　契約の法的性質から解決した裁判例

被告が原告に対し調剤薬局向けの顧客・在庫管理等のシステム開発を発注したところ、原告の作業が途中であるにもかかわらず被告が原告の債務不履行を理由に契約を解除した事案があります（東京地裁平成２０年４月２４日判決）。

この事案の争点は、①本件契約が準委任契約であるのか請負契約であるのか、②原告の債務不履行の有無、③相当な報酬額でした。

裁判所は、争点①（契約の法的性質）について、原告がこれまで調剤薬局向けシステムを開発した経験がなく被告側が要求仕様を伝えない限り開発は進められなかったこと、一般的にも基本設計までは発注者側が主導的立場にあること、原告がレビュー前の基本設計書（要件定義書）の作成をほぼ完了し、前倒しで詳細設計書の３，４割を作成していたことなどを理由に、原告・被告間の契約は、契約が解除される段階までは、被告側の要望を適宜取り入れながらシステムの開発に必要な設計書を作成する事務の遂行を目的とし、これに対して報酬が支払われる準委任契約であったと認定しました。
そして、争点（②原告の債務不履行の有無）については、被告側が原告に要求仕様を伝えなかったことが開発遅延の原因であるとして、原告の債務不履行を認めませんでした。
最終的に、争点③（相当な報酬額）は、原告の作業割合からすれば原告請求額の７，８割が相当であるとして、被告に対し原告への報酬支払を命じる判決が出ました。

２　作業内容の確定の問題

契約の法的性質を明らかにするだけでは解決できないケースもあります。それは、作業の範囲や報酬の金額が当初から合意されていたのかどうかが争われるケースです。

２－１　作業内容の確定が問題となるケース

ソフトウェア開発に関する紛争では、仕事が完成しているかどうか、ソフトウェアに瑕疵があるかどうかも多く争われます。ですが、それらに共通して問題となるのが、仕事の具体的内容や報酬額についてどのような合意をしたのかという点です。

例えば、開発途中で仕様が変更となり、ベンダーが新たな作業を行わなければならなくなった場合、その作業が「追加の作業」なのか、それとも「当初から合意されていた作業」なのかが明確でないと、その新たな作業についての報酬の請求権が認められるのかどうかが決められません。
そして、何が「追加の作業」なのかを明確にするためには、「当初から合意されていた作業」を明らかにしておく必要がありますが、「当初から合意されていた作業」の証拠が一元的にまとめられていないことが多いため、追加作業の範囲をめぐる紛争に発展するケースが多発しています。

２－２　作業内容の確定が争われた裁判例

被告が業務上使用する書籍在庫管理システムの開発契約に関して、当初開発が予定された１８２本のプログラムを大きく超える約４００本のプログラムをベンダーが開発し、超過分のプログラムは当初のシステム開発請負契約の範囲外であるとして、追加報酬を請求した事案があります（東京地裁平成１７年４月２２日判決）。この事案において、ユーザーは「現行システムでは約４００本のプログラムを使用しているのだから、ベンダーの作成した約４００本のプログラムはすべて本来業務だ」と争いました。なお、被告から原告に発注されたのは、被告が他の会社に一度発注したが開発が成功しなかったからでした。

裁判所は、原告が作成した見積書は、被告が他の会社に発注した業務範囲を前提に作成されたものであること、被告が他の会社に発注した業務範囲には個別出版社対応のプログラムは含まれていなかったと認定し、そのため、原告と被告が締結した一括請負契約の業務範囲に個別出版社対応プログラムは含まれていなかったと判断しました。
そして、「追加注文と評価される業務については、当事者間に相当の報酬を支払う旨の合意があるものと見るべきであるから、上記文言の有無にかかわらず、原告は被告に対して、追加注文部分について相当額の報酬請求権を取得するものというべきである。」と判示し、原告の報酬請求を認容しました。
なお、原告の見積書には、「作業着手後の機能追加、変更等により工数に大幅な変動が生じた場合は別途相談させていただきます」と記載されていましたが、裁判所は「見積書に上記の文言がなくとも」と、見積書の記載を重要視はしませんでした。

２－３　作業内容確定の重要性

上記の裁判例の事案のように、作業内容を確定しなければ、そもそもベンダーの仕事が完了したのかどうか、その分の報酬の合意はあるのかどうかが判断できません。また、納品されたシステムに不具合があったとしても、作業内容が具体的に決まっていなければ瑕疵担保責任や債務不履行責任が生じるかどうかも判断できません。

ソフトウェア開発の現場では、作業内容を口頭で伝えて契約書を作成しないことが非常に多いですが、上記のような紛争の原因になります。
面倒ではありますが、将来の訴訟コストを抑えるという長期的な視点を持って、作業内容に変更が生じた場合には契約書を作り直す、議事録にまとめる等の手間をかけるべきです。

３　まとめ

以上、今回は、ソフトウェア開発契約の法的性質と、作業内容の確定の重要性について解説しました。
これまで前回、前々回とソフトウェア開発契約に関する紛争について解説しましたが、今回で終了となります。

多くのソフトウェア開発の紛争が、契約内容をきちんと決めていないこと（書面に残していないこと）、ユーザーとベンダーの意思疎通の不十分さ（要求仕様を伝えない、追加報酬について作業着手前に合意しておかないなど）から発展しています。現場のスタッフ含めソフトウェア開発に携わる関係者全員が、十分に計画を練ってから作業に着手する姿勢を徹底することが後に裁判になるのを防ぐ最善の方法です。