thinking-via-negativa

Via Negativa

追加する前に、削ることで改善します。まず害や無駄、不可欠ではない複雑さを取り除きます。削除候補をすべて検討した後も、実証された必要性が残る場合にのみ追加します。

使用する場面

• 問題を解決するために、機能、抽象化、依存関係、プロセス、制御を追加しようとしている場合。
• 複雑さがコストとなっているシステムやワークフローを簡素化する場合。
• 何を残し、構築し、保守しないかを決めて優先順位を付ける場合。
• パフォーマンスや信頼性の改善で、対策を追加するより問題のある経路をなくすほうが有効な場合。

使用しない場面

• 重要な制御：認証、検証、テスト、レート制限、再試行、安全性チェック。不要だと証明されるまでは必要だと考えてください。
• 削除や簡素化では満たせないことが実証されている要件がある場合。
• 使用されていない、または差し引きで害があるという証拠のない、美的なミニマリズム。
• 影響が不明で、ロールバック手段もない不可逆な削除。

手順

1. 追加したい衝動をいったん止めます。 目標と追加案を1行で示します。
2. まず削減できないか考えます。 同じ目標をより少ない範囲で達成するために、削除または停止できるものを列挙します。
3. 証拠に基づいて候補を整理します。 未使用、重複、コストが高く価値が低い、または有害な要素を優先します。好みではなく、使用状況、呼び出しグラフ、メトリクス、実験による証拠を求めます。
4. 不可逆性を確認します。 元に戻せるか、復元が難しいかを分類し、依存先を特定します。正体のわからない保護機能は、不要だと証明されていない限り削除しません。段階的な削除を計画するか、リスクが無視できない場合はその旨を示します。
5. 最も安全で価値の高い候補から削除します。 削減し、監視し、必要な動作が失われていないことを確認してから次の削除に進みます。
6. 目標がまだ達成できない場合にのみ追加します。 削減で要件を満たせない場合は、変更を最小限にし、削減では不十分だった理由を記録します。
7. 停止します。 削除によって目標を達成した場合、または残りの候補が不可逆性と証拠の基準を満たさず、最小限の追加が妥当な場合に停止します。

停止条件： 削除によって目標を達成した場合、または証拠に基づく削減に失敗した後も残る必要性が記録されている場合。

出力

Goal: <desired outcome>
Proposed add (if any): <thing>
Removal candidates: <element — evidence — risk — reversible?>
Action: remove <X> | staged remove <X> | add minimal <Y> because <why removal failed>
Verification plan: <how absence/success is checked>
Do-not-touch: <load-bearing items preserved>

検証

• 未使用または有害であるという証拠なしに何かを削除した場合、または安全性を担保する制御を「複雑さ」として削除した場合は、誤りと判断します。
• 同じ目標について、事前に削減を検討せずに追加をリリースした場合は、誤りと判断します。
• 過剰適用を防ぐための注意：要素が不可欠な役割を担っている場合や、その必要性が実証されている場合は、行数を減らすことや純粋性を理由に削除しないでください。