从法律角度看系统开发中的会议记录保留方法

当一家公司委托另一家公司进行系统开发时，仅凭由代表董事之间用公司印章签署的合同和负责人编制的需求定义文件，往往无法明确地确定到底要做什么以及何时完成。这是因为在许多系统开发中，负责人级别的电子邮件和电话交流，由负责人主持的会议等，每天都在进行初步模糊的部分规格的确定，根据情况变化进行规格更改，添加功能的请求，以及对出现问题的协助请求等。

为了顺利进行系统开发，并从预防万一发生争议的角度出发，为了顺利管理一个系统开发项目，创建和管理文档变得非常重要。

本文将从法律的角度解释如何在系统开发的进度会议等中保留会议记录和会议资料。

为什么文档管理在系统开发中如此重要

在系统开发项目中，记录会议中的交流内容以及项目的进度和经过，从法律的角度来看，这是非常重要的。其原因可以归结为以下两点。

为了避免后期纠纷

系统开发通常是一个涉及用户方和供应商方的多方参与的项目。因此，如果用户方和供应商方对各自的角色和责任有不同的理解，可能会对项目的后期进展产生影响。

另外，由于项目涉及多人参与，换个角度看，这也意味着容易出现“每个人说的都有些不同，不清楚谁说的是正确的”这样的沟通问题。

为了确认双方的理解是否一致，将达成的协议内容整理成文字是有意义的，同时，将其整理成所有相关人员都可以（在各自的时间）查看的资料，有助于保持参与者的步调一致。

顺便提一下，利用法律知识来预防纠纷的发生，这也被称为预防法务。

为了应对后期纠纷

另外，从与预防法务相似但略有不同的角度来解释文档管理的重要性，我们可以考虑到在实际发生纠纷的情况下的“危机管理”。

假设出现了某种问题，项目在成果物完成之前被中断，或者无法按照原定的交付日期完成，甚至可能会引发诉讼。无论是用户方还是供应商方，都可能会说“对于发生的事情，我有我的说法”，但如果没有将记录整理成文字，就无法证明自己的观点，甚至可能在法庭上处于不利的地位。

特别是在由“未能按期交付”引发的问题中，关于其原因，“何时发现了问题”、“何时提出了规格更改的请求”、“对于用户方的功能添加请求，供应商尝试了何种应对”等问题，往往会成为可能影响诉讼结果的重要论点。在这种情况下，如果出现大量的“我说了，你没说”的问题，公平解决纠纷的期望可能会变得渺茫。

系统开发会议记录中特别重要的是什么

系统开发中的会议类型

在系统开发项目中，经常会计划并进行各种会议。这本身并不奇怪，因为这是一个涉及许多人的项目。在开发现场进行程序实现的程序员和工程师也经常会开展定期的进度确认会议。此外，他们可能会查看实际的代码，以确认实现的代码是否存在维护性和安全性等问题，并进行审查。

除了这些开发现场的负责人级别的会议外，公司的董事和有权力的负责人也可能会开会。在这种情况下，会议通常会确定开发项目的总体方向和政策。这种负责人级别的会议，用于“掌握”重要事项，也被称为指导委员会。

特别需要注意的会议是指导委员会

在系统开发现场，根据涉及的人的立场和目的，会计划各种会议，这已经在前文中提到。但是，从法务的角度来看，特别需要重视的会议是指导委员会。与负责人级别的进度确认会议和审查会议等相比，指导委员会在预防各种争议和应对争议发生时的策略方面，特别需要认识到文档化的重要性。这是因为：

1. 由于指导委员会是由负责人级别的人主持的会议，因此往往涉及重要的决策，作为显示用户和供应商双方认识的东西，在法律上也容易被重视。
2. 如果是负责人级别的会议，通常，会议的内容大多会反映在各种设计文档和规格书中，因此实际上很难预见到“缺乏文档”的问题。（当然，如果这些文档的编制也不够充分，那么也需要改进。）

可以列出这些点。

关于指导委员会会议记录的判例

以下，我们将介绍一个案例，其中指导委员会的会议记录在实际的法庭审判中被视为重要的证据。下面引述的判决书中的案例涉及到系统开发项目在中途停滞，供应商方面的项目管理义务违反被认定的情况。在此，会议记录的内容作为供应商和用户各自的初步认识的表现，在法庭审判中也具有非常重大的意义。

供应商指出，根据指导委员会的会议记录确认本案系统开发的进程，会议记录的内容是用户修改过的，不一定反映了工作等的实际情况。然而，指导委员会是为了进行本案系统开发的高级管理层的决策而设立的，供应商和用户双方的本案系统开发的实施负责人参加，进行综合评价，共享进度和工作进展的实际情况和问题，进行重要问题的决策等。并且，对于在那里讨论的要点，供应商应在会议的第二个工作日的上午之前制作会议记录，并在会议记录数据库中注册，通过会议记录记录会议的最终决定事项。在确认会议记录时，供应商和用户在充分认识到通过会议记录记录工作的意义的同时，考虑其内容和表达，作为反映会议实际情况的内容，确认记录内容。可以推定特别是供应商是从事系统开发的人，他们当然熟知这种会议记录制作的意义和方法。因此，可以说确认的会议记录应被视为反映指导委员会的工作实际情况的内容，除非有特殊情况，对于前述工作的进程内容等，应认定在该日期的指导委员会中总结的内容是适当的。

东京高等法院，2013年（平成25年）9月26日

法院的立场是，如果是供应商和用户双方在达成一致后制作的会议的书面记录，那么它可以被视为具有一定推定力的“证据”。从另一个角度来说，如果在会议记录中过于轻易地做出记录，那么这可能会带来直接成为证据的风险，对此我们应该充分注意。

会议记录应具体记载哪些内容

会议记录在可能出现的诉讼中具有重要的证据价值，即使没有诉讼，也有助于双方顺利进行后续的谈判。那么，具体来说，会议记录应该记录哪些内容呢？以下是一些整理出来的内容。

作为供应商应记录的内容

作为供应商，您需要承担项目管理的责任，作为系统开发的专家。关于这个责任的具体内容，可以参考以下的文章。

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

考虑到这些责任，供应商应特别记录的内容包括：

1. 每个开发阶段的完成事实和日期
2. 用户方的规格变更、功能添加等请求的回应历史
3. 由于用户方的自身原因，开发工作进展滞后时，采取的协作请求措施和其过程

以上就是一些可以列举的内容。

关于上述第3点，例如，如果用户方不进行验收，供应商应考虑的问题可以参考以下文章。在下面的文章中，我们引用了实际的判决文，解释了供应商对用户验收的协助程度如何可能大大影响法院的判断。

https://monolith-law.jp/corporate/estimated-inspection-of-system-development[ja]

作为用户方应记录的内容

当然，作为用户，由于是自家使用的系统，您也需要对供应商的开发工作承担一定的协作责任。关于这个责任的整体内容，可以参考以下的文章。

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

1. 用户方向供应商传达的需求功能、界面外观等的历史
2. 供应商工作过程中出现的各种问题的历史（例如，团队成员的突然离职，或者由于供应商的调查不足导致的开发进度延误及其原因等）

关于上述第2点，特别容易发展成不可预见的问题的是，同时废弃旧系统并开发新系统的情况。在将旧系统的数据迁移到新系统时，问题尤其容易发生，关于这些问题的法律问题的详细解释可以参考以下的文章。

https://monolith-law.jp/corporate/the-transition-from-the-oldsystem[ja]

总结

以上就是从法律角度看待系统开发现场会议记录的指导原则。不仅要掌握实务操作方法，还要深化对“法律”、“系统开发”和“文档管理”这些主题之间关联的理解。正因为系统开发容易涉及大量的人员和组织，容易发展为大规模的商业交易，因此，预防和应对相关纠纷就显得尤为重要。从法律角度看，保全证据的必要性使得可以被任何人客观确认的“文档”的存在具有重大意义。

确实，将所有的交流和项目进展完全语言化是一项巨大的负担，也可能并不现实。然而，识别出法律上重要的事项，并适时地将重要事项文档化，这一点无论是否是法律专家，对所有参与商业活动的人来说都应该被广泛认知。