2024.01.18
2019年4月30日に今上天皇が退位され、日本で約30年続いた「平成」という年号は終わりを告げます。2019年5月1日には、皇太子殿下が新天皇に即位され、この日に合わせて日本は新しい年号を用いることになります。
現在、日本の年号は一世一元の制度をとっており、天皇が変わるということは元号が変わるということを意味するわけです。
元号変更（改元）がシステムに与える影響
元号が変わるということは日本社会のさまざまな方面に大きな影響を与えます。
改元で影響を受ける業種
わかりやすい例でいえば、手帳やカレンダーなどに和暦を用いている印刷・出版業者です。しかし、元号が変わることによって最も大きな影響を受けるのはITシステムでしょう。日本では官公庁・自治体・金融機関などのシステムを中心に依然として和暦が用いられています。そのため、元号が変わるということは否応なしにシステムの改修を余儀なくされるわけです。
昭和から平成への改元と現在の違い
かつて元号が昭和から平成に変わった1989年は、現在と違いスマートフォンもインターネットも存在しない時代でした。また、パソコンも8ビット及び16ビットのものが一般的で、普及台数も現在に比べれば格段に少なかったです。
そのため改元に関連したシステム改修は決して楽ではなかったものの、ある程度影響範囲と作業量は予想可能なものでした。しかし、スマートフォンも含めコンピューター端末が爆発的に普及し、インターネットが社会インフラ化している現在、改元が社会に与えるインパクトは前回の改元とは比べ物になりません。
今回の改元とシステム改修のやっかいな点
現在では、官公庁で用いられているメインフレームと呼ばれる巨大なシステムから、Windowsを中心としたPCやスマートフォンなど、さまざまな種類のコンピューター端末のOS及びアプリケーションがこの変化に対応しなくてはならなくなっているわけです。
その上、近年ではIoT技術の普及・発展により、自動車や家電などかつてはコンピューターとは無縁であったものがインターネット接続されコンピューター制御されるようになりました。
これらのコンピューターシステムはいずれもさまざまなOS、さまざまなプログラミング言語で記述されており、全てに対応するには最低限それらに対応可能な技術者を集めることから始めなくてはならないという点が、前回の改元の時との大きな違いです。
新元号の発表から1カ月以内にリリース！
政府は新元号の発表を2019年4月1日にすると表明しています。そのため準備期間はわずか1カ月しかありません。
もともと政府は、新元号を4月10日に開かれる天皇陛下ご在位30年のお祝いと感謝の集いの翌日である4月11日に発表する予定でした。それが前倒しの4月1日に変更になったのには理由があります。
それは、大半の企業が導入しているWindowsの改修の都合によるためです。Windowsの開発元のマイクロソフトは毎月1回、第2水曜日に全世界統一でソフトの更新を行っています。そのため新元号の発表が11日ではソフト更新に向けた改修作業が次の5月8日まで行うことができないため、5月1日の改元には間に合いません。
準備期間は1カ月もない場合もある
このことから考えると、Windowsをベースにしたシステムが新元号に対応するための実質的な作業に着手できるのは、どんなに早くても4月11日以降、つまり期間は一カ月未満ということになるわけです。
2016年には既に天皇陛下が退位のご意思を示されていたため、和暦を使用しているシステムを開発・メンテナンスしているシステムインテグレーターは、既にこのころから準備を進めており、基本的な対策を行っていますが、肝心の変更部分が新元号に対応したOS上で不具合を起こす可能性も考えられます。
そのため、実際には使用しているOSが新元号に対応してからでないと本格的な準備作業には移行できない、というのが実情です。
事前の準備をどんなに万全に行っても、実際にOSがバージョンアップすることによって初めて明るみに出るバグや不具合が出る可能性もあり、テストを含めた改修対応を20日以内に行わなくてはならないという実にシビアな状況にあるわけです。
システム改修が必要な例
新元号に対応するためには、具体的にどのような対策が必要となる（もしくは必要とした）のでしょうか。次に2つご紹介します。
最低限やるべき作業は和暦変換モジュールの変更です。この変更プログラムには、大きく分けて2種類があります。
1つ目は、データベース上の西暦を和暦に変換する和暦変換テーブルへパッチを充てることです。システム上の暦の管理がここに一元化されていれば、対応はそんなに時間がかかりません。比較的最近できたようなシステムではそのような状況を想定して設計するのが一般的なため、特に問題はないでしょう。
2つ目は、ソースコードの中に直接埋め込まれている和暦変換のコードを直接しらみつぶしに直していくという方法です。これは最も原始的な方法であり、システム開発者はこのようなシステムを設計してはいけないと徹底的に教えられていることが多いと思います。
しかし、現実問題としては多くの巨大システム、特に官公庁や金融機関のように何十年も継続して使い続けられているようなシステムの場合は、このようなコードが必ず埋め込まれていないとは言い切れないわけです。
このような問題はレガシー問題と呼ばれ、古くからあるシステムをメンテナンスし続けている技術者にとって頭の痛い問題になっているのです。
また、官公庁や保険業など帳票を多く扱っている業種では、帳票に直接「昭和」「平成」といった元号が記載されており、その上に「○」印を印字する仕様が多くみられることから、帳票出力システムにおいて帳票レイアウトと印字用プログラムを修正する必要もあるでしょう。
システム改修後におけるテストの必要性
やっとの思いでプログラムを改修したからといって、それで終わりというわけではありません。その次に修正した箇所が正常に動作するかどうかを確認するテストが必要になります。
ソフトウェアの変更により、未変更部分に新たに欠陥が発生したり、発現したりしないことを確認するためのテストを「回帰テスト」といいますが、実はこの回帰テストを行うには膨大なコストがかかります。
なぜなら、回帰テストを行うためには変更がシステムにどのような影響を及ぼすかを調べる「影響度分析」といわれる作業を必要とし、その分の作業工数も多く見込まれるからです。
古くから使われているシステムの場合、仕様書がメンテナンスされておらず不完全だったり、そもそも最初から存在しなかったりするケースが少なくありません。
一般に「保守作業の40～60%程度の工数は、改変するソフトウェアを理解するために割かれる」といわれており、影響度分析にかかる時間と労力はかなりなものになることが予想されます。テストそのものも大変な作業ですが、事前に行う分析もそれに負けず劣らず大変というわけです。
以上のように、元号が変わるだけで、システム全体に膨大な影響があるということがわかります。しかもこれらの作業をとても短い時間に行わなくてはならないため、エンジニアをはじめとする関係者の負担はとても大きいといえます。
おわりに
このように大変な改元に伴うシステム改修ですが、見方によってはシステム全体を見直す良いきっかけにもなります。
例えば、みずほ銀行は通帳などで和暦の使用を廃止し、この領域で改元によって生じるリスクそのものを無くしました。
「ピンチをチャンスに変える」という言葉はよく使われますが、この改元も企業のIT担当者にとっては上手に活用すれば、レガシーシステムと決別するための良いチャンスとすることができるでしょう。
