システム開発にかかる紛争において、ベンダー側がユーザー側に対して、謝罪を行うことがままあります。
稼働時期に間に合わないことが判明した際、ユーザーがベンダーの責任者に対して、謝罪を求めることは珍しくないことです。
では、システム開発訴訟において、ベンダー側の謝罪はどのように扱われるのでしょうか？
ベンダー側が謝罪をすることにより、稼働時期に間に合わないことがベンダーの責任によるものだと、ベンダーが認めたことになってしまうのでしょうか？
先ほども述べたとおり、ベンダーがユーザーに謝罪を行うことはままあります。
しかも、もちろんすべてがベンダーの責任である場合もなくはありませんが、ユーザーに責任があるにもかかわらず、ベンダーのみが謝罪をしてしまうことも珍しくありません。
では、なぜベンダーはユーザーに謝罪をするのでしょうか？
システム開発プロジェクトは、ベンダーとユーザーの協力によって行われる共同作業です。
すなわち、ベンダーとユーザーとの信頼関係で成立しているものといえます。
そして、稼働時期に間に合わないという状態に陥った場合、ユーザーは、その責任が実際にどこにあるかは別として、ベンダーの責任を追及しがちです。
となると、ユーザーは、ベンダーに対して謝罪を求めることも、ユーザーの主観からすれば、そこまでおかしいことでもありません(もちろん、実際はユーザーの責任であることもままあります。)。
そのような場合に、ベンダーがユーザーからの謝罪要求を拒絶すれば、ベンダーとユーザーとの間の信頼関係は破壊され、それまでのプロジェクトが頓挫してしまう可能性があります。
実際にも、ユーザーからの謝罪要求が、プロジェクト頓挫を交渉材料にしている場合も少なくありません。
そして、ベンダーとしては、プロジェクトの継続を希望することが多いでしょうから、「謝罪をしない」という選択肢が現実には採用できないこともあるでしょう。
このような経緯から、ベンダーは、たとえ不本意であったとしても、プロジェクトを頓挫させないため、ユーザーに謝罪をするに至るのです。
すなわち、ベンダーによる謝罪は、とりあえず謝罪しておいてその場をおさめ、プロジェクトを進めていく、といった性質のものであることが珍しくないということです。
では、ベンダーが謝罪をしたことで、ベンダーの不利益が、すなわち、稼働時期に間に合わない責任がベンダーにあることが認められてしまうのでしょうか？
実のところ、裁判例は、ベンダーからの謝罪をほとんど重視していないと言っても過言ではありません。
それでは、いくつかの裁判例を見ていきましょう。
かの有名な、スルガ銀行vs日本IBM事件の東京高裁は、次のように述べ、ベンダー側の謝罪等に重きを置いていません。
「本件システム開発においては､企画･提案段階で想定した開発費用､開発スコープ及び開発期間等に従ってシステム開発を遂行することが極めて困難であることが明らかとなり､その打開を図るために､旧BRD､新BRD､Re-Planを提案し､更には全く別のアプリケーション･パッケージソフトであるTCB採用の提案がされた｡その過程において､控訴人のK専務やP常務執行役員が､当初採用した開発手法が不適切であったなどとして謝罪し､aa社長も､同旨の意向を明らかにする……などしたことが認められる｡
前記発言や意向表明等は､当時の控訴人の責任者によるものであり､当然のことながら契約上の責任等を考える上で無視しがたいものといえ､これら発言等に照らすと､控訴人には､本件システム開発を開始するに先立ち､Corebankの機能や充足度の検証､開発手法の選択の検討等が不足し､許容しがたい誤りがあったのではないかとの疑いが生じ得るところである｡
しかし､前記発言や意向表明等は､いずれも､本件システム開発を企画･提案段階の見込みどおり進めることができず､開発費用の負担､サービスインの時期等をめぐって調整困難な事態に陥ったため､事態を打開するための新たな提案をする交渉過程でされたものであることを考慮する必要がある｡また､その発言等は､困難な事態に至った結果責任を概括的に認める内容のものであり､開発当初の要因によりそのような事態に至ったものかについて､具体的な事実､実証的な分析等に基づいたものとは認めがたい｡前記交渉過程における前記発言や意向表明等の発言､文言等を捉えて､本件システム開発当初選択した開発手法が､システム開発の在り方からすると許容しがたい不適当なものであり､Corebankが邦銀の勘定系システムを担うソフトとして全く適合しないものであったと認めることはできないというべきである｡」
この裁判例は、次の事実を認定し、すなわち、ベンダーが詫び状等を作成してユーザーに交付している事実を認定しながら、裁判所の判断中においてはこの事実に特段触れず、ベンダーの責任を否定しています。
「原告の代表者は、……『……詫び状を書くか、ソフトウェアの開発費2000万円を負担するかのどちらかにせよ。』という趣旨のことを言い出した。被告は、右要求に従い、同年1月19日付で、右不具合の発生により原告に迷惑を掛けたことを詫びる趣旨の『詫び状』を作成し、これを原告に渡した。原告の代表者はそれにも満足せず、そのため被告は、さらに同年1月29日付で、『……の不具合及びご対応に関するお詫び』と題する書面を作成してこれを原告に渡すなどの措置をとった。」
謝罪とはやや異なりますが、ベンダーの自己都合による解約として解約申入書に記載をしたことが、ユーザーとの無用な紛争を回避しようとする趣旨にすぎないとした裁判例も存在します。
「本件解除の意思表示がされた書面に記載された解除理由は、もともとXの求めにより記載されたものにすぎない上、Yとしては、自己都合による解約という穏便な取引終了の体裁を取ることにより、Xとの無用な紛争を回避しようとする趣旨に出たものにすぎなかったから、上記の判断を左右する事情であるとはいえない。」
他方で、謝罪について、ベンダーに責任があることの一事情としてこれを用いた裁判例も存在します。
ただし、謝罪を除いた事情をもってしても、ベンダーに責任があると言い得るような事案であったこともあり、謝罪の有無が結論に影響した事案ではないと言うことが可能でした。
「Yらは、上記書面(註：謝罪する旨を含む書面)について、当初は『仕様の変更と追加の開発があったため。』と記載していたが、これを見たFから記載内容の変更を求められて作成したものであり、その記載内容を信用することはできない旨主張し、上記書面を作成したY1も、これに沿う供述をしている……。
しかし、上記書面の内容はシステム開発の遅延についてA社に責任があることを認めるものであり、このような書面を作成すれば、後にこれを根拠に損害賠償等を請求されることは容易に予測し得ることからすると、仮にXから求めがあったとしても，Y1がこのような内容の書面を作成して交付するとは考え難い。」
以上のとおり、裁判所は、ベンダーの謝罪をあまり重視していないと言っても過言ではありませんし、ベンダーの謝罪が結論を左右するような決め手であると考えていないように思われます。
謝罪をベンダーに責任があることと結びつけた東京地判平成29･2･3ですら、その他の事情を前提に判断したように思われ、また、謝罪自体に過度に重きをおいていません。
裁判所のこのようなスタンスは、ベンダーからの謝罪がプロジェクトを頓挫させないためになされたものであることを十分に了解していることの表れであると考えられます。
他方で、だからといって、安心して謝罪をしても問題がないということではありません。
裁判所も、謝罪を前提に心証を形成してしまうことがありますから、謝罪をしたことによって、ベンダーの不利益に働くこともあり得るからです。
謝罪をするかどうか、謝罪をするにしてもどのような文言の謝罪をするかは、法務や弁護士に相談した上で、慎重に判断すべき事項であると言えるでしょう。
受付: 10:00~18:00 / 土日祝を除く