その顛末書、裁判で不利になるかも？ システム開発における「謝罪と反省」は裁判でどう判断されるのか

「責任は受託者にある」とは限らない

　筆者がよく取り扱っているシステム開発の現場では，発注者であるユーザから、受託者であるベンダに対して、上記のようなクレームが入れられることが少なくありません。スケジュールが遅延し、品質不良が発生しているのであれば、速やかに謝罪し、原因分析・再発防止策を提示するのは当然だと思われるかもしれません。

　しかし、事態はそんなに単純ではありません。システム開発に限らず、プロジェクト型の取引では、両当事者の共同作業としての性質を有することから、スケジュール遅延や品質不良が必ずしも一方当事者のみの責任とは言えないことのほうが通常です。例えば、発注者が提示した仕様が不明確だったり、テストデータの提供が遅れたことが、上記の事態を引き起こした原因だったりすることも珍しくはないのです。

　「謝罪の記録が残ってしまうと、後で不利にならないか」「けれども、謝罪を拒絶し、自己の主張を貫くとプロジェクトが前に進まないのではないか」。現場ではそんな悩みが生じていると思われます。

　紛争対応をしていると、下記のような謝罪や反省の意を示した書面をよく見かけます。そしてそのほとんどすべてはベンダ（受託者）からユーザ（発注者）に差し入れられたものです。現場は悩んだ挙句、こうした書面を提出しているのです。

　しかし、その書面の作成者（ベンダ担当者）から話を聞いてみると、「確かに自分たちには至らない点もあったが、むしろ発注側に非がある。しかし、謝罪を拒絶すると関係が悪化してプロジェクトが前に進まなくなるから、やむなくあのような文書を提出したのであって、本意ではない」といった答えが返ってきます。

　以上のように、どう考えても一方的に自社に非があるというような場合は別として、クレームを入れられた際にどう対応するかというのは悩ましいところです。後から「本意ではない」と言ったところで、それが通用するのかどうかも疑問があります。そこで、この種の謝罪・反省が訴訟の場面でどのような評価を受けたのか、事例を紹介しつつ検討してみたいと思います。

事例から見る、裁判所の判断ポイント

裁判例①：東京高裁平成25年9月26日判決（スルガ銀行vs日本IBM事件控訴審）

　本件は、行き詰まってしまったシステム開発業務において、ベンダが異なる製品を提案した過程で、ベンダの専務らが「当初採用した開発手法が不適切であったなどと謝罪」していたことなどが認定された事例です。少々長いですが、判決文の中から関係個所を引用したいと思います。

　このように、責任者による謝罪の事実は認めつつも、交渉過程という場面や、概括的な結果責任を認めるという内容に着目し、結果的には謝罪の事実をもって義務違反を認定するには至りませんでした（ただし、結論としては本件ではベンダの責任が認められています）。

裁判例②：東京地裁平成25年5月31日判決

　本件では、ベンダがユーザに提出した顛末書を、さらにユーザの意向を受けて書き直して再提出したという事例です。問題となった顛末書には、次のようなことが記載されていました。

　これに対しベンダ（顛末書の作成者＝原告）は、「真意に反して作成させられたから納期遅延に関する責任があったことの根拠とすることはできない」と主張しましたが、裁判所は次のように述べて退けました。

謝罪と反省の違いは？

　裁判例①では、役員クラスの謝罪は結果を概括的に認めるものに過ぎないとして、謝罪があったとしても、義務違反があったということの根拠にはなりませんでした。他方、裁判例②は、詳細な自己分析をした内容であったことも考慮して、顛末書を義務違反の根拠としています。これら2つの個所だけを取り出して見れば、謝罪にとどまればセーフ（ベンダの責任にはならない）ですが、それに加えて具体的な事実を挙げて原因分析したものはアウト（ベンダの責任になる）といえそうです。しかし、そう単純に結論付けることもできません。

　東京地裁平成28年某日判決（判例集未登載＝裁判例③）では、どちらかというと裁判例②に近い内容の分析結果を記した書面がベンダから提出され、その中に「深く反省」「深くお詫び」という表現も含まれていました。しかし、裁判所は他の事情を考慮して、ベンダの責任を否定しました。そして当該書面については、「一般の取引において，立場の弱いベンダー側が，その後のプロジェクトを進行するために，非を認めるかのような内容を含む文書をユーザーに差し入れることも不合理であるとはいえない」として、義務違反を認定するには至りませんでした。

安易な書面提出は要注意

　以上の裁判例からわかるように、裁判所は、自らの債務不履行や過失を認めるような発言・書面があったことをもって、直ちに債務不履行や過失を認定しているわけではありません。しかし、後になって「真意ではない」「書かされた」といった言い分が通ることは期待しがたいことです。システム開発の現場で取引相手との間に立つ担当者やマネージャーが、 取引相手の要望に従って謝罪文を書いてしまったり、プロジェクトの実態をよく確認しないままスタンドプレー的に現場を腐すような書面を出してしまったりすることは大変危険であることに留意する必要があります。また、法務部門としても、こうした書面の意義について現場に注意喚起し、現場の判断のみでこの種のやり取りが行われないようにして、リスクを低減することが重要です。