月刊総務プラス

『月刊総務』本誌記事:

平成終了まであと少し 改元対応のポイント

2019-04-22 11:38

2019年4月30日をもって、30年続いた「平成」が終わりを迎えます。
新元号「令和」の発表で盛り上がる昨今、改元に伴う混乱はまだまだ続きそうですが、企業活動においては具体的にどのような影響が出るのでしょうか。改元のタイミングがわかっているのが今までとは異なる点。残りの時間で何をすべきか、何に注意すべきか、業務を滞りなく行うためにも、対応のポイントを確認していきましょう。

改元に伴うシステム改修対応

改元によって想定される混乱

 政府は2018年5月17日に2019年5月1日に切り替わる新元号について、同年4月1日の公表を想定して準備を進めると発表しました。

 これにより30年間続いた「平成」が終わり、今上天皇陛下が退位し、新しい天皇が誕生し、新しい元号に切り替わります。

 そこで改元によるシステムの改修等の必要が出てきました。一部では「2000年問題」の再来と叫ばれ、そのときの悪夢を思い出す方も多いのも事実です。

 2000年問題は1999年から2000年になったとき、当時の情報システムがメモリーを節約するために西暦の下2桁しか記録していないケースが多く、2000年になった瞬間にシステムが1900年と認識してしまい、情報システムが誤作動、停止などを起こしてしまうというものでした。

 しかし、2000年対応は当時のエンジニアが総動員されたことと、事前に改修を行ったことでそれほど大きな問題は実際起きませんでした。その後、IT企業、システム開発会社、そしてユーザーはこの2000年問題の教訓を経て、改元によって情報システムに改修が必要なことと、大変な労力が掛かることがわかったため、和暦についても、いつか変更になることを重々理解しています。

 つまり改元がいつ起きても対応できるように仕様・設計・開発を行ってきており、逆に改元に対応できないような情報システムの場合、仕様・設計・開発自体に問題があるといわざるを得ません。

 とはいえ、民間の情報システム以上に非常に複雑になってきている政府や自治体の情報システムでは証明書などに和暦である「昭和」「平成」などがほぼ100%記載されているために、元号対応の情報システムの改修が遅れると住民票の発行ができなかったり、住民税などの納税の際に記録が残らなかったりするなど問題が発生する可能性があるとしています。

 また、2019年は元号が「平成」と新元号の両方を持つ特殊な年となることで何が起こるか予測が付かない可能性もあります。これらの状況でエンジニア不足に悩む昨今において、早急の改修ができるかなどの混乱も予測されています。

改元前に何をすべきか

img04.png

 企業と政府や自治体、この2つは改元前に対応すべき情報システムの改修事情が違います。

 企業の場合は、現在利用している情報システムにかかわるIT企業、システム開発会社に対して、改元後の対応方法や改修状況を確認します。

 政府や自治体は、改元決定後から改修計画を立てて対応していると思われるので、そこは政府や自治体へ納入しているIT企業、システム開発会社に任せていくしかありません。

 現状、私たちが確認しなければならないことを「改元前のシステム対応チェックリスト」(図表4)にてまとめています。企業によって、該当しない項目もあるので、自社の情報システムはどれに該当するのかきちんと確認しましょう。

 また、チェックが付かなかった項目は、図表5を参考にしてチェックが付くように対応を検討していくことをお勧めします。

注意しておくべき点

img05.png

 今回、改元に伴うシステム対応は図表4のチェックリストの事項を一通り行えば大きな混乱はないと思います。パッケージやクラウド(SaaS※)であれば、その情報システムのバージョンアップを行う、または自動的にバージョンアップすればことが済むので、利用者である企業側は、特に改元の改修対応についてすることはありません。

 ただし、注意が必要なのが企業が独自で開発した情報システムの場合です。この場合、個別のSEやエンジニアが開発をするため、企業側は詳細な仕様・設計などの専門分野までは理解できていないことがほとんどです。つまり、今利用している情報システムが改元の際に元号のデータを一括管理しているかどうかが不明ということになります。

 一括管理とは、元号の情報を一括でデータ参照し、1か所の元号を修正すればすべての元号変更ができるように仕様・設計された情報システムです。Microsoft Windows の日付変換処理がされていれば1か所の元号変更で終了できるケースなどもあります。問題なのは元号表記のあるシステムが、それぞれ個別に元号情報を持っている場合です。

 その場合、見積書、注文書、請求書、領収書など、すべての帳票や情報システム内部の元号を個別で変更する必要があります。同時に、改修後はきちんと情報システムが稼働するかを確認するための単体テスト、総合テスト、運用本番テストも必要です。これを、稼働している本番の情報システムとともに並行で対応するために、バックアップを取り、休日や稼働時間後に対応しなければなりません。

 ですから、企業ごとに独自で開発した情報システムはIT企業、システム開発会社に早急の確認が必要です。その際、図表4でチェックが付かなかった項目は、図表5のアドバイスを参考にしてみてください。

 元号変更や消費税増税などはあくまでも想定できる範囲の改修になります。2000年問題のときのような大きな騒ぎにもならないと思われますが、備えあれば憂いなしです。見直しのきっかけにもなるので、この機会にいろいろと確認してみましょう。

※ Software as a Service:提供者(サーバー)側で稼働しているソフトウエアを、インターネット等のネットワーク経由で、利用者がサービスとして利用できる情報システム


ブリッジソリューションズ株式会社
代表取締役 阿部 満さん

経済産業省推進資格ITコーディネータ。富士ゼロックスIT関連企業にて、日本最大のネットワーク・セキュリティー業界のマーケティング関連に従事。その後、京セラ関連IT企業、ITコーディネータ協会職員を経て40歳で創業。中堅中小企業へのIT導入支援やアドバイスは1,000社以上。主な著書に、ITコーディネータ協会認定教材『IT経営実践の知識』(同友館)『IT経営可視化戦略』(産能大出版部)。コラム等を含め執筆多数。