ミレニアム・イヤー直前に騒がれた「2000年問題」、もしくは「Y2K問題」（Yは年、Kはキロ）を、その頃企業に勤めていた人ならまだ覚えている方も多いでしょう。
2000年問題は、社会の重要なインフラとなったコンピュータが全世界的に初めて経験する危機でした。
2000年問題とはどういう問題で、我が国はどう対応し、結果はどうなったのでしょうか。
同様に「2000年閏年（うるうどし）問題」ということもありましたが、知っていましたか。
また2025年には昭和100年問題、2036年、2038年にも、新たな問題が起こるといわれますが、本当なのでしょうか。
2000年問題とは何だった？
2000年問題とは、
「コンピュータ・プログラムが、西暦を例えば1998年なら下2桁の98で処理していたため、2000年になると00と認識したり、西暦2000年代のものを1900年代と誤って判断することによって、システムの停止や、誤作動などの様々なトラブルが発生する恐れがある」
という社会的な危機のことでした。
この2000年問題は専門家には相当前から認識されていたようです。
しかし、2000年が近づくに従って一挙に吹き出した背景には、コンピュータ利用の拡大によりプログラムやデータが急速に増加し、それまでこの潜在的な問題に手をつけることがコスト的、時間的にみて困難になっていたことがありました。
システムの全面更新の際に対応すればいいという、甘い考えがあったともいいます。
しかし、実際にシステムを更新する場合には、既存システムと互換性をもった新しいソフトウェアに順次変更していく方法が採られ、旧来のソフトウェアの基本仕様を引き継ぐことになることが多かったため、依然として問題は残ったのです。
2000年閏年（うるうどし）問題とは？
次に2000年閏年問題です。
閏年は、多くの人がオリンピックイヤーと同じ年に、必ず4年ごとに来ると思っているようですが、実はそれは間違いなのです。
私たちの使っているグレゴリー暦では、平年を1年365日としていますが、それでは地球の公転との時間差が生じるため4年に一度、１日多い閏年を設けて調節しています。
ところが、4年に1日加えると今度は時間が多くなり、閏年としない年が必要となって来るのです。
そこでその調整のため、次の原則が決められました。
・西暦が4で割り切れる年は閏年とする。
・ただし100で割り切れる年は平年とする
・そのうち400で割り切れる年は閏年とする。
したがって1900年は平年で2000年は閏年です。2100年は平年となります。
そうすると、コンピュータ・システムでは下2桁の認識では400で割り切れるかどうか区別付かないことから2000年を平年として扱い、2000年2月29日が存在しなくなるというトラブルが発生する懸念がありました。
これが「2000年閏年問題」ですが、通常、「2000年問題」と言う場合、この「2000年閏年問題」も含めます。
とにかく、システムが停止したり誤動作するようなトラブルになれば、私たちの生活に大きな被害を及ぼすことになるため、2000年問題には確実に対応することが必要でした。
特に日本は世界でもトップクラスの情報システムを活用した経済大国であり、また地理的にも先進国の中で最も早く2000年に到達するため、その対応に世界の注目が集まりました。
しかし、社会に無数に張り巡らされたシステムの扱う業務、機能、運用環境などは様々で、具体的な問題の対処方法、対処範囲、対処期限などもシステム毎に異なることから、問題の発見、修正、試験には多くの時間とコストが必要と考えられました。
そして言うまでも無く、直接対応に当たるシステム･エンジニアの要員確保も容易ではありません。
例えば、当時の英国2000年問題委員会は全世界で1兆5,600憶ドルの費用がかかるとの試算を発表しています。
我が国での対応
我が国では2000年問題は情報産業では早くから認識されていて、1989年の消費税導入や平成の改元時のプログラム修正時に2000年対応を行ったケースもあったようです。
1998年に、政府は先に述べたような事の重要性から国が主導して対応することとし、当時の小渕総理大臣を本部長とする「高度情報通信社会推進本部」を立ち上げ、行動計画を策定します。
その行動計画に基づき、金融（銀行・証券・保険等）、エネルギー（電力・都市ガス・石油）、情報通信（通信・放送）、交通（航空・鉄道･海運）、医療（医療用具･医療機関）、政府、地方公共団体など、国民生活に影響を及ぼす事項を中心に対策を実施します。
例えば、
金融機関、日銀、東証などの決済・取引システム、原発などの安全･安定運転、航空管制システム、鉄道の制御システム、また医療ではペースメーカーなどマイクロチップを搭載している医療器具について、トラブルが起こらないことの点検やシステムの修正およびテストなどを実施し、99年9月末までにほぼ終了します。
また、この機に乗じて起こるかも知れないサイバーテロなどへの対応も万全の体制を敷きました。
さらに1999年から2000年への年が変わる時点は、昼夜を問わず官邸危機管理センターを中心とする危機管理体制の強化を図りました。
一方、全国の民間企業も、サービスの提供、顧客対応、事務処理、社内連絡など、情報システムが経営基盤に深く浸透している重大性を認識し、社内情報システム部門を中心に、1999年ギリギリまでシステム修正等に従事したのです。
2000年問題の対応結果
以上のように、我が国は官民を挙げて対応した結果、社会･経済活動にほとんどトラブルが起こることなく乗り切りました。
発生した事象は、ほとんどが日付の誤表示などの不具合でした。
なかには核燃料施設の運転制御、監視システムの不具合、2月29日には郵便局のATM、アメダスのデータ不具合、バス・地下鉄乗継ぎの障害など重大問題につながるトラブルも散見されたものの、大事に至らず済んでいます。
この結果について一部ではもともと2000年問題はたいした危険性はなかったという意見もあります。
しかし、「2000年1月1日はサーバールームで寝袋に入ったまま迎えた」という証言に象徴されるように、水面下では当時のSEたちをはじめとする関係者の大変な苦労があったというのが実態です。
仮に彼らの努力がなく、広範な分野においてシステムの点検・修正などを行っていなければ、大量の障害が発生し国民生活に大きな影響を生じたと思われます。
昭和100年問題とは？
ところで2025年に、コンピューターシステム上のトラブルが起こるといわれているのが、「昭和100年問題」です。
ITの分野で、基幹システムで新しい技術を導入できない老朽化したシステムを「レガシーシステム」と呼びますが、運用中のレガシーシステムのなかには、「年」の情報を和暦の2桁で取得しているシステムが残っているといわれています。
ソフトウェアの内部では、平成（1989年1月8日）、令和（2019年5月1日）以降も昭和が連続していて、例えば平成2年3月1日を昭和換算し「650301」、令和3年2月1日を「960201」として処理しているようなケースがあります。
そうすると、「991231（昭和99年12月31日）」の次の日、すなわち2025年1月1日は、「000101（昭和00年1月1日）」となって数字が一巡してしまい、これが誤作動の原因になる可能性があります。
この昭和100年問題が起きた場合、2000年問題で懸念されたような事象が起こるかも知れません。
例えば、「日付のデータが正しく入力できない」「帳票の印字が間違ったものになる」といった誤作動や、日付を使って処理を行うデータベースであれば、データの順番が狂ってしまうといったこともあり得ます。
さらにはこうした表面的な問題では終わらず、システムのストップなどもっと深刻な事態になる可能性も否定はできません。
多くの企業は2000年問題を経験して、システムのベースを西暦の4桁にしており問題は起らないとはいわれます。
とはいうものの、膨大なソフトウェアやデータの中で、和暦を採用したレガシーシステムが残っている場合は、深刻な問題が生じる可能性が十分にあります。
システム設計者が容量を節約し、昭和100年以降おこる事態を想定できずに年を2ケタとしてデータを設計してしまっている場合です。
システム管理に専任の人的リソースを割けない中堅・中小企業はトラブルに見舞われる可能性がありますので、昭和のレガシーシステムが残存していないか、自社システムを検証しておく必要があるかも知れません。
2036年問題、2038年問題とは？
2036年問題とは、ほとんどのコンピュータで使用しているNTP（ネットワーク・タイム・プロトコル）で起こるトラブルです。
このソフトウェアは時間の認識を、協定世界時（UTC）（かつての世界標準時）で1900年1月1日時0分0秒をベースとして、そこから何秒経ったかで計算しています。
その積算は32ビットで計算されるため、2の32乗秒までしか容量がなく、基点から43億秒、すなわち136年でオーバーフローします。
それがUTC2036年2月7日6時28分15秒の時点で、日本時間ではその9時間後です。
その瞬間、リセットされUTC1900年1月1日時0分0秒にもどり、システムに誤動作を起こすと考えられています。
これが2036年問題で、さらに、UNIX系システムでは2038年問題というものがあります。
UNIX、UNIX派生のOS（ソフトウェア）の基幹システムを使っているコンピュータシステムでは、UTC1970年1月1日0時0分からの秒数経過で日付と時間を認識しています。
そうするとUNIX系のシステム内での時間は、2の32乗秒である 2,147,483,647秒後にオーバーフローしてしまいます。
その時刻が2038年1月19日3時14分7秒で、日本時間では＋9時間の12時14分7秒に当たります。
UTC2038年1月19日14分8秒を過ぎると、UTC1970年1月1日0時0分にリセットされシステムが正しく時刻を認識できなくなりトラブルを起こすといわれています。
すでに、丁度中間点の2004年1月10日に、多くの企業で、これに関連するトラブルが、プログラムの人為的ミスなどで秒数がオーバーフローし発生しています。
例えば電話会社で巨額のご請求が発生したり、20行以上の銀行のATMが利用できなくなったような不具合を発生させています。
2036年、2038年問題は2000問題より深刻だともいわれています。
2000年問題とは何だった？昭和100年、2036年、2038年問題も起こる？・まとめ
以上、2000年問題や今後懸念される昭和100年問題、2036年、2038年問題を見てきました。
いずれにしても、今後も、世界中で使用される汎用システムの重大な不具合の種は出現し、その対応のため多くの時間とコストが費やされるのでしょう。
これらの問題が残った理由は、情報システムの普及があまりに急激であり、莫大なプログラムをコンピューターや情報通信システムの中で早急に稼働させたために、長期的な視点がかけたことが原因といわれています。
将来の懸念はわかっていても、問題が起こる前にはシステムは全面更新されるに違いないという楽観論や容量を節約するなどという目の前の必要性を優先し、問題を先送りした結果、今になってその請求書が贈られてきたのです。
2000年問題当時は、ミサイルが誤射されるのではとか、ミサイルを検知する早期警戒システムが誤作動を起こし、戦争になるのではとの噂も流れました。
当時もまさかとは思いましたが、米ロの軍事部門は真剣に監視体制を敷いたともいわれています。
ですから、今後もその請求書はきっちり支払いをする必要があります。
コメント