改元でシステム不具合よりも深刻だった“人間の脆弱性”：ITりてらしぃのすゝめ（1/3 ページ）

[宮田健，ITmedia]

　2019年5月1日、元号が変わり「令和元年」となりました。ITの視点では2000年問題と同じくシステムのトラブルが起きぬよう、多くの方が対応に奔走されていたかと思います。現時点では致命的なトラブルもなかったようで、まずはひと安心といったところでしょうか。

　むしろ10連休で非営業日が連続したことによるトラブルの方が目立ったという印象です。確かにこの連休で積み重ねられた作業量や、連休明けの金融関連サービスへのアクセス集中は想定外だったかもしれません。関係した皆さまにはお疲れさまでした。

• 楽天銀行、接続しにくい状態に　連休明けでアクセス集中か（ITmedia NEWS）

連載：ITりてらしぃのすゝめ

「身近な話題を例にITリテラシーを高めていこう」がコンセプト。さらっと読めて人に話せる、すぐに身につく。分かりやすさ重視で解説。小ネタも扱います。

（編集：ITmedia村上）

ITにおける「改元」とは

　次の改元まではかなり長い期間が空くと思いますが、改元に伴って私たちが注意するべきことをいま一度振り返ってみたいと思います。

元号変更の心構えは「緩く」がポイント？

　まずは心構えを。今回多くのシステムでは影響がなかったものの、トラブルもありました。個人的にとても興味深いと思ったのは、一部の金融機関で先の日付の振込処理を行ったところ、本来連休明けの2019年5月7日（令和元年5月7日）と表示されるべきものが、なんと「1989年5月7日」と表示されたというトラブルです。

　これに関しては、あくまで対象の銀行Webサイトでの表示上の問題であり、振り込みは正しく行われるという案内がありました（現在はその文言は削除されていますが……）。実際にこのトラブルに遭遇された方の記録が下記リンクにあります。

• 【令和バグ?】コンビニATMで振り込みしようとしたら画面に出た日付がまさかの平成元年「これ出ちゃいけないバグでしょ」※追記あり（Togetter）

　ここから分かることはたくさんあります。まず、このトラブルは確かに表示上の問題であるとは思うのですが、金融機関のシステムの一部は内部で和暦を使っていると想像できるのです。

　恐らく内部で「新元号元年」として処理すべきところを、令和ではなく“平成元年”と誤って判断する処理があり、それを表示上西暦にしたことで、2019年が1989年に化けてしまった、と考えるべきでしょう。この不具合自体はすぐに直せるでしょうが、「内部で和暦で記録する」という処理自体がいまも続いているシステムが確かにあることが分かります。