契約不適合と保守契約と脆弱性

1 脆弱性と保守契約

2019年9月のエントリで、「脆弱性と債務不履行（東京地裁　平30.10.26）」「脆弱性と瑕疵の間に（再考）」があります。そこでは、脆弱性による不具合と契約との関係を考えました。そこでは、むしろ、契約の本旨と脆弱性との関係を検討していて、脆弱性による不具合というのは、契約の本旨にしたがっている場合でも発生することがあることを論じました。

こんな図を使って説明しました。

要するに契約時を考えて、その時点において、契約の趣旨に適合しない場合のみ、契約不適合責任が認められて、それ以外については、契約上の責任が出てきませんということになります。そのような場合には、保守契約の出番になるわけです。

でもって、実務的にもっとも問題になるのが、保守契約ともともとの開発契約による修補請求との関係ということができるかと思います。そこで、保守契約の概念/範囲、契約不適合責任との関係をまとめたいと思います。

2 保守契約の概念/範囲

この点についての基本文献として、「情報システム・モデル取引・契約書～（受託開発（一部企画を含む）、保守運用）〈第二版〉」をもとに議論したいと思います。ちなみにリンクは、こちらです。以下、モデル契約書といいます。あと、この点について、興味深い論考として、大谷和子「ベンダが知っておきべきシステム開発契約における民法改正の影響」(BUSINESS LAW JOURNAL 2019年12月号)があります。

2.1定義

保守契約の概念について見ていきます。保守契約とは何ですか、という問題になりますが、モデル契約では、保守契約のモデルを公表しています。同モデル契約48ページでは、

「保守」は、情報システムやソフトウェアの現状を業務及び環境に適合するように維持管理を行う工程である。

とされています。

2.2 含まれるべき作業内容

モデル契約書194ページは、保守業務又は運用業務の委託に関する個別契約書(サンプル)を公表しています。そこでは、業務内容として以下の項目をあげています。

（１）本件業務実施状況管理
ａ．案件管理
ｂ．インシデント管理
ｃ．問題管理
ｄ．変更管理
ｅ．リリース管理
ｆ．構成管理
ｇ．定例報告
（２）業務アプリケーション本番処理検証
（３）業務アプリケーションの改良
乙は、本件業務開始後、動作環境等が変化した場合においても対象アプリケーションを使用できるように保ち続けるための修正及び対象アプリケーションの性能又は保守性を改善するための修正を実施します。
（４）業務臨時処理
（５）トラブル対応
ａ．トラブル対応設計
ｂ．トラブル対応実施
ｃ．トラブル対応検証
（６）質問対応
（７）業務アプリケーションの予防保守
ａ．業務アプリケーションの予防保守設計
ｂ．業務アプリケーションの予防保守実施
ｃ．業務アプリケーションの予防保守検証
（８）システム／運用改善提案

となります。そして、これらについて、サービスレベル（達成目標の数値をいい、以下「目標値」という。）を設定し、当該サービスレベルを達成できるよう努めるということになります。

含まれない作業

では、保守として含まれないものは何かというと

⑴甲の要求による本件ソフトウェアの改変又は機能追加
⑵乙又は乙の指定する者以外の者による本件ソフトウェアの修補,改変,機能追加その他これらに関連する作業を行ったことにより生じた障害の修補
⑶他のソフトウェア(乙により修補,改変又は機能追加された部分は除く。)又は本件搭載装置の不具合,故障等を原因として生じた障害の修補
⑷甲の責に帰すべき事由により生じた障害の修補
⑸天災地変その他甲乙いずれの責にも帰すことができない事由により生じた障害の修補

になります。これについては、(株)NTTデータ著「システム開発を成功させるＩＴ契約の実務」240ページの表現です。

3 契約不適合責任との関係

3.1 契約不適合責任の概念

ここで契約不適合責任との関係をみます。

契約不適合責任に関する民法562条は、改正民法562条では、「目的物が種類,品質又は数量に関して契約の内容に適合しないものであるとき」(以下「契約不適合」という)に、売主が責任を負うこととされています。そして、改正民法下では損害賠償請求および解除(改正民法564条)に加えて履行の追完(修補・代替物の引渡請求等)(同562条)および代金減額請求(同563条)が認められています。

モデル契約書だと

（契約不適合責任）
第29条　前条の検収完了後、納入物についてシステム仕様書との不一致（バグも含む。以下本条において「契約不適合」という。）が発見された場合、甲は乙に対して当該契約不適合の修正等の履行の追完（以下本条において「追完」という。）を請求することができ、乙は、当該追完を行うものとする。但し、甲に不相当な負担を課するものでないときは、乙は甲が請求した方法と異なる方法による追完を行うことができる。

となっていて、ソフトウェア開発業務において生じた「システム仕様書との不一致（バグも含む。）」を契約不適合と定義した上で、契約不適合が発見された場合には、ベンダはその修正等の追完義務を負うことを規定しています(105ページ)。なお、外部設計書を作成する場合については、同98ページです。

この解説部分では、いくつか興味深い記述があり、

セキュリティ要件をシステム仕様としている場合には、「システム仕様書との不一致」に該当し、本条の「契約不適合」に含まれる。
「当該契約不適合によっても個別契約の目的を達することができる場合であって、追完に過分の費用を要する場合、乙は前項所定の追完義務を負わないものとする。」のに関して、「追完に過分の費用を要する場合に無償での追完をベンダに求めるのは酷であること」による。
モデル契約では、「権利行使の期間制限の起算点をユーザが契約不適合を知った時からとすると、ユーザにとっての検査の位置づけが軽くなり、適切な検査を行うことについてのインセンティブが失われることから、本モデル契約では、民法上のデフォルトルールにかかわらず、契約不適合責任の期間制限の起算点を検収完了時という客観的なものと」するのが妥当と判断した
当該期間内にユーザが契約不適合に基づく権利行使をするためにとる行動は、民法第637条第1項に準じて、契約不適合がある旨をベンダに通知することとしている。なお、改正民法の立案担当者によれば、この通知は、単に契約不適合がある旨を抽象的に伝えるのみでは足りず、細目にわたるまでの必要はないものの、契約不適合の内容を把握することが可能な程度に、契約不適合の種類・範囲を伝えることを想定しているとされており（前掲筒井＝村松285頁）、ソフトウェア開発の局面でも、ベンダが契約不適合の内容を把握できるように、契約不適合の内容や当該契約不適合の発生した状況（画面等）を具体的に示すことが求められる(110ページ)。

そうだとすると、検収後に、不具合が発生して、これに対して修補してくれという話が出てきます。この場合、契約不適合なのか、保守契約による対応なのか、という問題になります。

3.2 契約不適合責任の概念

これらの記述にならんで、モデル契約書109頁では、

契約不適合とは言えない不具合への対応も対象とする保守との役割分担をどうするのか

という記述も見受けられます。この役割分担について、さらに詳しくみていくことにします。これについて大谷論文ですと

例えば、ソフトウェアの稼働環境が第三者のプロダクトのバージョンアップやアップデート等により変動し、ソフトウエアがそのままでは使用不能となるような事態が考えられるが、それが不適合に該当するかは契約の内容次第である

とされています。

大谷論文だと「開発契約モデル」・「保守契約モデル」を二つをあげています。開発契約モデルについては

10年間分の不適合対応のコストを開発コストとして受領してしまったベンダは、保守契約の見積もりを減額しなくてはならないだろう。

としており、これに対して

不適合責任をすることを前提とした開発コストの見積もりをした場合、保守契約において不適合対応のコストを折り込むことが認められる

としています(保守契約モデル)。

一般的にどちらなのか、という点については、大谷論文は、結果をだしません。

10年間は、両社にとって未知の世界であることを認めるべきではないか

となっています。理論的には、当事者間の合意について、3つのモデルにわけて考察することができるといえると思われます。

検収後の修補の根拠は何であるのか、ということにも関連して、

A) 保守契約モデル

これは、契約不適合か、どうかは、検収の時点において、仕様書に適合しているか、という観点から判断されて、それ以降に発生する不具合については、すべて保守契約でもって対応する、というモデルになります。検収後における修補の手間を産出し、それによって保守契約として締結することによって開発費自体を低減することが可能であり、また、保守契約として工数を算定しやすいということになるかと思います。これに対しては、もともと、民法で定められている契約不適合責任を保守契約によって限定するのであれば、その旨の明示が必要であるという批判がなされうるものと考えられます。

B) 中間モデル

これは、システム仕様書との不一致によって生じる不具合か、それ以外の不具合か、というのを判断して、システム仕様書との不一致によって生じる不具合については、契約不適合責任の問題であり、それ以外(たとえば、上記の第三者のプロダクトのバージョンアップやアップデート等により変動し、ソフトウエアがそのままでは使用不能となるような事態)については、保守契約で対応するという考え方です。これに対しては、特段の限定がなければ、10年間は、契約不適合責任の追及を受けることになるが、それは、当事者(とくにベンダーにとって)の合理的な意思解釈といえるのか、ということになります。

c)開発契約モデル

これは、ソフトウェアの稼働環境が第三者のプロダクトのバージョンアップやアップデート等により変動し、ソフトウエアがそのままでは使用不能となるような事態であっても、開発者は、そのような事態に対応する義務が、存在するという考え方になります。このような考え方でも、脆弱性については、セキュリティ要件をシステム仕様としており、しかも、その期間を明確に定めているということがない限りは、契約不適合責任の問題ではなく、保守契約の問題ということになるだろうと考えられます。このような考え方については、第三者のプロダクトのバージョンアップやアップデート等により変動し、ソフトウエアがそのままでは使用不能となるような事態であっても開発者が対応すべき義務を負い、かつ,、そのような義務は契約で開発費用に折り込まれていると考えるのは、さらに多数のハードウェア、ソフトウェアを使用してシステムを構築する関係上、作成したプログラムに一定の不具合が混入することが避けられないというソフトウエア開発の実態から考えると、あまりにも開発者に対して想定し得ない対応を強いる可能性が存在すると批判されるものと考えられます。

3.3 保守契約での対応について

上述のように、契約不適合との関係が不明確なので、一般には、保守契約や開発契約で、両者の関係を明確にするようにということがいわれています。

このような立場から、論じてるのは、「システム保守契約・運用契約書作成に際し、特に意識したい条項について解説」や「システム保守と瑕疵担保責任の関係性」などです。

結局

①瑕疵担保責任に基づく修補請求できる期間はこちらを優先し，システム保守契約に基づく保守はその期間経過後からにする方法

②瑕疵担保責任に基づく修補請求が可能な期間は，システム開発段階に原因がある不具合とそれ以降に生じた原因によって生じた不具合とを区別する方法

③瑕疵担保責任に基づく修補義務を排除し，全てをシステム保守契約に基づく保守に委ねる方法

のいずれにするかを検討し，契約書の中で明記しておくことが良いでしょう。

とされることになります(これは、上記「システム保守と瑕疵担保責任の関係性」の表現)。まさに当事者間によって、合意されるべき事項であるかと思いますが、モデル契約書においても、その点について、明確に論じられているところではないことは、上でみたとおりです。

3.4 開発契約と保守契約の一体的な締結について

ところで、3.3の関係を明確にするというのであれば、むしろ、開発契約と保守契約の一体的な締結をすることが前提になります。この点について論じられているのが、公正取引委員会の「6　ソフトウェアメーカーによる保守契約の義務付け」の記載(リンクは、こちら)です。

この相談事例は、

個別に当該ソフトウェアAのアップグレード版を販売する際に保守契約を締結することを義務付けること(以下「本件取組」という。)を検討

しているというもので、開発契約と保守契約との一体というものではないのですが、保守契約によるアップグレードが顧客にとって有益と考えられることや保守契約を締結した上でアップグレード版の提供を受ける方が,従前よりも費用を削減することができるようになるため,顧客にとって不利益を与えることには該当しないこと、から優越的地位の濫用にはならないとされています。

もっとも、開発契約と保守契約の一体的な締結というのは、抱き合わせ販売の違法性の問題の観点から検討されます。

例えば、牧野和夫「初めての人のための英文・和文ＩＴ契約書の実務」(93ページ)は、

ライセンスが永久ライセンスの場合に,バグの修正のため改良版を保守契約で提供するので,保守契約を締結していないと改良版が使用されずに問題が発生することになります。ライセンス契約と保守契約をセットにする技術的な合理的理由がありますので,原則として独禁法の不公正取引行為(抱き合わせ販売)には当たらないでしょう。

とコメントしています。もっとも、抱合せ販売というと東芝エレベーターサービス事件が有名ですが、

主たる商品の市場における有力な事業者による抱き合わせ行為を通じて,従たる商品の市場において市場閉鎖効果が生じる場合

でなければ、特段の問題はおきないということになります。(個人的には、開発・保守契約と一緒にしてしまえば、そういう問題はおきないだろうという突っ込みもできたりします)