MONOLITH LAW OFFICE+81-3-6262-3248工作日 10:00-18:00 JST [English Only]

MONOLITH LAW MAGAZINE

IT

在系统开发中,供应商向用户道歉在法律上的含义是什么

IT

在系统开发中,供应商向用户道歉在法律上的含义是什么

不仅在系统开发中,在所谓的服务业中,对客户的投诉的应对无疑是非常重要的。在系统开发中,这种情况绝不是例外,提供技术服务的供应商经常需要应对用户的投诉。

如果重视双方的良好沟通,那么在某些情况下,听取对方的意见并道歉可能是合理的。然而,有些人可能会担心,如果口头道歉或提交书面道歉,用户方的不合理主张可能会变成既定事实。

本文将重点关注”供应商向用户道歉”这一行为,在法律上它被理解为何种含义。

为什么在系统开发现场「道歉」会成为问题

系统开发是一种服务业

首先,如果外部供应商以外包的形式介入系统开发这项业务,可以说这是一种「面向企业的服务业」。如果敢于使用法律术语,通常会以承包合同或类似代理合同的形式签订合同。关于承包合同和类似代理合同的区别,我们在以下的文章中进行了详细的解释。

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

关键在于,无论是哪种合同,接受工作的供应商依靠其技术力量和人力(以及由这些力量产生的产品)来创造收入,这一点是不会改变的。作为商业交易,其目的是交换由供应商的「人」力量提供的服务和相应的报酬,因此,IT系统的开发原则上可以说是一种服务业。

用户作为「客户」,因此会要求道歉

由于系统开发是一种服务业,用户自然会提出投诉和抱怨。同时,供应商也需要有能力准确地应对这些投诉。确实,供应商可能会通过道歉等方式来应对各种投诉和抱怨,从而重建合作关系,使项目成功。

然而,另一方面,如果项目后来真的失败了,我们假设这个问题可能会卷入到法庭。用户可能会以供应商的道歉为依据,主张「供应商也承认了他们的过错」。

问题是用户能够作为客户到什么程度

系统开发这个项目,确实在某种程度上是「客户」的用户和「外部供应商」的供应商之间的商业交易。但是,系统开发合同的特点是,它具有超出这种关系的复杂性。也就是说,作为客户的用户也必须协助供应商的义务,否则项目根本无法完成。用户也有一定的合作义务,双方应该建立合作关系来推进项目,这在过去的判例中也有指出。

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

在考虑供应商对用户的「道歉」的法律问题时,认识到这种关系的复杂性是非常重要的。用户和供应商之间的关系,可能会发展为平等的伙伴关系,也可能被视为「众多供应商中的一员」。当忘记了用户也需要合作,法律上也有义务协助项目的完成这个前提时,往往会出现不合理的道歉要求问题。这可以说是系统开发这项业务的特有特征,这在其他服务业中并不常见。

法院如何看待“道歉”

供应商的道歉可能被视为方便的行为,并不意味着责任会被归咎。

那么在实际的系统开发诉讼中,供应商的道歉在法律上被视为具有多大程度的意义呢?让我们在下面进行探讨。

关于道歉的判例1:用户要求道歉

在这个案例中,被告在连夜工作后访问用户,被指责删除了数据,并在被迫道歉后,按照用户的说法提交了道歉信。然而,法院表示,这份道歉信并非出自真心。

虽然H在这方面编写了道歉信,但这是在连夜工作后,于2001年(平成13年)10月4日访问原告办公室时,被单方面严厉指责,被迫道歉后,按照原告的要求,为了平息原告高管们的愤怒,按照他们的说法编写的,并非H的真心实意。同样,N编写的道歉信的意图也并非N的真心实意。

东京地方判决,2004年(平成16年)4月23日

可以说,这个判决的特点在于,它考虑了当事人的心情,指出指责是“单方面的”,是为了“平息愤怒”,并非“真心实意”。

关于道歉的判例2:选择写道歉信还是支付2000万日元

在以下的案例中,即使供应商同意写道歉信以弥补对终端用户造成的损害,法院也判断应区分这是否应由供应商承担法律责任的问题。

原告的代表在收到右侧报告书后,明确表示“既然已经明确是E公司的错,那么选择写道歉信,或者承担软件开发费用2000万日元。”被告按照这个要求,在同年1月19日,为了道歉给原告带来的不便,写了一封道歉信,并交给了原告。

(中略)

应该认为作为E公司产品的销售商,已经做了尽可能的处理,不能因为没有做更多的处理,就直接认为被告违反了基于本案买卖基本合同的被告的债务。

东京地方判决,平成8年(1996年)7月11日

从判决书中可以看出,不是重视形式上的道歉信的收件人是谁,而是重视实务的方式,并在此基础上确定应承担责任的对象。

对于上述判例的共同点

从上述的判例中我们可以看出,即使供应商在形式上应答了道歉的要求,这并不意味着在实际的法庭上一定会有决定性的意义。道歉的原因往往只是出于商业上或者为了推动事情的进展的便利,这种情况在法庭上也会被充分考虑。相反,比起这种形式上的道歉的存在与否,法庭更倾向于综合考虑道歉的过程,道歉信的写作过程,以及用户和供应商之间建立的人际关系等因素来做出判断。这应该是法庭的立场。

在系统开发中,用户也有义务与供应商合作,这本身就是法院的观点。对于那些用户与供应商之间存在着难以说是合作的支配性和高压性关系的案件,道歉更容易被视为仅仅是形式上的。

注意:不能随便道歉

尽管在诉讼中,道歉往往不会成为决定性的证据,但这并不意味着你可以随意道歉。轻率的道歉在诉讼前的谈判阶段也可能引发用户方的强硬态度,增加风险。此外,在诉讼的初期阶段,如果法官以道歉信为中心形成印象,那么纠正误解可能需要花费大量的时间和精力。再者,如果道歉的内容或道歉信的记载内容明确指出供应商的过失,那么在事实认定阶段可能会产生不利的解释。这些都是需要注意的。

无论如何,我们应该认识到处理投诉和索赔等问题本身就是法务问题,在考虑如何道歉的问题上,我们应该积极考虑利用外部专家的意见。
 

Managing Attorney: Toki Kawase

The Editor in Chief: Managing Attorney: Toki Kawase

An expert in IT-related legal affairs in Japan who established MONOLITH LAW OFFICE and serves as its managing attorney. Formerly an IT engineer, he has been involved in the management of IT companies. Served as legal counsel to more than 100 companies, ranging from top-tier organizations to seed-stage Startups.

Category: IT

Tag:

Return to Top