計算機の性能を測るとき、遅さは一つの数では表せません。ひとつの処理が返ってくるまでの応答時間と、単位時間あたりに捌ける処理量は、独立に動きます。一件あたり三秒かかる仕組みでも、並列に千件流せる設計なら毎秒何百件も処理できる。遅くて速い、という状態が普通に存在するわけです。逆に、一件は一瞬で返るのに全体としては詰まっている仕組みもある。この二つを混ぜて議論すると必ず話がずれるので、現場ではまず「いまどちらの話をしているか」を確認します。日本語の技術用語でも、遅延と低速はいちおう別語として立っている。ところが日常語のほうには、その区別が用意されていません。
この形容詞は、その二つに加えてもう一つを抱えています。時刻としての遅さ。「返事が遅い」という一文は、返事に時間がかかったのか、来るべき時刻を過ぎたのかを、それだけでは決められません。前者は所要時間の話で、後者は時間軸上の位置の話です。速度と位置は本来まったく別の量で、片方から他方は導けない。英語なら slow と late が分かれるところを、こちらは一語で受けている。翻訳する側から見れば取りこぼしですし、辞書を編む側から見れば厄介な多義です。しかも三つの意味は文脈で自動的に決まるわけではなく、決まらないまま流通することが多い。
では欠陥なのかと考えると、そうも言い切れません。むしろ人の会話ではこの未分化が効いている。「遅い」と言われた側は、作業の速度を責められたのか、約束を破ったと言われたのかを、その場で自分で選ばなければならない。選ばせること自体が圧力になります。分けて言えば「所要時間が長い」と「期限を過ぎている」で、後者のほうがはるかに重い。曖昧なまま投げられると、受け手はたいてい重いほうを引き当てる。責める側は最も軽い意味しか言っていないと主張でき、責められた側は最も重い意味を受け取っている。一語が分かれていないことが、そのまま対人的な機能を持ってしまっているわけです。
もうひとつ、運用の現場で広く共有されている経験則があります。仕組みの遅さの体感は平均では決まらず、最悪付近の応答時間で決まる、というものです。百回のうち九十九回が一瞬で返っても、一回だけ長く止まれば、その仕組みは遅いと記憶される。平均は改善しているのに苦情が減らない、という事態はここから起きます。ここで一度疑ってみると、記憶に残るのが最悪値なのは待たされた不快が強いからで、遅さの定義とは関係ないのではないか、とも言えます。それでも実務上は最悪値を削るほうが効くので、体感の側に合わせて指標を選び直すことになる。物語の速度感にも同じ構造があります。読者が遅いと言うとき、参照されているのは、全体の平均的な密度より、いちばん鈍かった数ページです。
書く側の対処は、たぶん二段になります。ひとつは、遅さを描く場面では読者に実際に待たせること。所要時間を数値で告げても遅さは伝わらず、待つ手続きを踏ませてはじめて伝わる。もうひとつは、意図せず鈍い箇所を作らないこと。この二つは矛盾しません。前者は設計された待機で、後者は事故です。自分の原稿を読み返すとき、全体の平均ではなく最も鈍い一箇所を探す——遅さの測り方を一つ借りてくるだけで、読み返しの手順そのものが変わります。