SRP（単一責任の原則）とは？保守性の高い設計を実現する基本原則を徹底解説

ソフトウェア開発では、機能を追加することだけでなく、長期的に保守しやすい設計を行うことが重要です。最初は小さなコードであっても、仕様変更や機能追加が続くうちに、1つのクラスや関数が多くの役割を持つようになることがあります。その結果、修正の影響範囲が広がり、バグが発生しやすくなり、テストやレビューにも時間がかかるようになります。

SRP（単一責任の原則）は、こうした問題を防ぐための基本的な設計原則です。SRPはSOLID原則の中でも最も基本的な考え方の一つであり、「1つのモジュールやクラスは、1つの責任だけを持つべきである」という思想を示します。オブジェクト指向設計でよく語られる原則ですが、実際には関数設計、モジュール設計、Webアプリケーション開発、フロントエンド開発、API設計など、幅広い場面で活用できます。

本記事では、SRPの基本概念から、責任とは何か、SRPを守らない場合の問題、クラス・関数・モジュール設計への適用方法、Web開発やフロントエンド開発での考え方、テスト容易性との関係、SOLID原則とのつながりまで体系的に解説します。保守性の高いコードを書きたい方や、リファクタリングの判断基準を身につけたい方に向けて、実務で役立つ視点を紹介します。

1. SRP（単一責任の原則）とは？

SRP（単一責任の原則）とは、1つのクラス、関数、モジュール、コンポーネントなどが、1つの責任だけを持つべきだという設計原則です。正式名称はSingle Responsibility Principleで、SOLID原則の最初に位置づけられる重要な考え方です。単に「処理を小さく分ける」という意味ではなく、「変更される理由を1つに限定する」という点が本質です。

SRPを守ることで、コードの修正範囲を小さくし、保守性やテスト容易性を高めることができます。たとえば、ユーザー情報を管理するクラスが、データ保存、メール送信、画面表示まで担当している場合、そのクラスは複数の責任を持っています。SRPに従うなら、データ管理、通知処理、表示処理をそれぞれ別の責務として分離するべきです。

主な特徴

1.1 SRPの基本概念

SRPの基本概念は、1つの設計単位に複数の責務を持たせないことです。ここでいう設計単位とは、クラスだけでなく、関数、モジュール、ファイル、サービス、コンポーネントなども含まれます。1つの場所に多くの処理を詰め込むと、一見便利に見えても、変更時にどの処理へ影響するのか分かりにくくなります。

SRPを意識すると、コードは役割ごとに整理されます。たとえば、入力値を検証する処理、データベースへ保存する処理、メールを送信する処理、画面へ表示する処理は、それぞれ異なる責任です。これらを分離することで、各処理の目的が明確になり、修正やテストを行いやすくなります。

1.2 「変更理由は1つだけ」の意味

SRPでよく使われる「変更理由は1つだけ」という表現は、あるクラスやモジュールが変更される原因を1種類に限定するという意味です。たとえば、請求書クラスが金額計算とPDF出力の両方を担当している場合、税率変更でもPDFデザイン変更でも同じクラスを修正する必要があります。これは、変更理由が複数ある状態です。

変更理由が複数あると、関係のない修正が同じコードに集まりやすくなります。その結果、金額計算を修正しただけなのにPDF出力に影響が出る、あるいは表示レイアウトを変更しただけなのに業務ロジックが壊れるといった問題が起こりやすくなります。SRPは、こうした影響範囲を小さくするための原則です。

2. なぜSRPが重要なのか

SRPが重要な理由は、ソフトウェアが常に変更され続けるものだからです。開発が進むにつれて、仕様変更、機能追加、不具合修正、UI改善、パフォーマンス改善などが繰り返されます。1つのクラスや関数が多くの責任を持っていると、変更のたびに影響範囲が広がり、修正作業が難しくなります。

SRPを守ることで、コードの役割が明確になり、変更しやすい構造を作ることができます。責任が分離されていれば、ある変更が発生したときに、どの部分を修正すればよいか判断しやすくなります。これは保守性だけでなく、テスト容易性、レビュー効率、開発チーム内の理解しやすさにもつながります。

2.1 保守性向上

SRPを守ると、コードの保守性が向上します。1つのクラスや関数が1つの責任だけを持っていれば、修正すべき場所が分かりやすくなります。たとえば、データ保存処理だけを担当するモジュールであれば、保存方法を変更するときにそのモジュールを確認すればよく、表示処理や通知処理まで追う必要がありません。

保守性が高いコードは、長期運用に強いコードです。新しい開発者がプロジェクトに参加した場合でも、責務が明確に分かれていれば、どのコードが何を担当しているのか理解しやすくなります。結果として、修正ミスが減り、レビューや調査にかかる時間も短縮できます。

2.2 変更の影響範囲削減

SRPは、変更の影響範囲を小さくするために有効です。1つの責任ごとにコードが分かれていれば、ある機能を変更しても、関係のない処理へ影響しにくくなります。たとえば、メール送信処理を変更しても、ユーザー情報の保存処理や画面表示処理には影響しない設計にできます。

変更の影響範囲が小さいと、開発者は安心して修正できます。逆に、1つの巨大なクラスが多くの処理を担当していると、どこを変更しても別の機能に影響する可能性があり、修正が慎重になりすぎます。SRPは、コード変更の心理的負担を下げる意味でも重要です。

2.3 品質向上

SRPを守ることで、ソフトウェア品質も向上します。責任が明確に分かれているコードは、テストしやすく、バグの原因も特定しやすくなります。1つの処理に問題があった場合、その責任を持つモジュールに調査範囲を絞れるため、デバッグ効率が高まります。

また、SRPはコードレビューの品質にも影響します。1つの関数やクラスが明確な責任を持っていれば、レビュー担当者はその責務に集中して確認できます。逆に、複数の責任が混ざっているコードは、レビュー観点が増え、問題を見落としやすくなります。

3. 「責任」とは何か

SRPを理解するうえで重要なのが、「責任」とは何かを正しく捉えることです。責任とは、単なる機能の数ではなく、そのコードが変更される理由や、誰の要求によって変更されるのかを表す概念です。1つのクラスに複数のメソッドがあっても、それらが同じ責任に属していればSRPに反するとは限りません。

責任を見極めるには、コードの処理内容だけでなく、変更の理由を見る必要があります。たとえば、データ形式の変更、業務ルールの変更、UIデザインの変更、外部API仕様の変更は、それぞれ異なる変更理由です。これらが同じクラスや関数に混ざっている場合、SRPを見直すべきサインになります。

3.1 機能との違い

責任と機能は似ていますが、同じものではありません。機能は「何ができるか」を表すのに対し、責任は「何に対して責任を持つか」「どの理由で変更されるか」を表します。たとえば、ユーザー登録機能には、入力検証、データ保存、メール送信、ログ記録など複数の処理が含まれますが、それぞれ責任は異なります。

機能単位だけでコードをまとめると、1つの機能クラスが多くの責任を持つことがあります。ユーザー登録という機能を1つのクラスにまとめた結果、バリデーション、保存、通知、画面表示が混ざると、保守しづらくなります。SRPでは、機能のまとまりよりも責任の分離を意識することが重要です。

3.2 変更理由の考え方

SRPでいう責任は、「変更理由」によって考えると分かりやすくなります。あるコードが変更される理由が1つであれば、そのコードは単一責任に近い状態です。逆に、業務ルール変更、表示変更、保存方式変更など複数の理由で同じコードを修正する必要があるなら、責任が混在しています。

変更理由を考えることで、分離すべき境界が見えてきます。たとえば、価格計算ロジックはビジネスルールの変更によって変わりますが、画面の表示形式はUI要件の変更によって変わります。この2つを同じクラスに置くと、異なる理由の変更が同じ場所に集まってしまいます。

3.3 ビジネス要件との関係

責任は、ビジネス要件とも深く関係しています。ソフトウェアはビジネス上のルールや業務プロセスを反映するため、変更理由の多くはビジネス側の要求から生まれます。たとえば、料金計算、承認フロー、権限管理、契約条件などは、ビジネス要件の変更によって更新されやすい部分です。

SRPを実務で適用する際は、技術的な処理単位だけでなく、ビジネス上の責任も意識する必要があります。業務ルールを担当するコードと、表示や保存などの技術的処理を分けておけば、ビジネス要件が変わったときの影響を限定できます。これは、長期的に変更に強いシステムを作るうえで重要です。

4. SRPを守らない場合の問題

SRPを守らないコードでは、1つのクラスや関数が多くの責任を抱えるようになります。最初は小さな処理でも、機能追加を重ねるうちに、データ取得、業務ロジック、表示処理、ログ出力、通知処理などが同じ場所に集まりやすくなります。この状態は、巨大クラスや長すぎる関数の原因になります。

SRP違反が進むと、コードの変更が難しくなります。ある部分を修正しただけで別の機能に影響が出る可能性が高まり、開発者は修正を恐れるようになります。結果として、保守コストが増え、バグが増え、開発スピードも低下します。

4.1 巨大クラス化

SRPを守らない場合によく起こるのが、巨大クラス化です。1つのクラスに多くの処理が追加され、数百行から数千行に膨らんでいく状態です。巨大クラスは、どの処理がどこにあるのか分かりにくく、修正時に影響範囲を把握するのが難しくなります。

巨大クラスは、責任が分離されていないことのサインです。たとえば、ユーザー管理クラスが、データベース操作、メール送信、権限判定、ログ出力、画面表示用データ整形まで担当している場合、それぞれを別の責務として分けるべきです。SRPを適用することで、巨大クラスを小さく整理できます。

4.2 バグ発生リスク増加

複数の責任が1つのコードに混ざっていると、バグ発生リスクが高まります。ある責任に関する修正が、別の責任に影響する可能性があるためです。たとえば、表示処理を変更したつもりが、同じ関数内にあるデータ保存処理に影響してしまうことがあります。

バグの原因調査も難しくなります。責任が分かれていれば、問題が起きた領域を特定しやすいですが、複数の責任が混在していると、どこに原因があるのか分かりにくくなります。SRPを守ることで、問題の発生箇所と原因を絞り込みやすくなります。

4.3 修正コスト増加

SRPを守らないコードは、修正コストが増加します。1つの変更を行うために、巨大なクラスや複雑な関数全体を理解する必要があるためです。さらに、責任が混在していると、修正後にどの範囲をテストすべきか判断しづらくなります。

修正コストが高いコードは、開発スピードを低下させます。小さな変更でも慎重な調査が必要になり、リリースまでの時間が長くなります。SRPを意識して責務を分離しておくことで、変更対象を限定し、修正とテストを効率化できます。

5. SRPの基本例

SRPを理解するには、悪い設計例と良い設計例を比較すると分かりやすくなります。悪い設計では、1つのクラスが複数の責任を持ちます。良い設計では、それぞれの責任を別のクラスや関数に分け、変更理由を分離します。

重要なのは、単にファイル数を増やすことではありません。責任ごとに分離し、各部品が何を担当するのかを明確にすることです。SRPはコードを細かくするための原則ではなく、変更に強い構造を作るための原則です。

5.1 悪い設計例

悪い設計例として、ユーザー登録クラスが入力チェック、データベース保存、メール送信、ログ出力をすべて担当しているケースがあります。この場合、入力ルールが変わっても、保存方式が変わっても、メール文面が変わっても、同じクラスを修正する必要があります。これは変更理由が複数ある状態です。

このような設計では、1つの修正が別の処理に影響しやすくなります。メール送信処理を変更しただけなのに、登録処理全体のテストが必要になるかもしれません。責任が混在しているため、コードの理解も難しくなり、保守性が低下します。

5.2 良い設計例

良い設計では、入力チェック、データ保存、メール送信、ログ出力をそれぞれ別の責任として分けます。たとえば、入力検証はValidator、保存処理はRepository、メール送信はMailer、登録の流れを制御する処理はServiceに分けることができます。これにより、それぞれの変更理由を分離できます。

この設計では、メール文面を変更したい場合はMailerだけを修正すればよく、保存処理や入力チェックに影響しにくくなります。責任が明確に分かれているため、テストも書きやすくなります。SRPを適用することで、コードの変更が安全で分かりやすくなります。

5.3 責任分離の考え方

責任分離では、処理を「何を担当しているか」に基づいて分けます。データを検証する責任、データを保存する責任、外部へ通知する責任、画面に表示する責任は、それぞれ異なる責任です。これらを1つにまとめると、変更理由が増えてSRPに反しやすくなります。

責任分離を行うときは、まず現在のコードがどのような理由で変更される可能性があるかを考えます。複数の変更理由が見つかる場合、それらを別々のクラスや関数へ分ける候補になります。実務では、変更理由を軸に考えることで、自然な分割がしやすくなります。

6. クラス設計におけるSRP

クラス設計におけるSRPでは、1つのクラスが1つの責任だけを持つように設計します。オブジェクト指向では、クラスにデータと振る舞いをまとめますが、便利だからといって関係の薄い処理まで詰め込むと、巨大クラスになりやすくなります。

クラスの責任を考えるときは、そのクラスがどの変更理由によって修正されるのかを確認します。データ構造の変更、業務ルールの変更、表示形式の変更、保存方式の変更などが同じクラスに集まっている場合、責任分離を検討するべきです。

6.1 データ管理

データ管理を担当するクラスは、データの保持や取得、保存に関する責任を持ちます。たとえば、RepositoryやData Access Objectのようなクラスは、データベースや外部ストレージとのやり取りを担当します。この責任を明確にすれば、保存方法が変わったときの修正範囲を限定できます。

データ管理クラスに業務ロジックや表示処理を混ぜると、SRPに反しやすくなります。データ保存の形式が変わっただけで業務処理にも影響したり、画面表示の変更でデータアクセス層を修正したりする状態は好ましくありません。データ管理はデータ管理として独立させることが重要です。

6.2 業務ロジック

業務ロジックは、システムの中核となるルールや判断を担当します。料金計算、権限判定、在庫確認、承認フロー、契約条件などは、ビジネス要件に基づいて変更される処理です。これらはデータ保存や表示処理とは分けて設計することで、変更に強くなります。

業務ロジックを適切に分離しておくと、テストもしやすくなります。データベースやUIに依存せず、純粋にルールだけを検証できるため、単体テストの品質が上がります。SRPを守ることで、ビジネス上重要な処理を分かりやすく管理できます。

6.3 表示処理

表示処理は、ユーザーに情報をどのように見せるかを担当します。画面レイアウト、表示形式、文言、UI状態などは、UIやUXの要件によって変更されます。これらを業務ロジックやデータ保存処理と混ぜると、見た目の変更がシステム内部の処理に影響しやすくなります。

表示処理を分離すると、UI変更に強い設計になります。たとえば、同じ業務ロジックをWeb画面、モバイルアプリ、管理画面で使い回す場合、表示処理が分離されていれば再利用しやすくなります。SRPは、UIとロジックの分離にも大きく関係しています。

7. 関数設計におけるSRP

SRPはクラスだけでなく、関数設計にも適用できます。1つの関数が複数の処理を行っている場合、その関数は理解しづらく、テストしにくく、修正しにくくなります。関数も1つの目的に集中させることで、読みやすく保守しやすいコードになります。

関数におけるSRPでは、「この関数は何をするのか」を一言で説明できるかが重要です。説明が長くなったり、「AしてBしてCする」という形になったりする場合、その関数は複数の責任を持っている可能性があります。小さく明確な関数に分けることで、コード全体の品質が向上します。

7.1 一つの処理に集中

関数は、できるだけ1つの処理に集中させるべきです。たとえば、入力値を検証する関数は検証だけを行い、保存や通知までは担当しないようにします。1つの関数に複数の処理を詰め込むと、修正時にどの処理へ影響するのか分かりにくくなります。

一つの処理に集中した関数は、再利用もしやすくなります。入力チェックだけを行う関数であれば、複数の画面やAPIで使い回せます。一方で、入力チェックと保存処理が一体化している関数は、保存が不要な場面では使いにくくなります。SRPは関数の再利用性にも影響します。

7.2 長すぎる関数の問題

長すぎる関数は、SRP違反のサインであることが多いです。長い関数には、複数の条件分岐、データ変換、外部呼び出し、エラーハンドリングなどが混ざりやすくなります。その結果、処理の流れを理解するのに時間がかかり、修正時のリスクも高まります。

長い関数を改善するには、処理のまとまりごとに小さな関数へ切り出すことが有効です。入力チェック、データ変換、保存処理、レスポンス生成など、役割ごとに分けることで、各関数の責任が明確になります。これにより、読みやすくテストしやすいコードになります。

7.3 可読性向上

SRPに従った関数設計は、可読性の向上につながります。関数名を見ただけで何をするのか分かる状態になれば、コードを読む負担が減ります。処理が小さく分かれていれば、全体の流れも理解しやすくなります。

可読性が高い関数は、レビューやデバッグでも有利です。問題が発生したときに、どの関数がどの責任を持っているか分かれば、原因を絞り込みやすくなります。SRPは、コードを短くするためだけでなく、読み手にとって分かりやすい構造を作るための原則です。

8. モジュール設計におけるSRP

モジュール設計におけるSRPでは、1つのモジュールが1つの明確な責務を持つように分割します。モジュールはクラスより大きな単位であることが多く、機能全体や特定のレイヤーを担当する場合があります。そのため、モジュールの責務が曖昧だと、プロジェクト全体の構造が分かりにくくなります。

モジュールに複数の責任が混ざると、再利用性も低下します。たとえば、ログ処理モジュールに設定読み込みや通知処理が混ざっていると、ログ機能だけを別の場所で使いたい場合に余計な依存が発生します。SRPを意識したモジュール設計は、保守性と拡張性を高めます。

8.1 機能ごとの分割

モジュールは、機能ごとに分割することで責務を明確にできます。認証、ユーザー管理、注文管理、通知、ログ、設定、API通信など、それぞれを独立したモジュールとして設計すれば、変更の影響範囲を限定できます。機能ごとの分割は、プロジェクトの見通しを良くするうえで重要です。

ただし、機能ごとの分割では、境界を適切に決める必要があります。関係の強い処理を細かく分けすぎると、モジュール間の連携が複雑になります。逆に、関係の薄い処理を1つのモジュールにまとめると、責任が混在します。SRPでは、変更理由と責任のまとまりを基準に分割することが大切です。

8.2 責務の明確化

モジュールの責務を明確にするには、そのモジュールが何を担当し、何を担当しないのかを決める必要があります。たとえば、認証モジュールはログイン状態やトークン検証を担当し、ユーザー情報の表示やメール送信は別モジュールに任せる、といった整理です。

責務が明確なモジュールは、利用者にとっても分かりやすくなります。どの処理をどのモジュールに追加すべきか判断しやすく、コードの配置も安定します。責務が曖昧なモジュールは、便利な置き場所として使われやすく、時間とともに肥大化します。

8.3 再利用性向上

SRPを守ったモジュールは、再利用しやすくなります。1つの責任に集中しているため、別の機能や別のプロジェクトでも利用しやすいからです。たとえば、ログ出力だけを担当するモジュールは、Webアプリ、バッチ処理、CLIツールなどさまざまな場面で使えます。

再利用性を高めるには、モジュールの依存関係を少なくすることも重要です。特定の画面や特定の業務ロジックに強く依存しているモジュールは、別の場所で使いにくくなります。SRPに従い、責任を明確に分けることで、独立性の高いモジュールを作ることができます。

9. Web開発でのSRP

Web開発では、Controller、Service、Repositoryなどの役割分担によってSRPを実践することが多いです。各レイヤーが異なる責任を持つことで、コードの見通しが良くなり、変更やテストもしやすくなります。特に業務アプリケーションでは、責務分離が保守性に大きく影響します。

SRPを意識しないWeb開発では、Controllerにすべての処理が集まりがちです。リクエスト処理、入力チェック、業務ロジック、データベース操作、レスポンス生成をすべてControllerに書くと、巨大で変更しづらいコードになります。役割ごとに分けることで、保守性を高められます。

9.1 Controller

Controllerは、HTTPリクエストを受け取り、必要な処理へ橋渡しする役割を持ちます。入力値を受け取り、Serviceを呼び出し、結果をレスポンスとして返すのが基本的な責任です。Controllerに業務ロジックやデータアクセス処理を大量に書くと、SRPに反しやすくなります。

Controllerを薄く保つことで、Webアプリケーション全体の見通しが良くなります。Controllerはリクエストとレスポンスの制御に集中し、業務判断はService、データ取得はRepositoryに任せる設計が望ましいです。これにより、処理ごとの責任が明確になります。

9.2 Service

Serviceは、業務ロジックを担当する層です。注文確定、料金計算、在庫確認、ユーザー登録、権限判定など、ビジネスルールに関わる処理をServiceに集約します。Controllerから切り離すことで、業務ロジックを再利用しやすくなり、テストもしやすくなります。

Serviceの責任も明確にする必要があります。1つのServiceに多くの業務領域を詰め込むと、巨大Serviceになり、保守性が低下します。ユーザー管理、注文管理、決済処理など、ビジネス上の責務ごとに分けることで、SRPに沿った設計になります。

9.3 Repository

Repositoryは、データアクセスを担当する層です。データベースからの取得、保存、更新、削除などを担当し、業務ロジックからデータアクセスの詳細を隠蔽します。Repositoryを用意することで、Serviceはデータベースの具体的な操作を意識せずに済みます。

Repositoryに業務ロジックを入れすぎると、責任が混在します。Repositoryはデータの取得や保存に集中し、取得したデータをどう判断するかはService側で扱うのが基本です。責任を分けることで、データベース変更や業務ルール変更に対して柔軟に対応できます。

10. API設計とSRP

API設計においてもSRPは重要です。認証処理、業務処理、データアクセス、レスポンス生成、エラーハンドリングなどを適切に分けることで、保守しやすく一貫性のあるAPIを作ることができます。1つのAPIハンドラーにすべての処理を詰め込むと、変更やテストが難しくなります。

APIは他のシステムやフロントエンドから利用されるため、安定性と一貫性が求められます。SRPに沿って責任を分けておけば、認証方式の変更、業務ルールの変更、データベース構造の変更がそれぞれ独立して扱いやすくなります。

10.1 認証処理

認証処理は、APIにアクセスしているユーザーやシステムが正当かどうかを確認する責任を持ちます。トークン検証、セッション確認、権限チェックなどは、多くのAPIで共通して必要になる処理です。これを各APIハンドラーに個別に書くと、重複や実装漏れが発生しやすくなります。

認証処理は、ミドルウェアや共通モジュールとして分離するのが一般的です。APIハンドラーは業務処理に集中し、認証は認証専用の仕組みに任せることで、SRPを守りやすくなります。認証方式が変わった場合も、共通部分を修正すれば対応しやすくなります。

10.2 業務処理

APIの業務処理は、リクエストに対してどのようなビジネスルールを適用するかを担当します。注文作成、ユーザー登録、在庫更新、レポート生成などは、業務処理に該当します。これらは認証やデータアクセスと分けて、Service層などに配置すると管理しやすくなります。

業務処理をAPIハンドラーに直接書くと、同じロジックを別のAPIやバッチ処理で使い回しにくくなります。Serviceとして分離しておけば、Web API、管理画面、バッチ処理などから同じ業務ロジックを利用できます。SRPは、業務処理の再利用性にも貢献します。

10.3 データアクセス

APIにおけるデータアクセスは、データベースや外部ストレージとのやり取りを担当します。SQLやORMの操作、データ取得条件、保存処理などは、RepositoryやData Access層に分けることで責任を明確にできます。APIハンドラーが直接データベースを操作すると、責任が混在しやすくなります。

データアクセスを分離すると、データベース構造の変更にも対応しやすくなります。ServiceやControllerはRepositoryのインターフェースを通じてデータを扱うため、内部の保存方法が変わっても影響を抑えられます。SRPは、APIの長期的な保守性を支える設計原則です。

11. フロントエンド開発とSRP

フロントエンド開発でもSRPは重要です。UIコンポーネント、状態管理、API通信、表示ロジック、入力検証などが1つのコンポーネントに混ざると、コードが肥大化し、修正やテストが難しくなります。特にReactやVueなどのコンポーネントベース開発では、責務分離が品質に大きく影響します。

SRPを意識すると、コンポーネントは表示に集中し、状態管理やAPI通信は別のフックやサービスへ分離できます。これにより、UIの変更とデータ取得ロジックの変更を分けて扱えるようになります。フロントエンドでも、変更理由を1つに近づけることが重要です。

11.1 UIコンポーネント

UIコンポーネントは、画面に何をどのように表示するかを担当します。ボタン、入力フォーム、カード、リスト、モーダルなどは、見た目や操作感に関する責任を持つ部品です。UIコンポーネントにAPI通信や複雑な業務ロジックを入れすぎると、再利用しにくくなります。

UIコンポーネントを表示に集中させると、再利用性が高まります。たとえば、データをpropsとして受け取り、表示だけを担当するコンポーネントは、複数の画面で使い回しやすくなります。見た目の変更が必要な場合も、コンポーネント単位で修正できます。

11.2 状態管理

状態管理は、アプリケーションのデータやUI状態を管理する責任を持ちます。ログイン状態、フォーム入力値、選択中の項目、取得済みデータなどは、適切な場所で管理する必要があります。状態管理をUIコンポーネントに詰め込みすぎると、コンポーネントが複雑になります。

状態管理を分離することで、UIとロジックの責任を分けられます。Reactであればカスタムフック、状態管理ライブラリ、コンテキストなどを使って、状態管理を整理できます。これにより、UIコンポーネントは表示に集中し、状態の更新ルールは別の場所で管理できます。

11.3 API通信

API通信は、外部データの取得や送信を担当する責任です。コンポーネント内に直接fetchやaxiosの処理を大量に書くと、表示処理と通信処理が混ざり、保守しづらくなります。API通信は、サービス層やカスタムフックとして分離することでSRPを守りやすくなります。

API通信を分離すると、エラーハンドリングやローディング状態の管理も統一しやすくなります。また、同じAPIを複数の画面で利用する場合も、共通の通信処理を再利用できます。フロントエンド開発におけるSRPは、UIの見通しとデータ処理の安定性を高めます。

12. テスト容易性との関係

SRPはテスト容易性と深く関係しています。1つのクラスや関数が1つの責任だけを持っていれば、その責任に対するテストを簡単に書けます。逆に、複数の責任が混ざっているコードは、テストの前提条件が増え、何を検証しているのか分かりにくくなります。

テストしやすいコードは、変更に強いコードでもあります。SRPによって責任が分かれていれば、ある処理を変更したときに、その処理に対応するテストを重点的に確認できます。テストの範囲が明確になるため、品質保証の効率も高まります。

12.1 単体テストの簡略化

SRPを守ったコードは、単体テストを書きやすくなります。1つの関数やクラスが1つの責任に集中していれば、入力と出力を確認するだけでテストできる場合が多くなります。複雑な外部依存や複数の処理を同時に扱う必要がないため、テストケースをシンプルにできます。

単体テストが簡単になると、テストの追加や保守もしやすくなります。新しい仕様が追加された場合でも、対象となる責任に対応するテストを追加すればよくなります。SRPは、テストコードの可読性や信頼性にも影響する設計原則です。

12.2 モック作成の容易化

責任が分離されていると、モックの作成も容易になります。たとえば、業務ロジックをテストするときに、データベースアクセスがRepositoryとして分離されていれば、そのRepositoryをモックに差し替えることができます。これにより、外部依存を切り離してテストできます。

複数の責任が1つのクラスに混ざっていると、モック化が難しくなります。データアクセス、メール送信、ログ出力などが同じ処理に含まれていると、テストのために多くの依存を準備しなければなりません。SRPを守ることで、テスト対象を小さく保てます。

12.3 品質向上

SRPによってテストしやすい構造を作ることは、品質向上につながります。責任ごとにテストできれば、不具合を早期に発見しやすくなります。また、変更時にも関連するテストを実行しやすいため、リグレッションのリスクを下げられます。

品質向上は、単にバグを減らすことだけではありません。コードの理解しやすさ、修正しやすさ、レビューしやすさも品質の一部です。SRPを守ることで、開発者が安心して変更できるコードベースを作ることができます。

13. SRP適用時の注意点

SRPは有効な原則ですが、適用方法を誤ると逆効果になることがあります。責任を分けることを意識しすぎて、必要以上にクラスやファイルを細かく分割すると、全体の構造がかえって分かりにくくなる場合があります。SRPは「細かく分けること」ではなく、「変更理由を整理すること」です。

実務では、SRPとシンプルさのバランスが重要です。責任が明確に異なる場合は分離すべきですが、まだ小さく安定している処理を無理に分ける必要はありません。過剰分割を避けながら、変更に強い単位で整理することが求められます。

13.1 過剰分割

過剰分割とは、責任を分けようとするあまり、細かすぎるクラスや関数を大量に作ってしまう状態です。1つの処理を理解するために多くのファイルを行き来しなければならない場合、コードの見通しは悪くなります。これはSRPの本来の目的である保守性向上に反します。

過剰分割を避けるには、変更理由を基準に分けることが重要です。単に処理が少し違うから分けるのではなく、別々の理由で変更されるかどうかを確認します。同じ責任に属する処理であれば、ある程度まとめておく方が分かりやすい場合もあります。

13.2 クラス増加

SRPを適用すると、責任ごとにクラスやモジュールが増えることがあります。適切に分割されていれば問題ありませんが、設計ルールがないまま増えると、どのクラスが何を担当しているのか分かりにくくなります。クラス数が増えること自体は悪ではありませんが、構造が整理されている必要があります。

クラス増加に対応するには、命名規則やディレクトリ構成を整えることが重要です。Service、Repository、Validator、Formatterなど、役割が分かる名前を付けることで、利用者が迷いにくくなります。SRPを実践する際は、分割後の管理しやすさまで考える必要があります。

13.3 バランスの重要性

SRPは、他の設計原則と同じくバランスが重要です。責任を分けすぎると複雑になり、分けなさすぎると巨大なコードになります。どこで分けるべきかは、プロジェクトの規模、変更頻度、チーム体制、テスト方針によって変わります。

実務では、最初から完璧な分割を目指すより、コードの成長に合わせてリファクタリングする方が現実的です。最初はシンプルに実装し、責任の混在が見えてきた段階で分離する方法も有効です。SRPは、一度適用して終わりではなく、継続的に見直すべき原則です。

14. SOLID原則との関係

SRPはSOLID原則の最初に位置づけられる原則です。SOLID原則は、オブジェクト指向設計において保守性や拡張性を高めるための5つの原則であり、SRPはその基盤となる考え方です。責任が整理されていないコードでは、他の原則を適用することも難しくなります。

SRPは、OCPやDIPなど他のSOLID原則とも密接に関係しています。責任が明確に分かれているからこそ、拡張しやすく、依存関係を制御しやすい設計が可能になります。SOLID全体を理解するうえでも、まずSRPを押さえることが重要です。

14.1 OCPとの関係

OCP（Open/Closed Principle）は、拡張に対して開かれ、変更に対して閉じているべきという原則です。SRPによって責任が分かれていると、新しい機能を追加するときに既存コードを大きく変更せず、必要な責任の部分だけを拡張しやすくなります。

責任が混在しているコードでは、機能追加のたびに巨大なクラスを修正する必要があり、OCPを守りにくくなります。SRPは、OCPを実現するための前提条件のような役割を持ちます。責任分離ができているほど、拡張に強い設計を作りやすくなります。

14.2 DIPとの関係

DIP（Dependency Inversion Principle）は、上位モジュールが下位モジュールの具体実装に依存せず、抽象に依存するべきという原則です。SRPによって責任が分かれていると、どの部分を抽象化すべきか判断しやすくなります。たとえば、業務ロジックとデータアクセスが分離されていれば、Repositoryをインターフェースとして扱いやすくなります。

SRPを守らずに責任が混在していると、依存関係も複雑になります。業務ロジックが直接データベースや外部APIに依存していると、テストや変更が難しくなります。SRPで責任を分け、そのうえでDIPを適用することで、柔軟でテストしやすい設計になります。

14.3 設計全体への影響

SRPは、設計全体の土台となる原則です。責任が明確に分かれていれば、コードの配置、依存関係、テスト方針、拡張方法が整理しやすくなります。逆に、責任が曖昧なままでは、どの原則を適用しても構造が不安定になります。

SOLID原則全体を実務で活かすには、まずSRPによって責務を整理することが重要です。そのうえで、拡張性を高めるOCP、置換可能性を意識するLSP、インターフェースを分けるISP、依存関係を制御するDIPを組み合わせることで、保守性の高い設計に近づきます。

15. 実務でのベストプラクティス

実務でSRPを活用するには、変更理由を意識する、責務ごとに分離する、定期的にリファクタリングするという3つの考え方が重要です。SRPは抽象的な原則ですが、日々の設計判断やコードレビューで使える実践的な基準になります。

SRPを適用するときは、最初から完璧な分割を目指す必要はありません。プロジェクトの成長に合わせて、責任が混ざってきた部分を見つけ、段階的に整理していくことが現実的です。継続的な改善によって、保守しやすいコードベースを維持できます。

15.1 変更理由を意識する

SRPを実践する最も重要なポイントは、変更理由を意識することです。あるクラスや関数が、どのような理由で変更される可能性があるのかを考えることで、責任の混在を発見できます。ビジネスルール変更、UI変更、データ保存方式変更、外部API仕様変更などは、それぞれ異なる変更理由です。

変更理由を意識すると、自然に分離すべき境界が見えてきます。たとえば、画面表示と業務判断が同じ関数に混ざっている場合、それぞれ別の理由で変更されるため分離候補になります。コードレビューでも、「このコードは何の理由で変更されるか」を確認すると、SRP違反を見つけやすくなります。

15.2 責務ごとに分離する

責務ごとに分離することで、コードの目的が明確になります。入力検証、業務ロジック、データアクセス、通知、ログ、表示処理などを、それぞれ適切なクラスやモジュールへ分けると、変更範囲を限定できます。分離された責務は、単体でテストしやすく、再利用もしやすくなります。

ただし、責務分離では過剰分割に注意が必要です。責任が明確に異なる場合は分けるべきですが、無理に細かく分けすぎると、コードの追跡が難しくなります。実務では、変更理由、利用頻度、処理の複雑さを見ながら、適切な粒度で分離することが大切です。

15.3 定期的にリファクタリングする

SRPを維持するには、定期的なリファクタリングが欠かせません。最初は単一責任だったコードでも、機能追加や仕様変更が続くうちに、複数の責任を持つようになることがあります。責任の混在を放置すると、巨大クラスや長すぎる関数へ成長してしまいます。

リファクタリングでは、変更理由が複数になっていないか、テストしづらくなっていないか、関係の薄い処理が混ざっていないかを確認します。問題が見つかったら、関数抽出、クラス分割、モジュール分離などを行います。SRPは一度守れば終わりではなく、継続的に見直すべき設計原則です。

おわりに

SRP（単一責任の原則）は、「1つの責任だけを持つ」というシンプルながら非常に重要な設計原則です。その本質は、単にクラスや関数を小さくすることではなく、「変更理由を1つに限定すること」にあります。責任が明確に分かれていれば、修正範囲を小さくでき、保守性やテスト容易性を高めることができます。

SRPはオブジェクト指向設計だけでなく、関数設計、モジュール設計、Web開発、API設計、フロントエンド開発など、幅広い領域で活用できます。Controller、Service、Repositoryの分離、UIコンポーネントとAPI通信の分離、業務ロジックとデータアクセスの分離など、実務の多くの場面でSRPの考え方が役立ちます。

一方で、SRPを過剰に適用すると、クラスやファイルが増えすぎて構造が分かりにくくなることもあります。重要なのは、変更理由を見極めながら、適切な粒度で責務を分離することです。必要以上に細かく分けるのではなく、保守性と分かりやすさのバランスを取る必要があります。

SRPはSOLID原則の基盤となる考え方であり、OCPやDIPなど他の設計原則を活かすためにも重要です。定期的なリファクタリングを通じて責任の混在を見直し、変更に強く、テストしやすく、長期的に保守しやすいコードベースを目指しましょう。