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

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

謝っているから全部悪い、ではない

東京高等裁判所 令和6年1月31日判決より（つづき）

当時の要件定義書に「Redmineやメールなどの内容」の全てが盛り込まれていなかったことは、この要件定義書の交付を受けて検収していた発注者においても認識し、少なくとも認識し得たものである上、本件システムの開発が遅れた要因において、発注者が要件定義書に盛り込まれていなかった事項についての要望を多数行ったことも影響していたことが認められる。

（中略）

上記のように紛争が顕在化した後、事態を打開し今後の交渉を進展させるためにいったんは相手の言い分を認めて謝罪することは、交渉の過程で一般的にあり得ることである。

　裁判所は、ベンダーの謝罪をその責任の証しであるとは認めなかった。

　裁判所の言う通り、ベンダーが「事態を打開し、今後の交渉を進展させるためにいったん謝罪する」ことは一般的にあり得る。また、ベンダーの謝罪も、そこで述べられている事象などが重要な判断材料となることはある。

　だが、それをもってベンダーの非を認める証拠とはならない。少なくともシステム開発を巡る裁判においては、謝罪自体あまり意味を成さないもののようだ。

　私が調停委員、専門委員をしていたときも、「謝っているなら、ベンダーに非があるのだろう」などと思ったことはないし、裁判官との話し合いでも謝罪したことが判断材料になったことがない。それどころか話題になったこともない。

　それよりも「実際の損害とそれを招いた原因と責任を、事実を基に検討する」のが裁判というものであり、裁判所の姿勢だろうと私は思っている。

安易な謝罪がもたらす危険

　ただし、それは裁判まで進んだ場合の話であって、開発現場でベンダーが簡単に頭を下げてしまうことには危険もある。

　判決文によると、ベンダーはRedmineやメールの内容を要件定義書に反映し切れなかったこと、仕様変更が繰り返されたことを自身の責任のようにして謝っている。しかし裁判所はこれを「発注者においても認識し、少なくとも認識し得たものである」とした。

　また、「本件システムの開発が遅れた要因において、発注者が要件定義書に盛り込まれていなかった事項についての要望を多数行ったことも影響していた」と述べて、「開発失敗の責任が一定の割合で発注者にもある」と述べている。つまり、ベンダーは本来、全面的に責任を負う必要のないことまで自身の責任だと謝罪していたことになる。

　システム開発はベンダーと発注者との協業であることは、これまで何度も述べてきた。つまり、ベンダーにはベンダーの、発注者には発注者の役割と責任が存在するのだ。このプロジェクトのようにベンダーがある程度要件の整理や仕様変更の検討を行うにしても、それを確認し、合意し、最終的に「自分たちが発出した要件である」と位置付けるのは、発注者の役割のはずだ。

　ところがこのベンダーは、そうした役割を超えて自分たちが要件の整理や仕様変更の責任を持っているかのような謝罪をしてしまった。本件では裁判所がその当たりを明らかにしてくれたわけだ。だが本来、プロジェクトの役割と責任を専門家であるベンダーが変えてしまうのは危険だ。

　プロジェクトが破綻しそうなとき、ベンダーが謝るのは心情としても分かるし、そうしなければプロジェクトが停止してしまうこともある。しかし、プロジェクトにおける双方の役割や責任を変えてしまうような謝り方には反省の余地が大いにあるように思う。

　無論、謝罪は既にプロジェクトが破綻しかけているときに行われるものであり、その時点で過去の責任をうんぬんしても致し方ない面はある。ただ謝罪の際に、もう一度、契約書上あるいはプロジェクト計画書上の責任分担、役割分担を確認した上で、今後、双方がどのように行動するかをもう一度確認する場があってもよかったのではないかと思う。

　本件で実際にどのようなやりとりがあったのかは知る由もないが、ベンダーだけが役割以上の謝罪をして、その後の責任も過度に重くしてしまうような進め方があるなら、プロジェクト破綻という結果も当然かもしれない。

細川義洋

ITプロセスコンサルタント。元・政府CIO補佐官、東京地方裁判所民事調停委員・IT専門委員、東京高等裁判所IT専門委員

NECソフト（現NECソリューションイノベータ）にて金融機関の勘定系システム開発など多くのITプロジェクトに携わる。その後、日本アイ・ビー・エムにて、システム開発・運用の品質向上を中心に、多くのITベンダーと発注者企業に対するプロセス改善とプロジェクトマネジメントのコンサルティング業務を担当。

独立後は、プロセス改善やIT紛争の防止に向けたコンサルティングを行う一方、ITトラブルが法的紛争となった事件の和解調停や裁判の補助を担当する。これまでかかわったプロジェクトは70以上。調停委員時代、トラブルを裁判に発展させず解決に導いた確率は9割を超える。システム開発に潜む地雷を知り尽くした「トラブル解決請負人」。

2016年より政府CIO補佐官に抜てきされ、政府系機関システムのアドバイザー業務に携わった

個人サイト：CNI IT アドバイザリ

書籍紹介

本連載が書籍になりました！

成功するシステム開発は裁判に学べ!〜契約・要件定義・検収・下請け・著作権・情報漏えいで失敗しないためのハンドブック

細川義洋著　技術評論社　2138円（税込み）

本連載、待望の書籍化。IT訴訟の専門家が難しい判例を分かりやすく読み解き、契約、要件定義、検収から、下請け、著作権、情報漏えいまで、トラブルのポイントやプロジェクト成功への実践ノウハウを丁寧に解説する。

エンジニアじゃない人が欲しいシステムを手に入れるためにすべきこと

細川義洋著　ソシム 　2420円（税込み）

1mmも望んでいないDX室への異動を命じられた主人公が、悪戦苦闘、七転八倒、阿鼻叫喚を繰り広げながら、周囲を巻き込んで「欲しいシステム」を手に入れるまでを8つのストーリーで解説。システムの開発工程に沿って、必要なノウハウと心構えを体得できます。

システムを「外注」するときに読む本

細川義洋著　ダイヤモンド社　2138円（税込み）

システム開発に潜む地雷を知り尽くした「トラブル解決請負人」が、大小70以上のトラブルプロジェクトを解決に導いた経験を総動員し、失敗の本質と原因を網羅した7つのストーリーから成功のポイントを導き出す。

プロジェクトの失敗はだれのせい？ 紛争解決特別法務室“トッポ―"中林麻衣の事件簿

細川義洋著　技術評論社　1814円（税込み）

紛争の処理を担う特別法務部、通称「トッポ―」の部員である中林麻衣が数多くの問題に当たる中で目の当たりにするプロジェクト失敗の本質、そして成功の極意とは？

「IT専門調停委員」が教える モメないプロジェクト管理77の鉄則

細川義洋著　日本実業出版社　2160円（税込み）

提案見積もり、要件定義、契約、プロジェクト体制、プロジェクト計画と管理、各種開発方式から保守に至るまで、PMが悩み、かつトラブルになりやすい77のトピックを厳選し、現実的なアドバイスを贈る。

なぜ、システム開発は必ずモメるのか？

細川義洋著　日本実業出版社　2160円（税込み）

約7割が失敗するといわれるコンピュータシステムの開発プロジェクト。その最悪の結末であるIT訴訟の事例を参考に、ベンダーvsユーザーのトラブル解決策を、IT案件専門の美人弁護士「塔子」が伝授する。