そのクラス、触るたびに何か壊れるやつになってない？🥺

これ絶対あるじゃん？？これ絶対あるじゃん？？

1000行超えのクラスがある
「とりあえずここに書いとけ」ってメソッドが積み上がってる
誰かが直すたびに、関係ないはずの場所が壊れる
「このファイルだけは触りたくない」って思いながらPR出してる

あるよね？あるよね絶対？？

これ全部、God Class（ゴッドクラス）、以降「神クラス」って呼ぶね、が原因なんだよね。

てかシンプルに言うとねてかシンプルに言うとね

1つのクラスが、全部の仕事を抱え込んでる。

「それの何がまずいの？」ってなる気持ち、わかる！
でもこれが深夜2時のSlack通知に直結するって話、ちゃんとするね。

ちょっと待って、先に全然関係ない話していい？🏠 ちょっと待って、先に全然関係ない話していい？🏠

田中さんって社員がいる会社を想像してほしいんだけどさ。

この田中さんがとにかくなんでもできる人でね、営業もやる、経理もやる、採用面接もこなす、掃除もする。社長は大喜びで、何かあればぜんぶ田中さんに投げてたの。

ある日、税制改正があって消費税のルールが変わったんだよね。
「田中さん、経理の計算式を直しといて〜」ってお願いしたら、翌朝「完璧です！」って返ってきた。

で、翌日の朝。こうなった。

「田中さん、見積書の金額がおかしいんだけど」

田中さん、経理の計算式を直したとき、営業の見積書にも同じ式を使ってたの忘れてた💔

昼過ぎに採用担当から。

「田中さん、来週の面接の日程が全員ずれてるんだけど」

面接スケジュールのスプレッドシート、実は経理ファイルと関数が連動してたんだよね。ヤバくない？

夕方に社長から。

「田中さん、先月の売上データが消えてるんだけど」

修正の途中で上書きしてた。

このとき田中さんの頭の中、こうなってる。

「計算式を1個直しただけなのに、なんで3箇所壊れてるの。どこまで壊れてるか、自分でもわかんない。てかそもそも全部わかってるの自分だけ」

クレーム来る。上司に呼ばれる。直しながら別の仕事も止められない。深夜まで作業して——翌朝辞めたんだって。マジで。

これが本番で起きてるやつが、神クラスってこと。

じゃあコードで見てみよっか👀 じゃあコードで見てみよっか👀

OrderManager ってクラス、見たことない？

class OrderManager:
    def create_order(self, user_id, items):
        # 注文を作る
        ...

    def calculate_tax(self, price):
        # 税金を計算する
        ...

    def send_confirmation_email(self, email, order):
        # メールを送る
        ...

    def update_inventory(self, items):
        # 在庫を更新する
        ...

    def generate_invoice_pdf(self, order):
        # 請求書PDFを作る
        ...

    def log_to_database(self, event):
        # ログを記録する
        ...

注文・税計算・メール・在庫・PDF・ログ、全部 OrderManager（=田中さん）がやってるじゃん。

ここで「税計算のロジックを変えて」って依頼が来たとするよね。
calculate_tax を修正して、テスト通った。リリースした。よしっ。

翌日——

請求書PDFの金額がおかしい（generate_invoice_pdf も同じ式を使ってた）
メールの合計金額が違う（send_confirmation_email も同様）
ログの金額がずれてる（log_to_database も影響受けてた）

修正は1行、壊れた箇所は4つ。

「なんで壊れてるか」の原因特定だけで数時間溶けて、深夜にSlack通知が来て、顧客に謝罪して、リリースを巻き戻す。
「ちょっとした修正だったのに」ってなるやつ。えぐいんだよねこれ。

やばいのまだあんだけど、バグに気づけない問題😭 やばいのまだあんだけど、バグに気づけない問題😭

神クラスの怖さって「壊れやすい」だけじゃなくて、「壊れてても気づけない」 のがほんとにやばい。

田中さんが全部やってる会社で「田中さんの仕事、正しくできてるか確認して」って言われたとする。

何を確認する？

経理の計算が正しいか
見積書の金額が正しいか
面接の日程がずれてないか
掃除が行き届いてるか
さらに、それぞれが互いに干渉してないか

この最後のやつが一番えぐくて。「経理変えたとき、営業への影響は？採用は？その組み合わせ何通りある？」ってなるじゃん。

全部確認しきれないから「たぶん大丈夫」でリリースするじゃん。その「たぶん」の隙間にバグが育つんだよね。

コードで言うと、OrderManager のテストはこんな地獄になる。

「税計算変えたとき、メール送信は正しく動くか？」
「在庫更新変えたとき、PDF生成に影響は出ないか？」
「メール送信が失敗したとき、在庫は正しく戻るか？」
「ログが失敗したとき、注文自体はどうなるか？」

テストケースが組み合わせ爆発を起こして、全部書ききれないからどこかを省略するじゃん。その省略した箇所に、バグが潜む。本番でそれが表に出るまで、誰も気づけないんだよね。

神クラスは「壊れやすい」だけじゃなく、バグを隠す設計でもあるってこと。

分けてた会社の話もするね〜✨ 分けてた会社の話もするね〜✨

田中さんがいた会社とは別に、最初から役割を分けてた会社の話もするね。

経理の鈴木さん：税金の計算と帳簿だけ
営業の佐藤さん：見積書の作成だけ
採用の山田さん：面接スケジュールの管理だけ

同じ日に税制改正の連絡が来て、「鈴木さん、計算式を変更しといてください」ってお願いしたんだけどさ。

鈴木さんは経理の計算式だけを修正した。30分で終わったんだって。

その日、佐藤さんは普通に営業してた。山田さんは普通に面接の準備してた。
誰も「自分の仕事が壊れてないか確認する」必要がなかった。

鈴木さんの修正は、鈴木さんの仕事にしか影響しないからね。それだけのことで、翌日何も壊れてなかった。クレームも来なかった。深夜対応もなかった。全員が定時で帰ったっていう。

コードに戻すとこうなるんだよね。

TaxCalculator だけを修正した。

EmailService は何もしなくていい。 メール送信のロジックは変わってないから。
InventoryService も何もしなくていい。 在庫管理のロジックは変わってないから。
InvoiceGenerator も何もしなくていい。 請求書のテンプレートは変わってないから。

直すのは1クラス、壊れるかもしれない場所も1クラス。テスト1箇所だけ確認してリリースできる。

class TaxCalculator:
    def calculate(self, price):
        # 税金の計算だけに責任を持つ
        ...

class EmailService:
    def send_confirmation(self, email, order):
        # メール送信だけに責任を持つ
        ...

class InventoryService:
    def update(self, items):
        # 在庫管理だけに責任を持つ
        ...

class InvoiceGenerator:
    def generate_pdf(self, order):
        # 請求書生成だけに責任を持つ
        ...

「税計算が変わった → TaxCalculator だけ直す」、これで全部。
他のクラスには関係ないから、触らなくていいんだよね。

「直すときに関係ある場所が1つだけ」になってる。これが仕事を分けること——責務の分離（Single Responsibility Principle、以降SRP）ってこと。

ちゃんとした名前もあるから一応言うね📚 ちゃんとした名前もあるから一応言うね📚

SRP（単一責任原則）とは、「このクラスを書き直すきっかけが1個だけになるように作ること」

Uncle Bobって呼ばれてるRobert C. Martinって人が言い出して、2002年の本で広まったやつ。SOLID原則のSね。

難しそうに聞こえるけど、やることは「このクラスを書き直すきっかけ、何個ある？」って聞き続けるだけなんだよね。

これだけ覚えて帰って🥺 これだけ覚えて帰って🥺

合言葉はこれ。nmy（なんでも屋）

コード書くとき、レビューするとき、これだけ問いかけてみて。

「このクラスのロジックが変わるとしたら、どんな出来事が起きたとき？」

たとえば OrderManager だったら——

税率が変わったとき（国の法律が変わった）
メールの文面が変わったとき（マーケがやり方を変えた）
在庫の管理ルールが変わったとき（倉庫の運用が変わった）

出来事が3種類出てきたよね？それ、書き直すきっかけが3つあるってことじゃん。
つまり田中さんが3人分の仕事を抱えてる状態なんだよね。

「このクラスを書き直すきっかけになる出来事、何個ある？」に対して、答えが1個だけになるまで分ける。 それだけっつーこと。

まとめるとこういうことねまとめるとこういうことね

	神クラス	責務が分離されたクラス
変更したとき	複数箇所が壊れる	影響が1箇所に閉じる
原因調査	どこが壊れたか把握できない	直すべき場所が一発でわかる
テスト	組み合わせ爆発で抜け漏れる	対象が明確で書ききれる
リリース後	深夜Slackが飛んでくる	定時で帰れる
チームの空気	誰も触りたくない	安心して修正できる

田中さんを量産しないために仕事を分ける設計、それがSRPっつーこと。

Dev-Here「ギャルでも分かる設計の勘ドコロ！」シリーズ第1回

沼りたい人はこっちも読んで📖 沼りたい人はこっちも読んで📖

書籍

Robert C. Martin 著『Clean Code』（2008） — 神クラスを含むコードの悪臭（Code Smell）と、保守しやすいコードの書き方を体系的に解説。
Robert C. Martin 著『Agile Software Development, Principles, Patterns, and Practices』（2002） — SOLID原則が初めて体系化された書籍。SRPの原典。
Martin Fowler 著『Refactoring: Improving the Design of Existing Code』（1999, 第2版2018） — 神クラスを含む「コードの臭い」の分類とリファクタリング手法を網羅。
Kevlin Henney 編著『97 Things Every Programmer Should Know』（2010, O'Reilly） — 第76章がSRPを扱っている。

一次資料

Uncle Bob公式ブログ — The Single Responsibility Principle https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html
Wikipedia — Single-responsibility principle https://en.wikipedia.org/wiki/Single-responsibility_principle
DigitalOcean — SOLID Design Principles Explained https://www.digitalocean.com/community/conceptual-articles/s-o-l-i-d-the-first-five-principles-of-object-oriented-design