---

name: problem-solving description: 壁にぶつかった時の思考パターンとアプローチを提供。行き詰まりを打破する。

Problem Solving Skill

目的

壁にぶつかった時の思考パターンとアプローチを提供し、行き詰まりを打破する。

使用タイミング

• 実装方法が思いつかない
• バグの原因が特定できない
• パフォーマンス改善の方向性が見えない
• 設計の選択肢で迷っている
• 既存の方法では要件を満たせない

壁打破のチェックリスト

🔍 前提条件の再確認

Copy□ 本当にその制約は必要か?
  例: "メモリ2KB以内" → 本当に2KB? 4KBなら許容される?
  
□ 要件を正しく理解しているか?
  例: "高速化" → どのくらい? 10%? 10倍?
  
□ 問題を正しく定義しているか?
  例: "ログインが遅い" → どの部分? DB? ネットワーク? UI?

🔄 逆方向思考

Copy□ ゴールから逆算したか?
  順方向: A → B → C → ゴール
  逆方向: ゴール → C必要 → B必要 → A必要
  
□ 「やらない」選択肢を考えたか?
  例: "機能追加" → 本当に必要? 既存機能で代替できない?
  
□ 問題の原因ではなく、結果から考えたか?
  例: "エラーが出る" → どんなエラー? いつ? どの条件で?

📊 抽象度の変更

Copy□ より高い抽象度で考えたか?
  具体: "Pythonでファイル読み込みが遅い"
  抽象: "I/Oボトルネックをどう解消するか"
  → キャッシング、先読み、非同期I/O
  
□ より低い抽象度で考えたか?
  抽象: "パフォーマンスが悪い"
  具体: "どの関数が遅い? CPU? メモリ? I/O?"
  → プロファイラで計測

🧩 問題の分割

Copy□ 問題を細分化したか?
  大: "認証システムを作る"
  小: "ユーザー登録 + ログイン + セッション管理 + パスワードリセット"
  
□ 最小の動くものから始められるか?
  MVP: まず最小限の機能だけ実装して動かす
  
□ 独立した部分はないか?
  例: "UIとロジックを分離" → ロジックだけ先にテスト

🔍 類似問題の調査

Copy□ 他の分野での解決例を調べたか?
  例: Web開発のキャッシング → 組み込みでも応用可能?
  
□ 既存ツール・ライブラリで解決できないか?
  例: "JSON解析を自作" → 既存のライブラリを使う
  
□ 似た問題を以前に解決していないか?
  → failure_log を検索
  → 過去の日報を確認

⚖️ トレードオフの見直し

Copy□ パフォーマンスを捨てればシンプルになるか?
  例: O(n²)アルゴリズムで十分な場合も多い
  
□ 完璧を求めすぎていないか?
  例: "全ケースに対応" → 80%のケースで十分では?
  
□ 要件を緩和できないか?
  例: "リアルタイム" → 1秒遅延は許容される?

🎯 極端な仮定

Copy□ 制約がなかったらどうするか?
  例: "無限メモリがあったら?" → 理想的な設計を考える
  → 現実に戻す際に本質的な解が見える
  
□ 10倍の性能が必要だったら?
  例: "10倍速くするには?" → アルゴリズム根本変更が必要
  → 現実的な改善案が見える
  
□ 全く別の手段でも良いなら?
  例: "ソフトウェアではなくハードウェアで解決できる?"

実践例

例1: メモリ制約の問題

Copy問題: 
2KB RAM制約の中でログ機能を実装したい

壁打ちプロセス:

1. 前提確認
   Q: 本当に2KB? → Yes, Arduino Uno
   Q: 全ログを保持する必要がある? → No

2. 要件緩和
   - 最新N件だけ保持 (リングバッファ)
   - ログレベルでフィルタリング
   - 外部メモリ (SDカード) 活用

3. 類似問題
   - 組み込みLinuxのdmesg → リングバッファ使用
   - syslog → レベル別フィルタリング

4. 解決案
   案1: 64バイト×10件のリングバッファ (640B)
   案2: フラッシュメモリに書き込み (RAM節約)
   案3: エラーレベルのみRAM、他は破棄

例2: パフォーマンス問題

Copy問題:
API応答が遅い (平均2秒)

壁打ちプロセス:

1. 問題の分割
   - DB クエリ: 1.5秒
   - ビジネスロジック: 0.3秒
   - JSON シリアライズ: 0.2秒
   → DBが主な原因

2. 抽象化
   "DBが遅い" → "データ取得が遅い"
   → キャッシュ、インデックス、クエリ最適化

3. 極端な仮定
   Q: 0.1秒以下にするには?
   → インメモリDB、マテリアライズドビュー
   → 現実的には Redis キャッシュ

4. 解決案
   案1: Redis キャッシュ導入 (推定0.5秒)
   案2: DB インデックス追加 (推定1.0秒)
   案3: クエリ最適化 (推定1.2秒)

行き詰まった時の具体的アクション

ステップ1: 情報を書き出す

Copy# ブレインストーミングファイルを作成
cat > claude_tmp/brainstorming/$(date +%Y%m%d_%H%M%S).md << 'EOF'
# 問題
[何に困っているか]

# 試したこと
1. [アプローチ1] → [結果]
2. [アプローチ2] → [結果]

# 制約条件
- [制約1]
- [制約2]

# 疑問点
- [疑問1]
- [疑問2]
EOF

ステップ2: チェックリストを実行

上記のチェックリストを1つずつ確認する

ステップ3: スキルを活用

Copy- pattern-thinking: 思考パターンを確認
- auto-consultation: 自己対話で整理
- systematic-debugging: バグなら4フェーズ分析
- brainstorming-design: 複数案を発散

ステップ4: 相談準備

Copy# consultation スキルを参照
view ~/.claude/skills/consultation/SKILL.md

# /bounce で相談
/bounce [問題の要約]

よくある落とし穴

落とし穴1: 最初の案に固執

Copy❌ 悪い例:
"この方法しかない" → 実装 → 行き詰まる

✅ 良い例:
3つの案を列挙 → 比較 → 選択 → 実装

落とし穴2: 問題を大きく捉えすぎ

Copy❌ 悪い例:
"認証システム全体を作る" → 圧倒される

✅ 良い例:
"まずユーザー登録だけ" → 動いた → 次にログイン

落とし穴3: 完璧主義

Copy❌ 悪い例:
"全ケースに対応しないと" → 実装が複雑化

✅ 良い例:
"80%のケースをカバー" → シンプル → 必要なら拡張

関連スキル

• pattern-thinking - 思考フレームワーク
• brainstorming-design - アイデア発散
• auto-consultation - 自己対話
• systematic-debugging - バグ分析
• consultation - 相談準備

まとめ

壁にぶつかった時は「考え方を変える」

1. 前提を疑う
2. 視点を変える (逆方向、抽象度)
3. 分割する
4. 類似例を探す
5. トレードオフを見直す
6. 極端に考えてから戻す

それでもダメなら相談する。1人で悩み続けない。