cause-and-effect

原因と結果の分析

フィッシュボーン（石川）図分析を適用し、複数のカテゴリにわたって問題の潜在的な原因を体系的に調査します。

説明

6つのカテゴリ（人、プロセス、テクノロジー、環境、方法、資材）にわたって潜在的な原因を体系的に調べます。要因を特定するための、構造化された「フィッシュボーン」形式の図を作成します。

使用方法

/cause-and-effect [problem_description]

変数

• PROBLEM：分析する問題（デフォルト：入力を求めます）
• CATEGORIES：調査するカテゴリ（デフォルト：6つすべて）

手順

1. 問題を明確に述べます（魚の「頭」にあたる部分）
2. 各カテゴリについて、考えられる原因をブレインストーミングします：
   • 人：スキル、トレーニング、コミュニケーション、チームの人間関係
   • プロセス：ワークフロー、手順、標準、レビュー
   • テクノロジー：ツール、インフラストラクチャ、依存関係、設定
   • 環境：作業環境、デプロイ先、外部要因
   • 方法：アプローチ、パターン、アーキテクチャ、プラクティス
   • 資材：データ、依存関係、サードパーティサービス、リソース
3. 考えられる原因ごとに「なぜ」と問い、さらに掘り下げます
4. 要因となっている原因と根本原因を特定します
5. 影響度と可能性に基づいて原因の優先順位を付けます
6. 優先度の高い原因に対する解決策を提案します

例

例 1：API の応答遅延

Problem: API responses take 3+ seconds (target: <500ms)

PEOPLE
├─ Team unfamiliar with performance optimization
├─ No one owns performance monitoring
└─ Frontend team doesn't understand backend constraints

PROCESS
├─ No performance testing in CI/CD
├─ No SLA defined for response times
└─ Performance regression not caught in code review

TECHNOLOGY
├─ Database queries not optimized
│  └─ Why: No query analysis tools in place
├─ N+1 queries in ORM
│  └─ Why: Eager loading not configured
├─ No caching layer
│  └─ Why: Redis not in tech stack
└─ Synchronous external API calls
   └─ Why: No async architecture in place

ENVIRONMENT
├─ Production uses smaller database instance than needed
├─ No CDN for static assets
└─ Single region deployment (high latency for distant users)

METHODS
├─ REST API design requires multiple round trips
├─ No pagination on large datasets
└─ Full object serialization instead of selective fields

MATERIALS
├─ Large JSON payloads (unnecessary data)
├─ Uncompressed responses
└─ Third-party API (payment gateway) is slow
   └─ Why: Free tier with rate limiting

ROOT CAUSES:
- No performance requirements defined (Process)
- Missing performance monitoring tooling (Technology)
- Architecture doesn't support caching/async (Methods)

SOLUTIONS (Priority Order):
1. Add database indexes (quick win, high impact)
2. Implement Redis caching layer (medium effort, high impact)
3. Make external API calls async with webhooks (high effort, high impact)
4. Define and monitor performance SLAs (low effort, prevents regression)

例 2：不安定なテストスイート

Problem: 15% of test runs fail, passing on retry

PEOPLE
├─ Test-writing skills vary across team
├─ New developers copy existing flaky patterns
└─ No one assigned to fix flaky tests

PROCESS
├─ Flaky tests marked as "known issue" and ignored
├─ No policy against merging with flaky tests
└─ Test failures don't block deployments

TECHNOLOGY
├─ Race conditions in async test setup
├─ Tests share global state
├─ Test database not isolated per test
├─ setTimeout used instead of proper waiting
└─ CI environment inconsistent (different CPU/memory)

ENVIRONMENT
├─ CI runner under heavy load
├─ Network timing varies (external API mocks flaky)
└─ Timezone differences between local and CI

METHODS
├─ Integration tests not properly isolated
├─ No retry logic for legitimate timing issues
└─ Tests depend on execution order

MATERIALS
├─ Test data fixtures overlap
├─ Shared test database polluted
└─ Mock data doesn't match production patterns

ROOT CAUSES:
- No test isolation strategy (Methods + Technology)
- Process accepts flaky tests (Process)
- Async timing not handled properly (Technology)

SOLUTIONS:
1. Implement per-test database isolation (high impact)
2. Replace setTimeout with proper async/await patterns (medium impact)
3. Add pre-commit hook blocking flaky test patterns (prevents new issues)
4. Enforce policy: flaky test = block merge (process change)

例 3：機能の開発に 3 週間ではなく 3 か月かかる

Problem: Simple CRUD feature took 12 weeks vs. 3 week estimate

PEOPLE
├─ Developer unfamiliar with codebase
├─ Key architect on vacation during critical phase
└─ Designer changed requirements mid-development

PROCESS
├─ Requirements not finalized before starting
├─ No code review for first 6 weeks (large diff)
├─ Multiple rounds of design revision
└─ QA started late (found issues in week 10)

TECHNOLOGY
├─ Codebase has high coupling (change ripple effects)
├─ No automated tests (manual testing slow)
├─ Legacy code required refactoring first
└─ Development environment setup took 2 weeks

ENVIRONMENT
├─ Staging environment broken for 3 weeks
├─ Production data needed for testing (compliance delay)
└─ Dependencies blocked by another team

METHODS
├─ No incremental delivery (big bang approach)
├─ Over-engineering (added future features "while we're at it")
└─ No design doc (discovered issues during implementation)

MATERIALS
├─ Third-party API changed during development
├─ Production data model different than staging
└─ Missing design assets (waited for designer)

ROOT CAUSES:
- No requirements lock-down before start (Process)
- Architecture prevents incremental changes (Technology)
- Big bang approach vs. iterative (Methods)
- Development environment not automated (Technology)

SOLUTIONS:
1. Require design doc + finalized requirements before starting (Process)
2. Implement feature flags for incremental delivery (Methods)
3. Automate dev environment setup (Technology)
4. Refactor high-coupling areas (Technology, long-term)

注意事項

• フィッシュボーン図は、複数の領域にまたがるシステム上の問題を明らかにします
• 複数の原因が組み合わさって問題を引き起こすことがよくあります
• 各カテゴリで最初に見つかった原因だけで終わらせず、さらに掘り下げます
• 複数のカテゴリにまたがる原因もあります（その場合は印を付けます）
• 根本原因は多くの場合、テクノロジーだけでなくプロセスや方法にあります
• 特定の原因をさらに分析するには、/why コマンドと併用します
• 解決策の優先順位は、影響度 × 実現可能性 ÷ 労力で決めます
• 症状だけでなく、根本原因に対処します