关于IT系统数据库相关的法律问题

在了解与IT系统相关的法律问题时，不仅需要系统性的法律知识，同时也需要了解IT系统的构成要素。本文将整理IT系统是由哪些部件构成，以及这些部件如何相互关联并发挥功能，并将解释用户难以察觉的数据库以及与之密切相关的法律问题。

IT系统由“界面”和“逻辑”构成

什么是IT系统的“界面”

当我们试图了解IT系统的结构时，最容易引人注目的部分可能是界面的外观。确实，在一般的系统开发过程中，继进行功能梳理等“需求定义”之后，通常会进行“界面设计”和“界面转换”的整理。这些界面的外观，对于下达系统开发订单的用户来说，自然是最容易看到的领域，也是用户和供应商之间最容易进行频繁交流的领域。在以下的文章中，我们将解释在系统开发的全过程中，用户为了实现项目的目标，对供应商所承担的“合作义务”。

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

本文主要解释了用户在系统开发中所承担的合作义务，特别是在基本设计（即界面）等阶段，需要与供应商协作的点。

在IT系统中，“界面”通常是按照HTML和CSS等计算机语言的规则进行描述的。关于IT系统的“界面”的讨论，有各种各样的称呼，如“前端”、“UI（用户界面）”等，但实际上，主要的论点是从用户的角度看“操作感的良好性”、“易读性”等。

什么是IT系统的“逻辑”

然而，如果IT系统只有“界面”，那么它就只是一个没有任何“动作”或“变化”的“界面”。即使在“界面”上进行用户输入的接收和输出的显示，这个过程也需要“计算处理”。

这些用户看不到的，可以说是“系统的背面”的部分，进行着复杂的计算和控制。从界面端搜索数据、修改数据、添加数据、删除数据等处理，都需要预先构建的数据库作为背景。对数据库信息的各种处理，通常是用被称为SQL的计算机语言来完成的。

通过设置在界面端的按钮等作为触发器，创建到执行必要的SQL语句的路径，这样就可以完成具有动作和变化的系统的全貌。

另外，关于从“界面”看不到的各种逻辑的组装的话题，有时被称为“后端”。

只关注系统“外观”的风险

到目前为止的解释构成了（预计在网页上运行的）IT系统结构的基础。对这些事项的理解在法律讨论、项目争议预防、危机管理等方面具有重大意义。具体来说，只关注屏幕“外观”的用户与承担大量重要业务但不易被看见的“逻辑”方面的供应商之间，可能会出现沟通的误解。

用户和供应商关注的焦点完全不同，这就是风险

例如，以“界面”为中心讨论IT系统的用户，往往对其内部结构的复杂性漠不关心。正因为如此，他们往往无法理解，看似“稍微增加一些功能”或“稍微改变一些规格”的事情，实际上会对多少工作流程产生影响。例如，在以下的文章中，我们解释了在进行新系统开发这样的项目时，常常会出现的法律问题，即在废弃当前正在运行的现有系统时。

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

在这里，我们解释了在废弃旧系统并将数据迁移到新系统的过程中，常常会出现的问题。也就是说，内部的计算和控制机制可能比想象中要复杂得多，这可能会给用户带来意想不到的麻烦。此外，由于用户不理解“制作系统的供应商的想法”，因此可能会出现逐渐出现的后期变更的情况。

https://monolith-law.jp/corporate/howto-manage-change-in-system-development[ja]

在这样的情况下，考虑到可能会被要求进行后期的规格变更和功能添加，报酬的后期增加是否可能，有时也可能成为一个严重的问题。

https://monolith-law.jp/corporate/increase-of-estimate[ja]

用户对“逻辑”背后的漠不关心可能带来风险

此外，用户无法观察到的部分，一旦出现问题，可能会变成大事件。以下是这样的例子。

在维护和安全方面可能出现问题的风险

这包括无法实现附加功能，使用过程中逐渐变慢，甚至无法运行的情况。

此外，利用屏幕端实现的代码的缺陷，进行安全攻击，如窃取本不应显示在屏幕上的个人信息和机密信息，这种手法被称为“SQL注入”。关于这种情况引发严重争端的案例，我们在以下文章中进行了详细的讨论。

https://monolith-law.jp/corporate/risks-of-libraryuse-and-measures[ja]

本文的主题是使用框架和库的风险，但我们列出的法院案例是关于使用SQL注入进行攻击的案例。

运营负责人的工作可能无法实现治理的风险

IT系统的用户对背后的“逻辑”不关心，可能导致IT系统的运营负责人的工作难以实现治理。关于这个内容，我们在以下文章中，以“运营负责人的失误导致数据丢失”为主题，解释了处理数据库业务的重要性。

https://monolith-law.jp/corporate/dataloss-risk-and-measures[ja]

即使表面上运行正常，逻辑也可能出错的风险

系统的问题不仅仅在于“屏幕”，即使表面上系统运行正常，实际上的“逻辑”也可能出错。这可能在日常基本业务中并未明显，但在“每半年一次”、“每年一次”等不规则业务中可能突然暴露出来。

在这种情况下，法律上将其视为“一旦系统交付完成，事后发现缺陷的案例”，而不是（债务不履行）而是瑕疵保证责任的问题。

https://monolith-law.jp/corporate/defect-warranty-liability[ja]

如果万一在验收后发现问题，我们在以下文章中详细解释了应对策略。

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

总结

系统开发和法务，对各自进行系统性的理解

关于系统开发的法律问题，不仅需要在确定法律论点的前提下，理解IT系统的构成要素，也需要明确问题出现在哪个部分。无论是法律问题还是IT系统问题，在系统开发项目中发生的争议中，保持对全局的理解，尤其是在不同行业间的协作中，都是非常重要的。