Dantotsu — Defect Analysis

A structured method for turning a single defect into a permanent quality improvement. Originated by Sadao Nomura, a former Toyota engineer, who used it to cut manufacturing defects by up to 98%. Adapted for software, where a small project run fully under this method reached ~0.3 defects per 1,000 lines of code — one to two orders of magnitude below the industry average — without the huge upfront-spec overhead of aerospace-grade processes.

Defect = any unexpected behavior for the user; the gap between the behavior that occurred and the behavior that was expected.

Two principles carry over directly from the manufacturing original and matter more than any specific template:

• Classify by where a defect escaped, not by severity. Severity triage optimizes for "what do we fix first"; stage classification optimizes for "what part of our process is leaking" — which is what actually drives systemic improvement.
• Analyze both occurrence and outflow. Why did the defect happen (prevention), and separately, why wasn't it caught sooner (detection). Conflating the two loses the detection-gap signal, which is usually a process/tooling fix rather than a code fix.
• Check hypotheses against facts, not against how plausible they feel. The main risk in a whys chain isn't lack of expertise — it's the feeling of having understood ("avoir compris") standing in for actually understanding ("comprendre"). Competence in the domain makes this worse, not better: an experienced reader accepts a plausible-sounding cause too quickly precisely because it fits prior experience. Each link in the chain should be checked against something verifiable (the diff, the logs, the ticket history) before moving to the next "why".

Detection stages

Ask the user which stage caught the defect if it isn't already clear — never guess.