コンピュータの西暦２０００年問題
コンピュータの、西暦２０００年問題が騒がれている。
システムが正常に動作しなくなるということで、深刻な事態となっている。
私は一応ＳＥであるから、業界の立場で物を言う必要があるのかも知れないが・・・。
しかし、コンピュータ業界が、こぞって「あたかも予期せず直面した問題」のごとく、対応している姿は、どうしても釈然としない。
なぜなら、問題は単純に、西暦年号をシステムで扱う場合の桁数の問題であるから、すべての場合、いずれ到来する西暦２０００年について、想定しなければならなかったはずである。
もちろん、この西暦を４桁で扱うか、下２桁で扱うかによって生じる、記憶容量の差は、確かにコストに連動する問題ではある。
が、この記憶容量のコストは、ハード価格の低下により、年々減少傾向にあり、むしろ年々西暦２０００年に迫る時点では、この記憶容量の問題よりも、考慮するべき課題であると思われる。
確かに、システムのライフサイクルは、５〜１０年であり、１９７０年代に稼動するシステムにおいては、西暦２０００年まで稼動しない可能性が高く、
また、当時の記憶容量のコストに起因する対応であったことも、うなずけなくはない。
しかし、１９８０年代以降に稼動するシステムにおいて、西暦２０００年を考慮していないのは、どうしても納得が行かない。
もちろん、考慮の上（入力の手間を省くとか）他の得失から、西暦２０００年を考慮しない設計としてあれば、２０００年まで使用しないシステムであるから、やむを得ない。
が、ほとんどのシステムは、期限を定めず使用するので、西暦２０００年を想定しないシステムは、どう見ても「設計ミス」としか見えないのである。
業界では、この２０００年問題を「新たな仕事」と捕らえているが、私は、「不良品を利用者が高額の負担をして修理している」としか見えないのである。
また、この２０００年問題というのは、システムの稼働日が、西暦２０００年に達する以前に、すでに発生しうる問題である。
たとえば３０年ローンであれば、すでに１９７０年の契約時点で、完済日が西暦２０００年を超えるので、とっくにトラブルとなるわけである。
他の業界で、類似の事があった場合、保証期間１年などの範囲で許されるであろうか。
たとえば、自動車が、走行メータの桁数の関係で一回りすることにより、００００となった時点で走れなくなったら、どうであろうか。
普通は、欠陥車と呼ばれるのではなかろうか。
そして、この問題を見る上でもう一つの観点がある。
官庁が「コンピュータの西暦２０００年問題」に着目し、対策を呼びかけ、また、官庁内部の対策状況を公表している。
ここで「対策済み」との表記が有るが、「確認の上問題が無い事を確認した」というのも広義「対策済み」であるが。
実際、現在稼動中のシステムで、ソフトウェアの実際の対策が必要な物が有れば、これは、欠陥品と言わざるを得ない。
少なくとも、納品後１年以内(または契約上の保障期間内)の物は、設計上の欠陥としての対応があってしかるべきと思われる。
コンピュータの西暦２０００年問題のついでに躍らされた、９９年９月９日
西暦２０００年問題にからみ、９９年９月９日が、９が並ぶ事から、コンピュータトラブルを警戒されていたが、特に何事も無かった。
当たり前の話で、９９年９９月９９日が訪れれば、確かにトラブルが発生するが、月は１２、日は３１迄しかなく、９９月９９日という日付は、この先何万年待っても訪れる事はない。
コンピュータソフトウェアの手法として、オール"９"(全て９が並ぶ事)を、処理の終了の判断とする事が多用されている。
９９年９月９日は、実は９９年０９月０９日であるから、９９年９９月９９日とは違う。そう、オール"９"は、ありえない値を使っているのである。
どうも最近、こういった問題に、的確な情報が流れてこない事に、疑問を感ずる。
新規作成日：1998年12月13日／最終更新日：1999年9月21日