Key Points to Check in a Contract When Conducting System Development through Semi-Delegation

Currently, the degree of IT utilization in our country’s daily life and socio-economic activities is rapidly increasing due to the dramatic improvement in computer processing capabilities and the widespread use of the internet. As a result, the social impact of business and service disruptions or functional declines due to information system failures is expanding daily, making the improvement of system reliability and safety a significant challenge.

On the other hand, the secondary, tertiary and futher accumulation of contracts for IT system development, which was not anticipated at the time of legislation, tends to make the transaction content unclear. The visualization of transactions based on close communication between the ordering party (user) and the receiving party (vendor), and the clarification of role sharing and responsibility relationships, have become issues.

Also, as information systems are now constructed by a combination of various elements, they have come to include risks related to combinations that did not exist before.

To improve the reliability and safety of such information systems, guidelines have been published by the Ministry of Economy, Trade and Industry, and within them, a model contract for system development is presented, with a commentary provided for each clause.

In this article, we will explain the checkpoints of the contract when concluding a quasi-delegation type of contract in IT system development work, citing the clauses of the model contract of the Ministry of Economy, Trade and Industry.

What are System Development and Quasi-Delegation Contracts?

What is a Quasi-Mandate Contract?

A quasi-mandate contract is defined in the Civil Code by applying the provisions of a mandate contract.

Section 10 Mandate
Article 643: A mandate is established by one party entrusting the other party to perform a legal act, and the other party accepting this, thereby producing its effect.
Article 656: The provisions of this section shall be applied mutatis mutandis to the entrustment of affairs that are not legal acts.

A quasi-mandate contract is a contract in which one party is entrusted by another party to handle affairs. The trustee is obligated to perform the duties with the due care of a prudent manager (duty of care). In simple terms, the duty of care means “doing one’s best”.

Differences from Contract for Work

In a quasi-mandate contract, as mentioned above, the contractor is obligated to exercise due care, but unlike a service-contract for work, they are not obligated to complete the work. Therefore, if there is no clear object, the contractor does not bear the warranty liability for defects. However, since they are obligated to exercise due care, in cases of negligence or fatal lack of attention, they may be liable for damages based on non-performance of obligations, or the contract may be terminated.

As stated above, a quasi-mandate contract does not carry an obligation to complete the work. On the other hand, a service-contract for work does carry an obligation to complete the work.

Model Clauses and Checkpoints for Quasi-Mandate Contracts

Requirements Definition Support Services

(Implementation of Support for Requirement Definition Creation)
Article X: Party B, upon concluding the individual contract stipulated in Article X, shall provide services to support Party A in the creation of requirement definition documents based on the information system concept documents, system planning documents, etc. created by Party A (hereinafter referred to as “Support for Requirement Definition Creation”).

2. Party B shall, based on its specialized knowledge and experience in information processing technology, conduct support services such as research, analysis, organization, proposal, and advice with the care of a good manager to ensure that Party A’s work is carried out smoothly and appropriately.

Requirement Definition is a task that greatly depends on the user’s business content, which involves compiling the requirement definition (functions to be realized by software) of the system that the user intends to build. Therefore, this section assumes a quasi-delegation contract where the user performs the requirement definition work and the vendor supports it. However, just because it is a quasi-delegation does not mean that the vendor bears no responsibility. As a trustee, the vendor has a duty of care, and if this duty of care is neglected and the support for requirement definition creation is not properly provided, the vendor will be liable for breach of contract due to violation of the duty of care.

(Conclusion of Individual Contract for Support for Requirement Definition Creation)
Article X: Party A and Party B shall determine the transaction conditions stipulated in Article X, paragraph X, through consultation, and conclude an individual contract for Support for Requirement Definition Creation.

The scope of the Support for Requirement Definition Creation will be determined by individual contracts in accordance with the conditions indicated in the previous clause.

(Requirement Definition Review Meeting)
Article X: Party A shall hold a contact consultation meeting (hereinafter referred to as “Requirement Definition Review Meeting” in this section) stipulated in Article X at a frequency deemed necessary to clarify or confirm the matters necessary for the creation of the requirement definition document, and Party B shall participate in this meeting and implement the Support for Requirement specification Creation.

2. Party B may also hold a Requirement Definition Review Meeting when it deems necessary for the implementation of the Support for Requirement Definition Creation, and Party A shall participate in this meeting.

In order to create a requirement definition document that defines business requirements and system functional/non-functional requirements, it is necessary to collaborate with the user’s business department, information system department, and vendor. Since this process is quasi-delegated, the first paragraph stipulates that the user is the main body of the meeting and the vendor, who provides support, participates in it. All clarifications or confirmations of matters necessary for the creation of the requirement definition document are conducted at the Requirement Definition Review Meeting, and both the user and the vendor are bound by the results of the discussion at the meeting.

The second paragraph stipulates that the vendor can also hold a Requirement Definition Review Meeting when necessary for the implementation of the Support for Requirement Definition Creation.

(Finalization of Requirement Definition Document)
Article X: When Party A has completed the creation of the requirement definition document, Party A and Party B shall inspect within the period stipulated in the individual contract (hereinafter referred to as “Inspection Period for Requirement Definition Document”) whether the requirement definition document conforms to the decisions made at the Requirement Definition Review Meeting stipulated in the previous article, and as a proof of confirmation of conformity, the responsible persons of both Party A and Party B shall sign and seal the requirement definition document. However, if the inspection results in a judgment that the requirement definition document does not conform to the decisions made at the Requirement Definition Review Meeting, Party A shall create a revised version within the period determined through consultation, and Party A and Party B shall again conduct the above-mentioned inspection and confirmation procedures.

2. The requirement definition document shall be deemed finalized upon confirmation by both Party A and Party B as per the preceding paragraph.

3. If the revision in paragraph X necessitates changes to the conditions of the individual contract such as the work period and the commission fee, the procedures in Article X shall be followed.

Requirement definition is a phase where the requirements necessary for implementing system design, etc. are confirmed after receiving an approximate estimate proposal from the vendor. If the requirements remain ambiguous, it will be difficult for the vendor to make an accurate estimate, and problems may arise in the subsequent development phase. This article stipulates the procedure for the user and the vendor to confirm the requirement definition document, which is the basis for the subsequent development work, and finalize it by signing and sealing by the responsible persons. Since there may be cases where it is judged necessary to revise the requirement definition document in the inspection for finalizing the requirement definition document, the first paragraph provides for the procedure in such cases.

The second paragraph clearly states that the requirement definition document is finalized upon confirmation by both the user and the vendor.
The third paragraph stipulates that necessary changes should be made in case the revision of the requirement definition document by the first paragraph results in changes to the conditions of the individual contract, such as an increase in the vendor’s workload beyond the initial assumption, the need to extend the schedule, etc.

(End of Work and Confirmation)
Article X: Party B shall create a work completion report within X days after the finalization of the requirement definition document stipulated in the previous article and submit it to Party A.

2. Party A shall confirm the said work completion report within the period stipulated in the individual contract (hereinafter referred to as “Inspection Period for the End of Support for Requirement Definition Creation”).

3. If Party A has no doubts about the contents of the said work completion report, Party A shall sign and seal the work completion confirmation document and deliver it to Party B, thereby confirming the end of the Support for Requirement Definition Creation.

4. If Party A does not raise any objections with specific reasons in writing during the Inspection Period for the End of Support for Requirement Definition Creation, Party A shall be deemed to have confirmed the end of the work upon the expiration of the Inspection Period for the End of Support for Requirement Definition Creation.

Since this process is quasi-delegated, this article stipulates the procedure for confirming whether the vendor has properly performed the support work based on the duty of care by using a work completion report that records the work content.
The first paragraph stipulates the obligation to submit a work completion report.
The second paragraph clearly states the inspection period for the report to prevent the confirmation from being delayed.
The third paragraph stipulates that the end of the Support for Requirement Definition Creation is confirmed by the user’s signature and seal on the work completion confirmation document.
The fourth paragraph provides for a deemed confirmation of completion if no written objections are raised by the user during the inspection period. This provision takes into consideration the possibility that if the user does not take the confirmation procedure in a timely manner for some reason, it may cause a delay in the subsequent work or start the subsequent work without clarifying whether the confirmation has been made, which may blur the responsibility relationship between the user and the vendor.

External Design Document Creation Services

(Implementation of External Design Document Creation Support Services)
Article X: Party B shall provide services to support Party A in the creation of the external design document (hereinafter referred to as “External Design Document Creation Support Services”) upon concluding the individual contract stipulated in Article X.

2. Based on specialized knowledge and experience in information processing technology, Party B shall conduct support services such as research, analysis, organization, proposal, and advice with the care of a good manager to ensure that Party A’s work is carried out smoothly and appropriately.

External design document creation is a task that formulates the use of interfaces such as screens and forms. The external design document should, in principle, contain all the information necessary for the vendor to develop the program based on it. The external design document includes detailed content of the format usage, but the user, who determines the business content, can change the requirement specifications.
Therefore, this clause assumes that the user is responsible for completing the external design document, and the vendor is in a position to support the completion of the external design document as the recipient in the quasi-mandate contract.
However, just because it is a quasi-mandate, it does not mean that the vendor has no responsibility at all. The vendor has a duty of care as a recipient. Therefore, if the creation of the external design document is not properly supported as a result of neglecting this duty of care, the vendor may be liable for breach of contract due to violation of the duty of care.

(Conclusion of Individual Contract for External Design Document Creation Support Services)
Article X: Party A and Party B shall determine the transaction conditions stated in Article 4, Paragraph 1 through consultation, and conclude an individual contract for the External Design Document Creation Support Services.

The scope of the External Design Document Creation Support Services will be determined by individual contracts.

(External Design Review Meeting)
Article X: Party A shall hold an External Design Review Meeting (hereinafter referred to as “the Meeting” in this section) at a frequency deemed necessary to clarify or confirm matters necessary for the creation of the external design document, and Party B shall participate in this and implement the External Design Document Creation Support Services.

2. Party B may also hold the Meeting when it deems necessary for the implementation of the External Design Document Support Services, and Party A shall participate in this.

3. If Party A intends to change the content of the requirement definition document as a result of the discussion at the Meeting, and it becomes necessary to change the conditions of the individual contract such as the work period and the commission fee, it shall be done by the procedure of Article X (Change of the content of this contract and individual contract).

Collaborative work between the user and the vendor is essential for creating an external design document that determines interfaces such as screens and forms.
Since this process is a quasi-mandate type, the first paragraph stipulates that the user is the main body of the meeting and the vendor, who provides support, participates. All clarifications or confirmations of matters necessary for the creation of the external design document are conducted at the Meeting, and the vendor and the user are bound by the results of the discussion at the Meeting.
The second paragraph stipulates that the vendor can also hold the Meeting when necessary for the implementation of the External Design Document Support Services.
The third paragraph stipulates that if the user changes the content of the requirement definition document as a result of the discussion at the Meeting, and it affects the work period, commission fee, etc. stipulated in the individual contract, the change of the content of this contract and the individual contract shall be made.

(Confirmation of External Design Document)
Article X: When Party A has completed the creation of the external design document, Party A and Party B shall inspect within the period stipulated in the individual contract (hereinafter referred to as “the inspection period of the external design document”) whether the external design document conforms to the requirement definition document confirmed by the provisions of Article X and the matters decided at the Meeting in the previous article, and as a proof of confirmation of conformity, the responsible persons of both Party A and Party B shall sign and seal the external design document. However, if it is found as a result of the inspection that the external design document does not conform to the requirement definition document confirmed by the provisions of Article X and the matters decided at the Meeting, Party A shall create a revised version within the period determined through consultation, and Party A and Party B shall again conduct the above-mentioned inspection and confirmation procedures.

2. The external design document shall be deemed to have been confirmed by the mutual confirmation of Party A and Party B according to the preceding paragraph.

3. If it becomes necessary to change the conditions of the individual contract such as the work period and the commission fee due to the revision in Paragraph 1, it shall be done by the procedure of Article X (Change of the content of this contract and individual contract).

This clause stipulates the procedure for confirming the external design document created by the user by having the user and the vendor confirm it and having the person in charge sign and seal it.
Since there may be cases where it is judged necessary to revise the document during the inspection for confirming the external design document, the proviso of the first paragraph stipulates the procedure in this case.

The second paragraph clearly states that the external design document is confirmed by the mutual confirmation of the user and the vendor.
The third paragraph stipulates that if it becomes necessary to change the conditions of the individual contract due to the revision of the external design document and the reconfirmation work according to the proviso of the first paragraph, the change of the content of this contract and the individual contract shall be made.

(End of Work and Confirmation)
Article X: Within X days after the confirmation of the external design document stipulated in the previous article, Party B shall create a work completion report and submit it to Party A.

2. Party A shall confirm the work completion report within the period stipulated in the individual contract (hereinafter referred to as “the inspection period for the end of the External Design Document Creation Support Services”).

3. If there is no doubt about the content of the work completion report, Party A shall sign and seal the work completion confirmation document and deliver it to Party B, and confirm the end of the External Design Document Creation Support Services.

4. If Party A does not raise an objection with a specific reason in writing during the inspection period for the end of the External Design Document Creation Support Services, Party A shall be deemed to have confirmed the end of the work at the end of the inspection period.

Since this process is a quasi-mandate type, this clause stipulates the procedure for confirming whether the vendor has properly performed the support work based on the duty of care by confirming the work content recorded in the work completion report.
The second paragraph clearly states the inspection period to avoid prolonging the confirmation of the report.
The third paragraph stipulates that the end of the External Design Document Creation Support Services is confirmed by the user’s signature and seal on the work completion confirmation document.
The fourth paragraph stipulates the deemed confirmation of the end of the work if the user does not raise an objection in writing during the inspection period. This provision takes into consideration the possibility that if the user does not take the confirmation procedure in a timely manner for some reason, it may cause delay in the subsequent work or start the subsequent work without clarifying whether the confirmation has been made, which may make the responsibility relationship between the user and the vendor ambiguous.

Software Development Services

Following the regulations for the system external design process, which is the basic design, are the regulations for the system internal design process, which is the detailed design. In the system internal design process, it is common for the development target and specifications to have been defined in the previous stages of work. Therefore, in the Ministry of Economy, Trade and Industry’s (Japanese Ministry of Economy, Trade and Industry) model contract, it is stipulated as a contract-based type.

Software Operation Preparation and Transition Support Services

(Implementation of Software Operation Preparation and Transition Support Services)
Article X: Party B, upon concluding the individual contract stipulated in Article X, will provide necessary support for Party A in conducting system tests, implementation and acceptance support, and operation tests necessary for the actual operation of the software in question (hereinafter referred to as “Software Operation Preparation and Transition Support Services”).

2. Party B, based on its specialized knowledge and experience in information processing technology, will conduct support services with the care of a good manager to ensure that Party A’s work is carried out smoothly and effectively.

In the following articles, we stipulate the clauses for conducting software operation preparation and transition in a quasi-delegation format. In the system acceptance and implementation support stage, it is common for the user to take the initiative, so in the model contract of the Ministry of Economy, Trade and Industry, it is stipulated as a quasi-delegation format where the user takes the lead and the vendor supports this. The second paragraph stipulates that the vendor, as the delegate, has a duty of care due to the quasi-delegation nature of this process.

(End of Services and Confirmation)
Article 32: Party B will create a service completion report within X days after the end of the Software Operation Preparation and Transition Support Services and submit it to Party A.

2. Party A will inspect the service completion report within the period stipulated in the individual contract (hereinafter referred to as the “inspection period for the end of Software Operation Preparation and Transition Support Services”).

3. If Party A has no doubts about the contents of the service completion report, it will sign and seal the service completion confirmation document, hand it over to Party B, and confirm the end of the Software Operation Preparation and Transition Support Services.

4. If Party A does not express any objections with specific reasons in writing during the inspection period for the end of the Software Operation Preparation and Transition Support Services, the end of the services will be deemed confirmed upon the expiration of the inspection period.

In this article, we stipulate the procedure for checking whether the vendor has properly carried out the Software Operation Preparation and Transition Support Services based on the duty of care in a quasi-delegation format. The second paragraph stipulates that the vendor will submit a service completion report to the user within a certain period after the end of the services. The third paragraph stipulates that the user will check the service completion report after clearly defining the inspection period. The fourth paragraph stipulates a deemed confirmation if the user neglects to confirm the end of the services in the previous two paragraphs.

Determining the Nature of the Contract

To determine the nature of a contract, one must examine the entire contract and consider whether its purpose lies in “delivering a completed product” or if the vendor aims to “carry out the business reasonably.” A general guideline for this consideration is whether the content of the intended finished product has been somewhat concretely defined, and whether the project has been advancing towards that goal.