昭和100年問題　レガシーなシステム大丈夫ですか？　もうひとつの2025年の崖問題

COBOL

2019年5月1日　年号が変わります。
IT小僧は、オジサンなので、昭和から平成、平成から？？？？と
２回年号が変わるののを体験することになります。

平成の幕開けは、日産自動車の「お元気ですか？」というCMで、井上陽水の言葉が無音になるなど
暗い雰囲気につつまれていたのですが、システム屋は、時間がない中で「昭和から平成の年号変換対応」に追われていました。

今回のIT小僧の時事放談は、
昭和100年問題　亡霊（レガシー）システムは、大丈夫ですか？　もうひとつの2025年の崖問題
と題して　まさか、平成の世になって３０年近い日々が経過している中で
「さすがにシステムもリニューアルしてるだろ」と思うのですが、万が一のためブログにまとめました。

小難しい話をわかりやすく解説しながらブログにまとめました。
最後まで読んでいただけたら幸いです。

スポンサーリンク

３０年前のコンピューター

今どきのコンピューターシステムは、メモリー、ディスクとも潤沢なので２桁を４桁に増やすなんて気にする人もいないと思いますが、３０年前は、違いました。

ビルの１フロアーを占めるコンピュータールーム、立ち並ぶハードディスクとテープリーダー
轟々とおとを立てるディスクと冷却ファン、夏でも防寒具が必要なほど冷やされたなかで仕事をしていました。
１つのタワーに収められているハードディスクは、

640メガバイト

640ギガではありません、640メガバイトですよ。

市場に出始めた、NEC　PC9801のメモリーは、64キロバイトで拡張して128キロバイト
当時の主力記憶媒体のフロッピーディスクと呼ばれるものが、5インチ　2HD（両面高密度）で約1.2-1.4MBの容量ですから、640メガバイトなんて広大すぎて埋め尽くせるものも納得できたのでした。

いまや、スマートフォンという手の上に乗る「万能型スーパーコンピューター」を使う我々にとってこの数字は、誤差レベルと言ってもいいでしょう。
たった３０年でこれほどの進化を遂げるとは、驚異的です。
当時、プログラム作成で、漢字をコードで打ち込んでいた自分に見せてあげたい。

平成に振り回されたコンピュータ屋

昭和から平成に変わるのは、忙しかった。
今回の開眼のように間に一ヶ月などの余裕もなく

「元号は、平成となりました。」

と故小渕官房長官の発表をテレビで見ていたら電話が鳴った。

「来週発行の伝票に間に合うようにすぐに元号を変えてくれ」
という上司の言葉

「来週って、３日しかない・・・」
こうして、当時のコンピュータープログラマーは、年号対応を急遽迫られ、その日から数週間、泊まり込みに近い状態で客先の大型コンピューターに向かっていたものです。

下２桁の年号

当時の言語は、COBOL、データベースの年号は、下２桁が、常識でした。
つまり、1995年は、データベースの中では、'95'と設定されるのが常でした。
理由は、ディスクサイズの節約です。

データベース設計で４桁の年を設定すると先輩方から怒られたのです。
「２桁というけど、数十万のデータだったら、その２桁でどれだけのディスクサイズが必要になるか考えろ」と
このことは、当時のCOBOL使いの常識でした、

今どきのプログラマーは、知らないと思いますが、当時のコンピューターのエディターは、シングルタスクが基本、縦25行、横128桁しか表示できない画面で日付のロジックを探し出し修正を続ける。

クラスなんておしゃれなもののない時代、サブルーチンと呼ぶライブラリーをINCLUDEで呼び出していた時代です。
「日付のサブルーチンを修正すれば終わり」
と思ったら大間違い。

多くのベンダーが入っているシステムでは、

WK_WAREKI = YY - 25

のようにプログラムの中に直で昭和の年号を求めているプログラムが多数あったのです。
星の数ほどあるシステムの中のプログラムを年号変換をしているプログラムと場所を見つけ出し修正を行う作業が続きます。
例えば

WK_WAREKI = YY - 25
などの箇所を見つけだし

などのように「平成和暦」修正が行われました。
※修正方法は、いくつかあるが、これは、やっつけ仕事で間に合わせるために行ったものです。
参考までにこの当時は、Javaなどもなく、クラスという概念もまだ普及していない時代でCOBOLも ELSEIFなどない時代

これが、後の2000年問題で再度修正されることになりますが、当時は、システムが「10年持てばＯＫ」という状況なのと時間がないということでデータ構造まで手が出なかったのです。

昭和100年問題

さすがにこの30年以上前のシステムが今でも動いているとは思えませんが、先日、JALのシステムが完全移行しましたが、それまでは、50年前のシステムが動いていたそうです。

金融系システム

金融系などでは、常にシステム改変が行われているだろうし、いまさら大型汎用機とCOBOLのシステムが可動しているとは思えません。
昨年、リニューアルした「みずほ銀行」のリニューアルが、最後の大物と思っています。

お役所

お役所もさすがにリニューアルしているだろう、
もしあったとしても2000年問題の時に修正しているだろう。
しかし、インチキ統計問題で明らかになったようにCOBOLで書かれているプログラムもゼロではない
そこで日付処理が古いものがあったら・・・

特にお役所は、和暦で処理をしているところが多いので少し心配

一般企業

そもそも、和暦を使う企業は、減っているはず。
30年の時を超えて可動しているものもないだろう

中小企業

これは、可能性ありそうです。
古い工場では、まだ NEC　PC9801が、可動しているところもあるらしい。
危険だなぁ

和暦でデータ保持

安心するのはまだ早い。
ここまで書いてきたのは、データベースの年号が、西暦下２桁が入っている場合です。
日付の内部データが、昭和2ケタ年のままで、「昭和65年」を画面や帳票出力を「平成2年」などと変換していたらどうなるか？

平成への改元は昭和天皇の崩御で急きょ決まりました。

内部データを昭和のままにして表示を平成に変換しているシステムはあるはずです。

限られた時間で業務を止めないために

「内部データが昭和（和暦）のままで　平成に変換していたとしたら」
そして
「2025年1月1日　昭和100年になり内部データが00になったとき」

なにがおこるかわからない。
あと2年
今更、こんな古いシステムを使っているわけがないと思いますが、
昭和期に開発されたレガシーの業務アプリケーションを、従来のソースコードのまま自動変換して使い続けている企業があったら危険です。

まとめ

いささか古い話で読者の皆様には、ピンとこないと思いますが、３０年前のプログラマーは、信じられないほどの納期のないところで仕事をしていました。

今回の年号変更は、期日が決まっているので、このタイミングでプログラムを見直すことになることでしょう。
しかし、昭和のレガシーシステムを解読して修正するには、ある程度のスキルが要求されます。
そう、現役を引退のオジサン、オバサン世代や、IT企業で偉くなって椅子にふんぞり返っている人の出番がもう一度やってくるかも知れません。

以前、「2025年の崖」というテーマでブログをまとめました。

まさか、ここにも2025年問題が潜んでいるとは思いもしませんでした。

昭和のシステムがなくなるまでこのような問題は、次々と起きてくることでしょう。
あなたの会社で和暦を使っている昭和のシステムがあったら、念の為に見直すことをオススメします。