はじめに
この記事はSchoo Advent Calendar2025の7日目の記事です！
こんにちは。開発部門に所属する新卒エンジニアの @takumi_hashimoto です。
この記事では、新卒エンジニアの私が犯した失敗と、そこから学んだ教訓を共有します。
概要
私が担当したタスクは、実行に25分かかる処理のパフォーマンス問題の解消です。
「パフォーマンスが悪い？じゃあキャッシュを入れれば早くなるはず！」
この安易な思い込みで実装したものは失敗したのですが、レビューから計測と方針の確認の重要性を学ぶことができました。
タイムライン
基本設計
↓
実装（詳細設計は実装しながら...）
↓
PR作成＆レビュー依頼
↓
レビュー返却「これ、根本の解決になってない...」
↓
実装方針からやり直し
私が選んだ実装方針（詳細の計測せずに進めた）
私の「なんとなく」の仮説
「キャッシュを入れれば解決だ！」
この根拠のない思い込みから、以下の方針で実装を進めました。
- キャッシュを入れられるところにはキャッシュを導入しよう
実装内容
- 処理の中でキャッシュを入れられるところ全てにキャッシュを入れる
「これで早くなった！」と自信満々でPRを出しました。
コードレビューでの指摘（現実を突きつけられる）
先輩からの最初のコメント
「お疲れ様です！ところで、なぜここにキャッシュをいれたのですか？」
私：「え...」
ログからそれぞれの処理のパフォーマンスを計測したことで判明した結果：
- DBクエリの処理に時間がかかっていた
発覚した問題点
1. ボトルネックを詳細に特定できていなかった
ログから大まかなボトルネックしか特定せず実装をしてしまっていた。
2. 全部のパフォーマンスを改善しようとしてしまっていた
実際にパフォーマンスの遅延となっていたのは処理の一部であり、全てにキャッシュを入れたことで、余計な変更が入り、実装コストが高くなった。またコードも読みにくいものになってしまっていた。
3. 方針の確認をせずに作業をしてしまった
自分で決めた方針を上司の方やチームの方に相談せず、実装してしまったことで途中、軌道修正ができなかった。
なぜこうなったのか（根本原因の分析）
1.「推測」で動いていた
- 「たぶんこれが原因だろう」という憶測
- 「キャッシュの導入は良いプラクティスだから」という表面的な理解
- 計測の重要性を理解していなかった
- 方針の確認をしていなかった
2. 問題の本質を見極めずに解決策を決めていた
- 状態：「処理が遅い」
- 推測：「とにかくキャッシュを入れればいいい」（根拠なし）
- 実際の原因：「DBのパフォーマンス問題」
作り直しの過程（正しいアプローチ）
Step 1: 計測とプロファイリング
まず、現状を正確に把握：
- 全体の処理時間を計測
- 詳細なプロファイリング
- ボトルネックの特定
Step 2: 真の原因を特定
プロファイリング結果から判明したこと：
- DBクエリが大部分を消費している
Step 3: 解決策の考案・確認
- 原因から解決策を考えてみる
- 解決策を上司の方やチームの方に確認してもらう
Step 4: 解決策の実装
- Step 3で決めた方針をもとに実装する
学んだ教訓
1. 必ず実装方針の確認をすること
自分で決めた方針が正しいものと思わず、作業に入る前に方針の相談をすることで間違えた方針のまま進まずに済む。
2. パフォーマンス改善の正しい手順
1. 計測する（現状把握）
↓
2. ボトルネックを特定する
↓
3. 仮説を立てる
↓
4. 方針を確認する
↓
5. 改善を実装する
↓
6. 再度計測する（効果測定）
↓
7. 改善されていなければ2に戻る
この手順を飛ばすと、私のような失敗をします。
実践している予防策
- ログからボトルネックを詳細に特定する
- 実装に入る前に上司の方、エンジニアの方に相談する（自分の仮説を確認・レビューしてもらう）
まとめ
これが今回の失敗から得た最大の学びです。
- パフォーマンス問題は必ず計測から始める
- ボトルネックを特定してから対策を考える
- 方針があっているかを早い段階で確認する
最後まで読んでいただき、ありがとうございました！
パフォーマンス改善で失敗した経験があれば、ぜひコメントで共有してください。
失敗から学んで、より良いエンジニアになりましょう💪
明日の12月8日は@schoo_n_longcapeの担当になります。お楽しみに！
Schooでは一緒に働く仲間を募集しています！