タイムゾーンの不確実性
2007年9月6日
私はボストンにいて、カルガリーのオフィスへ飛び立つところでした。カレンダーを見て、会議があるかどうかを確認しました。最初の会議は午前10時30分からでした。朝、急いで起きる必要はないなと思いました。
私は会議に現れましたが、2時間遅刻していました。何が起こったかというと、カルガリー時間の午前8時30分に始まった会議に招待されていたのです。Lotus Notesは私のコンピュータがボストン時間に設定されていることを認識し、親切にも2時間分のタイムゾーンを変換してしまったのです。
これは、私が注意を払わなかったのが悪いのだと主張することもできます。結局のところ、私はNotesがこのように動作することを知っていて、日記を読むときに不注意だったのです。私はこれを認めません。ドナルド・ノーマンが以前指摘したように、私たちは悪いユーザビリティが原因のエラーを自分たちのせいにする傾向があります。例えば、押すべきドアにハンドルが付いているようなものです。
私は今ではNotesのカレンダーを避けていますが、Macのical、Googleカレンダー、そして携帯電話でも同じような基本的な問題が発生します。私はボストンにいて、ロンドンでの午前10時の会議を設定します。私はロンドンに行きます。私は自分のいる場所に合うようにラップトップのタイムゾーンをシフトする傾向があります。そうすれば時計の意味が通るからです。しかし、そうするとこの予定時刻がずれます。これらのデバイスはすべてタイムゾーンをうまく処理しようとしていますが、結局、何を見ているのか分からなくなってしまいます。
タイムゾーンは、特にこの種の問題に対して脆弱です。これは、カレンダーアプリケーションで最も顕著な問題ですが、エンタープライズソフトウェアでもこの問題が見られます。タイムゾーンをうまく処理しようという誘惑がありますが、ソフトウェアが十分に賢くない場合、この誘惑は問題を引き起こします。まさにこのケースで起こったことです。
私はNotesがタイムゾーンを完全に無視することを好みます。会議が行われる場所の時間を設定すれば、それが表示されるはずです。タイムゾーンなんて誰が気にするでしょうか?通常、重要なのはその場所の時間だけです。カルガリーでの日のカレンダーを見るとき、私はその日のカルガリー時間を見たいのです。私がそれを見ている場所がどこであってもです。
もちろん、例外はタイムゾーンをまたがる電話会議です。しかし、ここでは、物理的な会議の処理を複雑にするのではなく、電話会議には特別なことを行う必要があります。電話会議用にフラグを設定できるようなものか、時刻表示にタイムゾーンを表示し、変換は読者に任せるだけという簡単なものでもよいでしょう。電話会議では、物理的な会議よりもタイムゾーンについて考えることが多いです(少なくとも私はそうです)。
ここでの重要な教訓は、最も一般的なケース(物理的な会議)をシンプルにし、あまり一般的でないケースには、例外として複雑なことを行うことです(おそらく手動での例外)。カレンダーのタイムゾーンが問題になるのは、一般的でシンプルなケースをより複雑にしているからです。問題が発生するのは、設計者がシンプルケースと電話ケースの両方に同じデータを使用したいと考えたからですが、それがシンプルケースを困らせているのです。
私が最悪のユーザーエクスペリエンス賞を授与するとき、通常、Lotus Notesがトップです。(実際、Thoughtworksがこのクソッタレを使っていると認めるのは恥ずかしいことです。)しかし、最悪のタイムゾーン体験賞はMicrosoft Officeに贈られます。これは何年も前のことですが、公平を期すために言っておくと。私は最近PDA(Windows CEバージョン2を搭載)を購入しました。私はいくつかの終日会議をカレンダーに入れて、シカゴに飛びました。PDAに会議を知らせるために、PDAのタイムゾーンを1時間早く変更しました。
すると、すべての終日会議が1日早くずれてしまいました。これは、エラーのカタログが原因でした。まず、彼らは終日会議を真夜中から真夜中までの会議として保存していました。これは、TimePointで人々を困らせるタイプの表現エラーです。次に、タイムゾーンを変更したときに会議の時刻がずれることで、さらに悪化しました。その結果、終日会議は午後11時から午後11時になりました。これはもちろん、PDAでタイムゾーンを変更したときに、会議がずれて見えるように、タイムゾーンを会議に入れたことが原因です。さらに、ソフトウェアは、終日会議は会議の日だけを表示する必要があることを知っていましたが、選択した日は会議の開始日でした。それは現在1日早くなっていました。それが、貧弱な時間点表現が逆襲しているのです。