私はコンピュータの西暦2000年問題に一貫して反対の立場をとってきた。
このように述べたとしたら、普通の人はどう思うだろうか？少なからぬ違和感を持つのではなかろうか。ホームページへ
そういう問題じゃないだろ、とたしなめてくれる親切な人には申し訳ないが、それに対して強硬に「ではあなたは2000年問題に賛成なのか？あった方がいいというのか」と切り返すことは可能である。2000年問題に携わってきた人にはよくおわかりのように、2000年問題は賛成／反対という区別が出来るものではない。実際にそこにあったし、多くの人がそれを克服すべく具体的な行動をとってきた問題である。
具体的な行動をとってきた、というのが重要なのだ。2000年問題は反対の立場を表明しただけで何らかの問題が克服できるという種類のものではなかったからだ。では翻って「賛成／反対」の枠でくくられている問題を見てみると、同種の違和感になやまされるのに気がつく。例えば「核兵器反対」。
声高にその主張をする人々に対して「そういう問題じゃないだろ」とたしなめると、確実に「ではあなたは核兵器に賛成なのか？」と怒鳴られそうである。
露骨にいうと、問題を克服するための具体的行動として反対する以外何もできないから、核兵器の問題を賛成／反対の枠に押し込めているように思える。確かに人々の意識を高めることは大事だろう。そのためには演説も必要だ。演説の表現として「核兵器反対」ということもあるだろう。
それはそれで認めるとしてもだ。最終目標は核兵器廃絶としてもだ。普通は手近な操作目標を考えないか？合衆国に核先制不使用の約束をさせることを考えて、どうするか、とか。（旧ソ連は核先制不使用を宣言した。合衆国はソ連がそう言っても信用できないというが、合衆国は歴史上唯一核を先制使用した国でもある。）一応いっておくが、吉永小百合までナレーターに担ぎ出した反核映画「１００匹目のサル」は間違っている。この映画の主張は、多くの人が核兵器廃絶への意識を持てば、突然それが全人類に広がるから、一人一人が意識を高めてゆけば、核が無くせるというものである。
そんな馬鹿な、と思っていたところこの「１００匹目のサル」という現象は、ライアル＝ワトソンの「生命潮流」という本に書かれていたものだと判明した。私は日本人だからワトソンの論がすぐさま嘘であると分かった。最初に海水でイモを洗ったサルの名前が「イモ」という事からして十分に作り話っぽい。で、これが本州の高崎山のサルに突然（集合無意識を通じて）広まったという話。サルで有名な高崎山は実際は九州にあるという間違いを外国人ならやむを得ないものとしてもだ。サルたちはどうやって海までイモを持って走るんだ。誰か見た人います？
更に、この現象を論文に書いた人が河合隼夫ですって。確かにユング派精神分析医だけど。京大のサル学は世界的に有名だけど。「賛成／反対」の別は未だ決定されていない議案に対しては有効でも、現実に起こっている問題に対してはなんの効力も持たない。現実の問題を容認しようが否認しようが、現実を動かすことはできないのだ。
2000年問題をＳＥとしてみれば、対応内容自体は単純でキャリアとして誇れるようなものではない。しかし、何らかの大問題があって、解決すべく具体的な行動をとって、そして見事に克服した、という点では結構、社会史的に価値があったのではないかと思う。
プログラムを修正する一方で、危機管理体制を敷き、各自が備えをする。対応が後手後手に回ったといわれはするが、結構、みなさん、うまくやりました。これは胸を張っていいのではなかろうか。だから、核に限らず社会問題に対して「反対」と叫びつつ実は耳を塞いでいる人に対して何か一言伝えるくらいはできますよね。
かくして、最後のKeyDate 12/31。私はなんの心配もせずに朝一番の飛行機で田舎に帰ることができます。みなさん、ありがとう。
「２０００年問題を笑い飛ばす」を読んでいただいたこちらの方から２０００年問題対処のアイディアをいただきました。西暦下２桁で年数を表すとき、実は３バイト使っていることが多いという指摘です。たしかに「90年」というとき「'90年」とアポストロフィをつけていることが多い。ホームページへ
なるほど、この１バイトを有効活用すればプルトニウムの半減期くらいは持つぞ。適用範囲は限られますが使えるかもしれないアイディアです。もっと早く気がついておけば、と考えてらっしゃる方は・・・さあ、８月２２日に人類が絶滅すると心配した人との数といい勝負かもしれません。そこで気がつきました。なぜ西暦下二桁を見たコンピュータはよりによって１９００年代と勘違いするのだろう。１８００年代でないのはなぜなのだろう。コンピュータの黎明期。つまり２０００年問題の遠因が作られたとき、たしかに１８００年代と１９００年代の区別をする必要に迫られたことがあったはずなのです。だって、当時は１８００年代生まれの人が現役でどんどん働いていたはずでしょう。生年月日だけ西暦４桁で扱っていたのですか？そんなはずはないでしょう。
ということは、例えば、５０より大きな数字は１８００年代と判断するようなルーチンをすでに組み込んでいたのかもしれない。で、途中でそれを変更してリコンパイル。そんなこんなをしているうちに、多くのプログラムが２０００年対応を終えていた、とか。うーん考えられないことはないなあ。ここで今更ながら思いました。人間の認識能力って凄いなあ。「私は９９年の生まれです」と言った人がいれば、たとえ目の前にいなくても「ああ１８９９年生まれなんだな」と分かってしまう。（去年産まれた赤ちゃんはまだ話せないだろうという常識的仮定に基づく。）
ということは、コンピュータの知能、ええと人工知能という奴ですか？が発達すれば、西暦下二桁だけでデータを持っていれば十分であるかもしれません。そして、2000年問題の遠因を作った人々は、2000年までにはそのくらいのコンピュータができるだろうと、未来を信じていたのでしょう。だから２０００年になっても問題が起こるなんて思わなかったのかもしれません。例えば「2001年宇宙の旅」で登場するコンピュータHAL9000が作られたのは小説では1997年1月12日、映画では1992年1月12日ということになっていました。2010年宇宙の旅では映画版と同じく1992年1月12日なので、こっちの日と見なした方が作者の意志に沿っているのかな。（このへんのことは、こちらのページで調べさせていただきました。クラッとくるほどかっこいいページだ。）
ともかく、９２年にあれだけのＡＩが出来ているのならば、2000年問題など恐れるに足らずです。
そのころの夢って、しかし実現しないものですね。アトムが出来ていないのは仕方がないとして、リニアモーターカーですら実現していないんですよ。ああ、大阪万博よ。テレビ電話は出来ましたが（昔私も買った）、流行りませんでしたし。エアカーの通信販売が始まったと週刊アスキーにありましたが、さあどうでしょう。Back To The Future2の頃にはデロリアンが飛んでいますかね。
あのころの夢で実現したのは、せいぜい携帯電話程度かな。プリウスは認めてあげたいな。「２１世紀に間に合いました」いいコピーだ。でもご存じのように西暦下二桁は２１世紀（近く）まで引きずる羽目になりました。
しかし、２０００年問題は人工知能で対応します、とぶちあげる会社が一つくらいあってほしかったな。
西暦２０００年問題、残るは366日目だけだろうと思っていましたが、非常に平穏にコトが運んだ故に、困る人がいるかもしれません。保存食料品の会社が売り上げ急減でにっちもさっちもいかなくなっているかもしれませんが、まあその分は年内に売れたからとあきらめてもらえるでしょう。ホームページへ
収益が平準化しないと税金が大変だというかもしれませんね。これがバブルの時代なら、レバレッジドリースとかで課税繰り延べの財テクをどこかの会社が売り込みに来てくれたでしょうが。まあ近所のコンビニの特売カップラーメンも随分前にはけてしまいましたし、これについてはいいでしょう。（よかあない！という方はご教示ください。）西暦２０００年問題対応に焦っていた末期には、様々な冗談のような対応策が提唱されました。１９９９年を９９ヶ月つづけるとか、同じ曜日の並びの年（１９７２年）に日付を逆回しするとか。全部話半分なのかな？そうなんだろうなあ。
本当にやっていたとすれば、小手先でしのいだ分を本格対応するという作業をやらなければならないはず。でも経営者はすんなりとお金を出すだろうか。２０００年問題起こらなかったんだろう、だったらやんなくても何とかなるんじゃないかと思うだろうね。さあ、どうする。２８年逆回しは、多分、内部日付が２０００年になるまでには何とかなるとして、１９９９年９９月はちょっときついかもしれませんね。
ああ、そういえば元号が変わったときに内部表現は昭和のままで、インターフェースだけを平成にしたという解決策もあったわ。多分昭和百年になると元号エリアがオーバーフローすると思います。でも、そのころは今の担当者みなさん引退ですね。忘れられた頃にぽつぽつと問題が生ずるというのがちょっと怖いですが。あ、Ｃ言語の２０３８年問題（1970年1月1日より2の32乗秒経過して時間が戻るというあれ）はOSが64bit対応になればリコンパイルだけで済むんでしたっけ。
COBOLを開発した短期言語委員会に課せられた課題は《１９５９年９月１日までに、既存自動コンパイラ（とくにAIMACO,FLOW-MATIC,およびCOMTRAN）の長所、短所に関する調査結果を報告し、デジダルコンピュータのプログラミングのための共通ビジネス言語に対する、短期的かつ複合的アプローチ（少なくとも今後１，２年通用するもの）を提言すること》であったそうな。
そもそも、西暦を下二桁で扱うやり方が問題であった！などと悪者にされがちなコボルの設計者ですが、このような事情を考えに入れると、その人たちに西暦２０００年問題がどうのこうのと文句をいうわけにはいけません。COBOLというのはすごい言語だったんだなと思います。１，２年使えればとわずか半年で作った仕様の言語が未だに使われているなんて大したことですよ。確かに西暦を２桁で扱うという仕様は結果的に問題となりました。でもこれを「（世紀の）バグ」といってはいけないと思います。今後１，２年もつという要求水準は満たしていますから。「バグではなくて仕様です！」
それにしても、この「１，２年持てばよい」という要求であるにもかかわらず、その後４０年の進歩に耐えうるだけのものを作ったという委員会のモチベーションは物凄いと思います。
私なら、例えば１年４ヶ月持てばいいシステムであれば、それなりのものしか作らないでしょう。開発がしやすければ、環境が多少複雑化しても良しとしますし、時間が経つとゴミになるログを消すサイクルなどの検討もおざなりになるでしょう。でも、COBOL作成委員会はそうしなかった。
このバージョンが２０００年まで持つわけない、と９８年になっても２０００年非対応ＯＳを出してきたメーカーに見習っていただきたいものです。もちろん、９９ヶ月問題、２０３８年問題、昭和百年問題を「その頃にはいないから」と安心してしまった自分も見習わなくてはならないことです。
２０００年問題を「Y2K」と略されて、Y2Kの商標権を持っているソフト会社やＹＫＫはさぞ気分が悪かったこととお察し申し上げます。ホームページへ
また、ビジネスを維持するにはどれだけの取引先とつながりを持てばよいかを調べた人たち、調べられた会社はさぞつらかったことと思います。あるいは、丁寧な口調で納入されたソフトウェア製品の動作を保証してくれと連絡されたソフト会社は実に嫌な思いをしたことでしょう。まあソフトウェア会社に限らず「お宅の会社は２０００年対応大丈夫だろうねえ、書面で回答してくれ」などと言われれば気分を害するのは当たり前でしょう。じゃあそっちは大丈夫？と尋ね返すと何も保証しませんといわれ、取引関係の強弱が改めて浮き彫りになったり、その辺の後遺症が心配となってきました。でもそれは、所詮はゲゼルシャフトの取引関係、つまりあくまで利害関係。仕方がないと割り切ることも出来るでしょう。
まあ２０００年動作保証の書類を持ってきた世界最大手の通信社、これにはあきれましたがね。保証期限が２０００年１月１日。でもこの利益共同体のルールを、それ以外のところに押しつけるというのはどうでしょうか。「社内で使っているソフトを洗い出して、２０００年問題が無いことの確認と保証を文書で取るように」というおふれをそのままフリーソフトにも適用したとしたら、これは反則じゃないですかね。
幸い私が公開しているフリーソフトを業務で使っているところは少ないようで、不愉快な思いをすることはありませんでしたが、よく使われているものだとどうだったでしょうか。例えば圧縮／解凍ソフト群です。
「使わせていただいています。ありがとうございました。」というお礼のメールもくれない先がいきなり「問題がないことを保証しろ」とくれば殆どの人は切れるでしょう。更には圧縮解凍DLLだったりするとどうでしょう。世の中には「あんたのDLLを勝手に使っているが、２０００年問題が起きた、あんたが悪いから何とかしろ」というメールを送った人がいるかもしれません。というか、あるＤＬＬのReadme.txtを読むといたようです。そのDLL本体には問題がないのに。
この作者が、２度と新バージョンを公開しなくても、あるいは次からシェアウェアにしても、私は納得せざるを得ませんね。私もこの作者ほどではありませんが不愉快な思いをいたしました。私は自作のフリーソフトをNiftyServeにアップしていますが、このNiftyが怒らせてくれました。
Niftyがオンラインソフトの２０００年対応状況を一元管理したいということでトップメッセージに「フリーウェア作者の方も対応状況アンケートに答えてください」と表示しておりました。まあ仕方ないかなとアンケートメニューに飛ぶとこれがあまりにもひどい。
フリーソフト一本一本ごとに再度トップメニューから入り、重複したことを記入させられる。自分がアップしたライブラリと一連番号を全部覚えているわけではありませんから、あれ、どこのライブラリだったっけ、と探そうとしてもアンケート回答中は他に飛べない。私のように１０本程度フリーソフトを公開している身としてはたまったもんじゃありません。しかも、しかもですよ。アンケート回答中もしっかりと課金されるのです。表示はされてないけども当然無料だろうと思った私が甘かったのか？
これがもし、個人別にメールで問うてきたのなら許せるんですよ。「当パソコン通信のライブラリにソフトを提供くださいましてありがとうございます。（中略）つきましては以下のオンラインソフトについて２０００年対応状況をお知らせくだされば幸いに存じます」とかね。だったらオフラインで記入して送ってあげます。
まあ、アンケートが途中で抜けられないので一度だけ回答しました。一ヶ月くらい経って怒りもおさまったころNiftyからメールが来ました。
やはりこのアンケートではフリーソフト作者の協力が得られなくて、十数件しか回答が集まらなかったようです。結局アンケート結果の公開は見送ったそうです。それはそうでしょう。さて、Niftyのみなさんはどうして作者の協力が得られなかったのか分かっておいででしょうか。根本的問題はNifty自身が２０００年問題対応に熱心でなかったことにあります。気配りが足りなかったのはこのためでしょう。証拠として、テスト環境を提供しなかったことがあげられます。
自作のフリーソフトにはNiftyの通信ログを扱うものが５つあります。もちろん自分では２０００年対応しているつもりですが、実際にテストしないことには何とも言えない。でもテスト環境がないのです。本来的にはNifty自身が２０００年以降の日付のテスト用サーバーを立ち上げ、オンラインソフト作者に通知すべきでしょう。もちろんフリーダイヤルでね。ならば我々も安心してテストが出来、自信を持って２０００年対応といいきれます。でもそれをしなかった。ということは、、、悩みましたよ。実はNiftyは社内に２０００年対応テスト環境を持っていないんじゃないかなと。だから公開できないんじゃないかと。
そんなわけで、私が２０００年問題で一番不安を感じたのはNiftyが動くか、でした。２０００年問題を笑い飛ばすとは言っても、やはり私自身ナーバスになっていたのですかね。（やっぱり怒ってはいましたし。）私でさえそうですから、世の中のフリーソフト作者は、それがポピュラーなものであればあるほど、怒っている可能性が高いです。そんなわけで、フリーソフトの供給が今後細ったとしたら、その原因の一つとして２０００年問題の後遺症があると言えるかもしれません。
そういえば、２０００年がうるう年だったおかげで、来期頭カットオーバーの案件が、楽になるかもしれませんね。ほら、４月１日が土曜日でいかにも移行作業にあたりそうな日。エープリルフールに感謝感謝。(^^;お、おそろしい。
あちこちで細かい問題は起こっているらしい。でも、まあ、ちょっとしたプログラムがトラブルを起こしても、代替手段があるからということで平穏なうちに処理されているようだ。ホームページへ
なにしろ、対策をやっていなかったロシアでさえ何も問題はなかったそうだから本当にＹ２Ｋ問題が存在したかどうかも疑わしいものだ。コンピュータ業界が儲けるための方便ではないかといわれても返す言葉がなかろう。ただし新たな問題が生じてきた。プログラムがトラブルを起こしたとしても「影響は軽微」「代替手段あり」ということでできるだけ事なかれで処理されているとすると、やがて「じゃあなんでそんなシステム作ったんだ」という当然の疑問が生じてくるだろう。これはポストＹ２Ｋ問題の発生か？
特に、あまりに平穏無事な２０００年の立ち上がりが「Ｙ２Ｋって対策費用かけすぎじゃなかったの？」という印象を与えているとしたら、「本当に（この）システムは必要だったんだろうか？」という疑念をそう簡単にぬぐい去ることはできないであろう。でも、今年ほど「あけましておめでとう」という挨拶が似つかわしい年は今までになかったね。ともかくまあ無事に明けてよかった、よかった。
何も起こらなかったことになっている２０００年問題ですが、逆にコンピュータなんか無くても何とかなるのではという気持ちにみなさんなってしまうかもしれませんね。確かに原発の異常を通産省に通知するシステムなんか、どうせ事故があっても連絡が行かないことが多いですから止まっても影響はないのかも。ホームページへ
ともかく生活に問題がなかったようでよかったです。心配していたのはこんなことです。みなさんＹ２Ｋでいろいろ問題があって出歩かない。とすると１０月１１日に産院が超満員になって医療機関が困る。
１月１０日とか１０月１０日とかいろいろ２０００年問題のKeyDateが思いつかれていますが、９月９日に何かが起こるよりは１０月１１日に医療機関が患者をさばききれなくなる可能性の方が高いなと思いました。
いずれにせよ、ライフラインはとても無事でしたから、そんな可能性はなさそうですね。
（2000.2.28補足）
有名サイトで紹介していただいたおかげで、いろいろと突っ込みをいただきました。感謝！感激！であります。m(_ _)m
原則みなさんに返事を書かせていただきました。なお、本編について１月１日の十月十日後は、１１月１０日であるというメールをいただきました。
その通りです。私のミスでした。１０月１１日問題、というタイトルにしたときの私の考えは以下の通りです。
最初は、元旦の夜に仕込めば産まれるのは１０月１０日、とすかっと思いこんでいました。「でも１０月１０日問題とすると、インパクトがないなあ。年月が４桁になる最初の日なので既存のKeyDateということもあるし。(^^;ええい、元旦の夜なので１１日にしてしまえ。」と思ってああいうタイトルにしました。
ちなみに今年は閏年ですからこの計算をしても１０月１０日になりますね。（あー2000年問題に足をとられた。）あとで変だということに気がついたのですが、「１１月１０日問題」というタイトルにすると、これが人間の妊娠期間を指しているということに読んだ人が気がつかない可能性が高い。ならば多少の間違いは方便のうち！と開き直っていたというのが実状です。中途半端で済みません。
１０月１１日問題、などとせずに「十月十日問題」とすれば「とおつきとおか問題」と読んでくれたかもしれませんでしたね。m(_ _)mちょおおっと考えが足りませんでした。なお、十月十日後に産院が超満員になるというネタは、まだ合衆国がのどかだったころのニューヨーク大停電のエピソードから連想しました。
（２０００年２月２９日補足）
またもやメールをいただきました。妊娠期間をいうときの十月十日は、０ヶ月を参入しないそうですね。つまり９ヶ月と１０日くらいになるそうです。日にちにすると２８０日だとか。
つまり、１０月１０日でいいようです。二転三転しましたが納得しました。単純に十月十日と勘定して、覚えがないとニョーボを責めている人がいるかもしれません。だとするとこういう誤解は、しっかり解いておかなければいけないということになります。
あなたのそばに、妊娠が判明したとたん夫婦仲が悪くなった人はいませんか？
（2000.3.2追加）
「妊婦は患者ではない」というごもっともな指摘をいただきました。
たしかに健康保険は効かないし、姑からは「妊婦は病気じゃないんだからちゃんと仕事はしてもらわないと」と言われるということも聞くし、そういえばそうですね。
まれに、赤ん坊の首にへその緒が巻き付いていたり、こうなると患者かもしれません。
でも、正規の妊娠期間を得て１０月初旬に産まれる方は、だいたいの場合「母子共に健康です」と言ってもらえるでしょう。問題になるのは、未熟児。２０００年問題で、一時的にベビーブームが起こると、当然未熟児も多くなるかもしれません。そうなるとどこの病院でも保育器が満杯。出産はしたものの保育器の空きがなくて、お医者さんは知り合いに電話をかけまくるが、やはりどこでも断られ、その間にも赤ちゃんはどんどん弱ってゆく。
こんな光景は人の親として想像もしたくないです。産婦人科がこのような患者であふれかえってほしくない。
（きちんと２８０日前後、お腹の中にいても、、、あ、双子だったりすると保育器が必要な場合がありますね。あー、２０００年早々問題が起こらなくて本当に良かった。）
今日になってもニュースでソ連の原発が２０００年問題に対応していなくて、ということを言っている。危なければ止めておけばよいだろうに、と思っているのだがそういうわけにはいかないようだ。ホームページへ
対応の必要性は感じていたが、どうやら予算が無くて、というのが対応していない理由らしい。あれ、原子力発電は低コストだから、そのくらいの予算は積み立てていたはずだろうと思うのだが、そうでもないらしい。
実は予算が無くとも対応する方法はあったのではないだろうか、と今日になって気がついた。原発の制御プログラムを全てオープンソースにして世界中のプログラマにデバッグしてもらえばよいのだ。さあ、だれか協力してくれる人はいるだろうか。
オープンソースのメリットを説く人の仮定によれば優秀なハッカーがよりよいものにしてくださるはずである。２０００年問題なんか平気である。制御プログラムをデバッグすることにより世界を救った人のリストに名前が載るというのは大変な名誉であろう。だいたい世界の命運を握る（というのは少し大げさかな）ようなプログラムを非公開にすること自体が罪である。オープンソースにすれば、メンテの問題は解決されるではないか。
ただひとつ問題が残るとすれば、どうやって修正したプログラムをテストするかである。（実に深刻な問題だ。オープンソースにして十分な開発者の数を集めるためには、それだけのテスト環境が必要なはずである。であるから、テスト環境の作りやすい、それこそ開発ツールがオープンソース運動の盛んな部分となるのであろう。）もし、エリック＝レイモンドあたりが音頭をとって、みんなでソ連の原発を救おう、というキャンペーンをはじめたらオープンソース運動に参加するハッカーたちがどう動いたかを想像するのは、それはそれでおもしろい問題であろう。 ひょっとしたら、だれも参加しないかもしれない。（直感的にはそんな気がする）もしそうだとすれば何故だろうか？
そろそろホームページへ
「２０００年問題は起こらないだろう」
「２０００年問題は起こっているのだろうか」
「２０００年問題は起こらなかった」（「２０００年問題」を「湾岸戦争」に置き換えた論文をフランスの偉い哲学者が書いていたなあ。）
の三部作でも書こうかと思っているのですが、２００１年問題が生ずることが判明しました。ただし、これは英語圏の問題です。例えば１９９９年を英語ではnineteen-ninety-nineと発音します。年号を発音するときに上２桁と下２桁をあたかも元々２桁であるかのように独立に読むわけです。（この習慣に２０００年問題の根っこはあるように見えますね）
では、２００１年をどう発音するのでしょう。twenty-oneですね。発音上「２１」と区別することはできません。つまり、英語は２００１年を２１年と間違って認識してしまうという構造的問題を抱えているわけです。
２０００年問題であれば、例えば山奥に逃げるなりして回避することができるそうですが、英語を話さずにいることはできないでしょう。くれぐれも言っておきますが、この影響はコンピュータの２０００年問題とは比較にならないほど深刻です。少なくとも英語圏の人間はコンピューターに対する依存度よりも英語に対する依存度の方がはるかに高いことは明白だからです。そして、これに対処することの困難さはプログラムを書き換えるレベルではありません。というのは、全英語圏の人間は例えばこれから日本語を学び始めなければならない。更には翻訳しなければならない英語の文献はあまりに膨大です。コンピュータプログラムの比ではありません。しかも時間は限られています。コストは膨大です。翻訳ができずに捨てられてしまう文化遺産が生ずる怖れもあります。
いったいわれわれはどうすればいいのでしょうか。少なくとも、まあ、音声認識ソフトは２００１年と２１年を区別できるように調整しなければならないかもしれないなあ。
（２０００年２月２９日補足）
複数の方からメールをもらいました。
２００１年は
twenty-oh-one ないし two-thousand-one と発音するそうです。おかげさまでひとつ利口になりました。(^^)
そんなわけで、英語の２００１年問題は、せいぜい音声認識ソフトが ”２００１”を”２０ｏ１”と認識したり”２０００１”と誤認識する程度の影響に留まりそうですね。
問題はむしろ日本の英語教育でしょう。いままで「英語は西暦を上２桁と下２桁にわけて読む」と教えていたのを変更する必要がありそうです。
ホームページへ今を去ること１９９９年前、ユダヤのベツレヘムに一人のみどり児がお生まれになりました。もっともイエス＝キリストが生まれたのが実際に西暦元年というわけではないというのは定説となっております。もしそれが分かった時点で西暦の数え方を変更してくださっていれば、我々が２０００年問題に頭を悩ませる必要はなかったわけで、重ね重ね残念であります。
しかしながら、イエス＝キリストの誕生を祝うということ自体は、我々にクリスマスという楽しい出来事をプレゼントしてくださるわけで、これに感謝しない人はいないでしょう。出席したクリスマスパーティの挨拶を聞きながら、私ならこのくらいのことは言うがなあ、とその場で作ったフレーズです。今一歩かな。
まあ、今年はサンタさんの優しさで初めて発見したこともありました。それは、かの「赤鼻のトナカイ」の詩に隠されています。サンタさんが赤鼻のトナカイにそりを引かないかと声をかけたのは「クリスマスの日」。でも、実際にサンタさんがトナカイにそりを引いてもらうのは「クリスマスイブ」ですね。つまり、赤鼻トナカイに自信をつけさせるために、必要もないのに呼んだということです。子どもの時から持っていた疑問が解けました。なぜ、発光能力のない赤鼻が暗い夜道に役に立つのか。一晩で世界を回るという熟練の必要なはずのそり引きがなぜその日はじめてそりを引く赤鼻トナカイにつとまるのか。つまり、実際に仕事をする必要はなかったのです。さて、２０００年問題で３日程度の食料や水を備蓄しなさいというガイドが出ているようです。でもそれだけで済むのでしょうか。ライフラインに問題があっても一週間程度で回復するからだそうです。ということは一週間でプログラム修正が終わるということだそうです。
無理でしょう。それで済むならとっくの昔にソフトウェアの２０００年対応は終わっているはずです。そんなわけで備蓄するなら１年分は必要でしょう。
あきらめたわが家は水のみ一週間分程度備蓄することにしました。なぜなら、水道局ははじめは手動で動かし、あとで電動に切り替えるということだそうなので。いつもやらないことをやるというのはいかにも危ないことですからね。で、手動で何とかなるのなら、これだけは１週間以内に回復しそうです。でも、電気がなかったらどうなるんだろう。
パソコン雑誌の特集が年賀状で塗りつぶされた今日この頃、みなさまいかがお過ごしでしょうか。ホームページへ
そういった特集の中で、パソコンで年賀状を作るのは２０００年問題を避ける意味で必ず１９９９年中に作りましょう、というアドバイスがないのはいろいろと問題なのではと思うのですが、みなさまにおいてはいかがでしょう。
そもそも２０００年問題で大変なのであれば、年賀状が届くかどうかも疑わしいので、今年に限り１９９９年中に届く年賀状というサービスも郵政省はやるべきではないかと思うのですが、賛同者はおられますでしょうか。
まさか、年賀電子メールで怠慢をしようとしている人はいませんでしょうね。どこかのサーバーが停止してメールが配信できなくなっても、それは誰にも文句が言えませんでしょう。インターネットで年賀状作成というサービスを考えたことがあります。プレステかドリームキャストのソフトで紙面デザインと宛先を設定し、インターネット経由でサーバーに送信する。これを印刷して郵便局に持ち込む。ユーザーは来年まで発送一覧を管理する必要はございません。けっこううまくいきそうですが、セキュリティも何もないのに気がつきやめました。
それではなぜドイツが、という問いに関しては「ドイツにはサマータイムがないので、サマータイム適用期間かどうかを調べて日付を算出するロジックが不要」という事実で納得できます。そもそも世界でも几帳面さで知られる日本人とドイツ人です。２０００年問題がどうのこうのなんてとっくに気にかけて、影響のないプログラムを書いていますよ。合衆国人は、９０年代後半になっても例えばJavaやWindows98のように２０００年対応していないプラットフォームを発売するほどいい加減なのですから、そういうのと比べて「対策費用が少ない」といわれてもねえ。
そもそも「格付け機関」というのがいい加減なのです。象徴的なのが、大和銀行のＮＹでの不祥事が明るみに出たとき。ムーディーズは「大和銀の格付けを下げることを検討する」などとしゃあしゃあとのたまいました。格下げを検討するのは当然といえば当然で特に問題視するほどのことではありません。が、時期が悪かった。ムーディーズは「日本の金融機関は先行き不透明」という理由で格付け発表を２ヶ月遅らせていました。ところが井口容疑者の事件が発覚したのは、それから２週間くらいしか経っていなかったのです。自分の格付けに多少なりとも誇りがあるのなら「この事件程度のものがあるのは折り込み済み、格付けは変更しない」とするべきでしょう。（これは私の証券アナリストとしての感覚。ちゃんと資格もある。）
よく、２０００年問題の起源として、西暦を下２桁で扱うのは、記憶域を節約するためと言われています。ところが私が昔メインフレームのプログラムを書かされたときの感覚では、ＯＳに日付を聞くと下２桁でしか値を返してこないからそれに合わせざるを得ないだけだ、と思っていました。殆どの日本人が同じ感覚だと思います。
ところが、合衆国のプログラマの記憶域節約への執念はどうやらすさまじいようで、そういえばＴＯＥＩＣの得点、日本人なら０点と１０００点としそうなところを５点と９９０点にしているらしい。これは０点をヘッダーレコード、エンドレコードを９９９点にしているからではないか、と邪推しています。これで１バイト記憶域が減る。
コーディングの仕方によるというものの、プログラムは動かす為に作られるものですから、理由もなく止まるはずがありません。2000年問題の騒がれ方はどうもこの辺が曖昧で、プログラムが動いて困るのか、止まって困るのかがはっきりしていないのは聞いていて不満を感じるものです。だいたいは止まって困ります。「ありえない日付」をチェックして危ないから止まるというコーディングをするものだからです。だから電気が止まると困る。だってコンピュータが動かないから。
ところが、世の中には２０００年問題をいかにも含んでいそうですが、決して対応されることはなく、なおかつ動くことによって破壊的作用をもたらす一群のプログラムが存在します。いわゆるコンピュータウィルスです。１３日の金曜日になると発病したり、感染後３０日たつと動いたり、感染の印にファイル日付を１００年ずらしたりする連中もいるわけですから、日付に依存している可能性は大。こいつらのうちには悪さをするやつらもおりますが、これでは作者の意図したとおりの動作をすることはできない。そんなわけでウイルス作者には是非、２０００年対応をしていただきたいものです。たまにしか悪さをしないやつが、毎日動作するようになっては大変です。でも、彼らにそういう倫理観をさあ、期待していいものでしょうか。まあ、エルサレム型ウィルスの中には二度と発病しないものがでてくるでしょうし、"4096"は広がりを止めるでしょうから、なにもしない方がいいというものもあるでしょう。でも、えてしてこういうものの方が２０００年対応が進みそうですね。
そうなると、２０００年をまたいで売れるのはワクチンソフト、ということになります。私としてはワクチンソフトは最低２社のものを入れることを推奨します。（良く干渉しますが）
というのは、ワクチンソフトがもっともウィルスに感染している確率が高いと思われるからです。例えば２０００種のウィルスに対応というワクチンソフトがあるとして、一体テストはどうやっているのでしょうか。２０００種のウィルスを集めてきて行っているはずです。これらを集めてくる過程を想像するとちょっと恐いものがあります。ありとあらゆる危ないサイトにアクセスしてファイルをとってくるのでしょうか。だとすればそれらのファイルに未発見のウィルスが潜んでいないと考える方がむしろおかしいと思いませんか。
従って、ウィルスがもっとも潜んでいそうなのはワクチンソフトということになります。少なくとも、社内にもっとも多くのウィルスをかかえ持っている会社はワクチンソフト会社です。
今回は、焦点のぼけた、でもちょっと恐いはなしでした。
ホームページへ
以前、Macintosh LC-475を使っていたときに内部電池が消耗したせいでＨＤＤが立ち上がらず難儀した覚えがあります。T-ZONEで電池を買って交換して、日付と時刻がメタメタに狂っていて、インストールしたファイル日付が原因なのでしょうか、急に不安定になって、システムの再インストールをして、それでもいまいちだったのでついに全てWindowsに移行することにしました。
プログラムは、ＯＳやプログラム本体より日付の古いシステムファイルを見つけると「このファイルは変だぞ」ということで停止するロジックを持っていたとしてもおかしくはないですからね。
ホームページへ
一番いいのは、２月２９日が休日になってくれることです。はじめからこういう対策をとっておいてくれれば、２０００年問題対応も多少は楽になっていて、合衆国の格付け機関ももっといい成績をくれたと思うのですが、いまからでも遅くありません。休みにしましょう。
国民としては紀宮さまのご成婚がなって、たまたまこの日にパレード、などとなると喜ばしいですね。
ついでに、OSとハードの組み合わせによっては、２月２９日は無事なんとかなっても、３月１日になると、月越え処理がうまくいかないのでしょうか、command.comが立ち上がらないものがあります。これを発見して騒いだのはもう４年も前のことです。
ホームページへ
もっともコンテンジェンシープランそのものが実行できるかどうか疑問です。家庭的問題に限っても、各家庭があと１０万円余分に銀行券を持つと信用収縮でさらなる貸し渋りが起こり、企業はバタバタ倒産するはずだし、水やトイレットペーパーの備蓄も時間的に偏った消費を招き、１月以降急激に売り上げが落ち込こみそうです。（そうでなければ株式市場で「２０００年問題関連株」として大商いが続いているでしょう。）
要するに各経済主体が一斉に２０００年問題対策に走る結果、思わぬ不経済を招くという問題が今後クローズアップされてくることになりそうです。
ホームページへ
ですからみなさん。年をまたいではご飯を炊かないようにしましょう。
これが、炊飯器ならいいのですが、発電所のバルブ開放時間だったりするとちょっとだけぞっとしますね。
あと、年をまたいでタクシーに乗ると、料金がどうなるのかちょっと興味があります。ご存じの方がおられましたら教えて下さい。
ホームページへ
まぬけな衛星（特に何も考えずロジックを移植したといわれる旧ソ連の衛星）は無理に位置を補正しようとしてバランスを崩し落っこちてくることでしょう。
そういえば２０年近く前に原子炉を積んだソ連の衛星が落ちてくるということで大問題になりました。（その後も沢山落ちているはずですが、報道されていません。不思議ですね。）まあ、チェルノブイリ原発があと何個か爆発したと思ってあきらめればなんとかなるのでしょうが、最大の問題は、合衆国の防空システムにあります。
1960年10月5日、水平線をスキャンしてミサイルの侵入を検知するシステムは、月の出をミサイル攻撃と誤認しました。それ以来、防空システムは月の位置を計算して警報を出さないように作りかえられているはずですが、その計算の元となる時計が狂うわけです。当然、1960年と同じように防空システムは誤警報を発するでしょう。しかも、その時には空から原子炉が落ちてきているわけです。軍事技術者は極めて正常な判断の結果、核攻撃と認識するでしょう。
1960年には、たまたまその日フルシチョフがニューヨークにいたために、専門家は誤警報であると判断することが出来ました。同様に、1999年8月22日にも、世界の核保有国首脳は一カ所に集まって、偶発核戦争を防止すべきです。（このように理路整然と世界平和を訴えているのですが、あまり評判が良くないのは何故でしょう。仕方がないので、次の冗談を加えました。）
奇しくもこの日、8月22日は半月、つまり月齢が７です。ノストラダムスがかの名高い４行詩で、「７の月」と表記し、「７月」としなかった理由はここにあります。つまり、月齢７の月が世界を滅ぼす原因となることを見事に予言しているわけです。（カッシーニが恐怖の大王だというネタよりはましだと思うのですがね。
そういえば、恐怖の大王はダイオキシンだという説をだしたこともあります。 ノストラダムスは安息香酸（ようするに亀の甲）の発見者であり、それを殺菌剤として使っていた。そのとき、亀の甲が二重になったときどんなに強い毒となるかに気がついていたに違いない。そして、ダイオキシンは亀の甲が二つつながった物なのである。（なぜかうけなかった）
ノストラダムスの予言はコックリさんであるという説も出しましたが受けませんでした。１巻の２は、いかにもコックリさんの風景なんですがね。
（以下、８月２３日加筆分）ホームページへ
私の論理展開に欠陥があり、人類は絶滅しませんでした。本気で心配された方、ごめんなさい。
私の間違っていたところは、衛星がその日のうちに落ちてくるかのように思いこんでいたことです。衛星がコースを外れたとしても、実際に空から落ちてくるまでには数日かかるんですよね。それまでには防空体制も整うでしょう。
その他、ＧＰＳの時計を利用していた機器が止まって、テレビ中継がうまくいかないという事態も予想されましたが、何も起こりませんでした。要するに２０００年問題といっても何も起こらないのかもしれません。別に１０４歳のご老人に入園通知が着たところで、あれ、なんか間違ってるや、で済むではありませんか。
どうも、２０００年問題を取り上げた本では「コンピュータがプログラムの組み方によっては誤動作する」ということがなぜか「電気、ガス、水道が止まる」に結論づけられる傾向が強いようです。しかし、その間の論理が「みんなコンピュータを使っているから」ということではあまりにいい加減です。
組み込みチップが「時間」情報を持っているというのは分かりますが、なぜ、それが「西暦という絶対時間」になってしまうのか、もし、絶対時間を使っているのだったら、その辺の機械の時間調節機能は年数から直す手段が提供されているはずではないか、、、それが無い以上、マイコン内蔵絶対時間に依存するということはないだろう、こう考えるのが普通ではないのでしょうか。
では、それでも依存する場合はどういうプログラミングをしたときなのか？それに対する解答は出されていません。私が唯一考えついたのが、「西暦2000年。ご飯が焦げる！」です。まあ、よほどタコなＯＳを使った場合はこの限りではありませんが。例えばWindowsの時間関数。時間経過の関数は55ミリ秒というものすごく使いにくいインターバルで時間経過を返してきますので、アプリケーションはそのほかの手段で時間経過をウォッチするしかありません。一般にはWindows起動からの経過時間を見ますが、絶対時間を調べるものもあるでしょう。
確かに、永久保存属性のファイルの保存期限が９９１２３１となっている場合などは、永久保存ファイルにデータを書き出そうとしたアプリケーションが２０００年以降困ってしまうこともあるでしょう。この場合はプログラムは停止します。でも、それはＯＳにパッチをあてれば解決する問題です。
アプリケーションのファイル日付が、ＯＳのインストール日付より古い場合にやたら不安定になったことがあります。でも、２０００年になった瞬間に電気が止まるわけではない。
というわけで、２０００年問題は、２０００年問題の対策が引き起こす人災である方が問題なのではないか、というのが私が予測していることなのです。（「2000年1月4日に大半の日本企業は倒産する」参照。）2000年問題は、決して無視してはいけないが、過剰に反応するのも良くない。だから余裕を持って、まず笑ってみよう。これがこのページの趣旨であります。と、いいながら。私は（受けねらいで）しっかり２２日には疎開していました。
かくして、１２月３０日にお金の足りない金融機関は、首が回らなくなって倒産します。（金融機関が潰れるのはほくたくもちょうぎんもこのパターンでした。）
さて、可哀想なのは、その潰れた金融機関に当座預金を持ち、手形を振り出していた企業です。現行法制度では、潰れた金融機関を支払い場所としている手形は不渡りとなります。普通、会社は不渡りを出すと潰れますよね。
ホームページへ