システム開発の契約不適合責任で、納品後のバグはいつまで無償になるのか
検収から数か月後、請求データの金額が合わないと分かりました。開発会社へ連絡すると、「検収済みなので保守の有償対応です」と返ってきます。発注者は、押印した検収書を前にして手が止まります。
「契約不適合責任 システム開発」と検索する人が知りたいのは、法律用語の定義より、納品後のバグをいつまで無償で直してもらえるかだと思います。
経過した月数だけでは決まりません。納品物が合意した仕様に合っているか、責任期間を契約でどう定めたか、不具合をいつ、どの方法で通知したかを見ます。僕なら「バグだから無償」「検収したから有償」という二択を止め、契約書、仕様書、変更記録、検収結果を同じ場所へ集めます。
システム開発の契約不適合責任は、バグを全部無償にしません
契約不適合責任が問題になるのは、完成したシステムの種類や品質が、契約で合意した内容に適合しない場合です。画面が止まった事実だけでは、無償修正の対象と断定できません。期待した動作が、基本契約書、個別契約書、要件定義書、仕様書、議事録のどこに書かれているかを確認します。
たとえば、確定済みの仕様書に「管理者を含む全利用者へ多要素認証を求める」と書かれているのに、管理者だけ認証を回避できるなら、契約内容との不一致を検討する材料になります。納品後に多要素認証を追加したくなった場合は、新しい要望として扱う可能性が高くなります。外部サービスが納品後に接続方法を変えた場合も、将来の変更対応まで契約範囲へ入れたかを見なければ判断できません。
2020年4月に施行された改正民法では、従来の「瑕疵担保責任」に代わり、契約内容との適合を基準にする規定へ整理されました。法務省の債権法改正資料は施行日と改正資料を公開しています。
古い契約書に瑕疵担保責任と書かれている場合は、単語だけを読み替えず、契約締結日と更新方法も確認してください。法務省の経過措置に関する説明資料によると、施行日前に締結した契約には原則として改正前の民法が適用されます。長期契約は専門家へ見せたほうが安全です。
請負か準委任かも確認が必要です。完成を約束する請負と、業務の遂行を約束する準委任では、成果物に対する責任の置き方が同じではありません。
民法632条、643条、656条は、請負、委任、準委任の法定原則を定めています。請負と準委任を契約書で確認する観点も参考になります。
契約名だけで決めず、各作業で何を約束したかを弁護士へ確認してください。
発注者が指定したデータや指示が原因になる場合もあります。民法636条は、注文者が供した材料や指図による不適合について、請負人の担保責任を制限する原則と、請負人が不適切だと知りながら告げなかった場合の例外を定めています。開発者一人の技量へ原因を押し込まず、誰が仕様を決め、危険をいつ共有したかまで記録で確かめます。
システム開発の契約不適合責任は、検収日だけで期限を決めません
「民法では1年」とだけ覚えると危険です。請負について定める民法637条は、注文者が不適合を知った時から1年以内に請負人へ通知しない場合、追完、報酬減額、損害賠償、解除を求められなくなる原則を置いています。
1年は、発見した不適合を知らせる期間です。納品後1年間なら全バグを無条件で直してもらえる、という意味ではありません。
同条には、引渡し時に請負人が不適合を知っていた場合や、重大な過失で知らなかった場合の例外もあります。別に民法166条の消滅時効があり、権利を行使できると知った時から5年、権利を行使できる時から10年という原則も関係します。どの起算点と請求が個別案件へ当てはまるかは、契約書と事実経過を専門家へ渡して判断してもらってください。
実務では、契約条項が法定の原則と異なる責任期間を置く場合があります。IPAの情報システム・モデル取引・契約書の見直し資料も、期間を「検収完了時から○か月／○年」と空欄にし、具体的な長さを当事者の対話へ委ねています。公的なモデルにも一律の月数がないため、「何か月なら業界標準」と数字だけで決めるのは難しいです。
期間を交渉するときは、システムが通る業務周期を見ます。日々の受注だけでなく、月末請求、年度更新、繁忙期の負荷など、検収テストでは再現しにくい処理がいつ動くかを一覧にします。期間の長さだけでなく、隠れた不具合、故意や重大な過失、通知方法を期間制限の対象からどう扱うかも条文で確認します。
システム開発では、契約不適合責任と保守契約を分けます
契約不適合への対応と、納品後の保守は役割が違います。前者は納品時点の成果物が合意内容へ適合していたかを扱います。後者は監視、問い合わせ対応、障害の一次調査、外部サービスの変更、セキュリティ更新、追加開発など、運用を続ける仕事を扱います。
保守契約を結んでいるから、開発時から存在した仕様不一致まで必ず有償になるわけではありません。保守契約がないから、開発会社が将来の環境変化へ無期限に対応するわけでもありません。基本契約の契約不適合条項と、保守契約の対象業務を横に並べます。
「無償修正」に含む作業も分解します。原因調査、プログラム修正、テスト、公開作業、壊れたデータの補正、利用者への連絡は別の作業です。
修補の対象になり得る場合でも、データ復旧や事業上の損失まで同じ扱いになるとは限りません。損害賠償の上限や対象範囲を含め、個別条項を弁護士へ確認してください。
保守の窓口には、受付時間、初回回答の目安、緊急度の決め方、回避策を出す期限、恒久修正の予定を記載します。「翌営業日までに回答」と「翌営業日までに修正完了」は別の約束です。発注時に二つを混ぜると、障害発生後に期待だけがずれます。
システム開発のバグは、仕様書と検収記録で範囲を分けます
最初に確認する資料は、契約書の責任期間だけではありません。個別契約書の成果物一覧、要件定義書、画面仕様、非機能要件、受入テスト項目、検収書、変更依頼の履歴を開きます。メールやチャットで仕様を変えたなら、決定日と承認者も拾います。
不具合の期待動作を示す文章が見つかったら、実際の入力と出力を並べます。文章が見つからない場合は、開発会社のミスと決めつけず、提案書や会議記録まで戻ります。仕様が曖昧なまま両社が異なる前提で作業した可能性もあります。
検収テストの合格は重要な記録ですが、検収時に発見できなかった不一致が消えるとは限りません。一方で、検収後の設定変更、発注者が渡した誤データ、利用者の権限変更、外部APIの更新が原因なら、納品時点の不一致とは分けて調べます。発注者が検収条件を決める時期でも書いた通り、開発方法の名前より、受入条件と変更方法を文章にする作業が効きます。
原因調査の担当と費用も先に決めます。調査の結果が契約不適合なら開発会社が調査費を負担し、環境変更や追加要望なら発注者が負担するなど、調査前に分岐を書きます。結論が出る前から無償か有償かで対立するより、ログを採る人、回答期限、サービスを止める権限を決めるほうが復旧を早めやすいです。
不具合を見つけた日に、通知と証拠保全を始めます
不具合を見つけても、原因の特定を待ってはいけません。民法上の「通知」を満たす内容や方法は個別に判断されますが、少なくとも契約で指定された窓口へ、発見した不一致を文章で伝えます。電話だけで終えず、送信日時と相手の受領を確認できる形を残します。
発見日に残したい内容は五つあります。
- 発生日時、利用者、端末、画面URL、操作順を記録します。
- 入力値、実際の出力、仕様上期待する出力を並べます。
- 画面の画像、エラー番号、監視ログ、対象データの識別子を保存します。
- 直前の公開作業、設定変更、外部サービスの更新を時系列へ置きます。
- 止まった業務、影響を受けた件数、回避策の有無を確認します。
開発会社への連絡には、契約不適合に当たる可能性を確認したい旨、参照する仕様書の箇所、調査回答を求める日を入れます。個人情報や秘密鍵はメールへ添付せず、安全な共有先を指定します。修正を急ぐ場合も、証拠を消す上書きやデータ更新を避け、退避した環境で再現できる状態を残します。
開発会社が調査を拒む、通知を受け取らない、契約終了を求める段階まで進んだ場合は、法的な通知を弁護士へ相談しながら、技術資料と管理アカウントの確保も始めます。開発会社を変更する前の棚卸しに、契約書、ソースコード、クラウド権限、復旧手順を確認する順番を書きました。
明日は、基本契約書、個別契約書、仕様書、検収結果、保守契約を一つの画面へ並べてください。責任期間の起算日、通知方法、期待動作の記載箇所、保守の対象外業務へ印を付けます。不具合が起きているなら、原因確定を待たず、観測した事実と仕様書の箇所を指定窓口へ送ります。
無償か有償かを決める出発点は、「バグ」という呼び名ではありません。合意した動作と実際の動作を比べ、期限内に記録を添えて通知できるかです。
次に読む