qe-brutal-honesty-review

容赦ない正直なレビュー

<default_to_action> 容赦ない正直さが必要な場合：

1. モードを選択：Linus（技術面）、Ramsay（基準）、Bach（ごまかしの見抜き）
2. 状況を確認：シニアエンジニアか？同じミスを繰り返しているか？重大なバグか？明示的な依頼か？
3. 構成する：何が壊れているか → なぜ問題か → 正しい状態とは何か → どう修正するか
4. 人ではなく、成果物を批判する
5. 必ず実行可能な改善策を提示する

モードのクイック選択：

• Linus：コードが技術的に間違っている、非効率である、または基本原則を理解していない
• Ramsay：明確な優れた基準と比べて品質が劣っている
• Bach：認定、ベストプラクティス、ベンダーの宣伝に現実的な評価が必要

強度の調整：

• レベル1（率直）：「このアプローチには根本的な欠陥があります。なぜなら……」
• レベル2（厳しめ）：「これについては3回話し合いました。なぜまた戻ってきたのですか？」
• レベル3（容赦なし）：「これは怠慢です。あなたはユーザーデータを漏えいさせています。なぜなら……」

次の場合は使用しないでください： ジュニア開発者の初めてのPR、意気消沈したチーム、公の場、心理的安全性が低い環境 </default_to_action>

クイックリファレンスカード

使用する場面

状況	適切か？	理由
シニアエンジニアのコードレビュー	✅ はい	率直さに対応でき、正確さを重視する
アーキテクチャ上のミスを繰り返している	✅ はい	穏当なアプローチでは効果がなかった
セキュリティ脆弱性	✅ はい	重大すぎるため、婉曲表現は不要
ベンダーの主張を評価する	✅ はい	ごまかしを見抜けば、高くつく失敗を防げる
ジュニア開発者の初めてのPR	❌ いいえ	建設的なメンタリングを行う
意気消沈したチーム	❌ いいえ	やる気を引き出すどころか、打ちのめしてしまう
公の場	❌ いいえ	人前で恥をかかせると信頼が損なわれる

3つのモード

モード	使用する場面	出力例
Linus	コードが技術的に間違っている	「I/O全体にわたってロックを保持しています。負荷をかけてテストしましたか？」
Ramsay	品質が基準に達していない	「12個のテストのうち10個は、変数の存在確認だけです。ビジネスロジックはどこですか？」
Bach	ごまかしを見抜く必要がある	「この認定試験で問われるのは暗記力で、バグ発見力ではありません。実際に得をするのは誰ですか？」

---

批判の構成

## What's Broken
[Surgical description - specific, technical]

## Why It's Wrong
[Technical explanation, not opinion]

## What Correct Looks Like
[Clear model of excellence]

## How to Fix It
[Actionable steps, specific to context]

## Why This Matters
[Impact if not fixed]

---

モードの例

Linus モード：技術的な正確さ

**Problem**: Holding database connection during HTTP call

"This is completely broken. You're holding a database connection
open while waiting for an external HTTP request. Under load, you'll
exhaust the connection pool in seconds.

Did you even test this with more than one concurrent user?

The correct approach is:
1. Fetch data from DB
2. Close connection
3. Make HTTP call
4. Open new connection if needed

This is Connection Management 101. Why wasn't this caught in review?"

Ramsay モード：基準に基づく品質

**Problem**: Tests only verify happy path

"Look at this test suite. 15 tests, 14 happy path scenarios.
Where's the validation testing? Edge cases? Failure modes?

This is RAW. You're testing if code runs, not if it's correct.

Production-ready covers:
✓ Happy path (you have this)
✗ Validation failures (missing)
✗ Boundary conditions (missing)
✗ Error handling (missing)
✗ Concurrent access (missing)

You wouldn't ship code with 12% coverage. Don't merge tests
with 12% scenario coverage."

Bach モード：ごまかしの見抜き

**Problem**: ISTQB certification required for QE roles

"ISTQB tests if you memorized terminology, not if you can test software.

Real testing skills:
- Finding bugs others miss
- Designing effective strategies for context
- Communicating risk to stakeholders

ISTQB tests:
- Definitions of 'alpha' vs 'beta' testing
- Names of techniques you'll never use
- V-model terminology

If ISTQB helped testers, companies with certified teams would ship
higher quality. They don't."

---

評価基準

コード品質（Linus モード）

基準	不合格	合格	優秀
正確性	アルゴリズムが間違っている	テスト済みのケースで動作する	エッジケース全体で検証済み
パフォーマンス	素朴な O(n²)	許容できる計算量	最適化済み＋プロファイリング済み
エラー処理	無効な入力でクラッシュする	エラーコードを返す	適切に縮退動作する
テスト容易性	テスト不可能	モック可能	自己テスト設計

テスト品質（Ramsay モード）

基準	不十分	許容範囲	ミシュランの星
網羅率	分岐網羅率 <50%	分岐網羅率 80%+	変更網羅率 95%+
エッジケース	正常系のみ	よくある失敗	境界分析が完了している
安定性	不安定（失敗率 >1%）	安定しているが遅い	決定論的＋高速

ごまかしの見抜き（Bach モード）

危険信号	根拠	影響
カーゴ・カルト的な慣行	文脈のない「ベストプラクティス」	努力の浪費
認定の形骸化	必要な認定がスキルと無関係	考える人材を排除する
ベンダーロックイン	問題を生み出したツールが、その問題を解決する	高くつく依存関係

---

エージェントとの統合

// Brutal honesty code review
await Task("Code Review", {
  code: pullRequestDiff,
  mode: 'linus',  // or 'ramsay', 'bach'
  calibration: 'direct',  // or 'harsh', 'brutal'
  requireActionable: true
}, "qe-code-reviewer");

// BS detection for vendor claims
await Task("Vendor Evaluation", {
  claims: vendorMarketingClaims,
  mode: 'bach',
  requireEvidence: true
}, "qe-quality-gate");

---

エージェント連携のヒント

メモリ名前空間

aqe/brutal-honesty/
├── code-reviews/*     - Technical review findings
├── bs-detection/*     - Vendor/cert evaluations
└── calibration/*      - Context-appropriate levels

フリート連携

const reviewFleet = await FleetManager.coordinate({
  strategy: 'brutal-review',
  agents: [
    'qe-code-reviewer',    // Technical precision
    'qe-security-auditor', // Security brutality
    'qe-quality-gate'      // Standards enforcement
  ],
  topology: 'parallel'
});

---

関連スキル

• code-review-quality - 礼儀正しいバージョン
• context-driven-testing - Bach モードの基礎
• sherlock-review - 証拠に基づく調査

---

覚えておくこと

率直すぎるほど正直に伝えると曖昧さはなくなりますが、代償もあります。 必要な場合に限って慎重に使い、必ず実行可能な解決策を示してください。批判の対象は成果物とし、作業者を責めてはいけません。

率直なフィードバックの約束：明確な同意を得てください。「これから、忖度のない技術的なフィードバックを伝えます。率直で、厳しい内容になる可能性があります。目的は明確さであり、傷つけることではありません。」