根本原因分析 - 5 Whys手法

目標: 症状ではなく根本原因に対処し、問題を一度で適切に解決する。

症状 vs 根本原因

セクション別ロード

クイックチェックリスト

修正を実装する前に確認:

• これは症状を修正しているのか、原因を修正しているのか？
• この問題を完全に防ぐには何が必要か？
• よりシンプルな技術（HTML/CSS）で解決できないか？
• ここで本当にJavaScriptが必要か？
• この修正は新たな複雑さを導入しないか？

5 Whysプロセス

1. なぜこの問題が発生するのか？ → [観察可能な事実]
2. なぜそれが起こるのか？ → [実装の詳細]
3. なぜそうなっているのか？ → [設計上の決定]
4. なぜそれが存在するのか？ → [アーキテクチャ上の制約]
5. なぜそのように設計されたのか？ → [根本原因]

分析例

問題: ボタンクリックがアクションを2回トリガーする

1. なぜ2回？ → クリックハンドラが2回発火
2. なぜ2回ハンドラ？ → クリック中にReactが再レンダリング
3. なぜ再レンダリング？ → クリックハンドラ内の状態更新が再レンダリングを引き起こす
4. なぜクリック内で状態？ → 状態であるべきでないものに状態を使用
5. なぜ状態を使用？ → 根本原因: 命令的アクションをリアクティブ状態として扱っている

解決策: 命令的フラグにはstateではなくrefを使用、またはボタンを適切に無効化

キー原則

よくある症状パターン

タイミング問題

// ❌ 症状: DOMを待つためにsetTimeout
useEffect(() => {
  setTimeout(() => { document.getElementById('target')?.scrollIntoView() }, 100)
}, [])

// ✅ 根本原因: React refを使用
const targetRef = useRef<HTMLDivElement>(null)
useEffect(() => { targetRef.current?.scrollIntoView() }, [])

状態同期

// ❌ 症状: 状態を同期するための複数のeffect
useEffect(() => { setFilteredItems(items.filter(i => i.active)) }, [items])
useEffect(() => { setCount(filteredItems.length) }, [filteredItems])

// ✅ 根本原因: 同期ではなく導出
const filteredItems = useMemo(() => items.filter(i => i.active), [items])
const count = filteredItems.length

子状態のポーリング

// ❌ 症状: 親が子の状態をポーリング
const childRef = useRef()
useEffect(() => {
  const interval = setInterval(() => { childRef.current?.getValue() }, 1000)
}, [])

// ✅ 根本原因: 適切なデータフロー（状態の持ち上げまたはコールバック）
const [value, setValue] = useState()
return <Child onValueChange={setValue} />

参照

コア原則

• @~/.claude/rules/development/PROGRESSIVE_ENHANCEMENT.md - シンプルが先
• @~/.claude/rules/reference/PRINCIPLES.md - 最もシンプルな解決策

関連スキル

• enhancing-progressively - CSS-firstアプローチはしばしば根本原因に対処
• applying-code-principles - 設計原則が根本原因の問題を防ぐ

使用するエージェント

• root-cause-reviewer - このスキルの主な利用者