システム開発を外部に発注する際、多くの現場で発生しやすいのが検収段階でのトラブルである。「納品されたものが仕様と違う」「検収基準があいまいで合格・不合格の判断がつかない」「追加開発の費用負担でもめる」といった問題は、契約締結時に検収に関する条項を十分に詰めていないことが原因になっている場合が多い。本記事では、ソフトウェア開発の検収でトラブルが起きやすいポイントと、契約書で事前に手当てすべき条項を整理する。
準委任契約と請負契約の違いを理解する
ソフトウェア開発の契約形態を検討する際、まず整理しておきたいのが準委任契約と請負契約の違いである。
請負契約は、受注者が「仕事の完成」を約束し、発注者がその結果に対して報酬を支払う契約である(民法第632条)。成果物が完成しなければ、原則として報酬を請求できない。また、完成した成果物が契約内容に適合しない場合、発注者は契約不適合責任を追及できる。
これに対し準委任契約は、受注者が一定の事務処理(善良な管理者の注意をもって業務を遂行すること)を約束するものであり、仕事の完成そのものは契約の要素ではない(民法第656条、第643条)。成果物の完成義務がないため、契約不適合責任も原則として問題にならない。
| 項目 | 請負契約 | 準委任契約 |
|---|---|---|
| 義務の内容 | 仕事の完成 | 善管注意義務をもった業務遂行 |
| 報酬発生の要件 | 原則として完成が必要 | 業務の遂行自体(履行割合型)または成果への対価(成果完成型) |
| 契約不適合責任 | 発生し得る | 原則として想定されていない |
| 向いている開発形態 | 要件が明確なウォーターフォール型開発 | 要件が流動的なアジャイル開発、保守・運用業務 |
ウォーターフォール型の開発で要件定義書・仕様書が確定している場合は請負契約が選ばれることが多く、アジャイル開発のように要件が開発の進行に応じて変化する場合は準委任契約が選ばれる傾向がある。ただし、実際の契約では、工程ごとに契約形態を使い分ける(要件定義・基本設計は準委任、詳細設計以降は請負とする等)ケースも見られる。契約書のタイトルだけでなく、条項の内容が実態に即しているかを確認することが重要である。
検収プロセスの設計で押さえるべきポイント
検収基準の明確化
検収トラブルの多くは、「何をもって検収合格とするか」の基準が曖昧なまま契約を締結していることに起因する。要件定義書や仕様書で機能要件を具体的に記載し、検収時にはその仕様書に基づいてチェックリスト形式で確認する運用にしておくと、合否判断の主観的な余地を減らしやすい。
検収基準を定める際は、次のような観点を具体化しておくとよい。
- 機能要件を満たしているか(画面遷移、入力チェック、出力結果等)
- 非機能要件(性能、セキュリティ、可用性等)の基準値
- テスト仕様書・テストケースに基づく検証結果
- 既知の不具合(納品時点で残存する軽微な不具合)の扱い
検収期間とみなし検収条項
検収には一定の期間を要するため、契約書で検収期間(納品後○営業日以内など)を定めておくことが一般的である。あわせて、検収期間内に発注者から合否の通知がない場合、検収に合格したものとみなす「みなし検収条項」を設けるかどうかも検討したい。
みなし検収条項がないと、発注者が検収作業を放置した場合、いつまでも検収が完了せず、受注者が報酬を請求できない状態が続いてしまう可能性がある。一方で、発注者側から見ると、みなし検収条項があることで、十分な検証時間を確保できないまま検収完了とみなされてしまうリスクもある。双方の実務上の負担を踏まえたうえで、検収期間の長さとみなし検収の要否をバランスよく設計することが望ましい。
検収不合格時の対応フロー
検収の結果、不合格と判断した場合の対応フロー(不合格の理由の通知方法、修正対応の期限、再検収の手続)を契約書に定めておくと、不合格通知後の手戻りがスムーズになりやすい。定めがないと、不合格の理由をめぐって発注者・受注者間で見解の相違が生じ、対応が長期化することがある。
契約不適合責任の実務上の注意点
2020年の民法改正により、従来の「瑕疵担保責任」は「契約不適合責任」に改称され、その内容も整理された。契約不適合責任のもとでは、納品された成果物が契約内容(種類、品質、数量等)に適合しない場合、発注者は次のような請求ができる。
- 追完請求(修補、代替物の引渡し等)
- 代金減額請求(追完がされない場合等)
- 損害賠償請求
- 契約の解除
契約不適合責任を追及するためには、発注者が不適合を知った時から原則として1年以内にその旨を受注者に通知する必要があるとされている(民法第637条)。この通知期間は契約書で伸長・短縮することも可能であるため、システムの特性(長期間の運用を前提とするシステムかどうか等)に応じて、通知期間の設計を検討することが望ましい。
なお、検収に合格したからといって、契約不適合責任がすべて免除されるわけではない。検収時点では発見できなかった潜在的な不具合について、契約不適合責任を追及できる余地が残る点にも留意が必要である。
アジャイル開発特有の検収課題
アジャイル開発では、要件が開発の進行とともに変化することを前提としているため、ウォーターフォール型開発のような「最終的な完成」を検収の対象とする発想がなじみにくい。この特性が、契約書上「検収」という概念をどう扱うかという課題を生む。
アジャイル開発の契約で実務上の工夫として挙げられるのは、次のような対応である。
- スプリント(イテレーション)ごとに受入基準(Definition of Done等)を定め、各スプリントの成果物についてスプリントレビューで確認する
- 全体の「完成」を定義するのではなく、各スプリントの成果の積み重ねとして進捗を管理する
- 準委任契約(履行割合型または成果完成型)を採用し、仕事の完成義務を前提としない契約構成にする
アジャイル開発を採用する場合でも、発注者側が「最終的に一定の機能を備えたシステムが完成する」ことを期待しているケースは多く、その期待値と契約形態(完成義務を負わない準委任契約)にギャップが生じやすい。契約締結時に、開発手法の特性について発注者・受注者双方が十分に認識をすり合わせておくことが望ましい。
よくある検収トラブルのパターン
- 仕様書の記載が曖昧で、発注者と受注者で「完成」の認識が食い違っている
- 検収基準が主観的な表現(「使いやすいこと」等)にとどまっており、客観的な合否判断ができない
- 検収期限を過ぎても発注者から連絡がなく、みなし検収条項もないため、報酬の支払いが宙に浮いている
- 開発途中で発生した追加要望(スコープ変更)について、追加費用や納期への影響を契約書に定めておらず、無償対応を求められる
- 検収後に発覚した不具合について、契約不適合責任の通知期間を過ぎてしまい、責任追及が難しくなる
こうしたトラブルを避けるためには、契約締結段階で仕様書・検収基準・スコープ変更時の手続を具体的に定めておくことが重要である。独立行政法人情報処理推進機構(IPA)が公表している「情報システム・モデル取引・契約書」などの資料も、契約書の条項を検討する際の一般的な参考として活用されることがある。
よくある質問(FAQ)
Q1. 検収期間を過ぎても発注者から連絡がない場合、報酬を請求できますか。
契約書にみなし検収条項(検収期間内に合否の通知がない場合、検収に合格したものとみなす旨の条項)があれば、その条項に基づいて検収完了として扱われ、報酬請求の根拠になり得る。みなし検収条項がない場合、検収完了の有無について発注者との協議や、契約書の他の条項に基づく主張が必要になることがある。契約締結時にみなし検収条項の要否を検討しておくことが望ましい。
Q2. アジャイル開発では、検収という概念自体が不要になりますか。
アジャイル開発では、最終的な「完成」を検収するというウォーターフォール型の発想がそのまま当てはまりにくい。ただし、各スプリントの成果物について受入基準を設け、発注者が内容を確認するプロセス自体は重要である。契約書上「検収」という用語を使うかどうかにかかわらず、成果物の確認プロセスと合否の基準を明確にしておくことが望ましい。
Q3. 検収に合格した後で不具合が見つかった場合、もう責任を追及できませんか。
検収に合格したことが、直ちにすべての契約不適合責任を免除するとは限らないと考えられている。契約不適合責任を追及するには、不適合を知った時から原則として1年以内に受注者へ通知する必要があるとされている(民法第637条)。ただし、この期間は契約書で調整されている場合があるため、契約書の記載内容を確認したうえで、対応方法について専門家に相談することが望ましい。
まとめ
ソフトウェア開発の検収トラブルを防ぐためには、契約締結段階での準備が重要である。
- 請負契約と準委任契約では、完成義務や契約不適合責任の有無が異なるため、開発形態に応じた契約類型を選択する
- 検収基準は客観的な仕様書・チェックリストに基づいて設計し、主観的な表現に頼らないようにする
- 検収期間とみなし検収条項の要否を検討し、検収の長期化を防ぐ
- 契約不適合責任の通知期間(原則1年、民法第637条)を踏まえ、契約書で調整の要否を検討する
- アジャイル開発では、スプリントごとの受入基準を明確にし、発注者・受注者間で「完成」概念のギャップを埋めておく
契約書を整備する際は、ソフトウェア開発基本契約書テンプレート、受入検査基準合意書テンプレート、アジャイル開発モデル契約書テンプレートも参考になる。
本記事は一般的な情報提供を目的として作成されたものであり、個別・具体的な法律相談に代わるものではありません。本記事の内容は執筆・更新時点の法令・裁判例等に基づいており、その後の法改正等により内容が現状と異なる場合があります。本記事の内容に基づいて行った行為の結果について、株式会社リーガリスト(以下「当社」)および監修者は一切の責任を負いかねます。個別の事案については、必ず弁護士等の専門家にご相談ください。
[要確認事項] - 民法第632条、第637条、第643条、第656条の条文内容および解説の正確性について要確認。 - IPA「情報システム・モデル取引・契約書」への言及内容が最新版の公表資料と整合しているか公開前に確認する必要がある。