改善を止めないために必要なもの

第6章で見たように、
最初の一手は「判断を動かす」ことから始まります。

この一手がうまくいくと、
現場では次に、こんな感覚が生まれます。

「もう少し、ここも直せそうだ」
「次は、あの判断も整理できそうだ」

設計改善が、
連鎖し始める瞬間 です。

しかし、この連鎖は、
意外と簡単に途切れます。

連鎖が途切れる典型的な瞬間

連鎖が止まるのは、
多くの場合、次の判断をしたときです。

「今の流れで、
　まとめて構造も整理してしまおう」

判断を一つ動かせた成功体験があると、
つい、こうしたくなります。

  • クラス構成を整理する
  • パッケージを切り直す
  • 似た責務をまとめる
  • 命名を一気に整える

結果として、
コードはきれいになります。

しかし、
ここで一気に構造を触ると、
改善の連鎖は途切れます。

なぜ一気に触ると、連鎖が止まるのか

理由は単純です。

判断の変化が、追えなくなるからです。

判断を一つだけ動かした場合

たとえば、
第6章で扱ったように、

  • 散らばっていた if の判断を
  • SpecialDiscountPolicy に集めた

この変更は、
とても説明しやすい状態です。

「特別割引という判断を、
　このクラスに置きました」

  • 何が変わったのか
  • なぜ変えたのか
  • どの判断を動かしたのか

が、
一文で説明できます。

変わった判断が、ひとつだけ
だからです。

変更が重なると、因果が見えなくなる

一方で、
次のような変更を同時に行った場合を考えてみてください。

  • 判断を切り出した
  • クラスを分割した
  • パッケージを整理した
  • util を削除した

コードの見た目は、
確実に良くなっています。

ですが、
ここでこう聞かれると、どうでしょうか。

「なぜ、この構造になったんですか？」

多くの場合、
答えがこうなります。

「判断を整理した結果で……
　ついでに構造も見直して……
　全体的にきれいにしました」

これは、
説明できているようで、できていません。

「追えない」とは、どういう状態か

ここで言っている
「判断の変化が追えない」とは、

  • どの判断が起点だったのか分からない
  • この構造が、どの判断に対応しているのか説明できない
  • diff を見ても、意図が読み取れない

という状態です。

設計の変更が、

  • 「なぜそうなったか」ではなく
  • 「そうなっている」という結果

だけを残してしまいます。

これはつまり、

判断の履歴が、消えてしまった状態
だと言えます。

連鎖が続く条件は「因果が見えること」

改善が連鎖するためには、
次の対応関係が、常に見えている必要があります。

  • この変更で
  • この判断が
  • ここに置かれた

この 1 対 1 の因果が、
誰の目にも明らかであること。

一気に構造を触ると、

  • どの判断が前進を生んだのか
  • 次は、何を基準に直せばいいのか

が分からなくなります。

その結果、
次の一手が選べなくなる。

これが、
「連鎖が途切れる」という現象の正体です。

チームでは、さらに問題が大きくなる

この問題は、
チーム開発では、より深刻になります。

  • レビューで意図が共有できない
  • 「とりあえずきれいにした変更」に見える
  • 次に触る人が、元の if を復活させる

つまり、
判断が再び漂流し始める のです。

「良くなったはずなのに、戻ってしまう」

多くの現場で起きているこの現象は、
技術力の問題ではありません。

判断の因果が、
コードに残っていないだけ です。

改善を止めないためのルール

改善を連鎖させたいなら、
守るべきルールは、実はとてもシンプルです。

  • 1 回の変更で
  • 動かす判断は 1 つ
  • 説明は 1 文でできる

この状態を保てていれば、
設計改善は自然に続いていきます。

この章のまとめ

改善が止まるのは、
難しいことをしているからではありません。

何を変えたのかが、
分からなくなるからです。

判断を一つ動かす。
その因果を、コードに残す。

この積み重ねが、
モノリスを少しずつ、
しかし確実に変えていきます。

次の章では、
この判断の連鎖を
個人の感覚ではなく、チームの共通理解にする方法
について扱います。