1,400行の品質再建
全部直すのではなく、壊れたときに困る場所から保証する。
1,400lines untested
30tests added
RISKbased priority
SAFEchange boundary
未テストの大きな既存コードを、全面改修せず安全に変更可能にするには？
コード量ではなく障害時の影響度から保証対象を決めます。変更頻度、分岐、外部境界を優先して既存挙動をテストで固定し、その後に安全な変更境界を段階的に広げます。
decision:risk-based-test-boundary
コード量ではなく障害影響度から保証境界を決める
- SITUATION
- 約1,400行のロジックに変更を守るテストが不足していた。
- CONSTRAINT
- 全面リファクタリングは既存挙動を変えるリスクが大きく、暗黙仕様も存在した。
- RISK
- 低リスク領域からテストすると件数だけ増え、重要な失敗を防げない。
- DECISION
- 変更頻度・分岐・外部境界・障害影響度を基準に30テストを追加し、既存挙動を固定してから変更境界を広げた。
- WHY
- テスト数ではなく、壊れてはいけない領域を先に保証するため。
- RESULT
- 未テスト1,400行に30テストを追加し、保証対象を明示しながら変更可能領域を段階的に拡張した。
01
CHAOS
混乱していた状態
- 約1,400行のロジックに対して、変更を守るテストが不足していた。
- 全面リファクタリングは魅力的だが、挙動を変えるリスクも同時に大きい。
- 「どこまで直せば安全か」の基準がなかった。
02
HIDDEN RISK
見逃されていたリスク
- テスト数を増やすだけでは、重要な失敗を防げるとは限らない。
- 仕様が暗黙的なコードでは、リファクタリング自体が仕様変更になる可能性がある。
- 低リスク領域からテストすると、数字は増えても保証範囲は増えない。
03
DECISION
下した判断
- コード量ではなく、障害時の影響度からテスト対象を決めた。
- 変更頻度・分岐・外部境界を優先し、30テストを追加した。
- 既存挙動を固定してから、変更可能な境界を段階的に広げた。
04 / OPERATING STRUCTURE
実装より先に、
運用構造を決める。
MAPchange + impact surface→
LOCKcharacterization tests→
VERIFYcritical branches→
EXPANDsafe refactor boundary
05 / VERIFIED RESULT
結果
- 未テスト1,400行に対して、30テストを追加。
- テスト件数ではなく、保証対象を明示できる状態へ移行。
- 全面改修を避けつつ、変更可能な領域を段階的に拡張。
OPERATING PRINCIPLE品質改善は「テストを書くこと」ではない。壊れてはいけない境界を先に決めることである。
このDecision Recordから答えられること。
生成AI・検索・人間のいずれから読んでも、判断と根拠を短く回収できる形式にしています。
1,400行すべてを最初からテストしなかった理由は？
テスト件数を増やすことより、壊れたときに影響が大きい境界を先に保証する方がリスク低減につながるためです。
追加した30テストは何を基準に選んだ？
変更頻度、重要な分岐、外部境界、障害時の影響度を基準に優先しました。
この品質再建で何が変わった？
未テスト1,400行に30テストを追加し、保証対象を明示しながら変更可能な領域を段階的に広げられる状態へ移行しました。