Ｙ２Ｋ問題／真の問題は？

「２０ＸＸ問題」という言葉がいっぱいあるが、その始まりは、「２０００年問題」＝Ｙ２Ｋ問題であった。

2000年問題ってなんだっけ？

1960年代や70年代などに開発されたソフトウェアの中には当時極めて高価で容量の少なかった記憶装置を少しでも効率的に利用するため、1975年1月31日を「750131」とするなど、年号部分を西暦の最後の2桁のみで記録しているものがあった。

当時は数十年先の西暦2000年まで同じソフトウェアやデータ形式が使われ続けるとは想定していなかった。

だが、実際には、システムは過去のデータを引き継ぎつつ進化していくものであるが故、システム化が早かった公官庁はもちろん、金融系および大企業の多くのシステムは、1990年代の半ばですら、西暦を最後の２桁で記録するシステムが多く残存していたことがわかった。

そのため、2000年1月1日を迎えると同時に、機能を停止したり誤作動するなどして使用できなくなることが懸念された。

生じる事態や影響範囲が正確に把握できず、社会インフラや官公庁、交通システム、金融システムなどに深刻な影響が出ることも想定された。
まさに、その想定こそが「2000年問題」であった。

ノストラダムスの大予言と2000年問題

わたしも、もう既に社会人になっていたため、Ｙ２Ｋ対策プロジェクトを経験している。

私の担当はビルファシリティ関連であったため、自社の入退館システムをリプレイスしたり、ＰＢＸのＳＷの更新を行ったり、株主総会や全社会議を行うホールなどのＡＶシステムなどの改修を行ったりもした。

だから、休日返上で土日祝まで出勤して、物理工事の立ち合い、新システムの検証テスト、切り替え作業などを行ったりもした。

ちょうと、ノストラダムスの大予言で、『1999年に人類が絶滅する』という噂もあり、その原因は、2000年問題で、核弾頭が発射されるとか、原発が大事故を起こすことではないか？と、まことしやかに言われていた。

だから、2000年1月1日の元旦に、特に問題がないことをオフィスで確認して、ホッとしたのを昨日のように覚えている。

実は先送りしただけだった

2000年よりさかのぼること11年前の1989年に、昭和から平成に変わる際に、和暦で日付を管理するシステムの平成対応で取った方法が主に４パターンあった。

　１．西暦化＆4桁化（4桁＝901231→19901231）
　２．西暦化だが、2桁のまま（データの書き換え実施）
　３．暫定西暦化（昭和歴でデータを残し、＋25年で表示）
　４．暫定平成化（昭和歴でデータを残し、－63年で表示）

この時、「１．西暦化＆4桁化」をとしておけばよかったが、急な年号変更や、春から始まる消費税対応で、システムエンジニアが枯渇する状況下でもあり、2～４の暫定対応を取らざるを得ない企業が多かった。

だから、データは昭和歴のまま残す手法（上記１．２以外）が多く取られた。

中でも、4は暫定策として一番賢い。４は昭和99年＝2024年まで延命可能である（実は、令和になる際にも表示を－93年するだけでいい）。

２と３は、1999年に、またシステム改修が必要となることが明確であった。

平成元年と言えば、バブル景気のピークでもあり、2000年までには、システムを入れ替えることも容易いという甘い予想があったので、とにかく今は簡単に！としたのだった。

だが、2000年に向かう頃は、大手金融機関ですら破綻をする時代だったため、2000年対応すらさらなる暫定対策で乗り切ったシステムも多かった。

暫定策は、99－50として、データを一括修正するもので、イメージ的には以下の通り。

1999年12月31日の日付データ＝991231－500000＝491231

企業のシステムデータは、古い会社でも1960年ごろからのデータしかないため、マイナス50としても、整合性は保てた。

つまり、2049年まで延命させられる？というわけである。

延命を阻止するデータ流通の時代

インターネットの普及と、システム連携強化により、各種のシステムが個別で動くのではなく、連携をする必要が出てきた。

人事データは、給与・財務会計や情報系のシステムとの連携が必要だったり、認証システムに連携される、そして勤怠管理や入退館システムとも連携されるのが当たり前になっている。財務会計システムは、金融ともつながり、購買管理系は、仕入れ先の各種システムともつながる。

工場のライン管理システムだって、販売店のシステムとつながっているし、産業用ロボットや各種加工機器のセンサーと生産管理システムや定常仕入れ管理システムがつながったりしている。

そのため、日付のみならず、企業内外問わず、あらゆるデータの構造を合わせることが求められる世の中であるからして、個別のシステムでデータをどう持たせるかの自由度がなくなっている昨今においては、２０００年対応時の応急策がなんとも牧歌的で郷愁を感じるほどである。

そして、先送りできない時代へ

前例主義では成り立たないし、いわんや、タイムマシン経営も無理な時代になりつつある。

おそらく、2000年問題を作ったのは、「変わる」ことを嫌う人間の性（さが）に起因するのではないかと思う。

例えば、誰が見てもダメな仕組みであっても、何とか使っているうちに、段々慣れて、居心地よくなる。ある時、だから変えると言われても、変化を嫌う、今のやり方に慣れた人間が、変革を拒む抵抗勢力になることがよくある。

また、言い方を変えれば、断捨離をすることができない煩悩に起因するのではないかと思う。

例えば、一度作ったんだから、除却できるまでは使わざるを得ないという習慣もある。

決める勇気と捨てる力！

Ｙ２Ｋ問題から学ぶ反省としては、小手先で乗り切り、個別最適にすることが、後々どんどん問題を大きくするだけでなく、成長の足かせになるということである。

物事を進めるうえで、まず最初にやるべきは、自分たちが進むべき方向からグランドデザインを描き、それに対する現状とのギャップを明確にし、皆で共有することで、ギャップを解消する手立てを考え、形にすることができるか？である。

だが、Ｙ２Ｋ以降、同じような過ちを何度も犯し続けているような気がする。

このスパイラルから抜け出せるかどうか、まさに今が一番つらいところであることだけは間違いない。

コロナ禍がまさに、人類に大きな変化することを求めているが、まさにそれが一つの試金石でもあるのだろう…

コロナ禍を追い風に変化できるか、逆風になり負けてしまうか？