trust-but-verify

信頼しつつ検証する

すべてのシステム上の主張、テスト結果、前提について、盲目的に信頼するのではなく独立した検証を通じて懐疑的に確認し、誤った確信を防ぎ、問題の検出を早めます。

どのような場合に使うか

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

• テストは成功しているものの、まだ問題があるのではないかと疑っている
• ドキュメントに機能が動作すると書かれているが、実際に確かめたい
• システムのメモリー／ブレイン／進捗管理に、何かが実装済みだと記録されている
• 報告に基づいて、ステークホルダーが機能の存在を前提としている
• 重要な意思決定の前に、前提を検証する必要がある
• 誤検知や見落としに対するレジリエンスを高めたい
• 本番リリースやリスクの高い変更を準備している
• 品質を示す情報が不確かなシステムのオンボーディングを行っている

このスキルでできること

1. 主張の特定

• 次の情報から主張を抽出します：

  • テスト結果とカバレッジレポート
  • システムのドキュメントと仕様
  • 進捗管理とメモリーシステム
  • ステークホルダーの期待と前提
  • デプロイログと監視ダッシュボード
  • チーム内の連絡と状況報告

• 次の観点で主張を分類します：

  • 重要度（ミッションクリティカルか、あると望ましいか）
  • 検証可能性（テストしやすいか、曖昧か）
  • 情報源の信頼性（信頼できる情報源か、不明か）
  • 最終検証からの経過時間（最新か、古いか）

2. 検証戦略の設計

• 適切な検証方法を選択します：

  • 独立したテストの実行（元のテストとは異なる方法で）
  • システムの調査とヘルスチェック
  • ユーザーシナリオのシミュレーション
  • データの検証と整合性チェック
  • パフォーマンスのベンチマーク
  • セキュリティの侵入テスト
  • ドキュメントと実装の比較

• ほかの種類のテストと連携します：

  • ユニットテストを使いつつ、異なる方法で実行する
  • 異なるデータを使ってインテグレーションテストを実行する
  • エッジケースを含めて E2E テストを実行する
  • レジリエンスに関する主張を検証するため、カオステストを実施する
  • ユーザー体験に関する主張を検証するため、ユーザビリティテストを実施する

3. 懐疑的な検証の実行

• 意図的に前提に疑問を投げかけます：

  • テストが誤った対象をテストしているとしたら？
  • 誤った理由でテストが成功しているとしたら？
  • 機能は動作していても、ユーザーの期待どおりではないとしたら？
  • 今は動作していても、負荷がかかると動作しないとしたら？
  • ドキュメントと実装が食い違っているとしたら？

• 異なるコンテキストで検証を実行します：

  • 異なる環境（テスト環境だけではなく）
  • 異なるデータセット（テストデータだけではなく）
  • 異なるユーザーペルソナ（問題なく進む場合だけではなく）
  • 異なる期間（直後だけではなく）
  • 異なる障害条件（成功する場合だけではなく）

4. 不一致の検出と報告

• 主張と検証結果を比較します：

  • 誤検知を特定する（主張は正しいが、検証に失敗する）
  • 見逃しを特定する（主張は誤っているが、検証に成功する）
  • 食い違いの度合いを測定する（軽微な差異か、重大な差異か）
  • 検証の信頼度を追跡する

• 実行につながる洞察を提示します：

  • 見つかった具体的な食い違い
  • 根本原因に関する仮説
  • 影響の評価
  • 優先順位の提案
  • 検証方法の有効性

主張の種類に応じた検証戦略

「テストに合格した」という主張の場合：

• テストの品質を検証する：テストは実際に正しい対象をテストしていますか？
• テストカバレッジを確認する：テストは重要な経路やエッジケースを網羅していますか？
• テストデータを見直す：テストデータは現実的で、十分な範囲をカバーしていますか？
• 代替テストを実行する：類似しているものの異なる検証テストを実行します
• テスト環境を確認する：テスト環境は本番環境と一致していますか？

「機能を実装した」という主張の場合：

• 機能性を検証する：機能は説明どおりに実際に動作しますか？
• ユーザー体験を確認する：機能は使いやすく、直感的ですか？
• 統合を検証する：機能はほかのコンポーネントと連携して動作しますか？
• エッジケースをテストする：通常とは異なる状況に、機能はどのように対応しますか？
• ドキュメントを検証する：ドキュメントは実装と一致していますか？

「システム運用」に関する主張の場合：

• ヘルスチェック：システムは実際に稼働し、応答していますか？
• 負荷テスト：システムは想定される負荷に耐えられますか？
• 障害テスト：システムは障害にどのように対処しますか？
• 監視の検証：監視システムは実際に問題を検知していますか？
• バックアップの検証：バックアップから実際に復元できますか？

「メモリ／進捗」に関する主張の場合：

• 完了の確認：完了したとされている作業は、本当に完了していますか？
• 品質の確認：完了した作業は、本番環境で使える品質ですか？
• 依存関係の検証：依存関係は実際に存在し、機能していますか？
• 実装のレビュー：実装は設計に合致していますか？
• 成果物のテスト：成果物は実際に問題を解決していますか？

例

# Verify test results claims
npm run verify:test-results -- --test-suite "user-authentication"
npm run verify:test-coverage -- --module "payment-processing"

# Verify feature claims  
npm run verify:feature -- --feature "checkout-flow" --claim "handles 1000 concurrent users"
npm run verify:feature -- --feature "report-generation" --claim "exports to PDF format"

# Verify system operational claims
npm run verify:system-health -- --component "database" --claim "redundant and fault-tolerant"
npm run verify:system-performance -- --endpoint "/api/orders" --claim "response < 200ms"

# Verify progress/memory claims
npm run verify:progress -- --task "implement-payment-webhook" --claim "completed and tested"
npm run verify:documentation -- --section "api-reference" --claim "accurately describes endpoints"

# Comprehensive verification
npm run verify:all-claims           # Verify all identified claims
npm run verify:critical-claims      # Verify only critical claims
npm run verify:stale-claims         # Verify claims not recently checked

# Integration with other testing
npm run verify:with -- --test-type chaos --claim "system-resilient"
npm run verify:with -- --test-type security --claim "no-vulnerabilities"
npm run verify:with -- --test-type usability --claim "user-friendly"

出力形式

Trust But Verify Report
──────────────────────────────
Verification Context: Pre-production release validation
Total Claims Identified: 47
Claims Verified: 23 (priority order)
Verification Duration: 2 hours 15 minutes

Critical Claim Verification Results:

1. Claim: "Payment processing tests pass with 100% coverage"
   Source: CI/CD pipeline report
   Verification Strategy: Independent test execution + coverage analysis
   Result: ❌ DISCREPANCY FOUND
   - Tests pass but don't validate currency conversion rates
   - Coverage shows 100% but misses error handling paths
   - Test data uses only USD, missing other currencies
   Recommendation: Add currency conversion tests, expand test data

2. Claim: "System handles 5000 concurrent users"
   Source: Performance test report from 2 weeks ago
   Verification Strategy: Fresh load test with different patterns
   Result: ⚠️ PARTIALLY VERIFIED
   - System handles 5000 users but response time degrades by 300%
   - Database connection pool exhausted at 4500 users
   - CPU usage reaches 95% at target load
   Recommendation: Optimize database connections, add autoscaling

3. Claim: "User registration feature complete"
   Source: Project management system
   Verification Strategy: End-to-end testing + security review
   Result: ✅ VERIFIED
   - Registration flow works correctly
   - Email verification functional
   - Password security requirements enforced
   - No security vulnerabilities found

4. Claim: "Monitoring alerts configured for all critical errors"
   Source: DevOps runbook
   Verification Strategy: Error injection + alert monitoring
   Result: ❌ DISCREPANCY FOUND
   - Database connection errors not alerting
   - Payment gateway timeouts not monitored
   - Alert thresholds too high for business impact
   Recommendation: Review and update alert configuration

5. Claim: "Backup system tested and functional"
   Source: System documentation
   Verification Strategy: Actual backup restore test
   Result: ⚠️ PARTIALLY VERIFIED
   - Backup creation works
   - Restore process documented but untested
   - Restore time exceeds RTO (Recovery Time Objective)
   Recommendation: Test full restore, optimize restore process

Verification Confidence Assessment:
  - High Confidence: 8 claims (thoroughly verified)
  - Medium Confidence: 10 claims (partially verified)
  - Low Confidence: 5 claims (insufficient verification)
  - Failed Verification: 5 claims (discrepancies found)

Critical Issues Requiring Attention:
  1. Payment currency conversion untested (business risk: high)
  2. Database connection pool limits scalability (performance risk: high)
  3. Missing critical error alerts (operational risk: medium)
  4. Backup restore untested (recovery risk: medium)

Verification Effectiveness:
  - False positives prevented: 3 (would have caused production issues)
  - Assumptions challenged: 12 (revealed hidden risks)
  - Verification time vs value: High ROI (2 hours prevented days of issues)
  - Recommendations generated: 7 actionable improvements

Next Steps:
  1. Address critical discrepancies before release
  2. Improve test coverage for payment processing
  3. Optimize database connection management
  4. Update monitoring and alert configuration
  5. Schedule regular verification for high-risk claims

注意事項

• 「信頼しつつ検証する」は、単なる技術的なプロセスではなく、考え方です
• 検証にかける労力は、リスクと重要度に応じて調整してください
• 監査証跡のため、検証方法と結果を記録してください
• 検証で得られた知見を活用し、元のテストや主張を改善してください
• 検証は一度きりではなく、継続的なプロセスとして捉えてください
• 検証には異なる視点を取り入れてください（新たな視点からは違うことが見えてきます）
• 検証の有効性を継続的に測定してください
• 検証で得られた知見を関係者と透明性をもって共有してください
• 検証は、問題を見つけるだけでなく、システムへの理解を深めるためにも活用してください
• 学んだことに基づいて検証戦略を適宜調整してください
• 覚えておいてください。証拠がないことは、不在の証拠ではありません