システム開発契約書のリーガルチェックポイント

システムやソフトウェア、アプリの開発を委託する契約はあらゆる企業で頻繁に行われています。
システム開発には、大企業が何億円もかけて一大プロジェクトとして行うものから、中小企業がスポット的に資源を投入して完成させるものまで、規模も内容も様々です。
そこで今回は、主に中小企業間で行われるシステム開発契約書についてのリーガルチェックポイントを解説します。

1 開発対象を明確に定める

システム開発をめぐってもめごとが起こる場合、必ずといっていいほど注目されるのが、「そもそも何を作る約束だったのか」、そして「それはできているのか」ということです。
「何を作る約束だったのか」(=開発対象)を明確にし、「それができているのか」の判断基準(=納品検査基準)を明確にしておくことで、多くの紛争を防ぐことができます。

システム開発は、ざっくり以下の流れで進みます。
① 要件定義:何を実現したくて、何を作るのかを定める。

② 仕様書:そのために、具体的にどんな機能を備えるのかを定める。

③ 設計書:それをどうやって作るのかを定める。

④ 開発:それを実際に作る。プログラミング。

⑤ テスト、実装:それを実際に動かしてみる。運用。

家やビルを建てるように、①→⑤を完成まで一回で行うウォーターフォール型と、
このサイクルを小さな塊にして、何度も繰り返しながらゴールに向かうアジャイル型とがあります。

この中で大切なのは①と②で、発注者(ユーザー)と開発者(ベンダ―)の密なコミュニケーションが必要です。

まず①要件定義では、そもそも何を実現したいかを共有することから始めましょう。
案外ここが抜けていて、その結果、
いきなり「こんな感じのシステム作って」にはじまり、
「こんな感じで作りました」と納品した結果、
「いやいや全然わかってないし、使えないじゃん」となり、
「いや、聞いてませんけど。ていうか、やった分払ってください」となって、
「は?払えるわけないでしょ」といってもめることになりがちです。

“そのシステムを使って何を実現したいのか”という、本当のゴールを見える化し共有しておけば、そのような行き違いは起きませんので、ぜひ意識していただきたいです。

次に、②の仕様書でも、ユーザーは専門外だからとベンダー任せにせず、教え・教わりながらの関係のなかで、どんな機能を備え、どんな情報を得て、どんな動きにするのかを協同作業のなかで構築していくようにしましょう。
ベンダー側も、自社が想定している機能や動きを、ユーザーも当然に分かってくれるはずと早合点せず、双方で認識や想定を共有できているか確認しながら進めるようにしましょう。

このように開発対象を明確に定めておくことで、「そもそも何を作る約束だったのか」のところでもめないようにし、そのために、要件定義、仕様書、設計書をできるだけ詳細に作成するようにしましょう。
もちろん、アジャイル型はじめ、開発を進めていくなかで、仕様や機能を決めたり追加変更を行うことも多いので、その場合の新たな合意事項の書面化・記録化、追加費用の有無の取り決め方も定めておきましょう。

2 納品検査の基準を定める

これは1の開発対象とリンクするところであり、またシステム開発独特の事情もあるところです。
システム開発は、イメージをしやすくするために、建物建築に例えられることがよくあります。
何を作りたいか定める

どう作るか定める

実際に作る
という流れは、たしかに建築と同じです。
けれど、建築との大きな違いは、完成引渡し後も、引き続き作業をすることがあるということです。
建築であれば、引渡後も施工業者が作業していたとしたら、「何かやり残したことがあるんだろう」とか「不具合があって直しを入れてるんだね」と言われてしまうでしょう。

しかし、システム開発の場合は、仕様書・設計書に基づいてやるべきことは完了し実装したけれども、なお改善の余地があったり、メンテナンスしながら動かしてみるということはよくあります。軽度なバグは避けられないケースもあります。
なので熱心なベンダーであればあるほど、ユーザーが満足いくまでとことんつきあうこともあります。

そして、ある程度互いの納得がいったところで、「このあたりでいったん作業を終えましょうか。また何かあれば仰ってください」「そうですね。ありがとう」というやりとりで完了になります。

そうやって最後まで信頼関係を保ちながらゴールにたどり着ければよいのですが、これがもめてしまうと大変です。
いつまでやっても「できてないじゃないか。まだまだだ」となったり、「納品期限過ぎてるのにいつまでかかるんだ」などとなってしまうのです。

そうならないためにも、納品検査基準として、仕様書や設計書に照らし合わせてのテスト項目、テスト方法を定めておき、「約束したものができているのか」の判断基準を契約書に盛り込んでおくようにしましょう。
ただ、アジャイル型の場合は、そもそもテスト項目やテスト方法を定められないタイプなので、検査基準を明確にしておく必要の高いユーザーとの取引では、費用がかかってもウォーターフォール型を選択し、テスト項目、テスト方法を定めるのがおすすめです。
システム開発の発注に慣れていない場合は、ドキュメント中心のウォーターフォール型にしておくとトラブルリスクを下げることができるでしょう。

3 契約不適合責任(瑕疵担保責任)について定める

2020年4月から施行された改正民法では、「瑕疵」という用語がなくなり、「契約不適合」(=契約の内容に適合しないもの)という用語が用いられるようになりました。
改正のポイントは次のとおりです。
①欠陥品だとか、契約で定められた品質を満たさない「契約不適合」品の場合は、修理(履行の追完)、代金の減額、損害賠償、契約解除といったメニューが一定要件のもとで認められる。
②①の責任追及は、「注文者がその不適合を知った時から1年以内に通知」すればよい。

この民法改正について、昨今、“何だか知らないけど大変らしいぞ”と実務をあおるような記事も散見されますが、これはあくまで契約書で何も定めがない場合に適用される規定です。
ですので、契約書において自由に欠陥や不具合についての担保や保証規定を定めておくことで対処ができます。

例えば、1や2で定めた内容を満たしていないものを「契約不適合」と定義するほか、
責任を負う期間は、「知った時から」ではなく、「納品時」とか「検査合格時」から1年とか6か月などと定めることで、ベンダーが負う責任の範囲や期間を明確にしておきましょう。
また、単に責任を負う負わないだけでなく、いつまでが無償対応で、いつからが有償対応なのか、という定め方も検討するとよいでしょう。
そうすることで、双方にとって、引渡後の不具合対応でもめるリスクを減らすメリットがあります。

4 知的財産権の帰属について定める

システム開発に伴って、著作権はじめさまざまな知的財産権が生まれることがあります。
その場合に、どの範囲でどちらが権利を持つのかを定めておくようにしましょう。
ちなみに、うまく折り合いがつかない場合に、安易に共有財産してしまうことがありますが、そうすると、どんな場合でも相手の了解がないと使えないということになり、かえって使い勝手が悪い場合も出てくるので、注意しておくとよいでしょう。

以上のように、システム開発契約書で注意すべきリーガルチェックポイントを整理しました。
システム開発は、ユーザーとベンダーとが、いわば投げる方も受け取る方も声を掛け合いながらキャッチボールをし、一緒にゴールを目指すプロジェクトのようなものでもあります。
ですので、そのための明確なルールブックとなるような契約書にしておきたいです。
リーガルチェックのご依頼ご相談も受け付けていますので、その場合は下記フォームからお問い合わせください。

◎ 契約不適合責任に関する改正民法の関連条文 ◎
第三節 売買
第一款 総則
第559条(有償契約への準用)
この節の規定は、売買以外の有償契約について準用する。ただし、その有償契約の性質がこれを許さないときは、この限りでない。

第二款 売買の効力
第562条(買主の追完請求権)
1 引き渡された目的物が種類、品質又は数量に関して契約の内容に適合しないものであるときは、買主は、売主に対し、目的物の修補、代替物の引渡し又は不足分の引渡しによる履行の追完を請求することができる。ただし、売主は、買主に不相当な負担を課するものでないときは、買主が請求した方法と異なる方法による履行の追完をすることができる。
2 前項の不適合が買主の責めに帰すべき事由によるものであるときは、買主は、同項の規定による履行の追完の請求をすることができない。

第563条(買主の代金減額請求権)
1 前条第一項本文に規定する場合において、買主が相当の期間を定めて履行の追完の催告をし、その期間内に履行の追完がないときは、買主は、その不適合の程度に応じて代金の減額を請求することができる。
2 前項の規定にかかわらず、次に掲げる場合には、買主は、同項の催告をすることなく、直ちに代金の減額を請求することができる。
一 履行の追完が不能であるとき。
二 売主が履行の追完を拒絶する意思を明確に表示したとき。
三 契約の性質又は当事者の意思表示により、特定の日時又は一定の期間内に履行をしなければ契約をした目的を達することができない場合において、売主が履行の追完をしないでその時期を経過したとき。
四 前三号に掲げる場合のほか、買主が前項の催告をしても履行の追完を受ける見込みがないことが明らかであるとき。
3 第一項の不適合が買主の責めに帰すべき事由によるものであるときは、買主は、前二項の規定による代金の減額の請求をすることができない。

第564条(買主の損害賠償請求及び解除権の行使)
前二条の規定は、第四百十五条の規定による損害賠償の請求並びに第五百四十一条及び第五百四十二条の規定による解除権の行使を妨げない。

第九節 請負
第634条(注文者が受ける利益の割合に応じた報酬)
次に掲げる場合において、請負人が既にした仕事の結果のうち可分な部分の給付によって注文者が利益を受けるときは、その部分を仕事の完成とみなす。この場合において、請負人は、注文者が受ける利益の割合に応じて報酬を請求することができる。
一 注文者の責めに帰することができない事由によって仕事を完成することができなくなったとき。
二 請負が仕事の完成前に解除されたとき。

第635条 削除

第636条(請負人の担保責任の制限)
請負人が種類又は品質に関して契約の内容に適合しない仕事の目的物を注文者に引き渡したとき(その引渡しを要しない場合にあっては、仕事が終了した時に仕事の目的物が種類又は品質に関して契約の内容に適合しないとき)は、注文者は、注文者の供した材料の性質又は注文者の与えた指図によって生じた不適合を理由として、履行の追完の請求、報酬の減額の請求、損害賠償の請求及び契約の解除をすることができない。ただし、請負人がその材料又は指図が不適当であることを知りながら告げなかったときは、この限りでない。

第637条(目的物の種類又は品質に関する担保責任の期間の制限)
1 前条本文に規定する場合において、注文者がその不適合を知った時から一年以内にその旨を請負人に通知しないときは、注文者は、その不適合を理由として、履行の追完の請求、報酬の減額の請求、損害賠償の請求及び契約の解除をすることができない。
2 前項の規定は、仕事の目的物を注文者に引き渡した時(その引渡しを要しない場合にあっては、仕事が終了した時)において、請負人が同項の不適合を知り、又は重大な過失によって知らなかったときは、適用しない。

 

 

リーガルチェック、契約書作成のご相談・お申込みフォーム

リーガルチェック、契約書作成に関するご相談・お申込みフォームです。
ご送信いただきましたら、一両日中にメールにてご返信いたします。
会社名等をマスキングのうえ契約書を添付頂けましたら、お見積りもご回答いたします。

※添付可能な拡張子はjpg、jpeg、png、gif、pdf、doc、docx、ppt、pptxのいずれかで、ファイルサイズは1MB以下です。
※ご送信後二日を過ぎても返信がない場合は、何らかのエラーが考えられますので、改めてお問合せをお願いいたします。

リーガルチェック契約書作成
Zoom面談対面いずれも可

経営者に、前に進む力を。
弁護士 波戸岡光太
東京都港区赤坂3-9-18赤坂見附KITAYAMAビル3階
TEL 03-5570-5671 FAX 03-5570-5674