What are the Points to Note When Entering into a Subcontracting Agreement for System Development?

The contracts concluded in IT system development projects are primarily subcontracting contracts and quasi-mandate contracts. Both for the user and the vendor, there are various advantages and disadvantages to adopting each type of contract. However, it is important to understand their personalityistics and points to note when concluding them. In this article, we will explain about the subcontracting contracts in IT system development work.

System Development and Contracting

What is a Contract?

When understanding what a contract is, the most important thing is to first confirm the requirements for the establishment of a contract directly from the text of the law.

Article 632

A contract is established when one party agrees to complete a certain job, and the other party agrees to pay for the results of that job.

The key term here is “completion of work”. A prime example of a contract is the construction of a building that requires construction work. For instance, the construction of a house or building by a certain deadline is considered “completion of work”, and the obligation is deemed to have been fulfilled. Conversely, if the construction does not progress and is delayed, the responsibility for non-performance of the obligation may be imposed as a delay in performance under certain conditions. However, once the “completion of work” is recognized, there is no longer a problem of non-performance of the obligation, and it becomes a matter of warranty liability for defects. In this sense, the emphasis on the result of “completion of work” is a personalityistic of a contract. For more details on what constitutes “completion of work”, please refer to the following article.

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

Contracts are not only used in construction, but also in large-scale system development projects that require a grand vision and meticulous planning.

Difference between Contract and Quasi-Mandate Contract

Once it is understood that a contract is a type of contract that emphasizes the result of “completion of work”, the personalityistics of a quasi-mandate contract also become clear. This type of contract emphasizes the process rather than the result of “completion”. For example, if the administrative process has been properly carried out regardless of the outcome, it is possible to claim a fee (Article 648, Paragraph 2), and if the performance is terminated midway due to reasons that cannot be attributed to the contractor, it is possible to claim a fee in proportion to that (Article 648, Paragraph 3).

For a detailed comparison of mandate contracts and quasi-mandate contracts, please refer to the following article.

https://monolith.law/corporate/contract-and-timeandmaterialcontract[ja]

Why Contracts are Preferred in System Development

In system development contracts, contracting is used very often. The reason for this is that there are certain advantages for both the user who orders the work and the vendor who receives the order.

Firstly, the advantage for the user in ordering work through a contract is that the requirements for the performance of the obligation can be easily clarified in the form of “completion of work”. In other words, there is a clear understanding that, unless the work is in a state that can be said to be “completed” (even if problems of warranty liability for defects arise later, such as bugs being found), payment of the fee is not required in principle. This can be a great attraction for users who do not want to risk their fees ballooning in cases where the work takes longer than expected or the schedule is delayed. The arrangement of paying a fixed fee in exchange for the “completed” deliverable has great convenience from a budget management perspective.

On the other hand, there can also be certain advantages for the vendor who receives the work in accepting it through a contract. If the contract can be executed smoothly, it can yield a higher profit margin than a quasi-mandate contract.

Since the requirement for the performance of the obligation is to “complete the work”, from the perspective of the party receiving the work, it does not matter how much was spent on the cost of goods (in the case of system development, this is mostly labor costs) in the process leading up to “completion”. In this way, both the vendor who wants to increase their profit margin and the user who wants to make budget management easier have their own motives, and contracts are therefore highly favored in system development.

Points to Consider When Entering into a Contract for Work

While there are benefits to a contract for work for both users and vendors, it’s important to note that entering into such a contract without careful consideration can pose risks, especially for vendors. The requirement for “completion of work” implies that vendors cannot be exempted from liability for non-performance unless the deliverables are completed. This is why there are frequent cases of projects going over budget due to estimation errors on the vendor’s side, forcing them to allocate more resources for delivery.

So, what should you pay attention to in the contract when entering into a contract for work? Let’s take a look at each point.

Clarify the system requirements and acceptance criteria in advance

One of the most important things in a contract for work is, needless to say, to clarify the conditions for “completion of work”. Normally, the requirements for “completion of work” refer to the contents of the agreement made during the requirements definition phase. However, in practice, the requirements for “completion of work” may change as the development process progresses and changes are forced upon retrospectively. It is considered important to document the history of specification changes, including these. The following article explains how to manage changes in system development projects from a legal perspective.

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

In relation to this topic, it is also effective in preventing future troubles to agree in advance on the “acceptance” that the user side will carry out. It is natural to assume situations where the deliverables are ready for delivery, but the person in charge on the user side cannot be reached, or no response is received for a long time. In order not to leave the acceptance undecided indefinitely, it is beneficial to set a certain deadline for acceptance. This is what is called the “deemed acceptance clause”, which is explained in the following article.

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

Agree in advance on whether or not to transfer copyright

Another issue that often arises is the transfer of copyright. While the principle is that the “creator”, i.e., the vendor in the case of system development, acquires the copyright, it is possible to transfer or assign it due to the nature of the right. Therefore, agreeing in advance on whether or not to transfer the copyright to the user can prevent troubles after the fact. The following article provides a detailed explanation of the attribution and transfer of copyright.

https://monolith.law/corporate/copyright-for-the-program-source-code[ja]

Other Points to Note

Furthermore, if you want to conclude a contract as a contract for work without including quasi-delegation elements, you should be aware of the following points:

• Keep the remuneration unrelated to the man-hours
• Clearly state “Contract for Work” in the title of the contract
• Clearly state the warranty liability clause
• Ensure that the payment of remuneration is an equivalent exchange for the results or outcomes

It is important to note that just because the title of the contract says “Contract for Work”, it does not mean that everything becomes a contract for work. In practice, templates of contracts from other companies are often reused without paying attention to whether the contents of the contract are for work or quasi-delegation. If a dispute goes to court, more substantive matters such as the overall content of the contract and past business practices are given more importance than superficial elements such as the wording of the title. You should also be aware of this point.

Summary

By considering the above points, it becomes easier to properly handle contract work through subcontracting. The term “commission” is used in both subcontracting contracts and quasi-mandate contracts. Also, the term “business commission” is typically used when there is an intention between the parties to have a quasi-mandate contract. It would be beneficial to pay attention to these subtle differences in terminology as well.