システム開発における契約書の記載事項と注意点を解説
全国20拠点以上！安心の全国対応
システム開発の受託案件では、発注側の企業と受託側のベンダーの間で仕様変更による追加費用の負担等を巡り、トラブルが生じることは少なくありません。
トラブルが発生した際に重要な証拠となるのが契約書ですが、スケジュールがタイトな案件も多く、必要な規定に抜け漏れがある、契約書と実際のプロジェクトの内容に乖離がある等、いざという時に契約書が機能しないケースも散見されます。
そこで今回は、システム開発における契約書の役割、契約書に不備がある場合のリスク、契約書に記載すべき主な項目と注意点、システム開発の契約におけるトラブル回避のポイントなどについて解説します。
システム開発における契約書の役割
システム開発を受託した際に顧客と契約書を交わす必要性について漠然と理解しているものの、本当に必要なのか疑問に思われている方もいらっしゃるかと思います。まずはシステム開発において契約書が果たす役割について説明します。
1．円滑なプロジェクト遂行のためのルールの制定
システム開発における契約書の重要な役割の一つは、プロジェクトを円滑に進めるためのルールを制定することです。システム開発は形のある物の売買等とは違い、最終的に完成するシステムの全体像を明確にイメージするのが難しいという特徴があります。そのため、発注側の企業と受託側のベンダーの間で認識のズレが生じることも少なくありません。また、プロジェクトの途中で仕様変更が生じることも多く、当初の計画通りに進まないことが多いという特徴もあります。特に長期に渡るプロジェクトの場合、クライアントの経営方針の変更、組織変更や担当者の入れ替わり等による影響を受けることが想定されます。また、OSのアップデートやセキュリティパッチの適用等により動作環境が変わる可能性もあります。
そのようなシステム開発の特徴を踏まえて、将来、想定される変更が生じた際にどのように対処するのかを予め決めておき、関係者全員が共通認識を持てるようにすることは非常に重要なのです。
2． 損害賠償責任等のリスクの軽減
受託側の法的リスクを軽減することも、システム開発における契約書の重要な役割の一つです。民法の規定は以下の2種類に大別されます。
- 強行法規：当事者の意思に関わらず強制的に適用される規定
- 任意規定：当事者間の合意がある場合、合意の方が優先される規定
民法には契約自由の原則という考え方を基本原則としており、任意規定については当事者間で締結する合意により、法律で定められている事項を自由に変更することが可能です。
請負型の業務委託契約の場合、2020年4月に施行された改正民法（以下「改正民法」といいます。）で瑕疵担保責任が契約不適合責任に変わったことにより、システム開発を受託するベンダーが負う責任が従来と比べて重くなりました。瑕疵担保責任の期限は納品物の引き渡し時から1年以内でしたが、契約不適合責任は契約不適合の事実を知った時から1年以内となります（改正民法第637条1項）。システム納品から2年後に発注側が契約不適合の事実に気づいた場合、その時点から1年以内、つまり納品から3年後も責任を負うことになるのです。
民法の契約不適合責任は任意規定ですので、契約書の規定により、契約不適合責任の期限の起算点を「契約不適合の事実を知った時」ではなく「検収完了時点」あるいは「システム稼働日」に変更しておけば、会社が負う責任を軽減することが可能です。このように契約書には、法的リスクを軽減して自社の利益を守るという重要な役割があるのです。
3．訴訟等に発展した場合の根拠としての役割
契約書には、訴訟等に発展した場合に証拠として機能するという重要な役割もあります。システムの受託開発において重大なトラブルが発生した際に発注側と受注側の話し合いによって解決できず、訴訟等に発展するケースは珍しくありません。最悪のシナリオを想定して契約書を作成しておくことで、裁判所に対して双方が合意していた内容を客観的に示すことが可能になります。
訴訟等に発展するケースとして特に多いのは納期遅延や仕様変更に伴う追加作業に対する報酬の支払いを巡るトラブルです。具体的なトラブルを想定して、契約書に対処法や責任の所在を明確に規定しておくことが、トラブルの早期解決や予防につながります。
契約書を締結しない・不備がある場合のリスク
「契約書の作成に時間や労力を費やすよりも、顧客の要望に沿った設計や開発に専念すべきではないか」「スケジュールがタイトな場合、契約書は後回しでもいいのではないか」などと思われる方もいらっしゃるかと思います。たしかに顧客の要望に沿うシステム開発は最優先事項ですが、ビジネスを円滑に進めるためには契約書の作成は必要不可欠です。契約書を締結しないままシステム開発に着手する場合のリスクや契約書の内容に不備がある場合のリスクについて説明します。
1．契約書を締結しない場合のリスク
IT業界では、契約書を締結しないまま発注書等のやり取りだけで開発に着手するケースは少なくないようです。しかし、契約書を締結する前に設計や開発作業を進めるのは非常に危険です。過去の裁判では、設計や開発作業を開始した後にプロジェクトが頓挫したケースで、契約書が締結されていなかったことを理由に契約は成立していなかったと判断され、受託側の損害賠償請求が認められなかった例があります。
法律上、口約束でも契約は成立しますが、企業間の取引の場合は契約書が締結されて初めて当事者間で合意されたと判断されるのが通常です。裁判では、口約束のみで契約が成立したと認められる可能性は低いという点はしっかり認識しておきましょう。相手が付き合いの長い取引先だったとしても、開発予定のシステムを巡ってトラブルが発生する可能性はゼロではありません。会社間の信頼関係を過信せずに、着手前に必ず契約書を締結するようにしましょう。
2．内容に不備がある場合のリスク
契約書を締結していても、その内容に不備があるとリスクを回避できない可能性があります。例えば、ネット上で「システム開発 契約書 雛形」等のキーワードで検索して見つけた契約書をほぼそのままの状態で流用していた場合、重要な規定が抜けていて、実際にトラブルが発生した際に全く機能しない可能性もあります。
また、受託側の企業が自社のリスクを回避しようとして契約書に自社が著しく有利になるような規定を盛り込んでいた場合、裁判等で争われた際に公序良俗違反とみなされて規定自体が無効と判断される可能性があるため注意が必要です。
システム開発における契約の種類
システム開発を受託する際に用いられる契約には、主に請負契約と準委任契約の２つの種類があります。請負契約と準委任契約の違いや、最近の主流となっている多段階契約について説明します。
1．請負契約
請負契約は、特定の仕事を受託した側が仕事の完成を約束し、発注側が仕事の結果に対する報酬の支払いを約束する契約です。受託側は仕事を完成させる義務を負い、原則として仕事が完成するまでは発注側に対して報酬を請求することができません（民法第632条）。システム開発の場合、完成したプログラム等の成果物を納品し、発注側の検収を経て、仕事が完成したと認められます。プログラム本体の他、基本設計書、詳細設計書、テスト結果報告書、操作マニュアル等のドキュメント類が成果物として指定される場合もあります。
請負契約の場合、受注側は発注側に対して契約不適合責任を負います。契約不適合責任は、2020年4月に施行された改正民法によって瑕疵担保責任から改定された概念で、成果物の品質等が契約内容に適合しないことを意味します。つまり、請負契約を締結すると、受託側は単純に成果物を納品するだけではなく、成果物の品質が契約内容に適合していることを保証しなければならないことになります。
2．準委任契約
準委任契約は、特定の業務を委任された側が業務を遂行し、発注側が業務に対する報酬の支払いを約束する契約です。以前はシステム開発を受託する際に用いられるのは請負契約が主流でしたが、最近は準委任契約が用いられるケースも増えています。2020年の民法改正によって、準委任契約においても仕事の成果（物）に対して報酬を支払うことを約した場合の規定が設けられました（改正民法第648条の2）。
準委任契約と請負契約の主な違いを表にまとめてみました。
| 請負契約 | 準委任契約 | |
| 報酬支払いの対象 | 成果物 | 作業または成果（物） （契約内容による） |
| 受託側が負う義務 | 契約不適合責任 | 善管注意義務 |
| 報酬支払いのタイミング | 仕事の目的物の引渡しと同時（多くは検収完了時となるが、契約による） | 作業完了時または成果（物）の引渡しと同時 |
準委任契約の報酬の定め方には、以下の２つの種類があります。
- 履行型：提供された労務に対して作業時間等をもとに報酬を支払う契約
- 成果型：作業の結果として達成された成果に対して報酬を支払う契約
成果引渡型の場合、作業自体に対して報酬が支払われるわけではなく、作業の成果と引き換えに報酬が支払われます（改正民法第648条の2）。システム開発における要件定義や設計作業等の受託案件のほとんどは成果型に該当します。そのため、受託側は成果物を引き渡すことが求められ、契約で定められた成果の引渡しができない場合は債務不履行責任を負うことになります。
また、準委任契約の場合、受託側は発注側に対して、善管注意義務を負います（民法第644条）。善管注意義務とは、業務を委任された人の職業や社会的地位などから考えて通常期待される注意義務をいいます。システム開発案件の場合、プロのシステムエンジニア・プログラマーとして求められるレベルのスキルや専門知識をもって業務を遂行する注意義務を負うことになります。善管注意義務を怠った場合、損害賠償を請求される可能性もあります。つまり、準委任契約の場合でも、受託側が負う実質的な責任の重さが請負契約の場合よりも軽いということではないのです。
3．多段階契約と一括契約
ウォーターフォール型のシステム開発は、要件定義、設計、プログラミング、テストというフェーズを経て完了します。これら全てのフェーズを一括で契約する場合もありますが、要件定義を行わないとシステムの全体像を把握することは難しいため、要件定義前に金額を確定することはリスクが伴います。特に稼働人数が数十人以上の規模が大きい開発案件の場合はリスクが大きくなります。そのため、経済産業省はプロジェクト全体に関する重要事項を規定した基本契約書を締結した上で、フェーズごとに個別契約を締結する多段階契約を用いることを推奨しています。
多段階契約の場合、各フェーズの性質を考慮して契約類型を選択することが可能です。基本的には、着手前に成果物が具体的に特定できる場合は請負契約、特定できない場合は準委任契約が適しているといわれています。また、要件定義、設計、テスト等で、クライアントのシステム部門とベンダーが協働で作業を進める場合は準委任契約を用いることが多いようです。
契約書に記載すべき主な項目
契約書にどのような項目を規定するべきなのか具体的に知りたいという方もいらっしゃると思いますので、記載項目について説明します。
1．経済産業省が公表しているモデル契約書を参考に
契約書に記載する項目や規定の内容を決める際は、経済産業省が公表している『情報システム・モデル取引・契約書』（モデル契約書）を参考にしながら、実際のプロジェクトの内容に即した規定を盛り込むとよいでしょう。モデル契約書は、経済産業省が、情報システムの信頼性向上と円滑な取引を主な目的として、システムの受託開発案件における理想的かつ実践的なモデルとなる契約書を提示したものです。2007年4月に公開された第一版は大規模案件向けでしたが、2018年には中小企業等での比較的小さい規模の案件を想定した追補版も公開されました。また、2019年12月には情報処理推進機構が改正民法に対応したモデル契約書を公開しています。
2．特に重要な項目と注意点
システム開発における契約書で特に問題になりやすい項目と注意点について説明します。
①開発・設計対象の範囲
開発・設計作業の対象となる範囲を明確に特定します。プロジェクトの途中でクライアントの都合で仕様変更が必要になった場合に、契約書に規定した範囲を超えた作業であることを認識してもらい、追加費用を請求する根拠となる大切な規定です。曖昧な表現や専門用語の使用は避け、または専門用語には説明を加えるなどして、クライアントと共通認識を持てるような客観的な表現を用いるようにしましょう。
②損害賠償の期間・上限金額
前述した通り、民法改正により瑕疵担保責任から契約不適合責任に変わり、損害賠償の期間の起算点が納品物の引き渡し時から契約不適合の事実を知った時点に変更されました。納品してから数年後に日常業務でほとんど使用しない機能のバグ（不具合）が見つかる可能性もあるため、民法の規定ではベンダー側は納品後長期間に渡って損害賠償責任を問われるリスクを負うことになります。そのようなリスクを回避するために、契約不適合責任の期限の起算点を「契約不適合の事実を知った時」ではなく「検収完了時」「システム稼働日」等、客観的に特定できる時点とし、契約書に明記することが大切です。
また、想定外の多額な損害賠償を請求されないために、損害賠償額の上限を設けることも検討しましょう。一般的には契約書に記載した当該案件の報酬金額を上限とすることが多いです。
③協力義務
要件定義はプロジェクトの成否に大きな影響を与える重要なプロセスです。要件定義では、現行の業務の流れや課題をできる限り正確に把握する必要があるため、業務を熟知しているクライアント企業の担当者の協力が不可欠です。
しかし、中には、システム開発はベンダーに丸投げで自分達は特に何もしなくていいと思っているクライアントも存在するので、契約書の中でクライアント側の協力義務について明記し、協力義務が課せられていることを認識してもらうことは非常に重要です。
④著作権
開発したシステムに関する著作権を巡り、ベンダーとクライアントとの間で揉め事になるケースもあるので、契約書内で著作権の帰属について定めておくことも大切です。汎用的に利用できるプログラムはベンダー、その他はクライアントに帰属する等、バランスを考慮して決めることが大切です。
⑤変更管理手続
システム開発の受託案件では、仕様変更による追加作業が発生することは少なくないので、仕様変更が必要になった場合の手続を契約書で明確に規定することはトラブルを防ぐために重要です。仕様変更による追加作業が生じた場合の手続や費用負担について明記しておきましょう。
システム開発の契約におけるトラブル回避のポイント
システム開発における契約を巡るトラブルを事前に回避するためには、どのような点に注意すればよいのでしょうか。トラブルを回避するためのポイントについて説明します。
1．契約書の内容を精査する
システム開発における契約を巡るトラブルを回避するためには、契約書のドラフトを用意し、その内容を十分に精査することが不可欠です。以下の３つの観点から、綿密に精査することが望ましいでしょう。
- 実態に即した内容になっているか
- 自社が負うリスクを最小限に抑えられているか
- 公平で合理的な内容になっているか
３つの観点について具体的に説明します。
①実態に即した内容になっているか
契約書の内容は、実際のプロジェクトの内容に即したものでなければ意味がありません。開発案件の難易度やクライアントのITリテラシーのレベル等も考慮し、起こり得るトラブルを想定しながら必要な事項に抜け漏れがないか丁寧に精査しましょう。
②自社が負うリスクを最小限に抑えられているか
実際にトラブルが発生した場合に、自社が負うリスクを最小限に抑えることができるかという観点も大切です。特に重要なのは、契約不適合責任を負う期間の起算点と損害賠償の上限の規定です。
③公平で合理的な内容になっているか
自社が負うリスクを最小限に抑えることは大切ですが、自社が一方的に有利な規定にすることには慎重であるべきです。例えば、予定工数を消化した時点で成果物が完成していなくても業務が完了したことになる旨を定めているケースがありますが、裁判ではこのような不合理な規定は公序良俗違反として無効と判断されることもあるので注意が必要です。裁判に発展した場合に機能する公正な規定になっているかという観点からも確認するようにしましょう。
2．契約内容を双方が理解すること
契約書の内容に抜け漏れがないよう精査しても、関係者全員が契約書の内容を理解していないと、トラブルが発生した時に「そんな話は聞いていない」などと揉めてしまう可能性があります。双方の責任者が同席した場で契約書の内容の読み合わせを行い、内容に不明点がないことを確認することが望ましいでしょう。
3．会議の内容は記録する
システム開発を巡るトラブルを回避するためには、定例ミーティングでの決定事項を議事録にまとめる等、プロジェクトの経緯を記録することが大切です。システム開発案件では、ベンダーがシステム開発のプロとして適宜クライアントの意見をヒアリングして開発作業を進行させる「プロジェクトマネジメント義務」があるとされています。（東京地判平成16年3月10日判タ1211号129頁では、ベンダーのプロジェクトマネジメント義務が認められています。）。議事録等の記録は、その義務を果たした証拠とすることができるため、非常に大切です。議事録はでミーティング終了後数日以内に作成し、クライアント側のメンバーにメール等で送信して内容に相違がないか確認してもらうことが望ましいでしょう。
4．変更管理を徹底する
契約書で変更管理手続について規定することの重要性については前述しましたが、契約書に規定しただけでは不十分です。現場の担当者間で仕様変更について口頭で指示されて、指示通りに作業を進めた結果、スケジュールに大幅な遅延が生じる可能性もあります。そのような事態を防ぐためには、変更管理手続について現場の担当者レベルまで周知徹底することが大切です。
仕様変更は納期や費用に多大な影響を及ぼすことを関係者全員が認識すること、変更が必要な際は必ず規定された手続を踏むことを徹底しましょう。
5．定例ミーティングのメンバーの検討
変更管理も大切ですが、開発後の変更を最小限に抑える努力も必要です。そのためには、要件定義や設計を綿密に行うことが求められます。
要件定義や設計には、現場の業務に精通し、実際に日々の業務の中で現行システムを使用している人物が必要です。システム管理部門の担当者だけが定例ミーティングに出席しているケースもあるようですが、その人物が現場の業務や現行システムの機能や問題点等を十分に把握しているとは限りません。業務を熟知している現場の担当者は日々の業務が忙しくて定例ミーティングに出席することが難しい場合もあるかもしれません。その場合は別途スケジュールを合わせてヒアリングを行うなど調整するとよいでしょう。
まとめ
今回は、システム開発における契約書の役割、契約書に不備がある場合のリスク、契約書に記載すべき主な項目と注意点、システム開発の契約におけるトラブル回避のポイントなどについて解説しました。
綿密に精査された契約書は、法的トラブルによる多大な損失を回避して自社の利益を守るだけではなく、クライアントと良好な信頼関係を構築するためにも重要な役割を果たします。システム開発特有の問題に適切に対処するためには、IT業界に精通した弁護士に相談してアドバイスを受けるとよいでしょう。
東京スタートアップ法律事務所では、IT業界の商慣習や法律問題に精通した弁護士が、様々な企業のニーズを丁寧にヒアリングした上で適切なサポートを提供しております。お電話やオンライン会議システムによるご相談も受け付けておりますので、契約書等に関する相談がございましたら、お気軽にご連絡いただければと思います。
