majiayu000 Root Cause Challenge Pattern - 機能要求の真の動機を問う
Extracted: 2026-02-09 Context: 新機能・アーキテクチャ変更・依存追加などの意思決定時
Problem
表面的な理由で機能追加・アーキテクチャ変更を進めると:
- 真の価値を見誤る
- 技術的好奇心やサンクコストに引きずられる
- より高いROIの代替案を見逃す
- 長期的なメンテナンス負債を作る
Solution: 5ステップの根本原因チャレンジ
Step 1: 論理的矛盾を探す
提案されたアーキテクチャ判断に矛盾がないかチェック:
- "なぜAは却下でBは承認なのか？"
- "基準は一貫しているか？"
- "コスト効率は合理的か？"
例（このセッションより）:
Batch API: $5節約のために250行 → ❌却下
OpenAI Provider: $10活用のために750行 → ✅承認
矛盾: LOC/$ 比率が OpenAI Provider の方が悪いのに承認されている
→ 表面的理由（$10クレジット）が本当の動機ではない可能性
Step 2: 根本的な問いを投げる
実装方法でなく、存在意義を問う:
- "そもそもこの機能は必要か？"
- "誰が本当に求めているか？"
- "解決しようとしている問題は実在するか？"
- "ツールは既に動いている。これは本当に足りない機能か？"
Step 3: Architectに忌憚ない評価を求める
重要: 単なる実装判断でなく、本質的価値の評価を依頼:
## Your Task
Answer the fundamental question: Should we build this feature at all?
Be brutally honest. The user wants candid feedback for growth, not validation.
### Evaluate:
1. **True ROI** - Is the return worth the investment?
- Investment: Code complexity, maintenance burden
- Return: Concrete value (NOT time estimates)
2. **Real motivations** - What's driving this? (be honest)
- Stated reason vs actual reason
- Technical curiosity? Architecture appeal? Sunk cost?
3. **Alternative uses of effort** - What else could be built?
- Focus on value delivered, not time estimates
4. **Honest scenarios** - Will this actually be used?
- Usage frequency: Every time? Sometimes? Rarely?
### Important
- Challenge the premise
- Consider opportunity cost
- Check for YAGNI violations
- DO NOT base ROI on time estimates (they're unreliable)
Step 4: 代替案と比較
同じ複雑性レベルで何ができるか列挙:
- より高い価値を提供する機能
- 既知のバグ修正
- UX改善
- 技術的負債の返済
価値比較表を作る（時間見積もりは使わない）:
| 機能 | 複雑性 | 価値 | 使用頻度 | 新機能 or 改善 |
|---|---|---|---|---|
| 提案機能 | 高 | ？ | 低 | 新機能 |
| 代替案A | 高 | 高 | 毎回 | 新機能 |
| 代替案B | 中 | 中 | 時々 | 改善 |
| 代替案C | 低 | 低 | 毎回 | バグ修正 |
評価基準:
- 複雑性: 低/中/高（コード量、依存、テスト負荷）
- 価値: 解決する問題の大きさ
- 使用頻度: 毎回/時々/稀（どれだけ恩恵を受けるか）
- 種別: 新機能/改善/バグ修正
Step 5: サンクコストを切り捨てる
既に投資した労力（リサーチ、ドキュメント作成）は判断材料にしない:
- "既に調査したから実装しないともったいない" ← サンクコストの罠
- 正しい問い: "今ゼロから始めるとして、これを優先するか？"
Example (from pdf2anki OpenAI support session)
状況
- OpenAI API対応を計画（$10クレジット活用のため）
- 実装規模: ~1,000行、テスト移行209箇所
Step 1: 矛盾発見
- ユーザー: "Batch APIは$5で却下なのに、OpenAIは$10で承認？矛盾してない？"
Step 2: 根本を問う
- "そもそもOpenAI対応自体をやるべきか？"
Step 3: Architectに評価依頼
- "忌憚ない意見をもらうことが私を最も成長させる"
- Architect評価:
- 投資: ~1,000行、複雑な抽象化層、永続的なメンテナンス負債
- リターン: $10クレジット消費（一度きり）
- 真の動機: 技術的好奇心、アーキテクチャの美しさ、サンクコスト
- 使用頻度予測: 1-2回試して終わり（Claudeの方が日本語で優秀）
- 判定: やるべきでない
Step 4: 代替案
| 機能 | 複雑性 | 価値 | 頻度 |
|---|---|---|---|
| OpenAI対応 | 高（1,000行） | 低（$10消費） | 稀（1-2回） |
| 画像認識カード | 高（新API統合） | 高（新カテゴリ対応） | 毎回（図表PDF） |
| インタラクティブTUI | 中（UI実装） | 中（UX改善） | 毎回（全セッション） |
| プロンプト評価FW | 中（eval実装） | 中（品質向上） | 時々（改善時） |
| トークン推定修正 | 低（ロジック修正） | 低（精度向上） | 毎回（日本語） |
明らかに優先度の高い代替案が複数存在
Step 5: 決断
- OpenAI対応をスキップ
- 4つの高価値機能に投資
- サンクコスト（3つのドキュメント、数時間のリサーチ）を切り捨て
結果: 同じ複雑性レベルで遥かに高い価値を獲得
When to Use
以下の場面で必ずこのパターンを適用:
- 新機能の追加 - "これ欲しい"と思った時
- アーキテクチャ変更 - "きれいにリファクタリングしたい"と思った時
- 依存の追加 - "このライブラリ便利そう"と思った時
- 抽象化の導入 - "将来拡張できるように..."と思った時
特に警戒すべきトリガーワード:
- "将来のために..."（YAGNI違反の可能性）
- "きれいな設計..."（過剰設計の可能性）
- "せっかく調査したから..."（サンクコスト）
- "$Xのクレジットが余ってる..."（アンカリング効果）
- "すぐできる"（時間見積もりは当てにならない）
Key Insight: 時間見積もりは使わない
重要: AIアシスタントの時間見積もりは不正確なため、ROI計算に使用しない。
代わりに評価すべき指標:
- コード量: 行数、ファイル数（複雑性の指標）
- テスト負荷: テスト数、モック箇所（保守コスト）
- 依存追加: 新しい外部依存の数（リスク）
- 具体的価値: 金額、ユーザー数、使用頻度（測定可能な価値）
- 問題の実在性: 既存のバグ？ユーザー要望？推測？
Related Patterns
- YAGNI (You Aren't Gonna Need It)
- Sunk Cost Fallacy
- Opportunity Cost Analysis
- "Don't Import the Warehouse for a Single Wheel"
Anti-Patterns to Avoid
- "Architectural Vanity" - きれいな抽象化のために実装
- "Feature Completionism" - 使われない機能を完全性のために追加
- "Credit Anchoring" - 無料クレジットを使い切ることが目的化
- "Research Justification" - 調査コストを正当化するための実装
- "Time-Based ROI" - 不確実な時間見積もりでROIを計算
Success Story
このパターンを適用したpdf2ankiプロジェクトでは:
- ❌ 削減: OpenAI対応（~1,000行、低価値、稀な使用）
- ✅ 選択: 画像認識、TUI、評価FW、バグ修正（同等の複雑性、高価値、頻繁な使用）
- 結果: プロジェクトの価値を最大化する正しい意思決定