さて…、「西暦が４で割り切れる場合は閏年である。」

これは　閏年の基本的な定義で　誰もが知っている事。

しかし、閏年の正確な計算定義は　実は　それだけでは無い。

「西暦が４で割り切れる場合は閏年である。」だが、

「１００で割り切れる場合は閏年でない。」のだが、

さらに「４００で割り切れる場合は閏年である。」 と言うのが正式である。

地球の公転周期が　約365.2422日の為、４年間で　ほぼ１日（２４時間）ズレるために行う誤差修正であるが、そのままだと４００年で　さらに１日ズレてしまう為の補正が必要となる。

以上の状況により、２０００年の２月は閏年だった。

しかし、これから９５年後の　２１００年の２月は　閏年では無い。

人間の寿命を考えると　私が生きて２１００年を迎える可能性は　限りなく少ない。

だから、こんな計算式等　どうでもいいと言えば　それまでである。

約２０年前　某生命保険会社の運用資産を管理するコンピュ－タ－・システムの制作に関わった事がある。

その時に　システム内のカレンダ－を自らが管理するプログラムの仕様に　上記の閏年の計算式をプログラミングするようにユ－ザ－から指示された。

１９８０年代の話である。

２１００年まで　ほぼ１２０年も　そのシステムが稼働しているとは　どうにも考えられず、そこまでシビアさを要求するのか？と　ユ－ザ－のシステム担当者に言ったら、

「それぐらいの精度を維持・管理するシステムの仕様を私が考案したんだ」

と、胸を張って断言され、強請された。

その１０年後、ハ－ドウェアの驚異的な進歩により、１９８０年代では　ＵＮＩＸを使用し、汎用機を必要としたシステムが　１９９０年代には　一般人が購入する家庭用のパソコンですら　性能を凌駕するに至り、システムの入れ替えを提案したところ　同じ担当者から頑として拒否された。

「このシステムは　私があらゆる状況を想定してシステムを構築し、その後１０年の間に　数え切れないほど仕様を付け足し、完全な状態を保持しているのだ…」と。

しかし、１９９９年になって　コンピュ－タ－システムにおけるＹ２Ｋ（２０００年問題）が世間一般で騒がれるに至り、その某生命保険会社のシステムを擬似的に　２０００年状態にした試験を行った結果、システムは　見事に崩壊した。

１９９９年の時点には　とっくの昔に　私はシステム・エンジニアという仕事からは離れていたが、元のシステム構築に携わった者の一人として協力を要請されたが、バカバカしくて断った。

「閏年の精度にまで　完璧を要求した担当者が構築したシステムなのである、Ｙ２Ｋごときで　問題が生じるわけないでしょ」

私は　口では　そう言って断ったのだが、正直言うと　心の中では「崩壊する」と信じていたからだ。

天下の生命保険会社が　資産を管理するためのシステムを２０年前の設備で行い続ける事、自体が基本的に問題なのである。

２０年前と言えば　今、全盛を誇っているＷＩＮＤＯＷＳも　まだ、日本では完全に実用化されていない実験段階であり、ＵＮＩＸを使っていれば　まだマシではあるが、今のプログラマの多くが使いもしない　コボルとかフォ－トランなんて言語でプログラミングされていたのである。

そう言った言語で記述されたシステムを　現在のハ－ドウエアに合わせた言語で記述し直す事を考えれば、システム自体を新たに設計し直して　一からやり直した方が　余程、効率的であり省力的でもある。

幸いにして２０００年を迎える前に　その会社のシステムは新たに構築されてＹ２Ｋで誤作動を起こす事は無かった。

しかし、２００１年秋　別の会社に合併と言う名目で　事実上、吸収され　会社自体が姿を消した。

毎年、２月の末日になると　その事を何故か思い出すので記した次第だ。