关于IT系统数据库相关的法律问题
![关于IT系统数据库相关的法律问题](https://monolith.law/zh-cn/wp-content/uploads/sites/44/2024/05/shutterstock_366193529.webp)
在了解与IT系统相关的法律问题时,不仅需要系统性的法律知识,同时也需要了解IT系统的构成要素。本文将整理IT系统是由哪些部件构成,以及这些部件如何相互关联并发挥功能,并将解释用户难以察觉的数据库以及与之密切相关的法律问题。
IT系统由“界面”和“逻辑”构成
![](https://monolith-law.jp/wp-content/uploads/2019/09/pixta_40551871_M-1024x588.jpg)
什么是IT系统的“界面”
当我们试图了解IT系统的结构时,最容易引人注目的部分可能是界面的外观。确实,在一般的系统开发过程中,继进行功能梳理等“需求定义”之后,通常会进行“界面设计”和“界面转换”的整理。这些界面的外观,对于下达系统开发订单的用户来说,自然是最容易看到的领域,也是用户和供应商之间最容易进行频繁交流的领域。在以下的文章中,我们将解释在系统开发的全过程中,用户为了实现项目的目标,对供应商所承担的“合作义务”。
https://monolith-law.jp/corporate/user-obligatory-cooporation[ja]
本文主要解释了用户在系统开发中所承担的合作义务,特别是在基本设计(即界面)等阶段,需要与供应商协作的点。
在IT系统中,“界面”通常是按照HTML和CSS等计算机语言的规则进行描述的。关于IT系统的“界面”的讨论,有各种各样的称呼,如“前端”、“UI(用户界面)”等,但实际上,主要的论点是从用户的角度看“操作感的良好性”、“易读性”等。
什么是IT系统的“逻辑”
然而,如果IT系统只有“界面”,那么它就只是一个没有任何“动作”或“变化”的“界面”。即使在“界面”上进行用户输入的接收和输出的显示,这个过程也需要“计算处理”。
这些用户看不到的,可以说是“系统的背面”的部分,进行着复杂的计算和控制。从界面端搜索数据、修改数据、添加数据、删除数据等处理,都需要预先构建的数据库作为背景。对数据库信息的各种处理,通常是用被称为SQL的计算机语言来完成的。
通过设置在界面端的按钮等作为触发器,创建到执行必要的SQL语句的路径,这样就可以完成具有动作和变化的系统的全貌。
另外,关于从“界面”看不到的各种逻辑的组装的话题,有时被称为“后端”。
只关注系统“外观”的风险
![](https://monolith-law.jp/wp-content/uploads/2019/09/pixta_19191219_M-1024x837.jpg)
到目前为止的解释构成了(预计在网页上运行的)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系统问题,在系统开发项目中发生的争议中,保持对全局的理解,尤其是在不同行业间的协作中,都是非常重要的。
Category: IT
Tag: ITSystem Development