4
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

時差とタイムゾーンがシステムとエンジニアに与える影響

Last updated at Posted at 2020-12-28

海外にいる同僚と仕事をしている場合や、自分が海外で仕事をしている場合、エンジニアにとって時差やタイムゾーンが結構な影響を持っています。
これはシステムにも同様でユーザが異なる国の人がいる場合も、同じくシステム上で結構な気遣いが必要となっていきます。それらについていろいろとまとめてみました。

#ミーティングの時間
エンジニアも会議、打ち合わせを多くします。日本とアジア近郊ですと1時間前後の時差ですので、大体同じ時間帯にミーティングもできます。
これがアメリカ在住の相手とミーティングをする場合は、少なくとも西海岸の標準時間で8時間、東海岸になるとさらに4時間追加で12時間になります。
これをさらにややこしくするのが、誰がミーティングをセットアップするかによって、夏時間が来た場合に1時間ずれることです。東海岸の同僚がセットアップした場合は、夏時間が始まると例えば夜11時開始のミーティングが夜中0時スタートになります。

もしミーティングが日本の早朝の場合、アメリカの人とミーティングをすると時差もありますが、日付そのものが変わります。エンジニア的にはこれは会話をかなりややこしくする要因となります。
システム上のジョブのスケジュールの話なんかしている場合に同僚に、”明日の午前9時スタートで”って言われると”何曜日のどのタイムゾーンの午前9時”なのか確認しないととんでもないことになったります。同僚としては火曜日のつもりでも、こちらはすでに火曜日なので明日とか今日みたいな相対的な単語は使わない方がいいかもしれません。

#夜中の電話
自分も日本にいた時に週に何回か東海岸の同僚とミーティングがあったので、毎週のように夜中までおきてミーティングに参加していました。夜型の人間なのであまり苦にはならなかったですが、やっぱり就寝の習慣が週に一回大きく変わると徐々に影響が出てくるものです。
疲れているときはミーティング中に寝落ちして気付いたら、次の話題に移っていたってこともよくありました。
当時は現在のように在宅勤務があまりなかったころですが、さすがに夜中のミーティングの次の日は在宅勤務をしていました。

#システムの時間設定
システムの時間やタイムゾーンの設定はそのシステムの用途によって要件は異なりますが、ユーザがいくつかのタイムゾーンに存在する場合は結構気を使います。
以前あった話ですが、参加しているプロジェクトで使っているOSのイメージの時間をすべて中央ヨーロッパ時間(CET)に設定していました。ドイツの会社なので一見普通のように思われますが、これは結構な問題で、アプリケーションにもよりますがOSの時間がアプリケーション側の時間となるような場合、夏時間と標準時間で1時間の時差が出てきます。
アプリケーション側でジョブを設定すると、夏時間になった日でもユーザから見ればジョブは例えば同じ2時スタートです。ですが、ログなんかはGMTで書かれていることが多いので、夏時間になった日から先日までは2時スタートのジョブがログ上は1時間早くスタートのように出てくることもあります。

システムの担当者が異なったタイムゾーンにいる場合は、さらにややこしくいくら慣れていてもOSの時間の設定で混乱が起こったりします。それを避けるためにGMTに統一すると、システム担当者としては少なくともすべて同じ時間で夏時間の変更もないので少しましにはなります。
ですが、ユーザとしてはこちらは問題でアプリケーション側でOSの時間がアプリケーション側の時間になっている場合は、次はユーザが夏時間になると表示される時間が1時間遅くなります。
アプリケーションが時間に正確性が必要な場合は、夏時間に代わる日と標準時間に戻る日にジョブの時間を設定しなおさないといけないものもあります。

最近はユーザ側の時間表示は、ユーザの環境に合わせて表示することができるアプリケーションがありますが、これは使用しているユーザ全員がそういう設定であるということを理解している必要があります。別々のタイムゾーンにいる人同士で”何時にアップデート終わりましたよ”なんて連絡貰っても、どのタイムゾーンの何時かほかのユーザにはわからないものです。

12/22/2020, 11:58 AM GMT+1

このようにはっきりとタイムゾーンも込で表示されると、混乱もなくなるかと思われます。これで少なくともユーザのタイムゾーンはGMTより時差が何時間あるのかはっきりします。

#時差
自分は現在ドイツ在住で、アメリカの同僚と一緒に仕事をしていますが、時差は東海岸だと普段は6時間ですが年に数週間5時間の時があります。詳しくは次の”夏時間”に書いてあります。日本との時間は普段は8時間で、ヨーロッパで夏時間が始まると7時間になります。
日本との時差は7-8時間ですので、ドイツの就業時間には日本の方々は夕方の4-5時で、本来なら帰宅時間が近いのですがやっぱり日本の方々は残業を良くされていて、同僚にもよく日本の同僚はまだオンラインだって言われます。またドイツの人も早めに出勤する人がかなり多く、時差があっても3-4時間ほど重なる時間帯があります。

アメリカの東海岸の場合は6時間ですので、こちらの昼過ぎぐらいから3-4時間の間にアメリカの同僚とのミーティングなどを行うといった感じです。

#夏時間
前述のとおりヨーロッパとアメリカの東海岸との時差は年に数週間5時間の時があります。ドイツもアメリカも夏時間が現在のところ存在します。ただ、開始はアメリカのほうが1-2週間早く、終了もアメリカのほうが1-2週間遅いです。
ですのでアメリカの人が設定したミーティングは、アメリカが夏時間に代わる日からヨーロッパが夏時間に代わる日までの約1-2週間ほど、1時間早く始まります。ヨーロッパが夏時間に代わるとミーティングは元の時間に戻り、またヨーロッパが標準時間に先に戻ると、1-2週間ほどまた1時間早くミーティングが始まります。

アプリケーションの時間表示も先ほどの例ですと、夏時間が始まると+2と変ります。

4/22/2020, 11:58 AM GMT+2

EUは現在のところ2021を最後に夏時間の廃止を決めています。国によって2021年の夏時間終了時に、そのまま夏時間で通年過ごすか、標準時間に戻して通年標準時間にするか決めるようです。
これは、ますますややこしくなる様子です。例えば今まで時差のなかったドイツとフランスで別々の選択をした場合、過去になかった1時間の時差が起こります。タイムゾーンの設定もその場合は新たな設定が追加され、すべてのシステムに影響を及ぼしかねません。

ちなみにベルギーとオランダの飛び地があり、道を隔てて違う国なんてことも普通のようです。もしこの2か国が別々の選択をすると、そうとう混乱しそうです。

#本番環境のメンテナス
本場環境のメンテナンス、デプロイはできるだけユーザが少ない時間帯を選んで行われていると思います。システムの重要度にもよると思いますが、重要なシステムはやはり週末に行われることもあるようです。
自分が担当しているのは社内システムですので、そこまで気にしなくてもよく平日のオフピークにメンテナスやデプロイを行います。自動化でゼロダウンタイムをしているので特に問題はないのですが、やはりユーザが少ない時間帯のほうが何かあった時の影響を考えるといいです。

そこで、また時差の問題が出てきます。世界中にオフィスがあったりして、多くのタイムゾーンにユーザがいる場合オフピークと言うのはかなり限られてきます。どのタイムゾーンに社員が多くいるかで変わってくるのですが、日本時間の早朝というのが最も影響が出にくいようで、アメリカはすでに終業していて、アジアはまだ完全に始業していない時間帯です。
ただ、担当者がドイツの人ですとこれはドイツ時間の前日の夜中前ですので、ほぼありえない時間になります。少し前に、海外と日本のエンジニアの様々な比較という記事にも書きましたが、その時間帯に仕事をするということはほぼありえません。
ですので、ドイツ時間の早朝メンテナスということはよくあり、これは日本時間のちょうどお昼前後となります。ですので、自分が日本で勤めていた時は、よくその時間にシステムが使えなくなるようなこともありました。

#国内での時差
アメリカでは国内にいくつものタイムゾーンが存在していて、それは普段の生活にもなじんでいるみたいです。
会話で時間が出ると、大概の場合はタイムゾーンと一緒に言うようです。例えば、"3pm ET"(東海岸時間)というように。それによって、他のタイムゾーンにいる人も自分の所で何時かわかります。初めてアメリカで同僚にメールを送った時に、自分はカリフォルニアにいたのでそこの時間のつもりで”何時から”と指定したのですが、すぐ同僚かどのタイムゾーン指定しないとわからないと言われたのを覚えています。

#単一のタイムゾーンの場合
では、日本のように単一のタイムゾーンの場合はどうなるかと言うと、前述の問題は起こらないだろうと思われます。時差もありませんし、夏時間もありません。ですので海外にユーザがいない場合は基本的にはJSTにシステム上は設定して大丈夫なのではないでしょうか。システムやアプリケーションによってはログの時間は自動的にGMTで変更できなものもあるようですが、それは担当者だけがちょっと計算すればいいことですのでそれほど問題ではないかと思います。

また、ヨーロッパから日本のサービスを利用したりすると、こちらの夜7-8時位(日本時間の午前3-4時)からメンテナスをしているところをよく見かけます。やはり外部のユーザ相手のシステムですと、それぐらいの時間になってしまうみたいです。

#最後に
いかかでしたか?時差は海外旅行などで身近になってきていますが、エンジニアにとってはちょっと厄介なものです。時差のおかげでシステムには結構な影響を及ぼします。また、働き方や時間も大きく影響されます。
時差は大概は1時間ごとの違いですが、30分刻みの違のところなどもあり単純そうで意外と複雑なものです。また、アメリカのように国内でいくつものタイムゾーンがあったり、州によってはアリゾナやハワイのように夏時間を採用していない州もあったりします。これに合わせてシステムを設定しようとするのも大変であろうと思われます。

もし、時差のある国の人と仕事をする機会がある場合は、ぜひご参考にしてください。

4
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?