１．コンピュータ西暦2000年問題
◇従来のコンピュータが、西暦を下2桁でしか認識しない様式であったため、2000年以降のデータを処理する場合にシステムがストップしたり、混乱したりする問題。
◇システムを保有する者は、プログラム・データの修正、システムの再構築等の対応が必要。
２．問題の背景
◇コンピュータでは、西暦年を下2桁で表記することが通例であった。
◇システムが更新された場合でも、コンピュータシステムにおける既存データの互換性確保の観点から、2000年問題を有するプログラムが継続使用された。
◇コンピュータでは西暦年を下2桁表記してきた
(1)1960〜1980年代のコンピュータの導入、普及時期においては、大量のデータを保存・処理することは技術的に困難であり、非常に高価なメモリやハードディスク容量の大幅な拡張なしには不可能であった。
(2)コンピュータ産業が育成されてきた欧米で、西暦年の下２桁表記が慣例であった。
(3)また、主に事務処理用コンピュータのプログラムに用いられているコンピュータ言語であるCOBOLのISO規格は、かつてコンピュータのハードウェアからプログラムへの西暦年データを受け渡すときに西暦年を下2桁で処理することが規格化されていた。
COBOL言語規格の経緯
1968年ANSI（米国規格協会）で「2桁年数処理」が規格化
1972年ISO（国際標準化機構）で「2桁年数処理」が規格化
1989年ANSI、ISOで「4桁年数処理」もオプションとして並記
1992年1992年のISO改正版の出版を受けて、JIS改正
３．想定される具体的事例
(1)基本的障害
○日付が設定できない
1999年に、1年後に必要な部品を発注した場合、その部品の納入処理が行われない。
○期間計算がおかしくなる
・年数の計算
・閏年の計算
西暦年下2桁では、2000年を閏年と判定できない。
○必要なデータが抽出されない
○必要なデータが消去される
部品在庫管理データファイルからデータが消去される
○日付順にデータが正しく並ばない
1900年代と2000年代が混在するデータを日付順に分類すると前後関係がおかしくなる。
○和暦表示がおかしい
「00」年を1900年と判断し、明治33年と表示。
(2)具体的障害
・2000年以降の予約不能
・商品受発注が不能
・金融取引に支障
４．対応方法
(1)準備
現行のシステム環境及び保守状況を調査し、実施計画を策定するとともに、社内へ啓発を行う。
(2)対応状況調査
ソフトウェア資産の棚卸、OS関係の対応策、業務プログラムの日付の使われ方、メーカの対応等を把握し、対応方針の決定の資料とする。
(3)方針決定
ハードウェアのリプレース、OSの変更、業務システムの修正、システム再構築等の対応方法を決定する。
(4)修正／再構築
OSの変更、業務プログラムの修正、データファイルの修正などを行う。システムの再構築を行う。
(5)テスト
修正されたプログラムテストのための環境設定、テストデータの準備などを行い、テストを実施し、修正結果の検証をする。
(6)本番移行
稼働環境の設定後、プログラム及びデータファイルを移行し、稼働結果の確認を行う。