ホーム > mixiニュース > IT・インターネット > IT総合 > 親会社の意向なので開発中止します。もちろんお金も払いません(IT訴訟解説)

親会社の意向なので開発中止します。もちろんお金も払いません(IT訴訟解説)

1

2019年07月10日 07:12  @IT

  • 限定公開( 1 )

  • チェックする
  • つぶやく
  • 日記を書く

@IT

写真写真

 システム開発プロジェクトは、マラソンのようなものだ。



【その他の画像】



 本物のマラソンは、選手が1人でゴールを目指し、ペースを上げるも落とすも、あるいは体調に異常を来して途中でレースをやめてしまうも、全て本人が判断する。



 しかしシステム開発は、ユーザーとベンダーが協力してゴールを目指す「二人三脚」のようなものだ。どちらかが勝手にペースを変えたりレースをやめたりしてしまうわけにはいかない。



 ゴールを目指して一生懸命足を動かし続けているのに、一緒に走っているパートナーが突然足を止めたら、走り続ける選手は転ぶかもしれない。場合によっては大けがをすることもある。



 同様に、システムの完成を目指して一生懸命作業をしていたベンダーに、ユーザーが突然プロジェクトの中止を申し入れると、ベンダーは財務的な痛手を被ることがある。



 このとき、ユーザーとベンダーの間に正式な契約があれば、ベンダーはユーザーの一方的なプロジェクト中断を糾弾し、損害賠償の請求などを求めることができる。しかし、正式な合意がない場合は、どうなるのか。



 システム開発プロジェクトはしばしば、正式な契約を後回しにして作業を先行させてしまうことがある。そのプロジェクトが途中で頓挫してしまったら、ベンダーはユーザーに何らかの補償を求められるだろうか。



 IT訴訟事例を例にとり、トラブルの予防策と対処法を解説する本連載。今回取り上げるのは、ユーザー上層部の指示で開発が突然中止になった事件だ。



●親会社の承認が得られませんでした



 事件の概要からご覧いただきたい。



---



東京地方裁判所 平成19年11月30日判決から



ある人材派遣会社が開発ベンダーに基幹業務システムの開発を委託した。両者が基本契約を締結した後、ベンダーは最初のフェーズであるフィージビリティスタディー業務と基本設計フェーズ1と呼ばれる作業を実施し、合計代金1億7000万円の支払いを受けた。ここまでの作業については、正式な個別契約の下、実施された。



続いてベンダーは基本設計フェーズ2と呼ばれる作業を開始したが、開始後2カ月弱で、ユーザーより親会社の承認が得られないことを理由に作業を継続できない旨の通知があった。



ベンダーは、その直後、基本設計フェーズ2の見積書(約1億5000万円)を提示し、そこまでに作成した成果物を提出した。しかしユーザーがこの支払いを拒んだため、そこまでに実施した作業の対価などして約1億800万円の支払いを求めて訴訟を提起した。



---



 事件の争点は「基本設計フェーズ2の契約が成立していたのか」になる。



 契約書こそ交わされていないが、ユーザーとベンダーの間に「実質的な合意があった」と認められれば、ユーザーに代金の支払いが命じられるかもしれない。そもそも「親会社の承認が得られない」という理由は、ベンダーには到底納得できないものであり、契約準備段階の不備ともいえる。



 ただ一方で、「契約書がない」ことも事実である。



 両者は「作業内容」についてはおおむね合意している。しかしユーザーは「作業着手」には合意したものの、「費用」については合意がなく、実質的に契約があったとまではいえない状況だった。契約がなければ、債務を履行する(代金を支払う)理由はない――ユーザーは、こう主張をして支払いを拒んだ。



 事件の経緯だけを追うとベンダーの主張の筋が通っているように思える。しかしユーザーは、ベンダーが作業に着手する前に契約には親会社の承認が必要であることを伝えていた。



 現場での会話では、次フェーズの契約を拒まれることなど感じられなかったのかもしれないが、それでも「親会社」というキーワードが出てきた際には、何らかのリスクがあることを考慮しておくべきだったかもしれない。



 では、判決はどうだったのだろうか。



●ベンダー勝訴、だが……



 判決文の続きを見てみよう。



---



東京地方裁判所 平成19年11月30日判決から(つづき)



ベンダーとしては、基本設計フェーズ1の作業終了後である(平成16年)8月には、主にユーザーの担当者などとの打ち合わせなどを通じ、ユーザーにより基本設計フェーズ2についてもそれまでの工程と同様の形で発注行為がなされるものとの強い信頼を有するに至っていたと認められるから、ベンダーとの間で本件基本契約および個別契約を締結して本件プロジェクトを基本設計フェーズ1まで進めてきたユーザーとしては、そのような打ち合わせなどの過程に照らし、信義則上、ベンダーに対し、そのような信頼を裏切って損害を被らせないように配慮すべき義務を負っていたというべきである。



にもかかわらず、ユーザーは、現場責任者において平成16年8月の時点で基本設計フェーズ2の開始を了承し、その後同年10月下旬に本件プロジェクトが凍結となるまで、ベンダーが上記作業を行っていることを認識しながら、これらの作業について注文書が発行されない可能性の有無やその場合にベンダーが負うリスクについて言及することなく、むしろユーザーの現場担当者がベンダーに協力して作業を進めるのを漫然と容認していたのであって、そのようなユーザーの対応は、上記のような信頼を抱いていたベンダーとの関係において、上記信義則上の義務に違反したものと認めるのが相当である。



---



 裁判所はベンダーの主張を認め、ユーザーに支払いを命じた。



 ITベンダーでシステム開発に携わってきた私から見ると、至極まっとうな判決だと感じる。いくら正式な書面がなくても、現場で次のフェーズを期待させる「言動」がなされ、実際、ベンダーが作業をしているのを「認容」、つまり作業をしていることを知りながら、これを「黙認」していたのであれば、突然のプロジェクトの中止はユーザーの信義則違反であり、損害賠償の対象となる。



 裁判所における他の判決を見ても、この「作業をしているのを知りながら、これを黙認している」というユーザーの行動は、事実上の発注と捉えられる可能性が高い。「これを突然中止すれば信義則違反となる」という考え方は、珍しくなくなっている。ユーザー企業の方にはぜひ気を付けていただきたいポイントだ。



 しかし、判決がベンダーの一方的な勝訴だったかといえば、そうではなかった。



●「3割」の内訳



 実は、裁判所はベンダーが求めた賠償額の満額は認めず、3割ほど減じている。



 ことのいきさつを見ても、ベンダーに大きな過失は見受けられない。作業は、ほぼスケジュール通りに進み、そこまでに提示した各種の成果物も、大きな問題はないようだ。細かいところは不明だが、少なくとも判決文を見る限り、ベンダーの作業品質が悪過ぎるためにユーザーの親会社がプロジェクトの中断を決断した、などの話はない。



 ベンダーには取り立てて非は認められない。にもかかわらず、裁判所は支払い額の一部を減じたのだ。果たしてこの「3割」とは何なのだろうか。



---



東京地方裁判所 平成19年11月30日判決から(つづき)



ベンダーは(略)ユーザーからの正式な発注行為がないにもかかわらず各作業に着手しているところ、ベンダーにおいても、信義則上、上記各作業を行う前にユーザーに対し正式発注を求めたり、作業開始後一定期間が経過しても正式発注がなされないのであれば上記各作業を中止したりするなど、損害発生、拡大を防ぐための対応を取ることが期待されていたというべきである。



---



 裁判所は判決文で、「正式な発注がないのであれば、それを求めたり作業を中止したりするなどの損害防止策をとるべきだった」と言っている。そうしたことをしていなかった、いわば「不作為の代償」が「3割」だったといえるだろう。



 しかし、これはなかなかに酷な話だ。私はベンダーにいた経験があるのでよく分かるが、「発注はまだか」と“お客さま”に申し入れても、「手続きが……」「調整が……」となかなか進めてくれないことは多い。そうしている間にも納期が迫ってくるので、作業を止めるわけにもいかない。まして、プロジェクトを中止するなど、現場の判断でそうそうできるわけではない。



 ならば、どうしたらいいのか。



 私の拙い経験を元に幾つかの提言をするならば、第一に、案件を受注するとき、契約書を取り交わすまでは必ず「複数のルート」でユーザーの発注意志を確認しておくことだ。



 今回のケースでもそうだが、ユーザーの現場は本気で発注をするつもりでも、経営層や他の関連部門がネガティブなケースというのは、ままあることだ。それが原因でプロジェクトが中断してしまうことは少なくない。



 確認は営業の役割かもしれないが、現場のエンジニアも、ユーザーのできるだけ多くのルートから発注意志に関する情報を集める姿勢が必要だ。



 第二は、ステアリングコミッティを組成すること。



 前述した通り、プロジェクトの中断は現場のプロジェクトマネジャーには判断できない。その際に発生する損失を受け入れられるか、あるいは損失が出ないように相手側の経営陣と交渉ができる人間(多くは自社経営層)を立て、ユーザーのしかるべき人間といつでも話し合える体制を作っておくことだ。



 第三は、多段階契約を結ぶこと。



 今回の事件は多段階契約を結んでいたので、ベンダーの被害額がある程度抑えられたといっていい。もしこれが一本の契約だったら、第1フェーズからの作業費用全てが回収できなかったかもしれない。



 第四は、「正式な契約の前」に、発注書や覚書あるいは議事録などで、「ある時期までに契約が成立できなければ、そこまでの費用をいったん精算して、再度仕切り直す」よう、取り決めておくことだ。いったんモメだしてからでは遅い。プロジェクトに着手する「前」にしておくことがポイントだ。



 もちろん、これらをやる以前に、正式な契約を結べるよう全力を尽くし、それがない限り、そもそも作業着手はしないというのが、最もあるべき姿だ。



 私が講演などでこうした話をすると、参加しているベンダーから必ず「そうは言っても……」という反応がある。しかし、だからといって最初から諦めていたのでは何も変わらない。まずは、理想の姿を目指して最善を尽くすこと。ベンダーが皆こうした活動を繰り返していけば、ユーザーとの関係も徐々に変わってくるのではないかと期待している。



●細川義洋



政府CIO補佐官。ITプロセスコンサルタント。元・東京地方裁判所民事調停委員・IT専門委員、東京高等裁判所IT専門委員NECソフト(現NECソリューションイノベータ)にて金融機関の勘定系システム開発など多くのITプロジェクトに携わる。その後、日本アイ・ビー・エムにて、システム開発・運用の品質向上を中心に、多くのITベンダーと発注者企業に対するプロセス改善とプロジェクトマネジメントのコンサルティング業務を担当。独立後は、プロセス改善やIT紛争の防止に向けたコンサルティングを行う一方、ITトラブルが法的紛争となった事件の和解調停や裁判の補助を担当する。これまで関わったプロジェクトは70以上。調停委員時代、トラブルを裁判に発展させず解決に導いた確率は9割を超える。システム開発に潜む地雷を知り尽くした「トラブル解決請負人」。2016年より政府CIO補佐官に抜てきされ、政府系機関システムのアドバイザー業務に携わる


    あなたにおすすめ

    ランキングIT・インターネット

    ニュース設定