概要
受託開発では、限られた工数・スケジュールの中で最大限の価値をクライアントに提供することが求められます。その中でしばしばボトルネックとなるのが、DBのスロークエリによるパフォーマンス問題です。
本記事では、技術実装を担わないプロジェクトマネージャーが、MySQLのスロークエリ問題にどう関与し、どう改善を推進すれば良いのかを解説します。
なぜPMがスロークエリに関わるべきか？
受託案件においては、次のような構造的な課題があります：
- 事前見積もりの制約により、後工程に余裕が少ない
- スコープ外と判断されやすく、性能問題は後回しにされがち
- クライアントから「遅いんだけど？」という定性的な指摘が多い
こうした状況では、PMが技術チームとクライアントの橋渡しをしながら、課題を定量化し、実行可能な改善タスクへ落とし込むことが重要になります。
スロークエリ改善におけるPMの主な役割
✅ 1. 「遅い」の定義を明確にする
クライアントの「遅い」は、体感ベースの表現であることが多いです。これを再現可能な操作と計測可能な応答時間に変換することが、PMの最初の役割です。
| 誤解されやすい表現 | PMがすべき変換例 |
|---|---|
| 検索画面が遅い | 商品検索でキーワード入力後、表示までに5秒以上かかる |
| 管理画面が重い | 管理画面TOP表示で毎回タイムアウト（30秒超）が発生している |
✅ 2. エンジニアの分析が進みやすいように条件を整える
- 発生時間帯の特定（ピークタイムだけ遅い？）
- 影響範囲の切り分け（全ユーザー？特定条件？）
- 画面操作や構成との対応付け（ログ出力との突合）
これらの情報を揃えることで、エンジニアはスロークエリログとの照合を効率的に行うことができます。
✅ 3. 工数に落とし込むための改善方針の整理
性能改善は、開発チームにとって見積もりが難しいタスクです。PMは、以下のような「改善単位」に分解して整理すると良いでしょう。
- インデックスの追加（軽微、即効性あり）
- クエリの書き換え（中〜大、動作検証が必要）
- UIや仕様変更による負荷回避（中程度、合意形成が必要）
4. スロークエリが複数ある場合の優先順位の付け方
スロークエリは一つとは限らず、「複数のクエリが少しずつ遅い」「ある時間帯に大量に発生している」など、多点同時発生型のケースも多く見られます。
PMは、限られた工数内でどの改善を優先するかを判断するために、以下の4軸でクエリを評価しましょう。
✅ 優先順位を付けるための4つの評価軸
| 評価軸 | 観点 | 例 |
|---|---|---|
| 発生頻度 | 1日100回 vs 月1回 | 商品検索 vs 月次レポート |
| 実行時間 | 数秒〜数十秒かかるクエリは要注意 | タイムアウト直前のUPDATE |
| 業務/UX影響度 | 顧客が使う／社内での業務遅延 | 顧客検索 vs システム設定 |
| 改善難易度 | 改修に必要な工数や範囲 | インデックス追加 vs 構造変更 |
✅ 優先順位マトリクス
| クエリ内容 | 発生頻度 | 実行時間 | UX影響 | 改善難易度 | 優先度 |
|---|---|---|---|---|---|
| 商品検索 | 高 | 高 | 高 | 低 | ★★★★☆ |
| 管理ログ表示 | 中 | 中 | 中 | 低 | ★★★☆☆ |
| 月次レポート生成 | 低 | 高 | 低 | 高 | ★★☆☆☆ |
このように整理すると、開発チーム／クライアントと相談の上、即対応できるもの／要検討に分けてアクションが明確になります。
💡 Tips：受託開発における「優先度」はクライアント主導で変わる
受託開発では、その時点でクライアントが重視している領域によって、技術的な優先順位とは異なる判断が下されることがよくあります。
たとえ技術的には即効性のある改善が明確でも、「今そこには投資しない」という理由で後回しにされる場合があります。
👉 ベンダー側としては、意思決定の材料を提示することまでが責務です。
📌 心がけたいポイント
- 判断材料があることで、クライアントは優先順位を明確にしやすくなります
- 「直せます」よりも「直す価値があるかどうか」の説明が信頼につながります
✅ PMが意識すべきTips
- 効果の見えやすい箇所から着手：成果が可視化されやすく、クライアント報告にも有利
- 「影響が大きく、直せるもの」から手を付ける：技術的な実現可能性も加味して判断
- 未対応項目はBacklog化しておく：技術的負債の見える化とチーム内共有が鍵
5. クライアント調整と合意形成
性能改善は見えにくい価値ですが、PMが以下のように翻訳することでクライアントの理解が得られやすくなります：
- Before：商品一覧表示に6秒 → ユーザー離脱の可能性が高い
- After：1秒以内で表示 → CVへの好影響、サポート問い合わせ減
PMが最低限知っておくと良い技術ワード
| 用語 | 意味 |
|---|---|
| スロークエリログ | 遅いSQLを記録するログ。MySQL側で設定可能 |
| インデックス | 検索速度を向上させるDBの目次。設計ミスに注意 |
| EXPLAIN | SQLの実行計画を表示。ボトルネック分析に有効 |
| N+1問題 | 無駄なDBアクセスが発生する典型的な設計ミス |
よくある落とし穴とPMアクション
| ケース | 落とし穴 | PMの対応 |
|---|---|---|
| 一律に性能改善を依頼 | 優先度不明・工数爆発 | ユースケースごとに影響を洗い出し、優先順位を整理 |
| 表示速度だけに注目 | バッチ処理や更新系が無視される | 書き込み系や非同期処理も対象に含める |
| 「やれば速くなる」幻想 | 根本原因が非DB領域にあることも | APIやネットワーク、アプリ側のボトルネックも考慮する |
おわりに
スロークエリの問題は、受託開発において多くのプロジェクトで避けて通れない課題です。しかし、それを単なる技術的な問題として放置するのではなく、PMが主体的に「課題の定義」「状況の整理」「関係者との交渉」を担うことで、対応は格段にスムーズになります。
最も重要なのは、技術的な詳細をすべて理解することではありません。
PMが果たすべき役割は、課題を見える化し、チームが動ける土台を整えることです。
「技術は分からないから任せる」のではなく、
「改善に向けて、動ける環境をつくる」ことこそが、PMとしての価値です。