关于系统开发项目成员离职的法律是什么
在系统开发项目中,通常会细分每个工程和任务,并尽可能地进行有计划性的推进。然而,无论我们多么重视计划性,总有一些无法预防的突发问题,尤其是与“人”相关的问题。例如,项目成员突然生病或离职等风险,无论我们多么努力地进行跟进,总是无法完全防止。本文将解释法律如何与项目成员的离职相关。
成员离职与项目管理义务的各论
首先,我们需要明确,在系统开发项目中,供应商被认为有义务全面保障项目的顺利进行。供应商需要对所需的人员、时间、预算和工作量进行估计,并在需要时向用户寻求合作,以便管理项目的进度。这些义务被称为”项目管理义务”,在过去的判例中,其存在已经被反复指出。
https://monolith-law.jp/corporate/project-management-duties[ja]
供应商方面的突然离职者的出现,可以说是供应商项目管理义务问题的一种。例如:
- 负责人因过度加班、节假日工作等长时间劳动导致的身体不适
- 人际关系不和导致的心理压力
在项目中,突然离职者的出现可能有各种原因。但这些基本上是供应商方面的劳务管理问题。因此,即使这些情况最终导致了交货期的延迟等问题,也应认识到免责的可能性很低。也就是说,供应商应该预见到这种突发的空缺的出现,并以计划性的态度进行项目的进度管理。
关于成员离职的重要判例
团队成员的离职导致交付日期延迟的案例
以下引述的法院案例涉及到一个团队成员突然离职后,项目进度无法按计划进行,导致交付日期延迟的情况。在这个案例中,用户方的负责人对供应商方的负责人采取了威胁的态度,也对他们造成了心理压力。
用户方希望追究供应商方因履行延迟而产生的债务不履行责任,而供应商方则希望追究用户方违反合作义务的高压和威胁态度。这个案例在双方之间引发了激烈的争论。
https://monolith-law.jp/corporate/user-obligatory-cooporation[ja]
然而,法院判断,各种情况并不能免除供应商方的项目管理义务,支持了用户方的观点(下划线和粗体部分是作者添加的)。
供应商主张,用户代表对供应商负责人的攻击性、高压的言行,如辱骂等,导致供应商负责人不得不从本案的承包业务中退出。
确实,用户代表在平成15年(2003年)11月的会议中,以强硬的口吻说,“你们是不是没有干劲”,“这个合同就要结束了。我一旦离开这个房间,就结束了。”等,这是因为尽管基本协议规定平成15年(2003年)10月底为原型期间,但是在需求定义书案中,开发目标的附加功能一直没有被包含,即使对提交的需求定义书案进行评论并回答,也没有得到任何回应,这是由于供应商的工作延迟和其对此的应对所导致的,并不能说是过度的言行。
另外,关于C因病从本案的承包合同业务中退出的原因尚不明确,即使是由于本案承包业务的工作压力导致的,基本上应该视为供应商的劳务管理问题,也不能归咎于用户。
东京地方判决,平成19年(2007年)12月4日
在上述法院案例中,法院在考虑到用户方以“强硬的口吻”对供应商方施压的事实后,最终并未免除供应商的责任。这样的判断背后的原因可能是,考虑到供应商方的应对不佳,认为将各种“强硬的口吻”归咎于用户方是不公平的。这是在采用了一个模式,即整个系统开发项目是由供应商的项目管理义务和用户的合作义务共同完成的,但仍然认为不应确认用户违反合作义务。这种含义应该可以从“并不能说是过度的言行”这种表述中看出。
从上述判例中我们可以得出什么
此外,我们还可以得到以下重要的教训:
- 当项目成员因病离职时,如果想要将责任归咎于用户方,那么供应商方需要证明离职是由于用户的原因,这就需要证明因果关系→但是,通常来说,证明存在因果关系并不容易。
- 即使能够证明由于用户的原因导致工作负荷增大,成员生病,但通常,最终这会被视为供应商方的劳务管理问题→如果注意到判决文中使用了“过度行为”这样强烈的措辞,那么我们应该认为,能够免除供应商方劳务管理责任的情况非常有限。
如何应对团队成员离职风险
如上所述,即使在人员突然出现空缺的情况下,将其归咎于用户方也是非常困难的。可能会发生被迫进行大量的额外开发,或者被迫进行强行的规格更改等情况,但在这种情况下,证明身心疾病和各种工作负担的因果关系并不容易。考虑到这些情况,更重要的是在预设项目成员可能因病假或身体不适等问题而出现的情况下,推进人员体制的建设。
如果真的要在法庭上争论这一点,供应商方面将处于非常不利的局面。因此,更重要的是预防这种争端的措施。可能的措施包括以下几点:
建立不让负责人孤立的体制
尽量避免让负责人一个人参加会议,通过建立多人参加会议的体制,可以更容易地预防心理上的孤立。
尽量保持人员配置的余裕
保持人员配置的余裕也是非常重要的。确保有足够的人员虽然会增加成本。但是,如果考虑到因交货期延迟而产生的赔偿成本,以及在处理这些问题的过程中可能产生更多的离职者,从一开始就保持一定的余裕来确保人员可能是更合理的。
在健康状况恶化之前进行配置的重新考虑
如果有一个人离职,其他人员的工作负担将增加,可能会引发更多的离职者,这种恶性循环也是需要担忧的。为了避免这种恶性循环,在健康状况严重恶化之前,重新考虑配置等也是非常重要的。
彻底进行项目的变更管理和文档管理
证明团队成员的离职和用户方的合作义务违反的因果关系并不容易,但即使如此,彻底进行规格变更管理和文档管理也是非常重要的。因为即使不能证明团队成员离职的原因,如果实际上存在导致负责人病假的过度工作的情况,那么可能包含证明用户方违反合作义务的元素。这种情况在项目“燃烧”案件中,即使供应商方面的违约责任或瑕疵担保责任被追究,也可以作为证明过失抵消等正当性的元素。
在以下的文章中,我们对系统开发项目中文档管理的重要性进行了详细的解释。
https://monolith-law.jp/corporate/the-minutes-in-system-development[ja]
特别是关于规格变更这一点,我们在以下的文章中进行了详细的解释。
https://monolith-law.jp/corporate/howto-manage-change-in-system-development[ja]
总结
以上,我们对“团队成员离职”这一现象的法律论述进行了解释。对于供应商来说,对用户进行成员离职责任追究确实在法律上极其困难。
然而,即使存在这样的情况,也不能误解为“在团队成员离职的问题上,法律无法发挥作用”。我们所列出的案例的思考过程本身就是在探讨如何确定“供应商的项目管理义务”和“用户的合作义务”的界限,而且,这些为预防纷争而采取的措施也往往是从预期的纷争场景中反推出来的。
我们不能将“在法庭上争论会处于不利地位”这一点理解为“法律无法发挥作用”,相反,我们应该理解为“预防法务的观点非常重要”。
Category: IT
Tag: ITSystem Development