モヤモヤした「単一責務」の正体は「未来への問いかけ」だった　#ヌーラボブログリレー2025夏

この記事は、ヌーラボブログリレー2025夏 の19日目として投稿しています。

はじめに

こんにちは！今年の春からヌーラボの一員になりました！入社して早半年、毎日が刺激的で、あっという間に時間が過ぎていきました。

さて、今回はブログリレーということで、私がこの半年間で特に「なるほど！」と膝を打ったソフトウェア設計の原則についてお話ししようと思います。テーマは、多くの方が一度は聞いたことがあるであろうSOLID原則のS 単一責任原則 :Single Responsibility Principle です。

AI時代に突入し、ソフトウェア開発の現場も大きく変わりつつある今だからこそ、改めてこういった原則の本質を理解することが重要だと感じています。AIの活用が進む中でも、最終的な判断や設計の質を担保するためには、人間によるレビューが不可欠であると強く思います。

単一責任原則の「単一責務」って、結局どこからどこまで？

普段のコードレビューや会話で頻繁に登場するこの言葉。「1つのクラスは1つの責任だけを持つべき」という説明は理解できるものの、「じゃあ、その単一責務って具体的にどこからどこまでなの？どこで分けるべきなの？」と、ずっとモヤモヤを抱えていました。

そんな中、『ちょうぜつソフトウェア設計入門』という本を読み、この長年の疑問が自分の中でスッキリと整理できたので、その学びを皆さんと共有したいと思います！

「責務」の正体は「変更が求められる理由」だった

単一責任原則を難しくしているのは、まさに「責務」という言葉の曖昧さです。たとえば「どこまでを一つの責任とみなすか」「どこで役割を分けるか」といった線引きが人によって違い、明確な基準が分かりにくいですよね。

この本では、責務とは「変更を求められる理由」であると、非常にシンプルに定義されていました。

つまり、「将来、どんな理由でこのコードに変更が入るだろう？」と想像することが、責務の範囲を見極めるための最大のヒントになる、ということです。この視点を得たとき、腑に落ちて、すっと納得できました。

CASE1：分けるべき責務 〜ニュースサイトの記事操作〜

本書で紹介されている「ニュースサイトの記事を扱うシステム」の例が非常に分かりやすかったので、ご紹介します。

このシステムには、記者が記事を「入稿」する機能と、読者が記事を「購読」する機能があります。これらは「記事を操作する」という点で、一つのクラスにまとめたくなるかもしれません。
（特にオブジェクト指向の設計では、1つのクラスに記事の操作をまとめて持たせる設計が、自然に思えることが多いです。）

しかし、ここで「変更が求められる理由」を想像してみましょう。

• 入稿機能の変更理由

  • 「新しい編集ツールを導入したい」
  • 「記事の承認フローを変更したい」
  • 主体は「記者」や「編集者」

• 購読機能の変更理由

  • 「読者向けにレコメンド機能を追加したい」
  • 「記事の表示形式を改善したい」
  • 主体は「読者」や「サービス企画者」

このように、変更を求める人（アクター）も、その背景（コンテキスト）も全く異なります。もしこれらを一つのクラスにまとめてしまうと、記者の都合で行った変更が、全く関係ない読者向けの機能に意図せず影響を与えてデグレてしまうリスクが生まれます。

したがって、この場合は「入稿」と「購読」をそれぞれ別の責務として扱い、クラスを分割するのが賢明な判断と言えます。

CASE2：まとめるべき責務 〜データベースドライバ〜

逆に、一見すると別々の機能に見えても、まとめるべきケースも存在します。その例が、データベースドライバの「書き込み（Write）」と「読み取り（Read）」の機能です。

これも同様に「変更が求められる理由」から考えてみましょう。

データベースの書き込みと読み取りの仕様が変更されるのは、どのような時でしょうか？多くの場合、それは「データベース自体のバージョンアップ」や「基盤となる仕様の変更」が原因です。つまり、書き込みと読み取りは、同じ理由で、同時に変更される可能性が極めて高いのです。

もし、これらを別々のドライバとして提供してしまうと、開発者が誤ってバージョンの異なる組み合わせ（例：書き込みドライバ v2.1 と 読み取りドライバ v2.0）で利用してしまうかもしれません。これは、発見が困難なバグの温床になりかねませんよね。

このケースでは、「書き込みと読み取りを分離できる」というメリットよりも、「バージョンを明確に区別し、常に一貫性を保てる」というメリットが優先されます。そのため、「データベースとの通信」という一つの責務として、これらをひとまとめに扱う方が合理的、という意思決定になるわけです。

まとめ：未来を想像する力が、より良い設計につながる

『ちょうぜつソフトウェア設計』を読んで学んだ最も重要なことは、単一責任原則とは、単にコードの構造を綺麗に保つためのルールではなく、「将来どんな理由で変更が起こりうるか」というビジネスやチームの文脈を想像し、未来の変化に強いソフトウェアを築くための指針である、ということでした。

ヌーラボが提供するBacklogやCacooといったプロダクトも、世界中の様々なチームの多様な働き方に合わせて、日々進化を続けています。そうした変化に対応し続けるためには、一つ一つの機能がどのような理由で変更されうるのかを想像し、責務を適切に分離・集約していく視点が不可欠だと、改めて実感しました。

まだまだ設計の世界は奥が深く、学ぶことばかりですが、この「変更理由を想像する」というコンパスを手に、これからも探求を続けていきたいと思います。