■　はじめに

ITに関わる方であれば誰でも耳にしたことがあるであろう「旭川医科大学・NTT東日本事件」。

この事件について、地裁（旭川地方裁判所平成２８年３月２９日判決）は、ユーザ・ベンダの過失割合を２：８（ユーザ：ベンダ）としましたが、高裁（札幌高等裁判所平成２９年８月３１日判決）は、一転、過失割合を１０：０（ユーザ：ベンダ）と判断しました。「過失割合が0」というのは全額請求できるということですから、ベンダの「大逆転」です。

このような「大逆転」劇が生じたのは何が原因なのでしょうか。
大きなポイントの１つとして「ベンダのプロジェクトマネジメント義務違反」の認定が旭川地裁と札幌高裁で大きく分かれたという点があります。

プロジェクトマネジメント義務と協力義務という言葉は、いまやシステム開発に関与するベンダ、ユーザ、法律家の間では常識となっています。これら２つの義務は、よく「表裏一体」とされ、システム開発訴訟でこれらの義務違反が争点になった事案では１００対０はありえないとまで評されることがあります。システム開発が頓挫したということは、通常、ベンダ・ユーザどちらにも多少の落ち度がある場合が多いからです。

この事件の争点は多岐にわたりますが（判決文は地裁で約15万字、高裁で8.5万字！なお、本記事は0.8万字）、今回は、プロジェクトマネジメント義務と協力義務に着目して検討したいと思います。

■　事案の概要　～ウォーターフォール型、パッケージ型案件～

▼　案件受注からトラブル発生まで
ユーザである国立大学法人旭川医科大学は、現行の病院情報システムの保守期限切れが近づいていたことから、平成２０年８月、新システム導入のために入札を実施しました。結果、ベンダである東日本電信電話株式会社（NTT東日本）は、⽇本IBMと共同開発したパッケージソフトを一部カスタマイズするシステムを提案し、同社が落札しました。

その後、平成２０年１１月にプロジェクトが開始され、当初、翌２１年２月末までに仕様を確定（凍結）する予定でした。しかし、ユーザからの仕様に関する要求は、同年２月以降も続きました。部会やワーキンググループ等での多数回の検討を経て、ベンダとユーザは、同年７月、６２５項目を追加で受け入れる代わりに、運用開始を同年９月から平成２２年１月４日に延期することとし、これで仕様を凍結しました（仕様凍結合意）。しかし、以後も、ユーザから１７１項目の追加要求が出されたのです。ベンダは１７１項目の追加要求を含め開発を継続しましたが、一部不具合が発生したため、平成２２年１月と２月に実施されたユーザによる到達度評価で不合格となり、その後、開発は頓挫しました。なお、平成２２年１月５日時点で、仕様凍結合意までに約束された機能６４８６項目のうち、未了は４項目でした。

時系列を簡単にまとめたのが以下の表です。

▼　旭川医科大学による訴訟提起
旭川医科大学は平成２３年３月１６日に旭川地裁に訴訟を提起しました。
旭川医科大学は、ＮＴＴ東日本に対し、新システム導入失敗に伴う逸失利益として約１９億４０００万円を請求し、他方、ＮＴＴ東日本は、旭川医科大学に対し、不当な受領拒絶でリース料を受け取れなくなったとして約２２億８０００万円を請求しました。

▼　地裁判決（旭川地判平成２８年３月２９日）
旭川地裁は、ユーザ・ベンダの過失割合を２：８（ユーザ：ベンダ）としたうえでユーザ・ベンダの両請求とも一部認容し、実質、旭川医科大学からNTT東日本へ約１８００万円の支払いを命じる判決をしました。
双方ともに控訴をし、舞台は札幌高裁に移りました。

▼　高裁判決（札幌高判平成２９年８月３１日）
札幌高裁は、ユーザ・ベンダの過失割合を１０：０（ユーザ：ベンダ）に変更した上で、ベンダの請求を認容、ユーザの請求を棄却し、旭川医科大学からNTT東日本へ約１４億円の支払いを命じる判決をしました。
当然のことながら旭川医科大学は上告をし、現在、最高裁で審理が続いています。

■　仕様凍結合意の意味　～逆転の前提～

この案件は、仕様凍結合意後にも追加要求があったことが開発頓挫の原因の大きな１つです。そのため、そもそも「仕様凍結合意」とはどういう意味なのかが争点となりました。

仕様凍結合意の意味について、
ユーザ（旭川医科大学）は「新しい機能の開発要求はしないという意味に過ぎず、例えば機能の開発要求ではない画面周りの要望は当然に許される」合意であると主張しました。
一方、
ベンダ（NTT東日本）は、「新たな機能の開発要求はもちろん、画⾯や帳票、更には操作性に関わる開発要求をすることは許されない」合意であると主張しました。

仕様凍結合意の意味についてユーザが主張するように緩やかに解釈すれば合意後の開発要求は一部許容されるのに対し、ベンダが主張するように厳格に解釈すれば、合意後の開発要求は一切許されないということになります。
本件では仕様凍結合意後に追加要求があったことが開発頓挫の原因の大きな１つですから、「仕様凍結合意」がどのような意味なのかによって要は「どちらのせいで開発が頓挫したのか」が変わってくるのです。

札幌高裁、旭川地裁ともに、仕様凍結合意の意味についてはベンダの主張どおり、本件における仕様凍結合意は「仕様凍結合意後の要望を基本的に許さないもの」と認めました。
認定理由は、①仕様凍結という単語そのものの持つ意味、②ウオーターフォール型を採用していること、③当初からのベンダの説明の一貫性、④旭川医科大学も仕様凍結の意味を理解したとれる言動をしていること、⑤仕様凍結合意締結に至る経緯（一部要求を受け入れる代わりに期限を伸ばしたこと等）等です。

このように判断されたことが、逆転の前提だと考えられるでしょう。
もしも、上記①～⑤の要素が複数欠けていたならば、形式上「仕様凍結」との合意がされていたとしても、ベンダの主張するような意味とは認められなかったと考えられます。そうなると、追加要望は何ら不当なものではないと判断され（＝協力義務違反はないと判断され）、結論は、地裁・高裁とも、ユーザである旭川医科大学に有利なものへと大きく変わっていたかもしれません。

■　プロジェクトマネジメント義務と協力義務

次にこの判決を理解するのには、システム開発における、ベンダのプロジェクトマネジメント義務とユーザの協力義務の内容・関係について知っておかなければなりません。

ベンダはシステムの専門家なのであり、ユーザの業務や要望について詳しいわけではありません。そのため、ユーザが求めるシステムを作るためには、ユーザとベンダとの共同作業が不可欠になります。この共同作業において、ベンダが負う義務がプロジェクトマネジメント義務、ユーザが負う義務が協力義務だといわれています。

これら両義務は、近時「スルガ銀行対IBM事件」（東京高判平成25年9月26日）等でも話題になりましたが、議論は複雑です。リーディングケースとされている「国民健康保険組合事件」（東京地判平成16年3月10日・判タ1211号129頁）において、下記のように判示されています。

▼ベンダのプロジェクトマネジメント義務
「ユーザのシステム開発へのかかわりについても、適切に管理し、システム開発について専門的知識を有しないユーザによって開発作業を阻害する行為がされることのないようユーザに働きかける義務」
▼ユーザの協力義務
「システムの開発過程において、資料等の提供その他システム開発のために必要な協力をベンダから求められた場合、これに応じて必要な協力を行うべき契約上の義務」

これらの両義務に違反したかどうかは、システム開発が頓挫した場合に問題として露見します。
ユーザ側の全責任で頓挫したのであれば協力義務違反のみが問題となり（＝ユーザの過失１０）、ベンダ側の全責任で頓挫したのであればプロジェクトマネジメント義務違反のみが問題となります（＝ベンダの過失１０）。ただし、通常、ベンダ・ユーザどちらにも落ち度がある場合が多く、その場合には、それぞれの義務違反がシステム頓挫へ影響した割合を裁判所が認定します（例えるならば、交通事故の場合と似ているかもしれません。）。

双方にどの程度の義務違反があったかによって双方の過失割合が変わり、ベンダの請求可能額が変わってくるということです。

もっとも、この旭川医科大学・NTT東日本事件高裁判決が出るまでは、プロジェクトマネジメント義務と協力義務は「不即不離」とか「表裏一体」といわれており、このような両義務の関係からは、システム開発に関する紛争に１００対０の案件はあり得ず、実際には、いずれの当事者も多かれ少なれ落ち度があった事案が多いと言われていました。つまり、上記の図の一番上や一番下のパターンは生じがたいとされていたのです。

それでは、本件について見てみましょう。

■　ユーザの協力義務違反　～地裁・高裁とも同じ判断～

旭川地裁は、以下のように判示してユーザの協力義務違反を認めました。

地裁判旨「（平成２０年１１月２７日実施の）早くも第１回専⾨部会において、ユーザ病院の職員から、現⾏機能の継承を必須とする発⾔が出ており、～平成２１年７⽉７⽇の本件仕様凍結合意後においては、⼀切の開発要望を出すことができないにもかかわらず、ユーザからは、９２項⽬にも及ぶ開発対象外の要望が出されたのであって～これが開発の遅延をもたらした⼀因であることは否定し難い～そして、ユーザは、⾃らの開発要望等が本件プロジェクトの遅滞をもたらした⼀因であるにもかかわらず、ベンダが本件システムの完成に向けてなお尽⼒したいとの姿勢を⾒せていた２０１０年４⽉、以後の⼀切の協⼒を拒絶して、本件解除を⾏い、その完成の可能性を閉ざしたのである。」

また、札幌高裁も下記のように判示して旭川地裁と同様、ユーザの協力義務違反を認めました。

高裁判旨「システム開発はベンダ～の努⼒のみによってなし得るものではなく、ユーザ～の協⼒が必要不可⽋であって、ユーザも、ベンダによる本件システム開発に協⼒すべき義務を負う～。そして、この協⼒義務は、本件契約上ユーザの責任とされていたもの（マスタの抽出作業など）を円滑に⾏うというような作為義務はもちろん、本件契約及び本件仕様凍結合意に反して⼤量の追加開発要望を出し、ベンダにその対応を強いることによって本件システム開発を妨害しないというような不作為義務も含まれているものというべきである。
しかるに、～ユーザが本件契約及 び本件仕様凍結合意に反して⼤量の追加開発要望を出し、ベンダがこれに対応せざるを得なかったことから、本件システム開発が遅延した。」

このように旭川地裁も、札幌高裁もほぼ同様の理屈で、ユーザの協力義務違反を認めています。
つまり、ユーザに協力義務違反があるとの部分には、旭川地裁と札幌高裁とでズレはないのです。
逆転のポイントは、次にみるプロジェクトマネジメント義務違反の有無です。

■　ベンダのプロジェクトマネジメント義務違反　～逆転のポイント～

▼　旭川地裁
旭川地裁は、ベンダのプロジェクトマネジメント義務違反について以下のように判示しました。

地裁判旨「ベンダとしては、本来、本件仕様凍結合意後のユーザからの開発要望に対しては、同合意を理由に追加開発を拒絶するか、代替案を⽰したり運⽤の変更を提案するなどしてユーザに開発要望を取り下げさせる、あるいは専⾨部会にこの問題を上程して開発⽅針について協議するなどの適切な対応を採るべきであったのに、本件仕様凍結合意後の専⾨部会の議事録に照らしても、ベンダがこのような対応を採ったことは何らうかがわれない。そうすると、ベンダは、納期までに本件システムを完成させることに⼗分な意識を向けないまま、ユーザの要望するままに追加開発を⾏い、その結果本件プロジェクトの遅滞を招いたものといわざるを得ない。以上によれば、本件プロジェクトが頓挫した最⼤の原因は、システム開発の専⾨業者であるベンダが、ユーザの追加開発要望に翻弄され、本件プロジェクトの進捗を適切に管理することができなかったことにあるとみるのが相当である。」

つまり、旭川地裁は、上記のとおり、仕様凍結合意後の追加要望に対するベンダの対応を重視し、ベンダはユーザを説得したり、毅然と拒否したりする対応まですべきだったとし、そのような対応をしなかったベンダのプロジェクトマネジメント義務違反を認定しました。

▼　札幌高裁
一方、札幌高裁は以下のように判示してベンダのプロジェクトマネジメント義務違反を認めませんでした。

高裁判旨「ベンダは、平成２１年３⽉４⽇以降、専⾨部会等において、繰り返し、ユーザによる追加開発要望の多くは仕様外のものであること、ベンダとしては、これらの追加開発要望に対応するのは難しく、同年９⽉２４⽇（本件原契約におけるリース開始⽇）に間に合わなくなることを説明した。そして、ベンダは、同年７⽉７⽇、ユーザによる６２５項⽬の追加開発要望を受け⼊れる（本件追加開発合意）⼀⽅で、以後は、新たな機能の開発要望はもちろん、画⾯や帳票、操作性に関わるものも含め、⼀切の追加開発要望を出さないという合意（本件仕様凍結合意）を取り付けたものである。このように、ベンダは、プロジェクトマネジメント義務の履⾏として、追加開発要望に応じた場合は納期を守ることができないことを明らかにした上で、追加開発要望の拒否（本件仕様凍結合意）を含めた然るべき対応をしたものと認められる。これを越えて、ベンダにおいて、納期を守るためには更なる追加開発要望をしないよう注⽂者（ユーザ）を説得したり、ユーザによる不当な追加開発要望を毅然と拒否したりする義務があったということはできず、ベンダにプロジェクトマネジメント義務の違反があったとは認められない。」

なお、旭川地裁が重視した仕様凍結合意後のベンダの対応については、札幌高裁は「ユーザは、本件仕様凍結合意後も、ベンダがユーザの指摘を受けて修正を行うなどした事実があった旨を指摘するが、これはユーザによる追加開発要望をベンダが拒否し切れなかったというにとどま」ると判断しています。

▼　分析
このように旭川地裁と札幌高裁では、ベンダのプロジェクトマネジメント義務違反についての判断が分かれ、その結果双方の過失割合についての判断も逆転し、結果としてベンダの請求が１００パーセント認められることになったのです。

地裁と高裁でプロジェクトマネジメント義務違反についての判断が分かれた理由は何でしょうか。

ニュース記事などにおいて、開発頓挫の原因は、仕様凍結合意後に多くの追加要望が出されたことであるとの見出しがつけられています。しかし、プロジェクトマネジメント義務違反があったか否かは、仕様凍結合意後の対応だけではなく、プロジェクトの全体から評価しなればいけません。

札幌高裁は、当初から相次いだ追加要望に対して、ベンダは、①仕様外の要望が多く、納期に間に合わなくなること繰り返し説明し、②仕様凍結合意という形で事後の追加要望を拒否する姿勢を示したことから、プロジェクトマネジメント義務を果たしたと認定しました。これを越えて、③ユーザを説得したり、毅然と拒否することまでは不要と判断しました。（なお、ベンダは、仕様凍結合意後に出された追加要望についても、事実上、開発を進めていました。詳細は判決文のみからは明らかではありませんが、札幌高裁は、ベンダは契約に基づく義務として応じていたものではなく、拒否しきれなかったに過ぎないのであり、そのことのみをもってプロジェクトマネジメント義務違反とは評価できないと判断したものと考えられます。）

仕様凍結合意後のベンダの行為をどこまで重視するかは議論がわかれるところでしょう（札幌高裁は重視していないように読めます。）。しかし、少なくとも、追加要望を毅然と拒否したり、取り下げさせたりするという方法は、ベンダにとってなかなか困難なものです。義務という以上は、ベンダが履行することが現実的でないといけません。旭川地裁は、ベンダに事実上困難な義務を課しており、この部分については、札幌高裁の方が納得できます。

■　まとめ

札幌高裁、旭川地裁とも、ユーザの協力義務違反を認定しました。
しかし、ベンダのプロジェクトマネジメント義務違反を、旭川地裁は肯定し、札幌高裁は否定しました。そのため、ユーザ：ベンダの過失割合が、２：８（地裁）から１０：０（高裁）となる逆転判決となったのです。

システム開発を専門としないユーザが、よりよいシステムを作りたいと考え、追加要望をすることは当然に予想されます。

本稿での検討結果からは、ベンダの対応として少なくとも、下記のことが大切といえるでしょう。

▼　プロジェクト当初からの十分な説明
本件では仕様凍結合意が「仕様凍結合意後の要望を基本的に許さない合意」と認定されたため、①仕様凍結合意後に出された数多くの追加要望が協力義務違反となり、②仕様凍結行為自体がプロジェクトマネジメントの履行と評価されたのです（札幌高裁）。
上でみたとおり、仕様凍結の時期とその意味、仕様凍結後に追加要望が行われたときの具体的な影響について、プロジェクト当初から十分に説明しておくことがまずは肝心です。

▼　追加要望を踏まえた納期の説明
追加要望を受け入れた場合に納期に間に合うかどうかの判断は、まさにプロジェクトマネジメントです。追加要望がなされた際に、この点をしっかり説明しておくことが重要です。

▼　仕様凍結合意「後」の対応
最後に仕様凍結合意「後」の対応も重要となります。仕様凍結合意後に機能開発の要望を受けた場合にどのように対応するか、です。
旭川地裁判決と札幌高裁判決の判断の相違を導いた大きな要因は、仕様凍結後のベンダの対応をどう評価するかです。
ベンダ側としては、旭川地裁が判示するような「仕様凍結後の追加要望を一切拒否したり、取り下げさせる」ということは現実には難しいとしても、安易に追加要望を受け入れるのではなく、あくまで仕様凍結合意の例外ということで対象を限定するなど可能な限りの「抵抗」をし、それを議事録などの証拠に残しておくことが非常に大事だと言えます。

この案件は、現在、最高裁に係属中です。もしも、最高裁が具体的な判断をすれば、プロジェクトマネジメント義務と協力義務に関する初めての最高裁判決となります。
果たして、高裁が判示したように１００対０が維持されるのか、あるいは再度の逆転があるのか。
最高裁の判断が注目されます。

■　追記（平成30年6月29日）

北海道新聞（電子版）５月１５日付け記事によると、最⾼裁第２⼩法廷（菅野博之裁判⻑）は、５月１１⽇付で、旭川医大側の上告を受理しない決定をしたようです。
そのため、この事件は、上記札幌高裁の判断で確定しました。

いまだ、プロジェクトマネジメント義務に関する法律論は、不明確な部分が多くあります。
本ブログでは、引き続き、システム開発関係に関する裁判例を取り上げていきたいと思います。

（弁護士菱田昌義）

→STORIAへのお問い合わせやご相談はこちらから