02. 複雑性の捉え方
目的
- 複雑性を「相互作用」として捉え、設計の焦点（制約/境界）を作る
- 局所最適ではなく、変更容易性に効く最小の手当を選べるようにする
得られる判断能力
- 変更が波及する「相互作用」を列挙し、複雑性の焦点を作れる
- 局所/大域の違いを踏まえて、設計の介入点（制約/境界）を選べる
- 抽象化や層分割が、複雑性を減らすか増やすかを説明できる
前提/用語
- 相互作用: ある変更が別の箇所に波及する関係（暗黙依存を含む）
- 局所/大域: 変更の影響範囲（モジュール内 vs システム全体）
- 制約としての設計: ルールを決め、逸脱を検知できる状態を作る
要点
- 複雑性は「コード量」ではなく「影響範囲×不確実性」で増幅する
- 設計は、相互作用の大きい箇所に限定して導入する（全体に抽象化を敷かない）
- 小規模では「見通しの良さ」と「学習コスト」のバランスが重要になる
相互作用の洗い出し手順（最小）
相互作用は「複雑そう」ではなく、変更シナリオ から機械的に列挙するとブレません。
- 変更シナリオを 3 つ書く（仕様変更、運用要件、外部I/Fの変更など）
- 波及先を列挙する（UI/API/DB/外部I/F/運用/テスト。漏れを防ぐため区分で見る）
- 観測点を決める（何を見れば合否が分かるか。画面、API、ログ、監査）
- 最小手当（制約/境界）を候補にする（重複実装の排除、契約の固定、失敗時の扱いの明文化など）
- 影響が大きい 1〜2 件を「設計の焦点」として扱う
この結果を、章 03 の S/D/V 採点と、章 05-06 のテスト配分へ接続します。
成果物として残す場合:
- 相互作用マップ（任意）: Appendix B: テンプレ集（B-9）
- 記入例: Appendix D: 記入例（D-17）
例（ランニング例）
タスク管理で相互作用が出やすい典型例です。
- 期限ルール変更: UI 表示、API バリデーション、通知条件、検索/並び替えに波及
- 権限モデル変更: 画面表示、API 認可、監査ログ、テストデータの前提に波及
- 通知方式変更（メール→別チャネル）: 外部I/F、リトライ、運用監視、E2E の安定性に波及
通し例: 期限ルール変更（焦点化→S/D/V→テスト）
例: 「期限が近い（due_soon）」の閾値を 2日 から 3日 に変更する。
| 観点 | 内容 |
|---|---|
| 変更シナリオ | due_soon の判定閾値変更（期限表示・通知条件に影響） |
| 波及先（例） | UI 表示（バッジ/色）、API 出力（dueStatus）、通知条件、検索/並び替え、E2E の期待値 |
| 観測点（例） | UI の表示/並び、API の dueStatus、通知要求の記録、監査ログ |
| 最小手当（例） | 期限判定を domain に集約し、UI/API が重複実装しない（タイムゾーン解釈も固定する） |
| 接続 | 依存関係を章 03 で S/D/V 採点し、章 05-06 で単体/統合/E2E に配分する |
内部リンク:
演習（最小1個）
ランニング例で、変更シナリオを 3 つ作り、相互作用を整理してください。
例:
- 期限ルール変更 → 表示/UI、API、通知、検索/並び替えに波及
- 権限モデル変更 → 画面表示、API 認可、監査ログ、テストデータの前提に波及
追加（任意）:
- 3 つのうち 1 つを選び、最小手当（制約/境界）を 3 行で書く
- その手当を「単体/統合/E2E のどれで守るか」を 1 行で書く
よくある失敗
- 目に見える問題（実装の重複）だけを叩き、真の相互作用（制約不足）を放置する
- 「アーキテクチャ図」を作ることが目的化し、運用・テストの制約に接続しない
- グローバル状態（共有ストア、環境変数、暗黙設定）で相互作用を増やす
チェックリスト
- 変更シナリオ（仕様/運用/外部I/F）を 3 つ列挙できる
- 変更が波及する箇所（UI/API/DB/運用）を具体的に列挙できる
- 相互作用を減らすための「制約」を言語化できる
- 影響範囲の大きい領域に、テスト投資を寄せる方針がある