What is the 'Responsibility' in Law Related to System Development?

The term “responsibility” is commonly used both as a legal term and in everyday conversation. In discussions about business, not limited to system development, the term “responsibility” is often used. In such cases, it is often beneficial to consciously distinguish whether the term is being used in a moral or emotional sense, or whether it is indicating the location of a legal obligation.

In this article, we will explain how the “responsibility” often used to criticize others from a moral or emotional perspective differs from legal responsibility, while organizing various legal responsibilities.

The Relationship Between System Development and ‘Responsibility’

Decision-Making is Fundamental to Legal Responsibility

In the context of “responsibility” under the law, the principle is that some form of decision-making is involved. In other words, the principle is that legal responsibility does not extend to matters that “the individual has not voluntarily assumed as an obligation” or “cannot be changed at the individual’s discretion”. This is most clearly demonstrated in “contracts”. By mutually deciding what obligations to assume and promising them to the other party, fulfilling a contract comes with responsibility and also carries legal enforcement power.

From the perspective of system development, the basic idea is that if there are no detailed provisions in the contract for system development agreed upon by the parties, general laws such as the “Japanese Civil Code” will apply. Understanding this is surprisingly important when understanding troubles or disputes surrounding system development.

“Responsibility” in the Field of System Development

For those involved in system development work, in a sense, the most tangible understanding of legal “responsibility” may be the “project management obligation” for vendors who receive orders, and the “obligation to cooperate” for users who place orders. In other words, as experts in system development, vendors bear responsibility, and users also bear the responsibility to cooperate in development work without treating their own system problems as someone else’s business. For detailed explanations of each responsibility, please also check the following articles.

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

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

The progress of a system development project, to put it positively, is also a collaborative effort to fulfill these obligations mutually. However, if the relationship between the two parties becomes strained, it could potentially turn into a situation where they are, so to speak, “pushing work onto each other”. For example, the following article explains the connection between these two obligations while organizing the flow of matters to be considered afterwards, assuming a case where “the user has proposed to stop the project”.

https://monolith.law/corporate/interruption-of-system-development[ja]

Here, we explain that it is important to be aware not only of pursuing the responsibility of the other party but also of the responsibility that you yourself bear.

The Concept of “Responsibility” in Legal Provisions

While the discussion gradually leans towards law, in cases where responsibility is pursued against the other party in the form of damage claims, the basis must be grounded in various laws, including the Japanese Civil Code. Particularly relevant to the context of system development are the following:

Liability for Non-performance of Obligations

Non-performance of obligations applies when there is a duty (i.e., an obligation) based on a contract, and this obligation is not properly fulfilled. The types of non-performance of obligations include:

• Delay in performance: When the performance is delayed beyond the due date
• Impossibility of performance: When performance becomes impossible
• Incomplete performance: When performance is not in accordance with the main purpose

All of these are attributed to the debtor’s intent or negligence, and are based on the principle of “responsibility” in law.

Warranty Liability for Defects

Warranty liability for defects applies when some kind of defect is discovered after the performance of the obligation. This can be attributed regardless of the other party’s intent or negligence, in the interest of fairness among the contracting parties. Contrary to the liability for non-performance of obligations, which requires the other party’s intent or negligence, this can be pursued even without negligence, making it an exceptional provision.

For example, in a contract for work, once the “completion of work” is recognized, the obligation is considered fulfilled. However, if various defects are found later, it becomes an issue of warranty liability for defects. The connection between “completion of work”, “performance of obligation”, and “warranty liability for defects” in a contract for work is discussed in detail in the following article.

https://monolith.law/corporate/completion-of-work-in-system-development[ja]

Tort Liability

Tort liability is established when someone infringes on the rights of others and there is some intent or negligence on the part of the infringer. A typical example is a traffic accident. There is no contract between the victim and the perpetrator of a traffic accident to “not cause injury by hitting a car”. However, it is considered that the driver has a duty to “not harm others intentionally or negligently” in relation to people other than himself.

However, in most cases where a lawsuit is filed in relation to system development, the cause of the claim is based on liability for non-performance of obligations or warranty liability for defects. Therefore, it is not often that tort liability is involved. This is naturally understandable considering that system development projects are basically conducted between two parties, the user and the vendor, who are in a contractual relationship, and it is difficult to imagine that “infringement of rights, etc.” occurs without assuming this contractual relationship.

Liability Based on the Japanese Product Liability Law

Software is not a “product”, so it is not usually subject to the Japanese Product Liability Law. However, for example, in embedded systems, if a machine with embedded software causes some incident (for example, a software defect causes overheating and burns down a house), it could be considered a liability issue based on the Japanese Product Liability Law.

Moral Responsibility is Different from Legal Theory

By the way, when we talk about “responsibility,” many people may associate it with words like “apology” or “regret.” These are different from the “responsibility” in the sense of legal obligations. Furthermore, we have explained in the following article how an “apology,” as a form of communication in business transactions, can potentially affect legal rights and obligations.

https://monolith.law/corporate/apology-for-system-development[ja]

In this article, we explain that taking on moral obligations in business does not necessarily create room for legal responsibility, based on past court cases and other references.

Summary

In this article, we attempted to organize the laws related to system development from the perspective of “responsibility”. It is important to distinguish between “responsibility” in a moral sense and legal obligations or debts. This distinction is crucial for managing project crises based on legal reasoning rather than emotional arguments.