【コード哲学エッセイ】 依存は 「少ない」 が正義じゃない —— 必要なつながりを恐れない設計

「依存は少ないほどいい」
「疎結合にしろ」

本を読んでも、先輩の口からも、そう言われてきました。
僕は長いあいだ、それを正義だと思っていました。

「少ない」 に酔っていた頃

クラス同士の参照を減らす。
モジュールの境界を厚くして、中身を見せない。
インターフェースを挟んで、直接つながらないようにする。

どれも、悪いことではありません。
むしろ、多くの場面で役に立つ考え方です。

問題は、「依存を減らすこと」それ自体が目的になってしまったときでした。

「ここ、直接参照してる。依存が増える。まずい」
「このふたつ、つながりが強い。切り離さなきゃ」

そう考えて、無理に層を挟んだり、別モジュールに追いやったりしていました。
結果、どこに何があるか分かりにくくなり、変更するたびに三箇所を触る羽目になる。
「依存」は減った数字のうえでは減った。
でも、読む人にとってのつながりは、かえって見えにくくなっていたのです。

必要なつながりまで、 断っていた

転機は、自分が「きれいに分離した」つもりのコードを、半年後に読み返したときでした。

「この処理、なんでこのモジュールにあるんだっけ？」
「ここからあそこを呼ぶのに、なんでこの層を経由してるんだ？」

当時の僕は、「依存を減らす」ことに必死で、「このふたつは本来、強い関係にある」という事実から目を背けていました。
本来つながっていてよいものまで、無理に引き離していた。
それで、見た目上の依存数は減ったけれど、概念的なつながりは残ったままで、コードのあちこちに「なぜここに？」という違和感が残る設計になっていたのです。

必要なつながりを恐れて、不自然に切り離す。
その代償は、未来の自分が「どこに何があるか」を理解するコストとして、しっかり返ってきました。

「少ない」 ではなく、 「必要なのか」 を問う

いま、僕はこう考えるようにしています。

依存の「数」ではなく、「そのつながりは必要か」を問う。

📍 この参照は、 domain と usecase のあいだに本当に必要なつながりか。
📍 このふたつを無理に分離すると、変更のときにかえって苦労しないか。
📍 「依存が少ない」ことと、「読みやすく変更しやすい」ことは、同じか。

「少ない」が正義だと信じていた頃の僕は、つながりそのものを悪だと思っていました。
でも、悪いのは「無自覚な依存」や「変更の影響が読めない依存」であって、必要なつながりを明示的に保つことではない。

むしろ、「ここはつながっている」と設計としてはっきりさせておくことのほうが、未来の読者（自分を含む）には優しい。
隠してごまかすより、必要なつながりを恐れず、名前と責任の範囲をはっきりさせておく。

そう思うようになってから、無駄な層を減らし、「ここはこのふたつがセットで動く」と宣言できる設計を選ぶことが増えました。
依存の数は、かえって「必要なもの」に絞られて、読みやすくなった気がしています。

設計は、 つながりを 「恐れない」 選択でもある

「依存は少ないほどいい」—— その一言に、僕たちは安心感を覚えがちです。
でも、少なさそのものが正義なのではなく、どのつながりを残し、どのつながりを断つかの「判断」が設計なのだと、僕は思います。

必要なつながりを恐れず、責任の範囲をはっきりさせておく。
不要な依存は、本気で減らす。

その両方をやるからこそ、未来の自分も、同じコードを開く誰かも、迷わずに済む。
依存は「少ない」が正義じゃない。
必要なつながりを恐れない設計が、僕たちを助けてくれるのです。

あわせて読みたい

▼ 「速さ」以外の正義を知りたいときに

速さを手放し、設計という優しさを選ぶ。
未来の自分を守る考え方です。

▼ コメントに「意図」を残したいときに

コードが語る「結果」と、コメントが語る「意図」を分ける。
未来の読者への手紙の書き方です。

▼ 名前の付け方に「約束」の視点を持ちたいときに

変数名や関数名を「約束」として扱う。
未来の自分を裏切らない命名の考え方です。

ひとりごと

「依存を減らせ」と呪文のように唱えていた頃の設計を、今でも時々見返します。

層だらけで、何がどこにいるか分かりにくい。
あのとき怖れていたのは「依存」ではなく、「自分で判断すること」だったのかもしれません。

必要なつながりを恐れない。
その一言が、いまの僕の設計の軸のひとつになっています。