設計の話が、なぜ噛み合わないのか

設計の話をしているはずなのに、会話がどこか噛み合わない。 そんな経験はないだろうか。

「このクラス、責務が重くないですか？」 「ここ、MVVM 的におかしくない？」 「もう少し共通化できそうですよね」

言っていることは、どれもそれなりに正しい。 しかし次の瞬間、場の空気は微妙になる。

  • なぜそれが“悪い”のか、うまく説明できない
  • 相手もなんとなく納得していない
  • 結局「今回はこのままで…」となる

設計の議論が難しいのは、知識が足りないからではない。 多くの場合、話題にしているレイヤがズレているだけだ。

私たちは「構造」について話しているつもりで、 本当はそこに含まれている 判断 について語れていない。

「良い構造」を真似ても、うまくいかない理由

世の中には、良いとされる設計がたくさんある。 レイヤードアーキテクチャ、MVVM、Clean Architecture、DDD。

それらを学び、 「正しい形」に沿ってコードを書いたはずなのに、 しばらくするとシステムはまた苦しくなる。

  • 変更のたびに広範囲を確認する必要がある
  • 触ってはいけない雰囲気のコードが増える
  • なぜこの構造なのか、誰も説明できない

これは「構造の選択を間違えた」から起きているのではない。

問題はもっと単純で、 その構造が前提としている判断と、現実の判断が一致していなかっただけだ。

設計はレシピではない。 同じ構造でも、 どんな判断を閉じ込めるために使うかによって、結果はまったく変わる。

設計とは、何をしている行為なのか

ここで、本書における設計の定義をはっきりさせておきたい。

設計とは、 不確実な判断を、どこに、どの強さで閉じ込めるかを決める行為である。

判断とは、次のようなものだ。

  • 将来、変わるかもしれない決定
  • 特定の文脈に強く依存した選択
  • あとから「間違っていた」と分かる可能性があるもの

設計が難しいのは、 これらの判断が 必ず間違える前提 で存在しているからだ。

設計の仕事は、 判断をなくすことではない。

判断が壊れたときに、 被害がどこまで広がるかを制御することにある。

判断は、コードのどこに現れるのか

「判断」と聞くと、 if 文や分岐ロジックを思い浮かべるかもしれない。

しかし実際には、 判断はコードのあらゆる場所に現れる。

  • クラスを分けたという事実
  • ファイルを分けたという事実
  • 名前を付けたという事実
  • 共通化した、しなかったという決定

たとえば、2 つのクラスを別々にした瞬間、 あなたはこう判断している。

「この 2 つは、将来別々に変わる可能性がある」

構造とは、 判断を固定化した結果の集合体 にすぎない。

判断が「にじみ出る」と何が起きるか

判断が一箇所に閉じ込められていれば、 修正は比較的容易だ。

しかし判断がにじみ出ると、状況は一変する。

  • 同じ前提が複数箇所に散らばる
  • どこを直せばよいか分からなくなる
  • 修正のたびに全体確認が必要になる

設計が壊れるのは、 新しい判断をしたときではない。

古い判断が、どこにあるか分からなくなったとき だ。

「閉じ込める」という発想

本書では、 判断を扱う方法として「閉じ込める」という言葉を使う。

閉じ込めるとは、 隠すことでも、押し込めることでもない。

  • 境界を作ること
  • 触っていい場所を決めること
  • 触ってはいけない場所を決めること

つまり、 判断に責任を持つ場所を明確にする ということだ。

もちろん、閉じ込めすぎれば身動きが取れなくなる。 このバランスについては、後の章で詳しく扱う。

この本で扱わないこと

本書は、次のようなことを目的としていない。

  • 最新フレームワークの解説
  • 正解のアーキテクチャ提示
  • テンプレート設計の紹介

本書が扱うのは、 設計の 答え ではなく、 判断の 考え方 だ。

まとめ

  • 設計は構造の話ではない
  • 設計は判断を扱う技術である
  • 問題は判断が存在することではない
  • 問題は判断が制御されていないことだ

次章では、 なぜ判断がシステムを壊すのか を、 もう一段深く掘り下げていく。