ここまで11回、計測から判断まで扱ってきました。区切りとして、よく見る失敗を裏側から整理します。
各項目は「何を誤解しているか」と「どう戻すか」の形で書きます。どれももっともらしい理由があって発生するもので、責める意図はありません。
1. 測らずに直す
症状: 「たぶんここが遅い」から始まり、直したが変わらない。あるいは変わったが理由が説明できない。
誤解: 経験があれば当たる、という前提。 の位置は直感に反することが多く、特に待ちが支配的なシステムでは計算量の直感が当たりません。
戻し方: EP.1 の順序に戻る。外側から内側へ、割合を確認しながら降りる。測るのは改善の前提ではなく、改善の一部です。
2. 平均だけを見る
症状: 平均応答時間は目標内なのに、利用者から遅いという声が続く。
誤解: 平均が全体を代表している、という前提。実際には少数の極端に遅いケースを隠します。データ量の多い顧客だけが破綻している、という形で現れます。
戻し方: を併せて見る。平均と p95 が大きく離れているなら、それ自体が調査対象です。
3. 本番と違う条件で判断する
症状: 手元では速い。試験でも通った。本番で遅い。
誤解: 環境差は誤差の範囲だ、という前提。実際にはデータ量と分布の差が、処理の経路そのものを変えます。件数が少ないとデータベースは別の方法を選びます。
戻し方: EP.10 のとおり、データ量とデータの偏りを最優先で揃える。均等なテストデータは最も危険で、極端なケースが存在しないため必ず通ります。
4. 局所最適に時間を使う
症状: 細かい非効率を丁寧に直したが、全体の所要時間はほとんど変わらない。
誤解: 非効率は直すべきだ、という一般論。直しやすさと、効くかどうかは別です。全体の1%を占める箇所を半分にしても、全体は0.5%しか改善しません。
戻し方: 割合の大きい順に処理する。調べていると細かい非効率が次々目につきますが、そこを我慢するのが EP.2 の要点でした。
5. 並列化から入る
症状: 台数や並列度を増やしたが、期待した倍率にならない。費用だけが増えた。
誤解: 並列化は万能だ、という前提。 のとおり、並列化できない部分の割合が上限を決めます。1割が直列なら10倍が限界で、実際には調整のコストでそこにも届きません。
戻し方: EP.7 の順序（減らす → まとめる → やり直せるように → 並列化）。直列部分を削るほうが効く場面が多い。
6. キャッシュで蓋をする
症状: 数字は改善したが、初回や期限切れの直後だけ極端に遅い。時々「古い情報が出る」という報告がある。
誤解: 遅さは隠せば解決する、という前提。実際には問題が見えにくい形に変わっただけで、平均に埋もれた として残ります。
戻し方: EP.6 のとおり、根本を直せるなら直してから入れる。入れるなら命中率を測れるようにし、鍵に利用者と権限を含め忘れないこと（これは性能ではなく事故になります）。
7. 件数に上限を設けない
症状: 開発中は快適。運用から半年後、特定の利用者だけ画面が開かなくなる。
誤解: そんなに増えないだろう、という見積もり。増えないデータは存在しません。そして上限がなければ、最悪値が計算できません。
戻し方: 一覧を返す処理には最初から上限を入れる。（EP.5）もメモリ枯渇（EP.9）も、根っこはここです。後から入れると既存の利用者に影響するため、最初に入れるべき制約です。
8. 効果を確認せずに次へ進む
症状: いくつも改善したが、どれが効いたか分からない。数か月後、同じ議論が再燃する。
誤解: 直したのだから速くなっているはずだ、という前提。まとめて変えると、効いたものと効かなかったものが区別できません。効かなかった変更（=複雑さだけが残る）も一緒に残ります。
戻し方: 改善前後の分位点を記録する。可能なら1つずつ変える。そして払った代償まで書き残す（EP.1）。
9. 結果が変わっていないかを確認しない
症状: SQL を書き換えて速くなったが、集計値が微妙に違っていた。気づいたのは数週間後。
誤解: 性能改善は挙動を変えない、という前提。書き換えの過程で、結合条件や NULL の扱いが変わります。特に集計クエリは行の重複で結果が変わりやすい。
戻し方: EP.3 のとおり、改善前後の結果を突き合わせる手順を作業の一部にする。件数と代表値の比較だけでも、大半の事故は防げます。速さより先に正しさです。
10. 目標がないまま続ける
症状: 改善が終わらない。どこまでやればよいか誰も答えられない。だんだんコードが読みにくくなる。
誤解: 速いほど良い、という前提。速さは可読性・正しさ・開発速度と交換して得るもので、無料ではありません（EP.11）。
戻し方: EP.1 で目標値を決め、満たしたら止める。やらないと決めたことも、再検討の条件つきで記録しておく。
11. どこから直すか
10個を並べましたが、優先順位があります。判断そのものを狂わせるものから先に扱ってください。
- 1測らずに直す（1番） — これが残っていると他が全部当たらない
- 2本番と違う条件で判断する（3番） — 測っていても、条件が違えば結論が逆になる
- 3平均だけを見る（2番） — 問題の存在自体が見えない
- 4件数に上限がない（7番） — 時間とともに必ず破綻する
- 5残り — 上4つが片付いてから
上から3つは、いずれも判断の土台に関わります。土台が歪んでいる状態で個別の改善を積んでも、正しい場所に手が入りません。4番目だけは性質が違い、放っておくと時間が問題を大きくするため、上位に置いています。
速くする技術より、どこを速くするかを見極める技術のほうが希少で、効果も大きい。
アンチパターンはどれももっともらしい理由から生まれます。経験を信じる、平均を見る、隠して解決する ── いずれも一見正しい。迷ったら、その改善は何を犠牲にして、全体の何割に効くのかという問いに戻ってください。ここまでの内容への反応や、扱ってほしい論点があれば記事下のリアクションからお寄せください。続編は随時追加していきます。
この記事の感想を教えてください
あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。