【発注者向け】リリース後にバグを発見！——全部直してもらえるとは限らない｜開発会社の責任範囲はどうやって決まる？ 

「システムをリリースした途端にバグが見つかりました。開発会社に直してもらえますよね？」

システム開発の発注者の方からよくあるご質問です。「はい、もちろんです」とお答えしたいところですが、実はそれほど簡単ではありません。ご質問の答えは「契約書の内容によって異なります」。
バグ対応の責任範囲は、契約書にどう書かれているか次第で大きく変わってしまうんです。

今回は、この問題についてわかりやすく解説します。

バグにも「種類」がある

バグと一口に言っても、原因によって責任の所在が変わります。
パターン分けしてみると、主に以下のようなケースがあります。

①開発会社の開発ミスによるバグ
仕様書通りに作ったはずなのに動かない、というケースです。開発会社側に修正責任があります。

②仕様書自体の誤りや曖昧さによるバグ
発注者・受注者双方の認識のズレが原因になるケースです。どちらの責任かの判断は難しいです。そのため、仕様書の内容が重要になります。

③リリース後の環境変化による不具合
OSのアップデートや外部サービスの仕様変更など、開発当時は問題なかったものが後から不具合になってしまうケースです。開発会社が責任を負わないことが多く、改修対応のためには新たな保守作業が必要になります。

④発注者作業による不具合
リリース後に発注者側で機能の追加や変更を行った結果として不具合が生じるケースです。この場合、原則として開発会社の保証対象外です。

以上のように、起こりうる様々なケースについて「誰が・どんなバグを・いつまで無償で(またはいつから有償で)直すか」を契約書に明記しておくことが、トラブル防止の第一歩です。

納品物に不具合がある場合、契約不適合責任を問うこともできますが「契約書に記載されているかどうか」で各種請求までのスムーズさが変わります。

契約不適合責任とは？（旧：瑕疵担保責任）
2020年の民法改正により「瑕疵担保責任」から「契約不適合責任」に名称が変わりました。納品物が契約内容（仕様書）と適合していない場合の、受注者の責任のこと。発注者は修補・代金減額・損害賠償・契約解除などを請求できます。

「どんなバグが保証対象となるか」を契約前に確認する

「バグが見つかったら全部直してほしい」という発注者と、「仕上がりが仕様書通りならば対応しない」という受注者の間で、認識のズレが生じることはよくあります。

発注者として契約前に確認しておきたいのが、「保証対象となるバグの定義が契約書に明記されているか」という点です。「仕様書に記載された機能の動作不全」「開発会社の開発ミスに起因するもの」のように具体的に定義されているかを確認しましょう。

あわせて「保証対象の範囲が狭すぎないか」「仕様書の記載に曖昧な箇所はないか」もチェックしておくことが重要です。

リリース前の「受け入れ検査」が自社を守る

「バグの発生」が後々問題化しないためには、リリース前に発注者が行う「受け入れ検査（UAT）」のプロセスが重要です。

「受け入れ検査で発注者がOKを出した場合」と「受け入れ検査未実施の場合」では、一般的に、開発会社の対応が大きく変わります。
また、発注者として検収完了を書面で確認・保存しておくことで、後からバグ対応の範囲をめぐる争いになったときの根拠になります。
「何をもって検収完了とするか」が契約書に明記されているかも、事前に必ず確認しておきましょう。

バグの発生で関係性を損なわないために

バグが発見されたとき、「どちらの責任か」を争う前に、まず「現状を把握して対応策を検討する」という姿勢が大切です。
誤解されがちなことですが、契約書は争うためのものではありません。話し合いの「出発点」として機能するもの。つまり、争わずに済むために活用されるべきものなんです。

「どんなときにどこまで直すか」が契約書で明確になっていれば、バグが発見されても冷静に対処できます。発注者・受注者双方が納得できる形を、開発が始まる前に整えておくことが最善の準備です。

システム開発契約書への保証条項・保守契約条項の追加、契約書の新規作成・見直しなど、ご状況に合わせてご対応しています。まずはお気軽にお問い合わせください。

付録：無料で試せるオリジナルチェックシート

ここまでお読みいただきありがとうございます。

システム開発契約書のバグ対応リスクが簡単に確認できる当事務所製のチェックシートをご用意しました。実際にタップ（クリック）でチェックを入れて、不足分を明確にすることができます。
自社の契約書の現在地を知るためにぜひご活用ください！