IT・システム判例メモ

弁護士 伊藤雅浩が,システム開発,ソフトウェア,ネットなどのIT紛争に関する裁判例を紹介します。

ERPパッケージ導入失敗の原因と責任 東京地判平28.4.28(平21ワ34501)

ERPパッケージの導入プロジェクトが頓挫し,その責任の所在が争われた事例。

事案の概要

大手総合化学メーカーXは,基幹系システムの更新を企図し,海外ERPパッケージであるSの導入を決定した。その導入ベンダーとして,コンペの結果,国内有力ベンダーであるYを選定した。当初の導入にかかる総予算は25億円±20%と見積もられた。


平成18年12月,XとYは,基本契約を締結し,以下の6つのフェーズに分けてそれぞれ個別契約を締結して進行することとなった。

  1. 検討フェーズ(方針策定,業務設計)
  2. SYM(システムモデリング)フェーズ(業務要件とシステム要件の確定)
  3. PRT(プロトタイピング)フェーズ(システム全体の設計)
  4. DVL(ディベロップメント)フェーズ(業務詳細化とアドオン開発からシステムテスト
  5. IMP(インプリメンテーション)フェーズ(実績運用テストとマスタ整備)
  6. 保守・運用フェーズ


検討フェーズ,SYMフェーズ,PRTフェーズ,DVLフェーズ,IMPフェーズは,適宜順に実施され,それぞれXが検収し,Yに対し,代金が支払われた。


しかし,パッケージSでは,権限管理が不十分であることのほか,現場ユーザの理解が得られなかったことや,アドオンの品質等が問題となり,平成21年の稼働の延期を決定した。その後,Xは,プロジェクトの中止を決定し,Yに対し,平成21年2月,契約を解除する旨の意思表示をした。


Xは,Yに対し,Yの債務不履行によって,本件システム開発に関して現実に支出した約40億円の損害を被ったが,契約上の賠償限度額である約18億円の支払いを請求した。


これに対し,Yは,反訴請求として,未払いの委託料の請求と,商法512条に基づいて追加で委託された作業の報酬請求の合計約2.3億円の支払いを請求した。

ここで取り上げる争点

本件は,工程ごとに個別契約が締結されて進行したプロジェクトである。上流工程については,検収を終えて支払いも完了していた。また,プロジェクトが頓挫したのは,ユーザにパッケージSの導入の意義が理解されず,プロジェクトメンバーと現場間との意思疎通の問題もあった。そのような中で,Yのいかなる債務の不履行があるかが争点となった。

裁判所の判断

まず,Xの最初の主張である,「基本契約書を取り交わしたことにより,概算17億円とする1個の請負契約が成立した」との点については次のように述べて退けた。

本件基本契約の内容は,本件プロジェクトにおいて締結が予定された各個別契約の種類,内容等を予め定めたものにすぎず,XとYは,本件基本契約の締結後,本件システム開発が進行するに応じて,検討フェーズ個別契約ないしIMP個別契約並びに追加開発に係る各個別契約を,それぞれ取引条件をその都度定めた上でそれぞれ別個の契約書を作成して締結したことが認められることからすると,本件基本契約及び各個別契約につき,実質的に見て一個の請負契約が成立したものと評価することはできない。かえって,上記のとおり,本件システム開発における各個別契約は,それぞれ別個の時期に別個の契約書を用いて締結されたことからすれば,これら各個別契約はそれぞれ別個独立の契約として成立したものと認められる。

したがって,本件システム開発に係る契約に関して1個の請負契約が成立したことを前提とする,仕事完成債務の履行不能に基づく損害賠償請求又は同債務の履行不能解除に基づく原状回復請求はいずれも失当である。


続いて,Xは,Yの責めに帰すべき事由によって本件システムに多数の不具合が生じたのであるから,契約上の債務の不完全履行があると主張したが,裁判所は個別契約の成り立ちや検収の事実に着目して,Xの主張を退けた。

確かに,本件システム開発に関してXY間に締結された各契約は,本件システムの構築に向けた1個のプロジェクトである本件プロジェクトを組成しているものであるとみることができる一面を有するが,他面では,それぞれが上記の各フェーズにおける独自の意義を持つ独立した1個の契約として独自の給付目的を有しているため,その解除原因としての債務不履行事由もそれぞれ別個に観念することができる。したがって,そのような各契約に係る個別の債務不履行事由をなおざりにした上で,単純にそれら契約がその組成要素として位置付けられる本件プロジェクトが頓挫したという一事のみで,これら各契約全体を解除しそれら契約の拘束力から一切解放されるという解除を認めることはできないというべきである。

かような観点からすれば,本件プロジェクトを組成する各個別契約についての解除の可否については,契約ごとに,それぞれの給付目的を中心とする具体的債務内容についての不履行があるか否か,それによって契約の目的を達成することができないなど契約の拘束力を維持するのが相当であるか否か等の諸要素を検討した上で判断するのが相当であるところ,以上のような各契約に係る解除原因を認めるに足りる証拠はない。
かえって,(略)Yは,検討フェーズからIMPフェーズに至るまでの全ての個別契約のサービス及び納入物に関して,Xから検収を受けるとともに代金の支払を滞りなく受けてきた。そうすると,Yには,上記各個別契約における主たる債務たる給付目的自体に関して債務不履行があったということはできない。(略)結局,本件においては,上記各契約の拘束力を解消させるべき解除原因を認めることはできない。


続いて,Xが主張していたのは,Yのいわゆるプロジェクトマネジメント義務違反*1である。


少々長いが,裁判所が認定した規範を引用する。

Yは,システム開発の専門業者として,Xに対し,本件提案書を提出し,ERPを活用して業務改革を早期に実現するためのアプローチ,組織,役割などについて体系化されたY独自の方法論,システムの企画から保守・運用までを8個のフェーズに分けたシステム開発工程,各フェーズの目的及び主要成果物などの説明,また,Yの業務改革プロジェクトの経験とノウハウを集約した化学産業向けシステム開発に適用するTCMテンプレートの説明,同テンプレートの想定業務プロセスに目標業務プロセスを合わせる形のシステム設計方法など説明をした上で,Xとの間で本件基本契約を締結し,本件プロジェクトを遂行するための協働関係に入った者である。
したがって,Yは,自らが有する専門的知識と経験に基づき,本件システム開発に係る契約の付随義務として,本件システム開発に向けて有機的に組成された各個別契約書や本件提案書において自らが提示した開発手順や開発手法,作業工程等に従って自らなすべき作業を進めるとともに,それにとどまらず,本件プロジェクトのような,パッケージソフトを使用したERPシステム構築プロジェクトを遂行しそれを成功させる過程においてあり得る隘路やその突破方法に関する情報及びノウハウを有すべき者として,常に本件プロジェクト全体の進捗状況を把握し,開発作業を阻害する要因の発見に努め,これに適切に対処すべき義務を負うものと解すべきである。そして,システム開発は開発業者と注文者とが協働して打合せを重ね注文者の意向を踏まえながら進めるべきものであるから,Yは,注文者であるXの本件システム開発へのかかわりなどについても,適切に配意し,パッケージソフトを使用したERPシステム構築プロジェクトについては初めての経験であって専門的知識を有しないXにおいて開発作業を阻害する要因が発生していることが窺われる場合には,そのような事態が本格化しないように予防し,本格化してしまった場合にはその対応策を積極的に提示する義務を負っていたというべきである。

他のプロジェクトマネジメント義務が問題となった事例と同様に,ベンダは,進捗管理,課題検出をするとともに,素人であるユーザを適切にリードする義務を負うと述べた。

具体的には,Yは,Xにおける意思決定が必要な事項や解決すべき必要がある懸案事項等の発生の徴候が認められた場合には,それが本格的なものとなる前に,その予防や回避について具体的にXに対して注意喚起をすべきであるし,懸案事項等が発生した場合は,それに対する具体的な対応策及びその実行期限を示し,対応がされない場合に生ずる支障,複数の選択肢から一つを選択すべき場合には,対応策の容易性などそれらの利害得失等を示した上で,必要な時期までにXにおいて対応することができるように導き,また,Xがシステム機能の追加や変更の要求等をした場合,当該要求が委託料や納入期限,他の機能の内容等に影響を及ぼすときにはXに対して適時にその利害得失等を具体的に説明し,要求の撤回,追加の委託料の負担や納入期限の延期等をも含め適切な判断をすることができるように配慮すべき義務を負っていたということができる。


そのうえで,今回問題となった以下の3点について検討した。適宜引用する。


(権限設定に関して)

Yとしては,Xが要望する会社の壁や組織の壁の詳細な内容によっては,上記方針がそのまま維持,実現することができるかどうかの隘路となることが予想されるところであるから,それを見極めるための前提として,Xが要望する壁の具体的内容を調査,確認すべきであったことにかわりはなく,会社の壁や組織の壁を設けるというXの要望が明らかになった検討フェーズの段階において,Xの要望する上記の各壁の具体的な内容を調査,確認する付随義務を負っていたにもかかわらず,これを怠った義務違反があるといわざるを得ない。

権限設定の問題点について,専門家として,適切に検討したり,情報提供したりしなかったことについて,Yの付随義務違反があるとされた。


(仕様の不適合)

この点については,業務負荷の定量化による分析を早い段階で具体的に検討しておくべきだったが,上流工程では不十分な検討しか行われていないこと,それは本来Xの担当業務であったが,Xを指導したYに問題があったといえるとして裁判所は次のように述べて義務違反が認められた。

検討フェーズ個別契約において,原告の現行業務調査や業務変更インパクトの内容検討などにつきXを支援することとされていたYは,信義則上,業務変更に伴う影響をなるべく早い段階で具体的に検討しておくことをXに対して注意喚起し進言すべき付随義務を負っていたにもかかわらずこれに違反したというべきである。


(プログラムの品質)

運用テスト中に不具合が多く発生したことが問題となっていたが,この点についてはYの義務違反が認められなかった。

本件システム開発の途上において,本件システムの品質には一定程度の問題があったといわざるを得ず,これがXのYに対する不信感を招いたことは否定することができない。もっとも,システム開発の過程で不具合が発生することは不可避であり,かつ,Yは,本件システム開発が中止されるまでに発見された不具合についてはほとんど対応していた。そうすると,Yにおいて,プログラム品質の問題に関して付随義務の違反があったとまではいうことはできない。


以上を踏まえ,裁判所は次のように述べて,Xの請求の3割について損害を認めた。

本来,システム開発は開発業者と注文者とが協働して打合せを重ね注文者の意向を踏まえながら進めるべきものであるけれども,前記前提事実のとおり,本件プロジェクトはそもそもSAPソフトウェアの導入に伴うXの業務改革プロジェクトであった。すなわち,フルオーダーメイドでソフトウェアを製作するのであれば,自社の業務フローを変えずにソフトウェアを業務フローに合わせることも可能であるところ,Xは,これを認識しつつも,敢えて現行業務の標準化を推し進める契機とするために,既存ソフトウェアであるSAPソフトウェアを導入してXの既存業務フローを変える選択をしたのである。確かに,上記(3)のとおりYに付随義務違反はあったものの,いったんは確定した目標業務とシステム要件に基づく本件システムが構築された。しかし,Xは,IMPフェーズに至ってX内部の現場ユーザーからの業務改革に対する強い反発を受けこれを抑えることができなくなったために,本件システムにつき仕様変更による対応へと方針転換を行い,多数の仕様変更とそれに伴うプロジェクトの遅延が起こり,結局,Xにおいて本件プロジェクトを中止するという決断に至った。このような経緯は,基本的にはX内部の要因であるといわざるを得ない。また,Yは,本件プロジェクトが中止されるまで,本件システム開発に係る業務を継続しており,本件プロジェクト中止までに発見された不具合のほとんどを修正していたことからすれば,仮にXが本件プロジェクトを中止しなければ,本件システムは完成に至っていたであろうともいえる。
以上のように,Xは,基本的にはその内部要因に基づき,本件プロジェクトの方針転換を自ら行い,仮に本件プロジェクトを中止しなければ完成したであろう本件システム開発を自らの判断で中止するに至ったということができる。以上のような事情に照らせば,Yの付随義務違反と相当因果関係のあるXの損害としては,Xが請求する賠償額の3割相当に当たる5億4034万0296円をもって相当と認める。

つまり,Yに付随義務違反(いわゆるPM義務違反の一種)を認めておきつつ,プロジェクトが頓挫した主因はXにあることから,その賠償範囲は,Xの請求の3割だとした。


Yからの反訴請求の詳細は割愛するが,Yの主張の大部分を認めた。


その結果,XのYに対する本訴請求は約5.4億円,YのXに対する反訴請求は約2.2億円が認容された。

若干のコメント

本件は,ERPパッケージの大規模導入プロジェクトが頓挫したという裁判例です。ERPパッケージ導入の失敗原因としてよく挙げられるのは,業務改革に関する判断のブレ(パッケージに合わせられるかどうか)や,現場ユーザとの意識統一などですが,本件はそうした問題が露呈してしまった事案であるといえます。


本訴請求については,様々な論点がありますが,大ざっぱにまとめると次のような判断がなされています。

  • フェーズ単位での多段階の契約について,一体的な請負契約が成立したものではないこと
  • 各個別契約の解除原因は,それぞれ別個に考えるべきで,プロジェクトが頓挫したという一事のみで,各契約全体を解除できるわけではないこと
  • 上流フェーズについては納入物の研修を受けて代金も支払われており,債務不履行があったとはいえないこと
  • システム開発の専門家であるYは,契約上の付随義務として,開発の阻害要因を検出し,対応策を提示する義務を負っていたこと
  • 権限設定の問題や,業務量の負荷等の調査については,Yに上記付随義務の違反が認められる一方で,多数の不具合があったことについては違反があったとまではいえないこと
  • プロジェクトが頓挫したのは基本的にはX内部の問題であり,Xが中止しなければ,システムは完成に至ってあろうことを考慮すると,Yの付随義務違反との相当因果関係ある損害は,X請求の3割にとどまること


両当事者の代理人は,著名事務所が務めています。他方で,事件番号が平成21年となっているように,一審判決まで7年もの年月がかかっており,この種の紛争を訴訟によって解決することが本当に適切なのかどうかを考えさせられます。

*1:判決文中にはこの用語は登場していないが,その意味するところは同様である。