IT業界で気づいたことをこっそり書くブログ

くすぶってるアプリエンジニアが、日々気づいたことを適当に綴っていきます(受託→ベンチャー→フリー→大企業→ベンチャー→起業)

サマータイム導入がシステム的にマズい理由

 

lite.blogos.com

 

サマータイム導入はシステム的に大丈夫と書かれていますが、全く大丈夫ではありません。

しかし、システム開発の業界にいない人はわからないかもしれません。

このサマータイムを導入するリスクというのは、割とよくあるテンプレ問題だったので簡単にまとめて見たいと思います。

 

サマータイムでテストしていない

システムというのはリリースする前に入念なテストをします。しかしその際にサマータイム前提でテストしていません。サマータイム導入で思わぬバグが発生するかもしれません。

例えば、「ある時間に◯◯を実行する」というプログラムがあった時、そのままサマータイムを導入しては間違いが起こる可能性があります。もちろんそれが致命的か、軽度なバグかは分かりません。

 

修正されない動いているシステムが沢山ある

サマータイム前にシステムを修正すれば良いと思われるかもしれませんが、現実的ではありません。常に修正され続けてるシステムは一部です。予算がないとか、人が居ないなどで保守メンテ状態のシステムが山のようにあります。

例えるなら、「サマータイムのために修正すればいい」は「全ての建物に耐震強化を施す」に似ています。大変な作業だと分かるはずです。

システムが家電のようなものに組み込まれている場合は更に大変です。

動いている最中のシステムに突然サマータイムが適用されるのも問題です。要はぶっつけ本番なのです。

 

連鎖でバグが起こる

今のシステムというのは、色んなシステム間で通信しつつ連携して動いています。なので、サマータイムによりメンテナンスされていないシステムが誤作動を起こし、それが別のシステムに影響し、更に誤作動を起こす。というようなリスクがあります。

 

何が起こるか分からない

問題なのは何が起こるのか分からないことです。そしてそれを調べるのはそれなりのコストが必要になります。サマータイム導入をシミュレートする必要があります。

特に面倒なのは、外部のシステムに問題が生じた時の事です。悪影響が無いようにバージョンアップして、場合によっては過去のバージョンを使えないようにしなければならないかもしれません。

 

怖いのは、医療、金融など

ちょっとした誤作動が致命的になるのが医療、金融などです。

2時間ずれる事で、例えば同じ処理を2回行ってしまったりすると、人命に関わったり、大きな損失を受けるかもしれません。

もちろん起きないかもしれませんが、やはり何より分からないのです。テストしてないんですから。サマータイムはシステムの仕様外の挙動を求めています。

 

2000年問題は話題になった

似たようなことは、2000年問題で結構語られたと思います。今回ははシステムの普及度合いも相まってあの時より厳しいことが予測されます。

 

サマータイムの価値

リスクとコストはこんな感じです。

それでもやる価値がサマータイムにあるのでしょうか?