Y2K-ちまたで話題の２０００年問題

作成日:1999/07/31

２０００年問題という物をみなさんは多少なりとも聞いたことがあると思います。 大雑把に言えば、その昔コンピュータのメモリや記憶装置などの価格が非常に高かった頃 メモリ消費を押さえるために西暦を４桁でなく２桁で短縮表現をするようになったのが きっかけといえます。

実はごく最近までこの昔ながらの風習が生きていて、今現在世の中で動いている コンピュータプログラムのなかにも西暦を２桁で表現している物がたくさんあるのです。

では、なぜ西暦を２桁で表現するとまずいのでしょうか。 コンピュータのなかでは様々な計算が行われていて、大小比較も行われています。 もし西暦を二桁で表現しているとすると、１９９９年を表す"99"の次は"00"になります。 そうすると本来なら"2000 > 1999" となるはずなのに"00 < 99"という大小関係になり 正しい計算が出来なくなります。

またデータの終わりを"99"という値で判断するプログラムや、データが無いというのを "00"という値で判断するプログラムが存在します。そういうプログラムの場合西暦の大小判断 を行っていなくても正しい計算が出来なくなります。

それなら西暦を４桁で表現するようにプログラムを変更すれば良いのではないでしょうか。 ところが話はそう簡単ではありません。企業などの場合、コンピュータで動いているプログラムの本数は 数千本以上あります。そのプログラムを一つ一つ調べて変更するのには非常に困難なのは おわかりになると思います。そのうえ、それらのプログラムが読み書きするデータも同様に 西暦を４桁にしてデータとして格納する必要があります。通常、何らかの処理でデータとプログラムが １対１に対応している場合はほとんどなく、データがプログラムで処理されてその結果をほかのプログラムが 処理をして...ということを経て最終的な結果を出力するというほうが一般的なのです。 そうすると変更するときはそれらの一連の処理を行っているプログラムを全て同時に変更しなければなりません。 また、過去のデータを残しておかなければならない場合は、その過去のデータを新しいプログラムに会わせて コンバートする必要があります。

２０００年問題として大きな物は上のような「西暦を２桁で表しているための不具合」 が大きな物ですが、ほかにも問題になる物があります。その一つは閏年です。

ふつう閏年というのは西暦を４で割って余りが０のとしが閏年だということはご存じだとおもいます。 世紀の境目以外ではこれで正しいのですが、正しくはさらに100で割り切れると閏年で、その中でも1000で割り切れる年は閏年ではないのです。 このあたりを正しくプログラムに組み込んでいる場合は良いのですが、100で割り切れても1000で割り切れると閏年というところが、
２０００年を100で割り切れるため閏年でないと判断するプログラムがあるのです。 こういうプログラムでは２０００年２月２８日の次を３月１日としてしまったり、日数計算を 正しく行えないなどの不具合が発生します。

コンピュータだけでなく、プログラムで制御されている機械は 全てが誤動作などの不具合が発生する可能性があります。大手企業では年末年始に役員などの 帰省を規制して早急な対策が出来るように備えたり、トラブルのためにホテルを予約したり 年末年始の交通機関の利用を制限したりと自社内部の問題だけでなく、社会的にも何かがあったときに 対応できるようにしている会社もあるようです。

コンピュータプログラムの不具合によるトラブルというのは 常に発生しています。私が経験した問題では、１年以上順調に動いていたある機械が 突然全く操作不能になり原因を探しても全く手がかりがつかめなくて、メーカに問い合わせたところ 497日間連続して通電していると、内部のタイマーがオーバーフローして０に戻ってしまうのが 原因だとわかりました。９９年の次が００年になるのと同じような理由で日付など全く関係のない 機械が止まってしまったのです。

２０００年問題が特殊なのは社会現象として発生しうるということです。 何が何処で起きるかわからない、というのが恐ろしいのです。不必要に不安がる必要はありませんが、 自分の身の回りの物がきちんと２０００年対応できているかどうか、 どういった対応をすればよいかなどを確かめてみてはいかがでしょう。