システム開発における契約の解除の方法とは

システム開発は長期間に及ぶため、納期の遅延やシステムの不具合（契約不適合）を巡り、プロジェクトが暗礁に乗り上げるリスクと常に隣り合わせです。協議による解決が困難となった際、最終的な法的手段として検討すべきなのが「契約の解除」です。

本記事では、「契約の解除」について、システム開発との関連で重要となる点について解説していきます。

システム開発における契約の解除とは

システム開発における契約は、特別な合意がない限り、原則として仕事の完成を目的とする「請負契約」として取り扱われます。そのため、契約の解除に関しても請負契約に関する民法上の規定が重要な基準となります。

民法上の解除とはなにか

民法において契約を「解除」するとは、一度締結された契約の効力を消滅させ、初めから契約がなかった状態にすることを意味します（民法第540条以下）。

システム開発契約において解除が成立すると、ベンダー（受注者）はそれ以降の開発義務を免れ、ユーザー（発注者）は未払い報酬の支払い義務を免れます。そして、すでに着手金が支払われている場合は返還し、納品物があれば引き渡すといった、契約締結前の状態に戻す「原状回復義務」が双方に生じるのが原則です。

ただし、システム開発の実務において「解除すればすべて白紙（全額返金）になる」と思い込むのは大変危険です。2020年施行の改正民法により、開発が途中で頓挫し解除された場合でも、すでに仕上がっている部分がユーザーにとって利益があると判断されれば、ベンダーはその割合に応じた報酬を請求できることが明文化されました（民法第634条等）。

なお、契約解除による原状回復とは別に、相手方の債務不履行によって生じた損害の賠償を請求することも可能です。ここで注意すべきは、現在の民法では「契約を解除するだけなら相手方の帰責事由（故意・過失）は不要だが、損害賠償を請求するには相手方の帰責事由が必要（民法415条）」と法的に切り分けられている点です。

システム開発実務における契約解除の二つのパターン

システム開発における契約解除は、原因に応じて主に「納期遅延（履行遅滞）」と「納品後の不具合（契約不適合）」の2つのパターンに大別されます。

なお、旧民法下に存在した「瑕疵担保責任による解除（旧民法第635条）」は、2020年4月施行の改正民法により廃止・削除されました。現在は、どちらのパターンであっても一般の債務不履行規定（民法第541条・第542条）に基づき手続きを行うことになります。

債務不履行（履行遅滞）を理由とする契約解除

（例）ベンダーが当初約束していた納期を超過しているにもかかわらず、納品に応じない場合など

ベンダーが正当な理由なく約束した納期を過ぎてもシステムを完成・納品しない場合、発注者は原則として「相当の期間」を定めて履行を催告し、その期間内に納品されない場合に契約を解除できます。

請負契約におけるベンダーの主たる債務は「期日までに要件通りシステムを完成させて納品すること」です。納期徒過は履行遅滞にあたるため、まずは内容証明郵便等で「◯月◯日までに納品してください」と催告した上で解除へ進みます。

なお、納期を大幅に過ぎて開発が事実上頓挫しているなど、履行の追完が不可能な状態（履行不能）に陥っている場合は、催告を経ずに直ちに解除（無催告解除：民法第542条第1項）することも可能です。

ちなみに、「仕事の完成」とは、システム開発の場面では、具体的にはどういうことでしょうか。この点に関しては下記記事において解説しています。

納品後の不具合（契約不適合）を理由とする契約解除

（例）ベンダーから納品されたシステムについて、バグやデータの不整合が多く、後から実用に適さないことがわかった場合など

納品されたシステムに深刻なバグやデータ不整合があり、契約した目的を果たせない場合、発注者は「契約不適合責任」に基づく債務不履行として解除を主張できます。

不具合がある場合も原則として、まずはベンダーに対してバグの改修（追完）を相当期間を定めて催告し（民法第541条）、改修されない場合に解除となります。

ただし、システムが根本的に稼働せず修復が到底不可能な場合や、ベンダーが改修を明確に拒否している場合は、催告をすることなく即時に契約を解除できます（第542条第1項各号）。なお、発生しているバグが軽微なものである場合は、軽微性の抗弁（第541条ただし書）により解除自体は認められず、修復請求や損害賠償請求にとどまる点に注意が必要です。

契約不適合責任については、下記の記事において詳細に説明しています。

解除通知書の法的役割と「解除原因」の記載ルール

契約解除の意思表示を相手方（ベンダーまたはユーザー）に伝える書面が「解除通知書」です。双方が署名捺印する契約書とは異なり、解除通知は民法上の「単独行為」であり、一定の法的要件を満たしていれば一方的な意思表示のみで契約を消滅させる効果を持ちます。

実務上、「解除通知書には解除の具体的な理由（不具合の内容や遅延の事実）をどこまで詳しく書くべきか」という点がよくトピックとなります。

解除通知書に「解除の具体的な理由」を書かなくても解除は有効か？

結論として、法的には解除原因（理由）を細かく特定・記載していなくても、解除の意思表示自体は有効に成立します。

納品されたシステムに多数の不具合が存在した事案において、裁判所は以下のように判示しています。

解除の意思表示には、必ずしも解除原因を示す必要はなく、複数の解除原因による解除を単一の意思表示によってすることができるのであり、解除の意思表示にあたってある理由を掲げても、特にそれ以外の理由によっては解除しない旨明らかにするなど特段の事情のない限り、当該意思表示は、解除当時存在していた全ての理由に基づき、およそ契約を一切終了させるという意思表示であると考えられる。

東京地判平成16年12月22日判決

裁判所が示した判断の要点は以下の通りです。

• 訴訟において後から解除根拠を追加・差替可能
  解除通知を出す段階で、それが「開発遅延（履行遅滞）」にあたるのか「納品物の不具合（契約不適合責任）」にあたるのかという厳密な法的整理ができていなくても、通知時点で存在していた理由であれば、後に訴訟となった際にいずれの根拠（民法第541条・第542条など）からでも解除の有効性を主張できます。
• 複数の解除原因（理由）をまとめて単一の意思表示で解除できる
  「納期遅延」と「システムの不具合」など、複数の契約違反が重なっている場合でも、それら全てを理由として包括的に契約を終了させることができます。

実務上で「解除原因」を具体的に明記すべき理由

法的に理由の不記載が直ちに通知を無効にするわけではありませんが、実際のビジネス実務においては可能な限り解除原因（契約違反の具体的事実）を明記して通知することが強く推奨されます。

1. 「有効な催告（民法第541条）」として認められるため
   原則として契約解除には「相当の期間を定めた履行の催告（修正・納期の要求）」が必要です。どの機能にどのような問題があるのか、何をいつまでに履行すべきかを具体的に示さなければ、適法な催告とみなされない可能性もあります。
2. 争点の早期明確化と交渉の円滑化
   相手方に対し「どの不具合・どの遅延が原因か」を客観的データ（仕様書やテスト結果等）とともに示すことで、相手方の反論や認識の齟齬を最小限に抑え、返金や損害賠償に向けた協議へスムーズに移行できます。
3. 証拠の保全（内容証明郵便の活用）
   紛争が泥沼化した際、裁判所で「いつ、どのような理由で解除通知が相手に到達したか」が審理されます。解除通知書は必ず内容証明郵便（配達証明付き）で送付し、通知内容とその到達事実を公的に証明できる状態にしておくことが鉄則です。

「相当な期間」を定めた催告とはどのくらいか？

民法第541条に基づく催告解除を行う際、実務上しばしば問題となるのが「『相当の期間』とは具体的に何日（または何か月）を指すのか」という点です。

結論から言えば、催告時に指定した期間が客観的に見て短すぎたとしても、それによって直ちに催告が無効になるわけではありません。

期間指定が不十分でも「相当期間の経過」で解除は有効になる

判例（最高裁昭和29年12月21日判決等）において、催告時に「相当の期間」を定めなかった場合や、不相当に短い期間を指定して催告した場合であっても、催告がなされた時から客観的に「相当な期間」が経過した時点で、契約解除の効力が発生するとされています。

例えば、本来ならバグの修正や開発の遅れを取り戻すのに1か月（相当な期間）が必要な状況で、発注者が「1週間以内に納品せよ」と催告したとします。この場合、1週間が経過した直後には解除の効力は発生しませんが、催告から1か月が経過した時点で、自動的に適法な解除の効力が発生することになります。

そのため、催告期間の指定日数に対して極端に神経質になる必要はありません。

システム開発実務における催告の事実の重要性

システム開発における開発遅延（履行遅滞）や納品後の重大な不具合（契約不適合責任）が発生している「プロジェクトの炎上」事案では、催告を行ったからといって、指定期間内にベンダーが不具合を完全に補正・完成させられるケースは極めて稀です。

したがって、実務上は「指定した期間が数日足りないかどうか」で争うよりも、「催告をした事実」および「催告から相当な期間（通常は数週間〜1か月程度）が経過しても履行されなかった事実」を客観的な証拠として残すことが最も重要となります。

システム開発において履行遅延となる定義について、別記事にて説明しています。

解除通知書の通知の適切な方法は？

契約解除の意思表示は、相手方に到達した時点で効力を生じます（到達主義：民法第97条第1項）。

法的には、相手方に解除の意思が届いたことが証明できれば、送付方法（書面、電子メール、FAX、チャットツールなど）に限定はありません。しかし、裁判等の法的紛争へ発展する可能性を考慮すると、送付手段の選択は重要です。

電子メールやFAXによる通知のリスク

電子メールやチャットツール（Slack, Teams等）、FAXによる通知は簡便ですが、訴訟になった際、相手方から以下のような反論を許すリスクがあります。

• 「メールが迷惑メールフォルダに入っており見ていない（到達していない）」
• 「受信した担当者には契約解除の権限がなかった」
• 「メッセージが改ざんされている、または削除されている」

到達の事実や通知時期をめぐって「言った・言わない」の水掛け論になると、解除の有効性を立証する側（解除を主張する当事者）が不利益を被るおそれがあります。

「配達証明付き内容証明郵便」が実務上の鉄則である理由

システム開発の契約解除においては、配達証明付きの内容証明郵便（または電子内容証明）で解除通知書を送付することが実務上の鉄則とされています。

1. 「いつ」「どのような文面が」届いたかを日本郵便が公的に証明できる
2. 相手方に「法的措置へ移行した」という強い意思（真剣度）を伝達できる
3. 裁判において一発で確実な証拠（到達証明）として採用される

手続き面の不備で後から解除の効力を争われるリスクを排除するためにも、解除通知書は内容証明郵便（配達証明付き）で送付すべきです。

まとめ：システム開発の契約解除は弁護士に相談を

システム開発における契約解除は、単にプロジェクトを中止する手続きにとどまらず、既履行部分の「割合的報酬請求」や「損害賠償請求」、原状回復（返金）の範囲を巡り、数千万円規模の法的紛争へ発展するリスクを孕んでいます。解除通知の送付手順や不具合・遅延の証拠保全を誤ると、本来主張できたはずの権利を失う恐れもあります。

「納期を過ぎてもシステムが完成しない」「相手方から不当な契約解除や返金を迫られている」といった問題に直面した際は、感情的な対立を深める前に、IT法務の実務実績が豊富な弁護士へ早期にご相談ください。契約書やプロジェクトの進捗ログを精査し、リスクを最小限に抑えた最適解をご提案いたします。

当事務所による対策のご案内

モノリス法律事務所は、IT、特にインターネットと法律の両面に高い専門性を有する法律事務所です。当事務所では、東証上場企業からベンチャー企業まで、さまざまな案件に対する契約書の作成・レビューを行っております。契約書の作成・レビュー等については、下記記事をご参照ください。