Ukeoi or jun-inin? Choosing the contract for agile development

For agile development, IPA's model contract uses jun-inin (準委任, a quasi-mandate, where you pay for professional work done with due care) instead of ukeoi (請負, a contract for work, where you pay for completing a specified deliverable). If you do use ukeoi, IPA's advice is to limit it to parts whose specification is already settled, and to sign small contracts again as each part becomes clear.

That answer comes from the agile edition of IPA's model contract, first published in March 2020 and still maintained. It was written by a working group of buyers, vendors, industry bodies and lawyers, so it does not lean toward either side.

The two contract types

Under ukeoi, the vendor promises to complete a defined deliverable, and the price is normally fixed in advance from an estimate. If the result does not match what was agreed, the vendor is responsible.

Under jun-inin, the vendor promises to carry out the work as a professional, with the care of a prudent manager (the Civil Code standard in Article 644, applied through Article 656). Payment is for the work itself, not for a finished object.

METI's 2018 DX Report noted that in Japan it is not unusual to sign ukeoi even for requirements definition, and called it buyers handing the whole job over to the vendor (the passage is quoted in a briefing on the agile model contract published by IPA). Paying for a result feels safer, and for a website with a fixed page list, ukeoi is often right. For an app that is expected to change once real users touch it, the model contract argues the opposite.

Why IPA chose jun-inin for agile

The commentary starts from how agile work behaves. Features get added, changed and reprioritized during development, some get dropped by the buyer, and improvement continues after the first release. A contract that obliges the vendor to complete a deliverable specified in advance fits that poorly.

It then names two risks of signing a single fixed price ukeoi for agile work. The first is a gap between price and effort: if the scope grows or rework follows a change, the vendor carries the cost of an estimate made when little was known. The second is a conflict of interest. With a fixed price, the vendor has a reason to resist changes, which is the opposite of what agile is for.

That second risk is the one buyers feel. It shows up as every new idea becoming a change request and a negotiation, and the project slowing to a pace set by the contract instead of by what users need.

Jun-inin still binds the vendor

A quasi-mandate is not a promise to try. The commentary is clear that the vendor must carry out its role in good faith within what the contract and its annexes define, and push the product forward. When changes affect price or schedule, the contract changes through a change management procedure that both sides agree to.

What changes is where the risk sits. Under jun-inin you are paying for a team's time and skill, so you carry more of the risk that the scope turns out larger than hoped. In exchange you get the freedom to change direction without a renegotiation each time.

What the buyer has to bring

Buyers tend to skip this part. The model contract has the buyer appoint the product owner, the person responsible for the direction and content of the product, who gives the team information and decisions on time and handles stakeholders. The vendor appoints the Scrum Master and gives advice on the backlog and on technical risk.

For many Japanese buyers the product owner is the hardest role to fill, for the same reason so few companies rate their DX talent as good enough.

IPA also publishes a pre-contract checklist for both sides to fill in. A few of its points are worth reading before any agile proposal:

• Is the purpose of the project, at least the near term goal, clear and shared with stakeholders?
• Is the product a size one team of up to about 10 people can keep developing?
• Can the buyer appoint a suitable product owner and delegate authority to them?
• Can the vendor appoint a Scrum Master with agile experience and keep the development team fixed?
• Do both sides understand that the contract is a quasi-mandate?

If the honest answer to the product owner question is no, the contract type is not your main problem. Agile without a decision maker on the buyer side tends to stall, which is close to why so many AI pilots never become products.

A note on disguised contracting

Agile teams talk to each other directly and often, and Japanese buyers sometimes worry that close collaboration with a vendor's engineers could be treated as disguised worker dispatch. IPA points to a Q&A from the Ministry of Health, Labour and Welfare, published on September 21, 2021, which addresses agile development under outsourcing contracts, and says following it should ease the concern. Read it with your legal team if this comes up.

When ukeoi is still the right call

Some work has a settled specification: a campaign site, a redesign with a fixed page list, a migration with a defined target. Ukeoi fits those well. For waterfall projects, IPA's model contract, second edition, published on December 22, 2020, is the reference. It splits a project into phases with an individual contract for each, so support for requirements definition is a quasi-mandate, external design can go either way, and the software build itself is ukeoi.

For agile work where you still want fixed prices, the commentary suggests the middle path: sign ukeoi only for portions whose specification is relatively clear and certain to be built, and repeat that contract as each portion firms up. That keeps a fixed price on the parts you can actually specify and leaves the rest under the quasi-mandate.