  
|
| 経済の研究No.81 |
| 迫り来る、１９９９年問題 |
「おや？」と思われるかも知れません。2000年問題というのは聞いていましたが、近頃1999年問題というのが出ています。これへの対策をしておきませんと、コンピュータが暴走したり、データが吹き飛んだりしてしまうのです。
コンピュータ言語というのは難解です。英語がベースである上に、自然言語ではないので、経理屋には理解できません。プログラム屋はプログラムを書きますが、処理の中身は分かりません。経理の素人であるプログラマーが経理システムを構築するのは無理な相談です。そこでシステムエンジニアが仲立ちして経理屋とプログラム屋の橋渡しをするのですが、上手くいかないことが多いです。このため、完成したプログラムが想定したとおりの動作をしないバグ（bug：エラーの原因を「虫」と呼んでいるのです）を発生します。バグに対しては、動作が停止してしまう致命的エラーと、動作は継続できるが結果が保証されない警告エラーが出されますが、これは発見される都度に修正されて、何とか体裁を整えられます。
エラーが発生しても見落とすことは良くありますし、通常操作で発見しにくいものもあります。バグを発見するための作業であるデバッグは頻繁に行われますが、致命的なエラーはデバッグで見つけにくいところに潜り込む習性があります。非常に危険な存在なのです。ところが、バグを発見しては修正するという個別対応を繰り返すウチに、プログラマーにさえプログラム全体が理解できないことが多々あります。また、プログラムを最初から構築すると開発時間と費用が膨大になるので、サブルーチン（自己完結した小道具の一種）やライブラリ（サブルーチンの集合体）を使いますが、これがシステムを一層意味不明にすることがあります。中身が見えにくいためにチェックが難しいのです。
これまで問題視されてきた2000年問題は、その一種です。まず昔のコンピュータは高価な記憶装置を使っていたため、年号を４桁（例：1998）ではなく２桁（例：98）で表現してきました。今では見掛け上４桁で表示するようになっていますが、コンピュータ内部では相変わらず２桁が基本です。このため2000年を00で表すことになり、2000年は1999年の翌年ではなく、99年前と認識してしまう問題があります。このため期間計算が大きく狂ったり、不要データと誤認して大量のデータが消滅したりする危険があります。最近ではクレジットカードの有効期限を2000年以降に設定したら無効カードと判断された・・・という笑えないトラブルがありましたし、会計ソフトでリース料金の算出ができなくなったというトラブルもありました。2000年問題はソフトウェアをきちんと書き換えれば回避できる問題ですが、上述のようにプログラマー自身がプログラムを把握できないため、万全とは言えません。また中小企業では、電算システムの更新が進まず、10年以上前のシステムをそのまま使っている例が多く、コストの問題で2000年問題に何ら対処をしていないようです。また10年も経てば、当時のプログラマーが行方不明であったり、受注企業が消滅していたり、ということもあります。
次に1999年問題です。これは最近指摘され始めたのですが、データベースのエンドコードに「99」や「99/9/9」が使われているソフトウェアが多く、誤動作の原因となるのではないか、と言われているものです。データベースでは、何かをキーワードに使ってデータの並べ替えや検索を行います。このため、とりあえず「９」や「99」を使うということがあり、通常はエンドコードを発見すると最終データと判断して処理を打ち切ってしまいますから、1999年１月１日や1999年９月９日、あるいは1999年12月31日にデータが吹き飛ぶ可能性は否定できません。
もう一つの1999年問題は、ＧＰＳの日付管理方式です。何故かＧＰＳは２進膜�i10ビット）で日付管理をしています。1980年１月６日を基準に何週目か日付を認識しているそうですが、1024週目になる1999年８月21日でデータがあふれて1980年に戻ってしまうと言います。航空機や船舶はＧＰＳデータから日付を修正するシステムを使っていることもあり、異常を来す可能性があるそうです（日経ビジネス12月14日号を参照）。
いずれにせよ、膨大な費用を投じて、これまでのプログラムを洗い直すのか、最初から新しいシステムを構築するのか、の選択を迫られています。望ましいのは新構築ですが、これまでのデータを活かそうと思うとなかなか難しいところです。また今回のように新しい問題が発見されると二度手間になるので、まだまだ思い切った対策に手が打てないかも知れません。どんなにシステムを洗い直しても完璧はありません。とくに昔ながらの逐次処理方式のプログラムは、全体としてどんな動作をするのか予想できないため、そのときに成ってみないと分からないとも言えます。
それでも対策を講じないよりはマシですので、是非是非1999年問題、並びに2000年問題に取り組んでいただきたいと思います。それと、いつシステムやデータが吹き飛んでも良いように、システムのバックアップだけはお忘れなく。
98.12.12
|
補足１
＃N問題がどれほど難しいかといいますと、世界でシェア最大のＯＳである、マイクロソフト社のウィンドウズでも解決できていないことが挙げられます。ウィンドウズ95では、2000年問題が指摘されたために修正ソフトが配布され、その後のバージョンでは解決されていたそうです。ところがウィンドウズ98で再びバグが発見され、修正ソフトが配られることになりました。
しかしこれでも万全ではありません。ウィンドウズ98上でどんなソフトを使うのか、が次なる問題になります。その組合せ次第では新たな2000年問題（とくにどんな修正が施されたのか分からないため、例えば2000年を2100年と表示するソフトが出てこないとも言えません）を生じる危険があります。さらにネットサーバ上でのトラブルも想定され、ある日突然にアクセスが禁止されるという危険もあります。
98.12.12
|
補足２
コンピュータ言語のうち、危険度が一番に高い言語はＣＯＢＯＬだと言われています。商業高校で積極的に教えているこの言語は、一行ずつ命令文を追加するのが簡単で、誰でも修正できることが優れているとされています。ウラを返しますと、応急用の絆創膏の上から、新しい絆創膏を重ね張りしているような部分もあり、誰がどんな意図で付け足したのかサッパリ分からない・・・という命令文を含んだシステムも多くあります。そんなシステムが一斉に反乱を起こすと、まず手が付けられないでしょう。
98.12.12
|
補足３
小さな2000年問題というのもあります。地球の公転周期は365.2422日です。このため、４年に一度閏日を入れていますが、400年に３度閏日を入れない、という複雑な処理が必要です。便宜上、400で割り切れず、100で割り切れる年に２月29日を入れないとしています。この処理をしても毎年１秒のずれができるため、年に１回、閏秒を入れています。つまり2000年は閏日がありますから、パソコンの日付が一日狂う可能性があります。
ポン太も学生時代に沢山のプログラムを書きましたが、万年暦のソフトを作るために、随分と苦労をしました・・・。今となっては自分のプログラムさえ手直しできません。
98.12.12
|
補足４
お客さまの声をご紹介します。「2000年問題はコンピューターのユーザが解決する問題だと言われていますが、本当はメーカーやソフトハウスが解決するべき問題ではないでしょうか。2000年が急に来ることになったわけではないので、この問題を意識していなかった専門家にこそ解決する責任があるのではないでしょうか」（匿名・男性）とのご意見です。そういえばＩＢＭとかが2000年問題の呼びかけをしていますが、どうもビジネスチャンスって感じの呼びかけをしていますよね。メーカーの方のご意見はどうですか？
98.12.21
|
補足５
マイクロソフトの2000年問題は、マイナーソフトにまで手が回らないようです。マイクロソフト製のデータベース開発用ソフト「フォックスプロ」シリーズで2000年に関わるバグがあるにも関わらず、依然としてマイクロソフトは対応できていないそうです。ソフトの瑕疵を知りながら、修正ソフトの配布を行わず、かつ販売は続けていたことを問題として、アメリカで集団提訴が行われているそうです。
またＩＢＭは病院の患者用診察予約システムに2000年問題があることに対応したが、その修正ソフトを有償配布しようとしたことから問題化している。現在、医師らが集団提訴を行っているそうです。以上のほか、アメリカでは40件前後の訴訟が提起されているそうですが、日本では概ね平穏です。お国柄もありますが、危機意識の持ち方が違うようです。
98.12.31
|
|
|