Specification-by-Absence
A Derived Failure Pattern of Implicit Rules and Unverifiable Expectations
Summary
Specification-by-Absence は、明示された仕様が存在しない状態において、 「何も書かれていないこと」自体が事実上の仕様として扱われる Failure Pattern である。
本 Pattern が扱うのは、仕様を十分に書いていないという問題ではない。 不確実性や変更圧力の中で仕様の明文化が後回しにされ、 その空白が暗黙の期待や慣習によって埋められていく構造である。
Context
運用中のソフトウェアでは、 すべての仕様を事前に定義することは現実的ではない。
特に既存機能の振る舞いや例外的なケースについては、 「これまでこう動いていた」という事実が、 明文化された仕様の代替として扱われやすい。
このような状況では、 仕様は明示されていないにもかかわらず、 期待だけが固定化されていく。
Forces
この Pattern を生み出す主な力学は以下である。
-
仕様記述コストの高さ
正確な仕様を書くには時間と合意が必要であり、 変更が頻発する環境では後回しにされやすい。 -
既存挙動への依存
動いているコードが事実上の仕様として参照され、 振る舞いの意図が言語化されない。 -
確認コストの非対称性
仕様を明示するコストに比べ、 暗黙の期待を前提に進める方が短期的には安く見える。 -
変更の局所化
影響範囲を限定した変更が積み重なり、 全体としての仕様像が共有されなくなる。
Failure Mode
仕様が明示されないため、 期待と実装の差異を事後に検証できなくなる。
その結果、以下のような壊れ方が同時に進行する。
-
期待がコードレビュー後に現れる
実装後になって初めて「想定と違う」と指摘される。 -
仕様確認が過去の挙動参照に置き換わる
正しさの根拠が履歴や記憶に依存する。 -
変更が仕様の根拠として扱われる
たまたま入った実装が、 後続の仕様判断の参照点として固定化される。
Consequences（定着する影響）
-
判断基準が共有されず、議論が感覚論に流れる
（Part II: Why It Breaks — コンテクスト不足） -
新規メンバーや AI が正しさを推測するしかなくなる
前提や制約が明示されていないため、 判断補助としての利用が限定される。
（Part II: Why It Breaks — コンテクスト不足n）
Countermeasures（向きを変える最小介入）
以下は解決策の一覧ではなく、 Failure Mode に対して最小限の介入で力学を変えるための対抗パターンである。
- 「何を決めていないか」を明示的に扱う
- 挙動の事実と期待を区別して言語化する
- すべてを書こうとせず、 判断に必要な最小仕様を残す
Resulting Context（新しい当たり前）
仕様は依然として不完全であり、 すべてが明文化されることはない。
しかし、未定義である部分が可視化されることで、 期待と実装のズレが早期に扱えるようになる。
その結果、仕様は固定された成果物ではなく、 判断を支える参照点として機能する。
See also
-
Context-Blind Change
変更時に前提が共有されないことで、仕様不在が構造として固定化される基底パターン。 -
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.
- Barry W. Boehm, Software Engineering Economics, 1981.
- Gojko Adzic, Specification by Example: How Successful Teams Deliver the Right Software, 2011.