早すぎる最適化 — 測る前に速さを追う

「ここはループだから速く書いておこう」「文字列結合は遅いと聞いたから」——良かれと思って書いた最適化が、実は何の役にも立たず、ただコードを読めなくしているだけ。これが早すぎる最適化です。

横にスクロール

症状：どう気づくか

• 「なぜこんな書き方？」と聞くと、「速いと思って」という答えが返る（実測データは無い）。
• ホットパスでもない場所に、技巧的で読みにくいコードがある。
• ベンチマークやプロファイルの結果がどこにも無いまま、性能を理由にした設計判断がされている。

なぜ悪いのか

プログラムの実行時間は、ごく一部のコードに集中しています。経験則としてよく言われるのが「時間の8割は2割のコードで消費される」。つまり、大半の場所をいくら磨いても全体はほとんど速くならない。

早すぎる最適化は、その「効かない8割」に労力を注いでしまう行為です。しかも代償が二重にかかります。ひとつは、効かない最適化に費やす時間そのもの。もうひとつは、可読性の犠牲です。技巧的なコードはバグを生みやすく、後から読む人（半年後の自分を含む）の理解を妨げ、保守コストを恒久的に上げます。速くならないのに、負債だけが残る。

直し方

順番を守るだけです。

1. まず素直に、正しく書く。 読みやすさを優先し、動くものを作る。
2. 計測する。 プロファイラで、実際にどこで時間を使っているかを測る。推測しない。
3. ボトルネックだけ最適化する。 測って見つかった上位の箇所に絞って手を入れる。
4. 再計測する。 本当に速くなったか、数字で確認する。効いていなければ戻す。

やりがちな順番（誤）:  推測 → 最適化 → （効かない・読めない）
正しい順番:            計測 → ボトルネック特定 → そこだけ最適化 → 再計測

まとめ

• 早すぎる最適化とは、計測せず勘で速そうなコードを書くこと。時間の大半はごく一部に集中しているのに、効かない場所を磨いてしまう。
• コストは二重。効かない労力と可読性の犠牲（将来のバグ・保守負債）。
• 正しい順番はまず正しく書く→計測→ボトルネックだけ最適化→再計測。推測でなく測定で動く。
• ただしアルゴリズムや計算量の設計判断は最初から。局所的な小細工だけを先回りしないこと。