不具合改修に関する覚書とは？
不具合改修に関する覚書とは、システム、アプリケーション、Webサイト、ソフトウェアなどの開発・保守において、発見された不具合（バグ）の修正内容や対応条件を当事者間で明確にするための文書です。システム開発では、納品後に不具合が見つかることは珍しくありません。しかし、その不具合が「契約上の瑕疵（契約不適合）」なのか、「追加要望」なのか、「仕様変更」なのかについて認識が一致していないと、費用負担や対応範囲を巡るトラブルが発生しやすくなります。そのため、不具合改修に関する覚書では、あらかじめ次のような事項を整理します。
- 改修対象となる不具合の内容
- 改修範囲
- 無償対応・有償対応の区分
- 改修スケジュール
- 確認方法・検収方法
- 責任範囲
- 原契約との関係
特にシステム開発では、「不具合」と「仕様変更」は全く異なるものです。この区別を明文化しておくことが、不要な紛争を防ぐ最大のポイントになります。
不具合改修に関する覚書が必要となるケース
次のようなケースでは、覚書を締結しておくことが望まれます。
納品後にバグが見つかった場合
システム納品後、利用開始後に不具合が判明することがあります。
例えば、
- ログインできない
- 登録ボタンが動作しない
- 帳票が正しく出力されない
- 決済処理でエラーが発生する
このような場合に、どこまでを無償で修正するかを明確にできます。
改修内容だけを書面で整理したい場合
原契約を変更するほどではないものの、一部機能だけ修正する場合にも覚書が利用されます。追加契約書を作成するより簡潔で、必要事項だけを整理できます。
仕様変更との区別を明確にしたい場合
開発現場では、「これはバグです」「いいえ、追加機能です」という認識の違いが頻繁に起こります。覚書で対象を具体的に列挙しておけば、このようなトラブルを防止できます。
保守契約が存在する場合
保守契約に基づき対応する案件についても、
- 保守対象
- 保守対象外
- 追加費用
を整理する目的で利用されます。
不具合改修に関する覚書に盛り込むべき主な条項
一般的には次の条項を設けます。
- 目的
- 対象となる不具合
- 改修範囲
- 改修内容
- 原因調査
- 費用負担
- 改修期限
- 動作確認
- 再改修
- 仕様変更との区別
- 資料提供
- 秘密保持
- 知的財産権
- 損害賠償
- 原契約との関係
- 協議事項
- 合意管轄
これらを定めることで、不具合対応に関するルールを明確化できます。
条項ごとの解説と実務ポイント
1．目的条項
目的条項では、本覚書が「不具合改修に関する事項のみ」を定める文書であることを明確にします。これにより、追加開発契約や保守契約との役割を区別できます。
2．対象不具合の特定
最も重要なのは、対象を曖昧にしないことです。
例えば、
- 画面名
- 機能名
- 発生日
- エラー内容
- 再現方法
- 優先度
まで記載すると、後日の争いを防止できます。
チケット管理システムやバグ管理ツールの番号を記載するケースも多く見られます。
3．改修範囲
「どこまで修正するのか」を明確にします。
例えば、
- 対象画面のみ
- 関連画面も含む
- プログラム修正のみ
- データ修正を含む
- テストまで実施する
など、具体的に定めます。
4．仕様変更との区別
実務上、最も紛争になりやすい条項です。
例えば、
- 新しい帳票を追加したい
- 入力項目を増やしたい
- ボタン配置を変更したい
- 管理画面を追加したい
これらは一般的に不具合ではなく、追加開発又は仕様変更となります。
覚書で明確に区別しておくことが重要です。
5．費用負担
費用負担は必ず定めるべき事項です。
一般的には、
- 乙の責任による不具合は無償
- 追加要望は有償
- 第三者サービス変更は有償
- OS変更による改修は有償
といった区分が用いられます。事前見積りの承認を条件にすることで、予期せぬ費用発生を防止できます。
6．改修期限
改修時期についても定めます。
例えば、
- 重大障害は3営業日以内
- 軽微な不具合は10営業日以内
- 協議により変更可能
など、優先度別に設定すると実務的です。
7．動作確認・検証
改修後は必ず確認作業を実施します。
一般的には、
- 開発側テスト
- 受入テスト
- 本番確認
を経て改修完了となります。確認期間を定めておくことで、いつまでも検収が終わらない状況を防げます。
8．再改修
同じ原因で再発した場合の対応も重要です。一定期間内であれば無償対応とするケースが一般的です。ただし、新たな原因による障害まで無制限に保証すると、開発会社の負担が過大になるため、対象を限定することが望まれます。
9．知的財産権
改修によってプログラムを修正した場合でも、著作権や知的財産権の帰属は原契約に従うことが一般的です。覚書では、原契約との整合性を明記しておくことが重要です。
10．原契約との関係
覚書だけで契約関係を完結させることは少なく、多くの場合は原契約を補足する位置付けとなります。
そのため、
- 原契約を優先するのか
- 覚書を優先するのか
を明確に定める必要があります。通常は、不具合改修に関する事項については覚書を優先し、それ以外は原契約に従う旨を規定します。
不具合改修に関する覚書を作成する際の注意点
- 「不具合」と「仕様変更」の定義を明確に区別する。
- 対象となる不具合を具体的に特定し、曖昧な表現を避ける。
- 無償対応と有償対応の基準を明文化する。
- 改修後の確認方法や検収方法を定める。
- 原契約や保守契約との関係を整理し、条項間の矛盾を防ぐ。
- 改修対象が複数ある場合は、一覧表や別紙を添付して管理する。
- チケット番号や障害管理番号などを記載すると、対象範囲を特定しやすくなる。
不具合改修に関する覚書と追加開発合意書の違い
| 項目 | 不具合改修に関する覚書 | 追加開発合意書 |
|---|---|---|
| 目的 | 不具合の修正条件を定める | 新機能や仕様変更を定める |
| 対象 | 契約内容どおりに動作しない箇所 | 新たな機能・画面・処理 |
| 費用 | 無償対応となる場合がある | 原則として有償 |
| 主な内容 | 改修範囲、責任、期限、確認方法 | 追加仕様、費用、納期、成果物 |
| 利用時期 | 不具合発生時 | 追加開発が決定した時 |
| 契約との関係 | 原契約を補完する | 原契約を変更・追加する |
まとめ
不具合改修に関する覚書は、システム開発やWeb制作において、改修対象や責任範囲、費用負担を明確にし、発注者と受注者双方の認識の違いを防ぐための重要な文書です。特に実務では、「不具合なのか」「追加開発なのか」という判断を巡ってトラブルになるケースが少なくありません。覚書によって対象となる不具合を具体的に特定し、無償・有償対応の基準や改修後の確認方法を定めておくことで、円滑なプロジェクト運営につながります。また、原契約や保守契約との整合性を確保しながら運用することで、将来的な紛争リスクを軽減し、継続的なシステム保守・運用を安心して進めることができます。
