UNIX 2038 年問題というのがある。西暦 2000 年問題と同じような話である。伝統的な UNIX オペレーティングシステムは日付・時刻を 32 bit 整数値で管理しており，1971 年 1 月 1 日 0 時 0 分 0 秒をはじまりとして 1 秒毎に数値を 1 ずつ増加させる。これを前提としてそのときの時刻を計算している。ところがこの 32 bit データが 2038 年 1 月 19 日 3 時 14 分 07 秒を過ぎると桁溢れし，なんと 1901 年 12 月 13 日 20 時 45 分 52 秒 (UTC) にすっ飛んでしまう。2038 年問題とは，これに伴って UNIX システムでさまざまな不具合が出るであろう事態の総称である。
2038 年なんてまだまだ先だと思う人がいるだろう。でももうこの問題は現実味を帯びはじめている。私は会社で回覧されてくる他サイトの事故事例には必ず目を通すようにしているが，先日，HP-UX (ヒューレットパッカード社の UNIX) の旧版を使っているサイトでユーザ・ログインができなくなる障害報告を読んだ。ユーザ管理項目に有効期限があり，それに 9999 日みたいな大きな数値を指定したら，有効期限日時が 2038 年を飛び越えて 1901 年から折り返してしまい，有効期限はすでに超過しているとシステムが判断したがゆえの障害だった（ヒューレットパッカード社の名誉のために付け加えておくと，HP-UX 最新版では 2038 年問題は訂正されている）。2038 年問題は世間ではあんまり騒がれていないけれども，UNIX サーバに移行したクリティカルなシステムが極めて多いだけに，これ以上にマズイことも起きる可能性がないわけではない。
西暦 2000 年問題は，多くのシステムが西暦を下 2 桁で管理しているがゆえに 2000 年の判断を 1900 年と誤ってしまうことに起因した。その発現は予想が一筋縄ではなく，大陸間弾道弾が誤動作するかも知れないとか，ジェット機が操縦不能に陥るとか，大いに世間を騒がせた。おまけに 2000 年は 100 でも 400 でも割り切れるので超特例的閏年であったという事情が，計算機関係者の恐怖を煽り立てた。閏年を「4 で割り切れ，100 で割り切れない年」とする単純なロジックを使うプログラマが実際にいたのである。ふつう 400 年に一回のことを人生で突き詰めて考える人はまれである。関ヶ原の合戦以来のことが自分の人生で起こるなんて考える人はまれである。
計算機業界のことを知らない人には，2000 年なんてすぐ来るのがわかっているのになんでこんなバカな設計にしたんだろう，まったく呆れる，のようなことをホザく正論吐きがゴマンといた。現象の内在的論理を辿るよりも前に己の感じ方に満足してしまう人，進化の恩恵に無意識に浴する人の典型である。私の尊敬する米原万里も，どの本であったか忘れたが，同じことを書いていて，私は正直悲しくなったことを思い出す。もちろん西暦 1990 年代に設計され，それなりの期間使用される予定のシステムならば，2000 年を考慮していないのはただのバカである。しかし，当時問題になったのはコンピュータ黎明期から少しずつ改修されながら大規模化したシステムだからこそであった。共同体への影響がじつに大きい官庁システムがまさにこれにあたるからだった。私の顧客は，幸いにも，その事情を痛いほど知っており，2000 年対応システム改修にケチケチしなかった。
そもそも，2000 年で問題が出るのがおよそわかっていながら，なんでそういう設計になっていたのか。コンピュータ機器の進化には，3 年で性能が 2 倍になるという「ムーアの法則」と呼ばれる経験則がある。2011 年から逆算して 70 年代あたりに舞い戻ると，かつての計算機が現在と比べていかに貧相なものだったかが想像できるだろう。30 年昔の計算機の性能はいまの 210 分の 1，逆にいうと同じもののお値段はいまの 210 倍。40 年前なら 213 倍くらい。そう，その当時はメモリ 256KB の一月の借料がサラリーマン大卒初任給を越えるくらい高価だった。磁気ディスクも同じ。こういう超高価なリソースを使うとき，とにかくケチろうとするのは当然である。日付・時刻はどんな業務データの属性にも付いて回り，これを仮に short (2 byte) 整数で年，月，日，時，分，秒 12 byte 使えばデータに占めるその割合はバカにならない（まさかと思う前に 12 × 213 がどれほど重いか考えるがよい。いま日付・時刻の格納に一個あたり 12 × 213 byte 使わせてもらいます，なんて顧客に言ったら即刻クビである）。昔，私の担当したシステムでは西暦を下 2 桁だけで管理し，数字 1 桁を 4 bit に入れて 6 byte に切詰めていた。理論的にはもっと切詰められるが計算速度やわかり易さとの兼ね合いでこうしていたわけだ。それくらい記憶域が貴重だったのである。70 年代くらいのシステム設計者は，おそらく皆，計算理論の前に経済学に縛られていたのだと思う。
UNIX 2038 年問題についても，なんでたった 32 bit で管理するなんてケチったんだろうと思う人がいまならウヨウヨいるはずである。4 byte 32 bit というデータ構造は 32 bit 計算機がもっとも高速に取り扱うことのできるものなのだ。でも，それを抜きにしても，1970 年ごろの UNIX 設計者は，2038 年にはボクはもう生きていないと無意識に思ったはずだ。人生 70 古来稀なり。そのころにはボクたちのような貧しい資源制約から解放された，もっと夢のようなオペレーティングシステムが動いているさ，と。つまり計算機の世界でも，老人の感慨同様，人生はあっと言う間に過ぎたわけである。
ところで，西暦 2000 年問題はジョークのネタにもなっている。「2005 年のある日，アルバニア軍のコンピュータ系統が一斉にダウンした。その理由は？ — 西暦 2000 年問題」。その国の時代遅れを笑う格好の題材になったんである。でも 2000 年を大きく超過して忘れ去られたころにプチ 2000 年問題が出て恥ずかしい思いをした SE／プログラマは必ずいると私は思う。
