The Basics of System Development Contracts: Contract for Work vs. Quasi-Delegation

When you order system development, the contract will typically use one of two terms: "contract for work" (ukeoi) or "quasi-delegation" (jun-inin). Both are contract types recognized under Japanese civil law, and which one applies has a major effect on whether the developer is obligated to deliver a completed result, and on how compensation is structured. Signing a contract without understanding this distinction can lead to disputes over "the scope of responsibility being different from what we expected." For the bigger picture of ordering a system, see our guide to ordering system development; this article focuses on the contract type itself and summarizes, as general information, the points a business owner should know. Note that this article is intended as general information only — for the interpretation of specific contract terms or any legal judgment, we recommend consulting a lawyer or other qualified professional.

In system development, the detailed specification of the deliverable is often not fully fixed at the time the contract is signed — it's common for requirements to become concrete as the requirements-definition process proceeds. Because of this characteristic, the nature of the contract and the scope of each party's responsibility differ depending on whether the development company is promising to complete a finished deliverable, or promising to carry out a defined set of tasks. Understanding this distinction matters both for reading a contract correctly and for knowing what you can and can't claim if a dispute arises.

A contract for work is generally understood as a commitment to complete a defined piece of work, with compensation paid in exchange for delivery of the finished result. In principle, if the work is not completed, payment cannot be claimed, and if the finished deliverable doesn't conform to the contract, issues around correction or damages can come into play. A quasi-delegation contract, by contrast, is a commitment to carry out a defined scope of work — it does not guarantee the completion of any particular deliverable, but does require the party performing the work to exercise the standard of care expected of a professional in that field. Compensation is typically tied to the time or effort spent, rather than to the completion of a deliverable. Neither type is inherently better than the other; the more common way to think about it is which type suits a given phase of the development process.

In practice, it's common not to cover an entire project under a single contract type, but instead to split the contract by phase — an approach often called multi-stage contracting. For example, the requirements-definition phase, where the specification isn't yet fixed, might be handled as quasi-delegation, while the development phase, once requirements are clear, switches to a contract for work where completion responsibility can be clearly defined. This approach is generally seen as making it easier to combine flexible spec adjustment upstream with clear completion responsibility downstream. Because the cost breakdown in a quote often reflects this distinction in contract type, it's worth reading alongside our guide to reading a development quote to build a fuller understanding of what you're agreeing to.

- Ownership of copyright: Confirm whether copyright in the developed program and documentation belongs to the client, to the development company, or is partly retained by the developer
- Acceptance conditions: Confirm what constitutes completed acceptance and how long the acceptance period is
- Liability for non-conformity: Confirm under what conditions and for how long you can request corrections if defects are found after delivery
- Termination conditions: Confirm the process for terminating the project midway, and how existing deliverables and costs are handled in that case
- Subcontracting: Confirm whether the development company may subcontract part of the work to another firm, and under what conditions
- Confidentiality obligations: Confirm how your company's business information and customer data, shared during development, are required to be handled

A quasi-delegation contract tends to accommodate spec changes flexibly, but because cost accrues based on time and effort spent, the total can grow larger than expected if the work takes longer than planned. A contract for work is less likely to generate additional costs within the originally agreed scope, but changes beyond that scope typically require a separate quote as "additional work." Because the way costs tend to expand differs by contract type, it's worth understanding this alongside how to prevent additional-cost disputes to avoid a mismatch between your cost expectations and the contract you sign.

A contract for work and a quasi-delegation contract are not a matter of one being better than the other — they're different contract types with different answers to who is responsible for completion and how compensation is structured. Understanding the multi-stage approach — quasi-delegation for requirements definition, contract for work for development — along with contract items to check such as copyright ownership, acceptance conditions, liability for non-conformity, and termination conditions, makes it easier to understand what you're agreeing to and to head off misunderstandings before they happen. That said, how a given contract type is interpreted, and what specific clauses mean for your business, depends on the wording of the actual contract in front of you. Before signing, be sure to read the entire contract, and consult a lawyer or other qualified professional about anything that's unclear or that concerns you.