SOFTIC 平成27年度 判例ゼミ（第4回
別紙１ ディスカッションテーマ

弁護士法人

内田・鮫島法律事務所
弁護士 永里 佐和子2015年10月15日）

株式会社エヌ・ティ・ティ・データ
総務部 法務室 柴田 茉佑1ディスカッション・テーマ•••••••••••••••••＜全体概要＞
第１ システムの完成
１．基本事項の確認
２．裁判例の紹介
第２ 瑕疵担保責任に基づく請負契約の解除の可否
１．基本事項の確認
２．裁判例の紹介
３．【ディスカッション・テーマ１】
裁判例と比較して、本件では新たな観点に基づき、解除が肯定されたものといえるか
第３ ベンダのプロジェクト・マネジメント義務・ユーザの協力義務
１．裁判例の紹介
２．【ディスカッション・テーマ２】
・契約締結後においてベンダとして注意すべきこと
・契約締結後においてユーザとして注意すべきこと
３．【ディスカッション・テーマ３】
ベンダが、ユーザの協力義務違反を主張する際に注意すべきこと
2

第１ システムの完成
１．基本事項の確認• 民法632条本文は、「請負は、当事者の一方がある仕事を完成することを約し、相手方がその仕事の結果に対してその報酬を支払うことを約することによって、その効力を生ずる。」と定める。
• また、民法633条本文は、「報酬は、仕事の目的物の引渡しと同時に、支払わなければならない。」と定める。
• ⇒請負契約において、「仕事の完成」+「仕事の目的物の引渡し」が報酬支払要件。
• では、「仕事の完成」とは？
3

第１ 仕事の完成
２．裁判例の紹介• １．東京地判平成14年4月22日が示した判断基準• 「請負人が仕事を完成させたか否かについては、仕事が当初の請負契約で予定していた最後の工程まで終えているか否かを基準として判断すべきであり、注文者は、請負人が仕事の最後の工程まで終え目的物を引渡したときには、単に、仕事の目的物に瑕疵があるというだけの理由で請負代金の支払を拒むことはできないものと解するのが相当である。」• ⇒多数の裁判例で踏襲。
• では、「最後の工程」とは？

4• （承前）• （１）本件地裁判決（控訴審は原審維持）

5• （承前）• （２）東京地方裁判所平成22年12月28日• ＜事案の概要＞• ユーザ（被告）との間でパッケージソフトウェアの使用許諾契約、保守サービス契約等を締結した原告が、被告に対し、使用許諾料等の支払を求めたのに対し、被告が、業務の効率化及び顧客関係管理の基盤づくりを行うとともに、役員が適切な経営判断を行うことができるようにすることを目的として、原告との間で、原告が被告の基幹情報システムの開発を請け負う旨の請負契約を締結したにもかかわらず、原告が開発した基幹情報システムには不具合があったとして、損害賠償を求めた事案。原告は、被告に対し、本件各個別契約に係る債務を履行・完成させたものと認められるとし、原告の請求が全額認容された事案。
6• （承前）• ＜裁判所の判断＞• 導入支援業務契約について、見積書、要件確認書等の記載及び基本契約書において「請負形態による業務とする」との記載があることを考慮し、「当初予定された最後の工程まで一応終了した場合には、導入支援業務が完成したといえる」と述べた上で、
7

• （承前）• 〔１〕本件プロジェクト計画書及び本件要件確認書には、「システムテスト」の項目において、被告の担当の欄には主担当を意味する「◎」印が記載されているのに対し、原告の担当の欄には「○」印が記載されており、また、備考欄に「お客様に実施していただきます。ＳＴＮｅｔはテスト実施における問合せ対応」「システムテスト：１日本番リハーサル：２日」と記載されていることが認められ、これらの事実に照らせば、システムテスト・本番リハーサルは被告が主担当として行うべき作業であって、かつ、合計３日程度で終了する作業であったこと• 〔２〕原告は、平成１８年２月１０日ころ、被告からテストシナリオを受領し、確認するとともに、同月２０日ころ、被告がテストを実施したことを確認し、原告は、被告のシステムテストの問合せ対応を同月２８日まで行ったことが認められ、これらの事情にかんがみれば、原告が本件導入支援業務契約上担当する作業は一応終了したものといえるから、システムテスト・本番リハーサルが終了していないとしても、当初予定された最後の工程まで一応終了したものといえる。と判断した。
8• （３）東京地方裁判所判決平成25年9月30日• ＜事案の概要＞• ベンダ（原告）が、ユーザ（被告）からウェブサイトのシステム開発に係る業務及び追加開発業務を請け負ったところ、被告が請負代金を支払わないことから、被告に対し、請負代金等の請求をした事案。

9• （承前）• ＜裁判所の判断＞• 「本件個別契約の業務の内容は、設計、プログラムの作成、テスト、ドキュメントの作成をした上で、これらを納品することであるとこ
ろ、原告は、本件プログラム一式及び成果文書を完成させた上、納品しており、本件プログラム一式に対しては被告も本件検収確認書を発行したことが認められる上、成果文書に関しても、被告は、納品を受けてから２０営業日以内に検査結果の通知を行っていないと認められるから（弁論の全趣旨）、本件基本契約１４条４項により、納品日である９月３０日をもって検査に合格したこととなる。
•
したがって、原告は、本件個別契約で予定された最後の工程まで終えたものであり、仕事を完成させたと認められる。」と判断し、ユーザ側が未実装機能の仕様について確認を求められたものの応答しなかったこと、未実装が全機能に占める割合がごくわずかであることから、仕事が未完成であるということはできないとした。

10第２ 瑕疵担保責任に基づく請負契約の解除の可否
１．基本事項の確認• 民法635条本文は、「仕事の目的物に瑕疵があり、そのために契約をした目的を達することができないときは、注文者は、契約の解除をすることができる。」と定める。
• ⇒請負契約において、契約解除が認められるのは、次の要件を満たすことが必要。
• （i）仕事の目的物に「瑕疵」があること• （ii）瑕疵があることで「契約をした目的を達することができないこと」• 上記（i）（ii）のうち、本件では、（ii）に重点
11

第２ 瑕疵担保責任に基づく請負契約の解除の可否
２．裁判例の紹介••••【瑕疵担保責任に基づき契約解除を認めた裁判例】
１．東京地判平成14年4月22日（平成10年（ワ）222251号等）＜事案の概要＞ユーザとの間におけるシステム開発契約に基づき、ベンダが、納期延長を繰り返した末、システムを納品し、検収が完了。本稼働が開始したものの、不具合が発生し、最終的にはユーザはシステムの継続使用を断念し、旧システムに戻した。ベンダが、請負契約等の残代金1億1522万4166円の支払を請求したのに対し、ユーザは、契約を解除する旨の意思表示をするとともに、ベンダに対し、既払金の返還及び損害賠償請求として、合計1億3266万8997円の支払を求める反訴を提起した事案。
• 裁判所は、コンピュータプログラム制作に瑕疵があるとして、ユーザからベンダに対してなされた基本契約の解除は有効であり、基本契約と請負契約はいずれも効力を失っているとしてユーザが行った既払金返還請求と損害賠償請求を認めた。

12

（承前）
• ＜裁判所の判断＞（下線：作成者）• 本件システムについて、• 〈１〉在庫照会の検索処理に３０分以上の時間を要する場合があり、その間、画面が止まったような状態になること• 〈２〉売上計上等の処理速度も遅く伝票を出力するまでの待ち時間も長いこと• 〈３〉１枚の仕入伝票を処理するのに約１時間かかること• 〈４〉平成９年１０月に実施した仮締処理では３０分程度であった月次処理時間が同１０年３月２１日の時点で約４時間に増加し、その後も増加を続けたこと• 〈５〉システム内容を変更した場合、朝の電源投入処理に数十分の時間を要すること• 〈６〉月次処理の実行中は、端末自体が使用できなくなること等の不具合が発生していたこと• という事実から、「本件本稼働後、本件システムに生じた処理速度に関する不具合は、被告が本件システムを用いて通常業務を行う上で、看過することができない重大な不具合であると認めるのが相当である。」と判断した。
• さらに、「旧システムでは電話やＦＡＸを含めたすべての月額通信費の平均は５万円ないし６万円であったが、本件システムではシステム自体の通信費が１２万７０００円にものぼり、システムの使用に応じて通信費が増加することが予想されて」おり、「処理速度が遅いことに対応して、通信費用も増加することが認められる」として、「通信費が多額に上る」ことが瑕疵に当たると判断した。
• その上で、「本件各瑕疵は、販売管理システムの瑕疵としては、重大なものであり、被告は、本件各瑕疵の存在により、本件システムの継続使用を断念し、旧システムを再び使用するに至って」おり、「被告は、本件システムの継続使用を断念した最大の理由について、処理速度の遅さにあると指摘しており、以上の各点を考慮すると、本件各瑕疵は、契約の目的を達成することのできない瑕疵であると認めるのが相当である」と判断した。
13第２ 瑕疵担保責任に基づく請負契約の解除の可否
２．裁判例の紹介••••【瑕疵担保責任に基づき契約解除を認めた裁判例】
２．東京地判平成16年12月22日（平成10年（ワ）23871号）＜事案の概要＞ユーザ（原告）が、ベンダ（被告）に対し、コンピュータによる販売管理システムの開発を依頼したが、ユーザが受領した同システムには種々の瑕疵があり、ユーザが、ベンダが納期に完成したシステムを納入できなかった、または、瑕疵が契約の目的を達成することのできない重大なものであるとして、契約を解除したことに基づく損害賠償として、または、仮に解除が認められないとしても修補完了までの履行遅滞に基づく損害賠償として、4074万9176円を請求した事案。
• 裁判所は、目的物に一括在庫引当処理及び排他制御の点について契約の目的を達成することができない重大な瑕疵が存在するとして、注文者が請負人に対して契約の解除を行った場合には、当該瑕疵は容易に修正できる軽微な瑕疵とはいえず、解除することができると判断。

14

（承前）
• ＜裁判所の判断＞• 「当日入荷の引当処理につき、移行データ（原告の実際の業務上のデータを移行したもの）による引当処理が４時間待っても終了せず、当日入荷の引当処理中は、他端末で『受注エントリー、在庫更新を行う処理』全てが行えないという」、「不具合８」は、「テストデータ（テストのために作成した複雑な情報を省いた簡単なデータ）を使用した場合ですらも、受注残データ200件の場合５分30秒、300件の場合44分、400件の場合には64分の処理時間を要した」と認定し、「本件程度のシステムにおける一括在庫引当処理に要する時間は、せいぜい数分程度が一般的に要求される内容であったということができ、テストデータ300件ですら処理時間に44分も要するよ
うなシステムは、およそ本件契約の内容に適合しないものというほかな」く、「したがって、本件システムにおける一括在庫引当処理の時間に関しては、当事者間に処理時間の長さにつき明示の合意がないとしても、同程度のシステムに通常要求される内容に適合せず、他方で、前記したような処理時間を許容するような合意を認めることもできないのであるから、瑕疵に該当するというほかない。」

15

（承前）
• さらに、「クライアントが商品マスタの登録データを修正する目的で開いていると、その間、一括在庫引当処理を含めた商品マスタを利用する各種プログラムの処理がとまってしまう」など、「排他制御による『待ち』が起こりやすい構造になっている」という、「本件不具合12」について、「本件システムが実際の業務において使用に耐えないことは明白であるから、およそ本件契約の内容に適合しないといわざるを得ず」、• 「一括在庫引当処理及び排他制御の問題は、契約の目的を達することができない重大な瑕疵に該当することが明らかである」と判断した。 16

第２ 瑕疵担保責任に基づく請負契約の解除の可否
３．【ディスカッション・テーマ１】• 瑕疵担保責任に基づく請負契約の解除を認めた平成14年事件、平成16年事件は、システムの処理スピードに照らして、瑕疵の重大性を認定し、「契約の目的を達することができない」と判断しているようである。他方で、ユーザが主張する不具合が、２週間で修復できることを理由に、契約解除を認めなかった裁判例もある（東京地判平成9年9月24日）。
17• （承前）• 本件は、「同種の大型開発案件と比べて不具合・障害が多くはないと認める余地があるとしても」、今後どの程度の障害・不具合が生じ、その補修にかかる期間についても目途が立たない状態であることや、検収が終了せず、検収が長期間を要する状態にあることを考慮した上で、解除を肯定している。このことからすると、本件判決は、従来の解除を肯定した事案とは異なる観点から解除を認めたものと考えるが、どうか。
18

• 【追記】瑕疵担保責任肯定の2類型：• ①不具合が、システムの機能に軽微とは言えない支障を生じさせる上、不具合発生の指摘を受けた後、遅滞無く修補することができないパターン（平成14年、平成16年判例）• ②不具合の数が著しく多く、しかも順次発現してシステムの稼動に支障が生じるようなパターン（本件）19

第３ベンダのプロジェクト・マネジメント義務／ユーザの協力義務
１．裁判例の紹介• （１）東京地判平成16年3月10日• ＜事案の概要＞• 国民健康保険組合であるユーザ（原告）が、新電算システムの開発をベンダ（被告）に委託したものの、納入期限までに完成しなかったことから、ユーザが契約解除の意思表示をし、既払金の返還及び損害賠償として合計3億4921万0157円の支払を求めたのに対し、ベンダが、ユーザの協力義務違反を理由とする債務不履行に基づく損害賠償請求等として、合計4億6546万1500円の支払を求める反訴を提起した事案。
20

（承前）
• ＜裁判所の判断＞• プロジェクト・マネジメント義務について：• 「被告は、システム開発の専門業者として、自らが有する高度の専門的知識と経験に基づき、本件電算システム開発契約の契約書及び本件電算システム提案書に従って、これらに記載されたシステムを構築し、段階的稼働の合意のとおりの納入期限までに、本件電算システムを完成させるべき債務を負っていたものである。
• したがって、被告は、納入期限までに本件電算システムを完成させるように、本件電算システム開発契約の契約書及び本件電算システム提案書において提示した開発手順や開発手法、作業工程等に従って開発作業を進めるとともに、常に進捗状況を管理し、開発作業を阻害する要因の発見に努め、これに適切に対処すべき義務を負うものと解すべきである。そして、システム開発は注文者と打合せを重ねて、その意向を踏まえながら行うものであるから、被告は、注文者である原告国保のシステム開発へのかかわりについても、適切に管理し、システム開発について専門的知識を有しない原告国保によって開発作業を阻害する行為がされることのないよう原告国保に働きかける義務（以下、これらの義務を「プロジェクトマネージメント義務」という。）を負っていたというべきである。 」
21

（承前）
• ＜裁判所の判断＞• 具体的には、• ①「原告国保における意思決定が必要な事項や、原告国保において解決すべき必要のある懸案事項等について、具体的に課題及び期限を示し、決定等が行われない場合に生ずる支障、複数の選択肢から一つを選択すべき場合には、それらの利害得失等を示した上で、必要な時期までに原告国保がこれを決定ないし解決することができるように導くべき義務」• ②「原告国保がシステム機能の追加や変更の要求等をした場合で、当該要求が委託料や納入期限、他の機能の内容等に影響を及ぼすものであった場合等に、原告国保に対し適時その旨説明して、要求の撤回や追加の委託料の負担、納入期限の延期等を求めるなどすべき義務」• を負っていたと判断した。
22

（承前）
• ＜裁判所の判断＞• その上で、被告がプロジェクト・マネジメント義務を尽くしていたかという点について、被告が、提案書で、設計、開発作業の各段階ごとにレビューを行い、また設計段階でプロトタイプを作成する旨を掲げながら、段階ごとのレビューを実施せず、プロトタイプをほとんど作成していないこと、被告が納品した基本設計書には、不完全な点があり、原告に校正班を納品すると説明しながら、納品していないことなどから、• 「被告は、自ら履践を約した開発手順や開発手法、作業工程を履践しなかったところがあるといわざるを得ず、この点において、被告のプロジェクトマネージメントは、不適切であったといわざるを得ない」と判断し、また、開発作業中に生じた被告の懸案事項を、自ら定めた目標期限までに解決しなかったことがあるものと認められ、この点においても、被告のプロジェクトマネージメントは、不適切であったと認められるとした。
23

（承前）

• ＜裁判所の判断＞• 他方、ユーザの協力義務違反については、次のように判示。
• まず、「本件電算システム開発契約は、いわゆるオーダーメイドのシステム開発契約であるところ、このようなオーダーメイドのシステム開発契約では、受託者（ベンダー）のみではシステムを完成させることはできないのであって、委託者（ユーザー）が開発過程において、内部の意見調整を的確に行って見解を統一した上、どのような機能を要望するのかを明確に受託者に伝え、受託者とともに、要望する機能について検討して、最終的に機能を決定し、さらに、画面や帳票を決定し、成果物の検収をするなどの役割を分担することが必要である。このような役割を委託者である原告国保が分担していたことにかんがみれば、本件電算システムの開発は、原告国保と受託者である被告の共同作業というべき側面を有する」と述べ、本件における契約書の記載から、「原告国保は、本件電算システムの開発過程において、資料等の提供その他本件電算システム開発のために必要な協力を被告から求められた場合、これに応じて必要な協力を行うべき契約上の義務（以下「協力義務」という。）を負っていたというべき」と判示した。

24

（承前）
• ＜裁判所の判断＞• その上で、「原告国保に協力義務違反があったかどうかみると、被告の主張には根拠のない点が多いものの、結局、原告国保は、被告から解決を求められた懸案事項を目標期限までに解決しなかった点において、適時適切な意思決定を行わなかったところがあるということができ、適切な協力を行わなかったところがあるといわざるを得ない」と判断した。
• もっとも最終的には、本件システムの開発作業が遅れ、納入期限までに完成に至らなかったことは、どちらか一方のみの責に帰すべき事由によるものとはいえないとして、どちらの債務不履行の主張も認めなかった。

25

第３

ベンダのプロジェクト・マネジメント義務／ユーザの協力義務
１．裁判例の紹介• （２）東京高判平成25年9月26日（スルガvs日本IBM事件）• ＜事案の概要＞• スルガ銀行（ユーザ・被控訴人）と日本IBM（ベンダ・控訴人）が、スルガ銀行の銀行業務全般を処理する経営システムの構築に関する基本合意及び個別契約を締結してシステム開発を目指したが、開発途中で中止となったことに関し、（１）スルガ銀行の日本アイ・ビー・エムに対する損害賠償等請求が一部（約４１億円）認められ、（２）日本アイ・ビー・エムのスルガ銀行に対する未払代金請求、損害賠償等請求がいずれも棄却された事例。

26

（承前）
• ＜裁判所の判断＞• 契約締結後のベンダのプロジェクト・マネジメント義務について：• 「控訴人と被控訴人とは、本件システム開発において、控訴人が、事業・業務要件定義、要件定義、外部設計工程、内部設計工程、プログラミング工程（実装工程）、総合テスト、システムテスト、運用テストの全てを担当し、本件システム開発の完成まで受任することとして、３つの基本合意と１６個の個別契約を締結した。控訴人
は、前記各契約に基づき、本件システム開発を担うベンダとして、被控訴人に対し、本件システム開発過程において、適宜得られた情報を集約・分析して、ベンダとして通常求められる専門的知見を用いてシステム構築を進め、ユーザーである被控訴人に必要な説明を行い、その了解を得ながら、適宜必要とされる修正、調整等を行いつつ、本件システム完成に向けた作業を行うこと（プロジェクト・マネジメント）を適切に行うべき義務を負うものというべきである。」
27

（承前）
• ＜裁判所の判断＞• さらに、上記義務の具体的内容について、次のように判示した：「前記義務の具体的な内容は、契約文言等から一義的に定まるものではなく、システム開発の遂行過程における状況に応じて変化しつつ定まるものといえる。
すなわち、システム開発は必ずしも当初の想定どおり進むとは限らず、当初の想定とは異なる要因が生じる等の状況の変化が明らかとなり、想定していた開発費用、開発スコープ、開発期間等について相当程度の修正を要すること、更にはその修正内容がユーザーの開発目的等に照らして許容限度を超える事態が生じることもあるから、ベンダとしては、そのような局面に応じて、ユーザーのシステム開発に伴うメリット、リスク等を考慮し、適時適切に、開発状況の分析、開発計画の変更の要否とその内容、更には開発計画の中止の要否とその影響等についても説明することが求められ、そのような説明義務を負うものというべきである。」
28

（承前）
• ＜裁判所の判断＞• さらに、「最終合意締結のころには、当初予定していた開発費用、開発スコープ及び開発期間内に収めて本件システムを開発することが不可能であることが明らかとなり、開発計画を続けてシステムを完成させるのであれば、開発費用、開発スコープ及び開発期間のいずれか、あるいはその全部を抜本的に見直すことにするか、それが困難であるならば、開発そのものを断念するかも含めて決定しなければならない局面に至っ」ていたことを認定し、その上で、• 「控訴人は、被控訴人と本件最終合意を締結し、本件システム開発を推進する方針を選択する以上、被控訴人に対し、ベンダとしての知識・経験、本件システムに関する状況の分析等に基づき、開発費用、開発スコープ及び開発期間のいずれか、あるいはその全部を抜本的に見直す必要があることについて説明し、適切な見直しを行わなければ、本件システム開発を進めることができないこと、その結果、従来の投入費用、更には今後の費用が無駄になることがあることを具体的に説明し、ユーザーである被控訴人の適切な判断を促す義務があったというべき」と判示した。

29

第３

ベンダのプロジェクト・マネジメント義務／ユーザの協力義務
１．裁判例の紹介• （３）東京地判平成24年5月30日• ＜事案の概要＞• ユーザ（原告）が、エレクトロニクス事業部門の販売・生産管理を一元管理する新しい電算機システムを構築する契約をベンダ（被告）との間で締結したが、被告に債務不履行があったとして、損害賠償等を求めたものの、被告に債務不履行はなく、請求が棄却された事案。
• 裁判所は、本番稼働の中止は、ユーザによるデータ移行等の準備不足が原因と認定した。
30

（承前）
• ＜裁判所の判断＞• 原告は、被告のデータ以降・運用支援に債務不履行によって本番稼働ができなかったと主張。これについて、裁判所は、次のように判示した。
• 「データ移行や、原告の従業員に対する教育段階（移行フェーズ）への被告の技術支援は、原告側の受入れ態勢が整わなければ実施できないものであった。しかるに、原告側の上記受け入れ準備が整わず、平成１９年１月にリ・スケジュールが実施され、同年６月以降本番稼働に向けて移行・運用支援フェーズに入った。被告は同年６月２９日から同年９月２８日までの間に本番稼働移行判定会議を開催し、原告のために移行と運用支援を行った。同年６月１１日から
原告により実施された総合テストで４４２項目の問題や課題が見つかったが、データ移行などは原告側の作業が予定どおりに進んでいなかった。」• 「しかし、原告は本番稼働の延期は許されないとして、同年１０月９日に本番稼働を開始したが、種々の障害が生じたため、原告は同月２２日に本番稼働を中止した。」• 「このように、本番稼働が中止した要因は、マスタ・データの移行作業や原告作成のプログラムに問題があったり、本件パッケージの標準機能で実現できる業務フローに原告の業務の方を合わせるための業務の見直しやルール作りが不十分であったりしたことによるも31のであった。」

（承前）• ＜裁判所の判断＞• 「本番稼働の中止後、原告が被告との間で、移行・運用支援フェーズの追加契約（本件契約１〔１４〕〔１５〕）を締結し、被告は原告側の作業の支援を行ってきたが、原告の作業が進まず、原告は平成２０年６月に自らの判断で本件新システム構築の中断を決断した。」• 「本件パッケージは市販ソフトウェアである上、原告の採用した本
件基本方針の下で行ったアドオンやカスタマイズの内容や範囲は限定的なものであり、本件パッケージの基本的な部分に変更を加える性質のものではないから、稼働しないことは考え難い。
• 以上認定の事実のとおり、本番稼働が中止となり、ひいては本件新システム構築が開発中止に至ったのは、原告のデータ移行等の準備不足等によるものである。したがって、本番稼働が中止となったり本件新システム構築が開発中止になったりしたことをもって、被告がデータ移行等の支援をしなかったと推認されるものではなく、原告の上記主張は採用することができない。」

32

第３ベンダのプロジェクト・マネジメント義務／ユーザの協力義務
１．裁判例の紹介• （４）東京地判平成9年9月24日• ＜事案の概要＞• ベンダ（原告）が、図書教材販売会社であるユーザ（被告）との間で締結した入金処理システムにかかる売買契約に基づきシステムを納入し、代金支払請求をした事案。裁判所は、被告による、原告の債務不履行を理由とする解除を否定し、原告の請求を全額認容した。
33

（承前）

• ＜裁判所の判断＞• 裁判所は、「原告は、コンピューター関係の専門企業として、顧客である被告から提供された資料及び聴取等の結果に基き、本件システムの導入目的に適合したプムグラムを作成すべき信義則上の義務を負担するものといえる。
• ところが、右１で認定した事実によれば、四月が教材会社である被告にとって最も多忙な時期であるため、プログラム作成のための打ち合わせをそれまでに終了させておくべき必要性があったにもかかわらず、これを行わなかった原告には非があるものといえる。」としつつも、

34

（承前）
• ＜裁判所の判断＞• 「しかしながら、被告の主張どおり、平成四年四月に旧システムから本件システムへの切り替えが予定されていたとするならば、被告も一つの企業体として事業を行い、その事業のために本件システムを導入する以上、自らも、積極的に原告との打ち合わせに応じ、平成四年四月の本件システムへの切り替えにむけて原告に協力すべき信義則上の義務を負担しているものといえる。
• にもかかわらず、右１で認定した事実によれば、平成三年四月以降の被告代表者の原告に対する対応（特に、登録作業の不実施）は、必ずしも好ましいものとはいえず、このことが、本件システムの本稼働へむけてのスケジュールを遅滞させた一因となっていることは否定できないのであるから、仮に、被告が主張するように、平成四年四月の本件シテスムへの切り替えが不可能な事態となっていたとしても、そのことを理由として本件システムについての契約を解除することは認められないものといえる。」と判断した。

35

第３ ベンダのプロジェクト・マネジメント義務／ユーザの協力義務
２．【ディスカッション・テーマ２】• 裁判例（４）は、その後の裁判例の蓄積による水準からすると、現在では違う結論になると考えられる。
• 裁判例（１）、（２）や本件判決からすると、ベンダにとっては、かなり厳しい水準が求められているといえる。
• 他方で、ユーザとしても、裁判例（３）からも明らかなように、単にベンダに任せてばかりでもいられない。
• そこで、ベンダ・ユーザ双方の立場から、これからのシステム開発において、注意すべき事項について検討したい。

36

• 【追記】• PM責任について、本件はシステム開発のどの工程で不具合が出たか、という点について裁判所は事情として重視していないのではないといえる。
• 法務部から開発部に対し、中止提言のタイミングをどう伝えるかは、個々の事案に応じて変わり、一般化することは難しい。
• 実務の観点からは、マイルストーン方式がベンダ・ユーザ両者にとって有益と考えられる。

第３ ベンダのプロジェクト・マネジメント義務／ユーザの協力義務
３．【ディスカッション・テーマ３】• たとえば、システム開発が中止になり、訴訟になった場
合、ベンダとしては、ユーザの協力義務違反を主張することを必ず検討すると考えられる。
• もっとも、本件判決からも見られるように、ベンダのPM責任については厳しく判断されていることからすると、PM義務違反の主張が跳ね返ってくるのではないか。
• この点について、実務経験を踏まえたご意見を伺いたい。
• 【追記】いずれにせよ、PM義務違反が主張されることは回避できないと考えられるから、ベンダとしては、主張可能なことはすべてしたほうがいい。

38