第1章では、設計とは「判断」を扱う行為である、という前提を置いた。

では次に浮かぶ疑問は、こうだろう。

なぜ判断は、システムを壊すのか。

判断は必要なものだ。 それなのに、なぜ判断が増えるほど、 コードは触りづらくなっていくのか。

この章では、 判断そのものが悪いわけではない という事実から出発し、 それでもシステムが壊れていく理由を丁寧に掘り下げていく。

判断は「悪者」ではない

まず、はっきりさせておきたい。

判断は、設計において避けるべきものではない。

「判断が多いコードは悪い」 「ロジックは少ないほうがよい」

こうした言葉は、しばしば聞かれるが、 それは半分しか正しくない。

判断がなければ、ソフトウェアは振る舞えない。 要件を満たすこともできない。

問題は、 判断が存在することではなく、 判断が制御されていないこと だ。

判断は、必ず寿命を持つ

すべての判断には、寿命がある。

  • 今は正しいが、将来は分からない
  • この前提が崩れたら成立しない
  • 別の文脈では通用しない

それでも私たちは、 あたかもその判断が永遠に正しいかのように、 コードに埋め込んでしまう。

設計が壊れ始めるのは、 判断の寿命が尽きた瞬間だ。

しかし実際には、 その瞬間がはっきりと分かることは少ない。

少しずつ前提がズレ、 少しずつ例外が増え、 気づいたときには全体が歪んでいる。

判断が「広がる」ときに起きること

判断が一箇所に閉じ込められていれば、 その寿命が尽きても、修正は局所的で済む。

しかし判断が広がっていると、 話はまったく変わる。

  • 同じ判断が、複数の場所に存在する
  • 微妙に違う形でコピーされている
  • どれが本体か分からない

この状態では、 一つの判断を変えることが、 システム全体を揺るがす行為になる。

結果として、 誰も判断を変えられなくなる。

「変更が怖い」という感覚の正体

現場でよく聞く言葉がある。

「この辺、変更すると影響範囲が分からなくて…」

これは、技術力不足の告白ではない。 設計上の問題だ。

変更が怖いとは、 判断がどこにあるか分からない という状態を指している。

  • 触る前に全体を読む必要がある
  • テストがあっても安心できない
  • レビューでも確信が持てない

こうしてコードは、 徐々に「触れない領域」へと変わっていく。

判断は、静かに増殖する

判断が怖いのは、 増えていることに気づきにくい点にある。

最初は、 「このケースだけ特別に」 という一行の if かもしれない。

しかしその判断が閉じ込められていなければ、 同じ前提が別の場所でも必要になる。

やがて、 似たような分岐が点在し、 少しずつズレたロジックが生まれる。

誰も全体像を把握できなくなったとき、 システムはすでに壊れ始めている。

再利用が判断を壊す瞬間

再利用は、善であるかのように語られることが多い。

しかし再利用は、 判断を壊す強力なトリガーにもなり得る。

本来、特定の文脈でのみ成立していた判断が、 別の文脈に持ち込まれる。

その結果、

  • 例外対応が増える
  • フラグやオプションが増える
  • 呼び出し側の責務が曖昧になる

再利用が問題なのではない。

判断のスコープを超えて使われること が問題なのだ。

判断が壊れると、構造も壊れる

判断が歪み始めると、 それを支えている構造も耐えきれなくなる。

  • 責務が曖昧になる
  • 境界が曖昧になる
  • クラス名が実態を表さなくなる

こうなると、 構造を直そうとしても、うまくいかない。

なぜなら、 壊れているのは構造ではなく、 その中に閉じ込められているはずだった判断 だからだ。

まとめ

  • 判断そのものは悪ではない
  • 判断には必ず寿命がある
  • 判断が広がると、変更は恐怖になる
  • 再利用は、判断を壊す引き金になり得る
  • 構造が壊れる前に、判断はすでに壊れている

次章では、 こうした問題に対して、 判断をどのように閉じ込めるのか を、 具体的な技術として扱っていく。