設計ができる人と、 できない人の違いは、 知識量ではありません。

経験年数でも、 使っているフレームワークでもありません。

違いが出るのは、 コードを書く前と後の「見え方」 です。

設計ができない人は、正しさを探す

設計がうまくいかないとき、 多くの場合、 こう考えています。

  • 正しい書き方はどれか
  • ベストプラクティスは何か
  • サンプルはどうなっているか

これは、 正解を探す思考 です。

しかし設計の世界では、 正解は一つではありません。

必要なのは、 正解探しではなく、 壊れ方を想像する力 です。

設計ができる人は、壊れ方を見る

設計ができる人は、 コードを見てこう考えます。

  • これは、どこから壊れるか
  • 判断は、どこに漏れそうか
  • 誰が、どこで迷うか

つまり、

「失敗のルート」から設計を見る

のです。

これは、 悲観的 という意味ではありません。 現実的 という意味です。

設計ができない人は、実装でカバーしようとする

判断が曖昧なとき、 設計ができない人は、

  • if を足す
  • チェックを増やす
  • テストで守る

という方向に進みがちです。

これは、 構造で解くべき問題を、実装で無理やり押し込んでいる 状態です。

一時的には動きますが、 壊れやすさは増えていきます。

設計ができる人は、判断を減らす

設計ができる人は、 逆の方向に進みます。

  • そもそも書けなくできないか
  • 間違った状態を表現できないか
  • 呼び出し順を型で縛れないか

つまり、

人の判断を、構造に引き取らせる

方向に進みます。

設計ができない人は、「あとで直す」と言う

設計が曖昧なまま進むと、 よく聞く言葉があります。

とりあえず、あとで直します

この「あとで」は、 ほとんどの場合、 来ません。

なぜなら、

  • 動いている
  • テストも通っている
  • 誰も止めていない

からです。

設計ができる人は、「今は決めない」を決める

設計ができる人は、 「決めない」ことを恐れません。

ただし、

意図して決めない

という判断をします。

  • 今は仮置き
  • ここは後で構造化する
  • 判断が出揃ってからやる

この区別がないと、 ただの放置になります。

設計ができない人は、境界をまたぐ

設計ができない人は、 境界を軽く越えます。

  • 別レイヤーの事情を知る
  • 他の責任に手を出す
  • ついでに処理を書く

その場では、 便利に見えます。

しかし、

境界を越えた瞬間に、判断が漏れる

のです。

設計ができる人は、境界で止まる

設計ができる人は、 境界で止まります。

  • これはここまで
  • それ以上は知らない
  • 知らなくていい構造にする

境界は、 不便にするためのものではありません。

判断を閉じ込めるための装置 です。

設計ができる人は、説明できる

設計ができる人は、 自分の設計を説明できます。

  • なぜこの責任なのか
  • なぜこの境界なのか
  • なぜこの制約なのか

これは、 口がうまいという意味ではありません。

判断を構造に落とした記憶がある ということです。

設計ができない人は、結果で語る

一方で、 設計ができない人は、 こう言いがちです。

  • とりあえず動いてます
  • 今のところ問題ないです
  • バグは出ていません

これらは、 設計の説明ではありません。

たまたま壊れていないだけ です。

設計ができる人は、未来の自分を見る

設計ができる人は、 常に未来を見ています。

  • 半年後の自分
  • 初めて触る人
  • 深夜に直す人

この視点があると、

  • 判断を残さない
  • 暗黙知を作らない
  • 説明がなくても読める

構造を作ろうとします。

設計ができる人は、速さを急がない

速く書くことと、 速く作れることは違います。

設計ができる人は、

  • 判断が多いところでは止まり
  • 構造が決まれば一気に書く

このメリハリがあります。

結果として、 一番速くゴールに着く のです。

この章のまとめ

設計ができる人は、

  • 正解を探さない
  • 壊れ方を見る
  • 判断を構造に移す
  • 境界で止まる
  • 意図して決めない
  • 説明できる

設計力とは、 才能ではありません。 判断を見る力と、構造に落とす習慣 です。

次の章では、 ここまでの話を踏まえて、

「なぜ、速さが価値に見えてしまうのか」

という、 最初の問いに立ち返ります。