記録するジャーナリズムから、測って確かめるデータイズムへ

時差を考慮しないシステムが多数の日本でサマータイム対応は不可能

»

2020年五輪にあわせてやろうという日本のサマータイム。欧米でもやっているありきたりなシステム変更に見えるかもしれませんが、決定的に大きな違いがあります。時差がある社会を前提とした欧米では時刻とタイムゾーンがセットでできています。アメリカ東海岸標準時(EST)と西海岸標準時(PST)があってという社会であり、サマータイム対応はタイムゾーンが、東海岸夏時間EDTや西海岸夏時間PDTに変わるという扱いで比較的楽に行なえます。また、時刻を記録する際は、協定世界時UTCで記載するというやり方に必然性があり、それを時差処理して現地の標準時や夏時間に戻すというのも日常的に行われているわけです。

一方、日本は国内で閉じている限りタイムゾーンを意識する必要がありません。海外と仕事をする人は少数であり、国内で閉じたシステムである限り、タイムゾーンやUTC変換などを行わずに済むわけです。表にしてみるとよくわかりますが、サマータイム対応に対する素地が欧米と日本で全く違うのです。

欧米 日本
タイムゾーン対応

必須。情報システムはタイムゾーンまたぎの処理に対応済み 不要。タイムゾーンをまたぐ処理は考慮されてないケースが大半
夏時間対応の仕方

タイムゾーンをずらす処理で可能

タイムゾーンの概念を追加し、世界標準時換算や、タイムゾーンのフィールド追加が必要
夏時間導入時期と情報システム

サマータイムは概ね、1980年前半に開始済み。ITの高度化はサマータイム以降

サマータイムは戦後数年の試行のみで、ITの発達以前。
1950年代から60年近くかけて発達したI日本のTが初めて、サマータイム対応に直面。

時刻や時間を扱う情報システムは様々です。日本で、勤怠管理にExcelを使う企業は非常に多いのですが、夏時間を扱う関数がないとかそういう細かなところで対応できる/できない の確認が必要となります。

そもそも、時間を扱うシステムやプログラムはかなりクリティカルで複雑な処理を行うものが多数あります。私がよく知るのはは、クレジットカードでカードローンを借りて一部繰り上げ返済した時の利息計算プログラムです。例外的なパターンが非常に多く、コードの改修を何年もやっていました。

システムの内部であれば、内部的には日本標準時で通して最終的な表示だけ夏時間に変えるとかいう手もあるのでしょうが、ともあれ、仕様の策定とシステム開発が伴います。また、体外接続するシステムで、時間を日本標準時のままとするか、フィールドを増やして夏時間かどうかの判定がつくように仕様を変えるのか?などなど検討すべき事項は多数です。

官公庁のシステムは予算化が遅れることも多く、WebのHTTPS対応ですら後回しになっていることが表面化しています。東京五輪に向けて夏時間導入を今から決めるとなるとその改修のための予算がつくころから改修を始めてもまず間に合わないと考えるべきでしょう。そして、そもそも改修の予算取りのための調査にもお金がかかるので今から2020年までにできることは見積もり調査のための予算獲得ぐらいでしょう。そうまでしてやるサマータイムにどれほどのメリットがあるのか?

日本の政策や企業経営などでの意思決定に、情報システム的な見地で責任を持つCIO不在が問題にされて久しいのですが、今回のサマータイム対応騒動はその最たる例でしょう。今回のサマータイム対応騒動を奇貨として日本にCIO、最高情報責任者が定着する契機となることを願っています。

Comment(0)

コメント

コメントを投稿する