システム保守契約・運用契約書作成に際し、特に意識したい条項について解説

【ご相談内容】

当社は、自らが制作しユーザに納品したシステムについて、事後的な保守運用サポートサービスを提供しています。
これまで特にトラブルもなく対応できていたのですが、一部取引先よりクレームを受け、不本意な対応を強いられたことから、今後はきっちりとした契約書を作成し、トラブル防止を図りたいと考えています。
システム保守契約書・運用契約書を作成する上でのポイントを教えてください。

 

 

【回答】

おそらくは「システム保守契約書」、「システム保守運用契約書」で検索を行った場合、たくさんの参考書式が検索結果として表示されると思われます。
もちろん、この参考書式を参照しつつ、システム保守契約書・運用契約書を作成することは可能です。ただ、参考書式であるが故に、残念ながら内容面で誤りがあったり、リスクヘッジ対策にはならない事項が明示されていたりする等、弁護士視点では「？」と思うことが多々あります。
したがって、きっちりとした契約書を作成するのであれば、是非弁護士にご依頼いただきたいところです。
もっとも、何らかの理由で事業者自らがシステム保守契約書・運用契約書を作成する場合もあるかと思います。そこで、本記事では、システム保守業務・運用業務を受託する事業者において、是非とも押さえておいて欲しいと考える5つのポイントにつき解説します。

 

 

【解説】

1.保守契約・運用契約とは

(1)必要性

そもそも論として、保守契約・運用契約を締結しなければならない法的義務はありません。
ただ、保守契約・運用契約を締結しなかった場合、次のような問題が起こりがちです。

 

①ユーザのみではバグ等の不具合対応ができないこと
残念ながら、バグ等の不具合が全くないシステムを開発することは不可能と言わざるを得ません。このため、システム稼働後に何らかのバグ等の不具合が発生することを前提に、できる限り速やかにバグ等の不具合を取り除くことが重要となります。
この点、ユーザがバグ等の不具合の補修を行うことができればよいのですが、通常ユーザは専門的知識や技術を有していないため、対応することが困難又は不可能です。
したがって、システムを正常稼働させ続けるためには、保守契約を締結することが必要不可欠となります。

 

②契約不適合責任だけでは不十分であること
上記①の問題を指摘した場合、「バグ等の不具合があるのであれば、システム開発契約を根拠に契約不適合責任を追及すればよいのでは」と質問を受けることがあります。
たしかに、システムの引渡し完了前に存在し、かつ契約目的を達成しえないようなバグ等の不具合であれば契約不適合責任で処理することも可能です。
しかし、システム開発契約においては、契約不適合責任を追及できる期間につき一定の制限が設けられることが通常であるところ、その期間を経過した場合は契約不適合責任を追及することは不可能です。また、そもそも契約目的を達成しないバグ等の不具合と評価できるのか当事者間で争いが生じることもあります。さらに、引渡し完了後の環境変化による不具合については契約不適合責任の対象とはなりえません。
したがって、幅広いバグ等の不具合に対処してもらうためには、保守契約を締結することが必要不可欠となります。

 

③サポートが受けられないこと
例えば、システムの引渡し完了後、操作方法が分からない等の悩みを抱えるユーザは一定数存在すると思われます。システム開発の契約内容にもよりますが、この種の悩みに対し、ベンダが回答及び指導する義務は通常生じません。また、引渡し完了後の環境変化によりアップデートが必要となる場合であっても、ベンダは当然にシステムの改修を行う義務を負うわけではありません。
したがって、システムを末永く使いこなすためには、運用契約を締結することが必要不可欠となります。

 

(2)定義

保守契約・運用契約という用語例ですが、法律上の定義がないことはもちろん、社会共通の認識も定まっているとは言い難いところがあります（むしろ、保守と運用について意識的に使い分けられていない場面もしばしば見かけます）。
この点、独立行政法人情報処理推進機構が公表している「情報システム・モデル取引・契約書（第二版）」では、次のように定義づけられています。
・保守とは、情報システムやソフトウェアの現状を業務及び環境に適合するように維持管理を行う工程のこと
・運用とは、業務運用環境で情報システムを稼働して、業務を円滑に遂行するフェーズであり、システムの起動／終了や監視、ファイルメンテナンスなどが含まれること

上記定義の通り、保守と運用は異なる作業を意味するのですが、端的には、保守は異常時対応を主とするもの、運用は正常時対応を主とするものとイメージしておけば、受託者・ユーザ間で誤解を招かず、共通認識を持ちやすいと考えられます。

 

(3)誰に依頼するべきか

保守契約・運用契約の必要性については、上記(1)で記載した通りですが、ではユーザは誰と保守契約・運用契約を締結すればよいのでしょうか。
これについては一義的な正解はないのですが、一般論としては、対象となるシステムを開発したベンダがその詳細を最も知り得る立場である以上、開発ベンダに依頼するのが一番確実といえます。
ただ、複数のシステムが連携している場合、開発ベンダは自ら開発したシステムのみ保守・運用するだけであって、システム全体の保守・運用を行ってくれない場合があります。また、ユーザ側にある程度ITスキルを持つ担当者がいるのであれば、保守のみ委託し、運用はユーザ自らが行うということも考えられるところです。
状況に応じて、誰に依頼するべきかを判断する必要があります。

 

(4)保守契約・運用契約の法的性質と印紙税

保守契約及び運用契約は、日常用語では業務委託契約というジャンルに分類されますが、この業務委託契約は、法的には請負契約と評価される場合もあれば、準委任契約と評価される場合もあります。
この点、保守契約の中でも、障害原因調査業務であれば準委任契約と評価されるのに対し、バッチ処理業務であれば請負契約と評価されると考えられます。また、運用契約の中でも、ユーザからの問い合わせ対応業務であれば準委任契約と評価されるのに対し、システムのバージョンアップ業務であれば請負契約と評価されると考えられます。
このように保守契約及び運用契約は、準委任と請負の混合契約と考えるのが理論的には素直なのですが、一般的には準委任契約として扱われることが多いようです。
ただ、契約上は準委任契約と明記したとしても、具体的な業務内容として、上記のような請負と評価される業務が含まれている場合、印紙税法上は請負契約（2号）と取り扱われることに注意を要します（なお、継続的取引であれば7号の取扱いとなります）。

 

(5)契約不適合責任との関係

上記(1)②で契約不適合責任について触れましたが、実はシステム開発契約書と保守契約書を作成する上では、契約不適合責任と保守契約の関係性を整理する必要があります。
なぜなら、契約不適合責任と保守契約に基づく業務範囲が一部重複するからです。この重複により、例えば、ユーザは契約不適合責任を主張すれば無償で修補してもらえたにもかかわらず、保守契約に基づく修補であれば有償であるといった問題が生じえます。
この点、理屈で考えた場合、対処法は次の3つとなります。
・契約不適合責任を特約で排除し、バグ等の不具合対応は保守契約に一本化する方法
・保守契約の開始時点をもって、契約不適合責任の追及可能期間を終了させる方法
・契約不適合責任と保守契約が重複する期間は、ユーザに選択権を与える方法
どの方法も一長一短ありますが、受託者視点で考えた場合、1つ目又は2つ目の方法が対処しやすいものと思われます。

2.保守契約・運用契約に定めるべき事項・ポイント

本記事では、特に押さえておきたい5つの条項につき解説を行います。

 

(1)業務範囲

・業務範囲を具体的に明記すること
【サンプル条項】

第×条 本契約において、受託者がユーザに対して提供する保守運用業務は次の各号に定める通りとする。 ①ユーザからの問い合わせに対し、オンライン手段を通じての回答業務 ②ユーザからの指示に基づく障害原因調査業務 ③××（以下省略）

 

上記1.(2)でも記載しましたが、「保守」「運用」という言葉は多義的に用いられています。このため、具体的にどのような業務が契約対象となっているのか、これらの言葉だけでは受託者とユーザとで認識を共有化することができず、「××業務が含まれるか」という点で紛争となりがちです。
したがって、業務範囲をできる限り個別具体的に明記することがポイントとなります（ちなみに、上記サンプル条項の業務の記載方法は必要十分とは言い難いところがあります）。そして、明記するに際しては、次のような視点で整理しながら、対象業務を抽出することが有用と考えられます。

 

①トラブル対応
・障害の原因調査業務が含まれるのか、含まれるのであればどのような手順で行われるのか等を明記する
・バグ等の不具合修補業務が含まれるのか、含まれるのであれば修補を行う前提条件及び何時までに・何を・どの範囲で行うのか等を明記する
・データ等の復元業務が含まれるのか、含まれるのであれば復元完全性につきどこまで保証するのか等を明記する

 

②環境変化対応
・システムと連携するハードウェア、ソフトウェア（OSを含む）の変更に伴う改修業務が含まれるのか、含まれるのであれば改修を行う前提条件及び何時までに・何を・どの範囲で行うのか、別途費用の発生条件等を明記する
・法令や社会情勢の変化に伴う改修業務が含まれるのか、含まれるのであれば改修を行う前提条件及び何時までに・何を・どの範囲で行うのか、別途費用の発生条件等を明記する

 

③予防・事前対応
・システム稼働分析を踏まえた提案及び改善業務が含まれるのか、含まれるのであれば提案の頻度、何時までに・何を・どの範囲で改善するのか、別途費用の発生条件等を明記する
・セキュリティ対策業務が含まれるのか、含まれるのであればセキュリティレベル、更新頻度等を明記する

 

④拡張対応
・機能、性能の追加拡張業務が含まれるのか、含まれるのであれば追加拡張を実施する前提条件、何時までに・何を・どの範囲で改善するのか、別途費用の発生条件等を明記する
・操作性、信頼性の改善対応業務が含まれるのか、含まれるのであれば改善対応を実施する前提条件、何時までに・何を・どの範囲で改善するのか、別途費用の発生条件等を明記する

 

⑤コンサルティング対応
・ユーザからの問い合わせ対応業務が含まれるのか、含まれるのであれば問い合わせ方法、対応時間、実施方法・手段、対応範囲、対応上限回数等を明記する
・利用方法に対する提案業務が含まれるのか、含まれるのであれば頻度、実施方法・手段等を明記する
・ユーザ人員の教育訓練業務が含まれるのか、含まれるのであれば対応人数、対応日時、実施方法・手段等を明記する

 

・対象外の業務を明記すること
【サンプル条項】

第×条 ユーザおよび受託者は、次の各号に定める業務が本契約の対象外であることを確認する。なお、本契約の対象外となっている業務について、ユーザが受託者に対して依頼を行う場合、別途協議し合意の上、個別契約を締結する。 ①稼働環境や閲覧環境（OSのバージョンアップやブラウザのバージョンアップ）の変化・変更による不具合の調査および修正 ②システムに対する新規システムの導入または外部システムとの連携 ③××（以下省略）

 

上記で「業務範囲を具体的に明記」することがポイントであると記載しました。
ただ、個別具体的な業務内容を言葉で表現することは難しいという場合が多々あります。特に契約書に落とし込むとなると、（別にそこまでに気にする必要はないのですが何故か）高尚な表現をしなければならないと考える方が多いようで、上手く言い表すことができないという現場の声をよく耳にします。
そうであれば、逆転の発想ではないですが、契約対象外となる業務を個別列挙し、当事者双方の認識共有化を図るという方法を講ずることも有用です。
なお、契約対象外となる業務と受託者が責任を負わない事項（免責条件）は重複することが多いので、これらの事項との整合性を検討しながら明記することがポイントとなります。

 

・契約対象となる物件を特定すること
【サンプル条項】

第×条 第×条に定める保守運用業務は、次に定めるシステムに対して実施される。 ・製品名称 ・納入日 ・設置場所 ・××（以下省略）

 

この対象物の特定に関する条項ですが、意外と忘れがちであり、しかし後日重大なトラブルにつながりかねないため、注意喚起を図るべく、上記の「業務範囲を具体的に明記すること」で解説した内容を独立条項化したものとなります。
例えば、一口にシステムと言っても、複数のベンダが制作した個別プログラムが連携することでユーザの利用目的に合致したシステムとして稼働する場合があります。この場合、受託者としては、同業他社が制作したプログラムについては精通しておらず、保守運用業務を実施することが難しいため対象業務外と認識します。一方ユーザは、システムを構成するプログラムの制作状況について十分な知識を持っておらず、システムが稼働するか否かが関心対象であり、たとえ他社制作のプログラムに原因があったとしても、システムが稼働しない以上は受託者に対して改善要求を行ってきます。
このようなトラブルを避けるためには、保守運用業務の対象となる対象物を契約書に明記することが有用となります。
また、受託者視点でより念入りに対処するのであれば、原因調査業務による障害切り分けに基づき、受託者が開発したプログラム以外に障害原因がある場合は保守運用業務の対象外となる旨明記することがポイントとなります。

 

・実施時間（対応時間）を明記すること
【サンプル条項】

第×条 1.受託者がユーザに対して保守運用業務を提供する日時（以下「受付時間」という）は、平日の10時～17時とする。土日、祝日、年末年始、夏季休業日および受託者の休業日は受付時間に含まれない。 2.前項に定める受付時間外や緊急時は、別途ユーザ受託者協議の上で定めた連絡方法により連絡を行うものとし、受託者は、連絡を受けた直後に到来する営業日に受付処理を行い、対応を行う。

 

この条項も、上記の「業務範囲を具体的に明記すること」で解説した内容を独立条項化したものとなりますが、軽視できない条項となります。
ユーザとしては、システムが正常に稼働しない以上、直ちに改修作業を行ってほしいと要求してきます。しかし、受託者としては、24時間365日、不眠不休でユーザからの要求を受付け、改修作業を実施することはおよそ不可能です。
そこで、サンプル条項では、1項で受付対応時間は一定の範囲があることを明記し、当事者間の認識の齟齬をなくすよう明記しています。また2項では時間外で申告があった場合、いつから作業を開始するのかを明記することで、ユーザの不安軽減を図っています。
なお、2項については、緊急度に応じて別途時間外対応を行う、時間外対応を行う場合は別途費用が発生することなどを定めておき、柔軟性を持たせる内容にすることも検討に値します。

 

・作業実施場所を明記すること
【サンプル条項】

第×条 受託者による保守運用業務の遂行は、原則としてユーザ事業所以外の受託者が定める任意の場所より、サーバ内データおよびデータベースへ接続し、状況確認および修正対応するものであって、訪問対応、常駐対応するものではない。ただし、受託者が必要と認めた場合、ユーザ事業所への訪問を行い対応する場合がある。

 

これも上記の「業務範囲を具体的に明記すること」で解説した内容を独立条項化したものであり、ユーザと受託者の認識共有が十分ではないことを理由に起こりがちなトラブルを予防するための条項となります。
ユーザの中には、不具合等が発生した場合、直ちに受託者がユーザの事業所まで駆け付け、その場で復旧作業を行うことを期待している場合があります。一方受託者からすれば、サーバ内にアクセスできれば業務を実施することが可能であり、わざわざユーザの事業所まで行く必要性が乏しく、むしろ無駄な時間となると考えていることが通常です。
自らの認識を相手当事者が認識している保証はどこにもない以上、当たり前だと思う事項であっても、適切に契約書に明文化することを心掛けたいところです。

 

(2)役割分担

【サンプル条項】

第×条 1.受託者は、保守運用業務に関する責任者（以下「業務責任者」という）を本件契約締結後速やかに選任し、その氏名をユーザに書面で通知する。 2.受託者は、保守運用業務に関する作業員（以下「業務従事者」という）を、保守運用業務の遂行に十分な経験・スキルを有するものから選定し、その氏名をユーザに書面で通知する。 3.受託者は、業務責任者又は業務従事者を交代させる場合は、新旧の業務責任者又は業務従事者の氏名をユーザに書面で通知する。 4.受託者は、労働基準法、労働安全衛生法、労働者災害補償保険法、職業安定法その他の関係法令に基づいて、業務従事者に対する雇用主としての一切の責任を負うものとし、業務従事者に対する保守運用業務遂行に関する指示、労務管理、安全衛生管理等に関する一切の指揮命令を行う。第×条 運用保守業務を実施するにあたり、ユーザは次の事項を遵守する。 (1)ユーザが受託者に対して問い合わせを行う場合、受託者が指定するメールアドレス宛に電子メールを送信すること（電子メール以外での連絡は行わないこと） (2)システムを保管する機器が老朽化し、正常な動作維持に支障があることを受託者より通知された場合、ユーザの責任と負担において、当該機器のオーバーホールを実施すること (3)システムを利用することで生成されたファイル、データ等につき、ユーザの責任と負担で定期的にバックアップを行い、保管すること (4)××（以下省略）

 

運用保守業務を実施する場合、ユーザとしては、受託者に全てお任せという認識を持つことが多いのですが、実際のところユーザに一定の協力を行ってもらわないことには業務遂行ができないことが多々あります。
そこで、ユーザと受託者との認識のズレを埋め、円滑に業務遂行ができるようにするためには、当事者がどのような責任と役割を担うのか明記することが極めて重要となります。
上記サンプル条項のうち1つ目は、まず双方当事者の連絡窓口となる者を固定化し、連絡の一元化及び集約化を図ることで、意思疎通の円滑化を図るための条項となります。ただ、ユーザ及び受託者ともに小規模事業者であれば、わざわざ連絡窓口を定める必要はないかもしれません。
次に2つ目の条項ですが、主にユーザが担うべき役割について定めています。連絡手段、保守運用対象外の機器の整備、バックアップといった典型的な事項を定めてみましたが、この内容は当事者間で合意した保守契約・運用契約の内容如何で加除修正が必要となる事項となります。また、上記サンプル条項で定めた以外にも、例えば、ユーザの事業所内で保守運用業務を実施するのであれば、作業場所・設備・回線等の作業環境構築にユーザが協力することを定める、あるいはシステムが他社制作のプログラムに依存している場合であれば、他社制作のプログラムの更新通知があった場合に受託者の承認なく更新を行わない…等々を定めることになります。

 

(3)免責事項

・免責事由を特定し具体的に明記すること
【サンプル条項】

第×条 受託者は、次の各号に定める損害がユーザに生じた場合であっても、ユーザに対して一切の責任を負わない。 ①××（以下省略）

 

現時点で人類が持ち合わせている技術開発力では、24時間365日正常に稼働するシステムを構築することは不可能とされています。このため、受託者として対処できないことは免責事由として具体的に列挙し、ユーザの理解を得る必要があります。
もっとも、ユーザからすれば、決して安くはない費用を負担している以上、何でもかんでも免責事由として明記することに強い抵抗を示すこと、ある意味当然の反応です。
したがって、具体的な取引内容、当事者間のパワーバランス等を考慮して、実情に応じた免責事由を定めることになるところ、次の5つの視点を用いながら検討することが有用ではないかと考えられます。
なお、免責事由を検討する場合、上記(1)「対象外の業務」との関係性を考慮する必要があります。この点、免責事由と上記(1)「対象外の業務」は、ある程度重複することが多いのですが、例えば不可抗力による免責は、対象外の業務として明記することはありません。
したがって、免責事由として特有の規定があることを押さえておく必要があります。

 

①ユーザ側の事情（帰責事由）による免責事項
受託者がユーザをどこまで管理・コントロールするのかという問題はあるのですが、ユーザが受託者に相談することなく勝手に行ったことに対してまで、受託者が責任を負うというのはおかしな話です。
そこで、受託者は、ユーザの責めに帰す事由によって生じた不具合等について責任を負わないこと、これが1つ目のポイントです。
（例）
・ユーザ使用の設備の障害、またはインターネット接続サービスの不具合その他のユーザの接続環境の障害に起因して発生した損害
・受託者が定める手順・セキュリティ手段等をユーザが遵守しないことに起因して発生した損害
・ユーザがレンタルサーバ契約の締結および更新を行う場合において、当該レンタルサーバについて必要な締結および更新ができなかったことに起因して発生した損害

 

②（受託者のコントール下に無い）第三者の事情による免責事項
システムを稼働させるために、受託者以外の第三者が提供するサービス等を利用することがあります。そして、この第三者のミスによりシステムに不具合等が生じた場合、受託者としては如何ともしがたく、責任を負ういわれはありません。
そこで、受託者は、コントロール下にない第三者の責めに帰す事由によって生じた不具合等については責任を負わないこと、これが2つ目のポイントです。
（例）
・ユーザに提供するサーバの管理会社の何らかのトラブルにより、システムが利用不能になったことに起因して発生した損害
・受託者の製造に係らないソフトウェア（OS,ミドルウェア等）およびデータベースに起因して発生した損害
・受託者の製造に係らないハードウェアに起因して発生した損害
・電気通信事業者の提供する電気通信役務の不具合に起因して発生した損害

 

③受託者の対応能力を超える事情による免責事項
いくら受託者がプロフェッショナルとはいえ、保守技術は日進月歩のところがあり、常に最新かつ最高の保守技術で対応することは困難と言わざるを得ません。
ただ、広い免責事由を書き並べてしまうと、ユーザからすれば、“この事業者に任せてよいのか？”という疑義を持たれることになります。
そこで、一方的に受託者有利とならないバランスを考えながら、免責事由を定めること、これが3つの目のポイントです。
（例）
・ユーザに提供するサーバ上にユーザがデータを記録した時間とバックアップを実施・完了する時間との間において生じたデータの消失等により、ユーザが期待する最新のデータを復旧することができないことに起因して発生した損害
・善良なる管理者の注意をもってしても防御し得ない第三者による不正アクセス、不正アタックまたは妨害行為、通信経路上での傍受に起因して発生した損害

 

④緊急避難的な事情による免責事項
自然災害や戦争などの不可抗力による場合が免責事由に該当することは当然のことなのですが、一般的には不可抗力とまでは言えないものの、しかし受託者としてはシステムの正常稼働を諦めざるを得ないという場面が生じます。
そこで、ユーザとのトラブル回避のために、あらかじめ受託者が責任を負えないことを定めておくこと、これが4つの目のポイントとなります。
なお、この類型の場合、ユーザに帰責事由が無いことから、正常稼働しないことへの強烈な不満をユーザは抱くことになるため、何を定めるべきか慎重に吟味する必要があります。
・ユーザに提供するサーバに対しDDoS攻撃等の第三者による攻撃を受けた場合における、ユーザに事前に通知することなく受託者の裁量で行うサーバの停止、ネットワークの切断、その他必要な措置を取ることによって発生した損害
・刑事訴訟法第218条（令状による差押え・捜索・検証）、犯罪捜査のための通信傍受に関する法律の定めに基づく強制処分その他裁判所の命令もしくは法律に基づく強制的処分により発生した損害

 

⑤包括的な事情による免責事項
いわゆるバスケット条項を定めることで、受託者の責任範囲を制限しようとする方法です。
ただ、このバスケット条項の発動場面はかなり限定的と言わざるを得ません。
原則的な対策としては、上記①から④までに記載した視点を考慮しながら、個別具体的な免責事由を明記することですが、保守契約書・運用契約書作成当時ではどうしても想定できない事由が出てきます。
過度な期待はできませんが、一応の対策としてバスケット条項による免責事由を定めておくこと、これが5つ目のポイントとなります。
（例）
・その他受託者の責に帰すべからざる事由によって発生した損害

 

なお、上記は、受託者が損害賠償責任より解放されるという視点で免責事項を解説しましたが、受託者においてユーザに約束しない事由（非保証事由）を列挙し、結果的に責任を負わないという記載方法もあります。
非保証事由を検討する場合であっても、上記①から④の視点で整理すれば対処可能と考えられます。

 

・損害賠償の制限を明記すること
【サンプル条項】

第×条 1.受託者がユーザに対して支払う損害賠償の累計総額は、債務不履行、法律上の契約不適合責任、不当利得、不法行為その他請求原因の如何にかかわらず、本契約に基づいてユーザが支払った報酬相当額のうち1ヶ月分を上限とする。 2.前項は、受託者の故意または重大な過失に基づく場合には適用しない。

 

例えば、ECサイトに搭載されているシステムに不具合等が発生し、取引が一定期間中止してしまった場合、ECサイトを運営するユーザは受託者に対し、中止期間に得られたであろう利益相当額の損害賠償を要求する可能性があります。あるいは正常稼働しなかったことでユーザ側の従事者が長時間勤務を強いられ場合、ユーザはその勤務分の人件費相当額の損害賠償を要求してくる可能性があります。
もちろん、保守業務に不備があった場合、受託者はユーザに対して損害賠償責任を負って然るべきです。しかし、近年の事業活動はシステムに過度に依存しており、ひとたびシステムが異常を起こすと、全ての業務がストップする等して莫大な損害が発生しがちです。一方で、保守契約・運用契約に基づき設定されている保守料金は、このような莫大な損害が発生することを見越して値付けされているわけではありません。このため、システムに関する取引では、受託者の損害賠償責任を何らかの形で制限するべきという考え方が強く主張されています（例えば、独立行政法人情報処理推進機構が公表しているモデル契約書では、この点に関する議論を踏まえて、損害賠償責任の制限条項を設けることを提案しているところです）。
上記サンプル条項では、一般的に定められることが多い、①損害賠償の上限額を設定することで損害賠償責任を制限する、②ただし、受託者に故意重過失がある場合は損害賠償責任の制限を外す、という内容で定めています。
なお、損害賠償条項の定め方に関する詳細については、次の記事をご参照ください。

（参考）
契約書に定める「損害賠償条項」の考え方・チェックポイントを解説

 

(4)金額の設定・計算方法

【サンプル条項】

第×条 保守料は、月額×円（税別）とする。 但し、本契約締結後におけるシステムの改修により、保守運用業務の内容・工数、保守運用業務に要する時間、保守運用業務に従事する人員体制、保守運用業務遂行に必要となる実費、その他の事情の変動により保守運用業務の遂行方法を見直す必要が生じた場合、ユーザ受託者協議の上委託料を変更する。 なお、消費税率の変動があった場合、変動に応じた委託料とする。

 

多くの保守契約・運用契約では、月額定額制が採用されているものと思われます。
ただ、受託者としては、契約締結後の事情変更に伴い、作業量が増加しているにもかかわらず一定額しか請求できないとなると、色々と不満を持つことになります。
そこで、上記サンプル条項では「但書」で変更可能であることを明記したのですが、これだけでは十分とは言い難いかもしれません。
もし可能であれば、月額の保守料に含まれている作業時間や工数を明記し、当該作業時間や工数を超えた場合、ユーザは別途費用を負担すると定めたほうが、追加費用を請求しやすいかもしれません。もっとも、この場合、作業時間や工数の見える化（ユーザに分かるようにする）を徹底する必要がありますので、受託者において手間が増えることを覚悟する必要があります。

 

(5)契約終了事由

【サンプル条項】

第×条 1.システムを構成するプログラムに第三者が権利を有するプログラムが含まれている場合において、当該第三者が当該プログラムの提供又はサポートを中止する場合、受託者は本契約を解約することができる。 2.前項の場合、ユーザは受託者に対し、損害賠償、異議その他何らの申立てを行うことができない。

 

保守契約・運用契約において、一定の契約期間を定めておき、期間満了により契約を終了させるという方法は当然あり得るところです。ただ、状況によっては、契約期間途中であっても、契約を終了させないことには、受託者において適切な業務遂行を担保できないという場面が生じ得ます。
典型的な例として、上記サンプル条項では、受託者においてコントールできない第三者の都合による中途解約を定めています。
この他にも、例えば、システムを構成する機器等の耐用年数が経過し修復困難な場合、当該機器の代用品が見つからない場合、天災地変等で業務遂行体制を構築できず如何ともしがたい場合などを中途解約事由として定めておくことも検討に値します。

なお、中途解約までには至らなくても、一定の事由が発生した場合、受託者は業務の中止又は中断を行うことができること、この場合受託者は何らの責任を負わないことを定めておくことも有用です。

 

 

3.当事務所でサポートできること

当事務所は、複数のベンダの顧問弁護士として活動しており、システム保守契約書・運用契約書の雛形作成はもちろん、ユーザとの関係性を考慮した修正案の提示、契約交渉の進め方に関するアドバイス、業務遂行段階における保守契約・運用契約活用法の提案、保守契約・運用契約に伴うトラブル対応など、様々な事例への対応実績があります。
また、日常的にIT業界に接することで、相応の専門知識も身に着けています。
したがって、専門用語が飛び交う協議においてもスムーズな意思疎通を図りつつ、実務経験により得られた知見及びノウハウ等をフル活用し、ご依頼者様に対して全力でサポートさせていただきます。
システム保守契約・運用契約に関するご相談は、是非当事務所をご利用ください。
＜2023年9月執筆＞
※上記記載事項は弁護士湯原伸一の個人的見解をまとめたものです。今後の社会事情の変動や裁判所の判断などにより適宜見解を変更する場合がありますのでご注意下さい。