設計原則チートシート（KISS／DRY／YAGNI／OCP）
良いコードの3条件（読みやすさ／変更容易性／正しさ）を満たすための実務判断ガイド。印刷してお使いください。
要約
- KISS：まずは最小構造。仕様が曖昧な時は直書きで出荷し、観測する。
- DRY：重複を避ける対象はコード行数ではなく知識（ルール・仕様）。同じ知識が2回出たら一元化を検討。
- YAGNI：必要の根拠（仕様／実測／顧客確約）が来るまで先回り実装はしない。
- OCP：同種変更が繰り返されるなら拡張点を設け、既存を修正せずに機能追加できるようにする。
トレードオフ早見表
| 原則 | 目的 | 適用する時（合図） | 適用しない時（見送り基準） | よくある落とし穴 | 迷った時の一手 |
|---|---|---|---|---|---|
| KISS | 構造を最小に保つ | 仕様が曖昧／パターンが1〜2種 | 同種の変更が繰り返し入る | 早すぎる抽象化で複雑化 | まず直書き→実データで様子を見る |
| DRY | 知識の一元化 | 同じルール・仕様が2回以上出た | 用途ズレ／似て非なるケースが混在 | コピペ削減＝善の誤解（湿ったDRY） | 似ているだけなら重複容認、共通化は後回し |
| YAGNI | 先回り実装を抑止 | 「必要」の根拠が仕様／実測／顧客確約 | 「あると便利」「たぶん使う」レベル | 設定や拡張点を先に作る | TODO化＋観測（使用率）で判断 |
| OCP | 拡張に開き修正に閉じる | 同種の拡張が2回以上発生／今後も増える | 拡張頻度が低い／抽象維持コストが高い | 目的不明のインタフェース乱立 | 拡張点を1箇所だけ設け範囲を限定 |
メモ：DRYは“コード行数”ではなく知識を対象に。OCP導入は「同種変更×2」がシグナル。
意思決定フロー（簡易版）
- その機能は本当に必要？根拠＝仕様／実測／顧客確約。なければ YAGNI（実装しない）。
- 必要なら、まずKISSで最小実装（直書きでOK）。
- 同種の変更・拡張が繰り返されたら、DRY（知識の一元化）とOCP（拡張点の設計）を検討。
- 用途がズレるなら重複容認（湿ったDRYを避ける）。拡張点は最小限・1箇所に限定。
- 導入後は観測（使用率・変更頻度）で見直す。
※ Mermaid図を使う場合はWeb版ガイドに掲載し、PDFには本文フローを掲載するのが安定です。
レビュー用チェックリスト
KISS
- 仕様が曖昧な箇所は直書きで十分か？
- 命名・引数・分岐は最小か？
- 抽象が早すぎていないか？（複雑度↑）
DRY
- 同じ知識が2回以上現れていないか？
- “似て非なる”ケースを無理に共通化していないか？
- 重複容認のほうがメンテ容易では？
YAGNI
- 「必要」の根拠はあるか（仕様／実測／確約）？
- 死蔵※しそうな設定・拡張点を先に作っていないか？
- TODO化して観測に回せるか？
OCP
- 同種変更が繰り返されているか（×2が合図）？
- 拡張点は1箇所に限定できているか？
- 抽象維持コストが便益を上回っていないか？
※ 死蔵…物事を活用しないで、ただしまい込んでおくこと。
アンチパターンと対処
| アンチパターン | 兆候 | 対処 |
|---|---|---|
| 湿ったDRY（過剰共通化） | 用途ズレで条件だらけ | 重複容認にロールバック／用途が収束してから共通化 |
| 早すぎる抽象化（KISS違反） | 将来予測でIF乱立 | 具体化して出荷→パターン出現を待って設計 |
| YAGNI違反（先回り実装） | 設定・フラグが死蔵 | TODO化＋実測で削除／着手判断 |
| OCP過適用 | 抽象だらけで追えない | 拡張実績のない箇所は閉じる／拡張点は最小に限定 |
