QAエンジニアとしてのパフォーマンス改善への向き合い方

初めに

こんにちは！「estie レジリサーチ」でQAエンジニアをやっている山本龍平（yamachan）です。

この記事はestie QAメンバー3名によるブログリレー 2日目としてお届けしています。

今回は、自分の開発ユニットがどのようにプロダクトのパフォーマンスと向き合い、改善に取り組んでいるかをご紹介します。「非機能面の品質改善に関心がある」「パフォーマンス改善って実際に何してるの？」という方にぜひ読んでいただきたいです！

背景

「estie レジリサーチ」は、住宅領域の不動産情報を扱うプロダクトです。この領域のデータ量は非常に膨大で、検索や集計にかかる処理は重くなりがちです。

私たちのプロダクトは、そうした複雑な情報を顧客がストレスなく扱えるようにすることをミッションにしています。つまり、「機能が豊富」だけではなく、「操作がスムーズでサクサク動く」ことが価値そのものです。

実際にお客様との会話でも、

「他のツールより軽くて、操作にストレスがない」
「レポート出力が早いのが地味に助かってる」

といったフィードバックをいただくことがあり、性能面の品質が選定理由の一部になっている実感があります。

性能の可視化

性能を改善するために、まず何よりも大切なのは「現状を正しく把握する」ことです。体感で「ちょっと遅いな…」という気づきはあっても、それを定量的に測定・観測できなければ改善にはつながりません。

私たちのユニットでは、以下のような仕組みで性能を定期的に可視化しています：

ログを仕込んで性能を取得する
ログをSnowflakeに送信して集約
分析基盤上のWebアプリで可視化・分析

この仕組みによって、特定機能の処理時間やパフォーマンスを時系列で追跡可能にしています。

ログの取得

バックエンドでの処理にかかった時間

多くのパフォーマンス課題はバックエンド処理に起因するため、GraphQL APIへのリクエスト時に以下のようなログを出力しています：

start: リクエスト送信タイミング
end: レスポンス受信タイミング

さらに、GraphQLのクエリ単位ではなくoperationName単位で計測することで、ユーザーの体感に近い粒度で分析できるようにしています。

実装イメージはこんな感じです：

app.use((req, res, next) => {
  // GraphQLエンドポイントへのアクセスのみ対象
  const isGraphQL = req.path === "/api/graphql" && req.method === "POST";

  if (!isGraphQL) return next();
  const start = Date.now();

  // 応答完了後にログ出力
  res.on("finish", () => {
    const duration = Date.now() - start;
    const status = res.statusCode;
    const operation = req.body?.operationName || "unknown";
    const vars = req.body?.variables || {};

    const log = {
      type: "GraphQL",
      timestamp: new Date().toISOString(),
      operationName: operation,
      durationMs: duration,
      statusCode: status,
      isError: status >= 400,
      variables: vars, // 本番環境では必要に応じてマスキング
    };

    console.log(JSON.stringify(log)); // ここを外部ログ送信に置き換えることも可能
  });

  next();
});