---
note: 複雑性とは規模ではなく、結果が事後にしか分からないこと。設計が守る境界は煩雑系と複雑系の間にある
created: 2026-08-09T21:56:00+09:00
---

# 複雑と煩雑は違う

「このシステムは複雑だ」と言われることがある。
だがこの一言は、少なくとも3つの異なる状態を指しうる。

1. 規模が大きく、全体の把握に時間がかかる
2. 詳しい人でないと手を出せない
3. 触ってみるまで、何が起きるか誰にも分からない

1と2の間には程度の差しかない。だが2と3の間には、**対処法が変わるほどの断絶**がある。
同じ「複雑」という語で呼んでいるかぎり、その断絶は見えない。

この文書は、その断絶がどこにあるかを特定し、
**設計が守るべき境界はそこである**と述べることを目的とする。

領域の呼び名と定義は「クネビンフレームワーク」に依る。本文書はそれを前提とする。

なお、クネビンをソフトウェアの結合の議論に接続したのは
Vlad Khononov『ソフトウェア設計の結合バランス』（原題 *Balancing Coupling in Software Design*）である。
以下の複雑性の定義と結合の三次元は同書に依り、
**4層モデルおよび文書との接続は本ハンドブックの解釈である**。

## 複雑性とは、結果をいつ知れるかである

同書は結合の本題に入る前に、まず「複雑性」という語を確定させる。
システムに変更を加えようとするとき、次のどれにあたるかを問う。

| 変更の結果を | 領域 |
|---|---|
| 正確に言える | 明確系。これは複雑ではない |
| 自分は言えないが、詳しい人に聞けば分かる | 煩雑系。これも複雑ではない |
| **変更して観察するしか、知る方法がない** | **複雑系。これが複雑性である** |

つまり複雑性とは量ではない。
**原因と結果の関係が、事後にしか特定できないこと**である。

この定義が効くのは、**規模と複雑性を切り離せる**からである。

- モジュールが100個あっても、変更の影響範囲を事前に列挙できるなら、それは複雑ではない。煩雑なだけである
- モジュールが5個でも、1つ触ると何が壊れるか分からないなら、それは複雑である

行数もクラス数も依存グラフの辺の数も、複雑性の指標ではない。
**指標になるのは、変更の前に影響範囲を言えるかどうかだけ**である。

冒頭の3つの状態のうち、1と2が煩雑系、3が複雑系にあたる。
断絶はそこにあった。

## 結合がこの境界を動かす

同書の骨子は、結合を**共有知識**として捉える点にある。

2つのモジュールが結合しているとは、何らかの知識を共有しているということである。
共有された知識が変われば、共有している側すべてに変更が波及する。これが**カスケード変更**である。

ここが境界と接続する。

- 波及先を事前に列挙できるうちは、**煩雑系**にとどまる
- 列挙できなくなった瞬間、そのシステムは**複雑系**へ落ちている

したがって結合そのものは悪ではない。モジュールが協働する以上、結合はなくせない。
問題になるのは、**境界を越えさせる結合だけ**である。

同書はこの判定のために、結合を3つの次元で測る。

| 次元 | 問い |
|---|---|
| 強度 | どれだけの知識を共有しているか |
| 距離 | 共有している相手はどれだけ遠いか |
| 変動性 | その知識はどれだけ変わるか |

強く結びついていても、近くにあり、かつ変わらないものなら害は小さい。
弱い結合でも、遠く、頻繁に変わるものに繋がっていれば害は大きい。
**結合を減らすのではなく釣り合わせる**という主張は、この3次元から出てくる。

## 目指す先は明確系ではない

ここが最も誤読されやすい。
クネビンが出てくると「複雑系 → 煩雑系 → 明確系と登っていくのが設計の目標」と読みたくなるが、そうではない。

**クネビンは梯子ではない。**
5領域は状況の種類の分類であり、上下関係はない。
むしろ明確系は混沌系と崖で隣接しており、安全地帯ですらない（「クネビンフレームワーク」参照）。

**意味のあるソフトウェアは明確系に入らない。**
明確系は「誰にでも自明で、前例どおりにすれば済む」領域である。
そこに完全に収まるものは、自分で作る理由が薄い。既製品を買えば済む。
価値のあるシステムは、解こうとしている業務の難しさを必ず引き受ける。これは設計では消せない。

**実際の境界は、煩雑系と複雑系の間にある。**

| | 明確系 | 煩雑系 | 複雑系 |
|---|---|---|---|
| 変更の影響 | 見れば分かる | **調べれば分かる** | やってみないと分からない |
| 必要なもの | なし | 時間と知識 | 実験と観測 |
| 設計上の扱い | 目指さない | **ここに留まる** | 落ちたら引き戻す |

煩雑系で十分である。
設計者が全体を頭に入れている必要はないし、入る規模でもない。
**「調べれば分かる」が成立しているかぎり、モジュール化は機能している。**

設計の目標は明確系への昇格ではなく、**複雑系への転落を防ぐこと**、
落ちたものを**煩雑系へ引き戻すこと**である。

## 煩雑系を保つのは設計だけの仕事ではない

ここからは本ハンドブックの立場である。

煩雑系の定義は「調べれば分かる」だった。
では、この「調べれば分かる」を成立させているものは何か。2つある。

1. **構造** — 影響がどこまで届くかを追跡できること
2. **判断の記録** — 追跡した先を、変えてよいかが分かること

構造だけでは足りない。

`LIMIT 20` を参照している箇所をすべて列挙できたとする。構造の側は健全である。
だがその `20` が業務上の判断なのか、性能上の妥協なのか、誰かの既定値がそのまま残っただけなのかが分からなければ、
**変えてよいかは分からない**。
「コードから何が読めるか」で述べたとおり、コードに残るのは判断の結果であって、判断そのものではない。

| 症状 | 失われたもの | 直す場所 |
|---|---|---|
| 影響範囲を追えない | 構造 | 結合の設計 |
| 影響範囲は追えるが、変えてよいか分からない | 判断の記録 | 文書 |

両方が失われたとき、変更は「やってみて観察する」以外の方法を持たなくなる。
それが複雑系である。

したがって次が言える。

**文書が失われることは、システムを煩雑系から複雑系へ落とす。**

これは比喩ではなく、煩雑系の定義そのものからの帰結である。
煩雑系とは「詳しい人に聞けば分かる」状態であり、
その詳しい人が退職したあと、**その席に座るのが文書**だからである。
席が空いたまま埋まらなければ、定義上、そのシステムは煩雑系ではなくなる。

## 設計書に何が増えるか

この見方を採ると、設計書に書く項目がひとつ増える。
決定そのものに加えて、**その決定の影響がどこまで届くか**である。

- ✗「セッション情報を Redis に保持する」
- ✓「セッション情報を Redis に保持する。参照側は認証ミドルウェアに閉じる。ここを広げると Redis の可用性がシステム全体の可用性になる」

前者は決定を記録している。
後者は決定と、**その決定が引いた境界**を記録している。

後任が「調べれば分かる」状態に置かれるのは後者だけである。
前者しかない設計書は、`Redis` を使っているという事実は伝えるが、
参照箇所を増やしてよいかどうかについては何も言わない。
そして参照箇所が静かに増えたとき、影響範囲は誰にも列挙できなくなる。

境界の記述は、越境の検出にも効く。
「ここを広げると全体の可用性になる」と書いてあれば、
それを広げる変更は設計判断として扱われ、記録される。
書いていなければ、同じ変更が実装の都合として無言で通る。
これは「層の越境パターン集」で扱った上向きの越境そのものである。

## 実務での判定

領域の判定は主観に頼らない。次の順で問う。

1. **この変更の結果を、変更する前に言えるか**
   - 言える → 明確系。そのまま進めてよい
   - 言えない → 2へ
2. **言える人はいるか。調べれば分かるか**
   - いる／分かる → 煩雑系。**ここが正常な状態である**。分析して進める
   - いない／分からない → 3へ
3. **なぜ分からないのか**
   - 影響範囲が追えない → **構造の問題**。結合を見直す
   - 追えるが、変えてよいかが分からない → **記録の問題**。判断の出所を確認し、書き残す

3で「とりあえず動かして様子を見る」を選ぶこと自体は間違いではない。
複雑系ではそれが正しい進め方である。
問題は、**そこで得た知見を記録しないと、次の人も同じ実験からやり直す**ことである。
複雑系での実験は、記録して初めて煩雑系への引き戻しになる。

## まとめ

- 「複雑」は3つの状態を指しうる。規模・専門性・予測不能性。断絶は最後の1つとの間にある
- 複雑性とは量ではなく、**原因と結果の関係が事後にしか分からないこと**である
- 行数もモジュール数も指標ではない。指標は「変更の前に影響範囲を言えるか」だけである
- 結合とは共有知識であり、波及先を列挙できなくなった時点で境界を越えている
- **目指す先は明確系ではない**。明確系は目標ではなく、価値のあるシステムが入れない領域である
- 設計が守る境界は、**煩雑系と複雑系の間**にある。煩雑系で十分である
- 煩雑系を成立させているのは構造と判断の記録の2つ。**文書が失われると、構造が健全でも複雑系へ落ちる**
- 複雑系での実験は、記録して初めて煩雑系への引き戻しになる

本ハンドブックは繰り返し「この判断は誰が検証するのか」を問うてきた。
その問いに答えられる状態が、ここでいう煩雑系である。

検証者が特定でき、判断の記録が残っているかぎり、
システムはどれだけ大きくなっても煩雑にとどまる。
複雑になるのは、規模が閾値を超えたときではなく、**その問いに誰も答えられなくなったとき**である。