仕事での開発にかかる工数の見積もりだったり、実際に開発をしたときにかかる時間は当然エンジニアによって違って、一般的には熟練のエンジニアほど工数はかからない・・・のは、それはそうなのだけど、今回は開発にかかる時間ではなく、プログラムの実行速度のお話です。

その1秒、速い？遅い？それとも普通？

Webサイトを開いてページが完全に表示されるまでに1秒かかりました。

といったときに皆さんは早い！と感じますか？遅い！と感じますか？はたまた、普通。と感じますか？
私はWebサイトであれば「普通」と感じます。
これは私がWebサイトであれば「1秒以内で表示されれば、ユーザーにはサーバーから応答がないなってそんな感じないし、SEO的にもまぁそんな問題にならないだろう」と考えているからです。

1秒超えたらもっと早くレスポンスを返せないか、どうしても縮められないならLoading画面とか挟んでサーバーはがんばってるんだよ、って表示させてユーザーに「サーバーは止まってないよ！」って示すべきかなと思います。
（Loadingのないページで3秒も待たされると「サーバー止まったか？」って感じます）

レイヤーが変わると「速さ」の基準も変わる

さて、Webサイトの「表示」関してはこんな感じのイメージというか感覚を持っていますが、これはエンジニアによっては「3秒くらいかかっても普通でしょ」と思う方もいると思います。
それは携わっているサービスだったりアプリケーションだったりして「それが普段からよくみる当たり前」なのかもしれません。

では、これがWebサイトではなくデータベースからの応答だったらどうでしょう？

1回のselectのqueryで500msかかります。

これは早いでしょうか？遅いでしょうか？
そんなのはquery文によって違うし、データベースのデータ格納量によっても違うからどちらともいえないよ！と思うかもしれません。

実際その通りです。

これがWebページで、1回の表示リクエストで1回だけ呼ばれてレスポンスとしてページ生成をして返した時に、ユーザーに800msくらいで表示されるのであれば、Webサイトとしては1秒以内で処理しているから早い、という感じになるかもしれません。

それはそれでシステム要件を満たしているのであれば、特に問題もない話なのです。

最終的に言えることは、「処理時間の良し悪しは絶対的な数値では決まらない」ということです。

※同じ1秒でも、どこにかかっているかで意味は変わる

処理時間は“文脈”で決まる

同じ1秒でも、ユーザーが見るWebページの表示であれば「普通」と感じられる一方で、データベースの1クエリとしては「遅い」と判断されることもあります。

つまり、時間の評価はその処理がどのレイヤーにあり、何を目的としているのかという文脈によって大きく変わります。

エンジニアによって時間の感覚が異なるのは、単にスキルの違いだけではなく、普段扱っているシステムやレイヤー、そして基準としている「当たり前」が違うからなのです。

だからこそ、「この処理は速いのか遅いのか」を判断するときは、単純な数値だけではなく、その処理の役割や全体の中での位置づけを踏まえて考える必要があります。

見るべきは「秒数」ではなく「意味」

私たちが向き合うべきなのは「何秒かかったか」ではなく、「その時間は本当に許容されるべきものなのか」という問いです。

時間はただの数値ではなく、ユーザー体験やシステム全体のバランスの中で意味を持つものです。

速さを追い求めること自体が目的ではなく、その処理がどこで、どのような価値を生んでいるのかを見極めることこそが、本質的な設計と言えるのではないでしょうか。

そして、その判断基準こそが、エンジニアにとっての「時間の感覚」なのだと思います。

時間をどう捉えるか。それ自体が、設計の質を決めるのです。