測らずに直さない——クヌースの警句の、正しい読み方

「ここ、遅い気がするので直しておきました」——本人は良かれと思っていても、直した箇所が実は遅くなかった、という報告を見たことはないでしょうか。

「最適化するな」ではない

クヌースの「早すぎる最適化は諸悪の根源」は、最適化そのものを否定した言葉ではありません。原典（1974年）には続きがあって、「小さな効率については、97%の場面で忘れるべき」としつつ、「残り3%の決定的な機会を逃してはならない」とも書いています。否定されているのは最適化ではなく、測らずにやることです。一文だけが独り歩きした典型例です。

桁の感覚があれば、疑う場所が先に分かる

メモリ参照はナノ秒、SSDはマイクロ秒、ネットワーク越しの通信はミリ秒——桁が3つずつ違います。この感覚を持っていると、「遅い」と言われた瞬間に、まず疑うのはループの中の通信やクエリだと見当がつきます。正確な数字は要りません。桁だけで、探す順番が決まります。

障害対応でも、同じ構造がある

障害対応で「まず動かす」か「まず原因を追うか」で流儀が分かれるのも、根っこは同じ話です。原因を確かめずに直すと、直したつもりの箇所が実は無関係だった、ということが起きます。「まず動かす」派と「まず原因」派、本番障害の初動、どちらも「測る・確かめる」を土台に置いている点は共通しています。

常駐先で効く場面

常駐先で性能の指摘を受けたとき、「感覚で直した」報告は信用を削ります。測った数字を一言添えるだけで、次から性能の話を任される側になります。逆に、測らずに直して的外れだったことが続くと、その現場では性能の相談自体が来なくなります。

こうした「知っていると判断が変わる」原則は、エンジニアの型の問題集にまとめてあります。