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

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

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

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

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

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

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

問題: 
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、他は破棄

問題:
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秒)

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

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

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

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

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

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

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

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

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

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

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

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

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