【コード哲学エッセイ】 関数は仕事じゃなく責任を持つ

単一責任原則の先にある意味の話

新しい機能を書くとき、僕はまず忙しい社員を雇いがちでした。

検証もする。
保存もする。
通知も飛ばす。
ログも残す。

一つの関数のなかに、できることを全部詰め込む。
名前は processUser みたいに、なんでもできそうな響き。

動く。
テストも通る。
だから正しいはずだと思っていた。

でも数ヶ月後、仕様がひとつ変わっただけで、その関数は最初に悲鳴を上げます。
変更の影響が、予想外のところまで波及する。

「ただのメール文面の修正のはずなのに、なぜ保存処理まで触るの？」

僕はそこで初めて気づきました。
関数に仕事を渡しすぎていたのだと。

単一責任を数え方だけにしていた

救いと思って手にしたのが、単一責任の原則でした。

「一つの関数は、一つのことだけをする」

教科書の言葉は、とても気持ちよかった。

だから僕は、機械的に切りました。
検証用、保存用、通知用、ログ用。
ファイルは増える。
行数は減る。
見た目はきれいになる。

でも読み返すと、別の違和感が残る。
どの関数が、どの問いに答えているのかが、見えない。

細かく割っただけで、意味の地図ができていない。
仕事は分散したのに、責任の輪郭はぼやけたままだったのです。

責任とは処理の量じゃない

転機は、命名の話と重なったときに来ました。

名前は説明ではなく約束だ、と気づいたあと、関数の見方も変わりました。

関数とは、ひとつの問いに答える存在なのかもしれない。

「このユーザーは有効か？」
「歓迎メールを送るべきか？」
「請求レコードを作るべきか？」

問いが違えば、関数は分かれる。
問いが同じなら、実装が長くても一つにまとまっていい。

これが僕にとっての責任です。
仕事のリストではなく、答える範囲の宣言。

責任がはっきりしている関数は、未来の自分を責めない。
「ここを変えればいい」と指が示せるからです。

意味のない分割は責任の放棄になる

逆に、意味のない分割は怖い。
三行の関数が十個並ぶだけのファイル。
呼び出しの鎖を辿らないと、全体が読めない。

それは丁寧さじゃない。
責任を細切れにして、誰のものか曖昧にする行為に近い。

単一責任の先にあるのは、行数の少なさじゃない。
変更の理由が、一つの問いに収まること。

抽象化が汎用ではなく変わるところを囲う道具だとしたら、
関数の責任はその囲いの中で、何に答えるかを決める作業です。

設計は、仕事を配分する作業ではない。
意味を配分する作業なのだと、今はそう思っています。

ひとりごと

吃音のある僕にとって、言葉は詰まるほど大事なものです。
だからこそ、コードのなかの言葉——関数の境界——を曖昧にしたくない。

みなさんの関数が、忙しさではなく責任で名前を持てますように。

Substack はじめました

ここまで読んでくださり、ありがとうございました。

X では短い言葉で、note では整理した文章で発信していますが、Substack では、もっと途中経過の思考や削りきらなかった葛藤、技術者として日々考えていることを書いています。

もし興味があれば、覗いてみてください。

会社員（元システムエンジニア）からフリーランスとなり、
15 年目に突入しました。

納期と障害対応に追われる毎日の中で、
「もっと自由に、もっと本質的にものづくりがしたい」
そう思ったのが独立のきっかけです。

現在は、技術と文章を軸に、
仕事がラクになる仕組みや続けられる働き方を発信しています。

あわせて読みたい

▼ 名前を約束として読み直したいときに

関数の責任と、命名の約束は表裏です。
何をしないかまで含めて信頼できる境界をつくる話です。

▼ 抽象化を変更の囲いとして捉え直したいときに

責任の単位を決めたあと、変わる部分をどう囲うかを考えるのに役立ちます。
汎用化の罠を避けたいときに。

▼ つながりを減らすことと、責任を曖昧にすることを区別したいときに

責任の境界を決めたうえで、必要な依存だけを残す視点が補強できます。

次の一歩を一緒に決める作戦会議室へ

関数の切り方や、リファクタリングの優先順位を現場向けに整理したい方もいると思います。

作戦会議室では、テンプレや設計の話を具体的に分け合える場所にしたいです。
必要なときだけ、覗いてみてください。

参加する