余談にそれますが、小学生からのプログラミング教育が無駄だというのは、実戦においてはプログラミング言語よりも、こうした常識と知識を踏まえて、可能性をさぐる論理力が求められるからです。
話を戻せば、浮かんでは消え、なんども議論されている、サマータイムへの対応、あるいは準備をしていないコンピュータ・システムの業者がいるなら、静かに退場すべきであり、裏返せば、多くのシステム屋はある程度の備えをしているものだということです。
なにより、今の時点からでも即座に対応できる程度のことです。2018年8月8日の読売新聞は「元号の変更とあわせてシステム改修が間に合わない」と書いていましたが、あまりにも無知。
コンピュータの内部は西暦で処理されていますが、元号表記が必要な場合、「1989年1月8日からは平成」と変換しているだけのことです。それが次は「2019年5月1日からは○○」と新元号の処理を一行加えるだけです。
さらにこれらの制御は「フラグ」によって行います。あるフラグが立っていれば元号処理、または「新元号」を含んだ処理をさせ、そうでなければ通常処理という具合です。
サマータイムも同じく、「サマータイム」のフラグが立っていれば、サマータイムの開始日時を参照し、その切り換え日ならば、必要な時間調整をするというだけのもの。プログラミング初心者でもできる程度の処理です。
一方で、ここがサマータイム導入が日本で難しいところに直結します。この記事を書いた読売新聞の記者のように、コンピュータへの無理解と、同時にコンピュータへの過大な期待が、日本社会にはあるからです。
先に述べたように、時間のずれた目覚まし時計を合わせるように「日付時刻の変更」をすれば済むだけの話。仮に政府案のとおり、東京五輪までの2年間限定ならば、システム改修など不要で、サマータイム開始日と終了日の年2回×2年の4回だけ「人力対応」すれば済む話。
これは「費用対効果」の話しです。システム改修に数千万円も掛けるなら、そこだけ「手間」をかけるほうが安上がりで合理的なのですが、こう考える日本人は少なくありません。
「コンピュータに任せているのだからコンピュータにやらせるべきだ」と、「自動処理」を望む日本人が少なくありません。筋が通っているようですが実は珍説。コンピューターは道具に過ぎず、それをつかって人間がどう楽するかがポイントなのに、コンピュータだけで完結させるために人間が右往左往するのです。
また、サマータイムの変動幅が2時間とすると、初日の一日は22時間となり、終了日は26時間となります。この時の売り上げの扱いはどうするのか、また「日給」はどうするのか、そしてこの処理をコンピュータにさせるにはどうすべきか、とまぁ馬鹿馬鹿しい議論が、プログラミングの前に行われます。
これを「仕様」と呼ぶのですが、主に発注者の「希望」が盛り込まれるもので、この発注者がコンピュータを理解していないことが多く、無理難題が盛り込まれることも多々アリ、これが日本のIT化を遠ざけている大きな要因となっています。
イレギュラーはイレギュラーとしてあきらめるのもプログラミングにおける基本なのですが、無知な人ほどコンピュータに「完璧」を求め、完璧を求める日本人の性向がこれに拍車を掛け自体を悪化させます。
その完璧さを求める性向が、ひとつの不備を見つけると全体に当てはめ、そして「サマータイムにシステム改修が間に合わない」という暴論を新聞が拡散し、みなが根拠無く同意し、先送りされてきた。これが「平成サマータイム議論」です。
こうした日本人の性向、習性からサマータイムは難しいのですが、反面、本来的な日本人が兼ね備えている「不便を楽しむ」ことができればサマータイムなど難なく乗り切れることでしょう。
つまり、アスリートファーストなどの詭弁では無く「不便なのは開始と終了の二日だけ。あとは慣れようよ」と、開き直ったアナウンスを政府がしてしまえば、勤勉でいてイベント好きな日本人なら、勝手に盛り上げてアジャストすることでしょう。
さらに、月替わりではなく「週末」や、やたらと増えた「三連休」をサマータイムの切り換え日に当てれば、寝不足や時間調整のイベント化だってできます。
image by: Shutterstock.com
