ディスカッションポイント
１ 本事案の検討順序（1） 本件個別契約 13～15 の履行不能① 履行不能の認定② 本件システムの完成不能による履行不能の成否（2） その他の各個別契約の履行不能の成否（3） 本件個別契約 13～15 の履行不能を理由とするほかの契約の解除の可否
本件個別契約 13～15 についての帰責事由の有無（4） 損害の範囲① 責任制限条項と信義則② 責任制限条項と重過失免責③ 責任制限条項と第三者との契約（5） 原告ら側の過失（過失相殺の成否）（6） 不法行為の成否
２ 履行不能の成否（１） 本事案における「履行不能」①

本件開発の目的・スケジュール
原告野村証券の個人向け商品のための情報システム全体を全面的に刷新する「リテール IT」プロジェクトの一環であり、バックオフィス関連（事務・会計・管理等）のシステムを「THE STAR」と呼ばれる新システムに変更するに併せ（平成 25 年 1 月 4 日稼働開始）、老朽化した投資一任口座サービス用の既存情報システムを変更するためのもの。
平成 25 年 1 月 4 日に STAR と連携して同時に稼働させる②

早期段階からのスケジュール遅延③

前工程までのテストが十分でなかったと分析される障害が多発し、STAR との同時稼働開始にスケジュール及び品質のリスクがあるとベンダから指摘④

リスク報告を受け、総合テストを中止してコンティンジェンシー・プランを発動

1

Q： このような事情のもとで、ユーザ側が、一方的な自らの通知により「履行不能」を生じさせることができるとした、「履行不能」の認定については妥当と考えるか？その判断をする上で、特にどの点が重要と考えるか。
【ゼミにおける意見等】
本事案では、客観的に見てユーザ側がプロジェクトを中止することが妥当であったと考えられるため、上記「履行不能」の認定は妥当と考えられる。
本事案のようにユーザ側に差し迫った事情がある場合は、一方的な自らの通知による「履行不能」が認められやすいのではないか。

（２）多段階契約における個別契約におけるシステムの完成義務① 各個別契約において、本件システムの完成義務を負うか【判旨】
確かに、コンピュータ・システム開発においては、不可避的に発生する不測の事態を想定し、これに対応しつつ、試行錯誤を経ながら進行するのが通常であるため、ユーザとベンダ双方のリスクマネジメントの機会を確保する観点から、工程ごとに段階的に個別契約を締結する手法が採られていることが認められる（乙１１８、乙１２４）。
実際に、本件開発業務においても、カスタマイズ量の著しい増大や要件定義作業の遅延、ドロップ２の分割出荷といった開発状況に応じ、当初予定されていなかった概要設計最適化フェーズのための本件個別契約８や、基本設計準備フェーズのための本件個別契約９、ドロップ２のための本件個別契約１５が締結されているのであり（前記認定事実４（３）ア、（５）ア及び５（３）イ）、本件各個別契約がフェーズごとに段階的に締結されてきたのは、様々な変更を織り込みつつ進行する開発状況に応じて、リスクマネジメントの観点から、段階ごとに次の工程の在り方を検討し、当該次の工程に必要・適切な債権・債務を契約ごとに個別具体的に定める趣旨に基づくものと解される。
そして、ＳＴＡＲと連携した稼働開始までには、本件各個別契約における債務のほかに、移行に関わる作業など、更に契約上の債務として個別具体化されるべき種々の作業が必要になると推認することができるから、被告が、本件各個別契約に基づき、直接、ＳＴＡＲと連携して稼働する本件システムを完成させるべき契約上の債務を負っていたとまでは解されない。
また、本件開発業務について、本件個別契約５～１７を包含し、本件システムの完成やＳＴＡＲと連携した稼働開始を直接の法的義務として約するような包括的契約が締結さ2れていた様子も見当たらない。
もちろん、平成２５年１月４日のＳＴＡＲと連携した本件システムの稼働開始は、本件個別契約５～１７の共通の目的であるから（前記（１））
、被告の本件個別契約５～１７における個別具体的な債務は、上記契約目的の達成のために履行されるものではあるが、以上によれば、被告が、ＳＴＡＲと連携して稼働する本件システムを完成させるべき債務を、本件各個別契約上の債務として負っていたと認めることは困難である。
（３）履行不能を理由とする解除
Q：多段階契約において、仕事の完成がなされなかった場合に、過去になされた個別契約の解除が認められない判断について賛成か、反対か。
【ゼミにおける意見等】
多段階契約であるにもかかわらず、基本契約を締結していないことに疑問。
大規模開発案件であったことから、ベンダのリスクヘッジ策として基本契約を締結していないのではないか。
基本契約の有無というよりは、システムの稼働を約していたか否かが重要なのではないか。
スルガ銀行対日本 IBM 事件のような最終合意書があれば、システムの稼働を約していたと認定されるのではないか。本事案においては、そのような最終合意書までは作成されていなかった。
（参考判例）
契約目的の密接関連性➢

最判平成 8 年 11 月 12 日（事案）
いわゆるリゾートマンションの売買契約と同時にスポーツクラブ会員権契約が締結された場合にその要素たる債務である屋内プールの完成の遅延を理由として買主が右売買契約を民法 541 条により解除することができるとされた事例（判旨）「同一当事者間の債権債務関係が、その形式は甲契約及び乙契約といった 2 個以上の契約からなる場合であっても、それらの目的とするところが相互に密接に関連付けられていて、社会通念上、甲契約又は乙契約のいずれかが履行されるだけでは契約を締結した目的が全体としては達成されないと認められる場合には、甲契約上の債務不履行を理由に、その債権3者が法定解除権の行使として甲契約と併せて乙契約も解除することができるものと解するのが相当である。
」
債務不履行・瑕疵の承継➢

東京地裁平成 25 年 5 月 28 日

（判例タイムズ 1416 号 234 頁）（事案）
本訴請求は，ソフトウェアの受託開発等を業とする本訴原告 X が，書籍の出版及び販売等を業とする本訴被告 Y との間で，Y の次期情報システムの開発プロジェクトについて業務委託基本契約を締結した上，順次個別契約を締結して Y から発注を受けた旨主張する業務のう
ち，代金の支払を受けていないソフトウェア開発個別契約の代金（なお，要件定義，外部設計については支払済みである。
）及び導入支援作業等の代金の合計 14 億余円と遅延損害金の支払を求めた事案。
反訴請求は，Y が，本件ソフトウェア開発個別契約について，多数の不具合・障害が発生して X が仕事を完成させることができなかった旨主張して，債務不履行又は瑕疵担保責任に基づく損害賠償として，無駄となった要件定義，外部設計の費用や，人件費等の合計 14 億余円と遅延損害金の請求をした事案。
（判旨）
導入支援作業は，本件ソフトウェア開発個別契約の対象である本件基幹システムを Y に導入するための作業であり，本件ソフトウェア開発個別契約に関連付けられているということはできるが，本件ソフトウェア開発個別契約と導入支援契約は社会通念上区別することができ，前者が請負契約であるのに対し，後者は仕事の目的物の完成という状態を観念することが困難で，前者の契約締結前から既に履行が始まっていた準委任契約であり，新基幹システム導入のための Y の作業を支援して一定程度進めたという限度ではその契約の目的も達成していると解されるから，本件ソフトウェア開発個別契約が解除されたからといって，導入支援作業についての合意も解除されたと認めることはできない。
追加費用〈１〉（新基幹システムを完成させるため必要となった INS 回線の敷設と指示システムアプリ対応機器追加の各作業についての合意）は、本件ソフトウェア開発個別契約の対象である新基幹システムに新たな機能を追加するために要した費用であり、その費用の負担に関する何らかの合意が成立したとしても、それは本件ソフトウェア開発個別契約に密接に関連付けられていて、それと相まって本件新基幹システムを完成させるための請負契約であり、社会通念上、その合意のみが履行されたとしても合意をした目的は達成することができない。したがって、本件ソフトウェア開発個別契約について上記１のとおり仕事の目的が達成できないものとして瑕疵担保責任に基づく解除が認められる以上、追加費用〈１〉に関する合意があったといても、その合意も解除されたと認めるほかない。
4➢

東京高裁平成 25 年 9 月 26 日（スルガ銀行 VS 日本 IBM）

上流工程におけるシステム開発が実現不可能といえるような状態になり、プロジェクトマネジメント義務違反が生じている場合には、それ以降の工程の契約については、不必要な開発費用を支払わせているものであり、これらの契約について、プロジェクトマネジメント義務違反が生じているものとして、下流工程の契約解除を認めている。
「以上検討したところによれば、本件最終合意締結の段階において不法行為が成立すると認められ、ⅠないしⅢの段階で締結した各契約に基づき本件最終合意締結直前までに支出した費用については、控訴人には、被控訴人に対し、不法行為（あるいは債務不履行）に基づいて損害賠償する義務は認められないというべきである。他方、本件最終合意締結後に支出した費用については、控訴人の義務違反により、必要としない費用の支出を強いられたものと認められるから、控訴人は、被控訴人に対し、不法行為に基づき、その費用相当額の損害賠償をする義務を負うというべきである。
3 本件個別契約５，８，９の債務不履行の有無
原告野村ＨＤが、被告に債務の本旨に従わないプロジェクト・マネジメント義務違反があったとして挙げる諸事情（ＰＭ整理表中「状況」欄、「原因」欄及び「対策」欄の各「原告ら」欄参照）は、本件個別契約１３～１５に関する事情を除けば、専ら要件定義に関する事情となっている。
そして、確かに、本件開発業務の上流工程では、例えば、本件個別契約５による概要設計フェーズまでの間、被告の支援の下で原告野村證券担当者がＷＭの機能に合わせた要件定義を行うことが不可能な状況の下でカスタマイズ量が増大する（前記認定事実４（４））など、被告の債務の履行に債務の本旨に従わないところがあったことは否定し難い。
しかし、開発状況に応じて必要・適切な債務を契約ごとに個別具体的に定める本件各個別契約の趣旨（前記（３）ア）からすると、本件各個別契約は、前の工程における不十分な点や不備の是正を、次の工程において行う趣旨をも含んでいたと認められる。実際にも、前記認定事実によれば、本件開発業務では、上記概要設計フェーズにおけるカスタマイズ量の増大に応じて、新たに本件個別契約８が締結されて概要設計最適化フェーズが行われ、同フェーズにおいて、概要設計フェーズで増大したカスタマイズ量は、相当程度削減されて是正されたものであり、それにもかかわらず、全体としてカスタマイズ量が削減できなかったのは、要件の詳細化によるカスタマイズ量の増大によるところが大きかったものである（前記認定事実４（４））
。そして、本件開発業務では、その後、取り立てて要件を見直す気配もないまま、ストーリーボードの取りまとめが進められ（同５（１））、平成２３年１２月５日には、開発の前提となるストーリーボードも確定し（同５（２）イ）、設計・開発フェーズが進められ、受入れテストと並行してとはいえ総合テストも開始され、原告野村ＨＤは、要件定義
5

のための上記各契約の対価の支払を完了している（別紙１「契約一覧」中「１ ウェルス・マネージャー導入にかかる被告との契約」と題する表の欄外５、８及び９の各「発注額（税別）」欄及び「支払額（税別）」欄）。
要件定義は、ウォーターフォール型開発方式におけるユーザの要求をベンダが開発できるような形に取りまとめる上流工程の作業であって（前記前提事実（３）イ）、その取りまとめの主体は、ユーザであり、ベンダとの間の契約は、その取りまとめをベンダが開発できるような形で行うことを支援する趣旨のものと解される。そして、以上の事情の下では、原告らは、遅くとも総合テストが開始されるまでには、ユーザとしてベンダが開発できるような形での要件の取りまとめを終了したと認めるのが相当である。
なお、前記認定事実によれば、本件開発業務では、平成２３年１２月５日のストーリーボードのサインオフ後の設計・開発フェーズでも、ストーリーボードの確認・修正作業が続いている（前記認定事実５（２）ウ（ウ）、（３）ウ、オ、（５）ウ（イ）など）。しかし、その確認・修正作業には、原告野村證券が確定した内容と異なることを理由とするものが散見されるところ、このような確定後の無断修正の是正は、要件の確定が未了であることを意味しないことが明らかである。また、ウォーターフォール型のコンピュータ・システム開発では、要件定義確定後の設計・開発・テスト段階において、確定した要件定義に不備や欠陥が発見されて修正されることも、あらかじめ予定されていると解されるから、このような修正作業もやはり要件の確定が未了であることを意味しないものというべきである。
そして、前記認定事実によれば、本件開発業務では、テメノス社の要件の把握不足からショーストッパーを呈し、最後まで総合テストへの参加を妨げた「運用開始日前日案件作成」も改善し、総合テストへの参加をみたものであり（前記認定事実６（２）エ）、本件全証拠によっても、総合テストへの参加時点において、ベンダが開発できるような形での要件の取りまとめ自体が終了していない要件があったとは認められない。
そうすると、要件定義のための本件個別契約５、８及び９は、被告の債務の履行に不十分なところがあったとしても、それぞれその段階的な契約目的を達成して終了したと認められ、後に履行不能を来すものとは解されない。
Q:

本件においては、開発業務の上流工程におけるカスタマイズ量の増大があり、その点は、プロジェクトマネジメント義務違反を問うことは難しいのか？

プロジェクトマネジ

メント義務としてはどのようなものを問うべきか？
【ゼミにおける意見等】
上流工程での問題（仕様確定、仕様変更等）は、ユーザ、ベンダが双方ともの責任としているのが裁判所の潮流。
ベンダとしては経験上、お客様内部での仕様に関する意思統一をすることは難しい。

6

（プロジェクトマネジメント義務）➢東京地裁

平 成 28 年 4 月 28 日 （ ト ク ヤ マ ・ TIS 事 件 ）被告は，自らが有する専門的知識と経験に基づき，本件システム開発に係る契約の付随義務として，本件システム開発に向けて有機的に組成された各個別契約書や本件提案書において自らが提示した開発手順や開発手法，作業工程等に従って自らなすべき作業を進めるとともに，それにとどまらず，本件プロジェクトのような，パッケージソフトを使用したＥＲＰシステム構築プロジェクトを遂行しそれを成功させる過程においてあり得る隘路やその突破方法に関する情報及びノウハウを有すべき者として，常に本件プロジェクト全体の進捗状況を把握し，開発作業を阻害する要因の発見に努め，これに適切に対処すべき義務を負うものと解すべきである。そして，システム開発は開発業者と注文者とが協働して打合せを重ね注文者の意向を踏まえながら進めるべきものであるから，被告は，注文者である原告の本件システム開発へのかかわりなどについても，適切に配意し，パッケージソフトを使用したＥＲＰシステム構築プロジェクトについては初めての経験であって専門的知識を有しない原告において開発作業を阻害する要因が発生していることが窺われる場合には，そのような事態が本格化しないように予防し，本格化してしまった場合にはその対応策を積極的に提示する義務を負っていたというべきである。
具体的には，被告は，原告における意思決定が必要な事項や解決すべき必要がある懸案事項等の発生の徴候が認められた場合には，それが本格的なものとなる前に，その予防や回避について具体的に原告に対して注意喚起をすべきであるし，懸案事項等が発生した場合は，それに対する具体的な対応策及びその実行期限を示し，対応がされない場合に生ずる支障，複数の選択肢から一つを選択すべき場合には，対応策の容易性などそれらの利害得失等を示した上で，必要な時期までに原告において対応することができるように導き，また，原告がシステム機能の追加や変更の要求等をした場合，当該要求が委託料や納入期限，他の機能の内容等に影響を及ぼすときには原告に対して適時にその利害得失等を具体的に説明し，要求の撤回，追加の委託料の負担や納入期限の延期等をも含め適切な判断をすることができるように配慮すべき義務を負っていたということができる。

4 ユーザ側の協力義務
本件は、原告による不法行為責任の責任を否定する過程で、原告ら側の要因を認めている。
これらの要因は、直接、過失相殺の理由や、債務不履行における被告の責任を否定する理由付けにはなっていない。もっとも、本件における価値判断においては、これら原告ら（ユーザ側）の事情を考慮していることが推察される。
（判旨）7本件開発業務が本件局面７及び８の時点で大きなリスクを内在するものとなった（前記１）
要因には、次の〈１〉～〈４〉のような上流工程における原告ら側の要因が含まれていたと認められる。
〈１〉 もともと本件開発業務の困難さの基礎に、原告事業部の要件にグローバルスタンダードとは異なる固有かつ複雑な内容があったことは、前記１のとおりである。しかし、原告らは、ＲＢＣを始めとする海外での実績を重視して、本邦で初めて導入されるＷＭの導入を決定しながら（前記認定事実３（４）ウ）、上記実績の詳細を全く調査しておらず（証人ａｂ４９～５０頁）、当時のプロジェクトマネジャであるａａ事業部課長は、自らそのことを「甘かった」と評している（証人ａａ４７頁）。
〈２〉 また、本件開発業務で想定された開発期間が、設計・開発フェーズの開始当初、想定された過少なカスタマイズ量を前提としても、ＷＭの通常の想定に不足していたことは、前記１のとおりである。そして、その不足期間は１か月であったところ（前記認定事実５（２））
、本件開発業務では、それより前、原告野村證券の予算上の事情に起因して、１か月間、実質的な要件定義作業に着手しない概要設計立ち上げフェーズが設けられていたものである（前記第４の２（２）ア、前記認定事実３（４）エ）。
〈３〉 さらに、本件開発業務におけるカスタマイズ量が、客観的には、本件局面７の設計・開発フェーズの開始時点で、パッケージ・ソフトウェアを利用する開発としては、相当程度、合理性を欠く量に及んだことが、大きなリスクを内在する要因となったことも、前記１のとおりである。しかし、原告らは、もともと低コストかつ短期間での構築を重視してＷＭの導入を検討し、その導入を決定したのに（前記認定事実２（１）イ及び３（４）ウ）、カスタマイズ量が増大し、また、その増大の経緯から被告のＷＭの理解度に疑問を覚えたにもかかわらず、特段の再検討を行わず、８億０８００万円という対価はさほど高額ではないなどとして本件個別契約１３を締結している（同５（１）ア（エ））。しかも、その際、原告らは、提案書に明記されたストーリーボードの重要性を見誤り（同４（４））、平成２３年９月９日のサインオフまでの検討期間は不十分であると認識しつつ、口頭であれば間に合うであろうという程度の見通ししかないのに、本件個別契約１３を締結し（同５（１）ア（エ））、上記サインオフ期限には、サインオフを条件付きのものとして、内容を確定せずに次のフェーズを進めることを了解している（同５（１）イ）。
前記認定事実によれば、本件開発業務におけるカスタマイズ量の増大自体は原告らの責めに帰すべき事由によるとまではいえないが（前記認定事実４（６））
、原告らは、要件定義の主体であるユーザである。そして、ＷＭは本邦に初めて導入されるパッケージ・ソフトウェアでもあったのであり（同１（３）柱書）、カスタマイズ量の増大を受けて、低コストや短期間・最低限のカスタマイズでの導入もうたわれなくなった段階（同５（１）ア（ウ））における上記のような原告らの態度は、ユーザとして、その増大したカスタマイズ部分の客観的な確認や、テメノス社がそのカスタマイズに必要な原告事業部の要件を把握したか否かの確認を十分しないまま、安易に設計・開発フェーズの開始に踏み切ったものと言わざる8

を得ない。
〈４〉 加えて、口頭であれば間に合うであろうという原告らの上記見通しは、上記のとおりストーリーボードの重要性を見誤ったところに基づき、平成２３年６月頃から情報提供を受けていたストーリーボードの案について本格的な検討を進めず（前記認定事実４（６））
、サインオフ期限の１０日前の同月８月末に受領した案について、初めて原告事業部のプロジェクトマネジャが検討を始めるというような状況の下での見通しであったものであり（同４（６））、その見通しに反して、ストーリーボードのサインオフが遅れ、本件局面７から不足していた開発期間が更に圧縮されて、本件局面８において、本件開発業務に内在するリスクを更に大きなものとしたことも、前記１のとおりである。

Q:システム契約におけるユーザ側の協力、その懈怠は、どの程度損害賠償に反映されるべきか。開発のフェイズにより異なるか？
Q：本事案の評価は？ユーザに厳しいかどうか？

5 損害賠償義務（１） 各個別における責任限定条項
・ 信義則違反・ 重過失がある場合は信義則に照らして責任限定条項が制限される余地（参考裁判例）➢東京地判

平成 26 年 1 月 23 日（事案）
ウェブサイトにおける商品受注システムの設計、保守等の委託契約において、受託者が製作したアプリケーションが脆弱であったことにより顧客のクレジットカード情報が流出した事案において、個人情報の漏洩を防ぐために必要なセキュリティ対策を施したプログラムを提供すべき義務に対する債務不履行責任を求めた事案（判旨）
本件基本契約二九条二項は、ソフトウェア開発に関連して生じる損害額は多額に上るおそれがあることから、被告が原告に対して負うべき損害賠償金額を個別契約に定める契約金額の範囲内に制限したものと解され、被告はそれを前提として個別契約の金額を低額に設定することができ、原告が支払うべき料金を低額にするという機能があり、特に原告が顧客
9の個人情報の管理について被告に注意を求める場合には、本件基本契約一七条所定の「対象情報」とすることで厳格な責任を負わせることができるのであるから、一定の合理性があるといえる。しかしながら、上記のような本件基本契約二九条二項の趣旨等に鑑みても、被告（その従業員を含む。以下、この（２）項において同じ。）が、権利・法益侵害の結果について故意を有する場合や重過失がある場合（その結果についての予見が可能かつ容易であり、その結果の回避も可能かつ容易であるといった故意に準ずる場合）にまで同条項によって被告の損害賠償義務の範囲が制限されるとすることは、著しく衡平を害するものであって、当事者の通常の意思に合致しないというべきである（売買契約又は請負契約において担保責任の免除特約を定めても、売主又は請負人が悪意の場合には担保責任を免れることができない旨を定めた民法五七二条、六四〇条参照。
）。
したがって、本件基本契約二九条二項は、被告に故意又は重過失がある場合には適用されないと解するのが相当である。
6 近似のシステム訴訟の傾向と本事案の位置づけ
Q：本事案は、システム訴訟全体の傾向から見てどのように位置づけられるか？
Q：本事案から、ユーザ・ベンダとして、どのような点に留意すべきか？（本事案の教訓は？）（１）システム関連訴訟における傾向➢ベンダ側のプロジェクトマネジメント義務と協力義務
スルガ銀行／IBM➢

ユーザ・ベンダの双方の責任を認める
トクヤマ / TTS➢

ユーザ側の協力義務
旭川医大 / NTT 東日本（２） 本事案の位置づけ・教訓・ パッケージソフトの利用形態での開発
・ 初期の要件定義の重要性
・ ユーザへの一定程度の責任・ 既存システムの流れをどこまで取り入れるか・ 現場の意見をどこまでくみ取るか・ パッケージソフトの理解・ 提携先の協力
・ 人的体制10

・ 証拠の準備
7 システム開発契約（１）システム開発の工程
工程の名称

作業内容

契約類型

主体

要件定義

業務要件を決定する工程

準委任

ユーザ

準委任又は請負

ユーザ又は外部設計（基本設計） 表示画面、業務で使用する帳票等を決定する工程

ベンダ

開発（プログラム～プログラムやデータベースのシステムテスト）

詳細な使用を決定し、実際にプ

請負

ベンダ

準委任

ユーザ

ログラムを開発する工程
運用テスト

ユーザ企業の実際のデータを利用して本番さながらのテストを行う工程

Q：今回の事案では、非常に細かく契約を分けているが（15 個の個別契約）、実際はどうか？
ここまで細かく分ける必要があるか？やりすぎではないのか？
→実際には開発規模やユーザ・ベンダ間の交渉力などによって決まると考えられる。必要以上に細かく分けることはユーザにとってリスクとなるのでは。
→経産省のモデル契約では、要件定義、外部設計、開発、運用準備・移行の４段階の個別契約に分けており、分けるとしたらこのくらいまでが妥当か？
【ゼミにおける意見等】
細かく分けることにより作業範囲が特定されていると判断される可能性があるため、ベンダ有利と考えられる
ユーザ側の予算取りの関係も踏まえて、契約を分けている場合もある
ユーザが上場企業の場合、決算の影響もあると考えられるため、大規模開発案件の場合は、契約を細かく分けることもあると思われる
２．一括契約と多段階契約の対比
・ベンダ視点
一括契約

メリット

デメリット

１回で契約手続が済む

・途中でプロジェクトが頓挫した場合、完了した工程の請負代金も請求できない可能性がある。
11

・要件定義のようにユーザ企業が主体的に関与すべき工程についても仕事の完成義務を負うことになる。
・契約締結時点で、作業量を把握することが困難で、正確な見積りができない。
多段階契約

・工程ごとに準委任契約と請負契約を使い分けることができる。

・工程ごとに個別契約を締結する手間が煩雑である。

・工程ごとに個別契約を締結する・工程ごとに個別契約を締結するたため、義務の履行が完了した個め、次の工程を必ず受託できるとい別契約の報酬は受領できる。

う保証はない。

・ユーザ視点
一括契約

メリット

デメリット

・途中でプロジェクトが頓挫した

・開発対象が具体的に定まっていない

場合、後払いの報酬の支払を拒時点で見積りをすることになるた

否し、又、既払いの報酬を原状回め、高額な見積を提示される傾向が復請求できる場合がある。

ある。

・提案段階でシステムの開発にかかる総額が確定するため、投資判断がしやすい。
多段階契約

・各個別契約は、ユーザ企業の検・要件定義工程や外部設計工程が完了収作業により終了するため、ベしないと正確な開発コストの総額をンダ企業の進捗状況を把握しや把握できない。

すい。

・途中でプロジェクトが頓挫した場

・工程ごとに個別契約を締結する

合、前の工程の費用の返還等を請求ので、途中で委託先を別のベンすることができるのか否か不明。

ダに変えることができる。
（おそらく実際上は難しい。）
Q：下線部分（プロジェクトが頓挫した場合）に着目すると、ベンダにとっては多段階契約が望ましく、ユーザにとっては一括契約が望ましいように思える。経産省のモデル契約は多段階契約を推奨しており、やはりベンダ側に寄っているのでは？本事案における裁判所の見解も、経産省のモデル契約を参照しており、ユーザにとって不利なのでは？
Q:

一括契約でプロジェクトが頓挫した場合、ベンダは完了した工程の請負代金を請求できないのか？
12→たとえ一括契約でも、工程ごとに分割して検収が行われ、その分割された給付についてユーザが独立した利益を得ているという場合には、ユーザが受ける利益の割合に応じて報酬を請求することができる。
（改正民法第 634 条）（最判昭和 56 年 2 月 17 日）→ユーザが独立した利益を得ている必要があるので、途中までの成果物がそれだけでは使い物にならなければやはり請求できない？
【ゼミにおける意見等】
多段階契約がユーザ・ベンダ双方にとってメリットがあると考えられる（完成品を最初からイメージすることが難しく、開発の過程で完成品が見えてくることから、仕様確定、請負金額、スケジュールなど、適切な時期、作業範囲で条件を定める方がトラブルとなる可能性が低くなる）。

※ 経済産業省モデル契約への言及
https://www.meti.go.jp/policy/it_policy/softseibi/index.html#05【貴社の実情の確認】
Q: 貴社のシステム開発契約においては、多段階的契約が締結されることは多いか。その段階の区切りはどの程度で行っているか。
Q: 個別契約を包括する契約として、システムの完成自体を確約する契約はあるか。
Q: 責任限定契約条項における故意・重過失の除外条項は入っているか。
【本事案の教訓】
Q：どのような契約を締結すればベンダには有利か？締結時期は関係あるのか？

【発表者による所感】
非常に長い判決文で読むのに苦労したが、システム開発紛争における様々な論点が含まれており、大変勉強になった。特に、多段階契約についてはこれまで曖昧な理解であったが、よく理解することができた。今後も、システム開発紛争事案には注目し、システム開発ベンダの法務部員として業務に活かしていきたい。（本田）
判決においても経済産業省のモデル契約に言及している点をふまえ、その位置付けの重要13

性を感じた。ユーザに酷なのではとの印象も事前の内部協議であったが、基本的に判決に賛同している方も多い点が印象的であり、上流工程におけるユーザのリスク認識の共有・現場とシステム担当者の認識の共有が実務上の課題であると感じた。システム訴訟においては事前における契約締結の持つ意味が大きいことを改めて学ぶとともに、進捗や会議でのやりとりをどのように証拠として整備していくかも大事だと考えるいい契機となった。
（太田）
本判決の事案を通して、ユーザ、ベンダ間で開発におけるリスク認識を合わせていくこと、および紛争対応に向けた証拠の用意、整理が重要であることを改めて認識できる機会となった。今回発表した内容を今後の自身の業務に活かしていきたい。（武藤）以上14