この記事で分かること
- SOLID原則を「全部適用」するとなぜ逆効果になるのか
- どの原則を、どんな場面で使うべきかの判断フローチャート
- 5つの原則それぞれの「使いどき」と「見送りどき」
- 実際のリファクタリングでS + Iだけを適用した実例
はじめに ― 全部適用して失敗した話
「コードが肥大化してきたので、SOLID原則に従ってリファクタリングしよう」
多くのエンジニアが一度は考えることです。しかし、ここに落とし穴があります。5つの原則を教科書通りにすべて適用した結果、コードがかえって複雑になってしまうというケースが少なくないのです。
ある中規模システムのリファクタリングで、クリーンアーキテクチャをフル適用しようとしたことがあります。ドメイン層・ユースケース層・インターフェース層・インフラ層を厳密に分けた結果、ファイル数が3〜4倍に膨れ上がり、もともと1ファイルに収まっていた見通しの悪さを解消するはずが、今度は 「どのファイルに何が書いてあるか分からない」 という別の見通しの悪さが生まれました。
これはSOLID原則に限らず、設計原則全般に言えることです。原則に従うこと自体が目的になってはいけません。
前提知識 ― SOLID原則30秒おさらい
SOLID原則とは、Robert C. Martinが2000年に提唱したオブジェクト指向設計の5つの原則です（頭字語はMichael Feathersの命名）。本の索引のように、「どこに何があるか」を整理するための指針と考えてください。
| 略称 | 原則名 | 一言でいうと |
|---|---|---|
| S | 単一責任原則（SRP） | 1つのクラス/ファイルには1つの責務だけ |
| O | 開放閉鎖原則（OCP） | 拡張に開き、修正に閉じる |
| L | リスコフ置換原則（LSP） | サブクラスは親クラスと差し替え可能に |
| I | インターフェース分離原則（ISP） | 使わないメソッドへの依存を避ける |
| D | 依存性逆転原則（DIP） | 具体ではなく抽象に依存する |
本題 ― 原則は「痛み」で選ぶ
ここからがこの記事の核心です。
SOLID原則は5つすべてを一度に適用するものではありません。「今、コードのどこが痛いのか」 を起点に、その痛みを解消する最小の原則だけを選びます。
これは「SOLID不要論」ではありません。原則自体は正しいのです。ただし、痛みのないところに薬を塗っても効果はなく、副作用だけが残るということです。
以下のフローチャートで、あなたのコードに今必要な原則を判断できます。
痛みがないなら、適用しないという判断も正解です。
各原則の「使いどき」と「見送りどき」
S（単一責任原則）― ファイルが肥大化したとき
使いどき: 1つのファイルやクラスが複数の理由で変更される状況です。例えば、API定義・ビジネスロジック・データアクセスが1ファイルに混在していて、1,000行を超えている場合。
見送りどき: ファイルが200行以下で、責務が自然にまとまっている場合。無理に分割すると、関連する処理を追うためにファイルを行き来する羽目になります。
# Before: 1ファイルに全部入り
# app.py に API定義 + ビジネスロジック + データ永続化が混在
# After: 責務ごとに分割
# routes/users.py - ユーザー関連API
# routes/orders.py - 注文関連API
# routes/products.py - 商品関連API
# services/order_service.py - 注文のビジネスロジック
O（開放閉鎖原則）― if文が増殖するとき
使いどき: 新しいタイプを追加するたびに既存コードにif/switchを追加している場合。通知機能でSlack/Email/Webhookが増えるたびに分岐が増えるような状況です。
見送りどき: 分岐が2〜3個で安定しており、今後増える見込みがない場合。たとえば本番環境と開発環境の切り替えだけなら、Strategyパターンは過剰です。
L（リスコフ置換原則）― 継承が壊れたとき
使いどき: 親クラスを子クラスに差し替えると予期しない動作やエラーが発生する場合。典型例として、Arrayを継承したReadOnlyListでpushメソッドが例外を投げるような状況があります。
見送りどき: そもそも継承をほとんど使っていない場合。最近のソフトウェア開発では「Composition over Inheritance（継承より合成）」が主流であり、継承を使わないなら意識する場面も少なくなります。
I（インターフェース分離原則）― 巨大クラスの一部しか使わないとき
使いどき: 巨大なインターフェースやクラスのうち、呼び出し側が一部の機能しか使っていない場合。DatabaseManagerがCRUD・バックアップ・マイグレーションを全部持っているなら、分離の候補です。
見送りどき: 1つのクラスの機能が凝集しており、利用側がほぼすべてのメソッドを使っている場合。無理に分割すると概念的に関連した操作が分断され、かえって理解しづらくなります。
D（依存性逆転原則）― テストが書けないとき
使いどき: テスト時にデータベースやAPIなどの外部依存を差し替えられない場合。DIを導入してモックを注入できるようにします。
見送りどき: 開発者が1人で、テストでのモック差し替えの必要性が低い場合。また、言語やフレームワークが柔軟なモック機構を持つ場合（例: Pythonのunittest.mock）は、DIコンテナまで導入しなくても十分テスタブルです。
実例 ― S + I だけで劇的改善
とある小規模システムのバックエンドを例に見てみましょう。
Before: 全部入りの状態
| ファイル | 行数 | 混在している責務 |
|---|---|---|
app.py |
約1,200行 | 全APIエンドポイント + ビジネスロジック + バッチ処理 |
app.js |
約2,000行 | UI・API通信・状態管理・レンダリング |
db.py |
約600行 | ユーザー・タスク・プロジェクト・通知・ログ管理 |
適用した原則と判断理由
- S（単一責任） → ファイルが肥大化している → 採用
- I（IF分離） → 巨大クラスに複数責務が混在 → 採用
- O（開放閉鎖） → プラグイン的拡張の予定がない → 見送り
- L（リスコフ置換） → 継承をほぼ使っていない → 見送り
- D（依存性逆転） → 開発者1人でDIの恩恵が薄い → 見送り
After: S + I だけ適用した結果
routes/
users.py # ユーザーAPI
tasks.py # タスクAPI
projects.py # プロジェクトAPI
reports.py # レポートAPI
stores/
user_store.py # ユーザー管理
task_store.py # タスク管理
project_store.py # プロジェクト管理
2つの原則を適用しただけで、各ファイルが200〜300行に収まり、「どこに何があるか」が一目で分かるようになりました。D/O/Lを無理に適用していたら、インターフェース定義・DIコンテナ・ファクトリーが追加され、ファイル数は今の3倍になっていたでしょう。
よくある落とし穴 ― 「おまじないプログラミング」に注意
教科書通りにフル適用するのは、実は経験が浅い段階でよく見られるパターンです。業界ではこれを 「Cargo Cult Programming（おまじないプログラミング）」 と呼ぶことがあります。リチャード・ファインマンの「Cargo Cult Science」に由来する言葉で、形式だけ真似て本質を理解していない状態を指します。
DHH（Ruby on Railsの作者）もSOLID原則への批判的な見解を示しています。特に「責任」や「変更理由」の定義が曖昧で、極端に適用すると凝集性（関連する処理がまとまっている状態）が失われると指摘しています。
大事なのはこの2つの問いです。
- 今、何が痛いのか？（例：ファイルが肥大化して見通しが悪い）
- その痛みを解消する最小の手段は何か？（例：責務ごとにファイルを分割する）
この2つに答えられれば、使う原則は自然に決まります。
まとめ
- SOLID原則は5つ全部をセットで適用する必要はない
- 痛みのないところに原則を適用しても、複雑さが増すだけ
- 「今何が痛いか」→「その痛みに効く原則はどれか」の順で考える
- 経験豊富なエンジニアほど、この「適材適所」を自然にやっている
- 迷ったら、この記事のフローチャートに立ち返ってみてください
原則は道具です。道具箱から全部出して使うのではなく、今の作業に必要なものだけを選んで使う。それがプロのリファクタリングです。