Context-Blind Change
A Failure Pattern of Context Erosion and Unverifiable Correctness
Summary
Context-Blind Change は、変更が継続的に行われているにもかかわらず、 その前提・判断理由・制約条件が共有されないまま失われていく Failure Pattern である。
本 Pattern では、変更を速く行うこと自体は否定されない。 むしろ、不確実性が高く変更頻度が求められる状況において、 前提を明文化しないまま進むことが最も合理的な選択となり、 その結果として「正しさ」を検証できなくなる構造を扱う。
Context
運用中のソフトウェアでは、 仕様変更、機能追加、リファクタリング、バグ修正など、 大小さまざまな変更が継続的に発生する。
多くの場合、個々の変更は局所的に合理的であり、 レビューやテストも通過している。 しかし、その変更が どの前提や制約に基づいて行われたか は、 コードやチケットから読み取れないことが多い。
この状態が続くと、 ソフトウェア全体としての振る舞いや制約条件を 誰も説明できなくなる。
Forces
この Pattern を生み出す主な力学は以下である。
-
変更速度への圧力
変更を止めること自体がリスクとみなされ、 前提の確認よりも実装を進める判断が優先されやすい。 -
前提の暗黙化
チーム内で共有されているつもりの理解が文書化されず、 判断理由がコードや差分の外側に留まる。 -
局所最適の連鎖
各変更は個別には正しく見えるため、 全体の整合性が失われていることに気づきにくい。 -
支援ツールの補完効果
AI や自動化ツールが変更作業を補助することで、 前提を明示しないままでも変更が成立してしまう。
Failure Mode
前提が共有されないため、 変更の正当性を事後に検証できなくなる。
その結果、以下のような壊れ方が同時に進行する。
-
「正」がコード断片へ拡散する
仕様やルールが実装の断片に埋め込まれ、 どれが基準なのか判断できなくなる。 -
状態遷移の理由が追跡できなくなる
なぜその状態に遷移するのかが特定できず、 表示と内部状態の不整合が検出されにくくなる。 -
変更理由が追跡できない
何を守るための変更だったのかが失われ、 後続の変更が推測に基づいて行われる。
Consequences（定着する影響）
-
変更の影響範囲を説明できず、判断が遅延する
（Part I: What Breaks — 責務が壊れる / 境界が壊れる） -
仕様確認がコードリーディングに置き換わる
（Part I: What Breaks — データが壊れる / 境界が壊れる） -
AI や新規メンバーが有効に支援できなくなる
前提や制約が明示されていないため、 判断補助としての利用が限定される。
（Part II: Why It Breaks — コンテクスト不足）
Countermeasures（向きを変える最小介入）
以下は解決策の一覧ではなく、 Failure Mode に対して最小限の介入で力学を変えるための対抗パターンである。
- 変更内容ではなく、 守ろうとしている前提や制約を先に言語化する
- すべてを文書化せず、 変更判断に必要な最小コンテクストを残す
- 変更が正しかったかどうかを、 後から検証できる形で残す
Resulting Context（新しい当たり前）
変更は依然として頻繁に発生し、 すべての判断が事前に確定することはない。
しかし、前提が可視化されることで、 変更の是非を事後に検証できるようになる。
その結果、変更は単なる差分ではなく、 学習可能な判断の履歴として扱われる。
See also
-
Specification-by-Absence
前提が明示されないまま変更が積み重なり、未定義が事実上の仕様として固定化される派生パターン。 -
Test-Passing Illusion
前提条件が共有されない環境で、限定的な成功が正しさの代理指標として扱われやすくなる構造。
Appendix: Conceptual References
- Requirements & Knowledge
判断に必要な前提知識が明示されないまま変更が進む構造の背景。 - Information Hiding & Boundaries
前提や制約がコード断片へ漏出する失敗構造の背景。 - Feedback, Measurement & Learning
前提不在の変更が学習や検証につながらない力学の背景。
Appendix: References
- Pamela Zave, Michael Jackson, Four Dark Corners of Requirements Engineering, 1997.
- David L. Parnas, On the Criteria To Be Used in Decomposing Systems into Modules, 1972.
- Barry W. Boehm, Software Engineering Economics, 1981.
- Gojko Adzic, Specification by Example: How Successful Teams Deliver the Right Software, 2011.