東京時間は UTC+9 ではない：タイムゾーンの裏には、もう一つの働き方がある

日本に来る前、タイムゾーンは私にとって単なるオフセットだった。サーバーの時刻を合わせ、CI にタイムスタンプを打ち、別の時間帯の同僚への返信は少し遅らせる。全部 +8 と +9 の足し算と引き算で片付く話だった。

東京に住み始めてから気づいた。タイムゾーンは数字ではなく、働き方そのものだ。

数字に表れないもの

日本の職場には、見たことのない現象がある。会議は、きっかり時間には始まらない。

上海では、「3 時に会議」とは 3:00:00 にプロジェクターが点いて、司会者がホワイトボードの前に立っている状態だった。東京では「3 時から」は、だいたい 3:00 から 3:05 の間に皆さんが陆续と着席し、第一声が「お待たせしました」になる。5 分遅れても遅刻ではない。礼儀として空けておくバッファだ。

エンジニアにとっての影響はこうなる。自分が考えている「リリース時刻」と、顧客が感じる「認識時刻」の間には、いつも 5〜15 分の見えないバッファがある。デッドラインは T+0 だと思っている。現実は T+grace だ。

カレンダーの中の「夕方」

来たばかりの頃、私はカレンダーに「下班」と書いていた。后来、日本の同僚が「退勤」「終業」「上がり」と書いていることに気づいた。さらに后来、彼らのカレンダーにはよく「夕方」というタグがついていることにも気づいた。午後 5 時から 7 時までの間には、硬い会議を入れない窓がある。

その窓は「見えない仕事」のためにある。当日のチケットを片付け、日報を書き、まだ返していないメールに返信し、午後のコミットを同僚と確認する。エンジニアが 3 日連続で「夕方」の時間を取れないと、4 日目にたいてい何かが壊れる。技術ではなく、判断力が。

この気づきは、私自身の事故から来た。ある週、カレンダーを 5 日連続で 22 時まで埋めた。6 日目に、race condition を含む hotfix を出した。ローカルでは再現できず、本番環境で関係のないサービスを落としてしまった。事後の振り返りで、根本原因はコードではなかった。疲れていて、テストを書く頭がなかった。

午前 3 時のオンコール

もう一つ、予想しなかったことがある。オンコールの文化が違う。

上海では、オンコールは「電話が鳴ったら飛び起きる」ことが多かった。顧客は仕事中なので、監視アラートはすぐ対応する必要がある。東京では、午前 3 時の PagerDuty アラートは、自動的に優先度が下げられる。誰も気にしていないからではない。この時間帯はアクティブなユーザーがほとんどおらず、自己回復の確率が高い。だから「15 分待って、勝手に治るか見る」という設計になっている。

私が慣れていた「まず対応、あとで原因究明」とは真逆だ。最初はとても馴染めなかった。「これって無責任じゃないか?」と思った。后来、分かった。これは「対応」と「修正」を分けるという、具体的な実践だ。対応は当番のエンジニアの仕事。修正は就業時間の仕事。午前 3 時に修正できるならしない——怠けではなく、深夜の雑な修正が二次インシデントを起こし、元のアラートより高くつくからだ。

私は自分のサイドプロジェクトでも、このパターンを採用するようになった。23:00 から 07:00 の間の P2 アラートは、電話ではなく Slack に送る。15 分以内に自然に消えれば、何もなかったことにする。消えなければ、翌朝見る。

最後に

1 年前、上海から東京への移動は、サーバを +8 のラックから +9 のラックに移すことだと思っていた。

今は思う。移ったのは「時間」に対する見方そのものだった。日本では、「時間」は精确に切り刻める資源ではない。リズムがあり、エチケットがあり、見えない部分を持っているものだ。

新しいタイムゾーンを学ぶエンジニアにとって、サーバを調整すれば十分だ。
新しいタイムゾーンを学ぶ人間にとって、カレンダーを組み直す必要がある。