多くの現場では、 「速く書けるエンジニア」が高く評価されます。

短期間で動くものを作れる。 仕様変更にもすぐに対応できる。 多少バグが残っていても、とりあえず形にできる。

こうした姿は、 一見するととても頼もしく見えます。

実際、 プロジェクトの初期段階や、 期限が迫った場面では、 速さが価値を持つこともあります。

ただし本書では、 速さが絶対的な価値であるとは考えていません。

なぜ「速さ」は評価されやすいのか

速さが評価される理由は、 とてもシンプルです。

速さは、目に見えるからです。

  • 何日で終わったか
  • 何機能実装できたか
  • どれだけ早くリリースできたか

これらは数値として観測できます。

一方で、 設計の良し悪しは、 すぐには見えません。

設計の差が表に出るのは、

  • 仕様変更が入ったとき
  • メンバーが入れ替わったとき
  • 数か月、数年が経過したとき

です。つまり、

  • 速さは「今すぐ評価できる価値」
  • 設計は「後から効いてくる価値」

だと言えます。

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

ここで、一つはっきりさせておきたいことがあります。

本書は、 「まず動くものを作る」 こと自体を 否定しているわけではありません。

要件が曖昧な段階で、 いきなり完成形の設計を書くことは、 シニアエンジニアであっても難しいと思います。

まず動くものを作ることで、

  • 他の実装と比較できる
  • 問題の輪郭が見える
  • 本当に難しい部分が浮かび上がる

ということは、確かにあります。

この段階のコードは、 思考のラフスケッチ です。

問題は、そのラフスケッチを 完成した設計 だと誤認してしまうことにあります。

速く書かれたコードが抱える問題

速く書かれたコードは、 多くの場合、次のような特徴を持ちます。

  • 一ヶ所修正すると、影響が爆発的に発生する
  • 一つの部品が複数の責任を負っている
  • 影響確認が人の注意力に委ねられている
  • 変更時に、どこを直せばよいかわからない

これらは、 「書いた人が賢いから私にはわからない」 「書いた人がわかるなら私にもわかるはず」 という問題ではありません。

暗黙の前提が、コードの外にある可能性があります。

結果として、 その人がいなくなると壊れるコード が生まれます。

速さが生む「負債」は、あとからやってくる

速さを優先して書かれたコードは、 最初は軽く、扱いやすく見えます。

しかし時間が経つにつれて、

  • 小さな修正に時間がかかる
  • 触ってはいけない場所が増える
  • 誰も全体を把握できなくなる

といった状態に変わっていきます。

これは、 過去に支払わなかった設計のコストを、 後からまとめて支払っている状態です。

速さは、 時間を節約しているように見えて、 未来の時間を前借りしている ことがあります。

設計は「速さ」と対立するものではない

設計は、 速さの対極にあるものではありません。

良い設計がされたコードは、

  • 変更の影響範囲が小さく
  • 安心して触ることができ
  • 結果として作業が速くなります

ただしそれは、 最初の一瞬の速さ ではなく、 長く続く速さ です。

この違いは、 短期的な評価指標では測れません。

だからこそ、 設計の価値は見落とされやすいのだと思います。

この章のまとめ

速さには、たしかに価値があります。

しかしその速さが、

  • 構造によって支えられているのか
  • 人の頑張りによって成り立っているのか

を見極める必要があります。

本書が扱う設計は、 後者を前者に変えるためのものです。

次の章では、 速さの裏側で起きている 「判断の散在」 について、 もう少し具体的に見ていきます。