【コード哲学エッセイ】 パフォーマンスは速さじゃなく体験だ —— 計測より先に問う、 誰のための最適化か

緑の数字と届かない安心

納品前の夜。
僕は Lighthouse を開き、スコアが緑になるまで微調整しました。

画像を圧縮する。
フォントを遅延読み込みする。
キャッシュのヘッダを整える。

数字はきれいになった。
胸のあたりも、少しだけ軽くなった。

それでも、クライアントから届いた言葉はこうでした。

画面は表示されている。
次に押していいボタンが分からない。
ローディングのあいだ、本当に動いているのか分からない。

僕はそのとき気づきました。
速さを測っていたのに、体験を設計していなかったのだと。

速さは正義じゃない、 体験のほうが先にある

「速さは正義じゃない」という話を、以前にも書きました。
あれは、書くスピードと未来の自分の話でした。

今回の話は、隣の棚にあります。
動く速さと使われるときの気持ちの話です。

ms は嘘をつきません。
ms だけでは、人の不安までは測れない。

初回表示が 1 秒でも、操作のあと 3 秒無反応なら、体験は遅い。
逆に 2 秒かかっても、何が起きているかが見えていれば、待てることもある。

パフォーマンスという言葉を、僕はもう速度の別名として使わないようにしています。

待ち時間・分かりやすさ・失敗のときの言葉
—— それらをまとめたものが体験だと。

計測は誰のための物語か

「ログを証拠ではなく対話」だと書いたとき、メトリクスにも同じ癖があると気づきました。

数字は、正しそうに見える。
だから、物語を奪いやすい。

「LCP が改善した」
「バンドルサイズが 30% 減った」

どちらも事実です。
でも、その事実が誰の困りごとに効いているかは、別の問いです。

僕が計測の前に置くのは、次の三つです。

誰が使うのか。
その人は、何に不安を感じているのか。
その不安を、数字のどれが代弁できるのか。

開発者のパソコンは、いつも速い。
Wi-Fi は安定している。
通知も、うるさくない。

フリーランスの現場だと、検証環境が自分の机になりがちです。
だからこそ、「誰のため」が抜けると、最適化は趣味に寄る。

クライアントの安心のためなのか。
エンドユーザーのためなのか。
それとも、僕自身の「数字を見たい」ためなのか。

速く見える変更が体験を壊すことがある

N+1 の話を書いたとき、僕は動くコードの裏側を学びました。
見た目は同じでも、裏で足がもつれる。

フロントでも、似たことが起きます。

スケルトンを出しすぎて、中身が空に感じる。
遅延読み込みを入れすぎて、スクロールのたびに画面が揺れる。
キャッシュを効かせすぎて、更新したはずの情報が古いまま残る。

どれも、指標だけを見れば改善に見える。
でも使う人の物語では、不信になる。

僕が大事にしているのは、最適化のあとに一行、メモを残すことです。

「誰の、どの操作が、どう楽になったか」

数字だけ残すと、未来の自分がまた ms を追い始める。
一行のメモは、体験への錨になる。

止められる設計も体験の一部だ

速さの話をすると、起動ばかりが主役になりがちです。

体験には、終わり方も含まれます。

グレースフルシャットダウンを書いたとき、僕は学びました。
急に電源を切られるより、余白を持って止まるほうが人にもシステムにも優しい。

ユーザー体験でも同じです。

送信中のボタンを二度押しさせない。
離脱のあと、処理が続いているなら、それが分かる文言を出す。
エラーになったら、次に何をすればいいかを一行で示す。

これらはベンチマークに載りにくい。
けれど、「このサービス、ちゃんとしてる」という感覚には直結する。

パフォーマンスは、走り切る速さだけじゃない。
安心して任せられるかでもあるのです。

計測は問いのあとに置く

結論だけ先に書くなら、僕の順番はこうです。

1️⃣ 誰の体験を良くするのか、文章で一行書く
2️⃣ その人の遅いとは何の感覚か、言葉にする
3️⃣ それから計測する。改善する。また聞く

計測は、正義の証明書じゃない。
問いに答えるための道具です。

緑のスコアは嬉しい。
でも、それだけでは、スマホを握る誰かの不安までは届かない。

パフォーマンスは速さじゃなく体験だ——
そう言い切れるのは、数字の前に、誰のためかを置けたときだけなのだと思います。

コード哲学の話として、そんな順番を忘れない夜にしたいです。

ひとりごと

吃音のある僕にとって、沈黙は怖いことがあります。
だから、画面の沈黙や無反応の数秒が、どれだけ人を不安にするか、想像しやすいのかもしれません。

ms を追うのは、やめません。
追う前に、誰のためかを置く。

それだけで、最適化の顔つきが変わりました。

Substack はじめました

ここまで読んでくださり、ありがとうございました。

X では短い言葉で、note では整理した文章で発信していますが、Substack では、もっと途中経過の思考や削りきらなかった葛藤、技術者として日々考えていることを書いています。

もし興味があれば、覗いてみてください。

会社員（元システムエンジニア）からフリーランスとなり、
15 年目に突入しました。

納期と障害対応に追われる毎日の中で、
「もっと自由に、もっと本質的にものづくりがしたい」
そう思ったのが独立のきっかけです。

現在は、技術と文章を軸に、
仕事がラクになる仕組みや続けられる働き方を発信しています。

あわせて読みたい

▼ 数字の前に、ログを対話として読み直したいときに

メトリクスとログを裁きではなく共有の道具として捉え直す話です。
今回の「誰のためか」と並べると、計測の姿勢が揃います。

▼ 速さを実装スピードと混同していた頃の自分に

書く速さと動く速さは別の棚にあるという整理の土台になります。
今回の体験論の隣の記事として読めます。

▼ 指標は良くても、裏側で足がもつれる話を知りたいときに

見た目の速さと、データベースの裏側の負荷を切り分ける具体例です。
緑なのに重い正体を探す手がかりになります。

次の一歩を一緒に決める作戦会議室へ

パフォーマンス改善を、再現手順や計測の型まで落とし込みたい方もいると思います。

作戦会議室では、現場向けのチェックリストや振り返りの話も小さく分け合っています。
必要なときだけ、覗いてみてください。

参加する