「２０００年問題って何じゃ」（１９９９／０６／０７〜０７／０５号）
世間で騒がれている２０００年問題。
来年になるとコンピューターが異常動作するというものだが、
騒がれているにもかかわらず、その詳細を知っている人は実は少ない。
そこで、一応その手の仕事をしている（していた？）わけだから、
それに付いての解説はしなければ成るまい、ということで
してしまうのである。
２０００年問題と言うのは、実は１つではない。
複数の問題が重なっているのだが、２０００年という年というかその数字表現が
いくつかの面で特殊であるために起こる。
また、「コンピューター」だけの問題だと思っているかも知れないが、
実は世の中にある時計というかカレンダーもまた狂う可能性がある。
専門用語は余り使う気はないけど、それなりに出てくることもあるかもしれないので、
解らなかったら、個別に質問するように。
（因みにこれと同じような文章を会社でも書いた。周りにソフト屋さんが
ほとんどいず、どうも認識が甘いような気がしたので思い切って書いたのでった。）
・・・
まずは簡単なカレンダーの狂いからいこう。
２０００年は閏年かどうか。
答は閏年である。
「そんなもん、４年に１回、４で割り切れる年だから当たり前だろ」
といわれるかも知れないが、実は当たり前ではない。
閏年には実は次のような法則がある。
普通の人が知っているのは「４年に一度、４で割り切れる年」である。
ところが、実は閏年の法則はそれだけではない。
１００年に１回は閏年でなくなるのである。
ということは、１９００年、１８００年・・・等は閏年ではないのである。
ところが、４００年に一度は閏年になる。
そう、２０００年という年は、この全ての条件を満たす非常に珍しい閏年なのである。
コンピューターのプログラムや、時計に組み込まれたカレンダーにおいて、
単純に４で割り切れるとし、だけで処理されていれば、
たまたま２０００年は問題無いが、１００年に一度閏年ではないまで
入っていたら狂ってしまうのである。
要するに、それを作った人間の閏年の法則に付いてどこまで知っていたかを
問うような問題なのである。
・・・
先の規則に従えば、「１６００年も珍しい閏年だった」といえそうだが、
実はそうとは言い切れない。なぜなら、このような法則が定められたのが
１６００年より後だからである。いわゆる太陽暦（グレゴリオ暦）
というものの規則は１６００年より前にはあてはまらない、かも知れない。
ということは、２０００年は、初めて全ての条件が成り立つ珍しい年、
といえるわけである。ほら、なんとなく何かが起こりそうな気配が
してきたでしょう(^_^)/。
そもそも何でこんな「閏年」が出来るかといえば、
地球が太陽の周りを回る公転周期が３６５日ではなく、３６５日と１／４日
だからである。
地球の公転、いや、惑星が恒星の周りを回る公転に付いて初めて明らかにしたのは
ヨハネス・ケプラーである。
彼の発見した法則は３つあるが、そこから地球の公転を言い表すと次のようになる。
１、地球は、太陽を重心のいずれか置く楕円の軌道で公転している
２、太陽と地球の移動範囲を結ぶ円弧の面積は一定である
後の１つは確か、太陽に近い天体ほど速く公転する、だったと思うが失念した。
（だから、地球の公転が１年とすると、より太陽に近い金星は１年未満、
太陽から遠い火星は１年以上の公転周期なのである。公転周期は惑星の大きさや重さ
にはよらないのだ。）
１はちょっと数学的だが、地球は太陽の周りを円軌道を描いて移動している
のではないということである。卵型のような楕円形の軌道で動いている。
彼のこの発見は、地球から見た火星の後戻りするような動きから発見された。
（因みに、金星の軌道はほぼ完全な円軌道である。彼が金星を観測していたら、
この大発見はされなかったであろう。）
・・・
地球の公転速度というものは、１年を通じて同じではない。これが２である。
太陽に近いところでは速く、遠いところでは遅く移動するのである。
この説明は文字だけではしにくいが、図を書けば解り安い。
「じゃあ、太陽に近い時が夏で、そうでない時が冬だな」と思われるかもしれないが、
実は外れである。北半球では、太陽から遠い時が夏となる。これは、地球の暑さ寒さは
太陽からの距離より太陽光の入射角に依るということである。
遠く離れた太陽からの光は地球に差し込む時はほぼ平行と考えて良いが、
地球は球面だから、赤道付近では垂直に、そこから南北に離れるほど斜めに日が
射すことになる。地球から見て、太陽が高い角度で回るほど暑くなるのである。
それは赤道付近の暑さと北極／南極の暑さを比べれば直ぐ理解出来る。
ただし、これは地球の軌道が円に近いのだからいえることで、楕円がきつく
太陽からの距離の差が大きく出る火星では本当に距離による差がないかは不明。
それもあるなら、南半球の夏の方が若干でも暑いのかも。
（南半球では太陽に近い時に夏になる。）
・・・
「閏」と言えば、実は「年」だけでなく「秒」もある。
ある時、１分が６０秒でなく６１秒になるのだ。
５９、００ではなく、５９、６０、００となるわけだ。
こういうのを「うるう秒」という。
原理は閏年と同じ。
こちらは割方頻繁に来るのでテレビなどを見ているといい。
（必ずどこかが言うから。）
・・・
まったくの余談だけど、何で１９９９年が２０世紀の最後の年じゃないか解る？
（２０００年が２０世紀最後の年。どこぞの政党が「来年は２１世紀！」
等といって馬鹿にされてたけど。）
それはキリスト教には西暦０年がないから。
西暦はＡＤ１年から始まる。そこから１００年毎に区切るからこうなるのである。
その前はＢＣ１年であるから、ＡＤ０年は存在しない。
もっとも、元号にも０年は存在しないから、普通に考えれば別に０年がないこと自体
おかしくはないけど、ＢＣなんてことを言うからおかしくなってしまう。
元号ではそんなこと言わないもんなぁ、「平成前？？年」とか。
まあ０を発明したのはインドだからしかたないとも言えるけど。
１９００年代が２０世紀なのはわかるよね？
これは英語で書けばはっきりするけど、
The Twentyth Century
~~
ということで、第２０番目の世紀と言うことだから。
ＡＤ１〜１００年が１世紀だからね。
・・・
さて、このような閏年の判定間違いは、いわば単なる表示上だけの問題であって、
大したことではない。カレンダーが狂ってしまう、時計が狂うということは
日常よく有ることだからだ。
そんなものはカレンダーを直せば済むだけの話である。
日付が狂うことでの問題は、例えばその日付から別の処理に入るなどの
（制度が変わるとか）などの時には大きな意味を持つが、
普通のそう言った重要な場合には日付の確認をさせるのが普通だから、
大丈夫であろう。
まして、２／２９と３／１の違いは大きな問題ではない。
期が変わってしまう３／３１と４／１ならその差は大きいだろうが。
だから、２０００年問題と言って、わざわざこれを上げるのは付け足しみたいな
ものである。
しかし世間では「これが重大だ！」と書いている記事が余りに多い。
そんな事書くのは、実は２０００年問題の真相を知らない事を表してしまう、
恥ずかしいことなのである。
２０００年問題で一番恐いのは、年号の管理方法の破綻によるものなのである。
・・・
昔のソフトでは年号の計算に次ぎのような処理をしているものがある。
いや、そういうものが多い。
１、年号は西暦の下２桁だけで持っている
３、あり得ない年号は特別な意味に使っている
１の原理は簡単であろう。１９９９年なら９９、２０００年なら００となるわけだ。
これだけなら問題はないのだが、これで差分を取ると異常が出る。
２つの年の間を計算する時だ。例えば、１９６５年から１９９９年までの間の年数は、
１９９９−１９６５＋１＝３５
９９− ６５＋１＝３５
である。これは下２桁の数字だけで行っても変わらない。
ところが、２０００年以降になるとおかしくなる。
２０００−１９６５＋１＝３６
００− ６５＋１＝−６４
例えばその人の年齢を計算しようとした時に異常が出るのだ。
一旦狂ってしまうと、この結果を使った後の計算も当然狂う。
この年数から利子を計算するようなことがあれば、それも狂う。
マイナスの利子が出来るかも知れないわけで、下手すると預金から引かれて
しまうかも知れない。う〜ん、恐い。
（引かれる利子が戻ってくるならいいけど。）
今年中に一度全預金を引き下ろしておくか？そんなにないけど(^_^;)。
・・・
実はこの問題は、２０００年問題の中でも、修正のしやすい部分である。
マイナスが出たら１００を足せば良い。
当面はこれでしのげる。
００− ６５＋１＝−６４
＋１００＝３６
また１には次のような問題もある。年号の入力において、
手間を省くため西暦の下2桁のみを入力させ、しかもその
上位桁を１９００と固定している場合がある。また、表示でそうしている場合もある。
この場合、データは4桁になっているなら、入力/表示そのものを4桁にすれば良いだけ
である。 ただ、画面/印刷レイアウト上、変更が難しい場合もある。
データそのものが2桁の場合、データ読み出し時に年代別にわけ、００〜？？年は
2000年代、それ以上は1900年と振り分けるだけで行ける場合がある。MS-DOSの場合
1980年が起点となっているため、00〜79なら2000年代、80〜99なら1900年代と分ける
場合が多い（Windows3.1も同じ）。
さて、２はどういう問題かというと、
マイナス年号や使われない年号、例えばそのプログラムで使う年号で１９８０年以前が
ないなら、００〜７９は別の意味に使う等という処理があるということだ（例えば
登録開始の年号を持っている場合、そのシステムが動き始めた年より前の年号は
あり得ないので、そういう年の数字に特別な意味を当てることがある）。
このとき、マイナスの年号が入っていた場合は、その人は解約されているから
処理しないとか、下手すると次の処理で削除するとか、そういう意味に使われて
いることがあるのだ。
この修正は厄介だ。プログラムによってどの数字にどんな意味が割り付けてあるかは
そのプログラムを読まないと解らないからだ。
・・・
２０００年問題では「画面が消えた」とかも言われるけど、
今までに述べた話からでは、なぜそうなるかは解らないだろう。
普通に考えるなら、数字上の異常や動作の不都合があったとしても、
画面が消えることは無いように思う。表示の桁がずれることはあったとしてもだ。
ところが、ここに大きな落とし穴がある。
コンピューター内部ではデータとプログラムが同じ記憶領域上に置かれている場合が
ある、ということだ。
データがおかしいとデータエリアを飛び出してプログラムを書き替えてしまう
ということがあるのだ。下図を参照して欲しい。
絶対番地 000 100 200 300 400
[ プログラム ] [データ ]
相対番地(ﾃﾞｰﾀ先頭から) -300 -200 -100 000 100
プログラムとデータは、記憶領域上に置かれるが、この記憶領域には番地と
呼ばれるものがつけられている。住所みたいなものだ。
通常プログラムは、データをその先頭から何番地目のところに入れなさい、
というふうに書かれている。先頭から何番地目と言うような相対値であり、
普通はマイナスはあり得ない。０〜の正数だけのはずだ。
ところが先に述べた通り差分など取り、それを相対値に使った場合、
マイナスの相対値が出てしまう。
ということは、データのマイナス何番地目ということになり、
結局、本来データが入るべき部分ではなくプログラム本体の上に
書き込んでしまうことになるのだ。
ということはプログラムが破壊されるということで、プログラムがその場所を
実行しようとした時に異常が起こる。
このように、通常は正しい入れ場所に入るべきデータが、変な位置に入り、
しかもそこがプログラムのある場所の場合それが破壊されてしまうのだ。
こういう時のバグの出方はそのデータによっても変わるので予測が付かない。
この手のバグは非常に厄介で、多くの場合実際に表に見える現象、
例えば動作不良や表示の異常からは原因が特定しづらい。
従って、対策もうちにくい。
これが２０００年問題の一番・最大の厄介な点なのである。
プログラムの破壊が問題なら、プログラム本体とデータの位置を離すとか、
プログラムを書き替え出来ないようにしてしまうとか方法はある。
しかし、この場合も、データが本来記憶されるべき場所に入らないのは
同じだから、異常の起こり方は違えども、異常そのものは残る。
・・・
そもそもなぜこういう問題が起こるのか。
なぜ年号を最初から４桁にしておかなかったのか、
年号に別の意味を持たせるとか、そんなことをするのか。
その謎を解くには、それらのプログラムが作られた当時の事情を考える必要がある。
最近はパソコンでも平気で数十メガバイトのメモリーを積めるようになった。
ハードでリスクなどの記録メディアも数Ｇバイトクラスが出てきた。
さらにその読み書きの速度も速く、コンピューター自身の処理速度も
飛躍的に向上した。
ところが、数年前まで、正確に言えばWindows3.1が一般的になるまでは
メモリーは非常に高くかつそれほど大容量は使えず、記録メディアもサイズが小さく、
その読み書きも遅く、処理速度も遅かった。
そのため、記録するデータは出来るだけ少なく、
処理も桁が少ない方が速いので少なくしたわけである。
およその価格であるが、私がコンピューターを触り始めたころのメモリーの価格と
現在のそれを比較すると、
１９８０年 ２０Ｋバイト ５０００円
１９９９年 １６Ｍバイト ５０００円
１６Ｍは２０Ｋの８１９.２倍のサイズである。
逆に言えば、価格がここ２０年で１／８１９.２にもなったということである。
ハードディスクも同様。一応値段を上げておくと
１９８４年 ４０Ｍバイト ５万円
１９９９年 ９Ｇバイト １０万円
９Ｇは４０Ｍの２３０.４倍である。価格で言えば１／１１５.２になった計算である。
これらの価格崩壊はすごいことである。
さらに、価格は下がったがその性能は数倍、下手すりゃ数百倍にもなっているので
ある。
ということで、今でならよほどのことがない限りそんな簡略化処理は
しないだろうが（したら単なる手抜き）、当時はそれは手抜きではなく
しかたないことだったのである。
・・・
２０００年問題というものは、本来プログラムのバグといえるものであるが、
通常はあり得ないデータに対する処理を省くことはよくあるので、
プログラマーを責めることは出来ない。
もう１つ。当時は自分達の作ったプログラムが２０００年まで使われるとは
余り思わなかった、というのもある。
しかし、思いの他プログラムの寿命は長かった。
いや、コンピューターの便利さを知った企業が、それに頼りすぎたために
使わなくしようにも使わざるを得なくなった。
さらに、プログラムは破棄出来てもそれまでに蓄積されたデータは棄てられず、
結局そのデータを操作するためには問題を知りつつも、同じようなプログラムを
作らざるを得なかったのである。
もっとも、Ｓ社のＪ部の某ように、修正出来たのにしなかった「昔からの互換性の
ために」などと抜かして馬鹿どももいるけど、これはまた別の話
（要するに面倒な仕事はしたくないんでしょ）。
・・・
２０００年問題は、１９８０年代後半から一部では言われていたが、
それが今まで、こんなぎりぎりになってまだ対策出来てないのには
次のような理由がある。
・作った人間とは違う人間が修正するのは非常に面倒
（修正箇所の発見が難しい）
・プログラムだけでなくデータも修正する必要がある
・修正する人が足りない
・コンピューター上のプログラムだけでなく、組み込み部品内の時計関係も対象である
（チェック対象が膨大）
・問題の重大性への認識が甘い
特に日本では、不景気でその対策に費用が当てられない、という問題も有った。
プログラムを全て読み、それを作った本人が修正出来ればまだ良いが、
他人のプログラムを読むということは非常に難しい。
例え作った本人でも、昔のプログラムなら内容は忘れている。
最近のプログラムは最初から対策されているものがほとんどだから、
多くは古くから使われているものだ。だから余計に修正が難しく、進まないのだ。
対策の中にはデータには変更を加えずにプログラムの修正だけでとりあえず回避
出来るものもあるが、重大な問題を起こすものほどデータそのものを直さないと
だめである。現在対策されていないプログラムと言うものは、多くの場合昔から
動いているものであり（基幹システムになっている）、そこで蓄積されたデータも
また莫大な量がある。そのため修正が難しくに多くの時間がかかる。難しい。
システムの稼働中にデータを更新することが難しいと言うのもあろう。
2000年問題の危険性は、このような基幹システムでこそ修正が難いというところにも
ある。
また、プログラムと言うものはパソコンやオフコン上にだけあるものではない。
今や身の回りではマイクロコンピュータがたくさん使われている。
冷蔵庫や掃除機の中にだって入っている。
それらが問題ないと言い切るには一応チェックが必要なのだ。
しかし、機種が余りに多すぎて、全てのチェックは事実上出来ない。
やり始める前にめげてしまうことだってあるのだ。
・・・
当面の２０００年問題の先送り方法としては、年号を戻すというのもある。
曜日の一致まで考えると、１９７２年まで戻すのが良いらしい。
が、この場合も差分を取っている場合には問題が出る。
年号の特殊利用に関しては回避出来るけど。
保険関係などは、最初から３０年とか生涯とか長いのがあるため
比較的早い時期から２０００年問題は認識していたようで、
いろいろな対策がとられているようである。
傑作なのが、西暦では足りないので皇紀で年号をとるというのがある。
皇紀は西暦より６６０年古い、ということは２０００＋６６０＝２６６０年なので
あと４０年は先送り出来る。これだけあればなんとかなりそうな気はする。
それにしても、これを思いついたプログラマーはすごい。
（初めてそれを聞いたときに「おぉ！」と膝を打った位。）
・・・
実は余り知られていないが、２０００年代には他にも危ない年がある。
＊２０３８年 １９７０年からのタイムオーバー
コンピューターソフトの多くでは、日時の計算を秒で行っており、
しかもその基準を１９７０年１月１日０時０分０秒に持っている。
全ての日時はそこからの経過秒で覚えているのだが、この覚えている領域が
あふれるのが２０３７年（内）である。
コンピューター内部ではこの記録に３２ビット使っている。
そのうち１ビットは符号に使っているので、３１ビットで＝２の３１乗で表すことの
出来る秒数０〜２１４７４８３６４７を越えるわけである。
越えると秒がマイナスになり問題が起こる。問題の起こり方は今までに
書いたものと同じことも予想される。
＊２０８０年 １９８０年ベースマシン
マイクロソフトのＭＳ−ＤＯＳやＷｉｎｄｏｗｓ３.１、Ｘ６８０００の
Ｈｕｍａｎ６８Ｋ等は内部での年号の管理を１９８０年からの経過年で持っている。
そして、その範囲は０〜９９である。このため、１００年後の２０８０には
年号が狂ってしまう。
この場合は年号だけの不都合だが、２０００年問題も年だけが問題の原因だから、
同じことが起こりかねない。
この他にも、危ないとされる年はいくつか有る。
このように、年号による問題というものは、いろいろな場所に存在するのである。
決して２０００年だけの問題ではない。
このような問題が起こった原因は前に書いた通りメモリー消費量を減らすことと
「このソフトがそんな時期まで使われることはない」という思い込みによるもの
だが、１９７０年代くらいならいざ知らず、１９９０年代につくられてソフトにも
それがあるというのが、いかにソフト屋の認識が甘かったという証拠であろう。
因みに、私が今まで作ったソフトでは初期（１９８２年ごろから）から２０００年問題
は起こさないように対策してきたが、２０８０年問題は知りながらも「そこまで
使われることはないだろう」で逃げたし、２０３８年問題は知らなかった。
これはこれで認識が甘いといわれてもしかたないが、わたしの創ったソフトこそ
１００年使われたら"いけない"ものだし、データの蓄積もほとんどないから
大丈夫だろう。
・・・
まあ、いまは世界中で騒いでいる２０００年問題、実際に表面化すれば
おそろしいことではあるが、こういう時期の動作においては人のチェックも
当然入るだろうし、案外こともなげなのかもしれないと思ったりもする。
人がコンピューターに頼らない昔ながらの生活に戻るだけではないか。
実際のところ、「人類に２０００年以降はないのだから、
このような心配も杞憂に過ぎない」のでは、などと思ったりするのであるが
いかがなもんであろうか。
逆に言えば、２０００年以降がないと、なんとなく解っていたから
対策されなかったのではないか、と。
はたして、人類最後の壮大なバカ騒ぎとなるか「２０００年問題」。