2019年4月30日、天皇陛下が退位され、翌日である5月1日に皇太子殿下が新天皇として即位されることになりました。一世一元制度が導入されている現代では、「明治」以降、天皇一代につき1つの元号を用いるようになり、退位のタイミングに合わせて元号も変更されることになっています。

また、景気回復が十分ではないという理由で2回に渡って延期されてきた消費税の増税（8%→10%）も、いよいよ2019年10月1日に施行される機運が高まっています。連日、新聞・テレビ等で、増税時の負担軽減策や増税の可否そのものについての報道が繰り返されているため、国民全体の関心も高まっている事柄と言えるでしょう。

元号や税率の変更は、世の中的に注目度の高いイベントですが、IT業界においても同様に、とても注目度の高いイベントと言えます。本記事では、元号が変わる・消費税が増税になるといった、社会制度の変更がITにもたらす影響を、システム開発の観点で考えてみたいと思います。

改元と消費税増税を、システム開発の観点から振り返る

1. 元号が変わると・・・

一番最初に思いつくのは「生年月日の入力欄の項目が増える」ことではないでしょうか。

2017年10月1日の総務省人口推計によると、明治・大正生まれの方の人口は「1,701名」です。そのため、新元号が制定されたからと言って、生年月日の入力欄から「明治」を消すことはできません。そうなると、これまでの入力欄のスペースはそのままに新元号を増やすのか、スペース自体を拡大するのか、考えなくてはなりません。

加えて、和暦と西暦の変換のテーブルを持っている場合は、テーブルに項目を増やした上で、和暦と西暦の紐付けを変える必要があります。

2. 消費税が増税されると・・・

当然のことながら、消費税の加算（もしくは減算）時の数値（パーセンテージ）を変更しなければなりません。昨今のシステムでは、税率が可変になるように設計されている場合がほとんどだとは思いますが、古くからあるシステムでは税率がハードコーディングされている場合もあるでしょう。また、消費税増税前後の期間がまたぐ場合はどうするのか、軽減税率適用時はどうするのか、仕様をどうするのかギリギリまで決まらない可能性もあります。

お金が絡むものですから、計算に誤りがあってはいけません。システム開発の現場では、様々なパターンで計算結果が誤っていないか、テストされることになるでしょう。

まとめ

元号の話題に関連する話として取り上げられる「2000年問題」。1990年代後半に大きくクローズアップされたときには、「ミサイルが発射される」「原子力発電が停止する」「医療機器が誤作動する」などと、クリティカルな問題が発生してしまう可能性をメディアが多く取り上げ、社会的な不安が増長しました。その後、多くのエンジニアたちの必死の努力の結果もあって、致命的なトラブルが起きることもほとんどなく、社会全体として乗り切ることができたのです。

消費税増税の例では、前回（5%→8%への）増税時には、増税施行初日にあるスーパーマーケットチェーンでシステムトラブルが発生し、営業停止する事態になってしまいました。

年号や税率のような、社会的変化がシステムに対して及ぼす影響は非常に大きいため、計画的にテストを実施し、問題が発生する場合は改修を行う必要があります。しかし、システムの設計者・開発者は、「元号が変わっても、項目追加するだけ」「データベースに登録されている税率をパッチ当てて変更すればいいだけ」などと安易に考えてしまいがちです。理論的にはそうなのかもしれませんが、イレギュラーケースも含めたすべてのシナリオを思い浮かべて検討し、「絶対に問題が無 い」と自信を持って言い切れる開発者は実際にはほとんどいないでしょう。

システムを設計・開発したエンジニアではない者（＝第三者）が客観的にシステムのテスト・検証を行うことで、予期しない問題が発生しないか確認・評価することができるのです。

2019年は、元号の変更に消費税の増税と、大きなイベントが控えています。こうした機会を第三者検証でシステムを点検する良い契機と捉え、きちんと対応できているのか確認してみるのもよろしいのではないでしょうか。

【参考文献】
総務省　人口推計　平成29年10月1日現在（結果の要約，概要，統計表）