• Home
• コーポレートブログ
• 16年前の思い出

新年あけましておめでとうございます。今年最初のブログは岩石が担当です。本年もよろしくお願いいたします。

この冬は暖冬状況が続いていて、島根県東部の今年の正月三が日はとても穏やかな天候でした。 元日には氏神さまにお参りした後、出雲大社に初詣に行きました。

天候が良いせいか参拝される方も例年より多かった気がしています。 皆さんがお過ごしになられた地域ではいかがだったでしょうか。

2000年問題

さて、今回のブログは年始ということもあり、随分長くなってしまった業務経験の中から、今から16年前に話題となった 2000年問題（通称Y2K問題） に明け暮れた頃の思い出ことを書きます。

当時を経験された方には説明するまでも無いこの問題ですが、お若い方はご存じ無いと思いますので簡単におさらいしてみます。

20世紀後半の1980年代からコンピュータの普及が進み、2000年に近づくころには社会インフラを支えるコンピュータの存在はだれも疑うことが無いものとなっていました。
当時一般的に西暦年の表現は4桁の内下2桁を用いて表すことが普通でした。現在も「16年」と言えば、「西暦2016年」のことと認識することが普通になっていますが、当時も「89年」といえば「西暦1989年」のことを表す物と認識されていました。
プログラミングも同様で、私が初めてプログラミングを学んだ本でも、閏年計算のサンプルプログラムでは「年」の入力欄が2桁だったことを覚えています。

そういった慣習から業務用のシステムでも「年」の入力欄は2桁で入力するものが多くありました。また、「今」の日付を表現するのに西暦の4桁の内、上2桁を取り去り下2桁で処理する物もありました。
1900年代に使い続け、1999年まではそれでも問題無いのですが、2000年になったと同時にそれでは問題が起きることは、誰でもわかるような問題です。

西暦の計算が2桁

仮に使用時間で課金をするシステムだとすると、1999年12月31日 22時00分から2000年1月1日 2時00分まで4時間使用した場合、 開始時刻：99年12月31日 22時00分 終了時刻:00年1月1日 2時00分 という処理となってしまいます。
未来から使用し始め過去に終了しているため、

• 小さな数から大きな数を引いたため異常な処理が起きてしまう
• システム内で意図せず正の整数に変換し膨大な使用時間と算出してしまう
• 使用期間が負の数となるためマイナスの金額を算出してしまう

などの可能性があり、 異常な計算結果が出力されること や 想定外の数字が異常動作を引き起こしてしまうこと などが予想されます。

このように年の計算を2桁で処理することからシステムの異常を発生させてしまう問題を総称して 2000年問題 と呼びました。
処理の対象がお金に関わる物であれば、取引等において大きな問題に繋がります。また社会インフラを制御するシステムが誤動作した場合、生活を脅かす恐れも有り、どのような影響が起きるかについても誰も全容がわからないという状況でした。

既にコンピュータを使用した処理が一般的となっていた1998年前後にニュースなどマスコミでも大きく取り上げられ、システム仕様設計に関する責任問題や対策進捗など話題は事欠きませんでした。
そして1999年の年末が近づくと、人的な運用での対策について話題は移っていきました。

待機

当時私は通信機器保守企業に所属しており、様々な機関・団体等の通信システムの保守をさせていただいていたため、年末から年始にかけてはすぐに業務対応ができるよう、待機の態勢を取るように指示を受けていました。
電話や無線などの通信機器も、もちろんコンピュータで制御されています。

また、消防団にも所属していましたが、消防団の団員全員も待機体制を指示されました。
消防のシステムが誤動作し通常の指令体制がとることができないかもしれない 、 消防団の車両で救急搬送をしなければいけない 、など想定することが出来ない異常事態が発生した場合のバックアップとして消防団の出動も考えられたからです。
私は業務での待機体制の事情で消防団での待機体制からは外れていましたが、このように多くの方々が待機の態勢を取った年末年始でした。

2000年1月1日

そして2000年1月1日を迎え、影響は様々な形で出てきましたが、社会全体から見ると大きな問題は発生せず対策が功を奏した結果となりました。
私本人の業務については、毎年1月1日に対応する定例業務を抱えていたため、年明けの1月1日未明に呼び出しが無い事を確認したのち朝からその定例業務を行い、その後何の業務指示や呼び出しも来てないことを確認し、関係各所も問題が発生してないことを再確認して帰路に向かいました。
今年の正月の様に穏やかな天候だったことを覚えています。

当時に学ぶこと

現在多くのプログラミング言語では時間や日付に関する計算処理を備えており、あえてこれを利用しないという選択をしない限りこのような問題（バグ）は起きなくなりました。
しかしながら新たに見つかる問題や想定外の問題は、依然として無くなりません。
※参考： 2036年問題、2038年問題など

ソフトウェアのバグ（意図していない動作もたらす開発上のミス）は、0になることはありません。0になることを目指して開発は行われますが、人為的な発想を繰り返して作成されるものであるという性格上、バグが全く無いソフトウェアを開発することは困難です。突然異常な動作による影響を受けるよりは、むしろ継続的にバグを検出して対策を続ける事の方が良い取組とも考えられます。

直接的であれ間接的であれ、ソフトウェアを利用する私たちは、こういった設計や開発、構築段階でのミスや不備に付き合っていくしかありません。
全く違う話ですが、昨年末にとあるところでランサムウェア（システムやファイルへアクセス出来ないようするマルウェア。攻撃者は解除するための身代金を要求する。）に感染しPC内のファイルを失ってしまった状況に立ち会わせていただくことがありました。
こういった脅威も含め、便利なことや都合の良いことについては、 バックアップを取得する 、 代替手段を用意しておく など、何かの時の備えを含めて物事を考えておかないといけないと感じています。