いま仕事をしているチームのリードはレビューの反応が速い。レビューに限らずメールの返事も速い。リード以外の人々もだいたい反応が速い。時差のある仕事をしていた頃は反応に一日かかるのが当たり前だったし、時差がなくなったあとも反応の遅い相手との仕事が多かった自分には新鮮だ。

一方、自分がこの速さを期待されたらしんどいと正直なところ思う。誰かに反応するには自分の作業を中断しないといけない。集中が途切れる。他人の仕事をブロックしないために自分の進みを犠牲にする。フォーカスやらフロー状態やらを重視する一方で反応の速さに美徳を見出す。共同作業のジレンマといえばそれまでだけれど、レイテンシ・スループットのトレードオフがレイテンシ側に倒れすぎていると思う。もう少しスループットに倒せる世の中になってほしい。

時差のある仕事では、待たされる前提でいくつもの仕事を同時に進めていた。一つをレビューに出したら、別の仕事に取り掛かる。コンテクストスイッチは悪というけれど、割り込まれてスイッチするのと待つためにスイッチするのは少し違う。待つタイミングは予測できるし、自分で決められる。他にやることがある限り、（そして締切が迫っていない限り）待つのはさほど苦痛でない。そして、やることはいつもそれなりにある。長く待つ前提でいくつもの仕事を受け持つのは、待たされる側がレイテンシを受け入れスループットにバランスを倒す一つの手管といえる。

待たされる苦痛というのはある。でも苦痛の大きさは、かならずしも待たされる長さに比例しない。むしろどれだけ待たされるかわからない不確定性や不透明さが辛かったりする。待てど暮らせど返事がないと、忘れられていないか不安になる。

反応が速い人々は、レイテンシのばらつきを小さくすることで不確定性を小さくしている。でも、他の方法で不確定性を減らしてもいいはずだ。たとえばメールでの問い合わせに対し「明日見ます」と締め切り付きの ACK を返せと説く仕事術師は多い。行列のできる人気店の電光掲示板には予測待ち時間がきらめいている。見通しに透明性を与えるこうしたアイデアは、もっとシステムやツールが後押ししてくれていい。相手ののメール、レビュー、バグ退治の待ち行列が目に見えるだけで、どれだけ人々は救われるだろう。

もっといえば、私達は待つ必要のないものを待っているかもしれない。たとえば Facebook は(少なくともある時期まで) コミット後のレビューを認めていた。コミット後レビューなら、コードの書き手はレビューを待たずに作業を続けられる。同様に GitHub の PR はレビューの単位をコミットからブランチに広げることで、ある程度の先行開発を書き手に許している。これらの方法には固有の難しさがあるけれど、実りも大きい。

並列性を使いレイテンシを隠す。わずかなレイテンシと引き換えに大きなスループットを得る。これらはソフトウェアエンジニアリングと少し似ている。割り込みでなく待ちを起点に仕事を切り替えるのは協調的マルチタスキングだし、ブランチ単位レビューや先行開発はバッファリング、あるいは投機的実行だ。コミット後レビューは Eventual Consistency と言えなくもない。

そんなエンジニアリングの眼鏡を通すと、これはみなスケーラビリティの問題に見える。返事の速い TL はスケールしない。自分は無茶なスケールの求めに引き裂かれたくない。システムとしてうまくやってほしい。世の中にはリアルタイム性が大切な仕事もあるだろう。けれどスケーラビリティに意味がある仕事も多いと思う。

個人的にはリアルタイム性よりスケーラビリティ重視の方が働きやすいので、世の中そういう仕事が増えて欲しいものです。