真夜中の脳みそ

詩集「半熟卵」(Update:2001. 9.16.)

コラム「午前３時の天気予報」(Update:2004. 8.21.)

AIBO日記(Update:2003.11. 3.)

アルバム(Update:2003.1.31.)

「紺野」とは？(Update:2004. 8.21.)

Links(Update:2002.10.20.)

更新ログ(Update:2004. 8.21.)

Mail Me !

第24回　コラム：2000年問題への対策と実情

---

　コンピュータシステムの「2000年問題(英語でも"Y2K problem"と呼ばれる)」が近年大きく取り上げられている。しかも、2000年は来年であるので、ぐっと身近な問題の様に思えてきているのではないだろうか。しかしながら、この「2000年問題」についてどれだけきちんとした認識があるのだろうか、きちんとした対策が取られているのであろうか、実際に「2000年問題」が表面化したときにどんな影響があるのか、それらを理解しているものは少数なのではないのか、私を含めた大半はよく理解していないのではないのか、というのが私の認識である。

　ではここで、「2000年問題」とは何か、報道などでいろいろと報じられているので既におわかりと思うが、整理させていただく。現在稼動している数多のコンピュータシステムにはほとんどと言っていいほど「日付け判定処理」という部分がプログラムの中に埋め込まれている。この「日付け判定処理」の大半が西暦の「年」を下２桁のみで年を判断しているため、2000年の年"00"(もっと厳密に言えば2000年以降の年"01"、"10"等も同じ)を入力した場合、そのプログラムが作成されたのは1960年代、1970年代のため、1900年(先ほどの例では"1901"年、"1910"年)と誤認識されてしまう可能性がある、というのがいわゆる「2000年問題」である。さらに、この「2000年」は西暦で用いられているグレゴリオ暦では400年に一度の特別な年である。グレゴリオ暦では、「年数が４で割り切れる年は閏年とする。しかし、100で割り切れる年は閏年としない。特例として400で割り切れる年は閏年とする。」という決まりがある。これは、地球の公転周期が厳密に365日ではなく、365.256日であることを調整するためである(ちなみに地球の自転周期も厳密に24時間でない(23時間56分)ため、閏年だけでは補正しきれないため時々閏秒と呼ばれる補正を行う)。よって、1900年は閏年ではないが、2000年は閏年のため２月29日が存在し、この閏年判定も誤動作する可能性がある(この閏年判定の誤りはごく最近開発されたソフトウェア(OS)にも内在することが発覚してしまった。「2000年問題」は過去の負の遺産だけではない、ということの証明である)。

　実際にどのような誤動作が予測されるのか。例えば2000年を過ぎてからクレジットカードで買い物をしようとした場合に、そのクレジットカードの有効期限が過去(つまり1900年代)であるがために拒否されてしまうこととか、2000年１月１日をまたがって物品をリースすることができなかったりとか、預金、ローン等金利計算に誤りが生じてしまうとか、電気、ガス、水道等の料金計算に誤りが生じるとか、列車、航空機等の座席が予約できなかったりとか、飛行機内システムの日付けと管制塔のシステムの日付けが合致しなくて着陸を許可できなかったりとか、当該飛行機を認識できなかったりとか、(システム上)存在しない日付けの精算処理に失敗するとか実に多岐にわたる(しかしここで挙げた例は後述する方法で「対策済み」とされている)。

　なぜ、これほどまでに問題がある西暦の「年」を下２桁で判断しているのか。それは現在のコンピュータシステムの原形が作られた当時(1960年代、1970年代)、現在に比べると格段にコンピュータの性能が低く、メモリと呼ばれる記憶領域を確保するための半導体の値段が非常に高価だったことによる(また、上２桁は少なくとも100年間は同じ数字であり当たり前、であるので、JIS/ISOでも年を下２桁のみで処理することを承認している)。1960年代、1970年代のコンピュータはたとえそれが大型コンピュータであったにしても、1980年代後半のパーソナルコンピュータ(PC)よりも性能が低かった(これはある意味コンピュータというものが非常に短期間で劇的に性能向上したことも示している)。しかも、現在(1999年)PC用のメモリが64Mbytesで１万円以下で購入できるのに対し、当時は256Kbytesで数百万円、数千万円もした。バイト単価で見れば、約30年で約10万分の一以下に激減した。その少ないメモリの上で、コンピュータ資源を効率よく動作させるためのオぺレーティングシステム(OS)、コンピュータシステムとしてのプログラム(銀行の勘定系、列車の座席予約システム、資材等の発注予約在庫管理システム等々)を動かさざるを得なかったのだから、たとえ数字１桁でも節約したかった、というのは無理もなかろう。また、少ないメモリしか必要としないプログラムは多くメモリを必要とするプログラムに比べて動作速度は自然と速くなるので、メモリを節約したプログラムがよしとされた。

　これが背景としての第一の問題(グレゴリオ暦の解釈のミスはプログラム設計者の怠慢であるので些細な問題としておく)であるが、第二の問題として、この当時(1960年代、1970年代)に記述されたプログラムが30年以上にわたって現在まで使われることを想定していなかった、ということである。当時のプログラマは限られた資源の中でできる限りのことをしたまでで、将来のことを考える余裕がなかったことと、「ソフトウェア資産」という考え方が発生してきたことにも原因がある。つまり、コンピュータの機械本体が古くなってもソフトウェアは「資産」であるのでそのまま新しい機械でも動作できることをユーザ企業はコンピュータメーカに要求したこと、機能拡張を行う場合でも、既に問題なく動作している部分のプログラムには手を入れず、「資産」として使用する、いわゆる「改修」という機能拡張を次々としてきたことだ。既に問題なく動作している部分(つまり「資産」)に手を加える、もしくは新規に作成するということは、単年度の開発コストとしては見た目大きくなる。既に問題なく動作している部分は資産としてそのままにし、「改修」という機能拡張は新しく作る部分だけを考えればよいので単年度の開発コストとしては見た目小さくなる。という考え方がユーザ企業の経営者の頭の中にあったためである。コンピュータシステムの運用コスト、複数年度にまたがった開発コストまで考えれば、定期的にシステム全体を新しく作り直した方がトータルではコストは少ないはず(そうしていればそもそも「2000年問題」なんて発生しなかったはず)であるのに、経営者の近視眼的な目ではその場その場を切り抜けた方が無難、安定稼動しているシステムを作り直すことに対して恐怖心を抱いた、作り直すだけの予算が組まれなかった、という理由である。特にこの「作り直し」を拒む、というのはインフラストラクチャとなるコンピュータシステムの場合が顕著である。あくまでもこの「資産」という考え方は見た目にしか過ぎなく、誤りであることは言うまでもない。

　では、対策はどのように行われたのか(行われてきているのか)。対策は大きく二つの方法がある。この際だから西暦を４桁で処理しようというもの、(見た目の)「資産」を活用するためなんとかして２桁で処理しようとするもの、である。４桁で処理をし、閏年判定もきちんとすればなんの問題もない(規模を考えればほとんど作り直しに近いかもしれない)。ところが問題はこの抜本的対策を行ったものはごくごく小数に限られてしまっている点だ。つまり、(見た目の)「資産」を活用するためなんとかして２桁で処理しようとする対策の方が大半で、それをもって対策は完了とした、と判断しているのが実情である。どのように２桁でその場しのぎをするのかというと、下２桁"YY"が与えられたとき、ある決まった「XX」という数字以下であったら"20YY"年、「XX」以上であったら"19YY"年と判断しよう(この間は４で割り切れる年は必ず閏年である)、という対策である。この対策は一見解決した様に見えるが、実は問題を先延ばしにしただけで、"20XX"年になってしまえばこの問題は再浮上するのだ。過去30年に渡って使い続けてきたプログラムが今後"XX"年に渡って使い続ける可能性があるのか、それはどう考えてもゼロではないだろう。各コンピュータメーカ、ソフトウェアベンダは自社製品について「2000年問題対策は万全」と銘打っている(日本の約450の金融機関も対策済みと報じている)が、大半が問題を先延ばしにしたに過ぎないのではないのか。根本的な対策はしきれていないのではないのか。さらにこの対策で問題を実は深めてしまっている。しきい値である"XX"年が対策したコンピュータメーカ、ソフトウェアベンダによってまちまちである、ということだ。"2000年"はみんな気が付いたが、"20XX"年になったらこのように大きな問題としてとらえられるのか。

　しかも、「日付け判定処理」はプログラムの随所に埋め込まれているので、どの箇所を対策したらよいか特定するだけでも困難である。しかも、大半が先延ばしにした不完全な対策であるがためにどこでどんな影響が起きるのか予測不能だ。世界中のコンピュータシステムはネットワークで接続されているので、実際に一箇所でも問題が具現化したときに生じる混乱は予測不能と言っても過言ではないかもしれない。ちなみに巷にあふれている「2000年問題」チェックツールも万能ではないらしい。

　確かに「2000年問題」はソフトウェア(プログラム)の問題であるのだが、実は様々なもの(家電製品、観測、測定装置、エレベータ、産業ロボット等々)に組み込まれているチップ(IC、LSI、VLSI等総称して)のマイクロプログラムにも実は「日付け判定処理」があり、やはり「2000年問題」に抵触するものがある、というのも明らかになってきた。こうなるとただの「ソフトウェアの問題」で片付けられなくなる。確かにマイクロプログラムもソフトウェアの一種ではあるが、扱いとしてはほとんどハードウェアである。いくら修正したチップを作り直しても、既に組み込まれているものを交換するのはもはや無理だろう。

　これだけでも充分悲観的になる要素は充分なのに、まだ隠されている事実がある。私が実際に直面した事例だが、ある総合電機メーカH社が提供しているOSに「2000年問題」に抵触する箇所がH社の社内調査で検出された。その対策版をユーザ企業である私の勤務先にも提供されたのだが、この対策版が実は別な「2000年問題」を引き起こしてしまうことが追加調査で発覚し、さらに修正版を配布する、という顛末があった。もともと問題があった箇所の修正はできたが、修正を加えたことにより別な誤りを埋め込んでしまった、という失態である。このことは多分H社に限ったことではないかもしれない。ソフトウェアの誤りに対しての「修正」は別な誤りを埋め込む危険性をはらんでいるのだ。

　今やコンピュータシステムがなければ私たちはこの高度な文明社会を維持することはできないし、生活が極端に困難になると言っても過言ではないだろう。しかもそれらコンピュータシステムはいざその日その時になってみないとどんな事態になるのか予測しきれない問題を抱えて現在稼動中である。その問題への対策も万全であるのか予め検証することもかなり困難であると思われる。多分「時間切れ」となってしまう可能性が高い(あくまでも可能性の問題であるから、楽観的に考えれば問題は発生しないかもしれない)。第三次世界大戦が勃発でもしない限り、誰かの書いた詩を預言の様に曲解してしまったことが本当に起きない限り、その日はやってくる。とりあえず自分の身を守る自衛の策として全ての銀行口座は直前に通帳記入しておいて、交通機関は一切使用せずに、ネットワークに接続せずに嘲笑しながらその日を迎えよう。

(1999. 2.21.)

今回参考にさせてもらったページ

• 宇宙開発事業団　http://www.nasda.go.jp/
• PC WEEK & Yahoo! JAPAN "Y2K Watch"　http://news.yahoo.co.jp/y2k/
• Y2K JAPAN　http://www.y2kjapan.com/

Prev　　　Next