偶有的複雑性 / 本質的複雑性
ソフトウェアの複雑性を、問題そのものに内在する 本質的複雑性（essential complexity） と、道具・言語・歴史的経緯から生じる 偶有的複雑性（accidental complexity） に分ける考え方。Fred Brooks「No Silver Bullet」(1986) が出典。偶有的は除去できるが、本質的は除去できない、というのが核。
「偶有的」の意味（誤読注意）
accidental の訳。アリストテレスの 偶有性（付帯的性質）= 本質(essence)ではない、たまたまそうなっている性質 に由来する。「偶発的・事故的（=ランダムに起きる）」ではなく 「本質ではない／取り除いてもその物が物でなくなるわけではない」 の意。
Brooks の主張
過去の生産性向上（高級言語、タイムシェアリング、統合開発環境）は、ほぼ 偶有的複雑性を削ったもの。だが偶有的が十分小さくなった今、残るのは本質的複雑性であり、それを一撃で10倍にする「銀の弾丸（silver bullet）」は存在しない。
本質的複雑性の源として4性質を挙げる:
- Complexity（複雑性） — 要素数とその相互作用が本質的に多い
- Conformity（適合性） — 既存の人間の制度・他システムへ追従させられる（恣意的だが従うしかない）
- Changeability（可変性） — 使われる限り変更要求が続く
- Invisibility（不可視性） — 構造が空間的に図示しにくい
区別の例
| 偶有的複雑性（消せる） | 本質的複雑性（消せない） | |
|---|---|---|
| 出どころ | 道具・言語・表現・歴史的経緯 | 問題ドメインそのもの |
| 例 | 手動メモリ管理、ボイラープレート、設定地獄、貧弱な型表現、ビルドの煩雑さ | 税法・医療プロトコルの規則、並行/分散の本質的難しさ、要件間トレードオフ |
| 対処 | 抽象化・自動化・良い言語/ツールへの投資で削減 | モデル化・整理するだけ。消そうとすると別の場所へ移動する |
なぜ重要か — 努力配分の指針
エンジニアリングの労力をどこに割くかを決める。偶有的複雑性は 投資で削れる（より良い抽象・言語・自動化）。本質的複雑性は削れず、無理に隠すと別の層に滲み出る（複雑性保存の法則 / Tesler’s Law）。
- 「全部偶有だ」と思う → 銀の弾丸幻想（次の技術が全部解決してくれる）
- 「全部本質だ」と思う → 改善放棄（このコードは複雑で当然、と居直る）
- 実務の判断: 目の前の複雑さの何割が偶有かを見積もり、偶有を削り切ってから本質に向き合う
注意: 本質/偶有の線引きは 文脈依存で主観的。同じ複雑さが、視点を変えると偶有にも本質にも見える。
関連概念
- Out of the Tar Pit（Moseley & Marks, 2006）— 同じ二分を発展させ、偶有的複雑性の主因を 状態（mutable state）と制御フロー に特定。関数型・宣言的アプローチで削れと説いた
- Simple vs Easy — Rich Hickey の simple（絡み合いが無い）追求は、偶有的複雑性の削減そのもの
- 銀の弾丸の不在は、要件定義・設計といった 本質に向かう活動の価値を裏づける
関連
- Simple vs Easy — simple の追求＝偶有的複雑性を削る営み
- The Rails Doctrine — 偶有的複雑性をフレームワークの規約で肩代わりする立場
- Convention over Configuration — 設定という偶有的複雑性を規約で消すパターン
- 関数型言語 — 状態を抑え偶有的複雑性を減らす処方箋（Out of the Tar Pit の主張）
Links
- Fred Brooks, “No Silver Bullet — Essence and Accident in Software Engineering” (1986)
- Ben Moseley & Peter Marks, “Out of the Tar Pit” (2006)