【徹底詳細解説】「システム開発に関する契約」の内容と注意すべきポイントについて

システム、ソフトウェア、アプリケーション、現代の会社で、システム開発を行わない会社はないといっても過言ではないでしょう。

しかし、「リリース日が迫っている、この金額であればそのまま決めてしまいたい!」などの気持ちから、契約書をよく精査しないまま、締結してしまっている会社も多いのではないでしょうか。

現代の会社運営に必要不可欠なシステム開発契約書について、その法的な性質、気を付けるべき条文について解説し、トラブル事例とその対処法について、全二回の記事に分けてご紹介します。

 

◆システム開発契約の種類

一概にシステム開発契約といっても、その規模は数億円単位から数百万円単位のシステムまで幅があり、また、開発対象も基幹システムなど大規模なものから、ソフトウェア、アプリケーションなどの比較的工数のかからない小規模な場合も存在します。契約書は、その実態に合わせて適切に規定する必要があります。

 

・「基本契約書+個別契約書」or「個別契約書」のみかは、案件のサイズで分かれる?

システム開発契約を締結する際に取られる契約の形態として、まずは基本的な条項について網羅的に定めたシステム開発基本契約書を締結した上で、具体的な業務内容を記載した個別契約書(見積書・注文書・注文請書の形式で締結される場合もあれば、「個別契約書」というタイトルで双方が押印する形態の場合もあります。)を締する形態で実施する場合や、業務委託契約書のような表題で具体的な業務内容を記載した個別契約書のみを締結する形態の場合があります。

実務上は、大規模なシステム開発を行うに際して①基本契約書+個別契約書によることが多く、小規模な開発の場合には②個別契約書のみという形態によることが多いです。

小規模開発であれば、最初の業務開始時点で、業務範囲が明確になっていることが多く、また期間も短いこともあり、個別契約書に具体的な業務範囲・期間を明示して一括で委託することができます。

これに対して、大規模開発の場合には、最初の業務開始段階では、以後のフェーズにおける業務の内容が確定していないことが多いため、各フェーズで区切って契約を締結する必要が生じます。その際、同一事業者に対して委託することが見込まれている場合には、①基本契約書+個別契約書という形態をとることによって、各フェーズの契約締結手続きをスムーズに行うことを目的として(毎回、全ての条項について契約交渉を行わなくて済むように)最初の段階で基本的な条項について定めた基本契約書を締結するのです。

法律上の効果は、契約書に記載された内容によりますので、記載の内容が自社にとって有利なのであれば、いずれの方法によってもかまいません。ただし、基本契約書よりも個別契約書の効力が優先すると定められているのが通常ですので、基本契約書でしっかりと交渉を行っても、個別契約書で別の定めをされていないかはしっかりと確認する必要があります。

逆に言えば、基本契約書では譲っても個別契約書で変更するチャンスが残るとも言えます。また、「一部条項の交渉が難航しており契約締結ができない」といった場合は、基本契約書においては、「別途協議の上個別契約において定めるものとする」といった規定にし、協議の機会を残しつつ、個別契約の交渉に譲って基本契約の締結を急ぐという方法も考えられるところです。

 

・準委任契約なのか請負契約なのか

システム開発契約を締結するにあたって、請負型・委任型という言葉を聞いた方も多いのではないでしょうか。この請負型・委任型とは、システム開発契約の法的な性質を指したものです。システム開発契約の法的性質は、準委任契約か請負契約に当たるといわれており、両契約には法律上、以下のような違いがあります。

save image

 

請負契約とされた場合には、受託者側は、ある仕事の完成義務を負うことになり、準委任契約の場合にはある事務を遂行さえしていれば足り、その時点で報酬請求権が発生することになります。また、瑕疵担保責任については、基本的に、請負契約の場合に問うことができます(準委任型の契約においても、契約上の責任として規定が置かれることはあります)。

このようにみると、請負契約のほうが委託者側に有利で、準委任契約のほうが受託者側に有利、というようにも見えますが、準委任契約であっても善管注意義務に基づく業務遂行責任は負いますし、債務不履行責任を問うことは可能です。

準委任なのか請負なのかという形式的な議論に終始することなく、業務の実態が、仕事の完成=成果物の完成を目的としているのか、それとも事務の処理=開発作業を行って貰うことを目的としているのか、報酬の支払形態はいかなるものなのか、その取引の実態に即して、適切に判断する必要があります。

 

・契約書に法的性質を記載するだけでは不十分!

ここで注意すべき点があります。それは、契約書に「準委任」型であることを明記すればそれで足りるというわけではないということです。

以下のような事例を考えてみます。

A社(委託者)はB社(受託者)に対し、システム開発を依頼した。両社は開発にあたって、「準委任契約である」と規定が置かれた契約書を巻いており、定期的に一定の報酬金額を支払う契約となっていた。

B社は納品をしたが、A社は「納品したシステムはまったく完成していない」と主張し始め、両社において、システムの完成度をめぐってトラブルが生じた。

その後、突然、A社から「本契約を解除する。本契約は実質的に請負契約であるから、仕事の完成が受託者の義務である。その義務を履行しなかったのだから、報酬を支払う義務は当社にはないため、事前に支払った代金を返還しろ。」という通知が到達した。

B社は、「契約書に準委任契約と書いてある」と反論した。

 

B社の主張は常に正しいということになるのでしょうか。

上記の事例が裁判に発展したとして考えてみます。裁判になると、契約書上に「準委任」と記載していても、当事者の合理的な意思を解釈して実質的に請負を内容とするものと認められれば、請負契約と解釈されてしまうことがあります。

では、どのような要素が考慮されて、そのような解釈がされるのでしょうか。

おおむねの指針となるのは、①システムの完成までの工程表が作成されていたかどうか、②完成させるシステムの具体的な内容が契約締結時点において確定していたかどうか、③報酬の支払時期がどうなっていたか、④契約書に検収の規定や瑕疵担保責任の規定、成果物の品質を保証する旨の規定が置かれていたかどうかとされております。

上のように実態に即して判断されるものの、④にあるように、やはり契約書の規定にどのような規定が置かれているかということは非常に重要な要素となります。

したがって、契約書の性質をただ記載するのではなく、その性質に即した規定を適切に置くことが重要となるのです。

なお、この法的性質は、一つの契約であっても、フェーズに応じて段階的に決まる場合もあります。一つのプロジェクト中でも、仕様の具体的内容を決めるまでのフェーズが準委任契約、仕様が確定し当事者がシステムの具体的内容を念頭に開発を行うフェーズが請負契約となる場合があります。請負契約なのか準委任契約なのかは流動的であるとされており、具体的な業務内容によって異なる認定がされる場合もあるのです。

 

・SES契約とは何か?

SES契約=システムエンジニアリング契約は、システムエンジニアの能力を契約の対象とする契約で、多くは準委任契約と記載されていますが、これも前述のとおり任せている業務の内容によると言わざるを得ません。あくまで、時間単価による価格算定がなされる契約にすぎないと考えるべきでしょう。

 

・契約書の記載内容が大切!

ここまで申し上げましたが、結局のところ、基本契約書+個別契約書によるのか、個別契約書によるのか、準委任契約とするのか、請負契約にするのか、という形式的な側面のみではなくその実質に踏み込んで、具体的に記載される契約書の各条項についてきちんと検討することが重要です。

ここからは、個別に注意しておくべき条文についてみていきましょう。

 

◆注意するべき条文

以下、システム開発契約書でよくみられる条項のうち、注意して読むべき条項を、その重要度が高い順に解説していきます。なお、以下の解説は主に委託者の立場で書いているものもありますが、受託者の立場で
あっても、同様に重要度が高い条項です。

・システム規模の大小/準委任・請負にかかわらず留意すべき条項

①著作権

システムの納入物に含まれるソースコードや各資料については、著作権が認められます。そして、著作権は、原則として著作者である実際に開発を行った受託者に帰属します。

また、受託者がさらに下請業者等を使っていた場合、下請業者に著作権が帰属している場合があります。著作権の譲渡をしっかりと受ける規定を置かないと、著作者から権利を主張される可能性があり、最悪事業運営に必要なシステム・アプリケーションの稼働・提供を止めなければならない事態に陥ることがあります。

このような事態に陥らないように、著作権の譲渡・使用許諾については当事者で明確に定める必要があります。そして、著作権譲渡を定める際には、著作権法第27条及び第28条の譲渡を明記しなければならないことに気を付けましょう。また、著作者人格権については譲渡できませんので、行使しない旨の条項を入れる必要があります。さらに、下請事業者を用いていた場合には、下請事業者から譲渡を受けること、下請事業者にも著作者人格権を行使させない旨の規定が必要になります。

なお、著作権の移転時期についても、当事者間でいつ時点にするのか明確に定めるべきですし、著作権譲渡の対価が委託報酬に含まれるか否かも明記するべきです。

※知的財産権についても、同様に原則として発明者たる受託者に帰属しますので、同様にその帰属関係、対価が委託報酬に含まれるかについては、契約書上明確に定めておく必要があります。

②委託業務の内容/報酬の算定方法

委託者から受託者に委託する業務の内容が明確に定められていないと、委託した事務の履行/目的物が完成したのかが不明になってしまいます。また、スコープ内外(委託業務の対象範囲内か否か)をよく確認していないと、スコープ外だったので別途見積を行います、と言われ思ってもみなかったような追加費用を負担しない限りシステムが完成しない場合があります。

システム開発業界では報酬を工数で算定することが一般的ですので、委託する業務の内容に、自社が求めている機能・要件がすべて含まれているのかをよく確認した上で、見積根拠が合理的か確認するようにしましょう。そして、これらの確認を行ったうえできちんと契約書に反映する必要があります。業務範囲が明確になるように、また、その際の報酬が明確な金額になるように記載しましょう。

③損害賠償請求

受託者側から提示されるシステム開発契約書においては、損害賠償額の上限が定められていることがほとんどです。委託者側としては、システムが完成しなかった場合のリスクを考慮して、契約書に記載された上限額でそれを補填するに足りるのか十分に検討しましょう。また、まれに「受領済みの委託料総額」を上限とするような規定が見られますが、システムの出来が悪く、委託料を支払っていない場合などには上限額が0円となってしまう可能性もありますので、十分に留意して修正を行うようにしましょう(なお、実質的に損害賠償責任を負わなくなる条項が有効か否かについては議論の余地があります)。

④再委託の可否

システム開発契約をある会社と締結する場合、委託者としては、受託者の能力を信頼して選任していることと思います。それにもかかわらず、再委託を無条件で可能とする条項が規定されていた場合、せっかく信頼した受託者の能力が発揮されないばかりか、システム開発を全く知らない第三者にゆだねてしまうことになりかねません。委託者としては、再委託の条件(事前の書面による承諾、事前の通知など)の設定や、再委託した場合の責任の所在を明確にするようにしましょう。

⑤第三者ソフトウェア/FOSSの利用

受託者において開発したものではない第三者ソフトウェア、フリーソフトウェア、またはオープンソースソフトウェアを利用する場合に、当該第三者ソフトウェアやFOSSに含まれる瑕疵やリスクに関して定める条項です。第三者ソフトウェアまたはFOSSの利用の可否判断者を委託者とし、受託者は自己の判断で利用してはならないこと、選定に際する責任の所在について明記するようにしましょう。

また、近年のソフトウェア開発において、OSSは必要不可欠なものとなっていますが、OSSのライセンス条項はOSSの種類ごとに様々な規定がなされており、それぞれについてライセンス条項を遵守する必要があります。その中には、OSSのライセンス文書を添付する、OSSに含まれている知的財産関係の情報を記載する、などの対応が容易なものから、OSSを使用して開発したプログラム全てについてソースコードを開示しなければならないというものまであります。委託者としては、相応の対価を払って開発を委託したにもか
かわらず、ソースコードを開示しなければならなくなるような事態は避けるべきです。そのようなOSSを指定して、あらかじめ使用を禁止することも検討するべきでしょう。

 

◆おわりに

いかがだったでしょうか?お悩みの問題は解決できましたか?

少しでもご参考にしていただけたら嬉しく思います。

次回は、請負契約・準委任契約の場合にそれぞれ気を付けるべき条項、及び資本金が相当額の会社が留意するべき下請法や偽装請負の問題について、そして、実際に生じたトラブル事例と行っておくべきであった対処方法や解釈の指針となった契約条項についてご紹介します。

 

この記事が気に入ったらいいね!をお願いします