匠人学院 JR Academy学AI来匠人
Chapter 29
29 / 38

Five Whys Analysis

⏱️ 8 min

What Are the Five Whys?

The Five Whys is a root cause analysis technique. You keep asking "why" until you reach the fundamental cause, instead of stopping at surface symptoms.

Process

1. Define the Problem

Clearly state the issue or symptom

2. Ask "Why?" Five Times

  • Why did this problem occur? → Answer 1
  • Why did Answer 1 happen? → Answer 2
  • Why did Answer 2 happen? → Answer 3
  • Why did Answer 3 happen? → Answer 4
  • Why did Answer 4 happen? → Answer 5 (Root Cause)

3. Validate Root Cause

  • Verify the logical chain
  • Check if addressing root cause prevents recurrence
  • Consider multiple root causes if applicable

4. Develop Solutions

  • Address the root cause, not just symptoms
  • Create preventive measures
  • Consider systemic improvements

Example: Application Crash

Problem: Application crashes when processing large files

  1. Why? → The application runs out of memory
  2. Why? → It loads entire file into memory at once
  3. Why? → The file parser wasn't designed for streaming
  4. Why? → Initial requirements only specified small files
  5. Why? → Requirements gathering didn't consider future growth

Root Cause: Incomplete requirements gathering process

Solution: Implement streaming parser and improve requirements process

Example: API Response Slow

Problem: API endpoint taking 10+ seconds to respond

  1. Why? → Database query is slow
  2. Why? → No index on the queried column
  3. Why? → Schema migration didn't include index
  4. Why? → No performance review in migration process
  5. Why? → Migration checklist is incomplete

Root Cause: Incomplete migration checklist

Solution: Add performance review step to migration process

Best Practices

  • Focus on process, not people - don't blame individuals
  • Look for systemic issues - find structural problems
  • Document the analysis - record the full reasoning chain
  • Involve relevant stakeholders - get the right people in the room
  • Test solutions address root cause - verify your fix actually works

Applying Five Whys in Vibe Coding

When AI-generated code has issues, Five Whys can pinpoint what went wrong:

Problem: AI generated code doesn't compile

  1. Why? → Using wrong syntax for the framework version
  2. Why? → AI assumed older framework version
  3. Why? → Prompt didn't specify framework version
  4. Why? → No project context provided
  5. Why? → Missing CLAUDE.md or context-prime step

Root Cause: Missing project context

Solution: Always run /context-prime before complex tasks

Five Whys Template

## Problem Statement

[Clear description of the issue]

## Analysis

### Why #1

Q: Why did this happen?
A: [Answer]

### Why #2

Q: Why did [Answer #1] happen?
A: [Answer]

### Why #3

Q: Why did [Answer #2] happen?
A: [Answer]

### Why #4

Q: Why did [Answer #3] happen?
A: [Answer]

### Why #5

Q: Why did [Answer #4] happen?
A: [Answer - Root Cause]

## Root Cause

[Summary of the fundamental issue]

## Proposed Solutions

1. [Solution 1]
2. [Solution 2]

## Preventive Measures

-   [Measure 1]
-   [Measure 2]

Next Steps

Check out Mermaid Diagram Generation to visualize your analysis results.

📚 Related resources

❓ Common questions

Open a question to review the practical answer.

Do I really need exactly 5 whys — can I ask fewer or more?

Five is empirical, not a rule. Toyota's data showed most root causes surface at depth 4-5; if your third "why" is still on the surface ("the code has a bug" → "the logic is wrong") you are too shallow, and at depth 7-8 you start hitting philosophy ("why do humans err"). Test for true root cause: would fixing it prevent the same class of problem from recurring.

AI-generated code has a bug — how do I run Five Whys on it?

Worked example from the chapter: (1) code does not compile → (2) wrong syntax for the framework version → (3) AI assumed an older framework → (4) prompt did not specify version → (5) skipped `/context-prime`, no project context was loaded. Root cause is missing project context — the fix is not a better prompt but baking the context into CLAUDE.md.

What are the common pitfalls of Five Whys?

Three frequent pitfalls: (1) blaming people instead of process — "why did the bug ship? because the reviewer missed it" turns analysis into blame, the chapter's rule is focus on process, not people; (2) single-thread chasing — one symptom can have 2-3 independent root causes, run them in parallel; (3) guessing without verifying — each layer needs a log / data / repro as evidence, not "I think that is it".

In the slow-API example, why is "missing DB index" not the root cause?

Because adding this index does not stop the next migration from forgetting again. The chapter's chain: slow API → slow query → no index → migration omitted the index → no performance-review step in the migration process. Root cause is the incomplete migration checklist — the fix is adding a review step, not a one-off index.

When does Five Whys work and when does it not?

Good fit: single-point issues with a clean causal chain (production bug, performance regression, process failure) — five hops gets you to an actionable root cause. Bad fit: emergent issues in complex systems (distributed race conditions, multi-service coordination failures) — no single root cause exists, you need multi-factor methods like fishbone diagrams or fault tree analysis.