サマータイム導入に対する初見の感想
サマータイム導入が現実的な方向で検討されはじめました。聞いた当初はシステム観点から言っていろいろなリスクがあり、否定的なことしか浮かびませんでした。
猛暑が後押しする日本へのサマータイム導入、インフラエンジニアは頭を抱える - orangeitems’s diary
シスエムエンジニアとしては
初見に関してはこんな感想でもいいのですが、ネットのいろいろな反応を見て少しづつ意見が変わってきました。
もともと仕様の変更をシステムに求めてくる人は、ITのことを知らない人です。今回の場合も政治家が起点です。こういった仕様変更に対して、UTC、システムクロック、NTP、いろいろな時刻をめぐる仕組みを語りだし否定的な態度を取るのが、システムエンジニアとして本当にふさわしい態度なのでしょうか。
「大丈夫です。任せてください。リスクはありますが全て洗い出し、安全に対応します。方法はいくつかあるので、ご提案します。」
と返すのが、最も望ましいのではないかと思いました。
システムの変更理由について、妥当性があるのかはお客様側の話です。これに立ち入るべきではないのではないでしょうか。システムエンジニアがシステムの変化を認めないのは、社会を変化の乏しいつまらないものに陥れる危険性も感じます。例えば元号の話でも、システム側面で考えると恒久性の高い西暦が最も取り扱いやすいです。西暦でのリスクは西暦9999年になると思いますが、7000年弱のことを考えてシステムを作る人は誰もいないでしょう（いたりして）。しかし、元号とは日本の文化を構成する一つの部品でもあります。システム的な側面から文化の仕組みまで立ち入るのはシステムエンジニアの領域ではないと思うのです。あくまで、リスクと工程を洗い出しつつ、実現する方法を語るのがシステムエンジニアに求められていることだと思います。
やるなら、まかせとけ
国民としてサマータイム導入の賛否を表現するのは、当然の権利だと思います。ただ、システム的にコストがかかることを理由に否定することは、これは違うと思います。むしろそのコストに見合うかこそ、国民的な議論とすべきかと思います。
「やるなら、まかせとけ」
これこそシステムエンジニアの醍醐味かなと思います（かっこいい）。
なお、経営者の立場からすると、自社のシステムにて追加補修が発生しまたそのリスクにも費用が発生するので、サマータイムなんかやめてくれよウチの会社関係ないじゃん、というのはまっとうな意見かと思います。ただ、消費税の税率が上がったり内税と外税の話であったり、祝日が毎年変わったりなど、システムなんて外部環境に都度適応していかなければいけないのは宿命です。だからこそ保守費用が必要となるわけで、いちいち反応していたらキリがないのではないかな、と思います。
事前準備をしておこう
ということで、これから、もっといろんな識者が出てきて「サマータイムガー」という記事をたくさん見かけることになりそうです。私個人は、
「やるなら、まかせとけ」
と言えるように、事前に情報収集し、依頼されたらすぐに資料が出せるような事前準備を始めておこうと思います。
