取りあえず謝っただけなのに、プロジェクト失敗の責任を取らされるんですか：「訴えてやる！」の前に読む IT訴訟 徹底解説（128）（1/2 ページ）

プロジェクトが遅延してお客さまが激おこだ。ここは取りあえず謝っておこう。本当は向こうにも責任があるんだけどな。まあ、いいや。ごめんなさい！！！

[ITプロセスコンサルタント 細川義洋，＠IT]

連載目次

　システム開発が行き詰まったとき、ベンダーが「申し訳ありません。私どもの責任です」と謝罪の言葉を述べるのはよく見る光景だ。読者の中にもそうした場面に立ち会った、あるいはご自身がその当事者となった方も多いのではないだろうか。

　そうした謝罪の中には、本当に自分たちに非があると心からわびている場合もあれば、とにかく相手の怒りを静めたい、早く前に進めたいなどの思いから、「取りあえず謝っておこう」とする場合もあるだろう。しかし、プロジェクトが破綻し裁判などに発展すると、本意ではない謝罪であっても、これを証拠として「ベンダーも非を認めている」との主張につながることがある。

　IT訴訟事例を例にとり、システム開発にまつわるトラブルの予防策と対処法を解説する本連載。今回は、プロジェクトが危機にひんしたときのベンダーの謝罪について考えてみたい。

謝罪は責任を認めた証しとなるのか

　まずは、裁判の概要から見ていこう。

東京高等裁判所 令和6年1月31日判決より

求人情報事業などを行う発注者は、求人の募集要項の自動組版システムをベンダーの持つパッケージソフトウェアをカスタマイズして開発する契約をこのベンダーと結び、開発をスタートさせたが、要件定義開始から2年以上たっても、要件定義のやり直しなどが行われるなどプロジェクトは混乱し、納期を超えて納められたシステムにも多数のバグが生じたことから発注者は契約を解除し、支払い済み代金の返還を求めて訴訟を提起した。

この訴訟において発注者側は、プロジェクトの遅延に対応するための会議の席上でベンダーが述べた謝罪を一つの証拠として示し、失敗の責任はベンダー側にあると主張した。

出典：判例タイムス1533号 90ページ

　発注者が提示したベンダーの謝罪とは、「『Redmine』（プロジェクト管理ツール）やメールなどの内容が全て当時の要件定義書に盛り込まれておらず、現在の不足（追加見積もり）箇所が出ていると認識しています」「この期間の遅れの要因は、弊社（ベンダー）の主担当従業員の退職および人員の不足と、前述の要件整備問題により開発中に度重なる仕様変更を要したことが大きかったと考えています」というものだったようだ。

　推察するにこのプロジェクトでは、要件の取りまとめや仕様変更への対応はベンダーの役割だったようだ。ベンダーは自らがそうした責任を果たし切れなかったことがプロジェクト遅延の原因であると、この時点では謝罪している。

　もちろん裁判では、ベンダーも「こうした謝罪は、責任が全て自分たちにあると認めるものではない」と否定しているが、かなり具体的かつ明確な謝罪であるようにも思える。これを裁判所がどのように扱うのか、謝罪自体がベンダーに責任のあることを示す証しになるのか、興味深いところではある。

　ただ実際は、プロジェクト失敗や遅延などの責任について十分に検討することなくベンダーが謝罪してしまうのはよくあることだ。何といっても客の立場は強い。商売のことを考えれば、「カラスは白い」と言ってしまうことも、ままあるのではないか。この謝罪が、そうした意図で、つまり「自分たちが悪いとは思わないが、取りあえず謝っておこう」という意図で発せられたとしたら、裁判所はこれをどう判断するのだろうか。

　判決の続きを見ていきたい。