システム等の運用保守契約のポイント｜TECH GOAT PARTNERS法律事務所

本記事の概要

システムの開発が完了した後、システムの運用保守の契約を締結することになります。システムは「開発したらおわり」ではなく、その後の安定的な運用のための管理が必要になることが一般的です。では、システムの運用保守に関する契約では、どのような事項について定めればよいのでしょうか。よくあるトラブルを踏まえて契約内容を決めていきましょう。

※5分程度の読み終えることができます。

1.　運用保守とは

システム開発が完了した後、そのシステムを実際に現場で運用していくことになります。

運用して行く中で、バグが発見されたり、予想外のアクセス数によりサーバーがダウンしてしまったり動作が遅くなったりすることがあります。

場合によっては外部からの不正な攻撃（サイバー攻撃）によりその対応を行う必要があるケースもあります。

サイバー攻撃への対応はこちらの記事で詳しく解説しています。

システムの運用保守は、このような問題に対応し、システムが正常に動作することを維持することを目的としています。

システムに生じている問題を発見し、その原因を特定し、原因を解消することが必要になります。

バグが生じているケースであれば、バグによって生じている不具合から、バグの位置を特定し、バグを直す（デバッグといいます）作業を行い、正常な動作がする状態に持って行く必要があります。

2.運用保守に関する契約を締結する必要性

「システムの開発をしっかり行っていれば運用保守の契約なんで結ばなくていいんじゃないの？固定費かさむし、出来れば契約したくないんだよね」

システム開発が十分に行われていれば運用保守は必要ないのではないか？と思われるユーザーの方も少なくないと思います。

それでも、なぜ世の中の多くのシステムで運用保守契約が締結されているのにはそれなりの理由があります。

運用保守契約が必要となる理由としては大きく以下の3つが挙げられます。

①現実的な問題としてバグの発生を完全に回避することが難しいこと

②運用保守は技術的・リソース的に外部の業者に任せた方がメリットあること

③システム開発契約で運用保守段階のリスクを全てヘッジすることは難しいこと（契約不適合責任では完全にリスクヘッジできないこと）

以下、一つずつ解説していきます。

①現実的な問題としてバグの発生を完全に回避することが難しいこと

システムは膨大な量のソースコードによって構成されています。

近年はノーコードによるシステム開発も行われていますが、ノーコードによって開発できるシステムには限界があるのが現状です。今後、ノーコードによるシステム開発はより高度なレベルまで対応できるようになることが見込まれますが、複雑なシステム開発に関してはしばらくコーディングが必要になる時代が続くでしょう。

ソースコードは定型的なコードを流用する箇所もありますが、最終的には人が入力していくものです。また、システム開発の規模が大きくなれば成程、コーディングを行うプログラマーの数も数十人、数百人規模に膨れ上がります。関与する人数が増えれば増えるほど人為的なミスが起こる可能性は高くなります。

実際に数多くのシステム開発において事後的にバグが発見されている事実もあります（資料みつける）

システム開発においてバグは発生するという前提で運用保守に関する計画を策定する必要があります。

②運用保守は技術的・リソース的に外部の業者に任せた方がメリットあること

ユーザーもシステムの運用保守の担当者がいるケースでは、社内の担当者に運用保守業務を任せるという考えもあります。

もっともシステムは開発に携わっている者の方が当然その構造を理解しています。

そのため、実際に開発を担当したベンダーやその協力会社に運用保守を任せた方が効率の良い業務遂行が期待できます。

また、複雑なシステムの場合には、社内の担当者の技術レベルを超えている場合もあります。

システムによっては24時間365日稼働している必要があるものもあります。このようなシステムの場合、24時間対応可能なシフトを組むことが難しいこともあります。

運用保守はそのシステムに詳しい者が担当した方が効率が良いこと、社内の担当者の技術レベルを超えていることがあること、運用保守の対応時間に必要な人的なリソースの確保の側面から

③システム開発契約で運用保守段階のリスクを全てヘッジすることは難しいこと（契約不適合責任では完全にリスクヘッジできないこと）

システム開発契約では一括請負形式の場合だけではなく、多段階契約の場合であっても、開発工程において請負契約が選択されることが多いです。

請負契約では、ベンダーは仕事の完成義務を負います。そして、納品した成果物に関して、民法上は契約不適合責任を負います。

ユーザーとしては、納品後に判明した不具合については、契約不適合責任によって対応が可能と考えている方もいますが、契約不適合責任は万能なものではありません。

まず、契約不適合責任の概要について理解しましょう。

3.契約不適合責任

契約不適合責任は、2020年4月に施行された改正民法以降に使用されるようになった用語です。民法が改正される前は「瑕疵担保責任」と呼ばれるものでした。長らくIT業界にいる方には「瑕疵担保責任」という用語の方が馴染みが深いかもしれません。

契約不適合責任は、簡単にいえば、「完成した納品物に契約の内容（≒仕様）との不一致があった場合に、その不一致を発見してから1年間の間は、その不一致を修正、代替品の納品、不一致の程度に応じた料金の減額を求めることができる権利です」

契約不適合責任を定める民法は以下のとおりとなっています。

なお、民法上は、売買契約に関する定めとして契約不適合責任が規定されており、その定めが他の契約にも準用される形になっています。

（買主の追完請求権）
第五百六十二条　引き渡された目的物が種類、品質又は数量に関して契約の内容に適合しないものであるときは、買主は、売主に対し、目的物の修補、代替物の引渡し又は不足分の引渡しによる履行の追完を請求することができる。ただし、売主は、買主に不相当な負担を課するものでないときは、買主が請求した方法と異なる方法による履行の追完をすることができる。
２　前項の不適合が買主の責めに帰すべき事由によるものであるときは、買主は、同項の規定による履行の追完の請求をすることができない。

（買主の代金減額請求権）
第五百六十三条　前条第一項本文に規定する場合において、買主が相当の期間を定めて履行の追完の催告をし、その期間内に履行の追完がないときは、買主は、その不適合の程度に応じて代金の減額を請求することができる。
２　前項の規定にかかわらず、次に掲げる場合には、買主は、同項の催告をすることなく、直ちに代金の減額を請求することができる。
一　履行の追完が不能であるとき。
二　売主が履行の追完を拒絶する意思を明確に表示したとき。
三　契約の性質又は当事者の意思表示により、特定の日時又は一定の期間内に履行をしなければ契約をした目的を達することができない場合において、売主が履行の追完をしないでその時期を経過したとき。
四　前三号に掲げる場合のほか、買主が前項の催告をしても履行の追完を受ける見込みがないことが明らかであるとき。
３　第一項の不適合が買主の責めに帰すべき事由によるものであるときは、買主は、前二項の規定による代金の減額の請求をすることができない。

法律上は、上記のような定めになっていますが、現実の取引においては法律上の定めを修正していることも多いのが実情です。

契約不適合責任自体は任意規定といって当事者の合意によってその内容の修正が可能なものとなっています。そのため、契約書においても、ユーザーは契約不適合責任が追求できるケースを多くするように修正をします。その一方で、ベンダーは契約不適合責任を免責したり、契約不適合責任を負うケースを限定する形で修正します。

契約不適合責任についてはこちらの記事で細かく解説しています。

いずれにせよ、契約不適合責任には一定の期間制限があり、その対応内容にも限界があるため運用保守段階で発生するトラブルの全てを契約不適合責任で対応することは困難です。