在系統開發中,供應商對使用者道歉在法律上的意義是什麼

不僅限於系統開發，對於所謂的服務業，對於客戶提出的投訴的回應無疑是非常重要的。在系統開發中，這種情況絕不例外，提供技術服務的供應商經常需要對用戶的投訴進行回應。

如果重視雙方的溝通，那麼在某些情況下，聆聽對方的意見並道歉可能是合理的。然而，有些人可能擔心，口頭道歉或提交書面道歉信的結果，可能會使用戶方的不合理主張成為既定事實。

本文將專注於「供應商對用戶的道歉」，並解釋在法律上這種行為被理解為何種意義。

為何在系統開發現場「道歉」會成為問題

系統開發是服務業的一種

首先，當外部供應商以外包的形式介入系統開發這項業務時，可以說這是一種「針對企業的服務業」。如果要引用法律術語，通常會以承包合約或準委託合約的形式簽訂合約。關於承包合約和準委託合約的區別，本所在以下的文章中進行了詳細的解釋。

https://monolith-law.jp/corporate/contract-and-timeandmaterialcontract[ja]

話題的重點是，無論是哪種合約，接受工作的供應商擁有的技術力量和人力（以及由這些力量產生的產品）都是其營業收入的來源，這一點是不會改變的。由於供應商提供的服務是由「人」的力量提供的，並且交換相應的報酬，因此，IT系統的開發業務原則上可以說是服務業的一種。

用戶因為是「客戶」，所以會要求道歉

由於系統開發是服務業，因此，用戶自然會提出投訴和抱怨。同時，供應商也需要有能力適當地應對這些投訴。確實，供應商可能會通過對各種投訴和抱怨進行道歉等回應，重新建立合作關係，並導致項目成功。

然而，另一方面，如果項目在之後真的中止了，並且情況甚至發展到需要進行訴訟的地步，本所可以想象，用戶可能會以供應商的道歉為依據，主張「供應商也承認了他們的責任」。

問題在於用戶能夠作為客戶到何種程度

系統開發這種項目，確實在某種程度上是「客戶」的用戶和「外部供應商」之間的商業交易。然而，系統開發合約的特點是，它具有超越這種關係的複雜性。也就是說，作為客戶的用戶也必須協助供應商履行其義務，否則項目將無法完成。用戶方也有一定的協助義務，雙方應該共同推進項目，這一點在過去的判例中也有指出。

https://monolith-law.jp/corporate/user-obligatory-cooporation[ja]

在考慮供應商對用戶的「道歉」的法律問題時，認識到這種關係的複雜性是非常重要的。用戶和供應商之間的關係，有時可能會發展成為平等的夥伴關係，有時可能會被視為「眾多供應商之一」。當人們忘記了用戶也有法律義務協助並共同努力實現項目的這一前提時，不合理的道歉要求問題就可能顯現出來。這一點可以說是系統開發這種業務所特有的特點，這在其他服務業中並不常見。

法院如何看待「道歉」

那麼實際上，在關於系統開發的訴訟中，供應商的道歉在法律上被視為何種程度的意義呢？讓本所以下面的例子來看。

關於道歉的訴訟例1：用戶要求跪地道歉

在這個案例中，供應商在熬夜工作後訪問用戶，被指責可能刪除了數據，被迫跪地道歉，然後根據用戶的要求提交了道歉信。然而，法院認為這份道歉信並無真誠之意。

Ｈ製作了關於這一點的道歉信，但這是在熬夜工作後，於2001年（平成13年）10月4日訪問原告辦公室時，被單方面嚴厲指責，被迫跪地道歉後，按照原告的要求，為了平息原告高層的憤怒，按照他們的說法製作的，並非Ｈ的真實意願，同樣，Ｎ製作的道歉信的意義也並非Ｎ的真實意願。

東京地方裁判所2004年（平成16年）4月23日

可以說，特點在於考慮到了「單方面的指責」、「平息憤怒」、「並非真實意願」等形式，並將當事人的心情納入判決。

關於道歉的訴訟例2：寫道歉信或支付2000萬日元的選擇

在以下的案例中，即使供應商同意寫道歉信以彌補給最終用戶的損害，也應該區分是否應該將法律責任歸咎於供應商。

原告的代表在收到右側的報告書後說出了「現在已經清楚E公司是壞的，所以寫一封道歉信，或者承擔軟件開發費用2000萬日元」的意思。被告遵從了這一要求，於同年1月19日製作了一封「道歉信」，道歉信的內容是對由於右側的故障對原告造成的困擾表示道歉，並將其交給了原告。

（中略）

應該認為作為E公司產品的銷售商，已經做了盡可能的對應，並不能因為沒有做出更多的對應就認為被告違反了基於本件銷售基本契約的被告的債務。

東京地方裁判所1996年（平成8年）7月11日

不僅僅是形式上的道歉信的收件人，而是重視實務的方式，並確定應該負責的對象，這種思考方式可以從判決書中讀出。

上述訴訟例子的共同點

從上述的訴訟例子可以看出，即使供應商形式上回應了道歉的要求，這在實際的訴訟中並不一定具有決定性的意義。道歉的原因往往只是為了便利的商業行為，或者為了推進事情的進行，這一點在訴訟中也會被充分考慮。相反，比起這種形式上的道歉的存在與否，更應該考慮的是，基於道歉的經過和道歉信的製作經過，用戶和供應商之間建立了怎樣的人際關係，並在此基礎上進行綜合判斷，這應該是法院的立場。

在系統開發中，用戶也有義務協助供應商，這本來就是法院的觀點。對於那些被認為存在支配性、高壓性關係，使得用戶難以說是對供應商有協助的案例，道歉更容易被視為僅僅是形式上的。

注意不要輕易答應道歉

然而，即使在訴訟中，道歉本身很少成為決定性的證據，也不意味著可以輕易地進行道歉。輕率的道歉可能在訴訟之前的談判中引發用戶的固執態度，也可能在訴訟的初期階段，讓法官以道歉信為中心形成印象，需要花費大量的時間和精力來解釋誤解。此外，如果道歉的內容或道歉信的內容詳細指出了供應商的過失，那麼在事實認定階段可能會成為不利解釋的因素。

無論如何，應該認識到，處理投訴和索賠等問題本身就是法務問題，並考慮如何進行道歉，積極考慮利用外部專家。