サマータイム対応に、貴重なIT人材を費やすべきなのか（3/3 ページ）

公開 2018年09月19日 07時01分

更新 2018年09月18日 06時57分

[ITmedia]

印刷する

　例えば、総務省が示した情報システムの強靭性向上に、ようやく対応したばかりの自治体。サマータイム導入でログに記される時間がずれると、セキュリティ機器によって不正アクセスと判断される可能性があるといいます。また、総合行政ネットワーク（LGWAN）側に置かれたタイムサーバを参照する設計になっているところもあれば、手動で設定している場合もあるといい、各システムがどのサーバから時刻をもらっているのか、時刻源を探して突き止める仕事も必要になります。

　何より自治体にとって6月というのは、税金や社会保険などのさまざまな処理に迫られる「繁忙期」です。自治体によっては夜間に走らせるバッチプログラムのスケジュールをギリギリで組んでいるところもあり、それが2時間ずれると「突き抜け」が発生する恐れがあります。ならばと改修したり、あるいは機器の性能向上で対応するにしても、その措置を2019年度の予算に組み入れるにはそろそろギリギリのタイミングです。

　なお自治体の仕事の1つに戸籍の管理がありますが、戸籍には死亡時刻の記載が必要になります。もしサマータイム実施中に死亡した場合、どの時刻を表記すべきなのかも判断しなくてはいけません。上原氏によると、戦後のサマータイム導入時は、「手書き」という最も柔軟な処理方式が採用されていたため、戸籍の死亡時刻欄には時刻の後に（夏時間）と手で記されていたそうです。

　また、先に上原氏が説明した通り、UTCを取得し、それを調整して利用している家電やIoT機器の中には、サマータイム用の改修が必要になるものがあります。ですが、地震計のような機器の中には、山中など容易に足を運べない場所に設置されているものも少なくなく、対応には文字通り多大な労力がかかると見込まれます。

　パネルディスカッションでは他にも、食品流通業で利用されている電文フォーマットや銀行界のシステムインフラ「全銀EDI」の電文メッセージID、あるいは気象関係で活用されるビッグデータなど、細かく見ていけばさまざまなところで「日時」がかかわってくることが紹介されました。ビッグデータの場合、時刻にばらつきが生じたデータをそのまま解析すると、結果が思わぬ方向にゆがむ恐れがありますし、「日」ではなく「時間」単位で消費期限をコントロールしている食品業界では、大きな混乱が懸念されます。

　会場からは「ゾンビのような電話システムが動いている。これもサマータイム対応するとなるとアップデートが必要だが、そもそも再起動したらちゃんと立ち上がってくれるのか不安だ」という苦笑混じりの声も上がっていました。

　悩ましいのは「中にはきちんと対応している機器があるかもしれないので、その洗い出しも必要だ」（上原氏）ということです。全ての機器が対応しておらず、手動で頑張るしかない状況ならば、それはそれで腹をくくることもできるでしょう。けれど、対応している機器としていない機器が入り交じっており、誰もその実態を把握できていない、まるでどこに地雷が潜んでいるか分からない状況は、多くの人を悩ませているように思います。

　一歩引いてみれば、これまで「やっつけ仕事」で片付けられ、正しい設計・正しい作法で開発されていなかったソフトウェアを修正し、国際的に通用するコーディングへと変えていくいい機会と捉えることもできます。しかし、それは十分な議論がなされてコンセンサスが得られ、対応に必要な時間が与えられた上でのことではないでしょうか。

　IT業界のみならず国民生活全体に大きな影響を与えるこうした政策は、そもそも何を目的に導入するのかを、根拠（エビデンス）をベースに丁寧に議論すべきではないか。そして、メリットがあるとしても、たびたび上原氏や日本IT団体連盟政策委員会委員長の別所直哉氏が強調した通り、貴重なITリソースをこの問題に費やすべきなのか、冷静に判断すべきではないか――。筆者は、一連の議論からこうした思いを強くしました。