システム開発でのベンダーからユーザーへの謝罪の法律上の意味とは

システム開発に限らず、いわゆるサービス業という業態において、お客様から寄せられる苦情への対応は言うまでもなく重要になります。システム開発においてもこうした話は決して例外ではなく、お客様たるユーザーから寄せられる苦情に、技術サービスの提供を担うベンダーが対応を迫られる場面は間々あるものです。

両者のコミュニケーションを良好にとりもつことを重視すれば、相手の言い分を聞き入れ謝罪することが合理的な場合もあるでしょう。しかし口頭で謝罪を行ったり、文書で謝罪文を提出したりした結果として、ユーザー側の理不尽な主張がそのまま既成事実化してしまうのではないかという懸念を抱いたことがあるという人もいるのではないでしょうか。

本記事では、「ベンダーからユーザーへとなされた謝罪」というものにフォーカスして、それが法律上どのような意味をもつものと理解されるのかについて解説します。

システム開発現場でなぜ「謝罪」が問題となるのか

システム開発はサービス業の一種である

そもそもシステム開発という業務を、アウトソーシングというかたちで外部業者が介入する場合、それは一種の「企業向けのサービス業」であるといえます。あえて法律用語を持ち出すならば、請負契約あるいは準委任契約といったかたちで契約の締結もなされるのが通常です。請負契約と準委任契約の違いについては、以下の記事にて詳細に解説を行っています。

話の要点としては、いずれの場合の契約にしろ、仕事を受けるベンダー側の企業が有している技術力・マンパワー（と、そうした力を背景に生み出されるプロダクト）をもとに売上をだしているという点に変わるところはありません。ベンダー側に属する「人」の力によって提供されるサービスと、それに対応する報酬の交換を旨とする商取引である以上、ITシステムの開発という業務は原則、サービス業の一種であるといえます。

ユーザーが「お客様」であるがゆえに謝罪が求めてくる

システム開発がサービス業であるからには、そこでは苦情・クレームがユーザーから寄せられることも勿論想定されます。同時に、そうしたクレームに的確に対応する力もまた、ベンダーに求められることとなります。たしかに実際問題、各種クレームや苦情に対し、ベンダーが紳士に謝罪等の対応を行うことによって、再度協力体制が構築され、プロジェクトが成功に導かれるといった場合もあるでしょう。

しかし一方で、もしプロジェクトがその後本当に頓挫したような場合において、裁判にまで事案がもつれるような事態を想定してみましょう。ユーザーはベンダー側からの謝罪を根拠として、「ベンダー側も帰責事由を自認している」と主張してくることが考えられます。

そもそもユーザーはどこまでお客様でいられるのかという問題

システム開発というプロジェクトは、たしかにある一面では、「お客様」としてのユーザーと、「外部の業者さん」としてのベンダーという二者間で交わされる商取引です。しかしこうした関係性に納まらない複雑さを持つものがシステム開発にまつわる契約の特徴です。すなわち、お客様たるユーザーもまた、ベンダーの義務に協力していかなければプロジェクトは到底完了できるものではありません。ユーザー側にも一定の協力義務が課され、両者が協働関係に立ってプロジェクトを進めていくべきものであるということは、過去の裁判例においても指摘されていることです。

ベンダーからユーザーに対する「謝罪」をめぐる法律問題を考察する際に、こうした関係性の複雑さを認識しておくことは大切なことでもあります。ユーザーとベンダーの間の関係は、対等なパートナーシップとして、健全なかたちになっていく場合もあれば、「数ある出入り業者の一つ」といった見方をされしまうことも考えられます。ユーザーも協力し、プロジェクトの達成を目指して協働することは法律上の義務でもあるのだという大前提が忘れ去られたときに往々にして顕在化するのが、不当な謝罪要求という問題であるといえます。この点については、その他のサービス業にはあまりみられない、システム開発という業務に固有の特徴であるといえます。

裁判所は「謝罪」をどう見ているのか

では実際に、システム開発をめぐる裁判で、ベンダーからの謝罪はどの程度法律上意味を持つものとして扱われているのかを以下に見ていくことにしましょう。

謝罪をめぐる裁判例１：ユーザーからの土下座の要求

本件では、徹夜作業空けにユーザーのもとへと訪ねた際に、データを消したのではないかとの非難がなされ、土下座させられた後に、ユーザーの言い分に沿って謝罪文を提出したという経緯のものです。しかし裁判所は、そこでの謝罪文に真意はないとの見解を示しました。

Ｈは、この点に関して記載のある謝罪文を作成しているが、それは、徹夜作業の後に、平成１３年１０月４日、原告事務所を訪れた際、一方的に厳しく非難され、土下座させられた後、原告の要求に従い、いったん原告役員らの怒りを沈静化するため、その言い分に従って作成したものであって、Ｈの真意ではないし、同様にＮの作成した謝罪文の趣旨もＮの真意ではない。

東京地判平成１６年４月２３日

非難が「一方的」であった点、「怒りを沈静化」、「真意ではない」といったかたちで、当事者の心情を取り入れた判断を行っている点が特徴だといえるでしょう。

謝罪をめぐる裁判例２：詫び状を書くか2000万円払うかの選択

また以下の事案では、エンドユーザーにもたらされる損害について、詫び状を書くことについてベンダーが合意したとしても、法律上の責任がベンダーに帰責されるべきものであるかの話とは区別すべきとの判断が下されました。

原告の代表者は、右報告書を受け取った後、「これでE社が悪いことがはっきりしたので、詫び状を書くか、ソフトウェアの開発費二〇〇〇万円を負担するかのどちらかにせよ。」という趣旨のことを言い出した。過ぎ被告は、右要求に従い、同年一月一九日付で、右不具合の発生により原告に迷惑を掛けたことを詫びる趣旨の「詫び状」を作成し、これを原告に渡した。

（中略）

E社製品の販売者としてできる限りの対応をしたものとみるべきであり、それ以上の対応をしなかったことをもって、直ちに被告が本件売買基本契約に基づく被告の債務を怠ったということはできない。

東京地判平成８年７月１１日

形式的な詫び状の宛名を誰にするかといった点ではなく、実務のあり方のほうを重視したうえで帰責する対象を見定めるという考え方が判決文からも読み取れるものとなっています。

上記裁判例に共通していえること

上記の裁判例からいえることは、たとえベンダーが形式的に謝罪の要請に応じたとしても、それが現実の裁判において必ずしも決定的な意味を持つわけではないということです。謝罪が行われる理由がビジネス上も、物事を前に進めるための便宜上のものにすぎないことが多いという点は、裁判においても十分斟酌される事情であると考えられます。むしろそうした形式的な謝罪の有無よりは、謝罪が行われた経緯や、謝罪文が書かれた経緯を踏まえて、ユーザーとベンダーの間でどのような人間関係が構築されていたかなども取り入れたうえで総合的な判断を行っていこうとしているのが裁判所のスタンスだとみるべきでしょう。

システム開発において、ユーザーもベンダーに協力する義務があるというのは、そもそも裁判所が示している見解でもあります。ユーザーがベンダーに到底協力的であったとは言い難いような支配的・高圧的な関係があったとみられる事案については、尚更謝罪はかたちだけのものと扱われやすくなるでしょう。

安易に謝罪に応じていいわけではないので注意

もっとも、いざ裁判になった際に、謝罪がそれ単体で決定的な証拠となる場合が少ないからといって、安易に謝罪を行っていいということではありません。安易な謝罪は、裁判に至るまでの交渉場面でも、ユーザー側から頑なな態度を引き出してしまうリスクにもなります。また、裁判の初期の段階で、裁判官が謝罪文を中心に心象を形成してしまえば、誤解を解くのに多くの手間や時間を要することにもなりかねない点も注意しておくべきでしょう。またさらに付言すると、単に謝罪の意を示すという点にとどまらず、謝罪内容や謝罪文の記載内容がベンダーの落ち度を克明に指摘しているような場合には、事実認定の段階で不利な解釈が行われる要素ともなりえます。

いずれにせよ、苦情対応・クレーム対応といった問題それ自体も法務の問題であるという認識をもったうえで、いかにして謝罪を行うべきかという問題についても、外部専門家の活用を積極的に検討すべきでしょう。