システム開発における契約の解除の方法とは
システム開発というプロジェクトは、長きにわたるプロジェクトであるため、その進行の途中で「炎上」といった事態になることも当然想定されます。そして、いつもユーザーとベンダーが歩調を合わせてやっていけるならともかく、途中で契約の解除という手段を検討する事態も想定しておくべきでしょう。
本記事では、契約の「解除」という法律上のオプションについて、システム開発との関連で重要となる点について解説していきます。
この記事の目次
システム開発と解除の関係とは
民法上の解除とはなにか
改正民法おいて、契約の「解除」に関する一般的な規定は、５４０条から５４８条までの条文で定められています。契約を解除するということは、一度締結された契約について、その効果を後から消滅させるということを意味します。
ユーザーとベンダーという関係でいうならば、通常、ひとたび契約が締結されれば、ベンダーにもシステムを開発する義務が課せられ、ユーザーにも報酬の支払いという義務が課せられます。そして、これらを裏返したものが、両者の「権利」ともなります。もしこれが解除されるということになれば、両者が負っていた義務・持っていた権利は、契約が締結される前の状態に戻ることになります。したがって、もしまだ履行されてない部分の債務があったとしても、履行する義務がなくなることはもちろんのこと、契約締結前の状態を基準にして、相互に元どおりの状態としていく義務が発生することになります。これが「原状回復義務」というものです。
なお、もし同時に、損害が発生しているといった事情があるのであれば、それに対しては別途損害賠償を行うことも可能です。
システム開発実務と解除のかかわり
システム開発をはじめとするビジネスまわりの法律実務に馴染みのある人からみれば、契約の「解除」といえば、まず連想されるのは解除通知書のほうかもしれません。しかし、法律上はシステム開発の文脈に限ったとしても、根拠となる条文は、その解除の原因ごとに二つのパターンに大別されます。
債務不履行（履行遅滞）を理由とする場合
（例）ベンダーが当初約束していた納期を超過しているにもかかわらず、納品に応じない場合など
民法 第五百四十一条 当事者の一方がその債務を履行しない場合において、相手方が相当の期間を定めてその履行の催告をし、その期間内に履行がないときは、相手方は、契約の解除をすることができる。
請負契約型のシステム開発において、「当事者の一方」であるベンダーが負う「債務」とは、要件定義通りのシステムを完成させて納品することです。したがって、納期を徒過したにもかかわらずベンダーが納品を行わない場合とは、言い換えれば、納期までにベンダーが仕事を完成させなかった場合です。では、「仕事の完成」とは、システム開発の場面では、具体的にはどういうことでしょうか。この点に関しては下記記事において詳細に解説しています。
瑕疵担保責任を理由とする場合
（例）ベンダーから納品されたシステムについて、バグやデータの不整合が多く、後から実用に適さないことがわかった場合など
民法 第六百三十五条 仕事の目的物に瑕疵があり、そのために契約をした目的を達することができないときは、注文者は、契約の解除をすることができる。ただし、建物その他の土地の工作物については、この限りでない。
なお、システム開発プロジェクトという観点からいうのであれば、ベンダー側から契約解除の意思表示がなされるということはそうあるものではありません。通常はユーザーからベンダーに対してなされるケースを想定しておけばよいでしょう。
瑕疵担保責任については、下記別記事において詳細に説明しています。
解除通知書とそれに関連する法律問題
解除通知書とは、（通常はユーザーからベンダーに対して）契約を解除する旨を伝えるための文書をさします。条文としては、以下のものを参照するとよいでしょう。
民法 第五百四十一条 当事者の一方がその債務を履行しない場合において、相手方が相当の期間を定めてその履行の催告をし、その期間内に履行がないときは、相手方は、契約の解除をすることができる。
システム開発にかかわるドキュメントとしてみた場合には、解除通知書の特徴としては、プロジェクトの円滑な進行を目的としたものではなく、プロジェクトを終了させるためのものであるという点を挙げることができます。また、直接的に一定の法律上の効果をもたらすことを期待している文書であるという点も大きな特徴です。
しかし、前掲の条文の通り、契約書などとは異なり、（一定の条件さえ整えば）一方からの意思表示のみで足りるものでもあります。ユーザーからベンダーに解除通知書が提示される場合、それを受領したベンダー側の担当者にとっては、「解除通知書を読んでも、どうして契約が解除されたかがわからない」といった問題が起きることが想定されます。では、ユーザーは解除通知書を作る場合、そこには解除の理由をどこまで具体的に指摘すべきなのでしょうか。
解除通知書に解除の原因は書いておくべきか
この点については過去の裁判例等をみるに、解除通知書に解除の原因を明記することは、必ずしも解除を行うために必須ではないと考えられています。下記に引用する裁判例は、納品されたシステムに不具合があったことから法律問題に発展したという事案です。ユーザー側から解除の意思表示を行う際、どこまで不具合の内容について具体的に把握し、それを具体的に指摘しておく必要があるのかといったことが問題となった点につき、裁判所は以下のように判示しました。
解除の意思表示には、必ずしも解除原因を示す必要はなく、複数の解除原因による解除を単一の意思表示によってすることができるのであり、解除の意思表示にあたってある理由を掲げても、特にそれ以外の理由によっては解除しない旨明らかにするなど特段の事情のない限り、当該意思表示は、解除当時存在していた全ての理由に基づき、およそ契約を一切終了させるという意思表示であると考えられる。
東京地判平成１６年１２月２２日
「複数の解除原因を単一の意思表示によってすることができる」というのが裁判所の見解です。つまり、契約の当事者に解除の意思があるのか否かが重要なのであり、その詳細な原因について事細かに指摘する必要はないということです。
すなわち、納品されたとはいえ、未完成であるという扱いをすべきなのか、重大な欠陥があるため瑕疵担保責任の問題であるという扱いをすべきなのかといった点までは、解除の意思表示の段階では問題にしなくてもよいということです。こうした微妙な問題については一旦不問にしておくとしても、先に解除の意思表示をしておけば、万が一後に訴訟になったような場合でも、後から履行遅滞・瑕疵担保責任どちらを解除の根拠としても争うことが可能ということです。
- 未完成のものが納品された・・・→債務不履行
- 重大な欠陥のあるものが納品された・・・→瑕疵担保責任
原因を詳細に特定せずとも、解除の意思表示は解除の意思表示として有効です。
もっとも、解除原因を具体的に指摘したうえで解除通知書を提示するほうが、万一ベンダーとの間でコミュニケーションの行き違いや認識に齟齬があるような場合でも、それを明らかにできるといったメリットもあります。また、解除通知書を受領する相手方にとっても、その原因に思い当たりがあるのであれば、後から紛争にもつれる心配も小さくなります。したがって可能な限り解除原因を明確に記載しておくほうがよいことも事実です。
「相当な期間」を定めた催告とはどのくらいか？
また、もう一つ考えられる点としては民法５４１条における、「”相当な期間”というのがどのくらいの長さか」という問題です。しかし、この点については、あまり神経質に考える必要はないと思われます。なぜなら、催告を行うまでの期間に「相当な期間を定めて」いない場合であっても、催告から相当期間が経過していれば、結果的に契約の解除は可能となるからです。また、催告までの期間が「相当な期間」でなかったとしても、結果的に相当な期間が経過した段階で契約の解除は可能となることが判例法上も明確にされているからです。
システム開発プロジェクトにおいて、ひとたび履行遅滞や瑕疵担保責任が問題となるような「炎上」事案においては、「相当な期間」を定めて催告を行ったところで、納品や瑕疵修補が完了する場合は多くはないでしょう。こうした点を踏まえても、実務上、「相当な期間」をめぐって深刻な争いが起きることは考えにくいといえます。
システム開発において履行遅延となる定義について、別記事にて説明しています。
解除通知書の通知の方法は？
また解除通知書はどのような方法で通知するのがよいかという点については、結果的に通知が到達するのであれば（さらに言えば、確実に到達したということが後から立証できるような方法であれば）どのような方法であっても問題はありません。
したがって、あまり手続き面の問題で神経質になる必要はありません。たしかに実務上は、後から「言った・言わない」の問題となることを避けるために、内容証明郵便などのやり方が好まれる傾向はあります。しかし、相手に到達したことが確認できるのであれば、FAXや電子メールなどの簡便なやり方であっても問題はありません。ただ結局、裁判などになってしまった場合は、「相手方に到達した」ということを証明する必要があり、この観点で内容証明が安全であるとは言えます。
まとめ
本記事では、システム開発という文脈に沿って、契約の解除というものについての整理を行いました。解除の行い方という実務のノウハウはもちろんのこと、あわせて法律的に有効な意思表示のやり方という点も含めて理解できれば、応用の効きやすい知識となるのではないでしょうか。
