多くの現場で、 こんな評価がされがちです。

  • 早く実装できる人は優秀
  • 手が止まらない人は頼りになる
  • とりあえず動くものを出せる人が強い

設計よりも、 速さが価値として見える瞬間 です。

なぜ、 こうなってしまうのでしょうか。

速さは、目に見える

まず、 速さはとてもわかりやすい指標です。

  • 何日でできたか
  • どれくらいの量を書いたか
  • すぐに画面が動いたか

これらは、 誰の目にも見えます。

一方で、

  • 判断が構造に閉じ込められているか
  • 責任がきれいに分かれているか
  • 将来の変更に耐えられるか

といった設計の価値は、 その場では見えません。

設計の価値は、時間差で現れる

設計の良し悪しは、 あとから効いてきます。

  • 仕様変更が入ったとき
  • 人が入れ替わったとき
  • 想定外の使われ方をしたとき

その瞬間に初めて、

  • 修正が一瞬で終わる
  • 影響範囲が限定されている
  • 原因がすぐに特定できる

といった差が現れます。

つまり、 設計は未来のための仕事 です。

人間は、未来の価値を割り引く

ここに、 人間の認知の癖があります。

人は、

  • 今すぐ得られる成果
  • 目の前の評価
  • 今日怒られないこと

を優先しがちです。

半年後の自分の苦労より、 今日の「進んでいる感」の方が、 強く感じられます。

その結果、 設計より速さを選んでしまう のです。

「まず動くものを作る」は、間違いではない

ここで、 大事な補足があります。

「まず動くものを作る」 という考え方自体は、 間違いではありません。

むしろ、

  • 要件が曖昧な段階
  • 正解がまだ見えていない段階
  • 問題空間を理解する段階

では、 動くものがないと、設計できない ことも多いです。

いきなり、 最初からリファクタリング不要なコードを書くのは、 シニアでもほぼ不可能です。

問題は、「速さで止まってしまう」こと

問題は、

  • 速く作ること ではなく
  • 速く作ったまま止まってしまうこと

です。

プロトタイプのはずが、 いつの間にか本番コードになり、

  • 判断が散らばり
  • 責任が混ざり
  • 構造が育たない

まま、機能だけが増えていきます。

速さは、設計を先送りにする免罪符になる

「今は速さが大事だから」 という言葉は、

  • 設計をしない理由
  • 判断を曖昧にする理由
  • 境界を越える理由

として使われがちです。

しかしそれは、 設計をしないことを正当化しているだけ かもしれません。

本当に速い人は、止まれる人

皮肉なことに、 本当に速い人ほど、 よく止まります。

  • 判断が増え始めたところで止まる
  • 構造が崩れそうなところで止まる
  • このまま進むと壊れると気づいて止まる

その上で、

  • 判断を構造に戻し
  • 責任を分け直し
  • 境界を引き直す

だから結果的に、 全体として一番速い のです。

設計は、速さを否定しない

この本は、 速さを否定しません。

ただし、

  • 速さだけを評価しない
  • 速さで設計を潰さない
  • 速さの裏にある判断を見る

ことを勧めています。

設計とは、 スピードを落とす行為ではありません。 スピードを維持できる構造を作る行為 です。

この章のまとめ

  • 速さは、目に見える価値
  • 設計の価値は、時間差で現れる
  • 人は未来の価値を過小評価する
  • 「まず動くもの」は間違いではない
  • 問題は、速さで止まってしまうこと
  • 本当に速い人は、設計のために止まれる人

次の章では、 この本全体を締めくくる形で、

「では、設計とどう向き合えばいいのか」

という実践的な話に進みます。