在系统开发项目中,经营目标和数值目标的法律含义是什么

系统开发项目往往与企业和工作场所的大规模业务改进密切相关。在这其中，可能需要用户端的企业解决管理问题，或者实现数值目标等，对此，他们可能需要展现出积极贡献的态度。然而，对于这些管理目标的承诺，真的是法律义务吗？数值目标和管理目标的法律含义是什么，这成为了一个问题。本文将解释与系统开发相关的各种“目的”和“目标”所带来的法律问题。

为什么系统开发的目的和目标会成为争议的火种

因为它位于用户的合作义务和供应商的裁量权之间的问题

从商业交易的角度看，系统开发项目有一些特点。一方面，供应商的系统开发项目不是供应商单独可以完成的，而需要用户方的合作。这种义务的存在在判例法上被明确地称为”合作义务”。主要在以下几个阶段，用户也被要求参与系统开发：①需求定义②基本设计③成果物的验收等。

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

另一方面，供应商通常被要求在工作中发挥大的裁量权。有一个法律术语总结了供应商在整个系统开发项目中应做的事情，称为”项目管理义务”。关于这一点，我们在下面的文章中进行了详细的解释。

https://monolith-law.jp/corporate/project-management-duties[ja]

总结以上内容，我们可以指出两个重要的点：

• 用户需要提供必要的信息给供应商，并在实际工作中协助供应商的开发工作。
• 供应商需要理解用户的项目目的和目标，并进行符合这些目标的工作。

由于以上两点的原因，用户在事前的说明中，达成管理目标和数值目标的程度，法律上到底在多大程度上成为供应商的义务，也成为了问题。也就是说，供应商需要将其应做的事情（不是模糊的目标，而是具体的规格）整理出来并提出，这是用户的义务。另一方面，供应商作为专家，也有义务提供用户真正需要的东西，而不仅仅是按照对方的要求去做。这种相互冲突的双方的观点的冲突，也是围绕系统开发的”目标”和”目的”的争议的特点。从法律的角度来看，提供公平的争议解决指导方针，是实际工作中的问题。

用户的目标对项目产生影响的具体场景

系统开发项目往往与企业或工作场所的大规模业务改进和效率提高的措施相联系，因此在项目的规划和提案阶段，往往会进行关于管理问题和管理目标的听证会。在这里，可能会进行关于系统开发带来的成本效益的讨论，以及通过各种数值目标的讨论。

• 由于省力化而减少的人力成本
• 销售额或收益的增加
• 工作时间的缩短

例如，如果上述项目的最终目标是上述项目，供应商可能会在项目前期以咨询师的身份解释系统开发的投资效果，并进行销售。

用户方提出的经营目标成为问题的判例是什么？

然而，供应商通常只是系统开发的专家。如果所有的责任都压在对用户方的经营目标上，那就可能变得过于苛刻了。

目标是提高业务速度的案件

关于这个问题，以下引述的判决书中的案件，项目启动时创建的计划书中记录了启动系统开发项目的目的和目标。然而，实际上系统完成并开始运行后，无法实现这些目的和目标，从而引发了争议。最初的计划书中写明，系统完成并实际使用后，将实现以下状态：

• 将人工输入的时间减少50%
• 使用该IT系统进行办公处理，能在规定的时间内完成

用户因无法最终实现这些目标，试图追究供应商的违约责任和瑕疵担保责任。然而，法院并未接受这一主张（下划线部分和粗体部分是作者添加的）。

然后，（省略）根据辩论的全体意旨，①本案的目的是”提高业务效率”、”建立CRM基础”、”进行可视化管理”等抽象的事物，目标值也是”增加与客户的接触点”、”将行政工作的劳动力分配到内部控制和销售支持”、”能更准确地预测销售”、”抑制过度的销售折扣”等，抽象的事物较多，上述”减少输入时间50%”、”减少估算时间50%”、”法定披露能在法定日期内完成”等目标值，是关于SBO引入后被告的经营管理和业务方式的存在方式，并非作为系统开发公司的原告可以承担的性质的事物，②本案项目启动后的会议记录中，没有具体讨论关于实现本案目的和目标值的内容，③本案项目计划书中，”为了上市”等，使用了不能被认为具有合同性质的表述，（省略）考虑到这些情况，原告基于被告的说明，在本案项目计划书中创建了本案目的的描述，是为了确保本案项目不会失败，是为了获得对本案项目的目的和结果的共同认识，不能认为被告委托原告为实现本案目的进行系统开发。（省略）因此，不能认为原告接受了被告为实现本案目的的系统开发，（省略）违约责任和瑕疵担保责任的主张都没有理由。

东京地方判决，平成22年（2010年）12月28日

从裁判例中解读经营目标和数值目标的法律含义

如本判决所述，系统开发的目的和用数字量化的目标能否实现，通常取决于使用该系统的用户方的经营努力等各种因素。因此，我们应该认为，将这些责任归咎于供应商方的门槛非常高。首先，如果供应商方的违约责任或瑕疵担保责任被认可，那就意味着”目的”或”目标”的实现已经被纳入合同内容的一部分。然而，在本案中，”目的”和”目标”：

• 对于抽象和模糊的目标，由于其性质不符合法律义务，因此认为它们是合同内容的一部分是不合理的
• 对于需要用户方，特别是管理层自我努力的目标，由于供应商方无法控制，因此将其归咎于供应商方是不恰当的，认为它们是合同义务的一部分也是不合理的

这就是本案在法律上得到的评价。

从本判决中进一步解读

本判决中还包含了一些其他的有趣内容。

• 法院考虑到，共享系统开发项目的“目标”或“目标”可能只是用户和供应商为了获得“共同认识”而进行的沟通努力的一部分。
• 在一系列的项目中，考虑到这些“目标”或“目标”是多么的基本元素，会议记录等也被作为参考。

另外，关于系统开发项目相关的法律问题，从文档管理和会议记录的重要性的角度，我们在以下的文章中进行了解释。

https://monolith-law.jp/corporate/the-minutes-in-system-development[ja]

关于经营目标和数值目标的法律问题注意事项

然而，关于这些“目的”和“目标”的法律问题，我们也需要注意以下一些补充事项。

咨询服务是有偿还是无偿，情况会有所不同

如果不仅是系统开发项目，而且还签订了有偿咨询合同，那么情况可能会发生很大变化。如果用户方在不考虑其经营资源的情况下，制定了实现可能性较低的执行计划，那么在该有偿咨询合同部分，可能会被追究债务不履行责任等。

成果物的瑕疵，功能和规格要求的不一致是另一个问题

另外，如果整个“开发”项目本身存在瑕疵，即成果物中确认存在故障或错误，那么我们需要将这些问题与其他问题区分开来。在这种情况下，无需讨论经营上的“目的”和“目标”，主要问题是成果物与所要求的功能要求和规格的一致性。例如，如果系统在事后发现瑕疵，用户方的应对措施在以下文章中有详细解释。

https://monolith-law.jp/corporate/system-flaw-measure-after-acceptance[ja]

此外，还有一些相关话题，例如，虽然没有包含在要求中，但被认为供应商有义务进行实施的事项。关于这一点，我们在以下文章中进行了详细解释。

https://monolith-law.jp/corporate/system-development-specs-function[ja]

无论哪种情况，都应理解为与“目的”和“目标”相关的争议是相似但不同的问题。

对责任和合同等主题的基本理解也会受到质疑

以上，我们对围绕系统开发的“目的”和“目标”展开了法律问题的解释。在这些问题的争议中，法院通常会作为用户和供应商之间协调步伐的努力，作为通信努力的一部分，共享的情况较多，我们认为法院已经充分理解了这一点。然而，即使结论本身的合理性可以通过实践者的现场感觉充分理解，但在达到这一点的过程中，对“责任”和“合同”等事物的基本理解也会受到质疑。关于这些问题，我们在以下的文章中进行了解释。

https://monolith-law.jp/corporate/responsibility-system-development[ja]

我们认为，理解法律责任与模糊的道德责任不同，以及双方当事人的明确“意愿一致”是产生合同责任的因素等，从而获得更本质的理解是非常重要的。