Japan's SI Industry Structure: Why Multi-Tier Subcontracted SES and Man-Month Billing Are Inefficient

What "Structure" Means Here

Let's be clear about the framing up front. This article is not an accusation of misconduct or negligence against any company or individual. What it examines is structural inefficiency — the kind of problem where every participant behaves rationally given their own position, and the system as a whole nonetheless settles into an inefficient equilibrium. Most of the complaints you hear about Japan's systems integration (SI) industry trace back not to anyone's bad intentions, but to four layers that reinforce one another: contract types, billing units, procurement procedures, and industrial history. Which also means individual effort alone has a hard time moving any of it.

We'll go in this order: (1) the market structure of the vendors that run mission-critical systems, (2) the multi-tier subcontracting structure, (3) the man-month billing convention, (4) the legal framework of ukeoi (contract for work) versus jun-inin (quasi-mandate) contracts, and (5) the waterfall culture that set in during the 1980s. At the end, we'll look at how all five interlock.

The Oligopoly Behind Mission-Critical Systems, and How It Came About

Large-scale build contracts for mission-critical systems (kikan-kei — accounting, HR, production control, core banking, resident records: the systems whose failure stops the business itself) have historically gone, in Japan, primarily to a small group of large vendors: NTT Data, IBM Japan, NEC, Hitachi, and Fujitsu. This is an uncontroversial description of market structure, not a charge against anyone. Vendor revenue rankings for the domestic IT services market from IDC Japan and Gartner have had these firms at the top for years (IT Leaders' coverage of IDC's 2024 survey reports a domestic IT services market of ¥7.0205 trillion, with Fujitsu, Hitachi, NEC, NTT Data, and IBM Japan among the leaders).

Why did it turn out this way? There's a path dependency here. Through the 1960s and 70s, Japan's mainframe market was shaped by domestic manufacturers (Fujitsu, Hitachi, NEC, Toshiba, Mitsubishi Electric, Oki Electric) alongside IBM Japan, and a natural business shape emerged: the company that sold you the hardware also took care of the software running on it. Mainframes were expensive, the OS and middleware were vendor-specific, and business applications could realistically only be written by that vendor's engineers. Competition to sell hardware was, directly, competition to win systems-integration work.

From the 1980s onward, each manufacturer spun its swollen software divisions out into subsidiaries. These became what the industry calls maker-affiliated SIers. In parallel, user companies were spinning off their own internal IT departments into subsidiaries (user-affiliated SIers). The result was a keiretsu of partner companies beneath each major vendor — what the industry calls the "NEC group," the "Hitachi group," the "Fujitsu group," and so on. These groupings are not merely trading relationships. Each grew its own distinct set of business customs: development standards, document formats, unit-price tables for estimation, quality-control procedures, even engineer training curricula, all vendor-specific. An engineer with ten years inside one group cannot necessarily carry that skill set into another — and that lock-in reinforces the oligopoly from the labor-mobility side as well.

Multi-Tier Subcontracting: Prime, Secondary, Tertiary, and the Margin Staircase

The multi-tier subcontracting structure (tajū shitauke kōzō) is the implementation layer that sits on top of those groupings. A prime contractor (motouke) wins the job from the end client, then re-subcontracts all or part of the development to a first-tier subcontractor, which passes part of it to a second tier, which passes part to a third tier, and the chain extends downward. The comparison to multi-layered subcontracting in construction is often made, but there's a decisive difference: what each tier supplies is not materials or heavy equipment, it's engineer-hours themselves.

These chains often run deeper than people assume. The Japan Fair Trade Commission's survey report on subcontracting practices in the software industry, published in June 2022 and based on a questionnaire sent to roughly 21,000 software companies capitalized at ¥300 million or less plus interviews with industry participants, notes that repeated re-subcontracting multiplies and complicates the distribution chain, sometimes producing extremely long chains. Responses quoted in the report include accounts of participating "as a bottom-tier engineer at the sixth level of subcontracting" and of "experience on projects as deep as the fourth tier." The report also documents awareness among a substantial share of subcontractors of firms that insert themselves into the chain without performing substantive work and simply take a cut — the practice known as nakanuki. The JFTC frames this structure as fertile ground for problems under the Subcontract Act, such as forced price reductions and demands for unpaid work on specification changes.

With the shape of it established, here's why it sits badly with software development specifically.

• A margin is taken at every tier. A staircase forms between what the client pays and what reaches the engineer at the bottom. Where intermediate tiers genuinely add value — design, quality assurance, project management — that's fair compensation. Where a tier merely passes the work along, the spread is pure inefficiency.
• Information degrades like a game of telephone. The most valuable asset in software development is context: what the client actually wants. That never fits entirely into a specification document. Every tier down loses some of the unwritten assumptions, the rejected alternatives, the concerns deferred for later. It is not unusual for an engineer at the bottom not even to be told who the end user of their code is.
• Accountability diffuses. When a defect or a delay surfaces, isolating whether the cause lies in vague requirements, flawed design, or poor implementation — across contractual boundaries — is extremely difficult. The result is a state where nobody is responsible for the whole, yet everybody is partly responsible for a piece.
• Incentives point the wrong way. This is the most fundamental one. For a tier billing by engineer-hours (man-months), the economically rational behavior is not "finish quickly with fewer people," it's "keep as many engineers as defensibly possible staffed for as long as possible." If a strong engineer halves the effort through automation or refactoring, that act halves the invoice; it does not help that tier's revenue. In practice it is the professional ethics of individual engineers that push back against this — which is to say that the structure and the conscience of the people in it are pulling in opposite directions.
• Career paths get distorted. The further down you are, the further you sit from upstream work (requirements definition, architecture), and the more your accumulated experience consists of "writing exactly the spec you were handed." Opportunities to be trained in design judgment are structurally concentrated at the top.

Why Don't User Companies Build In-House?

The obvious question follows: if this is so inefficient, why don't the client companies just hire engineers and build in-house? That question is the other end of the structure.

In Japan, the large majority of IT engineers are employed by IT vendors rather than by user companies, a skew in workforce distribution that has been noted repeatedly for years. The Japan–US comparisons published by the IPA (Information-technology Promotion Agency) in its IT Human Resources White Paper and later DX White Paper consistently show the opposite distributions: most IT personnel in Japan sit on the vendor side, while in the US the majority sit on the user-company side. (Current figures are available through IPA's digital workforce survey.) The precise percentages shift with survey year and definitions, so what matters here is less the exact ratio than the fact that the direction is reversed between the two countries.

This skew is both cause and consequence of multi-tier subcontracting. The user company has no engineers, so it hands the whole thing to a vendor. Because it handed the whole thing over, no knowledge accumulates internally, so the next project must be handed over too. The vendor, for its part, needs a large engineering headcount, but project volume swings hard with the economy and the fiscal-year budget cycle — absorbing peak demand with permanent staff alone is risky. So the variable portion is pushed down to partner companies. In other words, multi-tier subcontracting also functions as a buffer against demand volatility. The legacy-system problem that METI flagged as the "2025 cliff" in its 2018 DX Report — aging mission-critical systems that never get modernized while the engineers who understand their internals retire — is continuous with this same picture of companies not understanding the insides of their own systems.

The Man-Month as the Unit That Governs Estimation and Budgeting

A man-month (ninigetsu) is one engineer working for one month. In Japanese SI projects, estimation, contracting, progress reporting, and invoicing are all typically built on this unit. "This project is 120 man-months," "the rate is X yen per man-month" — that vocabulary works essentially anywhere in the industry.

It's easy to see why it took hold. Software has no physical output. There is no equivalent of meters excavated or tons delivered — no externally visible, easily verifiable unit. Meanwhile, the people approving the budget — internal approval chains, municipal assemblies, government accounting offices — need a justification for the number that can be explained in advance. The man-month supplies exactly that, in the form of "how many people for how many months," verifiable by a non-engineer. It fits procurement procedure beautifully.

But a billing unit always creates incentives. As long as billing is by man-month, vendor revenue is proportional to headcount times duration, and not proportional to value delivered. Several consequences follow from that one plain fact.

• Productivity gains translate into revenue losses. Building the same functionality with ten people over six months or with three people over three months is worth the same to the client (arguably more in the latter case), but the vendor's revenue is about 6.7× higher in the former. There is no contractual channel through which efficiency gains return to the vendor.
• Estimation becomes sizing, not problem-solving. What should be estimated is "what will it cost to solve this problem." What actually gets estimated is "how many man-months to implement this specification." Whether the problem was framed correctly in the first place falls outside the scope of the estimate.
• Budgets get tied to fiscal years and headcount. Public procurement and large-company budgeting run on annual cycles. Man-month estimates drop neatly into an annual budget, but sit badly with iterative development, where "we built it, we learned something, we're changing direction" is normal. Re-planning becomes an accounting problem rather than a technical one.
• Unit-price tables flatten out exceptional engineers. Man-month rates are usually set by skill grade (SE, programmer, and so on). An engineer five times as productive as a peer cannot be priced five times higher if the rate table doesn't allow it.

The Contract Law: Ukeoi versus Jun-inin

This is the section where precision matters most. Japan's Civil Code provides two contract types commonly used in system development — ukeoi (請負, contract for work) and jun-inin (準委任, quasi-mandate) — and their liability structures differ fundamentally.

An ukeoi contract (Civil Code Art. 632) is a contract whose object is the completion of a work. The contractor is obligated to complete the agreed deliverable, and payment is in principle made against completion (Art. 633). If what is delivered does not conform to the contract, the contractor bears liability for non-conformity (keiyaku-futekigō sekinin), and the client may demand cure (repair), a reduction in payment, damages, or termination. (The Civil Code reform that took effect in April 2020 restructured what was previously called "defect warranty liability" into non-conformity liability, applying the sales provisions by reference.) In software terms, delivering something that works is itself the obligation.

A jun-inin contract (Civil Code Art. 656) is a contract entrusting the handling of non-legal affairs, to which the mandate provisions apply by reference. The contractor owes a duty of care of a good manager (zenkan chūi gimu, Art. 644) — the care ordinarily expected of a professional in handling the entrusted work — but owes no obligation to complete a deliverable. Payment is in principle proportional to the performance rendered (Art. 648(2), the so-called performance-ratio type), and the 2020 reform also codified a result-completion type (Art. 648-2), under which payment is tied to a result. Even under the result-completion type, though, there is still no obligation to complete — and that is the dividing line against ukeoi.

Here is how it plays out in practice. As recommended in the IPA's Model Contract for Information Systems, Second Edition, the standard approach for large developments is a multi-stage contract that splits the project by phase: jun-inin for the planning and requirements-definition phases, where requirements aren't yet fixed; ukeoi for internal design through implementation, once the specification is frozen; jun-inin again for operations and maintenance. But that describes the contract between the client and the prime. Below the prime — second tier, third tier, and the SES contracts that supply individual engineers — the overwhelming norm is jun-inin. An SES (systems engineering service) contract is a form of quasi-mandate: a transaction supplying engineers' working hours.

Why is jun-inin chosen? The reason is blunt: ukeoi loads the entire completion risk onto the vendor. Software development is structurally hard to estimate accurately before you start. Requirements move, assumptions break, and the true state of the existing system is unknowable until you dig into it. Take that work on an ukeoi basis anyway and any overrun beyond the estimate is the vendor's loss — plus liability for non-conformity if what ships doesn't match the contract. Passing that uncertainty all the way down the chain on ukeoi terms isn't realistic, so the lower tiers are structured as jun-inin, settling on effort supplied rather than results delivered — the natural choice. And once you settle on effort, the unit is the man-month. The causal chain closes here: the choice of contract type determines the billing unit, and the billing unit determines the incentives.

To avoid a misreading: none of this means a jun-inin vendor can be cavalier. Japanese case law on failed system-development projects has recognized both a vendor-side project management obligation (a good-faith duty to manage progress and risk as a professional and to explain problems to the client in a timely way) and a client-side duty to cooperate (to settle specifications promptly and provide necessary information and materials) as obligations grounded in the principle of good faith. Having no completion obligation is not the same as having no obligations. But note what kind of norm this is: it is evaluated after the fact, in court — not a mechanism that ties the vendor's compensation to outcomes at the time of contracting.

The 1980s "Software Factory" and the Entrenchment of Waterfall

The last piece is methodology. It's well known that Japan's SI industry standardized on waterfall development — requirements, basic design, detailed design, implementation, testing, migration, proceeding in order, each phase "frozen" at a review gate before being handed to the next. But this was never merely a technical choice; it is inseparable from the contract structure described above.

The historical reference most often cited here is MIT's Michael A. Cusumano and his 1991 book Japan's Software Factories. It documents in detail how major Japanese manufacturers — Hitachi, Toshiba, NEC, Fujitsu — brought manufacturing's process and quality control methods into software development from the late 1960s through the 1980s, building "software factories" with standardized development processes, systematic reuse, and phase-based division of labor. In the context of the time, this was advanced practice. It suppressed variance in quality, made large-scale development predictable, and reduced dependence on individual heroics — applying a philosophy that had worked in manufacturing to the mainframe-based mission-critical development that was then the main arena.

Standardization of terminology and phases progressed domestically too. Built on ISO/IEC 12207, the Common Frame (SLCP-JCF) was developed from 1994 onward to give client and vendor a shared yardstick for discussing projects, and was revised through editions including the 1998 and 2007 versions (the lineage is summarized on IPA's SLCP overview page). With phase names and deliverable definitions shared industry-wide, estimates became comparable across vendors, and outsourcing by individual phase became easy.

And that is the crucial point. Waterfall was the precondition that made multi-tier subcontracting and man-month billing possible in the first place. Consider: you cannot carve out a phase whose specification is not frozen and hand it to an outside party under contract. "Send detailed design and coding to the third tier" works only because basic design has finished, the specification is fixed, and that phase's inputs (design documents) and outputs (modules) are defined on paper. Likewise, "how many man-months will this take" is answerable in advance only on the premise that scope is frozen. Agile approaches that revisit requirements iteratively — quite apart from whether they are technically superior — simply do not fit, as-is, into a framework of tiered outsourcing and man-month estimation premised on frozen scope.

Which is why the methodology persisted in Japan's SI industry long after iterative approaches became mainstream elsewhere. The reason it persisted is not that Japanese engineers are unaware of newer methodologies — as knowledge, they are thoroughly diffused. It's that the surrounding institutions — procurement procedure, contract types, the subcontracting chain, the budget system — are all optimized around waterfall. Swap out the methodology alone, and if the way budget is secured and work is carved into contracts doesn't change, you tend to land on "waterfall phases renamed as sprints."

How the Layers Interlock

In summary, the causation runs roughly in a loop:

• Market structure: a small group of large vendors, originating in the hardware business, came to hold mission-critical systems, each forming a keiretsu of partner companies with its own business customs.
• Workforce distribution: with few engineers on the user-company side, everything from requirements to operations became externally dependent, and vendors in turn needed to push demand volatility down into their partner networks.
• Contract type: because software is hard to estimate, completion-obligation ukeoi contracts could not be passed down the chain, so the lower tiers became jun-inin (SES).
• Billing unit: settling under jun-inin means settling on effort rather than results, so the unit became the man-month, and vendor revenue became proportional to headcount times duration.
• Development methodology: man-month estimation and phase-based outsourcing require scope to be frozen in advance, and waterfall supplied exactly that precondition.
• And it loops: waterfall makes phases easy to outsource, easy outsourcing means in-house capability never develops, and no in-house capability means external dependence continues.

The nastiest property of this structure is that reforming any single point in the loop has limited effect. Adopt agile, and if the contract is still jun-inin billed by effort, the incentives are unchanged. Design an outcome-linked contract, and if the client has no engineers able to define the outcome, it can't be operated. Declare a shift to in-house development, and as long as the industry's engineers are concentrated on the vendor side, it becomes a recruiting contest. If the structure does move, our reading is that it will be in cases where restored client-side technical capability, contract design, and a rethink of the billing unit advance at the same time.

Summary

• Construction of Japan's mission-critical systems has historically been carried out primarily by a small group of large vendors — NTT Data, IBM Japan, NEC, Hitachi, and Fujitsu — each of which formed a keiretsu of partner companies with its own business customs
• In the multi-tier structure of prime → first tier → second tier → third tier, a margin is taken at each level, information degrades, and accountability diffuses
• The Japan Fair Trade Commission's 2022 survey report documents the formation of extremely long distribution chains and the presence of firms that take a cut without performing substantive work
• In Japan, IT engineers are skewed toward vendors rather than user companies, which is both a cause and a consequence of external dependence
• Man-month billing makes vendor revenue proportional to headcount times duration, creating a reversed incentive in which productivity gains reduce revenue
• An ukeoi contract (Art. 632) has completion of the work as its object and carries liability for non-conformity; a jun-inin contract (Art. 656) carries only a duty of care, with no completion obligation. SES contracts are a form of quasi-mandate
• Because estimation is hard, lower-tier contracts gravitate to jun-inin; because they are jun-inin, the billing unit becomes the man-month; and because man-month estimation must work, frozen-scope waterfall is required — each reinforcing the others
• That said, the structure has also served to absorb demand volatility and guarantee a floor on quality, and the major vendors are investing in in-house-development enablement and agile organizations. The problem lies in how institutions interlock, not in anyone's bad intentions