Zenn
🔖

【独り言】コードが生み出す価値と単一責務を結びつける

に公開
architecture
idea

ソースコードに対して責務という単語がいまいちしっくりこなかったので、そこをベースに単一責務がなぜ大事なのかまでを考えてみました。また、この考えを言語化することでclaude codeの力をどれほど引き出せるのか？という問いに対する実験という側面もあり、その言語化フェーズに位置する記事でもあります。

責務とは何か？

第一に責務とは何かを考えました。googleで責務と検索したところ以下のように検索結果に表示されました。

責任と義務。義務を果たすべき責任。

では責任と義務とは何でしょうか？一度整理します。

義務

法律上または道徳上、人や団体がしなくてはならない、また、してはならないこと。

責任

人や団体が、なすべき務めとして、自身に引き受けなければならないもの。

ここまでで「責務」「義務」「責任」という単語がそろいました。これらについてソフトウェアの開発のシーンにおいて再解釈をしていきます。

義務について

「ソフトウェアはなんらかの価値を生み出すもの」という前提に立ったとき、私は以下のように解釈しました。

「人」=「ソースコード(メソッドやクラスといった単位)」
「団体」=「ソフトウェア」
「しなくてはならない」=「生み出さなければいけない価値」
「してはならない」=「生み出してはいけない価値」

まとめると以下のようになりました。

法律上または道徳上、ソースコード(メソッドやクラスといった単位)やソフトウェアが生み出さなければいけない価値、また、生み出してはいけない価値のこと。

責任について

こちらも「ソフトウェアはなんらかの価値を生み出すもの」という前提に立ち、以下のように解釈しました。

以下は先ほどと変わらずです。
「人」=「ソースコード(メソッドやクラスといった単位)」
「団体」=「ソフトウェア」

以下は少し変わってきます。義務との補完関係で意味を持つ一文だと思っています。
「なすべき務めとして、自身に引き受けなければならないもの」

なので、まとめると以下のようになります。

ソースコード(メソッドやクラスといった単位)やソフトウェアが、なすべき務めとして、自身に引き受けなければならないもの。

「自身に引き受けなければならない」と書いていますが、引き受けなくて良いものについての言及はありません。これも仮説ですが、こういった言葉から受ける影響として、引き受けなくても良いものというカテゴリが人の意識の中にないことが、単一責務という形で人に意識させるためのカテゴリを生み出したともいえるのでしょうか？これに関しては、もはや仮説通り越した妄想な気もします。

単一責務の重要性

ここまでで、責務という単語についての言語化をしました。辞書からとってきた意味をベースに言語化しているので当たり前かもしれませんが、この言語化したものの中にはソフトウェアを継続的に開発し続けるための指針となるようなニュアンスは含まれていないと感じています。

とりあえず、例としてECサイトのカート機能を考えます。在庫がある商品をカートに入れると在庫から一つ消える。そして自分のカートにその商品が1つ増えるという機能です。

この機能をざっくり設計したとして、以下のようなレイヤーに分けられるのではと考えます。
とりあえず

controllerにはバリデーションであったり、ドキュメントコメントであったりを書いたりされていて、serviceでいえばさっき書いた「在庫がある商品をカートに入れると在庫から一つ消える。そして自分のカートにその商品が1つ増える」というロジックがもろここで表現していて、repositoryでは実際にデータベースのデータを操作するための処理が書かれているというのが想定できます。

ここで、controller/service/repository それぞれの層が何を生み出しているかを整理すると以下のようになります。

  • controller
    • 「UIと本質的価値をつなぐ」という価値を生み出している
  • service
    • 「こんなのが欲しいな～と思ったそれそのもの(本質的価値)」を生み出している
  • repository
    • 「システムと本質的価値をつなぐ」という価値を生み出している

雑に考えて例えばこの構成で、カートの仕様を変えたいとなれば「service(本質的価値)」のコードの変更がまずあり、その後、このserviceを成立させるための価値を生むコードの修正が決まるかと思います。
1価値 = 1責務 となっていることで、各修正もわかりやすいものになるかと思いますし、迷いがなくなるのではないか？という仮説があります。

雑文

ソフトウェアの新規開発は新しい価値を生み出す行為、バグ修正や仕様変更などは価値を生み出せていない、もしくはユーザーの都合で今ある価値を違う形に変えなければならないというときに、それに追従する行為だとみなしています。
なぜここまでわざわざ言語化したのかいというと、これが単一責務の重要性と結びつくと考えているからです。例えば、バグ修正は本来生み出しているはずの価値を生み出せていない状態で、どこで価値が生み出せていないのかを特定し、修正する行為。仕様変更は、今ある価値を変更する行為。このように考えたとき、「ソフトウェアの設計 = 価値を成立させる構造」という理想を達成すると、ユーザーの要望から自然と設計が出来上がるという理想論ももしかしたらあるのかもという仮説があります。そして、この理想は単一責務から始まるとしたら、単一責務はかなり重要なものに位置づけられるという風に考えています。

この場合の単一責務は、「1つの価値 = 1つの責務」としているので提供する価値が違えばコードの字面は一緒でも共通化しないという方針になります。この辺りはコードをいくつか実際に書いてみて、本当にこれで良いのかの検証は必要かなと思います。

最後に

思いついたことをすごい雑に書いているので伝わりづらいと思いますし、そもそもこれが有効な考えなのかというのもわかっていません。
なので、この理論・解釈を検証するために個人開発をしていきたいところ。

Discussion