Key Points to Check in Contract Documents for Contracted System Development

Japan’s Ministry of Economy, Trade and Industry (METI) has provided model clauses for IT system development contracts in its “Guidelines for Improving the Reliability of Information Systems.” Due to the spread of the Internet and other factors, the social impact of business and service disruptions or declines in functionality due to information system failures is becoming increasingly serious. While the enhancement of system reliability and security is an urgent issue, IT system development contracts tend to lack clarity in their transaction details. Therefore, these guidelines aim to clarify and visualize roles and responsibilities. In this article, I will explain the checkpoints in the contract document when entering into a contracted development agreement for IT system development, referring to the clauses of METI’s model contract.

System Development and Contracted Agreements

A contracted agreement is when one party promises to complete a certain job, and the other party promises to pay for the results of that job.

What is a Contracted Agreement?

A contracted agreement is defined under Japanese Civil Law as follows:

Article 632 A contract is formed by one party promising to complete a certain job, and the other party promising to pay for the results of that job, thus giving effect to its obligations.

In a contracted agreement, the requirement is to “promise to complete a job.” For example, if the purpose of the contract is to create a specific system by a deadline, the vendor’s obligation becomes “to complete the system by the deadline.” If the system cannot be completed by the promised date, there may be liability for non-performance due to delay. However, if deficiencies are found after completing and delivering the system by the deadline, since the vendor’s obligation has already been fulfilled, non-performance is not an issue, and it becomes a matter of warranty liability for defects.

Difference from Quasi-Mandate Contracts

In a contracted agreement, the vendor has an obligation to complete the work, and if there are defects in the delivered product, they bear the warranty liability for those defects. In contrast, in a quasi-mandate contract, there is no obligation to complete the work, so there is no such liability for defects like in a contracted agreement. However, if a duty of care is recognized in the process of handling affairs, there may be separate liability for non-performance, such as damages.

Model Clauses and Checkpoints for Contracted Agreements

Support for Creating Requirement Definitions

Requirement definition is the task of summarizing the system requirements that users intend to build. In the requirement definition stage, you consider the direction of system construction and decide what kind of system to build. Since the outcome is not specifically envisioned at this point, Japan’s Ministry of Economy, Trade and Industry’s model contract stipulates this as a quasi-mandate type.

Preparation of External Design Documents

(Implementation of the External Design Document Preparation Task) Article ○ The second party shall, upon entering into the individual contract prescribed in Article ○, perform the external design document preparation task for the subject software based on the requirements specification determined according to the provisions of Article ○. 2. In implementing the external design document creation task, the second party may request the necessary cooperation from the first party, and the first party shall respond to such requests in a timely manner.

Preparing external design documents involves planning the usage of screens, forms, aninterfaces. The external design document must, in principle, contain all the information necessary for vendors to develop programs based on it. Though it includes detailed content following the prescribed format, the ability to change the specifications rests with the user side that determines the business content. However, if the previous phase’s outcome, the requirements specification, clearly defines the user’s needs and the work that the vendor needs to complete, it is possible to enter into a contract with the vendor taking the lead in creating the external design documents.

The first clause states that the vendor is the main body responsible for performing the work since this process is a contractual one. Nevertheless, even in a contractual arrangement, external design involves significant parts related to the user’s business content, and active user involvement is required. Therefore, the second clause makes it clear that the vendor can request the necessary cooperation from the user in discussing and deciding on system specifications, and the user must respond timely to this, clarifying that the examination of system specifications is a joint effort between the vendor and the user.

(Conclusion of Individual Contract Related to External Design Document Creation Task) Article ○ The first and second parties shall discuss and determine the trading conditions stipulated in Article ○, Paragraph ○, and conclude an individual contract related to the external design document creation task.

The scope of the external design document creation task is to be determined in an individual contract, following the previously established trading conditions.

(External Design Deliberation Meeting) Article ○ The second party shall hold an external design deliberation meeting (hereinafter referred to as the “external design deliberation meeting” in this section) at a frequency deemed necessary to clarify or confirm matters necessary for the creation of the external design document, and the first party shall participate in it. 2. The first party, too, when deemed necessary for the creation of external design documents, may hold an external design deliberation meeting, and the second party shall participate in it. 3. If, through the discussions in the external design deliberation meeting, the first party intends to change the contents of the requirements specification, and it becomes necessary to change the terms of the individual contract, such as the work period and commissioning fees, it shall be done according to the procedure of Article 33 (Modification of this Contract and Individual Contract Contents).

Determining the interfaces, such as screens and forms, in the creation of external design documents requires collaboration between the user and the vendor. Since this process is contractual, the first clause stipulates that the vendor will host the deliberation meeting, and the user will participate in it. Clarifications or confirmations of matters necessary for the creation of external design documents occur in the external design deliberation meeting, and both the vendor and the user are bound by the results of these discussions.

Clause 2 allows the user also to hold an external design deliberation meeting if necessary for the creation of external design documents.
Clause 3 addresses the possibility that the user might change the contents of the requirements specification, impacting specific contract-defined work periods, fees, etc., and must follow the procedure for modifying this contract and individual contract contents as set out in another clause.

(Delivery of External Design Documents) Article ○ The second party shall deliver the external design document and the external design document acceptance request form (also a delivery slip) to the first party by the date specified in the individual contract.

Since this process is contractual, the vendor must deliver the external design documents and related materials as the final product.

(Approval and Finalization of the External Design Document) Article XX Party A shall inspect the external design document within the period stipulated in the individual contract (hereinafter referred to as the “inspection period for the external design document”) to confirm whether it complies with the requirements definition document finalized by Article XX and the decisions made in the external design review meeting specified in Article XX, and whether there are any logical errors. Both Party A and Party B’s responsible persons shall sign and seal the external design document approval as proof of compliance and the absence of logical errors. However, if the inspection reveals that the external design document does not comply with the requirements definition document and the decisions made in the external design review meeting or there are logical errors, Party B shall create a revised version and present it to Party A within a mutually agreed deadline, and Party A shall conduct the aforementioned inspection and approval procedure again. 2. If Party A does not object in writing with specific reasons during the inspection period for the external design document, Party A shall be deemed to have approved the external design document upon the expiration of the inspection period. 3. The external design document shall be considered finalized upon Party A’s approval as per the preceding two paragraphs.

In the external design phase, requirements must be determined for the creation of subsequent internal design documents; if the determination of these requirements remains vague, problems may arise later in the development. This clause sets forth the procedure for inspecting the external design document that will be the basis for subsequent development work by the user, and for finalizing it with the user’s approval.

Paragraph 1 states that the user shall inspect for compliance with the requirements definition document and the results of the external design review meeting as well as for any logical errors in the external design document. There may be cases where revisions are deemed necessary during the inspection for approval of the external design document, and the proviso in the same paragraph defines the procedure for such cases.

Paragraph 2 is a provision that, even if the signature and seal of approval are not yet completed, if no objection is raised by the user within a certain period, it is considered approved by the user. The purpose of this paragraph is to prevent potential trouble later, as proceeding to the internal design with an ambiguous approval status from the user can cause problems.

And Paragraph 3 establishes that the external design document is finalized upon the user’s approval.

(Warranty Liability for Defects) Article XX After the finalization of the previous article, if any inconsistency with the requirements definition document and the decisions made in the external design review meeting specified in Article XX, or logical errors (hereinafter referred to as “defects” in this Article) are discovered in the external design document, Party A may request Party B to correct such defects, and Party B shall correct them. However, Party B shall bear the responsibility for such correction only if the request is made by Party A within XX months after the finalization of the previous article. 2. Notwithstanding the preceding paragraph, if the defect is minor and would require excessive costs for the correction of the external design document, Party B shall not bear the responsibility for the correction as specified in the preceding paragraph. 3. The provision of Paragraph 1 does not apply if the defect arose from materials or instructions provided by Party A. However, this does not apply if Party B did not inform Party A that such materials or instructions were inappropriate, even though they knew them to be so.

This article defines the warranty liability for defects concerning the external design document. The warranty period should be set to a reasonable period through consultation between the parties, considering factors such as the scale of the information system and the consideration.

Paragraph 1 describes inconsistencies between the external design document and the requirements definition document and decisions made in the external design review meeting or logical errors in the external design document as defects.

Paragraph 2 is intended to protect the vendor, following the model of Article 634(1) of Japan’s Civil Code, as it would be harsh to demand free correction from the vendor if the defect is minor but requires excessive costs for the correction.

Paragraph 3 is a provision that follows the model of Article 636 of Japan’s Civil Code, stating that the vendor cannot escape warranty liability if the defect is due to the user’s instruction or provided materials, although the vendor knew they were inappropriate and did not point it out.

Please note that the warranty liability for defects is an optional provision, and if it is not placed, it will be treated according to the general principles of Japan’s Civil Code. Since the warranty liability for defects has been significantly influenced by the amendment to Japan’s Civil Code enforced from April 2020, it will become an area where handling differs from the past after the enforcement of the amended Civil Code.

Software Development Services

In this section and those that follow, the clauses pertaining to software development conducted by a vendor on a contract basis are outlined in accordance with Japanese practices.

(Implementation of Software Development Services) Article X: Party B shall perform the software development services, from internal design to system testing, based on the system specifications defined in the individual contract stipulated in Article 25, as part of this project. 2. In implementing the software development services, Party B may request necessary cooperation from Party A, and Party A shall respond to such requests in a timely manner.

In this section and the ones that follow, regulations are provided for the clauses concerning software development that a vendor undertakes on a contractual basis. In the internal system design phase, it’s common to define the development target and specifications based on the work performed up to the previous stage, so this is stipulated as contract-based in the Japanese Ministry of Economy, Trade, and Industry’s model contract.

(Conclusion of an Individual Contract for Software Development Services) Article X: Party A and Party B shall discuss and agree upon the transaction terms specified in Article X, Section X, and conclude an individual contract regarding the software development services.

The scope of software development services is determined according to the transaction terms defined previously, and is to be agreed upon in an individual contract.

(Delivery of Deliverables) Article X: Party B shall deliver the deliverables specified in the individual contract, along with the acceptance request form (also known as the delivery note), by the agreed deadline. 2. Party A shall conduct an inspection based on the inspection specifications stipulated in the next article, following Article X (Acceptance of the Software in Question). 3. Party B may request necessary cooperation from Party A during the delivery of the deliverables, and Party A shall promptly comply with such requests. 4. The risk of loss or damage to the deliverables shall be borne by Party B before delivery and by Party A after delivery.

As this process is contract-based, the completed software is to be delivered for inspection as a finished product. The first clause stipulates the delivery of the deliverables along with an acceptance request form.

The second clause outlines the implementation of inspection by the user.
The third clause sets forth the user’s obligation to cooperate, as the delivery to the specified location in the individual contract may require the user’s assistance.
The fourth clause differentiates the timing of risk transfer in case of loss or damage to the deliverables based on physical possession.

(Acceptance of the Subject Software) Article X: Party A shall inspect the Subject Software, which is part of the delivered items, within the period specified in the individual contract (hereinafter referred to as the “Inspection Period”) according to the Inspection Specifications mentioned in the previous article, to confirm whether it aligns with the System Specifications. 2. If the Subject Software complies with the inspection stated in the previous clause, Party A shall sign and stamp the Inspection Certificate and promptly deliver it to Party B. Additionally, if the Subject Software fails to comply with the inspection, Party A shall promptly provide a written explanation detailing the specific reasons for the failure to Party B, requesting modifications or completions. When such failure reasons are accepted, Party B will make the necessary corrections free of charge within an agreed-upon deadline, and Party A will conduct the inspection outlined in the previous clause again. 3. Even if Party A does not issue an Inspection Certificate, the Subject Software will be considered as having passed the inspection defined in this article if Party A does not present any objections in writing, specifying concrete reasons, within the Inspection Period. 4. Completion of the inspection as outlined in this article shall be considered as final acceptance of the Subject Software.

Given that this project operates on a contract basis, this article outlines the procedures for acceptance testing of the delivered software.

The first clause stipulates that Party A must inspect the Subject Software within the Inspection Period, based on the Inspection Specifications, to check whether it aligns with the System Specifications.
The second clause obliges the vendor (Party B) to correct the software and deliver the revised version to the user (Party A) if it is found to be non-compliant with the System Specifications.
The third clause aims to prevent delays in the acceptance process due to the user’s circumstances by specifying conditions for deemed acceptance.
The fourth clause explicitly states that passing the inspection constitutes final acceptance of the Subject Software.

(Warranty for Defects) Article X: After the completion of the inspection in the previous article, if any defects (including bugs; hereinafter referred to as “defects” in this article) that cause discrepancies between the delivered items and the System Specifications are discovered, Party A may request Party B to correct such defects. However, Party B shall bear the responsibility for such corrections only when Party A requests it within ○ months after the completion of the inspection in the previous article. 2. Notwithstanding the previous clause, Party B is not obligated to make the specified corrections if the defect is minor and would require excessive cost to correct. 3. The rules of Clause 1 do not apply if the defect arises due to documents or directions provided by Party A. However, this exclusion doesn’t apply if Party B knows that the documents or directions are inappropriate and fails to notify Party A.

Given that this project operates on a contractual basis, this section outlines the warranty responsibilities for defects in the delivered goods. Distinguishing between liability for non-performance when work is incomplete and warranty liability for defects after work is complete can be practically challenging. A Tokyo District Court ruling from April 22, 2002 suggests that the criterion for considering a system development project complete should be whether it has finished all the stages initially outlined in the contract. In principle, warranty liability for defects applies if flaws are discovered after the software has been delivered and passed its final inspection.

The first clause defines a “mismatch with the system specifications” as a defect within the scope of software development services. For any shortcomings that occur during the external design phase, responsibility is determined not by this section but by other provisions specifically addressing warranty liability for that phase. Parties will agree on a reasonable warranty period for defects, considering factors such as the scale of the information system and the compensation involved.

The second clause introduces a provision in line with Article 634-1 of the Japanese Civil Code. It states that even if a defect is minor, demanding the vendor correct it for free is unreasonable if such correction would incur excessive costs.

The third clause aligns with Article 636 of the Japanese Civil Code. It states that the vendor won’t assume warranty liability if a defect arises from the user’s instructions or provided documents. However, if the vendor knows these instructions or documents are inappropriate and doesn’t point this out, then the vendor cannot escape warranty liability.

Software Operational Readiness & Transition Support

In the acceptance and implementation phase of a system, it’s generally the user who takes the lead. The Japan Ministry of Economy, Trade and Industry’s model contract stipulates this as a quasi-delegated format, where the user serves as the principal and the vendor provides support.

Determining the Nature of the Contract

To determine the nature of the contract, one must consider its overall purpose. You’ll need to examine whether the aim is to “deliver a finished product” or if it centers around the vendor “effectively executing the work.” A general guideline here is whether the content of the intended final product has been somewhat specifically identified and if the project has been progressing toward that end.