Japan’s haken rules cost us 6 weeks — the 7 steps I would follow next time

William

Engineering Operations Lead, Tokyo · August 18, 2026

We had used the words “dispatch”, “outsourcing” and “contractor” interchangeably for months. In Japan they describe different legal structures, and the difference is not academic: it determines who is allowed to tell an engineer what to do on Tuesday morning. We had the wrong contract for the way we were actually working, and unwinding it took six weeks.

Step 1 — Identify which structure you actually need

Start from how you intend to work, not from which vendor is easiest to sign. Three structures cover almost every engineering case in Japan, and choosing between them is a decision about control, not about cost.

Direct employment gives you full control and full obligation. Haken dispatch lets you direct daily work while the agency remains the employer — useful for capacity that fits into your existing team and process. Gyomu itaku outsourcing buys a defined outcome from a supplier who manages their own people.

The practical test: ask whether you intend to tell a specific person what to work on each day. If the answer is yes, you need direct employment or dispatch. If the answer is genuinely no — you are buying a delivered system and do not care how it gets built — outsourcing works. Answering “yes” while signing an outsourcing contract is the mistake that cost us the six weeks.

Step 2 — Be clear who the employer is

Under haken, the dispatch agency is the legal employer. It handles the employment contract, payroll, social insurance and statutory obligations. The engineer is the agency’s employee, placed with you.

But you are not merely a customer. As the client accepting a dispatched worker, you carry real co-employment responsibilities in the working environment: workplace safety, working hours as actually managed on your premises, and harassment prevention. The split is genuinely a split, and treating the agency as a vendor who owns every obligation is a misreading.

What this means in practice: designate a named person on your side responsible for the dispatch relationship — hours actually worked, working conditions, escalation. If nobody owns it, the obligations do not disappear; they simply go unmanaged.

Step 3 — Plan around the three-year placement limit

Dispatched workers generally may not remain at the same placement for more than three consecutive years. Where a company wishes to continue accepting dispatched workers at an organisational unit beyond three years, it must hear the opinion of the labour union or equivalent employee representatives.

For engineering teams this bites harder than it first appears, because dispatch is often used for precisely the work that outlasts three years: platform maintenance, a long-running integration, an internal tool with no natural end date. Teams reach year three, discover the limit, and improvise.

There are three honest responses, and all three are better than improvising. Convert to direct employment — frequently the right answer for someone who has become genuinely central. Plan the placement to end within the window, with knowledge transfer built into the schedule. Or restructure the work as a genuine outsourced deliverable, which means actually changing how instruction flows, not just re-papering the contract.

The practical action: record the placement start date and set a review at the two-year mark. Two years leaves room for a real decision; two years and ten months does not.

Step 4 — Respect the gyomu itaku boundary

Under gyomu itaku, the contractor controls how the work is delivered. You pay for a defined output or service, and no employment relationship exists between you and the individuals doing the work — provided the arrangement is genuine.

That last clause carries the weight. If you direct daily tasks, set working hours, supervise output or require attendance, the arrangement may be re-characterised as disguised dispatch or even direct employment, triggering obligations under both labour law and the Dispatching Act.

Engineering teams walk into this almost by default, because modern development practice is built from exactly those behaviours. Daily standups where a client manager assigns work. Tickets in your tracker assigned to named contractor engineers. Core-hours expectations. Performance conversations. None of it is done with any intent to mislead; all of it is evidence of the thing the contract says is not happening.

Step 5 — Design instruction flow to match the structure

If you have chosen outsourcing, redesign the working pattern rather than relabelling it.

Requirements and priorities go to the contractor’s own lead, who allocates work within their team. Your product owner discusses scope and acceptance criteria with that lead, not with individual engineers. Progress is reported against deliverables and milestones, not against individual assignments. Joint planning sessions are entirely fine; a client manager dragging tickets onto named contractor engineers is not.

Many teams find, when they run this exercise honestly, that their way of working genuinely requires direct daily instruction. That is a legitimate conclusion — and it means dispatch or direct employment is the honest structure. The failure mode is not choosing dispatch; it is choosing outsourcing on price and then behaving as though it were dispatch.

Step 6 — Handle intellectual property explicitly

Ownership of work product does not follow automatically from paying for the work, and the default position differs by structure.

Under dispatch, the engineer is the agency’s employee, so the chain from creator to agency to you needs to be complete in writing. Under outsourcing, ownership sits with the contractor unless the agreement assigns it. Neither default is what most clients assume.

Cover three things in the agreement: assignment of rights in work product created under the engagement, including moral-rights handling appropriate to Japanese law; treatment of pre-existing materials, which should be licensed rather than assigned; and open-source contributions, where the engineer may want to upstream a fix and everyone should know in advance whether that is permitted.

This is the clause teams most often discover is missing at the worst possible moment. Colleagues at HireDeveloper.ae report the identical pattern with UAE contractor agreements: ownership is assumed, never written, and the gap surfaces during due diligence.

Step 7 — Document the arrangement as it is actually run

The classification is determined by observable reality, so your documentation should describe reality rather than aspiration.

Keep four things per engagement. The signed agreement with the structure stated plainly. A one-page note of how instruction flows — who talks to whom about what — which is the single most useful document if anyone ever asks. For dispatch, a record of the placement start date and the three-year horizon. And for outsourcing, deliverable acceptance records showing you accepted outputs rather than supervised effort.

Then review it annually against what people actually do. Arrangements drift: a contractor who joined for one project is, two years later, in every standup and on the on-call rota. Nobody decided that. It accumulated. Catching drift early is far cheaper than unwinding it, as our colleagues at HireDeveloper.sg note about contractor classification in Singapore, where the analysis turns on the same question of control and integration.

The three mistakes that cost the most

Choosing the structure on price. Outsourcing often quotes lower than dispatch, so teams sign it and then work as though it were dispatch. This produces the worst of both: outsourcing economics with dispatch exposure and none of the protections.

Assuming the contract settles the classification. It does not. If the working pattern looks like dispatch, the paperwork will not save it. Design the pattern first, then paper it.

Discovering the three-year limit in year three. By then your options have collapsed to conversion at whatever price the moment dictates, or losing someone who holds irreplaceable context. Set the review at two years.

If you are weighing dispatch against building a permanent team, our guide to backend development services in Tokyo covers how teams at that stage are usually structured.

Frequently asked questions

What is the difference between haken and gyomu itaku in Japan?

Haken is worker dispatch under the Worker Dispatching Act. The dispatch agency is the legal employer, but the client company directs the worker’s day-to-day work, and the client carries co-employment obligations plus dispatch-period limits. Gyomu itaku is a services-outsourcing agreement: the contractor controls how the work is delivered, the client pays for a defined output or service, and no employment relationship exists provided the arrangement is genuine. The practical test is who gives instructions. Under haken, the client may direct daily tasks; under gyomu itaku, it may not.

How long can a dispatched engineer stay at the same company?

Dispatched workers generally may not remain at the same placement for more than three consecutive years. Where a company wishes to keep accepting dispatched workers at an organisational unit beyond three years, it must hear the opinion of the labour union or equivalent employee representatives. For engineering teams this matters more than it first appears, because dispatch is often used for exactly the kind of long-running platform or maintenance work that outlasts three years. Plan the exit or the conversion to direct employment from the start rather than discovering the limit in year three.

What is disguised dispatch and how do engineering teams fall into it?

Disguised dispatch (gizou ukeoi) is an arrangement papered as outsourcing but run as dispatch. It happens when a client signs a gyomu itaku contract and then directs the contractor’s staff directly — assigning daily tickets, setting working hours, supervising output, requiring attendance at standups. Engineering teams fall into it almost by default, because modern development practice is built on exactly those behaviours. The consequence is that the arrangement may be re-characterised, triggering obligations under both labour law and the Dispatching Act. The contract does not protect you; the observable working pattern determines the outcome.

Can we run agile ceremonies with an outsourced engineering team?

You can, but the instruction flow has to be redesigned rather than simply relabelled. Under a genuine outsourcing arrangement, requirements and priorities go to the contractor’s own lead, who then allocates work to their team. Your product owner discusses scope and acceptance with that lead, not with individual engineers. Joint planning sessions are fine; a client manager assigning tickets to named contractor engineers in your tracker is not. Many teams find that if agile ceremonies genuinely require direct daily instruction — which they often do — dispatch or direct employment is the honest structure to use.

In summary

Japan’s dispatch framework is not complicated once the organising question is clear: who is allowed to tell this engineer what to do today? Dispatch says you are. Outsourcing says you are not. Everything else — the three-year limit, the co-employment obligations, the disguised-dispatch risk — follows from that answer.

If you take only two steps from this list, take the first and the fifth. Deciding the structure from your intended working pattern prevents the mismatch entirely. And designing the instruction flow to match what you signed is what keeps the two aligned once real delivery pressure arrives — which is precisely when arrangements start to drift.