以下引用です。
「2000年問題」が10年遅れてオーストラリアを直撃、金融システムが大混乱に陥る
リンク：「2000年問題」が10年遅れてオーストラリアを直撃、金融システムが大混乱に陥る - GIGAZINE
1995年を「95年」と表記するなど、年数の表記を西暦の下2桁のみで行っている一部のコンピュータで、「2000年（00年）」を「1900年」と解釈してしまった結果、コンピュータが誤作動する可能性があるとされた「2000年問題（Y2K問題）」が1990年代末に世界を騒がせましたが、オーストラリアで2010年を迎えた途端、金融システムにエラーが発生したそうです。どうやら10年遅れる形で「2000年問題」で懸念されていた事態が到来してしまったことになりますが、いったいどうなっているのでしょうか。
詳細は以下から。
リンク：http://www.insideretailing.com.au/Latest/tabid/53/ID/7306/Bank-error-costs-retailers.aspx
この記事によると、オーストラリアのクイーンズランドにある銀行のシステムが2010年1月1日を迎えた途端、なぜか日付を「2016年1月1日」であると誤認識してしまうエラーが発生したそうです。
このエラーによってクレジットカードやデビットカードといった、カードを利用した決済がすべてシステムによって拒否されてしまったとのこと。
…略
この問題に対して銀行の広報担当者は全国レベルでシステム障害が発生していることを認識した上で、現在復旧作業中であることを明かしていますが、復旧の見通しは立っていないとされています。ちなみに以下の記事によると、現在は手動で決済を行うことで対応しているそうです。
リンク：Bank of Queensland hit by “Y2.01k” glitch - Software - Security - iTnews
ソフト開発者って、リスクが大きいのが判っていても端折らざるを得ないんだろうと想像。テスト用データの閾値の設定とか手を抜きたいし...本来、最も時間を掛けなくてはならないのがデバッグの筈ですけどね。
西暦を、下二桁のみでと端折っちゃったのが原因。
冷静に考えれば、桁数が小さければ桁上がりなどのエラー発生要因を数多くこなさなきゃならないので...想像できる要因は、とにかく排除したい。プログラマーならば多分最初は、そう考えると思う。
でも...計算処理に掛かる時間も、データ保持のための資源も...減らさなければならないと迫られたんでしょう。で、皆、最悪の選択をしちゃった。
- プログラマー側は言い訳が出来ない。何も起こらなければ稼げる資源。数字で出せるところがイタイですか...プログラマー側から提案せざるを得ない場合も多々あるでしょうし（^_^;でも、その稼げた資源って、桁が上がらないことが前提で...しかし、資源の追加って許されないでしょ？追加せずに動かし続けろとか...
だから数字ってキライです。いかに馬鹿馬鹿しいことでも正当化されちゃいますから。問題が起こった場合の損失は計り知れないけど問題が起こることは考えない。しかし、せっかく稼いだコストもチャラか赤字です。
桁上がりの問題って、身近にもまだまだあるから。
電波時計の信号。あれって日付も送ってる。で、年の部分は2桁までしか無い。資源は大事ですから（笑）その頃になったら今の時計は無くなってる？でも、その直前まで売り続けてるんでしょうから...現に、コンピューター資源だって当初予定した期限以降も使い続けた。だから結果、桁上がりでエラーが起こった。
世の中には、判っててやってる事が、いくらでもあるものです（^_^;
