assumption-buster

前提破壊

体系的な反例の生成、エッジケースの探索、敵対的な思考を通じて、前提を積極的に特定し、疑い、反証を試み、隠れた弱点や誤った思い込みを明らかにします。

どのようなときに使うか

次のような場合に、このスキルを使います。

• 重要な意思決定が、検証されていない前提に依存している
• システムの障害コストが高い（安全性、財務、評判）
• チームが確証バイアスに陥っている疑いがある
• 敵対的な環境（セキュリティ、競争、規制）に備える
• システムの根幹にある考え方の耐性をテストする
• 大規模な投資の前に、基本的な前提を検証する
• 適用されない可能性がある「業界のベストプラクティス」に異議を唱える
• アーキテクチャ上の意思決定に負荷をかけてテストする
• 監査、侵入テスト、規制当局による審査に備える

何をするか

1. 前提への積極的な挑戦

• 前提をただテストするのではなく、積極的に反証を試みる
• 前提を崩す反例を生成する
• 前提が壊滅的に破綻するエッジケースを見つける
• 証拠に含まれる矛盾のパターンを特定する
• 境界条件が破綻するまで徹底的に負荷をかける

2. 反証の方法論

• ポパーの科学的方法を用いて反証を試みる
• ブラックスワン（まれだが壊滅的な反例）を探す
• 前提の破綻を最大化するストレスシナリオを構築する
• マーフィーの法則を適用する――「起こり得ることは、いずれ起こる」
• 障害モードの組み合わせ爆発を探る

3. 敵対的テスト

• システムを壊そうとする攻撃者のように考える
• 弱点を探して利用しようとする競合他社の視点を取る
• （リソースの制約、悪意ある行為者など）敵対的な環境をシミュレーションする
• 設計仕様を超える極限条件でテストする
• 障害の連鎖や波及効果を引き起こす

4. 認知バイアスへの対策

• 反証となる証拠を探し、確証バイアスに狙いを定める
• まれなケースを探し、利用可能性ヒューリスティックに対抗する
• 極端な値を探り、アンカリング効果に対抗する
• 厳密なストレステストで過信を克服する
• 異論の視点を取り入れ、集団思考を打ち破る

前提を破るテクニック

技術的な前提に対して：

• 限界まで負荷をかける：「どれほどの負荷でこの前提が崩れますか？」
• リソースの枯渇：「リソースが最小限の場合、何が起こりますか？」
• 依存関係の障害：「すべての依存関係が同時に障害を起こしたらどうなりますか？」
• バージョン地獄：「すべてのバージョンが一致していなかったらどうなりますか？」
• データ破損：「データが意図的に不正な形式にされていたらどうなりますか？」

ビジネス上の前提に対して：

• 市場の逆転：「顧客の好みが一晩で変わったらどうなりますか？」
• 競合他社の革新：「競合他社が、これをより良く、より安く解決したらどうなりますか？」
• 規制の急変：「規制が全面的に変わったらどうなりますか？」
• 経済の崩壊：「資金が突然なくなったらどうなりますか？」
• チームの解散：「重要なメンバーが退職したらどうなりますか？」

プロセス上の前提に対して：

• コミュニケーションの断絶：「すべてのコミュニケーションが途絶えたらどうなりますか？」
• ツールの障害：「主要なツールが利用できなくなったらどうなりますか？」
• 知識の喪失：「組織の知識が失われたらどうなりますか？」
• スケジュールの圧縮：「締め切りが90％早まったらどうなりますか？」
• 品質の低下：「品質基準が着実に低下したらどうなりますか？」

例

# Aggressively test a technical assumption
npm run assumption-buster:disprove -- --assumption "database-always-available" --method "chaos-engineering"

# Find counterexamples for a business assumption
npm run assumption-buster:counterexamples -- --assumption "users-prefer-mobile" --data "analytics-export.csv"

# Stress-test architectural decisions
npm run assumption-buster:stress-test -- --architecture "event-driven" --scenario "complete-network-partition"

# Generate failure scenarios for a process
npm run assumption-buster:failure-scenarios -- --process "ci-cd-pipeline" --intensity extreme

# Comprehensive assumption busting
npm run assumption-buster:all -- --criticality high --thoroughness maximum

出力形式

Assumption Busting Report
──────────────────────────────
Target: Payment Processing System
Assumptions Targeted: 14
Busting Duration: 2 hours
Busting Intensity: Aggressive

Assumption Busting Results:

1. Assumption: "Payment gateway responses always within 2 seconds"
   Status: ❌ BUSTED (Catastrophically)
   
   Counterexamples Found:
   - Network partition causes indefinite hangs (no timeout)
   - Gateway DDoS attack results in 30+ second responses
   - SSL certificate expiration causes silent failures
   - DNS poisoning redirects to malicious endpoints
   - Gateway vendor bankruptcy (no responses at all)
   
   Stress Test Results:
   - Under simulated attack: 85% of requests exceed 2 seconds
   - Failure cascade: timeouts cause thread pool exhaustion
   - Worst-case latency: 47 seconds (complete system stall)
   
   Impact if Believed:
   - Payment system becomes unresponsive during attacks
   - Financial losses from failed transactions
   - Customer trust destroyed
   - Recovery requires complete system restart
   
   Recommendation:
   Implement circuit breakers, aggressive timeouts, fallback providers

2. Assumption: "Users always complete checkout in single session"
   Status: ⚠️ PARTIALLY BUSTED (Significant weaknesses)
   
   Counterexamples Found:
   - Mobile network drops during payment (common)
   - Browser crashes after cart creation (frequent)
   - Users comparison shop across tabs (standard behavior)
   - Payment requires external verification (bank 2FA)
   - Users interrupted by real-world events (constant)
   
   Stress Test Results:
   - 41% of simulated users experience session-breaking events
   - Recovery rate without persistence: 12%
   - Data loss probability: 29%
   
   Impact if Believed:
   - Significant abandoned cart revenue loss
   - User frustration and negative reviews
   - Competitive disadvantage against persistent carts
   
   Recommendation:
   Implement cart persistence, resume functionality, email reminders

3. Assumption: "Fraud detection catches 99% of fraudulent transactions"
   Status: ❌ BUSTED (Dangerously false)
   
   Counterexamples Found:
   - New fraud patterns not in training data (always emerging)
   - Low-and-slow attacks evade threshold detection
   - Synthetic identity fraud has no historical patterns
   - Insider threats bypass external detection
   - Collusion attacks distribute suspicious activity
   
   Adversarial Testing Results:
   - Simulated novel fraud: 67% detection rate (not 99%)
   - Adaptive attackers: detection degrades over time
   - False positive rate forces threshold lowering
   - Detection latency allows transaction completion
   
   Impact if Believed:
   - Financial losses from undetected fraud
   - Regulatory penalties for inadequate controls
   - Reputation damage from fraud incidents
   
   Recommendation:
   Implement multi-layered fraud detection, continuous model updates

4. Assumption: "Database transactions always rollback on failure"
   Status: ✅ WITHSTOOD TESTING (But edge cases found)
   
   Stress Test Results:
   - Normal failures: proper rollback (assumption holds)
   - Edge Cases Discovered:
     * Connection pool exhaustion during rollback
     * Deadlock during distributed transaction cleanup
     * Storage engine corruption preventing rollback
     * Partial network failure leaving transactions dangling
   
   Recommendation:
   Implement transaction monitoring, orphan detection, manual cleanup procedures

Assumption Survival Rate:
- Completely Busted: 6 assumptions (43%)
- Partially Busted: 5 assumptions (36%)
- Withstood Testing: 3 assumptions (21%)

Critical Vulnerabilities Exposed:
1. Payment timeout handling (catastrophic failure possible)
2. Session persistence (significant revenue loss)
3. Fraud detection gaps (financial and regulatory risk)
4. Transaction cleanup (data consistency risk)

Busting Effectiveness Metrics:
- Novel failure modes discovered: 23
- Catastrophic scenarios identified: 7
- Previously unknown risks: 11
- Testing time vs value: Extremely high ROI
- Confidence adjustment: From 85% to 42% (more realistic)

Actionable Insights:
1. IMMEDIATE: Implement circuit breakers for payment gateway
2. HIGH PRIORITY: Add cart persistence and resume functionality
3. HIGH PRIORITY: Enhance fraud detection with behavioral analysis
4. MEDIUM PRIORITY: Add transaction monitoring and cleanup
5. MEDIUM PRIORITY: Create assumption registry with busting schedule

Next Busting Cycle Recommendations:
- Schedule: Monthly for critical assumptions
- Focus: New features and changed assumptions
- Method: Rotate between technical, business, process assumptions
- Participants: Include external perspectives for fresh eyes

Philosophical Notes:
- The assumptions that hurt most are those we don't know we're making
- A busted assumption is a gift - it reveals a hidden risk
- The goal isn't to prove assumptions wrong, but to find where they fail
- The most dangerous assumption is "our assumptions are mostly correct"
- Assumption busting creates antifragility - systems that improve when stressed

注意事項

• 前提破壊は意図的に積極的で、物事を壊そうとします
• 徹底的な検証と、実務上の制約とのバランスを取ります
• 破られた前提と、テストに耐えた前提の両方を記録します
• 検証結果を使ってシステムを改善し、単に批判するだけにとどめません
• その価値は、未知の未知を発見することにあります
• 維持すべき前提もあります（ただし、その限界は把握できます）
• 前提破壊によって、システムの境界や障害モードについての知見が得られます
• 組織的な学習を促すため、検証結果を透明性をもって共有します
• 定期的に前提を破壊して検証することで、誤った思い込みの蓄積を防ぎます
• 最も効果的な検証は、異なる視点を持つ外部の人からもたらされることがよくあります