まずは2000年問題について振り返ろう。「Y2K（わいつーけー）問題」とも言われた。2000年以前の古いコンピュータでは、OSや関連プログラムの中で西暦を「下2桁」で認識させることが多かった。コードの文字数を極力減らすためと言われてはいるが……。

　つまり2000年は「00年」だ。これが1900年と間違って処理されることでシステムの誤作動が発生するのではと危惧されたのだ。特に金融系やインフラ系のシステムで問題が発生すれば世は大混乱になる。当時のエンジニアたちの懸命な対処もあり、1999年から2000年の年越しで大きな問題が起こることはなかった。めでたしめでたし。

　それから20年が過ぎた2019年から2020年の年越し、冒頭で触れたケータイのカレンダーの問題の他にも、米ニューヨーク市では1万4000台分のパーキングメーターシステムが不具合を起こし、クレジットカードでの支払いができなくなった。ポーランドでは、あるメーカーのレジスターでレシートの発行ができなくなった。ドイツのハンブルグ市の地下鉄システムも2020年を迎えて実行されたソフトウェアアップデートで不具合が発生し、運休の憂き目に遭ったという。

　英国の科学誌「New Scientist」は2020年問題の原因の1つとして、1999年までに2000問題に対処したエンジニア（主にプログラマー）にあると指摘した。プログラムの改修を急いだためプログラムを完全に書き換えることなく「windowing」と呼ばれる処理をしたことが原因だ。

　windowingは、UNIX時間を採用するプログラムで使われた。UNIX時間は1970年1月1日0時0分0秒を基点とする経過秒数だ。1970年以前についても負の値として利用できる。多くのプログラマーがUNIX時間における基点「1970年」を中心に、時間枠（window）を単に広げるだけの処理を実行したのだ。正の値、負の値ともに拡張しシステムで扱える時間枠を「1920年～2020年」とした。

　この処理がなされたシステムは、日付が2020年に達したとたんに1970年に巻き戻ったわけだ。多くの関係者は、対処中のシステムが2020年まで使われるとは夢にも思わなかったのだろう。今後、どのように対応すべきなのか。さらに時間枠を拡大して乗り切るのだろうか。UNIX時間にはいわゆる2038年問題と呼ばれる上限がある。頭の痛い問題が続きそうだ。

---

上司X：　2020年問題の原因が2000年問題だったという話だよ。

ブラックピット：　何てことでしょう。20年前のテキトーな処理が今になって問題を引き起こすとは。

上司X：　当時としては急いで改修しなければならなかったのだし。ベストだと思ったのだろう。

ブラックピット：　でも甘くないですか？　その場しのぎっていうのは……。

上司X：　20年後にそのシステムが使われているとは思わなかったんだろう。そもそも2000年問題だって、1970年代に活躍したプログラマーが20数年まで同じ仕組みを使うだろうと思っていなかったから発生したのだと思うぞ。

ブラックピット：　そうか……、考えてみたら同じスパンですよね。でも……。

上司X：　起きてしまったことなのだし、適宜対処していくことしかできないじゃないか。

ブラックピット：　丸め込まれているような気がしないでもないですが。今度は2038年問題ですね、楽しみだなあ。

上司X：　おいおい。2028年問題も確かに見逃せない。せめて問題が起こったときに素早く対処できるようにしておきたいところだな。