5 Whys Example: Why-Why Analysis Japanese Customers Accept
You ship a batch of assemblies to a Japanese customer. One unit arrives with a cover screw missing, and the customer's quality team asks for a corrective action report with a why-why analysis attached. You fill in five rows: the operator forgot the screw, was not careful enough, had low quality awareness, needed more training. The fix is retraining and a double check. A week later the sheet comes back with questions on every line.
Why-why analysis, called naze-naze bunseki (なぜなぜ分析) in Japan and better known in English as the 5 Whys, asks "why" again and again until it reaches a cause that, once fixed, stops the problem from coming back. It works only when each step rests on facts you have checked. When the goal becomes filling in the boxes, the chain tends to end at "operator carelessness" and "retraining," and that is the version that gets sent back.
This guide covers what the method is and where it came from, a 7-step way to run it, a fictional 5 Whys example showing a rejected sheet next to a rewritten one, six common mistakes, and when to use a different tool. It ends with a checklist and a sheet layout you can reuse.
Contents
- What Is Why-Why Analysis (5 Whys)?
- How to Do a Why-Why Analysis in 7 Steps
- 5 Whys Example: A Rejected Sheet vs. a Rewritten One
- Six Mistakes That Get Why-Why Analyses Rejected
- Limits of 5 Whys and When to Use Other Tools
- Checklist: Before You Submit a Why-Why Sheet
- Where This Guide Does Not Apply
- FAQ
- Sources
What Is Why-Why Analysis (5 Whys)?
Why-why analysis starts from a problem that has occurred and asks "why" step by step until it reaches a cause that, once addressed, keeps the problem from recurring. The Information-technology Promotion Agency, Japan (IPA) uses that same idea in its guide to failure analysis methods: it defines the root cause as the cause that, once you fix it, stops the problem from happening again.
The Union of Japanese Scientists and Engineers (JUSE), in a seminar description, presents it as a method of repeatedly asking why the event behind a problem occurred, listing the factors logically and without gaps, and arriving at actions that prevent recurrence.
Both descriptions share one point: you do not list whatever causes come to mind. You build a logical chain that leads all the way to an action.
Origin: Taiichi Ohno's "Five Whys" Example
The phrase "ask why five times" is widely traced to Taiichi Ohno's book Toyota Production System (Diamond, 1978; published in English in 1988 as Toyota Production System: Beyond Large-Scale Production). The book describes a machine that stopped running.
We have not checked the original text ourselves. The summary below is based on articles that quote the book (see Sources), and the wording varies slightly between them.
Starting from a stopped machine, repeated questions lead to a cause in the system itself.
Summary based on articles that quote Taiichi Ohno, Toyota Production System (Diamond, 1978). Wording may differ from the original.
The point of the example is what happens if you stop partway. If you only replace the fuse or the pump shaft, the same failure comes back before long. Only when you reach the missing strainer and install one does the failure stop recurring.
As of October 2026, Toyota's Japanese-language page on the Toyota Production System centers on its two pillars, jidoka and just-in-time, and we did not find the phrase "five whys" there. Toyota Motor Europe's site, however, says Toyota uses the "ask why five times" technique to get to the root cause of every problem.
Toyota's own media site, Toyota Times, has also run an article in which an employee describes asking "why" five times to work out a method as typical of Toyota. Toyota's official 75-year history, in its section on quality, describes how the company handled breakdowns in its early years by going to the actual site and the actual parts to prevent recurrence. It helps to see why-why analysis as one of the problem-solving habits that grew up inside the Toyota Production System and kaizen.
"Five" Is a Guide, Not a Rule
"Five" is not a required count. IPA's guide also describes the method in terms of where you end up, not how many times you ask: you keep asking until you reach a cause that, once addressed, stops recurrence.
Hitoshi Ogura, author of Naze-Naze Bunseki 10-soku ("Ten Rules of Why-Why Analysis," JUSE Press, 2009), takes the same view. One of his ten rules is to keep asking "why" until you find a way to prevent recurrence. Sometimes you reach an actionable cause in three steps; sometimes it takes six or seven.
When filling five boxes becomes the goal, people pad the rows by restating the same thing or fill them with guesses they never checked. Judge the analysis by how far it got, not by how many rows it has.
How to Do a Why-Why Analysis in 7 Steps
The seven steps below are not an official procedure from any one organization. We put them in a practical order based on material from Japanese public agencies and industry bodies and on the rules Ogura sets out in his books and articles. Forms and labels differ from company to company, but the points to cover are the same.
Three phases: gather the facts, dig down, then verify and act.
Steps 3–5 usually go back and forth. Depending on what you find, return to an earlier step and rewrite.
Before You Start: The Team and the Ground Rules
An analysis written by one person at a desk is less reliable than one built with the people who know the facts. IPA's guide says the analysis rests on facts, so the people directly involved should take part wherever possible.
Agree on the purpose first. The same guide asks that everyone understand that the goal is not to blame individuals but to find the cause and decide on organization-wide measures to prevent recurrence. If that understanding breaks down, the people involved stop speaking openly, and the facts never come out.
This works the same way as near-miss (hiyari hatto) reporting: when reporting does not hurt the person who reports, you get more and better information. A facilitator from quality assurance or another department, rather than the operators' own supervisor, often makes it easier for people to talk.
Step 1: Define the Event and Confirm the Facts
The first job is not asking "why." It is establishing what happened. A column by JMA Consultants (JMAC) puts it as doing the "what-what" before the "why-why." It recommends the sangen shugi (三現主義, "three actuals") approach: go to the actual place, look at the actual parts, and check the actual facts to establish when, where, what, and how it happened.
Keep what you observed separate from how you interpret it. "One screw is missing" is an observation. "The operator forgot to tighten it" is an interpretation: the screw may have loosened and fallen out, or it may never have been installed.
Check which it is by looking at the screw hole and seating surface on the actual part, the production records, and the inspection records. If you get the starting point wrong, every "why" after it chases a different problem.
Step 2: Split the Problem and Write It in One Sentence
Once the facts are clear, write the starting event as a sentence. The first of Ogura's ten rules is to write each event and each "why" as a "one-cut" statement. In a series for Nikkei xTECH, he explains it as one box, one item.
"A screw was left untightened and also slipped past inspection" contains two different events. Ask "why" against that sentence and the answers drift between the assembly work and the inspection, and the chains get tangled.
Write them separately: "The product went to the next process with a screw left untightened" and "A product with a missing screw passed final inspection." The same ten rules also say to word each statement so that anyone reading it pictures the same scene, and to state what you are comparing against whenever you use an adjective.
Avoid phrases such as "checking was lax" or "control was insufficient." Different readers will take them in different ways.
Step 3: Ask "Why" One Level at a Time
Starting from the event, name its direct cause, then the cause of that cause, and repeat. Go one level at a time and skip nothing. If "forgot to tighten" is followed directly by "lack of training," everything in between, such as the work situation and the equipment conditions, drops out.
There may also be more than one cause. Ogura's rules say to check, for parallel "whys," whether the event above would still have happened if none of them had occurred. If one "why" has several answers, branch the chain and write them side by side.
Just as important, mark whether each "why" is a confirmed fact or still a hypothesis. If you cannot confirm it on the spot, do not fill the box with a guess. Label it "hypothesis" and note next to it who will check it and what they will look at.
The JMAC column makes the same point: the purpose of investigation is to test hypotheses, ruling out factors that do not fit the facts and test results.
Step 4: Separate the Occurrence Cause from the Escape Cause
For a quality defect, "why was the defect made?" and "why did it get out without being detected?" are different problems. Japanese quality teams call the first the occurrence cause (hassei gen'in, 発生原因) and the second the escape cause (ryushutsu gen'in, 流出原因), and they run a separate chain of whys for each.
A Japanese Standards Association (JSA) seminar on inspection also lists these as separate tasks: find the occurrence cause and feed it back to the process, and find the escape cause and use it to prevent recurrence. Dig only into occurrence and the hole in inspection stays open; dig only into escape and the defects keep being made.
The two chains start from different questions, so write them as two chains instead of one.
Look at: work method, equipment, materials, work instructions, process design
Action aims to: keep the defect from being made, or make it harder to make
Look at: inspection items, inspection methods, acceptance criteria, inspection design
Action aims to: reliably stop the defect even when it is made
Customers often ask that corrective action reports keep these two chains separate. For how the full report fits together, including containment and the system-level cause, see our guide to writing an 8D report.
Step 5: Dig Until You Reach a Cause You Can Act On
Where to stop digging is where many people get stuck. There are two tests. First, the cause is backed by facts. Second, you can explain why fixing that cause will keep the same problem from happening again.
IPA's guide says that if you cannot find a reasonable recurrence-prevention measure that removes the root cause, you redo the analysis. If the only actions you can come up with are not feasible because of cost or staffing, you may not have dug far enough, or you may be digging in the wrong direction.
That is not the same as writing causes so they lead to the fix you already want. If you decide the fix first and work backward to the causes, you get a story with no evidence behind it. Confirm the causes with facts, and let the fix follow from them.
You can also dig too far. Ogura's rules say not to ask "why" about personal matters (a person's state of mind) and to stop before subjective judgment comes in. Once you ask "Why was the operator in a hurry?" or "Why did they lose focus?", you are in territory you cannot verify, and there is no action you can take.
Step 6: Read the Chain Backward to Check the Logic
Once the chain is complete, read it in reverse, from the last cause back to the event. This is another of Ogura's rules: build the chain so that it still connects logically when you read it backward.
The method is simple. Read it aloud, joining the steps with "therefore": "A happened, therefore B happened. B happened, therefore C happened." Where the link sounds forced, either a "why" is missing in between or another factor has crept in.
This reverse reading also catches the failure pattern the JMAC column calls a cause-and-effect mismatch, where the stated cause does not actually explain the effect.
Reading backward only tells you whether the chain makes sense as a chain of reasoning. A chain can be logical and still be wrong about the facts. Check separately that each "why" is backed by the actual parts or by records.
Step 7: Decide on Actions and Check That They Work
Split the actions into two kinds: an immediate fix for the direct cause, and recurrence prevention for the deeper cause you dug down to. In Ohno's example, replacing the fuse or the pump shaft is the immediate fix, and installing a strainer is the recurrence prevention. You need both, but they do different jobs.
Along with an owner and a deadline, decide in advance what you will measure, over what scope, and for how long to judge whether the action worked. For example: will you count repeat defects, or in-process detections? Does the check cover only the affected line, or similar processes too?
If the same problem recurs during that period, check whether the action was actually carried out and whether your reading of the cause was right, then go back to the analysis. Also check whether other products or processes share the same cause.
JSA's advanced why-why analysis course includes exercises on extending a fix for one case to similar products and processes. Japanese plants often call this yokoten (横展開, horizontal roll-out).
5 Whys Example: A Rejected Sheet vs. a Rewritten One
The example below is fictional, made up for this guide. It does not describe any real company or product.
On an assembly line for a control unit, a cover is fixed with four screws. After shipment, the customer's receiving inspection finds one unit with one cover screw missing.
The Version That Gets Sent Back
Here is a pattern you see often.
All five levels are filled in, but almost nothing in it can be checked against facts.
Fictional example created for illustration.
The weakness is that none of these whys can be checked on the shop floor or in the records. Read backward, it seems to connect: "guidance was lacking, therefore training was insufficient, therefore awareness was low." But no level has evidence behind it.
The actions depend on the operator being more careful. If someone else works under the same conditions, the same thing can still happen.
Rewriting It with Verified Facts
Now redo the same event step by step, starting with the actual part. In this example, the returned unit's screw hole and seating surface show no tightening marks, and no loose screw is found inside the unit or in the packaging. From this, the team concludes that the screw was never tightened, not that it loosened and fell out.
Next, split the event in two. On the occurrence side: "The product went to the next process with one cover screw left untightened." On the escape side: "A product with one screw missing passed final inspection."
For the first occurrence "why," a team member suggests the work may have been interrupted. At this point it is only a hypothesis, so the team writes "Hypothesis. To be checked against production records and an interview with the operator" and stops there for now.
The check shows a record of the operator leaving the station to restock parts at that time, and the operator says they left right after tightening the third screw. The hypothesis is now a fact. Working down one confirmed level at a time in the same way produces the analysis sheet below.
Occurrence and escape are split, and each "why" comes with its evidence.
Fictional example created for illustration. Real causes and actions depend on the process and product.
Read the occurrence chain backward: "The work instructions gave no order or restart method, and nothing counted the screws. Therefore, on returning, the operator had no way to confirm how many were tightened. Therefore, the operator moved to the next unit with three screws in. Therefore, the product went to the next process with one screw left untightened."
There are no gaps, and every level can be checked against records or the part itself. The difference between the two analyses is not writing skill. It is that the evidence is visible, and the action builds a check into the process instead of relying on people to be careful.
Interruptions can still happen. Recurrence prevention means setting things up so that an interruption no longer leads to a missed screw.
If the cause turns out to be in how the work instructions are written, rewriting them is not enough. Also check that they are in a form the shop floor will actually use.
Related: Standardized Work Instructions: Sagyo Hyojunsho Template
Six Mistakes That Get Why-Why Analyses Rejected
Before you submit an analysis, check it against these six. Each one can look tidy on paper and still fail to prevent recurrence.
Use these as checks before you submit.
Don't Stop at Carelessness or Attitude
The most common pattern stops at "carelessness," "insufficient checking," or "low awareness." None of these can be verified, and they leave you with nothing but reminders as an action. Start from the fact that people make mistakes at some rate, and make the situation and conditions at the moment of the mistake the subject of your next "why".
This is also why Ogura says not to ask "why" about a person's inner state. Move the question from what was in the person's head to the work conditions, the equipment, the standards, and how information was passed along, and the whys become ones you can check.
Don't Guess, Mix Factors, or Work Backward
Mistakes 2 to 4 are about how the analysis is written. A "why" filled in by guesswork may sound plausible and still not be the real cause. Label a hypothesis as a hypothesis, and move on only after you have checked it.
When several factors share one sentence, nobody can tell which one the next "why" answers. Working backward from the fix, as noted in Step 5, puts things in the wrong order. If the conclusion comes first ("we want this equipment," "we want more checks"), you stop seeing any other cause.
Don't Assign Blame; Check the System Behind the Work
Mistake 5, blame, lowers the quality of the whole analysis. Where people expect to be blamed, the facts closest to the cause, such as having been interrupted or having changed the procedure, are the first to disappear. That is why IPA's guide asks that participants be told clearly that the analysis is not for blaming individuals.
Mistake 6 stops at the operator and never looks at the system that the operator's work depends on. When you look at what the work instructions say, the condition of equipment and fixtures, how inspection items were chosen, and whether anything changed recently, you often find a cause you can act on.
That does not mean every analysis should end at "poor management." If every chain ends with "insufficient supervision" or "rules not enforced," that is just the "stop at the individual" pattern turned around.
Training works the same way. If you confirm that something was genuinely missing from what people were taught, training is a valid action. Judge it by whether it matches a confirmed cause.
Don't just reword it. Ask another question, check the facts, then rewrite.
The right-hand column follows this guide's fictional example.
Limits of 5 Whys and When to Use Other Tools
Why-why analysis needs no special tools and you can start right away, but it is not the right fit for every problem.
It Tends to Follow a Single Line of Causes
The method's biggest weakness is that it tends to follow one line of causes. The JMAC column calls the approach of committing to a single factor and building out from it a "single-breakthrough" pattern and lists it as a way analyses go wrong. If the first "why" you pick is wrong, no amount of digging below it will reach the real cause.
The same criticism appears outside Japan. A 2017 commentary by Alan J. Card, "The problem with '5 whys'," appeared in BMJ Quality & Safety, a journal on healthcare quality and safety.
According to a summary by the US Agency for Healthcare Research and Quality (AHRQ), the commentary accepts that the 5 Whys is useful as a teaching tool. But it argues that using it for root cause analysis in healthcare tends to oversimplify complex problems and can limit understanding of how processes fail.
When several factors combine to cause an event, or factors affect each other, branch the chain deliberately or combine the method with another tool.
Choosing the Right Tool
The Japan Institute of Plant Maintenance (JIPM) offers an on-demand seminar on choosing among FMEA, FTA, PM analysis, why-why analysis, and other methods to suit the problem. It starts from the idea that each method has situations where it works best.
Some tools dig down, some broaden and organize, and some prepare in advance.
These methods are not mutually exclusive. A common pattern is to widen the candidate list with a fishbone or relations diagram, then dig into the narrowed-down factors with why-why analysis.
When you have no idea yet what the cause is, widen the list of candidates first. A fishbone (Ishikawa) diagram, called tokusei yoin zu (特性要因図) in Japan, sorts factors into major branches and smaller sub-branches.
Related: 7 QC Tools in Japanese Quality Reports: How to Read Them
According to JUSE, the relations diagram method links factors that have a cause-and-effect relationship with arrows when causes and effects are tangled, to find a way into the problem. It can show relationships between factors that a fishbone diagram has trouble showing.
The same JUSE material suggests running a "why-why" question-and-answer when you get stuck building a relations diagram. Broadening tools and digging tools are not an either-or choice; you move back and forth between them.
Fault tree analysis (FTA) puts an undesired event at the top and breaks its causes down top-down into a tree. IPA's guide describes it as a method that uses a tree to analyze failure paths, causes, and probabilities. It suits serious accidents and failures caused by combinations of factors.
Don't let a cause found by why-why analysis end with that one case. Add it to the FMEA as a defect the process could produce, and it helps prevent the same defect in similar processes and the next product. For how Japanese teams use FMEA alongside design reviews, see DRBFM vs. FMEA.
The method is used for workplace accidents too. A seminar listed by the Kanto center of the Japan Industrial Safety and Health Association (JISHA) includes an exercise that combines why-why analysis with a 4M factor classification table (man, machine, media such as work methods and environment, and management).
Checklist: Before You Submit a Why-Why Sheet
This list pulls the points above into one place. Go through it before the sheet leaves your plant.
- The starting event is based on what you saw on the actual part and in the records, not on an interpretation ("missing screw," not "forgot the screw").
- Each sentence describes one event. Occurrence and escape are written as two separate chains.
- Every "why" is marked as confirmed fact or hypothesis. Each hypothesis says who will check it, and how.
- No level is skipped: no jump from "forgot" straight to "lack of training."
- No "why" is about a person's state of mind (rushed, careless, low awareness).
- The chain reads correctly backward with "therefore" at every link.
- The last cause is something you can act on, and you can explain why fixing it prevents recurrence.
- Actions are split into an immediate fix and recurrence prevention, and each one traces back to a cause.
- Recurrence prevention changes the process, equipment, standards, or inspection, not just reminders. Training appears only where a real gap in what people were taught was confirmed.
- You have defined what you will measure, over what scope, and for how long to judge effectiveness.
- You have checked whether similar products and processes share the same cause (yokoten).
Sheet Layout You Can Reuse
If your customer has not prescribed a form, a layout like this keeps the two chains and the evidence visible. If the customer has its own form, use theirs.
| Occurrence chain | Escape chain | |
|---|---|---|
| Starting event (one sentence, observed fact) | ||
| Why 1 (fact / hypothesis) | ||
| Why 2 (fact / hypothesis) | ||
| Why 3… (add rows as needed) | ||
| Evidence for each why (records, parts, interviews) | ||
| Hypotheses still open (owner / check method / date) | ||
| Immediate fix | ||
| Recurrence prevention | ||
| Effectiveness check (what / scope / period) | ||
| Similar products or processes checked |
Questions to Ask Your Customer First
- Do you have a prescribed why-why analysis form, or should we attach it to an 8D or your own corrective action form?
- Do you want the occurrence and escape causes as separate chains?
- For causes we have not yet confirmed, can we submit them marked "hypothesis, under investigation" with a target date?
- What evidence should we attach (records, photos, measurement data)?
- How will you judge effectiveness, and over what period?
Where This Guide Does Not Apply
- The 7 steps are our own arrangement, based on the Japanese sources listed below. They are not an official standard, and forms, labels, and rules vary by company and customer. The customer's own requirements always come first.
- The screw example in Figures 4, 5, and 7 is fictional. Real causes and actions depend on the process and the product.
- Ohno's example is summarized from secondary sources that quote the book; the original wording may differ.
- For complex events with many interacting factors, why-why analysis alone may not be enough. Combine it with a fishbone diagram, relations diagram, or FTA.
FAQ
Is Why-Why Analysis the Same as the 5 Whys?
Yes. Naze-naze bunseki (why-why analysis) is the Japanese name for the same method of asking "why" repeatedly to reach a root cause. The phrase "ask why five times" is widely traced to Taiichi Ohno of Toyota.
Do You Have to Ask "Why" Exactly Five Times?
No. Five is a rough guide. You keep going until you reach a cause that is backed by facts and that, once fixed, stops the problem from recurring. That may take three steps or seven.
Why Shouldn't a 5 Whys Stop at "Carelessness"?
Labels such as "carelessness," "insufficient checking," or "low awareness" cannot be verified, and they lead only to reminders or retraining, which leave the conditions unchanged. Ask what situation the operator was in and what in the process allowed the mistake, then fix that.
What Is the Difference Between 5 Whys and a Fishbone Diagram?
A fishbone diagram broadens: it lists many candidate causes when you do not yet know where to look. The 5 Whys digs down into one cause at a time. Teams often use the fishbone first, then run 5 Whys on the most likely candidates.
Sources
- Bibliographic data: Diamond, Toyota Seisan Hoshiki (Toyota Production System), Taiichi Ohno, May 1978 (Japanese)
- Ohno's "five whys" example (quoted sources): Monodukuri.com, on the intent of Taiichi Ohno's "five whys" (Hamada) (Japanese); ITmedia Alternative Blog, on Ohno's Toyota Production System (Nagai) (Japanese); Lean Blog, "Even Ohno's Classic '5 Whys' Example Deserves Another Why"
- Toyota: "Toyota Production System" (Japanese); "75 Years of Toyota: Quality" (Japanese); Toyota Motor Europe, "Quality everywhere, in everything"; Toyota Times, January 2022 (Japanese)
- Definition, analysis points, FTA: Information-technology Promotion Agency, Japan (IPA), lessons for highly reliable IT systems, supplement II: failure analysis methods (revised March 2020) (Japanese, PDF)
- Description of why-why analysis: Union of Japanese Scientists and Engineers (JUSE), two-day why-why analysis seminar (Japanese)
- Hitoshi Ogura's ten rules: JUSE Press, Naze-Naze Bunseki 10-soku (Japanese); National Diet Library Search (bibliographic record, March 2009) (Japanese); Management Dynamics, "Why-why analysis" (Japanese); Nikkei xTECH, one item per box: "one-cut" statements (Hitoshi Ogura, May 2018) (Japanese)
- Establishing facts and narrowing down factors: JMA Consultants (JMAC), column on finding the true cause of defects (Tsujimoto, August 2018) (Japanese)
- Occurrence and escape causes, roll-out to similar cases: Japanese Standards Association (JSA), inspection system course (Japanese); JSA, advanced course on why-why analysis for preventing recurrence of defects (Japanese)
- Limits of the 5 Whys: AHRQ PSNet, "The problem with '5 whys'" (summary of Card AJ, BMJ Quality & Safety 2017;26(8):671-677)
- Relations diagram method: JUSE, new QC seven tools series, part 3: relations diagrams (Ebata) (Japanese, PDF)
- Choosing failure analysis methods: Japan Institute of Plant Maintenance (JIPM), failure analysis methods by issue (Japanese, PDF)
- Root cause analysis for workplace accidents: Japan Industrial Safety and Health Association (JISHA), Kanto center, seminar on cause analysis from accident cases (Japanese)
Original article in JapaneseThis guide is adapted from a MONOSCOPE article written for readers in Japan: なぜなぜ分析のやり方｜再発防止につながる問いの立て方とNG例
About the editor
MONOSCOPE EditorFOUNDER & EDITORSpent about ten years at a plant equipment maker and a plant engineering company, proposing, designing, and commissioning equipment, then moved into web marketing. Now a web consultant for B2B manufacturers, helping them explain their products and technology. Licensed in Japan as an Energy Manager and a Third-Class Chief Electrical Engineer.
Has run an engineering blog since 2017 (500+ articles) and a Japanese YouTube channel with about 20,000 subscribers. Each English guide is written from the Japanese shop-floor point of view and checked against the cited standards.
