SRPの教条主義から脱却せよ！単一責任の原則を愚直に守った結果として保守性が下がる罠と防ぎ方

ソフトウェア設計の世界で、単一責任の原則（SRP: Single Responsibility Principle）は長年にわたって重要な指針として扱われてきました。
しかし、その解釈を一歩間違えると「1つのクラスは1つのことしかしないべき」という表面的なルールになり、かえって保守性を損なうケースがあります。

特に経験の浅い段階では、責務を細かく分割すること自体が良い設計だと考えがちです。
その結果、わずかな処理しか持たないクラスが大量に生まれ、変更時には多くのファイルを横断して影響範囲を追跡しなければならなくなります。
設計をきれいにしたつもりが、コード全体の理解コストを押し上げるという逆転現象が起こるのです。

本来のSRPが示しているのは、単純な「処理を分割するルール」ではありません。
重要なのは、変更理由という観点で責務を整理することです。
同じ理由で変更される可能性が高い処理を無理に分離すると、関連する知識が分散し、結果として修正漏れや不整合を招きます。

この記事では、SRPを機械的に適用することで発生する設計上の罠を整理し、どのような基準で責務の境界を決めるべきかを解説します。
原則を守ること自体を目的にするのではなく、ソフトウェアの変更容易性を高めるために原則をどう使うべきか、具体的な考え方を掘り下げていきます。

優れた設計とは、ルールを一切破らない設計ではありません。
将来の変更に対して、開発者が安全かつ効率的に対応できる設計です。
SRPの本質を理解し、教条主義から脱却することが、長期的に保守しやすいコードを作るための第一歩になります。

SRP（単一責任の原則）を正しく理解するために知っておきたい本来の意味
1. 単一責任の原則とは何か？クラス設計で守るべき責務の考え方
2. SRPが目指すのは処理の分割ではなく変更理由の分離
SRPを愚直に守ることで発生する保守性低下の問題
1. クラスを分割しすぎることでコード理解のコストが増える理由
2. 責務分離のしすぎが引き起こす変更漏れと依存関係の増加
SRPの教条主義が失敗する典型的な設計パターン
1. 1メソッド1責務や1クラス1機能という誤った解釈
2. マイクロクラス化によって発生する設計上のデメリット
保守性を高めるためのSRP適用基準と判断方法
1. 変更の頻度と理由から責務の境界を決める
2. 関連するビジネスロジックを無理に分離しない設計判断
SRPと他のSOLID原則を組み合わせた実践的な設計方法
1. 開放閉原則や依存関係逆転の原則との関係
2. 実際の開発現場でSRPを柔軟に適用するポイント
SRP違反かどうかを判断するためのコードレビュー観点
1. 責務の変更理由が異なるかを確認する
2. 分割によるメリットと複雑化のデメリットを比較する
SRPを守ることより重要な保守しやすい設計の本質

SRP（単一責任の原則）を正しく理解するために知っておきたい本来の意味

ソフトウェア設計において、SRP（Single Responsibility Principle：単一責任の原則）は非常に有名な原則です。
しかし、実際の開発現場では、この原則が本来意図している内容とは異なる形で解釈されることがあります。

特に多い誤解は、「1つのクラスには1つの処理だけを書かなければならない」「クラスはできる限り小さく分割するべき」という考え方です。
このような理解でSRPを適用すると、確かに一見すると責務が整理されたように見えます。
しかし、過剰な分割によってコード全体の関連性が失われ、変更時に多くのファイルを修正する必要が発生することがあります。

本来のSRPは、コード量を減らしたり、クラス数を増やしたりするためのルールではありません。
ソフトウェアが将来的に変更されることを前提として、その変更に強い構造を作るための設計指針です。

例えば、ある機能に関連する処理が複数存在していても、それらが同じ理由で変更される可能性が高い場合、無理に分離する必要はありません。
むしろ、関連する知識を1つの場所に集約することで、変更時の影響範囲を限定できます。

SRPを正しく理解するには、「何を分割するか」ではなく、「何を同じ責務として扱うべきか」という視点が重要になります。
単純なルール適用ではなく、ソフトウェアの変化に対してどのような構造が適切なのかを考える必要があります。

単一責任の原則とは何か？クラス設計で守るべき責務の考え方

単一責任の原則とは、1つのクラスが1つの責任だけを持つべきだという考え方です。
ただし、ここでいう「責任」は単純な処理単位ではありません。
より正確には、「変更される理由の単位」として考える必要があります。

例えば、ユーザー情報を管理するクラスを考えてみます。
このクラスが以下のような処理を持っている場合を想定します。

ユーザー情報の取得
ユーザー情報の保存
ユーザー向けメール通知
管理画面向けの表示形式変換

これらをすべて「ユーザー関連の処理だから」という理由で1つのクラスにまとめると、短期的には分かりやすく感じるかもしれません。
しかし、実際にはそれぞれ異なる理由で変更される可能性があります。

データベース構造の変更、メール配信仕様の変更、画面表示要件の変更は、それぞれ別のタイミングで発生します。
この場合、1つのクラスが複数の変更理由を持っている状態となり、SRPに反する可能性があります。

一方で、関連性の低い処理を機械的に分離すればよいわけでもありません。
例えば、ある業務処理で必ず一緒に変更される検証処理と計算処理を別クラスに分けると、かえって業務ロジックの理解が難しくなる場合があります。

重要なのは、責務とは技術的な分類ではなく、変更の観点から判断するものだという点です。
データ処理、表示処理、通信処理といった技術的な役割だけで分割するのではなく、どのような要求変更に対応する単位なのかを考える必要があります。

SRPが目指すのは処理の分割ではなく変更理由の分離

SRPを理解する上で最も重要なポイントは、目的が「処理の分割」ではなく「変更理由の分離」であることです。

ソフトウェア開発では、コードは一度完成したら終わりではありません。
仕様変更、機能追加、バグ修正など、継続的な変更が発生します。
そのため、設計では現在の動作だけではなく、将来どのように変更される可能性があるかを考える必要があります。

例えば、注文処理を担当するクラスに、注文計算、請求処理、配送管理、通知処理がすべて含まれている場合を考えます。
この構造では、注文に関する機能が集約されているように見えますが、実際には異なる部門やルール変更によって修正される可能性があります。

このような場合は、変更理由ごとに責務を整理することで、変更の影響範囲を小さくできます。

ただし、変更理由の分離を意識するあまり、細かく分けすぎることにも注意が必要です。
クラス間の関係が複雑になれば、今度は変更箇所を探すためのコストが増加します。

優れた設計とは、最も多く分割された設計ではありません。
開発者がコードの意図を理解しやすく、変更時に安全な修正ができる設計です。

SRPは「必ずクラスを小さくする」という制約ではなく、「異なる理由で変更されるものを適切に分離する」という考え方です。
この本質を理解することで、形式的なルール遵守から脱却し、実際の保守性向上につながる設計判断ができるようになります。

SRPを愚直に守ることで発生する保守性低下の問題

SRP（単一責任の原則）は、適切に適用すればソフトウェアの変更容易性を高める強力な設計指針です。
しかし、原則を表面的なルールとして扱い、「責務は可能な限り細かく分割するべき」という考え方に陥ると、逆に保守性を低下させる原因になります。

ソフトウェア設計では、分割すること自体が目的になってはいけません。
重要なのは、変更が発生した際に、どれだけ少ない範囲で安全に修正できるかです。
クラス数やファイル数が少ないことが必ずしも良い設計ではありませんが、過剰な分割によって関連する処理が複数箇所へ散らばると、開発者は変更対象を把握するために多くの時間を費やすことになります。

例えば、ある注文処理機能を実装するとします。
この機能には、商品の検証、料金計算、割引適用、在庫確認、注文確定など複数の処理が含まれています。
SRPを過剰に意識すると、それぞれの処理を別々のクラスへ分割する設計になる場合があります。

もちろん、明確に異なる理由で変更される処理であれば分離する価値があります。
しかし、同じ業務ルールに基づいて変更される処理まで分離すると、1つの仕様変更に対応するために複数のクラスを修正しなければならなくなります。

この状態では、個々のクラスは小さく整理されているように見えても、システム全体としての理解は難しくなります。
設計品質を評価するときは、クラス単体の美しさだけではなく、開発者が機能全体を把握しやすい構造になっているかを見る必要があります。

SRPはコードを細分化するためのルールではなく、変更による影響を適切に制御するための考え方です。
原則を守ることだけに集中すると、本来の目的である保守性向上から離れてしまう可能性があります。

クラスを分割しすぎることでコード理解のコストが増える理由

クラスを細かく分割しすぎると、1つひとつのクラスの責務は小さくなります。
しかし、その代償として、システム全体の流れを理解するためのコストが増加します。

開発者が既存コードを読む場合、必要なのは個々のクラスの情報だけではありません。
「この処理はどこから呼ばれているのか」「関連するデータはどこで管理されているのか」「変更する場合に影響する範囲はどこまでか」といった関係性を把握する必要があります。

過剰に分割された設計では、1つの処理を追跡するために複数のファイルを移動することになります。
その結果、コードを読む時間が増え、単純な変更でも設計全体を理解するための負担が大きくなります。

例えば、以下のような状況では注意が必要です。

1つのビジネス処理を理解するために多数のクラスを確認する必要がある
クラス名だけでは役割や関係性が判断しにくい
単純な変更でも複数箇所の修正が必要になる
依存関係を追跡しなければ動作を理解できない

このような問題は、特にチーム開発で顕著になります。
コードを書いた本人にとっては整理された構造でも、他の開発者にとっては処理の流れを把握するための学習コストが高くなる場合があります。

良い設計とは、クラス数を最大限減らすことでも、最大限増やすことでもありません。
開発者が自然に理解できる適切な粒度を維持することが重要です。

責務分離のしすぎが引き起こす変更漏れと依存関係の増加

SRPを過剰に適用した場合、もう1つ大きな問題になるのが変更漏れです。
処理が複数のクラスに分散されると、仕様変更時に修正すべき場所を見落とすリスクが高まります。

例えば、料金計算に関するルール変更が発生した場合を考えます。
料金計算の責務を複数の小さなクラスに分割していると、一部の計算ロジックだけを修正してしまい、別の関連処理が古いルールのまま残る可能性があります。

これは、責務分離そのものが悪いという意味ではありません。
問題は、分離された責務同士の関係性が複雑になり、変更すべき範囲を把握しにくくなることです。

また、クラスを分割すると、それぞれのクラス間に依存関係が発生します。
依存関係が適切に管理されていれば問題ありませんが、過剰な分割では以下のような状態になりやすくなります。

1つのクラスが多数の小さなクラスに依存する
変更時に関連クラスをすべて確認する必要がある
呼び出し関係が複雑化して処理の流れが追いにくくなる
テスト対象が増えて修正コストが高くなる

ソフトウェア設計では、依存関係を完全になくすことはできません。
重要なのは、依存関係を管理しやすい形に保つことです。

SRPを適用するときは、「この処理は別クラスにするべきか」ではなく、「分離することで変更が本当に容易になるか」を判断基準にする必要があります。
責務分離は手段であり、目的はあくまで保守性の向上です。

原則を機械的に適用するのではなく、システムの規模や変更頻度、チームでの開発状況を踏まえて判断することが、長期的に安定したソフトウェア設計につながります。

SRPの教条主義が失敗する典型的な設計パターン

SRP（単一責任の原則）は、オブジェクト指向設計において非常に重要な考え方です。
しかし、原則の背景にある意図を理解せず、表面的なルールとして適用すると、設計品質を高めるどころか複雑性を増加させる結果になります。

特に問題になりやすいのが、「SRPを守るためには、あらゆる処理を細かく分割する必要がある」という考え方です。
このような設計思想では、クラスやメソッドのサイズだけを基準にして責務を判断してしまいます。
しかし、ソフトウェアの責務は単純なコード量や処理数で決まるものではありません。

例えば、ある業務機能を実装する際に、入力値の検証、データ加工、ビジネスルールの適用、結果の保存という複数の処理が存在するとします。
これらをすべて別々のクラスへ分割すれば、一見すると単一責任を満たしているように見えます。
しかし、実際には同じ業務変更によって同時に修正される可能性が高い処理である場合、分割によって変更コストが増えてしまいます。

設計において重要なのは、現在のコードがどれだけ分割されているかではありません。
将来的な変更に対して、開発者がどれだけ安全に対応できるかです。

SRPを教条的に適用した設計では、以下のような問題が発生しやすくなります。

処理の流れを追跡するために多くのファイルを確認する必要がある
関連するロジックが複数箇所に散らばる
小さな変更でも複数のクラスを修正する必要がある
クラス間の依存関係が複雑になる

これらはすべて、SRPが本来目指している「変更しやすい設計」とは逆方向の問題です。

優れた設計者は、原則を守ること自体を目的にしません。
なぜその原則が存在するのかを理解し、状況に応じて適切な粒度で適用します。
SRPの場合、その判断基準になるのは「何を分割するか」ではなく、「何が同じ理由で変更されるか」です。

1メソッド1責務や1クラス1機能という誤った解釈

SRPに関する代表的な誤解として、「1メソッド1責務」や「1クラス1機能」という考え方があります。
これらは設計上の目安として語られることがありますが、SRPそのものを表現したルールではありません。

例えば、1つのクラスに複数のメソッドが存在していても、それらが同じ目的のために変更されるのであれば、単一の責務として扱うことができます。

逆に、1つのメソッドしか持たない小さなクラスであっても、そのクラスが複数の変更理由に関係している場合は、適切な責務分離ができているとは言えません。

重要なのは、技術的な処理単位ではなく、ビジネス上またはシステム上の変更単位を見ることです。

例えば、ユーザー登録処理を考えた場合、入力データの検証とユーザー情報の生成処理が存在するとします。
これらは異なる処理ではありますが、ユーザー登録仕様の変更によって同時に修正される可能性があります。
この場合、必ず別クラスに分けるべきとは限りません。

一方で、メール通知処理や外部決済処理のように、異なるシステムや異なるルールによって変更される可能性があるものは、分離する価値があります。

つまり、SRPにおける責務とは「何をしているか」ではなく「なぜ変更されるか」によって判断します。

プログラミングでは、処理を小さく分解すること自体は簡単です。
しかし、意味のある境界を見つけることは難しい作業です。
設計力とは、単にコードを分割する能力ではなく、適切な境界を見極める能力だと言えます。

マイクロクラス化によって発生する設計上のデメリット

SRPを過剰に適用した結果として発生する代表的な問題が、マイクロクラス化です。
これは、1つのクラスが数行程度の処理しか持たず、大量の小さなクラスが存在する状態を指します。

マイクロクラス化された設計では、個々のクラスの役割は明確になります。
しかし、その一方でシステム全体の構造を理解する難易度が上昇します。

例えば、注文処理という1つの機能を確認したい場合に、注文検証クラス、価格計算クラス、割引判定クラス、税計算クラス、保存処理クラスなど、多数のクラスを順番に確認しなければならない状況が発生します。

このような設計では、コードの再利用性が高まる場合もありますが、多くのケースでは理解コストや依存関係の管理コストが増加します。

また、クラス数が増えるほど、以下のような問題も発生します。

どのクラスが処理の中心なのか分かりにくくなる
変更箇所の特定に時間がかかる
クラス間の結合を管理する必要が増える
テストコードの構成も複雑になる

特に大規模なシステムでは、コード量そのものよりも、開発者がシステムの構造を理解するための認知負荷が大きな問題になります。

もちろん、適切に分離されたクラスは保守性向上に役立ちます。
問題は、分離する基準が「小さくすること」になってしまうことです。

SRPを活用する際には、クラスの数ではなく、変更理由のまとまりを意識する必要があります。
関連する知識を適切な場所に集約し、変更時に必要な範囲だけを修正できる構造こそが、保守性の高い設計です。

保守性を高めるためのSRP適用基準と判断方法

SRP（単一責任の原則）を効果的に活用するためには、単純にクラスやメソッドを分割するのではなく、どこに責務の境界を置くべきかを判断する必要があります。
設計において最も難しいのは、コードを書くことではなく、将来的な変更を予測しながら適切な構造を決めることです。

SRPを適用する際の重要な視点は、「現在の処理内容」ではなく「将来発生する変更」です。
同じデータを扱っている処理でも、変更される理由が異なる場合は分離する価値があります。
一方で、異なる処理であっても、常に同じ理由で変更されるのであれば、無理に分ける必要はありません。

例えば、ECサイトの商品注文処理を考えた場合、商品の価格計算、割引ルールの適用、注文金額の算出などが存在します。
これらは技術的には別々の処理ですが、ビジネス上の「注文料金計算」という同じ責務に属する可能性があります。

逆に、注文完了後のメール通知や外部決済サービスとの連携処理は、異なるシステムや運用ルールによって変更される可能性があります。
その場合は、注文計算の責務から分離することで、変更の影響範囲を限定できます。

つまり、SRPの適用基準は「処理の種類」ではなく「変更の方向性」です。

設計判断を行う際には、以下のような問いを考えることが有効です。

このクラスは複数の異なる理由で変更される可能性があるか
変更要求が発生した場合、修正箇所は自然に1か所へ集約されているか
分割することで依存関係や処理の流れが複雑にならないか
分割後のクラス構造は、他の開発者が理解しやすいか

SRPは機械的に適用するものではありません。
ソフトウェアの規模、チーム構成、変更頻度などを考慮しながら、最適な境界を見つけることが重要です。

変更の頻度と理由から責務の境界を決める

責務の境界を判断する上で、最も重要な基準になるのが変更頻度と変更理由です。
同じタイミングで変更される処理は、同じ責務としてまとめたほうが保守しやすい場合があります。

例えば、給与計算システムを考えてみます。
基本給の計算、手当の加算、税金計算などが存在するとします。
この場合、税制変更によって税金計算だけが頻繁に変更されるのであれば、給与計算全体から税金関連の責務を分離する価値があります。

一方で、基本給と手当の計算が常に同じ制度変更によって更新されるのであれば、それらを別々のクラスへ分割してもメリットは限定的です。
むしろ関連するロジックが離れた場所に配置され、変更時の確認範囲が広がる可能性があります。

設計では、「変更される可能性があるか」だけではなく、「どのような理由で変更されるか」を見る必要があります。

例えば、以下のような観点で判断できます。

判断基準	分離を検討するケース	まとめるケース
変更理由	異なるルールや担当領域で変更される	同じ仕様変更で変更される
変更頻度	一方だけ頻繁に変更される	常に同時に変更される
利用範囲	独立して再利用される	常にセットで利用される
理解容易性	分離で構造が明確になる	分離で追跡が難しくなる

このような判断を積み重ねることで、適切な責務の境界を設定できます。

重要なのは、未来の変更を完全に予測しようとしないことです。
ソフトウェア開発では、すべての変更を事前に把握することは不可能です。
そのため、現在分かっている変更パターンやビジネスルールを基準に、合理的な設計を選択することが現実的なアプローチになります。

SRPと他のSOLID原則を組み合わせた実践的な設計方法

SRP（単一責任の原則）は、SOLID原則の中でも特に基本となる考え方です。
しかし、実際のソフトウェア設計では、SRPだけを単独で適用しても十分な効果を得られない場合があります。

ソフトウェアは複数の要素が関係しながら動作するため、責務の分離だけではなく、拡張性や依存関係の管理も考慮する必要があります。
そのため、SRPは他のSOLID原則と組み合わせることで、より実践的な設計指針になります。

例えば、クラスの責務を適切に分離したとしても、そのクラスが具体的な実装へ強く依存している場合、変更への耐性は十分ではありません。
また、変更のたびに既存コードを修正する必要がある設計では、保守性を高めることは難しくなります。

SRPが担当するのは主に「変更理由の整理」です。
一方で、他のSOLID原則は「変更に強い構造をどのように作るか」という別の観点を補います。

代表的には、以下のような関係があります。

原則	主な目的	SRPとの関係
単一責任の原則	変更理由を分離する	設計の基本単位を整理する
開放閉原則	拡張に強い構造を作る	分離した責務を安全に拡張する
依存関係逆転の原則	依存方向を制御する	責務間の結合を弱める

このように、それぞれの原則は独立したルールではなく、組み合わせることで効果を発揮します。

ただし、SOLID原則もSRPと同様に、形式的に守ればよいものではありません。
すべてのコードを抽象化したり、すべての依存関係を分離したりすると、かえって理解しづらい設計になる可能性があります。

重要なのは、将来的な変更に対してどのような構造が適切なのかを考えることです。
原則は目的ではなく、設計判断を行うための道具として利用する必要があります。

開放閉原則や依存関係逆転の原則との関係

SRPによって責務を整理した後、その責務をどのように変更に強い形で構成するかを考える際に重要になるのが、開放閉原則（Open/Closed Principle）と依存関係逆転の原則（Dependency Inversion Principle）です。

開放閉原則は、「ソフトウェアの構成要素は拡張に対して開かれ、修正に対して閉じられるべき」という考え方です。

例えば、決済処理を担当するクラスがある場合、新しい決済方式を追加するたびに既存クラスを修正する設計では、変更によるリスクが高まります。

SRPによって決済処理という責務を明確に分離し、さらに開放閉原則を適用することで、新しい決済方式を追加するときに既存コードへの影響を抑えられます。

一方、依存関係逆転の原則は、具体的な実装ではなく抽象に依存することで、変更の影響を減らす考え方です。

例えば、注文処理クラスが特定のデータベース操作クラスへ直接依存している場合、データベースを変更すると注文処理にも修正が必要になります。

しかし、データ保存という責務を抽象化し、注文処理がその抽象に依存する構造にすれば、保存方法の変更による影響を限定できます。

ここで重要なのは、SRPが「何を分けるべきか」を考える原則であり、開放閉原則や依存関係逆転の原則が「分けたものをどう結びつけるか」を考える原則だという点です。

3つの考え方を組み合わせることで、以下のような設計を目指せます。

責務ごとに変更理由を整理する
変更されやすい部分を独立させる
依存関係を制御して影響範囲を小さくする
新しい要件を追加しやすい構造にする

ただし、過剰な抽象化には注意が必要です。
将来使うか分からないインターフェースや階層構造を大量に作ると、コードの理解コストが増加します。

設計では、現在発生している問題や予想される変更に対して必要な分だけ原則を適用することが重要です。

実際の開発現場でSRPを柔軟に適用するポイント

実際の開発現場では、教科書通りに責務を分割できる状況ばかりではありません。
既存システムの制約、チームメンバーの経験、納期、技術的負債など、さまざまな要素を考慮する必要があります。

そのため、SRPは絶対的なルールではなく、設計判断のための基準として柔軟に利用することが重要です。

例えば、既存コードの1つのクラスに多くの処理が集約されている場合、いきなりすべての責務を分離すると大規模な変更になります。
その場合は、変更頻度の高い部分や問題が発生している部分から段階的に分離するほうが安全です。

また、新規開発の場合でも、最初から完璧な責務分割を目指す必要はありません。
初期段階では関連する処理をまとめて実装し、実際の変更パターンを見ながら境界を調整することも有効です。

設計判断では、以下のような観点が役立ちます。

最近変更される頻度が高い部分はどこか
修正時に影響範囲が広がって困っている箇所はどこか
複数の開発者が理解に時間を要している部分はどこか
分離することで本当に変更が容易になるか

特に重要なのは、コードの見た目だけで判断しないことです。
小さなクラスが大量に存在する設計でも、変更が安全であれば問題ありません。
逆に、きれいに整理されて見えるコードでも、変更のたびに多くの修正が必要なら改善の余地があります。

SRPを実践で活用するには、「分割する技術」だけではなく、「分割しない判断」も必要です。
ソフトウェア設計の目的は原則を満たすことではなく、変化する要求に対して持続的に対応できるコードを作ることです。

SRPを他のSOLID原則と組み合わせながら、状況に応じて適切な設計判断を行うことで、長期的に保守しやすいソフトウェアを構築できます。

SRP違反かどうかを判断するためのコードレビュー観点

SRP（単一責任の原則）を実際の開発で活用するためには、コードレビューの段階で責務が適切に分離されているかを確認することが重要です。
ただし、レビュー時に「このクラスは大きすぎる」「メソッドが多すぎる」といった表面的な基準だけで判断すると、SRPの本来の目的から外れてしまいます。

コードレビューで見るべきなのは、クラスやメソッドのサイズではなく、そのコードがどのような理由で変更される可能性があるかです。
同じ理由で変更される処理がまとまっているのであれば、多少コード量が多くても適切な設計である場合があります。

反対に、1つのクラスの中に複数の異なる変更理由が存在する場合は、SRP違反の可能性があります。
例えば、データベースの仕様変更、画面表示の変更、外部サービス連携の変更がすべて同じクラスに影響する場合、そのクラスは複数の責務を持っていると考えられます。

コードレビューでは、以下のような観点を意識すると、より本質的な判断ができます。

このクラスは何を担当しているのかを自然に説明できるか
変更要求が発生した場合、どの範囲を修正する必要があるか明確か
異なる担当領域やルール変更が同じクラスに影響していないか
クラスを分割することで本当に変更が容易になるか

また、SRP違反を見つけることだけがレビューの目的ではありません。
分割しすぎている設計についても注意する必要があります。

過剰な責務分離は、一見すると設計が整理されているように見えます。
しかし、関連する処理が複数の場所に分散すると、コードを理解するためのコストが増加します。
レビューでは「分けるべきもの」だけではなく、「まとめておくべきもの」も判断する必要があります。

SRPは、すべてのクラスを小さくするための規則ではありません。
変更理由を整理し、将来的な修正を安全に行える構造を作るための考え方です。
そのため、コードレビューでは形式的なルール適用ではなく、保守性という観点から評価することが重要になります。

責務の変更理由が異なるかを確認する

SRP違反を判断する際に最も重要な確認ポイントは、そのクラスやモジュールが複数の異なる理由で変更される可能性を持っているかどうかです。

例えば、ユーザー管理機能を担当するクラスがあるとします。
このクラスに、ユーザー情報の保存処理、メール送信処理、権限管理処理、画面表示用のデータ変換処理が含まれている場合、それぞれの変更理由を考える必要があります。

データ保存処理はデータベース設計の変更によって修正される可能性があります。
メール送信処理は通知要件の変更によって修正されます。
権限管理処理はセキュリティポリシーの変更によって修正される可能性があります。

これらは同じ「ユーザー」という領域に関係していますが、変更される理由は異なります。
そのため、1つのクラスにまとめると、変更の影響範囲が広がる可能性があります。

一方で、関連する処理を単純に分割すればよいわけではありません。
例えば、ユーザー登録時の入力検証と初期データ作成処理が、常に同じ仕様変更によって更新されるのであれば、無理に分離すると逆に理解しづらくなる場合があります。

コードレビューでは、以下のような質問をすると責務の境界を判断しやすくなります。

このクラスを変更するとき、どのような理由が考えられるか
その理由は1種類に限定されているか
別の担当者や別の仕様変更によって修正される可能性はないか
分離した場合、それぞれの責務は明確になるか

特に重要なのは、「今のコード構造」だけを見るのではなく、「未来の変更」を想定することです。

ソフトウェアは時間の経過とともに変化します。
現在動作しているコードであっても、変更しづらい構造であれば将来的な開発コストになります。
SRPを意識したレビューでは、現在の正しさだけではなく、変化への対応力を評価する必要があります。

分割によるメリットと複雑化のデメリットを比較する

SRPを適用するかどうかを判断するとき、分割によるメリットだけを見るのは危険です。
責務を分離すれば、それぞれの役割は明確になります。
しかし同時に、クラス間の依存関係や処理の流れが複雑になる可能性があります。

例えば、ある処理を独立したクラスへ分割することで、単体テストが容易になったり、別の場所で再利用できたりするメリットがあります。
しかし、そのために複数のクラスを経由しなければ処理内容を理解できなくなる場合、開発者の理解コストは増加します。

コードレビューでは、次のような比較が必要です。

観点	分割によるメリット	分割によるデメリット
保守性	変更箇所を限定できる	関連処理を追跡しにくくなる
再利用性	他の機能で利用しやすい	抽象化が過剰になる可能性がある
テスト	単体テストしやすい	テスト対象や設定が増える
理解性	責務が明確になる	クラス間の関係理解が必要になる

このような比較を行い、分割による効果が複雑化のコストを上回る場合に責務分離を行うべきです。

特に注意したいのは、将来の可能性だけを理由に分割しすぎることです。
「いつか別の場所で使うかもしれない」「将来的に変更されるかもしれない」という理由だけで抽象化や分割を進めると、現在必要のない複雑性を抱えることになります。

良い設計判断とは、可能性をすべて予測して構造を作ることではありません。
現在発生している問題や、現実的に予想される変更に対して適切な境界を設定することです。

SRPに基づくコードレビューでは、分割されているかどうかではなく、その分割が本当に価値を生んでいるかを確認する必要があります。
責務を整理する目的は、コードを美しく見せることではなく、開発者が安全に変更できる状態を維持することです。

SRPを守ることより重要な保守しやすい設計の本質

SRP（単一責任の原則）は、保守性の高いソフトウェアを設計する上で非常に有効な考え方です。
しかし、長期的に維持されるシステムを作るために本当に重要なのは、SRPというルールを厳密に守ることではありません。
大切なのは、ソフトウェアが変化し続けることを前提として、開発者が安全かつ効率的に変更できる構造を作ることです。

設計原則は、目的ではなく手段です。
SRPを含むSOLID原則や各種設計パターンは、ソフトウェアの複雑性を管理するために生まれた考え方です。
そのため、原則を適用することで逆にコードの理解が難しくなるのであれば、本来の目的から外れていると言えます。

例えば、1つのクラスが複数の処理を持っている場合、それだけでSRP違反と判断するのは適切ではありません。
重要なのは、その処理が同じ理由で変更されるかどうかです。
同じビジネスルールの変更によって一緒に修正される処理であれば、まとめて管理したほうが自然な場合があります。

一方で、異なる理由で変更される処理が混在している場合は、責務を分離することで保守性を高められます。
例えば、データ保存処理と外部サービス連携処理は、それぞれ異なる技術的制約や変更理由を持つため、分離する価値があります。

つまり、保守しやすい設計とは「最も細かく分割された設計」ではありません。
「変更の影響範囲が予測しやすく、修正箇所が明確な設計」です。

ソフトウェア開発では、コードを書いている時間よりも、既存コードを理解して変更する時間のほうが長くなることがあります。
そのため、設計品質を評価するときは、現在のコード量やクラス数ではなく、将来の変更に対してどれだけ理解しやすいかを重視する必要があります。

保守性の高い設計には、いくつかの共通した特徴があります。