設計ができないのではなく、判断が残っていないだけ
多くの現場では、
「設計が弱い」「設計ができていない」
という言葉が使われます。
コードが複雑になっている。
変更に弱い。
触るのが怖い。
そうした状態をまとめて、
「設計の問題」と呼ぶことは珍しくありません。
ただし本書では、
この捉え方を少しだけ変えます。
多くの場合、
問題は設計そのものではありません。
判断が、残っていないのです。
設計が壊れるのは、いつか
設計が壊れる瞬間は、
突然訪れるわけではありません。
ある日いきなり破綻するのではなく、
小さな判断が、少しずつ積み重なった結果として現れます。
たとえば、
とりあえず今はこれでいい。
前からこうなっている。
あとで直せばいい。
ここまで影響しないと思った。
こうした判断自体が、
必ずしも間違っているわけではありません。
問題は、
その判断がどんな前提で行われたのかが、
コードにも、ドキュメントにも、
残っていないことです。
設計が壊れるのは、判断の理由が失われたときです。
良い設計者は、うまいコードを書いているとは限らない
設計ができる人、という言葉から、
次のような人物像を思い浮かべる人も多いかもしれません。
抽象化がうまい人。
新しいアーキテクチャに詳しい人。
きれいなコードを書ける人。
しかし本書では、
それを設計者の条件だとは考えません。
良い設計者とは、
判断を説明できる人です。
なぜこの構造にしたのか。
なぜ今はやらなかったのか。
なぜ将来の変更を見送ったのか。
それらを、
感覚や雰囲気ではなく、
後付けの理由でもなく、
当時の制約と目的を使って説明できること。
設計とは、構造ではなく、説明可能な判断です。
モノリスは、問題そのものではない
モノリスは、
しばしば問題視されます。
ただし本書では、
モノリスを悪者にはしません。
モノリスとは、
過去の判断が積み重なった結果です。
問題になるのは、
その判断が今も有効なのか分からない。
なぜそうなったのか説明できない。
変えようとしても、判断材料が残っていない。
こうした状態に陥っていることです。
問題は構造ではなく、判断の履歴が失われていることです。
構造より先に、判断がある
ここで、補足しておきたいことがあります。
本書では、
設計を「構造を作る行為」そのものとは捉えていません。
しかしそれは、
構造の重要性を否定しているわけではありません。
構造は、
設計の結果として残るものです。
どの構造を選ぶかは、
必ず何らかの判断の結果です。
以前の著作では、
「構造によって不具合が起きないようにする」
という観点を中心に扱いました。
本書は、
その一つ手前に焦点を当てています。
なぜその構造を選んだのか。
どの前提で、その判断を下したのか。
構造は成果物であり、設計そのものではありません。
再現できなかったのは、技術ではない
「この設計を採用すればうまくいく」
「この構成にすればスケールする」
そうした話を真似して、
同じことをやってみたけれど、
うまくいかなかった経験はないでしょうか。
その理由は、
技術が間違っていたからではありません。
判断の前提が、
再現されていなかっただけです。
チームの規模。
メンバーの経験。
変更頻度。
失敗の許容度。
将来の不確実性。
これらが違えば、
同じ設計が同じ結果を生むことはありません。
再現できなかったのは、判断の前提です。
この本が扱うのは「正解」ではない
本書は、
最適なアーキテクチャ。
失敗しない設計手法。
万能なリファクタリング手順。
を教える本ではありません。
本書が扱うのは、
判断の質です。
どんな制約のもとで、
何を選び、
何を捨て、
どこまで責任を持つと決めたのか。
それを、
後から説明できる形で残すこと。
設計とは、未来に対する判断である
設計は、
構造を作る行為ではありません。
設計とは、
未来に対する判断を、今下すことです。
そこには、
不確実性があります。
失敗の可能性があります。
後悔が含まれます。
それでも判断する。
そして、その判断を説明できる形で残す。
本書が扱う設計とは、その判断そのものです。
この章のまとめとして、
一つだけ述べておきます。
設計ができないのではありません。
多くの場合、
判断が残っていないだけです。
構造を見る前に、
判断を見る。
コードを見る前に、
判断の前提を見る。
次の章では、
判断がどのように散らばり、
失われていくのかについて、
もう少し具体的に見ていきます。