この記事で言いたいこと

エンジニアとしての「正しさ」と、 会社としての「合理性」は、必ずしも一致しない。

そして多くの現場で、 過剰設計は「善意」で始まり、「負債」として残る。

この記事は、 限られたリソースで戦う会社のエンジニアとして、 どこで割り切るか・何をやらないか についての整理です。

僕たちはマイクロソフトではない

まず前提として。

  • 無限の開発者がいるわけでもない
  • 専任SREがいるわけでもない
  • 失敗しても許される資本力があるわけでもない

多くの会社は、 限られた時価総額・限られた人員・限られた時間 の中で戦っている。

それなのに、

  • 将来スケールする前提の設計
  • まだ存在しない要件への備え
  • 理想的すぎるアーキテクチャ

を最初から持ち込むと、 その瞬間に 会社の体力を削り始める。

過剰設計は、なぜ起きるのか

過剰設計の多くは、悪意ではなく エンジニアの誠実さ から生まれる。

  • 将来困らせたくない
  • 技術的に正しいことをしたい
  • 後から怒られたくない
  • 「わかってない」と思われたくない

気持ちはわかる。 でも、ここに落とし穴がある。

「将来のため」は、今のビジネスを犠牲にしていい理由にはならない

ビジネス合理性という視点

ビジネス合理性とは、 売上・コスト・リスク・速度 を天秤にかけること。

例えば：

  • 今月リリースできないと失注する
  • 運用できる人が限られている
  • 修正コストより、作り直した方が安い
  • スケールする前に撤退する可能性もある

こうした現実の中で、

「技術的に美しいか」 より 「今、この会社にとって得か」

を優先する判断が必要になる。

「正しい設計」より「戻れる設計」

私が意識しているのは、 完璧な設計 ではなく、戻れる設計。

  • 作り直せる
  • 捨てられる
  • 影響範囲が小さい
  • 理解できる人が多い

これは、 スケールしない設計ではなく、 失敗しても立て直せる設計 だと思っている。

エンジニアの価値は「技術」だけじゃない

限られた環境では、 エンジニアの価値はコード量では測れない。

  • どこを作らないと決めたか
  • どこで割り切ったか
  • 誰が運用できるかを考えたか
  • 会社の体力を理解しているか

これらは、 コードレビューでは見えにくいけれど、 事業にとっては非常に重要な能力だと思っている。

まとめ：合理性は「逃げ」ではない

  • 過剰設計は優しさから生まれる
  • でも、会社を苦しめることもある
  • 僕たちはマイクロソフトではない
  • 限られたリソースで勝つ必要がある

だから私は、

エンジニアのエゴより、 ビジネス合理性を優先する判断をしたい。

それは妥協ではなく、 現場で生き残るための選択だと思っている。

関連記事