新元号「令和」が発表されました。
いよいよ新元号に向けたシステム対応も本格的なテストが可能になります。
というのは、既にシステムへの影響調査や改修対応は進められていても、実際に新しい元号を使ったテストはできなかったからです。
また、古いプログラムなどでソースコードに元号が埋め込まれている場合は、新しい元号をもとにソースコードの変更がこれから必要になります。
本記事では、残された1ヶ月の期間で重要になる実データを用いたテストやリハーサルについて紹介します。
新元号への対応（改元対応）の影響範囲
元号が変わるのにともなうシステム対応は以下の通りです。
- マスタやコードテーブルのデータ変更
- 画面や帳票レポートのラベルやレイアウト変更
- 和暦変換モジュールの変更
これらの影響範囲を事前に洗い出し、システム改修の準備を進められているかと思います。
机上での影響調査には限界がある
しかし、机上での影響調査には限界があります。特に古いプログラムや規模の大きなシステムになると、仕様書と実際のソースコードに差があったり、仕様書すらなく担当者も退職してしまっている中で影響を見極める必要があることも珍しくありません。
また仕様書とプログラムがきっちり対応していて、初期開発に携わったメンバーが運用保守を担当している場合でも安心はできません。
周辺システムとの連携でどんな影響があるか、使用しているパッケージやクラウドサービスでどんな影響かあるかなど、読みきれない要素は多分にあります。
そこで実データを用いたテストやリハーサルが重要になってきます。
実データテストで気づけること
実データとは本番環境で実際に使っているデータのことです。個人情報管理の観点などからテスト環境にそのまま保管することはできずマスキングすることはあっても、なるべく本番同等のデータで試すことをおすすめします。
試すべきなのは本番同等のあらゆるオペレーションです。ひととおりの画面操作、帳票レポートの出力、ひととおりのバッチジョブの実行。
これらを実行し、新元号に変える前と結果が「新元号」以外に変わらないことを検証するのです。
想定外にレイアウトが崩れたり、想定外にデータが変換されたりされなかったり、想定外を見つけてはひとつひとつつぶしていきます。
終わりに
残された期間は1ヶ月。一文字で元号を示す合字で文字化けするとか、昭和と平成をboolean型（true, false）で管理しているシステムがあるといった噂も耳にします。
今年は長いGW。滞りなくシステム対応ができますよう影ながらお祈りしております。
