DRYとKISSは矛盾する？設計原則を使いこなすためのバランス感覚とは

ソフトウェア設計において、「良いコード」とは何かを考える際にしばしば登場するのが DRY（Don't Repeat Yourself） と KISS（Keep It Simple, Stupid） という2つの原則です。

どちらも保守性と可読性を高めるための重要な指針ですが、実際の開発現場では両立が難しい場面もしばしばあります。本記事では、この2つの原則の違いと、実践でバランスを取るための考え方を解説します。

---

DRY原則とは？

DRYは「同じことを繰り返すな」という原則です。

• 目的：重複コードを排除し、単一の情報源（Single Source of Truth）にする
• メリット：変更が一箇所で済み、整合性が保ちやすい
• 典型的な適用例：共通ロジックを関数やクラスに抽出する、共通定数を設定ファイルに切り出す など

---

KISS原則とは？

KISSは「とにかくシンプルに」という原則です。

• 目的：複雑な設計・実装を避け、理解しやすくする
• メリット：初見でも理解しやすく、ミスが起きにくい
• 典型的な適用例：過度な設計パターンや抽象化を避ける、ストレートな処理を心がける

---

なぜDRYとKISSは衝突するのか？

よくある衝突パターン

共通化のしすぎによる複雑化（DRYの過剰適用）

# 例：3つの似た関数を共通化しようとしたが…

def process_item(item, type):
    if type == "A":
        # 処理A
    elif type == "B":
        # 処理B
    elif type == "C":
        # 処理C

→ if文が肥大化し、コードの可読性が低下

逆に、KISSを重視して重複が発生するケース

# 似たような処理を3つに分けて書く

def process_A(item):
    # 処理A

def process_B(item):
    # 処理B

def process_C(item):
    # 処理C

→ 重複しているが、それぞれの責務が明確で読みやすい

---

バランス感覚を持って設計するコツ

1. 「抽象化の価値」を評価する

• 共通化によって実際に保守が楽になるか？
• 将来の変更頻度や拡張性に貢献するか？

→ 無理に1つにまとめるより、「目的の明確化」が重要

---

2. 「複雑さの移動」に注意する

共通化すると、その分だけ抽象度が上がります。

それがチーム全体にとって「扱いやすい抽象化」かどうかを常に意識しましょう。

---

3. 最初はKISS寄り、必要があればDRYへ

いきなり抽象化せず、まずはシンプルに書いておく。

同じようなコードが3回以上出てきたら、はじめてDRYを検討するのが現場での定石です。

---

まとめ：原則に従うのではなく、原則を使いこなす

• DRYとKISSはどちらも「正しい」
• しかし、目的や文脈が異なるため、盲目的に適用すると逆効果になることも
• 原則を道具として使いこなすためには、バランス感覚が必要

設計原則を学ぶことは「ルールを守る」ことではなく、設計の判断軸を持つことです。

最適解は常にコードとチームの状況にあります。

DRYとKISS、それぞれのメリット・リスクを理解しながら、場面に応じた設計判断を積み重ねていきましょう。