DX対応・民法改正で変わる情報システム取引に関する契約⑦

株式会社シナプスイノベーション法務室です。

本連載企画では、DX（デジタルトランスフォーメーション）の進展を受けて、ソフトウェア・システム開発における契約形態も変化しつつある、ということを解説させていただいております。本連載の第4回より、2020年12月に経産省・IPAが連名で公表した「情報システム・モデル取引・契約書」第2版（以下、「モデル契約第2版」といいます）の主な改訂ポイントを取り上げております。
前回は、「ベンダのプロジェクトマネジメント義務とユーザの協力義務」の内容につき、モデル契約第2版の解説や、そこで引用されている裁判例を手掛かりに整理を試みてみました。
今回は、この「ベンダのプロジェクトマネジメント義務とユーザの協力義務」との関連で、ユーザとベンダ間での契約内容等の変更協議が不調となった場合につき、一定の場合にベンダの解約権を認めるオプション条項B案の内容につき、解説してまいります。

契約の中途終了時の解約権
– 民法上の原則と、オプション条項の必要性

民法上の原則

契約事の基本として、ユーザ・ベンダ間でのシステム開発において契約書等に特に定めなかった事項については、民法の規定が適用されることになります。

モデル契約第2版は、システム開発を大きく①要件定義、②外部設計、③ソフトウェア開発、④ソフトウェア運用準備・移行支援の4つの工程に分けています。これらの4つの工程は、各工程で実施する業務の内容の特質や責任分担の観点から、請負契約と準委任契約のいずれかに分類されます。

民法の定めでは、準委任契約では契約中の中途解除を各当事者がいつでも契約を解除することができるとされる一方、¹請負契約においてはユーザはベンダが仕事を完成しない間はいつでも損害を賠償して契約の解除をすることができることとされ、²ベンダからの解除・解約権は、その旨の特約等がない限り、一般的には生じないものと考えられています。

従前の経産省モデル契約やモデル契約第2版 第38条 A案では、ユーザによる中途解約に関しては上記の請負契約の方に平仄を合わせ、ベンダによる解約権については特に定めを置かないようにしております。³

オプション条項の必要性

民法の定めやモデル契約第2版 第38条 A案によった場合、ユーザ・ベンダ間での契約内容等の変更協議が不調だったときは、債権債務の内容が変更されなかった以上、ベンダは当初の合意内容通りの開発業務を実施して債務を履行すべし、ということになります。

もっとも、契約内容等の変更協議が行われるような事態が生じた場合には、契約当初に両当事者間で合意されていた開発スコープ・費用・納期・品質のバランスが失われてしまっています。そのような中で当初の契約通りの債務の履行をなお実施しなければならないとすることは、ベンダにとり過剰な負担ともなりうる自体も想定されます。⁴

また、ベンダのプロジェクトマネジメント義務が争点となったとある裁判例⁵では、「当該時点において当初予定していた開発費用、開発スコープ及び開発期間内に収めてシステムを開発することが不可能であるであることが明らかとなり、開発計画を続けてシステムを完成させるのであれば、開発費用、開発スコープ及び開発期間のいずれか、あるいはその全部を抜本的に見直すことにするか、それが困難であるならば、開発そのものを断念するかも含めて決定しなければならない局面に至ったことを認定した上で、ベンダは、これらの状況を説明し、このような危機を回避するための適時適切な説明と提言をし、仮に回避し得ない場合にはシステム開発の中止を提言する義務があった」とされています。⁶このような議論を受け、一定の場合にはベンダにも解約権を認めるべきではないかという観点から、モデル契約第2版38条のB案が、オプション条項として準備されました。

オプション条項B案の内容

モデル契約第2版第38条（変更の協議不調に伴う契約終了）B案の第3項、同第4項において、ベンダによる解約権が発生するまでの流れを大まかに図示すると、以下のようになります。

上記の手続きの流れや要件・考慮要素につき、留意すべき事項は以下の通りです。

変更管理手続

そもそもの前提として、ベンダによる中止提言義務や解約権の発生等についての検討は、変更管理手続（モデル契約第2版 第37条）の中で行われるという想定になっています。

モデル契約においては、開発スコープや費用、納期、品質等の変更が必要な場合の解決プロセスとして変更管理手続を置いている以上、ユーザ・ベンダ双方とも、変更管理手続に乗せるべき事象が発生していないか、プロジェクトの状況を注視し、判断する必要があります。ユーザ・ベンダ双方のプロジェクト推進体制と運用状況も問われることになります。

中止提言義務の発生要件に該当する状況

モデル契約第2版解説で「個別契約を続行することが困難となる事情」にあたる状況としては、以下のようなものが例示されています。⁷

1. 1. ある時点において、当初予定していた又は途中で合意の上変更した開発費用、開発スコープ及び開発期間内に収めてシステムを開発することが不可能である状況（外部環境等の変化によってこのような状況に至ることもありうる。）の中で、前条の変更協議によって見直しを図ったものの、当該協議が調わない結果不可能な状況を払拭できないといった状況
   2. ユーザからの追加開発要望についてそれを受け入れてしまうと、やはり当初予定していた又は途中で合意の上変更した開発費用や開発期間で収まらなくなることが想定され、第37条［引用者注: 変更管理手続］の変更協議による要望内容の見直しを経ても、その状況が解消されないといった状況

      「個別契約を続行することが困難となる事情」に該当する状況は他にも考えられますが、中止提言義務の有無の判断に当たっては、実際のプロジェクトの状況と、上記のモデル契約解説での例示を対比する事が有益である、と考えられます。

ベンダによる解約権が発生するための「合理的な理由」の有無

「個別契約を続行することが困難となる事情」があっても、ユーザが「合理的な理由」を示せばベンダによる解約権の発生は制限されることになります。
モデル契約第2版解説では、「個別契約を続行することが困難となる事情」に至った両当事者の帰責性については、この「合理的な理由」の有無の要件において検討することを想定しています。
ベンダの解約権発生が制限される「合理的な理由」に該当する場合としては、同解説では以下のようなものがあげられています。⁸

1. 1. 1. 「個別契約の続行が困難となるような事情」を招来したことがもっぱらベンダの責めに帰すべき事由による場合
         1. ベンダが、変更協議においてユーザ都合の追加機能が発生していると主張しているが、システム仕様書には、該当する機能が記載されている場合
         2. ユーザによる前条の変更提案が追加開発を伴うものであるが、それがもっぱらベンダによる仕様の検討が不十分だったことによって生じたものである場合
         3. ユーザから変更に関わる十分な情報提供がされたにもかかわらず、ベンダが当該情報に基づき適切な見積を行わなかったために、提示した変更のために要する費用またはそれに要する工数、あるいは作業期間の延長期間が、従来の個別契約に示されていた見積と比較して想定以上に高額である（あるいは工数が多い、期間が長い）場合
            
      2. 「個別契約の続行が困難となる事情」を招来したことがもっぱらベンダの責めに帰すべき事由によるとはいえなくとも、なお「合理的な理由」が認められ得る場合
         1. ユーザによる前条の変更提案が追加開発を伴うものであるが、当該開発が必要となったことについてユーザとベンダの双方に一定の帰責事由が認められる場合であるにもかかわらず、ベンダがユーザに対し当該追加開発の費用全額の負担を要求し、その減額に応じない場合
         2. ベンダが提示した変更提案の内容が短期間に甚だ多くのSEを投入するなど、ユーザから見てもベンダのプロジェクトマネジメントが機能しないと判断せざるを得ない場合
         3. ベンダが提示する変更提案の内容が当該時点におけるマーケットスタンダードに照らして高額（あるいは工数が多い、期間が長い）であり、その差異の理由についてベンダが合理的な説明を行っていない場合

実務対応における若干の検討

モデル契約第2版の第38条オプション条項B案は、契約の中途解約についての権利はユーザ側に（のみ）発生するのが原則であることを堅持しつつ、例外的にベンダ側にも解約権を発生させるよう、要件を整理して特約事項を設けたものです。

この例外要件の内容については上述の通りですが、解約権発生の前提としての中止提言義務を生じさせる「個別契約を続行することが困難となる事情」や、ベンダへの任意解約権の発生障害事由としてユーザが示す「合理的な理由」といった規範的な要件については、実際のトラブル・紛争の場面においてそれぞれの要件を満たすのかどうかにつき、ユーザ・ベンダ双方の認識・見解が一致しない、という事態も十分に考えられます。

上記のような規範的な要件を充足しているかどうかを考えるにあたっては、システム開発への理解や実際のプロジェクトの進捗状況の把握に加え、具体的な事実がそれぞれの要件に対しどのように位置づけられ、評価されるのか、といった法的判断も必要となってきます。こういった法的評価や判断までに関しては、当事者間の交渉だけでは「水掛け論」に終始してしまう危険も高いでしょう。

このような事態を防止し、本オプション条項を実質的に機能させることも含めてトラブルの解決を図る、という意味では、和解による紛争解決⁹や仲裁¹⁰において、システム開発紛争の実態やそれらについての法的知見を持った裁判外紛争解決手続（ADR）を活用すること¹¹も、あわせて視野に入れておくべきかと考えます。

おわりに

本稿では、「ベンダのプロジェクトマネジメント義務／ユーザの協力義務」に関連し、変更協議が不調だった場合のベンダの解約権について規定した、モデル契約書第2版 第38条 B案 オプション条項の内容につき、解説させていただきました。
次回からは、モデル契約第2版の解説をいったん離れ、近時ますます導入が進んでいる「クラウドサービス」につき、法的なポイントにつき検討できれば、と考えております。

▼注釈

1. 民法 第651条第1項。
2.  民法第641条。
3. モデル契約 第2版 第38条A案 参照。
4. 経産省モデル契約2007年版を修正し、変更協議不調時にベンダ側にも解約権を認める条項例として、㈳電子情報産業協会（JEITA）「ソフトウェア開発モデル契約の解説」P169～172[2008]参照。なお、「JEITAソフトウェア開発モデル契約及び解説（2020年版）」P94~95においても同様の条項は維持されている。
   
5. 東京高判平成25年9月26日金融商事判例1428号16頁（スルガ銀行対日本IBM銀行事件）。
6. 引用は、モデル契約第2版解説P123より。下線は本項執筆者による。
7. 下記a., b.の例示は、モデル契約第2版解説P123より抜粋。
8. モデル契約第2版解説P124参照。
9. モデル契約第2版 第55条第3項および同条第4項。
10. モデル契約第2版 第56条A案。
11. たとえば、㈶ソフトウェア情報センター内「ソフトウェア紛争解決センター」の中立評価や和解あっせん、仲裁手続など。