開発原則の失敗パターンとは？やりすぎが招く落とし穴とその回避法

「良い設計をしたい」と思うすべての開発者にとって、DRY、KISS、SOLIDといった設計原則は心強い指針になります。

しかし、どんなに優れた原則であっても、やりすぎれば逆効果です。

本記事では、実際に現場で見られる「原則の過剰適用による失敗例」と、原則をバランスよく使いこなすためのヒントを紹介します。

---

原則が“毒”になる瞬間とは？

設計原則はあくまでガイドラインです。

それを“ルール”や“正義”のように扱うことで、かえって設計が歪んでしまうことがあります。

以下に代表的な「やりすぎパターン」を紹介します。

---

DRYのやりすぎ：過剰な抽象化地獄

よくある失敗

• 無理やり共通化してしまい、実装の意図が読めなくなる

• type

  や

  if

  が乱立し、修正時の影響範囲が読めない
• 一箇所の変更が他にも波及し、安心して触れないコードになる

例

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

対策

• *「繰り返し回数が3回以上」**などの基準で共通化の判断をする
• 読む人が直感的に理解できることを優先する

---

KISSのやりすぎ：重複を恐れず書きすぎる

よくある失敗

• 似たような処理が複数あり、修正が面倒に
• コピペ中心になり、コードの整合性が保てない
• KISSを言い訳にして「設計しない」選択をしてしまう

対策

• 最初はシンプルでも、3回以上似たコードが出てきたら見直す
• KISSは“簡単に”ではなく“単純にしてわかりやすく”という意味だと意識する

---

SOLIDのやりすぎ：設計が先行しすぎる

よくある失敗

• 単一責任を意識しすぎて、1つの処理に5クラス使う
• 「とりあえずインターフェースを切る」が目的化する
• 実装が伴っていないのに層だけが増えていく

対策

• 小規模・中規模プロジェクトではSOLIDを“全部守る”必要はない
• 必要に応じて徐々に適用する“漸進的設計”を意識する

---

原則の過剰適用が生まれる理由

• 原則を「正解」だと思い込む
• 書籍や講座を鵜呑みにし、現場への適用を考慮しない
• “守った方がかっこいい”という思考の誘惑

---

原則は「守るもの」ではなく「使いこなすもの」

設計原則はあくまで設計判断を助けるための視点です。

• 状況に応じて“あえて守らない”判断も必要
• チームのスキルレベルや開発フェーズによっても適用の仕方は変わる
• 原則同士が矛盾する場合もある（DRY vs KISS など）

---

バランス感覚を育てるためにできること

• 1つの原則に固執せず、複数の視点で設計を見る習慣をつける
• 「なぜその原則を適用したか？」を言語化して説明できるようにする
• 定期的に過去のコードを振り返ることで、設計判断をアップデートする

---

まとめ：原則は“答え”ではなく“問いのヒント”

設計原則は、私たちに「このコードは読みやすいか？」「今後の変更に強いか？」と問いかけるための道具です。

大切なのは、「原則を守ったかどうか」ではなく、「それが設計として良かったかどうか」です。

失敗を通して原則の意味を理解し、バランス感覚を育てることが、優れた設計者への第一歩です。