コンピュータのシステムは、元号ではなく西暦を使うべし

コンピュータのシステムは、元号ではなく西暦を使うべきだと思いませんか？

役所から受け取る書類や、役所に提出する書類は、西暦ではなく元号を使うケースがあります。役所のコンピュータシステムは、西暦ではなく、元号が使われています。

2019年の4月に平成が終わると、どうなるのかなと思っていましたが、しばらくの間「平成」を使う役所もある模様です・・・

政府がこんなことを真剣に議論するなんて馬鹿げているし、随分レベルの低い話だと思うのは僕だけではないはず。
だって1989年に昭和から平成に変わっているし、2000年問題だって経験しているので、色々と学習しているはずなんだけどね。

2000年問題を振り返る

1999年から2000年になる年に、2000年問題がありましたよね。

コンピュータが西暦の下二桁だけで年を処理していたことが原因で、2000年になるとコンピュータが誤動作すると言われておりました。

例えば、1999年から2000年に移行する際、西暦の下二桁だけを見ると、99から00に移行することになるため、コンピュータ内部では1900と2000の区別がつかず、正しい処理が行われない可能性があったのです。
当時、役所や会社に泊まり込みで2000年の元旦を迎えたシステムエンジニアの方も多いですね。

2000年問題で想定されたトラブル

どんな問題が想定されていたのか見ていきます。Wikipediaに詳しく載っていますので引用します。

• 発電、送電機能の停止や誤作動とそれに伴う停電
• 医療関連機器の機能停止
• 水道水の供給停止
• 鉄道、航空管制など交通機能の停止
• 弾道ミサイルなどの誤発射。2000年に突入するタイミングに合わせて、
• Y2K問題にかこつけて故意にミサイルを発射する国家が出るのではという懸念もあった。
• 銀行、株式市場など金融関連の機能停止
• 通信機能の停止

実際にどんな問題があったのか

先ほど紹介した問題を想定して1990年台末期には、コンピュータのシステム更新が世界的に行われたという経緯があります。
なので、想定されていた問題はほとんど起きませんでした。
これは、システムエンジニアのみなさまの努力によるところが大きいですね。

元号が変更されることを想定していないプログラムに問題あり

元号は、明治以降、天皇=元号となっており、新しい天皇が即位すると元号が変更されています。
ちなみに、江戸時代までは、天皇=元号ではなく、一人の天皇でいくつもの元号もありましたし、1つの元号で複数の天皇が即位しているようなこともありました。

明治以降は天皇=元号という事情を考えると、元号が変更されることを想定していないプログラムを作ったことに問題があると言わざるをえません。

コンピュータ内部は西暦で処理し、外部出力を元号に変換して表記すべし

コンピュータ内部の処理を西暦にしておいて、外部へ出力する年号を元号に変換するプログラムを作っておけば、元号が変わっても何も問題は発生しません。
どうしてこのようなシステムを作らなかったのかは謎ですよね・・

でも、役所のコンピュータシステムは、ポンコツを掴まされるケースが非常に多いです。

社会保険庁時代から、年金システムはバグだらけだし、最近も保険料納付額が表示されないバグがありましたので、システム自体ポンコツなのは明白です。確かNTTデータが作っているんだよね。

役所の要件定義にも問題あり

役所の要件定義にも問題があります。

なぜ、元号が変更された際に対応できるプログラムを組むような要件定義をしなかったのでしょうか？元号は変わることは分かっているはずです。

西暦を使うにしても2038年問題がある

西暦を使うにしても2038年問題があることは頭に入れておきましょう。

2038年問題とは、2038年1月19日3時14分7秒を過ぎたら、コンピュータの時刻が誤動作するという問題です。

なぜこのような問題が生じるのかというと、UNIX時間を前提としたプログラムでは、1970年1月1日0時0分0秒から2,147,483,647秒を経過する2038年1月19日3時14分7秒になると、時計を正しく扱えなくなるために問題が起こります。

でもね、macOSでは、2001年1月1日0時0分をエポックタイムに更新したため、2038年問題を回避できます。きちんと先を見越して取り組めば、対応できない問題ではありません。

さいごに

コンピュータのシステムは、元号ではなく西暦を使うべきです。

西暦を使ってシステム構築をしておけば、元号が変わった2019年5月以降も一定期間「平成」を利用する必要がなくなりますからね。