UXから考えるクライアントサイドのパフォーマンス監視設計

リファクタリングによるデグレーションは、機能は正しく動いているのに体験が劣化するという、テストでは捕捉しにくい領域で起こります。
ユーザーからの問い合わせが届く前に検知したい。しかし、すべての指標を監視するのは現実的ではありません。
本LTでは、「ユーザーの体験に悪影響を与えるか？」を基準に監視対象を絞り込む設計指針と、その基準をもとに筆者が実際にどのように指標を選定し運用したのかを紹介します。
特定の技術スタックに依存しない設計思想の話なので、どなたにも持ち帰れる内容です。リファクタリングに限らず、日々の開発で「何を監視すべきか」を判断するためのヒントになればと思います。

https://fortee.jp/fec-nagoya-2026/proposal/4b846089-31f2-4dad-8f7f-e01708380c03

Transcript

1. UXから考えるクライアントサイドの パフォーマンス監視設計 石田 健太郎（@ishida_2002） 2026年5月9日
2. 2 自己紹介 石田 健太郎（いしだ けんたろう） • 2002年生まれの23歳 • 株式会社kubell ◦ 新卒3年目のフロントエンドエンジニア ◦ 「Chatwork」のブラウザ版・デスクトップ版の開発を担当 • パフォーマンスチューニングとかが好き • 今日はパフォーマンス監視について話します
3. 背景
4. 事の発端はリファクタリング
5. 5 背景 • 「Chatwork」のフロントエンドは、jQueryとReactが混在している • jQuery時代の処理をReactに移行する試みをしていた • 機能が仕様を満たしていることはテストしやすい • 一方、エッジケースのパフォーマンス悪化には気付きづらい ◦ 我々の想定を超えるデータ量を扱うアカウントが存在している
6. 6 背景 • 「Chatwork」のフロントエンドは、jQueryとReactが混在している • jQuery時代の処理をReactに移行する試みをしていた • 機能が仕様を満たしていることはテストしやすい • 一方、エッジケースのパフォーマンス悪化には気付きづらい ◦ 我々の想定を超えるデータ量を扱うアカウントが存在している ➡ リファクタリングのデグレはユーザー体験として現れることがある
7. 7 どうしていたか • リファクタリング箇所の前後にタイマーを仕込み、ログを飛ばす • 集計してダッシュボード化
8. リファクタリングが一段落
9. 9 ダッシュボードどうする？ • リファクタリングには区切りがつき、当初の目的は達成した • せっかく作ったし、消すのは惜しい • 何かあった時に気づけるなら残しておきたい
10. 10 ダッシュボードどうする？ • リファクタリングには区切りがつき、当初の目的は達成した • せっかく作ったし、消すのは惜しい • 何かあった時に気づけるなら残しておきたい ➡ 見ないよりは見たほうがよさそうなので残してみた
11. 11 どうなったか 「なんとなく」の監視に時間を取られる • 毎朝15分メンバー全員でダッシュボードを確認 • 指標の数が多く、「これ何だっけ?」となる • 目的が曖昧なので、悪化を検知しても判断に悩む
12. 12 どうなったか 「なんとなく」の監視に時間を取られる • 毎朝15分メンバー全員でダッシュボードを確認 • 指標の数が多く、「これ何だっけ?」となる • 目的が曖昧なので、悪化を検知しても判断に悩む ➡ ダッシュボードを整理することに
13. 目的を再定義
14. 14 目的を再定義 「なんとなく」ダッシュボードを見ていた時期にやりたかったことを言語化 Q. パフォーマンスが悪化すると、何が困るのか？
15. 15 目的を再定義 「なんとなく」ダッシュボードを見ていた時期にやりたかったことを言語化 Q. パフォーマンスが悪化すると、何が困るのか？ A. ユーザーの体験が悪化する
16. 16 目的を再定義 「なんとなく」ダッシュボードを見ていた時期にやりたかったことを言語化 Q. パフォーマンスが悪化すると、何が困るのか？ A. ユーザーの体験が悪化する Q. ユーザーの体験が悪化すると、何が困るのか？
17. 17 目的を再定義 「なんとなく」ダッシュボードを見ていた時期にやりたかったことを言語化 Q. パフォーマンスが悪化すると、何が困るのか？ A. ユーザーの体験が悪化する Q. ユーザーの体験が悪化すると、何が困るのか？ A. ユーザーがサービスに対してストレスを抱くようになり、最悪の場合解約に繋がる
18. 18 目的を再定義 「なんとなく」ダッシュボードを見ていた時期にやりたかったことを言語化 Q. パフォーマンスが悪化すると、何が困るのか？ A. ユーザーの体験が悪化する Q. ユーザーの体験が悪化すると、何が困るのか？ A. ユーザーがサービスに対してストレスを抱くようになり、最悪の場合解約に繋がる ➡ 「ユーザーの体験が悪化していないか」を監視したかった
19. 19 基準を再定義 「ユーザーの体験が悪化していないか」を監視するため、3つの基準を定義 • 処理時間が人間に体感できる長さか ◦ 3msが30msになっても気付かないが、1000msが1500msになったら気付く • サービスのコア機能にあたるか ◦ チャットが重かったら大問題だが、設定の変更が重くても大きな問題ではない • ユーザーの操作がブロックされるか ◦ バックグラウンドで動く処理が遅くなっていてもユーザー体験は損なわない
20. 20 基準を再定義 「ユーザーの体験が悪化していないか」を監視するため、3つの基準を定義 • 処理時間が人間に体感できる長さか ◦ 3msが30msになっても気付かないが、1000msが1500msになったら気付く • サービスのコア機能にあたるか ◦ チャットが重かったら大問題だが、設定の変更が重くても大きな問題ではない • ユーザーの操作がブロックされるか ◦ バックグラウンドで動く処理が遅くなっていてもユーザー体験は損なわない これらの基準を満たす処理の中で監視の優先度を決めるため、さらに2つの基準を定義 • データの母数が十分か ◦ 稀にしか呼ばれない処理は監視の優先度を落とせる • 変更されやすいか ◦ そもそも変更されない箇所は見なくていい
21. 結果
22. 22 どうなったか 毎日15分 ➡ 毎日5分 • 監視している指標の数が約半分に減った • 全ての指標がコア機能のユーザー体験に紐付いているので、トリアージコストが下がった ◦ 数値の悪化 = ユーザー体験の悪化であり、対応すべきものという認識になった
23. 23 どうなったか 毎日15分 ➡ 毎日5分 • 監視している指標の数が約半分に減った • 全ての指標がコア機能のユーザー体験に紐付いているので、トリアージコストが下がった ◦ 数値の悪化 = ユーザー体験の悪化であり、対応すべきものという認識になった 量が減り、質が上がった🎉
24. まとめ
25. 25 まとめ • 目的を持って監視する ◦ 「なんとなく」では時間だけ取られる • フロントエンドなら、UXが一つの軸になる ◦ 「ユーザーが困るか？」を判断軸にできる • 見ないものも決める ◦ 母数が少ない・変更されない箇所は思い切って外す
26. 26 まとめ • 目的を持って監視する ◦ 「なんとなく」では時間だけ取られる • フロントエンドなら、UXが一つの軸になる ◦ 「ユーザーが困るか？」を判断軸にできる • 見ないものも決める ◦ 母数が少ない・変更されない箇所は思い切って外す 良い監視ライフを🙌
27. 働くをもっと楽しく、創造的に