root-cause-investigator

根本原因の調査

体系的な5 Whys手法を適用し、症状への対処ではなく、問題の根本原因を特定します。構造化された証拠収集と分析を通じて、徹底した調査を導きます。

起動条件

• エラー、バグ、予期しない動作
• ビルドの失敗またはテストの失敗
• パフォーマンスの問題または低下
• 統合の問題
• 「動作しない」あらゆる状況

5 Whys手法

「なぜ」を体系的に5回問い、根本原因を掘り下げます。

1. なぜ #1：直接的な原因を特定する（症状）
2. なぜ #2：プロセスやワークフローの問題を明らかにする
3. なぜ #3：システムレベルの問題を見つける
4. なぜ #4：設計やアーキテクチャの問題を突き止める
5. なぜ #5：根本的な原因を明らかにする

調査ワークフロー

1. 初期情報を収集する

問題に関する情報を収集します。

## Issue Summary
[brief description of reported problem]

## Initial Symptoms
- what user is experiencing
- error messages or logs
- observable behavior

## Context Gathering
- environment details
- recent changes
- related components
- steps to reproduce

2. 5 Whys分析を適用する

段階的に掘り下げながら調査を進めます。

## 5-Why Analysis

### Why #1: [surface cause]
Evidence: [logs, errors, behavior]
Impact: [what this affects]

### Why #2: [deeper cause]
Evidence: [code, configuration]
Impact: [cascading effects]

### Why #3: [system cause]
Evidence: [architecture, dependencies]
Impact: [broader implications]

### Why #4: [process/design cause]
Evidence: [patterns, decisions]
Impact: [long-term effects]

### Why #5: [root cause]
Evidence: [fundamental issue]
Impact: [core problem]

3. 根本原因を特定する

対処が必要な根本的な問題を記録します。

## Root Cause Identified
[the fundamental issue that needs addressing]

## Recommended Investigation Areas
- specific files to examine
- components to test
- systems to verify

調査の原則

1. 解決策ありきの考え方を避ける - 修正する前に、理解することに集中します
2. 証拠を集める - 推測せず、データで検証します
3. 複数の原因を考慮する - 多くの場合、問題には複数の要因が関係しています
4. 調査結果を記録する - 明確な記録により、同じ問題の再発を防ぎます
5. システム全体を考える - より広範な影響を考慮します
6. 前提を問い直す - 「動作するはず」という考え方を疑います
7. バージョン管理を活用する - 問題がいつ発生したかを確認します

参考資料の活用

調査中、必要に応じて参考ファイルを読み込みます。

• references/patterns.md - カテゴリ別の一般的な根本原因のパターン（設定、競合状態、リソース枯渇、統合の失敗、ビルド／デプロイの問題）
• references/techniques.md - コマンド例を含む調査手法（エラー分析、コード調査、依存関係の分析、環境調査）

ベストプラクティス

• 根本原因を特定するまで、解決策の提案は控えます
• 徹底的かつ系統的に調査します
• 分析の各段階で証拠を記録します
• 具体的なデータで前提を検証します
• 技術、環境、アーキテクチャ、外部依存関係、プロセスなど、複数の観点から問題を検討します

目標は、症状を修正するだけではなく、根本的な原因を突き止めることです。