被告(Y)との間で新基幹システム開発にかかる契約を締結した原告(X)が、Yに対し、同契約を解除した上で債務不履行に基づく損害賠償等を求める本訴を提起し、他方、Yが、Xに対し、同契約に基づく委託料の支払等を求める反訴を提起した事案です。
この事案では、契約の性質や個数について争いがあったほか、XがYのプロジェクトマネジメント義務違反を主張していました。
契約の性質等については、下記各エントリにて解説しています。
ソフトウェア開発委託契約の性質
開発モデルとソフトウェア開発委託契約
ベンダーとユーザーがそれぞれ負う、プロジェクトマネジメント義務と協力義務については、下記エントリにて解説しています。
H18.12.11 X･Y、SAPソフトウェアを使用したERPシステムを中心とする新基幹システム開発にかかる業務委託基本契約(ウォーターホール)と方針策定等の個別契約1(検討フェーズ)締結
H19.4.1 X･Y、要件確定等の個別契約2(SYM(システムモデリング)フェーズ)締結
H19.6.30 X･Y、全体設計確定等の個別契約3(PRT(プロトタイピング)フェーズ)締結
H20.2.5 X･Y、追加開発や各種テスト等の個別契約4(DVL(ディベロップメント)フェーズ)締結
H20.4.20 X･Y、運用テスト等の個別契約5(IMP(インプリメンテーション)フェーズ)締結
H21.1.13 X･Y、プロジェクト中止決定
裁判所は、まず、次の2つをその理由として、システム開発にかかる契約が1つの請負契約であることを前提とする主張は失当である旨を述べました。
「本件基本契約の内容は、本件プロジェクトにおいて締結が予定された各個別契約の種類、内容等を予め定めたものにすぎず、原告と被告は、本件基本契約の締結後、本件システム開発が進行するに応じて、検討フェーズ個別契約ないしIMP個別契約並びに追加開発に係る各個別契約を、それぞれ取引条件をその都度定めた上でそれぞれ別個の契約書を作成して締結したことが認められることからすると、本件基本契約及び各個別契約につき、実質的に見て一個の請負契約が成立したものと評価することはできない。かえって、上記のとおり、本件システム開発における各個別契約は、それぞれ別個の時期に別個の契約書を用いて締結されたことからすれば、これら各個別契約はそれぞれ別個独立の契約として成立したものと認められる。」
次に、裁判所は、本件においては、 プロジェクトが頓挫したことのみをもって各契約全体を解除することは認められず、各個別契約につきそれぞれ個別の解除原因が存在するか否かによってその解除の可否を判断するのが相当である 旨を述べた上で、各個別契約にかかる解除原因は認められないとしました。
なお、後述のとおり、 Yにはプロジェクトマネジメント義務違反は認められるものの、同義務はあくまでも付随的な義務であって、プロジェクトマネジメント義務違反があったことは、本件で解除原因となるものではない 旨を述べています。
「確かに、本件システム開発に関してXY間に締結された各契約は、本件システムの構築に向けた一個のプロジェクトである本件プロジェクトを組成しているものであるとみることができる一面を有するが、他面では、それぞれが上記の各フェーズにおける独自の意義を持つ独立した一個の契約として独自の給付目的を有しているため、その解除原因としての債務不履行事由もそれぞれ別個に観念することができる。したがって、そのような各契約に係る個別の債務不履行事由をなおざりにした上で、単純にそれら契約がその組成要素として位置付けられる本件プロジェクトが頓挫したという一事のみで、これら各契約全体を解除しそれら契約の拘束力から一切解放されるという解除を認めることはできないというべきである。
かような観点からすれば、本件プロジェクトを組成する各個別契約についての解除の可否については、契約ごとに、それぞれの給付目的を中心とする具体的債務内容についての不履行があるか否か、それによって契約の目的を達成することができないなど契約の拘束力を維持するのが相当であるか否か等の諸要素を検討した上で判断するのが相当であるところ、以上のような各契約に係る解除原因を認めるに足りる証拠はない。かえって、前記認定事実に加え、証拠……及び弁論の全趣旨によれば、Yは、検討フェーズからIMPフェーズに至るまでの全ての個別契約のサービス及び納入物に関して、Xから検収を受けるとともに代金の支払を滞りなく受けてきた。そうすると、Yには、上記各個別契約における主たる債務たる給付目的自体に関して債務不履行があったということはできない。また、本件システム開発に関してXY間に締結された各契約は、本件システムの構築に向けて有機的に総合されているものとみることができる点で、後述するような、本件プロジェクトを成功させるための協働関係に入った者としての付随的注意義務を、XY双方に、殊にシステム開発を専門とし知識と経験を有しているYに生じさせるということができるが、それら注意義務は飽くまで信義則に基づく付随的なものであるから、それを根拠として、上記各契約の拘束力を全て解消するような解除を認めることはできないと解するのが相当である。結局、本件においては、上記各契約の拘束力を解消させるべき解除原因を認めることはできない。」
裁判所は、プロジェクトマネジメント義務違反の有無を検討する前提として、本件でYが負っていたプロジェクトマネジメント義務の具体的な内容等について述べています。
ベンダーが負うプロジェクトマネジメント義務の内容について、参考になるものと考えられます。
「Yは、システム開発の専門業者として、Xに対し、本件提案書を提出し、ERPを活用して業務改革を早期に実現するためのアプローチ、組織、役割などについて体系化されたY独自の方法論、システムの企画から保守･運用までを八個のフェーズに分けたシステム開発工程、各フェーズの目的及び主要成果物などの説明、また、Yの業務改革プロジェクトの経験とノウハウを集約した化学産業向けシステム開発に適用するYCMテンプレートの説明、同テンプレートの想定業務プロセスに目標業務プロセスを合わせる形のシステム設計方法など説明をした上で、Xとの間で本件基本契約を締結し、本件プロジェクトを遂行するための協働関係に入った者である。したがって、Yは、自らが有する専門的知識と経験に基づき、本件システム開発に係る契約の付随義務として、本件システム開発に向けて有機的に組成された各個別契約書や本件提案書において自らが提示した開発手順や開発手法、作業工程等に従って自らなすべき作業を進めるとともに、それにとどまらず、本件プロジェクトのような、パッケージソフトを使用したERPシステム構築プロジェクトを遂行しそれを成功させる過程においてあり得る隘路やその突破方法に関する情報及びノウハウを有すべき者として、常に本件プロジェクト全体の進捗状況を把握し、開発作業を阻害する要因の発見に努め、これに適切に対処すべき義務を負うものと解すべきである。そして、システム開発は開発業者と注文者とが協働して打合せを重ね注文者の意向を踏まえながら進めるべきものであるから、Yは、注文者であるXの本件システム開発へのかかわりなどについても、適切に配意し、パッケージソフトを使用したERPシステム構築プロジェクトについては初めての経験であって専門的知識を有しないXにおいて開発作業を阻害する要因が発生していることが窺われる場合には、そのような事態が本格化しないように予防し、本格化してしまった場合にはその対応策を積極的に提示する義務を負っていたというべきである。
具体的には、Yは、Xにおける意思決定が必要な事項や解決すべき必要がある懸案事項等の発生の徴候が認められた場合には、それが本格的なものとなる前に、その予防や回避について具体的にXに対して注意喚起をすべきであるし、懸案事項等が発生した場合は、それに対する具体的な対応策及びその実行期限を示し、対応がされない場合に生ずる支障、複数の選択肢から一つを選択すべき場合には、対応策の容易性などそれらの利害得失等を示した上で、必要な時期までにXにおいて対応することができるように導き、また、Xがシステム機能の追加や変更の要求等をした場合、当該要求が委託料や納入期限、他の機能の内容等に影響を及ぼすときにはXに対して適時にその利害得失等を具体的に説明し、要求の撤回、追加の委託料の負担や納入期限の延期等をも含め適切な判断をすることができるように配慮すべき義務を負っていたということができる。」
そして、裁判所は、システムの権限設定に関する事項につき、Yのプロジェクトマネジメント義務違反を認めました。
「以上の事実関係からすると、前記認定事実のとおり、本件権限方針書には、具体的な権限の設定に当たってはSAPソフトウェアの標準機能で実現することができる範囲で設定して追加開発による機能拡張は行わないという方針が定められていたことを考慮しても、Yとしては、Xが要望する会社の壁や組織の壁の詳細な内容によっては、上記方針がそのまま維持、実現することができるかどうかの隘路となることが予想されるところであるから、それを見極めるための前提として、Xが要望する壁の具体的内容を調査、確認すべきであったことにかわりはなく、会社の壁や組織の壁を設けるというXの要望が明らかになった検討フェーズの段階において、Xの要望する上記の各壁の具体的な内容を調査、確認する付随義務を負っていたにもかかわらず、これを怠った義務違反があるといわざるを得ない。
さらに、SYMフェーズにおいても、Yは、Xが要望する会社の壁や組織の壁に関する具体的内容の調査、確認をすることがなかった。……Xが要望する会社の壁や組織の壁を立てる場合には、開発初期の組織設計やコード設計などの段階から、それなりの検討を行う必要があり、本件プロジェクトにおいても、権限関連定義書の作成等の権限設計の作業は、本来、開発の初期段階であるSYMフェーズにおいてコード設計と一緒に行う必要があったのであり、現に、本件プロジェクト前にXに提示された本件提案書では、権限関連定義書の作成はSYMフェーズで行うことが予定されていたことが認められる。しかしながら、Yは、組織の壁に関する組織の具体的な定義は運用･保守性を考慮してPRTフェーズ以降で決定することと併せて、権限関連定義書の作成をもPRTフェーズに持ち越すこととした。これらの結果、前記認定事実のとおり、会社の壁･組織の壁に関する問題がPRTフェーズに至って初めて発覚することとなり、SYMフェーズではコード設計やパラメータ設計等の作業だけが進行してしまい、次フェーズ以降で後戻りすることが非常な困難な状況に陥ってしまったことが認められる。以上の事実関係からすると、Yとしては、検討フェーズでの付随義務違反に引き続き、SYMフェーズにおいても、会社の壁･組織の壁に関する調査、確認義務を怠ったというべきである。」
また、裁判所は、XがPRTフェーズにおいてプロジェクトを進行させる決定をしていたとしても、その決定の前提として十分かつ正確な情報がXに与えられていたとはいえず、YにはPRTフェーズにおいても、適切な情報提供をしなかったというプロジェクトマネジメント義務違反があったとしました。
「……Yは、……会社の壁や組織の壁を設けることができない情報の一部のみをXに説明するにとどまったことが認められる。そうすると、たとえYからの権限設定に関する説明を聴いたXが、自ら本件プロジェクトを進行させることを決定したとしても、この決定の前提として十分かつ正確な情報がXに与えられていたということはできない。したがって、XがPRTフェーズにおいて本件プロジェクトを進行させることを決定したことをもって、Yに注意義務違反がなかったことにはならず、かえって、同フェーズにおいても、Yは、Xに対し、適切な情報提供をしないというさらなる付随義務違反をしたということができる。」
裁判所は、プロジェクトが頓挫した原因は、権限設定に関し、プロジェクトマネジメント義務違反があったことが一因であると指摘しています。
「そして、PRTフェーズまでの各義務違反の結果、会社の壁や組織の壁に関する適切な調査、分析が行われないままDVLフェーズ及びIMPフェーズに進み、これらフェーズの段階ではもはや後戻りすることができない状態になっており、IMPフェーズにおいて、多数の権限設定の問題が顕在化することとなった。
以上によれば、Yには、権限の設定に関し、Xに本件プロジェクトを中止するとの判断に至らせる原因を生じさせた各付随義務違反があったというべきである。」
続いて、裁判所は、提案書の段階で予定されていたXの業務の網羅的な検討やその業務変更等に伴う影響等の検討等が不十分であったこと等により生じた仕様自体の不適合につき、YがXに対して必要な注意喚起し進言することを怠っていたことや、再検討を促すことを怠ったことに原因がある旨を述べ、Yのプロジェクトマネジメント義務違反を認めました。
「以上の事実関係に照らせば、本件プロジェクトにおける検討フェーズでは、本件提案書で予定されていたような、Xの現行業務の全範囲についての網羅的な検討や、現行業務から目標業務へ移行した場合に生じる業務負荷の定量化による分析をなるべく早い段階で具体的に検討しておくことが肝要であるにもかかわらず、それらは行われておらず、同フェーズにおける検討内容は本件システムを開発するための上流工程における検討としては十分とはいえない内容であったといわざるを得ない。この原因は、これら業務の主担当であったX自身にあるというよりも、むしろ、上記のとおり、現行業務調査等の工程は概略的に行うようXに指導していたYにあるというべきである。そうすると、検討フェーズ個別契約において、Xの現行業務調査や業務変更インパクトの内容検討などにつきXを支援することとされていたYは、信義則上、業務変更に伴う影響をなるべく早い段階で具体的に検討しておくことをXに対して注意喚起し進言すべき付随義務を負っていたにもかかわらずこれに違反したというべきである。」
「このように、YがXのプロジェクト担当者に対してのみ目標業務プロセスフローの精緻化、確認を行うように指示をし、現場の意見をなるべく聞かない方針で本件プロジェクトが進められたことによって、SYMフェーズにおいても、網羅的な現行業務の洗い出しや、現行業務及び現行システムとのフィットアンドギャップ分析は引き続き行われることなく推移し、目標業務プロセスフローの作成･精緻化やこれに基づく課題検討、アドオン要否の検討は網羅的に行われることがなかった。したがって、Yは、SYMフェーズにおいても、業務変更に伴う影響をなるべく早い段階で具体的に検討しておくことをXに対して注意喚起し進言すべき義務に違反したというべきである。」
「さらに、PRTフェーズにおいて、前記認定事実のとおり、Yは、プロトタイピングの準備として、四八％苛性ソーダに関する基本業務プロセスに係る実装を加えた本件デモ機を用意して二回にわたってプロトタイピングを実施した。しかしながら、……PRTフェーズで実施された上記プロトタイピングでは、Xの現場ユーザーが業務の具体的内容をイメージすることができないものであったといわざるを得ない。……X内部では、上記……プロトタイピングでは網羅的に問題を抽出することができないのではないかとの疑問が生じたことから、丙山は、平成一九年一〇月二三日、SYMフェーズにおいて作成した本件棚卸表を戊田リーダーに電子メールで送付して業務把握の網羅性チェックを行うことを進言したにもかかわらず、Yはこれに対して何らの回答もしなかったことが認められる。このように、X自身は本件プロジェクトにおけるプロトタイピングにつき疑義を呈していたのであるから、Yには、Xに対し、本件プロジェクトにおけるプロトタイピングの再検討を促すべき信義則上の義務を負ったと見るべきところ、Yは何らの回答もしなかったのであるから、上記義務の違反があったというべきである。」
裁判所は、プロジェクトが頓挫した原因は、仕様自体の不適合に関し、プロジェクトマネジメント義務違反があったことが一因であると指摘しています。
「そして、PRTフェーズまでの各義務違反の結果、業務変更インパクトに関する網羅的定量的な把握がされないままDVLフェーズ及びIMPフェーズに進んだところ、これらフェーズの段階ではもはや後戻りすることができない状態になっており、IMPフェーズにおいて、多数の権限設定の問題が顕在化することとなってしまった。
以上によれば、Yには、仕様自体の不適合に関し、原告に本件プロジェクトを中止するとの判断に至らせる原因を生じさせた各付随義務違反があったというべきである。」
他方で、裁判所は、システムの品質に問題が生じていたことにつき、XのYに対する不信感を招いたことは否定できないが、システム開発過程で不具合が発生することは不可避であり、かつ、Yも不具合についてほとんど対応していたことから、プロジェクトマネジメント義務違反があったとまではいえない旨を述べています。
「このように、本件システム開発の途上において、本件システムの品質には一定程度の問題があったといわざるを得ず、これがXのYに対する不信感を招いたことは否定することができない。もっとも、システム開発の過程で不具合が発生することは不可避であり、かつ、Yは、本件システム開発が中止されるまでに発見された不具合についてはほとんど対応していた。そうすると、Yにおいて、プログラム品質の問題に関して付随義務の違反があったとまではいうことはできない。」
裁判所は、Yのプロジェクトマネジメント義務違反はあったとはいえ、Yによっていったんは確定した目標業務とシステム要件に基づくシステムが構築されたにもかかわらず、XがX内部の現場ユーザーからの反発を受け、システムに関する仕様変更による対応へと方針転換を行い、多数の仕様変更とそれに伴うプロジェクト遅延が生じ、結果としてXが本件プロジェクトを中止するという決断に至ったことは、基本的にはX内部の要因であるとしました。
「本来、システム開発は開発業者と注文者とが協働して打合せを重ね注文者の意向を踏まえながら進めるべきものであるけれども、前記前提事実のとおり、本件プロジェクトはそもそもSAPソフトウェアの導入に伴うXの業務改革プロジェクトであった。すなわち、フルオーダーメイドでソフトウェアを製作するのであれば、自社の業務フローを変えずにソフトウェアを業務フローに合わせることも可能であるところ、Xは、これを認識しつつも、敢えて現行業務の標準化を推し進める契機とするために、既存ソフトウェアであるSAPソフトウェアを導入して原告の既存業務フローを変える選択をしたのである。確かに、……被告に付随義務違反はあったものの、いったんは確定した目標業務とシステム要件に基づく本件システムが構築された。しかし、Xは、IMPフェーズに至ってX内部の現場ユーザーからの業務改革に対する強い反発を受けこれを抑えることができなくなったために、本件システムにつき仕様変更による対応へと方針転換を行い、多数の仕様変更とそれに伴うプロジェクトの遅延が起こり、結局、Xにおいて本件プロジェクトを中止するという決断に至った。このような経緯は、基本的にはX内部の要因であるといわざるを得ない。」
また、仮にXがプロジェクトを中止しなければ、システムは完成に至っていたであろうとも述べています。
「また、Yは、本件プロジェクトが中止されるまで、本件システム開発に係る業務を継続しており、本件プロジェクト中止までに発見された不具合のほとんどを修正していたことからすれば、仮にXが本件プロジェクトを中止しなければ、本件システムは完成に至っていたであろうともいえる。」
以上を踏まえ、裁判所は、Xが自らの判断でシステム開発を中止するに至ったものであるとして、Yのプロジェクトマネジメント義務違反と相当因果関係のあるXの損害は、Xが請求した賠償額の3割相当額であるとしました。
「以上のように、Xは、基本的にはその内部要因に基づき、本件プロジェクトの方針転換を自ら行い、仮に本件プロジェクトを中止しなければ完成したであろう本件システム開発を自らの判断で中止するに至ったということができる。以上のような事情に照らせば、Yの付随義務違反と相当因果関係のある原告の損害としては、Xが請求する賠償額の三割相当に当たる五億四〇三四万〇二九六円をもって相当と認める。」
裁判所は、Yが主張していた未払委託料の請求につき、契約成立自体に争いのなかったIMPフェーズの延長契約の一部とERP追加開発契約を除き、Y主張の各契約はそもそも締結されていないとしましたが、契約成立が認められなかった部分のうち一部業務に関しては、XのためにYが業務を行っていたことが認められるとして、商法512条に基づく相当報酬請求を認めました。
契約解除が認められる範囲やプロジェクトマネジメント義務違反など、システム開発訴訟としてはよく争点とされる部分が争われており、本裁判例も、これに関連する一つの事例として、非常に参考になるものと思われます。
また、 ベンダーにプロジェクトマネジメント義務違反があったとしても、プロジェクトを中止したユーザーの判断がユーザーの内部要因によるものであれば、実際に支払が認められる賠償額は少なくなる(本件でいえば3割の限度) という意味でも、本裁判例は参考になるものと思われます。
受付: 10:00~18:00 / 土日祝を除く