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

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

本連載企画では、前回から、2020年12月に経産省・IPAが連名で公表した「情報システム・モデル取引・契約書」第2版（以下、「モデル契約第2版」といいます）の主な改訂ポイントを取り上げております。

モデル契約第2版の主な改訂ポイントは、「A セキュリティ」、「B プロジェクトマネジメント義務及び協力義務」、「C 契約における「重大な過失」の明確化」、「D システム開発における複数契約の関係」、「E 再構築対応」の5つとなります。

今回からは、「B プロジェクトマネジメント義務及び協力義務」につき、解説してまいります。

「プロジェクトマネジメント義務及び協力義務」の改訂点

結論から申し上げると、「モデル契約第2版」では、プロジェクトマネジメント義務と協力義務につき、従来のモデル契約より新たに一般的な規定を設け、改訂を行う、ということは見送られております。¹

ただ、2007年の「情報システム・モデル取引・契約書」（「モデル契約2007年版」）が発表された後に、システム開発紛争における「プロジェクトマネジメント義務と協力義務」という枠組で、裁判例がある程度蓄積されてきたことを受け、解説の内容が大幅に刷新されております。

また、「プロジェクトマネジメント義務と協力義務」の問題から派生して、「プロジェクトの変更協議不調時に、ベンダにも解約権を認めるべきではないか」というポイントにつき、第38条（変更の協議不調に伴う契約終了）で、一定の事由がある場合にベンダの解約権を認める条項例が、B案〔オプション条項／従来の38条（A案）との選択〕として追加されています。

裁判例における「プロジェクトマネジメント義務と協力義務」の内容

「プロジェクトマネジメント義務と協力義務」という言葉は、民法その他の法律に規定が置かれているわけではないのですが、システム開発紛争が裁判で争われる事になった場合に、ベンダ／ユーザのいずれに（もしくは両当事者にどの程度）責任があったのかを分析するための、いわば「フレームワーク」として用いられてきた概念です。

代表的な裁判例²の判示を取り上げてまとめると、以下のようになります。

ベンダのプロジェクトマネジメント義務とユーザの協力義務の議論がされる場合には、上記の代表的な裁判例に基づく整理が参照され、この枠組をベースにベンダ／ユーザ双方の義務違反を整理していくことが多かったのではないか、というように思われます。また、プログラム開発委託契約につき、上記の裁判例等を参照しつつ、ベンダのプロジェクトマネジメント義務／ユーザの協力義務を、契約書の条項に落とし込むという工夫・提案も見られたところです。³

上記の代表的な裁判例による整理は、ベンダとユーザとの間に「情報の非対称性」が一定程度存在することを前提としています。
すなわち、ベンダにはシステム開発のプロとして十分な知識が存在するのに対し、ユーザにはそのような知識が往々にして十分ではありません。逆に、当該システムが取り扱うユーザの業務については、ユーザ自身が精通されている一方、ベンダ側にはそのような業務知識が必ずしも備わっているわけではない、という事もあげられます。

このような整理は、一般論としては一定の合理性が認められます。そのため、「ベンダのプロジェクトマネジメント義務とユーザの協力義務」という議論の立て方をする場合に、枠組みを整理する先例として、まずは参照されることが多かったのだ、と理解しています。

もっとも、上記のような「情報の非対称性」が実際にどの程度存在するのかは、実際の案件ごとに異なってきます。また、開発対象となるシステムの内容や、紛争が問題となるステージの違いによっても、ベンダがなすべき義務、ユーザがなすべき義務の内容はそれぞれ変わってくる、というのが実態です。

たとえば、同じくベンダのプロジェクトマネジメント義務とユーザの協力義務が問題となった近時の裁判例では、銀行の業務全般をつかさどる次期情報システムの導入が頓挫した事案において、（当該時点において）当初予定していた開発費用、開発スコープ及び開発期間内に収めてシステムを開発することが不可能であることが明らかとなり、開発計画を続けてシステムを完成させるのであれば、開発費用、開発スコープ及び開発期間のいずれか、あるいはその全部を抜本的に見直すことにするか、それが困難であるならば、開発そのものを断念するかも含めて決定しなければならない局面に至ったという認定のもと、以下のような判示をしています。⁴

この裁判例では、以上のように述べた後、当該義務が発生したと認定された、次期業務システムの開発に関する最終合意が行われた時点より後の契約に限り、ベンダに対してのプロジェクトマネジメント義務違反を理由とした損害賠償を認めています。⁵上記のような認定の場合においては、ベンダにプロジェクトの中止提言義務までがある、とした点に特色があります。⁶

このように、「ベンダのプロジェクトマネジメント義務とユーザの協力義務」といっても、その内容は問題となるプロジェクト毎に大きく異なり得ます。そのため、「モデル契約第2版」では、プロジェクトマネジメント義務／協力義務につき、一般的な規定を設けることは見送られました。⁷

若干の考察

一定規模を超えたシステム開発のプロジェクトでは、全体を一括請負で締結するのではなく、各システムやその開発フェーズ毎に個別契約を締結し、後続の個別契約締結段階で再度見積を実施し、業務範囲を明確にしていくことが一般的、とされています。

大規模なシステム開発では、プロジェクトそのものの規模が大きく、開発期間も長期にわたります。そのような場合に、1年後、あるいは数年後のプロジェクトの状況を正確に予測し、見積の根拠とすること自体にはそもそも限界があります。したがって、多段階契約と再見積プロセスを前提としたこのような慣行は、ある程度合理的なものといえる、と考えています。「モデル契約第2版」も、かかる多段階契約と再見積プロセスを前提として採用しています。⁸

ただ、多段階契約方式を採用すると、契約単位が細かく分かれることになってしまうため、「システムの完成」というプロジェクトの目標自体が達成されているかどうかを、契約全体を俯瞰した観点からとらえ直す必要がどこかで生じます。

多段階契約を採用する大規模プロジェクトに関しては、かかる特性を踏まえ、プロジェクトマネジメント義務／協力義務の内容を、個別案件毎に明確化せざるを得ないか、と考えています。個別案件での検討を進めていった結果、ある開発フェーズにて必要がある場合には、個別契約において、当該フェーズにおけるリスクやその進め方を踏まえた具体的なプロジェクトマネジメント義務／協力義務についての条項を検討するのも一案か、と思われます。⁹

おわりに

本稿では、いわゆるプロジェクトマネジメント義務／ユーザの協力義務につき、「モデル契約第2版」における条項改訂の概要と、裁判例におけるこれらの義務の内容を解説させていただきました。

次回以降では、「モデル契約第2版」で紹介されているプロジェクトマネジメント義務／協力義務についての裁判例の内容に今少し踏み込んだ後、第38条（変更の協議不調に伴う契約終了）のオプション条項〔一定の事由がある場合にベンダの解約権を認めるB案〕の内容について触れていくことができれば、と考えています。

以上

▼注釈

1. なお、従来のモデル契約では、第13条（プロジェクトマネジメントの責任）という条項が設けられていたのですが、本条文の内容はユーザがシステムの発注に際し複数のベンダに分割発注している、いわばマルチベンダの場合における調整についてのものでした。「モデル契約第2版」では、同条は小見出しを「マルチベンダの調整等の責任」として、プロジェクトマネジメント義務／協力義務の話とは違うテーマの内容であることが、より明確になるよう改訂されています。
2. 東京地判平成16年3月10日判例タイムズ1211号129号。
3. 阿部・井窪・片山法律事務所編「契約書作成の実務と書式－企業実務家視点のひな型とその解説」第2版（2019）407頁、427-428頁等参照。
   
4. 東京高判平成25年9月26日金融商事判例1428号16頁。
5. 第一審の東京地判平成24年3月29日金融法務事情1952号111頁で認容された74億円から、控訴審では41億円と、損害賠償の金額が大きく減額されています。
6. ただ、上記の裁判例については、「上記裁判例以外にはベンダの中止提言義務に言及した裁判例はなく、この点については今後の裁判例の判断の動向を確認する必要がある。」とされている（経済産業省・IPA「～情報システム・モデル取引・契約書～（受託開発（一部企画を含む）、保守運用）〈第二版〉P123）点には注意が必要です。
7. 経済産業省・IPA 「～情報システム・モデル取引・契約書～第二版の公表にあたって」P6参照。
8. 前掲注6 経産省・IPAのP4参照。
9. システム開発における複数契約の関係については、後日別稿にて解説・検討させていただければ、と思います。