西暦２０００年問題・現場編

　　　　　　１９９９年１月　　by Ｍｕｌｅ

西暦２０００年まであと１年にせまり、コンピュータの２０００年問題もだいぶ騒がれるようになってきたよね。食料の備蓄が必要なんて話もあるみたいで、以外に重大な問題のようだね。でも、マスコミで言われていることはどうも全貌を捉えていないように思えるんで、不足分をちょっと書いてみたんだ。
だいたいは、僕のまわりの主にオフコン（オフィス・コンピュータ）やパソコンの開発現場から、先輩や同僚の経験なんかを中心に拾った話だよ。

Ｗｉｎｄｏｗｓ９８のバグ

Ｗｉｎｄｏｗｓ９８には２０００年問題関連のバグがあり、現在修正プログラムを配布中（１月下旬予定・・・３月になってやっと公開）。導入しておいたほうがいいかも、多分。
なお、Ｍｕｌｅブランドのシェアウェア／フリーソフトは、ＰＣの日付けを２０００年や２００１年にしたテストもちゃんとやってあるから、ＯＳがきちんとしてれば問題無い（はずだ）よ。

１９９９年問題

９９年１月になって、一部の医療機器に年号として９９を入力したら動作が停止してしまったという報道があったけど、気づいたカナ？
「２０００年問題が１年早く始まった」なんて報道されたけど、実態は９９を「停止コード」としていたためらしい。マイコン組み込みのシステムではよく使う手だね。
でも、医療機器に組み込むマイコンなんて、事務処理用よりずっと歴史が浅いのに、メーカーは１９９９年までその製品が使われることを想定できなかったんだろうか。この分だと、２０００年に突然停止して患者を殺してしまう機器があっても不思議じゃないね。ちゃんとメーカー名を公表すれば、少しは未然に防げるだろうに。

２０００年問題と和暦

ある２０００年問題のみを扱った書籍に、「日本ではすべて和暦で処理しているシステムが多い。そういうシステムは内部処理も和暦で計算しているから、２０００年問題は関係無い」と書いてあったのを見つけたんだけど、要注意。その著者のまわりではそうなのかもしれないけど、僕の知る限りは全然そんなことはないね。和暦を入力するソフトでも、特に昭和５０年代以降に作成したものは、いつ改暦されてもすぐ対応できるように内部計算は西暦で行っているもののほうが多く、やっぱり２０００年で問題の出るシステムもありうるということだ。
危いのは、こういった専門書籍の著者が、無知のために「和暦のシステムには２０００年問題が無い」と言い切ってしまう事だ。政府の２０００年問題の諮問機関に、こういうオトボケな委員がいないことを祈ろう。

２０００年問題の責任者

責任者について、あまりきちんとした報道が無いようなのが不思議だ。契約で「２０００年までは使用されない」とうたってあるシステムを除けば、ソフトウェア開発会社の責任に決まっているのに、なぜユーザーがその改修費用を負担しなければならないのか。
また、汎用機（大型機）のシステムは、コンピュータメーカーのＳＥが毎月高額の契約で面倒を見ているはずなので、２０００年問題を指摘しなかったメーカーの責任だろう。これらのＳＥが経験不足の新人だったりして（多いんだ、そういうことが）、今のトラブルを増やしたのは間違い無いね。
しかし、もしメーカーやソフトウェア会社に責任をとらせたら、倒産続出だろうな。

ただ、システム構築の打ち合わせ段階で、
　ＳＥ「西暦２０００年の対応や元号の改暦処理を組み込みますか？」
　ユーザー「そんな先のことより、まずはシステムの完成が先だし、予算もそんなに無い」
というような会話があった事例は結構あるようだ（僕も経験がある）。マスコミで言われているように、ＳＥが仕事を端折ったという事例ばかりではないことは確かだが、小規模のシステムではそれらの打ち合わせ録などは残っていないので、結局責任がだれにあるのかつきとめるのは難しいね。

いずれにしても、訴訟が頻発し、それで経済活動が停滞して「２０００年問題による全世界同時恐慌」なんてならなきゃいいが。
おーい。責任者出てこーい。

２０００年２月　うるう年問題

うるう年の計算を入れてないために、工場全体が暴走したということもあったくらいで、結構深刻だ。しかし２０００年のうるう年は特例中の特例なので、このバグはかなり潜在しているはずだ。

よく話題になるように、「うるう年」は次の様に決められている。
　１．西暦年が４で割り切れる年をうるう年とする。
　２．西暦年が１００で割り切れる年は、例外的にうるう年としない。
　３．西暦年が４００で割り切れる年は、例外の例外としてうるう年とする。
つまり、１９９２年、１９９６年はうるう年だが、１９００年や２１００年は４で割り切れても規則２によりうるう年ではない、２０００年は１００で割り切れても規則３によりうるう年である、ということになる。

ここまでは書籍やＷｅｂでもよく目にするのでいいが、問題はこれをプログラミングするプログラマが、これらをよく理解しないでシステムを作っていることだ。上の規則を半端に覚えていて、規則２を計算して規則３を計算してないシステムは、結構ある。僕自身見聞きしたので、これは事実だ。
プログラマが「何か複雑な規則があったが、きっと２０００年はその複雑な規則に当てはまるのでうるう年ではないのだ」と勘違いしていることもよくある。三流プログラマ（技術がというより、プロとしての自覚が三流って意味ね）は、調査／確認しようなどとは思いもつかないのだ。
数人以下の小さなプロジェクトで作られたシステムは、プロジェクト関係者が全員この病気にかかっている場合があるので、とてつもなく危険だ。上記の工場（海外）なんて、結構大きい会社なのに、１９９６年のうるう年すら計算に入れてなかったんだから。

現実的には、規則２と３は全く無視して、４で割り切れる時がうるう年ということだけを計算しておけば、西暦２０９９年まで問題無いわけだ。三流プログラマに、４で割り切れる部分以上の複雑な仕様を要求すれば、かえってバグが増えるだけだ。
それに、現在のコンピュータ・システムを１００年後にも使っているなんてことはありえないしね。

危いのは、雑誌やＷｅｂでもこの複雑な規則のことは触れられても、「プログラミング上は４で割る分だけ考慮すれば良い場合が多い」という極めて単純なことにほとんど触れられていないことだ。

君の会社の取引先は大丈夫か？入金額は正しいか？
工場のプロセス制御は安全か？３月１日は工場を止めたほうが良くはないか？

２０ｘｘ年問題

ＭＳ−ＤＯＳやＷｉｎｄｏｗｓ９５／９８ではＯＳとそのファイルシステム自体が２０４３年（２０３ｘ年だったかも）までしか扱えない。
ＵＮＩＸも２０３７年までだし、Ｗｉｎｄｏｗｓ−ＮＴもバージョンによっては２０７ｘ年までだったりするらしい。
２０００年問題の轍（てつ）を踏まないためにも、２０００年問題が片付いたら直ちに対策を始めて欲しいものだ。僕もその頃まだ生きてるつもりなんだから。Ｗｉｎｄｏｗｓで制御された医療ロボットが２０４４年問題で暴走して殺されるなんてのは絶対イヤだよね。

３００００年問題？

上記のうるう年の３つの規則では、３００００年くらいすると実際の季節と１日ずれてしまうので、
　４．西暦年が３００００で割り切れる年は例外の例外の例外としてうるう年としない。
という規則が必要になる・・・かもしれない（笑）。その前に西暦年が５桁になる時に問題になるけど（笑）。

影の２０００年問題

マスコミで報道される２０００年問題には、上に書いたような「現場の声」がほとんど出てこない。それに、プログラマには無資格でなれることもあり、現場の人材の何割かは”とてつもなく低レベル”だ。これら、認識されていない「影の２０００年問題」によって、予想外のトラブルが出ないか、注意しておいた方がいいよね。
そんなわけで一言。
　トラブルは現場で起きているんだ！会議室で起きているんじゃない！！

間違いや、「こんな事例もある」など、意見があったらメール送ってね。