先月は注意報の夏休みをいただきました。悪しからず。さて、７の月も何事も無く過ぎました。予言は杞憂でした。が、猛暑がつづいています。そのせいでしょうか、あるお客様に納めたソフトで、たてつづけにトラブルが起きました。ある日、本店からおかしいという連絡。つづいてＦ店からも。対処をしてやれやれと思った２、３日後にＫ店から、つづ けてＭ店から連絡。その対処しているときにＡ店からも．．．何事も無かったのはＨ店だけ。しばらくしてそのお客様のエライさんから「今回のトラブルは２０００年問題と関係あるのか？」との問い合わせ。対応した社員は即座に「２０００年問題は関係無いです」。トラブルの原因はソフトのミスであったり、ウィンドウズの問題点であったり、それぞれ違っていたのですが、それにしてもこうも連続して起きるのは初めてでした。
巷では２０００年問題、カッコつけてＹ２Ｋ（Ｙｅａｒが２キロで２０００年）問題が賑やかになっています。はっきり言って２０００年１月１日に何が起きるかわかりません。が、何も起きないということは無いでしょう。
第１報でお報せしたように、２０００年問題とはコンピュータの日付の憶え方が起こす問題です。たとえば１９５０年１月１２日を「500112」と年の１９を端折って記録しているため、２０００年１月１２日は「000112」となり、１９００年と区別がつかなくなるのです。それで、２０００年対策とは、日付の年を４桁で記録するようにプログラムを改修することになります。ところがこのプログラム、作った人間でないとわからないから、解析作業からはじめるとけっこうな手間になるのです。
私自身、以前勤めていた会社でダムの警報装置のプログラムを担当しました。手元に資料がありませんので、年は２桁か４桁か定かではありませんが、装置を安く仕上げるため記憶容量を節約したと思いますので２桁でしょう。２０００年問題を起こします。後任のどなたかがきっと改修してくれていると信じるしかありません。でないとダムから誤報が流れるかもしれないのです。そう、その後担当した自動車電話はどうだったか．．．
プログラムを改修するにあたり、明らかに日付である個所は簡単に対処できます。ところが、隠れた日付があるのです。それはコード化したデータです。たとえば、当社のあるお客様では、受付番号を「９８０１２３４」というふうにコード化してつけています。これは９８年度の１２３４番目という意味を持たせています。また、別のお客様では会員番号を「０１１０１２３４５」というふうにコード化し、３・４桁目の１０が平成１０年度を意味しています。お気づきのように年が２桁しかありません。コード化したデータの年を使って何らかの計算をしていたら、２０００年問題です。
コード化は、記憶容量の節約も目的ですが、コードを見ただけでデータの内容がある程度わかるからという目的もあります。また、入力の手間が省けるというメリットもあります。現在のようにワープロが普及してキーボード操作があたりまえになる前の時代は、盛んにコード化していました。今日ならコードを憶えて入力するより、直接文字入力した方がよい場合もあります。
どれかのコードに２桁の年が潜んでいたら、それが計算に使われていたら・・・。プログラムの解析・改修作業は一筋縄ではいかないのです。それにコード化は一例にすぎません。年２桁は別のところにも潜んでいることでしょう。ですから、２０００年になってみないとどうなるかわからない、ということになるのです。
２０００年１月１日、暮れのうちにビデオデッキに１月１日の録画予約したのに、デッキは１９００年と判断して録画してくれませんでした、という程度ならお笑いですみますが、物流が止まってオイルショックのようなパニックになったり、銀行がダウンして取りつけ騒ぎが起きたり、病院で装置が停まって患者が・・・、原子力発電所が暴走して・・・、はたまたミサイルが飛んで来て・・・。
アメリカでは「２０００年問題は起こるのだ、それにどう対処するか」という危機管理体制に取り組んでいるといいます。日本では「何も知らせず、無事２０００年を迎えられた方が幸せ」と政府高官がおっしゃているそうです（日経新聞）。どうなることやら。
今から、大晦日から元旦にかけてどう過ごそうか思案しています。とりあえず、多少の現金と食料は用意するとして、その前に入院だけはしないよう健康に気をつけます。旅行には行きません。都内のホテルで優雅に過ごそうかと思ったのですが、もう満杯。２０００年対策要員のために確保されてしまったとか。
ＴＯＰへ