平成29年8月31日、札幌高裁は、旭川医大（ユーザ）とNTT東日本（ベンダ）との間のシステム開発契約を巡る紛争について、NTT東日本のプロジェクトマネジメント義務を認めた原審を覆し、旭川医大に協力義務違反があったことを理由として、同大学に対し、NTT東日本への14億9744万8554円の支払いを命じました。
プロジェクトの遅延が、専ら、仕様確定後も大量の追加要望等を出し続けたユーザにあると評価した点に特色があり、システム開発訴訟における当事者の責任範囲を検討するに際して参考となる事案です。
ポイント
骨子
- ユーザとベンダとの間に「開発範囲を確定し，以後，一切の追加開発要望を出さないとの合意」がある場合、ユーザには、その協力義務の一態様として、開発契約及び当該合意に反して大量の追加開発要望を出し，ベンダにその対応を強いることによって本件システム開発を妨害しないというような不作為義務がある。
- 本件事案の下では、ベンダは、追加開発要望に応じた場合には納期に間に合わないことを説明し、上記合意による追加要望の拒否を含めた然るべき対応をとれば足り、それ以上に、更なる説得行為や毅然と追加要望を拒否する等しなくとも、プロジェクトマネジメント義務に違反しない。
判決概要
| 裁判所 | 札幌高等裁判所 |
|---|---|
| 判決言渡日 | 平成29年8月31日 |
| 事件番号 | 平成28(ネ)189 損害賠償請求控訴事件 |
| 原判決 | 旭川地判平成23年(ワ)99号、平成23年(ワ)148号 |
| 裁判官 | 裁判長裁判官 竹内 純一 裁判官 髙木 勝己 裁判官 小原 一人 |
解説
プロジェクトマネジメント義務と協力義務
プロジェクトマネジメント義務
システム開発を現実に行うベンダは、システムを発注するユーザと比較して、高度の専門的知識と経験を有することが一般的です。
そのため、学説・裁判例上、このような情報格差に鑑みて、ベンダは、①ユーザとの間において合意した仕様や作業工程等に従い開発作業を進めるのみならず、②ユーザのシステム開発へのかかわりについても、適切に管理をする義務としてのプロジェクトマネジメント義務を負うと考えられています。
ベンダのプロジェクトマネジメント義務についてのリーディングケースである、東京地判平成16年３月10日判タ1211号129頁は以下のとおり判示しています。
したがって，被告は，納入期限までに本件電算システムを完成させるように，本件電算システム開発契約の契約書及び本件電算システム提案書において提示した開発手順や開発手法，作業工程等に従って開発作業を進めるとともに，常に進捗状況を管理し，開発作業を阻害する要因の発見に努め，これに適切に対処すべき義務を負うものと解すべきである。そして，システム開発は注文者と打合せを重ねて，その意向を踏まえながら行うものであるから，被告は，注文者である原告国保のシステム開発へのかかわりについても，適切に管理し，システム開発について専門的知識を有しない原告国保によって開発作業を阻害する行為がされることのないよう原告国保に働きかける義務（以下，これらの義務を「プロジェクトマネージメント義務」という。）を負っていたというべきである。
協力義務
もっとも、他方において、ひとたびシステム開発契約を締結すれば、ユーザはその開発のすべてをベンダに委ねれば足りるということではなく、システム開発に必要な資料等をベンダに対して提供等する協力義務を負うと考えられています。前掲東京地判平成16年3月10日は以下のとおり、契約上の明示の定めに基づく義務と構成していますが、仮に明示の定めを欠く場合であっても、黙示の義務として認められる余地は十分にあるものと考えられます。
本件電算システム開発契約は，いわゆるオーダーメイドのシステム開発契約であるところ，このようなオーダーメイドのシステム開発契約では，受託者（ベンダー）のみではシステムを完成させることはできないのであって，委託者（ユーザー）が開発過程において，内部の意見調整を的確に行って見解を統一した上，どのような機能を要望するのかを明確に受託者に伝え，受託者とともに，要望する機能について検討して，最終的に機能を決定し，さらに，画面や帳票を決定し，成果物の検収をするなどの役割を分担することが必要である。このような役割を委託者である原告国保が分担していたことにかんがみれば，本件電算システムの開発は，原告国保と受託者である被告の共同作業というべき側面を有する。
そして，本件電算システム開発契約の契約書（乙1）は，4条1項において，「被告は，原告国保に対し，委託業務の遂行に必要な資料，情報，機器等の提供を申し入れることができる。資料等の提供の時期，方法等については，原告国保と被告が協議して定める。」旨定め，5条において，「原告国保の協力義務」として，「被告は，4条に定めるほか，委託業務の遂行に原告国保の協力が必要な場合，原告国保に対し協力を求めることができる。この協力の時期，方法等については，原告国保と被告が協議して定める。」旨定めており，原告国保が協力義務を負う旨を明記している。
したがって，原告国保は，本件電算システムの開発過程において，資料等の提供その他本件電算システム開発のために必要な協力を被告から求められた場合，これに応じて必要な協力を行うべき契約上の義務（以下「協力義務」という。）を負っていたというべきである。
スルガ銀行対日本IBM事件
システム開発におけるプロジェクトマネジメント義務が問題となった近時の裁判例としては、スルガ銀行対日本IBM事件（東京高判平成25年9月26日金商判1428号16頁）があります。
スルガ銀行対日本IBM事件は、スルガ銀行株式会社（原告・被控訴人。以下「スルガ銀行」といいます。）が、日本アイ・ビー・エム株式会社（被告・控訴人。以下「日本IBM」といいます。）に対して、基幹系システムの開発を委託したところ、開発プロジェクトが頓挫したことを理由として、損害及び逸失利益として115億8000万円の支払いを求めた、という事件です。
一審は、日本IBMのプロジェクトマネジメント義務違反を認め、スルガ銀行の請求のうち74億1366万6128円を認めましたが、控訴審は、その判断を一部覆し、41億7210万3169円の限度で日本IBMの責任を認めました。
控訴審において認容額が減額された大きな要素として、プロジェクトマネジメント義務がいつから生じるかによる見解の違いがあります。
一審は、契約締結前の企画・提案段階からプロジェクトマネジメント義務違反を認めましたが、これに対し、控訴審は、当該事件におけるプロジェクトの開発過程を、
Ⅰ．企画準備から基本合意①締結前の段階（企画・提案）、
Ⅱ．基本合意①締結から基本合意②締結前の段階（計画・要件定義）、
Ⅲ．基本合意②締結から最終合意締結前の段階（計画・要件定義）、
Ⅳ．本件最終合意締結からシステム開発終了の段階（計画・要件定義、実装）
の4つの段階に分けた上で、Iの段階とII～IVのそれぞれの段階において、ベンダが負うプロジェクトマネジメント義務について判示しています。
まず、Iの企画・提案段階については、控訴審は、以下のとおり判示し、契約締結前であっても、不法行為上のプロジェクトマネジメント義務を認めつつも、情報・能力の非対称性がベンダ・ユーザの双方に存在することを理由としてユーザ自らの分析義務の存在を認めた上で、プロジェクトの頓挫については「控訴人による企画・提案段階における検討・検証等において、その後の遂行過程で生じた事情、要因等を漏れなく予測することは困難であったといえ、本件システム開発の過程において一定の修正等があり得ることも当然想定されていたものというべきである」として、日本IBMのプロジェクトマネジメント義務違反を否定しました。
企画・提案段階においては，プロジェクトの目標の設定，開発費用，開発スコープ及び開発期間の組立て・見込みなど，プロジェクト構想と実現可能性に関わる事項の大枠が定められ，また，それに従って，プロジェクトに伴うリスクも決定づけられるから，企画・提案段階においてベンダに求められるプロジェクトの立案・リスク分析は，システム開発を遂行していくために欠かせないものである。そうすると，ベンダとしては，企画・提案段階においても，自ら提案するシステムの機能，ユーザーのニーズに対する充足度，システムの開発手法，受注後の開発体制等を検討・検証し，そこから想定されるリスクについて，ユーザーに説明する義務があるというべきである。このようなベンダの検証，説明等に関する義務は，契約締結に向けた交渉過程における信義則に基づく不法行為法上の義務として位置づけられ，控訴人はベンダとしてかかる義務（この段階におけるプロジェクト・マネジメントに関する義務）を負うものといえる。
もっとも，ベンダは，システム開発技術等に精通しているとしても，システム開発の対象となるユーザーの業務内容等に必ずしも精通しているものではない。企画・提案段階における事前検証を充実させることにより，システム開発構想の精度を高め，想定外の事態発生の防止を図り得ると考えられるが，受注が確定していない段階における事前検証等の方法，程度等は自ずと限られ，ユーザー側の担当者等から得られる情報や協力にも限界があることは明らかである。そのため，プロジェクトが開始され，その後の進行過程で生じてくる事情，要因等について，企画・提案段階において漏れなく予測することはもとより困難であり，この段階における検証，説明等に関する義務も，このような状況における予測可能性を前提とするものであるというべきである。その意味では，ベンダとユーザーの間で，システム完成に向けた開発協力体制が構築される以前の企画・提案段階においては，システム開発技術等とシステム開発対象の業務内容等について，情報の非対称性，能力の非対称性が双方に在するものといえ，ベンダにシステム開発技術等に関する説明責任が存するとともに，ユーザーにもシステム開発の対象とされる業務の分析とベンダの説明を踏まえ，システム開発について自らリスク分析をすることが求められるものというべきである。
このようなことからすると，企画・提案段階におけるシステム開発構想等は，プロジェクト遂行過程において得られるであろう情報，その過程で直面するであろう事態等に応じて，一定の修正等があることを当然に想定するものといえ，企画・提案段階の計画どおりシステム開発が進行しないこと等をもって，直ちに企画・提案段階におけるベンダのプロジェクト・マネジメントに関する義務違反があったということはできない。…
他方、控訴審は、IIないしIVの計画・要件定義・実装段階におけるプロジェクトマネジメント義務について、以下のとおり判示した上で、「本件システム開発においては、少なくとも、本件最終合意を締結する段階において、本件システムの抜本的な変更、または、中止を含めた説明、提言及び具体的リスクの告知をしているとは認めがたいから、控訴人に義務違反（プロジェクト・マネジメントに関する義務違反）が認められるというべきである」とするとして、日本IBMの責任を認めました（ただし、故意・重過失は否定しました。）。
控訴人と被控訴人とは，本件システム開発において，控訴人が，事業・業務要件定義，要件定義，外部設計工程，内部設計工程，プログラミング工程（実装工程），総合テスト，システムテスト，運用テストの全てを担当し，本件システム開発の完成まで受任することとして，3つの基本合意と16個の個別契約を締結した。控訴人は，前記各契約に基づき，本件システム開発を担うベンダとして，被控訴人に対し，本件システム開発過程において，適宜得られた情報を集約・分析して，ベンダとして通常求められる専門的知見を用いてシステム構築を進め，ユーザーである被控訴人に必要な説明を行い，その了解を得ながら，適宜必要とされる修正，調整等を行いつつ，本件システム完成に向けた作業を行うこと（プロジェクト・マネジメント）を適切に行うべき義務を負うものというべきである。
また，前記義務の具体的な内容は，契約文言等から一義的に定まるものではなく，システム開発の遂行過程における状況に応じて変化しつつ定まるものといえる。すなわち，システム開発は必ずしも当初の想定どおり進むとは限らず，当初の想定とは異なる要因が生じる等の状況の変化が明らかとなり，想定していた開発費用，開発スコープ，開発期間等について相当程度の修正を要すること，更にはその修正内容がユーザーの開発目的等に照らして許容限度を超える事態が生じることもあるから，ベンダとしては，そのような局面に応じて，ユーザーのシステム開発に伴うメリット，リスク等を考慮し，適時適切に，開発状況の分析，開発計画の変更の要否とその内容，更には開発計画の中止の要否とその影響等についても説明することが求められ，そのような説明義務を負うものというべきである。
事案の概要
当事者の請求
旭川医大，NTT東日本及びNTTファイナンスは、NTT東日本が、旭川医大のために病院情報管理システム（以下「本件システム」といいます。）を構築し、NTTファイナンスを所有者として、旭川医大にこれをリースすることを目的として、リース契約を締結しました。
そうしたところ、旭川医大は、NTT東日本が平成22年1月3日に本件システムの完成及び引渡しをしなかったことから，逸失利益等の損害が生じたと主張して、NTT東日本に対して19億3567万9067円の損害賠償を請求しました（第1事件）。
他方、NTT東日本は、旭川医大に対して、その協力義務違反及び無効な解除の意思表示を前提とする不当な受領拒絶により，被告は上記契約に基づく完成義務を履行し得なくなったと主張して、債務不履行（主位的請求）及び不法行為（予備的請求1）に基づく損害賠償として22億7976万3373円の支払いを求めました。また、NTT東日本は、旭川医大に対して、さらに、商法512条に基づき22億5960万6269円の報酬支払いを求めました（予備的請求2）。
結論としては、控訴審は、旭川医大の協力義務違反があったのに対して、NTT東日本の債務不履行がなかったと認定し、NTT東日本がNTTファイナンスから支払いを受けることができたであろう14億9744万8554円をNTT東日本の損害額として認めました。
事実関係
本件の関連事実及び争点は詳細かつ多岐にわたるものの、プロジェクトマネジメント義務にかかる控訴審の判示の理解に重要と思われる事実は以下のとおりです。
| 平成20年8月 | 旭川医大が、電子カルテシステムを中核とする病院情報管理システム導入に向けて、入札を実施した。 |
|---|---|
| 平成20年10月 | NTT東日本は，入札に当たり，平成20年10月1日付けで，本件要求仕様書等に記載された要求要件に対する提案内容を記載した「病院情報管理システム技術仕様書」（以下「本件技術仕様書」といいます。）及び「病院情報管理システム導入・保守ご提案補助資料」（以下「提案補助資料」といいます。）を作成し，旭川医大に提出した。 |
| 平成20年10月31日 | 開札が行われ、NTT東日本が落札者と決定された。 |
| 平成20年12月9日 | 旭川医大、NTT東日本及びNTTファイナンスとの間において、①NTT東日本が旭川医大のために本件システムを開発すること（以下「本件システム開発」といい，そのための一連のプロジェクトを「本件プロジェクト」といいます。）、②本件システムをNTTファイナンスが所有し、旭川医大に対してリースすることを内容とするリース契約（以下「本件原契約」といいます。）を締結した。本件システムのリリース日（リース開始日）は平成21年9月24日とされた。 |
| 平成21年1月以降 | 仕様作業等を行うための各ＷＧにおいて，旭川医大から種々の開発要望が出された。これに対して、NTT東日本が仕様外カスタマイズ，すなわち，本件技術仕様書においてNTT東日本が開発するものとはされていない項目に関するカスタマイズに当たるとして，開発範囲を絞るよう旭川医大に要求し，双方で意見の対立が生じた。 |
| 平成21年3月 | 仕様外カスタマイズを実施するか否かが専門部会でも議論の俎上に上るようになり，NTT東日本は，旭川医大に対し，NTT東日本が仕様外カスタマイズとする開発要望を絞るよう求めたものの，旭川医大のカスタマイズ要望はその後も増加した。 |
| 平成21年4月27日 | 第7回専門部会（本件システム開発の開発方針の決定や工程完了の承認など，重要な意思決定を主な役割とする部会）では，カスタマイズ要望を絶対に必要な機能に限ることが確認された。 |
| 平成21年7月7日 | 第8回専門部会において、旭川医大とNTT東日本は，電子カルテカスタマイズ要望一覧においてNTT東日本が開発するとされた625項目を開発対象に含めることで（以下「本件追加開発合意」といいます。）「仕様凍結」する旨合意（以下「本件仕様凍結合意」といいます。ただし、「仕様凍結」の意味について、当事者間に争いがあります。）した。 |
| 平成21年9月3日 | 旭川医大とNTT東日本は本件システムのリース期間を「平成22年1月4日から平成28年1月3日まで」と変更する旨のリース変更契約（以下、本件原契約と併せて、「本件契約」といいます。）を締結し，本件システムの運用開始日を平成22年1月4日に変更した。 |
| 旭川医大は，その後も92項目にわたる開発対象外のカスタマイズを追加要望し，NTT東日本は，これらを含む旭川医大の開発要望171項目のうち135項目の開発要望に応じた。 | |
| 平成21年11月から同年12月 | リハーサルで不具合等が発生した。 |
| 平成22年1月4日 | NTT東日本は，平成22年1月3日までに，本件システムを旭川医大に引き渡さなかった。 |
| 平成22年3月10日 | 旭川医大は、NTT東日本に対し、本件システムに関する債務の履行を催告した。 |
| 平成22年4月26日 | 旭川医大は、NTT東日本が本件システムを完成して旭川医大にこれを引き渡さなかったとして，本件契約を債務不履行に基づき解除するとの意思表示をした。 |
原審の判断
原審は、本件仕様凍結合意について、「開発範囲を確定し，以後，原告は，被告に対し，新たな機能の開発要求はもちろん，画面や帳票，更には操作性に関わる開発要求も含め，一切の追加開発要望を出さないとの合意であったとみるのが相当である」とした上で、以下のとおり、本件プロジェクトの頓挫については、NTT東日本（被告）の債務不履行責任を認めつつも、同社に8割、旭川医大（原告）に2割の過失がそれぞれあると述べました。
NTT東日本の責任
…以上の経緯に鑑みると，本件プロジェクトが頓挫するに至った大きな要因は，開発工数が被告の処理能力を超えていたという点にあるといえる。そして，その原因を本件仕様凍結合意後の事情に照らし考察すると，原告が同合意後も様々な開発要望を出したことが被告の重い負担になっていたことが容易に推認される。…原告が本件仕様凍結合意の後に開発要望を出したことは，同合意に反するものといわざるを得ない。
しかしながら，そもそもシステムの開発過程においては，ユーザ側から，本来ベンダが開発義務を負うものではない項目について開発（カスタマイズ）が要望されることはしばしばみられる事態である。そうすると，システム開発の専門業者である被告としては，納期までに本件システムが完成するよう，原告からの開発要望に対しても，自らの処理能力や予定された開発期間を勘案して，これを受け入れて開発するのか，代替案を示したり運用の変更を提案するなどして原告に開発要望を取り下げさせるなどの適切な対応を採って，開発の遅滞を招かないようにすべきであったというべきである。
このような観点から被告の対応をみると，そもそも平成21年2月第4週までには要件定義書及び外部設計書を完成させることが予定されていたにもかかわらず，その完成は大幅に遅滞し，被告は同年7月7日の本件仕様凍結合意の時点でもこれらを完成させることができなかったものである。この原因についても，原告から種々の開発要望が出されたことが大きな要因になっているものと推認することができるものの，被告が本件プロジェクトの進捗を適切に管理すべき専門業者であることも踏まえると，要件定義書及び外部設計書の完成が遅滞したことについては，被告がその責任の大半を負うべきものである。
そして，原告が要件定義書や外部設計書の全貌を確認することのないまま本件仕様凍結合意をしていることからすると，その後実際のシステムのイメージを確認した原告病院の職員から種々の開発要望が出されることは，当然に予想される事態であったというべきである。
加えて，…被告が，本件プロジェクトの遅滞の原因の一つとして，平成21年7月7日に合意した追加カスタマイズの開発ボリューム自体が大きいものであったことを認めていることからすると，被告が同日に追加開発を約束した内容自体が被告の処理能力からみて過大なカスタマイズであったというべきである。
そうであるとすると，被告としては，本来，本件仕様凍結合意後の原告からの開発要望に対しては，同合意を理由に追加開発を拒絶するか，代替案を示したり運用の変更を提案するなどして原告に開発要望を取り下げさせる，あるいは専門部会にこの問題を上程して開発方針について協議するなどの適切な対応を採るべきであったのに，本件仕様凍結合意後の専門部会の議事録…に照らしても，被告がこのような対応を採ったことは何らうかがわれない。そうすると，被告は，納期までに本件システムを完成させることに十分な意識を向けないまま，原告の要望するままに追加開発を行い，その結果本件プロジェクトの遅滞を招いたものといわざるを得ない。
以上によれば，本件プロジェクトが頓挫した最大の原因は，システム開発の専門業者である被告が，原告の追加開発要望に翻弄され，本件プロジェクトの進捗を適切に管理することができなかったことにあるとみるのが相当である。
したがって，被告は，本件システムが完成しなかったことについて，債務不履行に基づく損害賠償責任を負う。
旭川医大の責任
他方で，本件プロジェクトの遅滞については，原告にも責めに帰すべき事由があることは否定し難い。
…原告は，本件システムの入札手続を実施するに当たり，提案する機器及びソフトウェアが原則として製品化されていることを求め，被告は，これに応じて，本件要求仕様書等の仕様項目の多くについて，分類1，2，すなわち既存のパッケージ標準機能や他病院で稼働実績のある機能をもって提供することとして入札をしている。そして，…，キックオフのＫ1教授の発言に照らしても，原告の責任者がカスタマイズを最小限にすることを想定していたことは明らかである。
ところが，…早くも第1回専門部会において，原告病院の職員から，現行機能の継承を必須とする発言が出ており，さらに，各ＷＧにおいて仕様の確認・検討が開始されると，原告病院の医師等から，現行機能の維持を求めるなどして様々な追加開発要望が出されたのであって，上記の想定が原告病院全体には必ずしも共有されていなかったことがうかがわれる。このように，原告が，本件プロジェクトの開始直後から，本来被告が開発義務を負わない分類1，2の項目についても多数の追加開発を要望したため，本件プロジェクトの遅滞を招いた面があることは否定できない。
加えて，…平成21年7月7日の本件仕様凍結合意後においては，一切の開発要望を出すことができないにもかかわらず，原告からは，92項目にも及ぶ開発対象外の要望が出されたのであって，…これが開発の遅延をもたらした一因であることは否定し難い。
また，…原告は，マスタの移行に関して，既存マスタからデータを抽出した上で，これをマスタ登録シートに入力するなどの協力義務を負っていたにもかかわらず，多くのマスタについては，原告が作成しなかったため，被告が作成せざるを得なくなったことが認められる。加えて，…マスタ作成に当たっての原告の被告に対する協力姿勢は十分であったとはいえず，その結果被告の稼働が増加したことが推認されるのであって，この点も本件プロジェクトの遅滞をもたらした一因であると認めるのが相当である。
そして，原告は，自らの開発要望等が本件プロジェクトの遅滞をもたらした一因であるにもかかわらず，被告が本件システムの完成に向けてなお尽力したいとの姿勢を見せていた平成22年4月，以後の一切の協力を拒絶して，本件解除を行い，その完成の可能性を閉ざしたのである。
こうした一連の経緯に鑑みると，本件プロジェクトが頓挫したことについては，原告の協力が不十分であったこともその一因となっていることは否定できない。本件プロジェクトは，医療に関する大規模システム開発を目的とするものであって，その遂行に当たっては，情報システムの専門家である被告が中心的役割を果たすべきことはもちろんであるが，原告も医療の専門家としてこれに協力すべき義務があるというべきである。そして，一たび本件プロジェクトが頓挫してしまえば，被告としては，その時点での成果物を他のプロジェクトに流用することも困難であると考えられるのであって，原告が十分な協力を行わず本件プロジェクトの遅滞を招いた上，本件解除によって本件プロジェクトを頓挫させたことについては，原告にも協力義務違反があったものとして，相応の責任があるというべきである…。
控訴審の判断
札幌高裁は、本件仕様凍結合意の意味に関する原審の認定を是認しつつも、以下のとおり述べて、本件プロジェクトの頓挫の原因は、専ら、仕様確定後も大量の追加要望を出し続けることにより旭川医大（一審原告）が協力義務に違反したことにあるとして、NTT東日本（一審被告）の債務不履行責任を否定しました。
旭川医大の責任
システム開発はベンダである一審被告の努力のみによってなし得るものではなく，ユーザである一審原告の協力が必要不可欠であって，一審原告も，一審被告による本件システム開発に協力すべき義務を負う（一審原告も，一般論として上記のような協力義務を有していることは認めているところである。）。そして，この協力義務は，本件契約上一審原告の責任とされていたもの（マスタの抽出作業など）を円滑に行うというような作為義務はもちろん，本件契約及び本件仕様凍結合意に反して大量の追加開発要望を出し，一審被告にその対応を強いることによって本件システム開発を妨害しないというような不作為義務も含まれているものというべきである。
しかるに，…一審原告が本件契約及び本件仕様凍結合意に反して大量の追加開発要望を出し，一審被告がこれに対応せざるを得なかったことから，本件システム開発が遅延した。また，…一審原告がマスタの抽出義務を負っていたにもかかわらず，これを懈怠し，一審原告の協力が得られないまま一審被告が代行せざるを得なくなったことも，本件プロジェクトが遅延した理由の一つになっている。
さらに，一審原告は，一審原告の追加開発要望に基づいて現行システムの備える機能を最大限取り込むことを要求しながら，そのために必要な現行システムの情報（基本設計書等）を十分に提供せず…，また，一審被告が一審原告に代わってマスタの抽出作業を行うに際しても，NECに必要な協力依頼を行うことを怠った…。
そして，…本件システムは，遅くとも平成22年4月26日までには，一審原告の協力が得られずに保留せざるを得なかった1項目を除き，全て完成していたにも関わらず，一審原告は，独自の見解から本件システムの開発が一審被告の責任で遅延したとして，一方的に本件解除をした。
上記のとおり，一審原告には，本件契約上の協力義務違反（債務不履行）が認められる。
NTT東日本の責任
前記…のとおり、本件システムの引渡日を平成22年1月4日以降へ延期するとの合意があったとは認められず，約定の期日に本件システムの引渡しがなかった（履行遅滞）との事実は認められる。
しかしながら，本件システム開発が遅延し、結局引渡しがなされないまま本件解除に至ったのは、前記…のとおり，一審原告が協力義務に違反したためであり，一審被告の責任によるものとは認められない。
一審原告は，一審被告にプロジェクトマネジメント義務違反が認められる旨を主張する…。しかしながら，一審被告は，平成21年3月4日以降，専門部会等において，繰り返し，一審原告による追加開発要望の多くは仕様外のものであること，一審被告としては，これらの追加開発要望に対応するのは難しく，同年9月24日（本件原契約におけるリース開始日）に間に合わなくなることを説明した…。
そして，一審被告は，同年7月7日，一審原告による625項目の追加開発要望を受け入れる（本件追加開発合意）一方で，以後は，新たな機能の開発要望はもちろん，画面や帳票，操作性に関わるものも含め，一切の追加開発要望を出さないという合意（本件仕様凍結合意）を取り付けたものである。
このように，一審被告は，プロジェクトマネジメント義務の履行として，追加開発要望に応じた場合は納期を守ることができないことを明らかにした上で，追加開発要望の拒否（本件仕様凍結合意）を含めた然るべき対応をしたものと認められる。
これを越えて，一審被告において，納期を守るためには更なる追加開発要望をしないよう注文者（一審原告）を説得したり，一審原告による不当な追加開発要望を毅然と拒否したりする義務があったということはできず，一審被告にプロジェクトマネジメント義務の違反があったとは認められない。
コメント
システム開発は、ベンダ・ユーザの相互関与及び協力があって初めて十分になしうるものですので、プロジェクトマネジメント義務と、協力義務の境界線は、実務上は必ずしも明確とはいえません。そのため、プロジェクトが頓挫した場合、ベンダ及びユーザの双方について、何らかの義務違反又は過失が認められる場合は少なくないと思われ、現に、本件の原審もそのような事実認定をしています。
しかしながら、これに対して、本判決は、専らユーザによる協力義務違反がシステム開発の頓挫の原因であったと認定しており、この点に特色があるといえます。そのため、ベンダのプロジェクトマネジメント義務違反を認めたスルガ事件控訴審判決と共に、システム開発が頓挫した際の当事者の責任の所在を検討するに際して、実務上参考となる事案であると思われます。
特に、本判決は、ユーザの協力義務違反を認定した大きな要因の一つとして、本件仕様凍結合意に反して大量の追加開発要望を出し続けたこと等を挙げていますが、その反面、ベンダについては、追加開発要望に応じた場合には納期に間に合わないことを説明し、追加開発要望を拒否すること以上に、更なる説得行為や毅然とした要望拒否等を行う義務がないことを述べています。
勿論、本判決はあくまでも事例判断に留まり、ユーザの追加開発要望等を協力義務違反と捉える一方、ベンダのプロジェクトマネジメント義務を制限するという手法がどこまで一般化できるかは、今後の裁判例の集積を待たざるを得ませんが、ベンダとしては、ユーザとの間において、仕様に関する認識の齟齬が生じている場合には、早期に話し合いを行い、本件仕様凍結合意類似の合意（「開発範囲を確定し、以後、一切の追加開発要望を出さないとの合意」）を締結することにより、後にプロジェクトマネジメント義務違反を問われるリスクを軽減することは検討に値するものと思われます。
本記事に関するお問い合わせはこちらから。
（文責・松下）
