SeverityとBlockerを分ける

AIエージェントへ実装とレビューを任せると、問題を見つける速度が上がります。問題の発見速度が完成速度を上回ると、開発は別の形で止まります。

Netsujoでは、問題を見つけるたびに「正しさを高めること」を優先し、現在の完了単位を閉じる責任を後回しにした時期がありました。結果は単純でした。

発見
  ↓
修正
  ↓
再QC
  ↓
新しい発見
  ↓
再修正
  ↓
再QC ...

個々の指摘へ真面目に対応していました。システム全体では、完成を自分で遠ざけていました。

今回の根本原因は、ルール不足より運用判断の失敗にありました。FOLLOW_UPや並行PREPARATIONの考え方は既に設計していました。停止・続行を決める瞬間に、その設計を意思決定アルゴリズムとして使っていませんでした。

Incident Card

INCIDENT:
重要な指摘を見つけるたび、現在のPRと現在のDoDへ取り込んだ

SYMPTOM:
修正→再QC→新しい指摘→再修正が続き、完了条件が実質的に動き続けた

FALSE_ASSUMPTION:
P0 / P1 / Highなら、今回の作業を止めて今すぐ直すべきである

ROOT_CAUSE:
SeverityとCURRENT_BLOCKERを分離せず、FOLLOW_UPを実際の停止・続行判断へ強制していなかった

IMMEDIATE_FIX:
発見した瞬間に CURRENT_BLOCKER / FOLLOW_UP / IGNORE の三択へ分類する

SYSTEM_FIX:
Aレーンは固定DoDを閉じる。Bレーンは後続問題を先回りして調査・再現・修正準備する

REMAINING_RISK:
新しい証拠が現在DoDの未達や進行中事故を示した場合、FOLLOW_UPをCURRENT_BLOCKERへ昇格させる必要がある

1. SeverityとBlockerを同じものとして扱った

最初の失敗は、重大度ラベルを停止判断そのものとして使ったことです。

P0、P1、Highは、その問題が成立した場合の影響を分類するために使えます。CURRENT_BLOCKERは「今回の固定DoDを満たせないか」を判定します。二つは別の軸です。

ここで効く問いは「重大か」です。その次に、別の問いを置きます。

この問題は、今回の固定DoDを満たせなくするか。

Highだから停止、Lowだから通過、というショートカットを禁止しました。

2. QCを欠陥探索へ広げ、合格条件を動かした

独立QCの仕事は、固定された候補が固定された受入条件を満たすか判定することです。

ところが、レビューのたびに新しい脅威モデル、将来のhardening、周辺コードの改善余地まで拾い、その指摘を現在PRへ戻すと、レビューは探索工程へ変わります。探索には自然な終点がありません。

Acceptance QC
入力: 固定候補 + 固定DoD + 必須検査
出力: PASS / CURRENT_BLOCKER

Exploration / Hardening
入力: 広いコード・運用・将来リスク
出力: FOLLOW_UP候補 + 再現 + 修正準備

二つの仕事は両方必要です。同じ終了条件で回すと収束しません。

現在の完了判定では、重大な新事実が出たときだけ前提を再評価します。「もっと良くできる」はDoDを変更する理由にしません。

3. 設計済みのルールを、意思決定へ強制していなかった

今回の失敗で最も大きかったのはここです。

FOLLOW_UPも、並行PREPARATIONも、問題を後続へ分離する考え方も既にありました。設計文書へ書いた時点で安心し、実際の判断時には別の行動を取っていました。

ルールが存在する状態と、ルールが運用を拘束する状態は違います。

今はFindingが発生した時点で、必ず次の三択へ落とします。

FOLLOW_UPは「後で考える」というメモではありません。再判定条件と再昇格条件を持つ管理状態です。

4. 「安全側」を、広すぎる停止へ変換した

fail-closedは安全設計に必要です。停止scopeを誤ると、復旧経路と無関係な作業まで止まります。

たとえば認証経路Aに問題がある場合、必要な停止対象は認証経路Aへの危険な操作です。検証済みの別経路、非競合作業、承認済み修理まで一律に止める理由はありません。

問題があるdomain
  ├─ 危険な通常操作      → STOP
  ├─ 承認済み最小修理    → ALLOW
  └─ 証拠取得            → ALLOW

影響しないdomain          → CONTINUE

停止には4点を必ず持たせます。

• 何を止めるか
• 何を止めないか
• 何を確認すれば解除できるか
• 誰が解除判定を持つか

「全部止める」は安全判断の省略になり得ます。

5. 局所的な正しさを、全体throughputより優先した

一件の指摘へ正確に対応していても、全体最適になるとは限りません。

実際の失敗は、追加安全性を少し積むために、完成までの時間、再レビュー回数、認知負荷、統合コストを大きく増やしたことでした。

品質とthroughputは対立概念として扱いません。品質の受入条件を固定し、その条件を最短で満たす経路を設計します。

追うべき数字も変わります。

FOLLOW_UPを増やして完成だけ早めればよい、という設計でもありません。Reopen rateやB→A escalationが上がれば、分離判定が甘い可能性があります。

Aは終わらせる。Bは後から出る問題を減らす

現在は、仕事を二つの責任へ分けています。

Aレーン: Convergence

Aは現在の完了単位を閉じます。

固定DoD
  ↓
実装
  ↓
必須検証
  ↓
Finding triage
  ↓
CURRENT_BLOCKERだけ修正
  ↓
Acceptance
  ↓
COMPLETE

AのDoDは途中で簡単に増やしません。新しいFindingは三択へ分類します。

Bレーン: Preparation

Bは後続問題を先回りして減らします。

広い探索
  ↓
再現
  ↓
影響範囲の特定
  ↓
回避策
  ↓
限定修正案
  ↓
検証準備
  ↓
FOLLOW_UPとして待機

BがAへ割り込める条件も固定します。

1. 新しい証拠が現在DoDの未達を示した
2. 現在の操作に必須な安全条件が崩れた
3. 進行中の事故経路が確認された
4. 現在候補の前提が変わり、既存Evidenceを使えなくなった

P0/P1/Highというラベルだけでは割り込みません。

QCの出力を「修正指示」から「判定材料」へ戻す

レビューAIが返すべき情報を、次の形へ寄せています。

FINDING
severity: High
confidence: High
failure_path: ...
affected_scope: ...
relation_to_current_change: ...
relation_to_frozen_DoD: ...
workaround_available: true / false
recommended_class: CURRENT_BLOCKER / FOLLOW_UP / IGNORE
re_evaluate_when: ...

最終分類は統括側が行います。レビューAIがHighを付けた瞬間に全工程が停止する構造は作りません。

これでQCは「欠陥を何個見つけたか」を競う役割から、現在候補を受入可能か判断するための証拠提供へ戻ります。

Evidenceと未検証範囲

今回確認できた事実と、今後測る内容を分けます。

対策を書いたことを効果の証明には使いません。今後はTime to Accepted、Review loops、Reopen rateを継続して測ります。

運用時のチェックリスト

1. 今回のDoDは着手時に固定されているか
2. FindingのSeverityと、今回のDoDへの影響を別々に判定したか
3. Highというラベルだけで停止していないか
4. Lowというラベルだけで受入未達を許していないか
5. QCは固定候補と固定DoDに対する受入判定になっているか
6. 将来hardeningはFOLLOW_UPへ分離したか
7. FOLLOW_UPへ回避証拠・担当・再判定工程・再昇格条件があるか
8. 停止scopeは問題のあるdomainと操作に限定されているか
9. BからAへの割り込み条件を満たしているか
10. 完了速度と再オープン率を同時に測っているか

運用規則として残したこと

問題を見つける能力が高いほど、終了条件の設計が必要になります。

Netsujoで今回変えたのは、レビューの賢さそのものではありません。停止・続行の判断規則です。

Finding
  ↓
CURRENT_BLOCKER → 今回のDoDを閉じるために最小修正
FOLLOW_UP       → 重大度を保ったままBへ分離
IGNORE          → 今回の目的から外す

Aは終わらせる責任を持ちます。Bは後から出てくる問題を減らす責任を持ちます。

この二つを推奨事項として置かず、Findingが発生するたびに必ず通る判断手順へします。設計したルールは、運用を拘束して初めて機能します。