2017/03/15
2016年7月13日の夜、NHKが「天皇が生前退位の意向」との報道を行いました。
それにより、翌日からはニュースやワイドショーが、天皇の生前退位について一気に取り上げ始めました。
この報道を受けてSE（システムエンジニア）やプログラマー界隈では、「元号変更」によりシステム改修が必要になるという話題が持ち上がっています。
筆者は元SE・プログラマーとして、とあるWebシステム開発会社で働いていました。
今は退職したためその肩書は外れています。
しかしながら、約7年間Webシステムの開発に携わってきた人間としては、システム改修の必要性について「確かになぁ」と思うところがあります。
しかし、その一方で、そこまで「大きな問題かな？」とも思います。
もちろん、天皇の生前退位自体ではなく、元号変更によるシステム改修の話ですよ。
筆者は主にWeb上のシステム（例えば、会員サイトなど）の開発に携わってきた人間なので、その範囲のことしかわかりません。
Web以外の開発に携わっているSEやプログラマーの方もたくさんいますから、もしかしたら彼らにとっては大問題なのかもしれません。
私はその分野には詳しくないのであしからず・・・。
ただ、私の知りうる範囲で言うならば、「大騒ぎするレベルのようには感じない」のです。
ネットニュースで「エンジニアに激震」みたいな見出しを目にしましたが、ちょっと大げさかなと思います。
sponsored link
目次
そもそもの設計の問題
今回、「元号の変更」が発生することから「システム改修」が必要であるという話題になったわけですが、そもそも「元号の変更」は予想外のことだったのでしょうか？
平成に入ってから30年近く経とうとしています。
20代の多くは平成時代しか経験していないわけですから、若い人になるほど「元号は変わるもの」という認識は薄くなる傾向にあるかもしれません。
でも、元号はこれまでも天皇が崩御された時に変わってきましたよね。
極端な話、縁起でもない話ではありますが、天皇陛下に万が一のことあった場合には明日「元号の変更」が起こる可能性だってあるわけです。
それを考えると、「元号の変更」はいつ起きてもおかしくないこと。
よって、あらかじめ「元号の変更」に対応しやすいようにシステムを作っておくべきなのです。
もし、元号の変更に対応できないようなシステムがあったとしたら、それはそもそもの仕様・設計に問題があると言わざるを得ません。
こんなことがあったら面倒
元号の変更は予測できるものですが、例外もあります。
それは、元号変更がこれまでとは大きく異なる形で行われた場合です。
例えば、「新しい元号は101年から数える」「文字数が5文字の元号」など、これまでとは違うルールが採用された場合は話が変わってきます。
直近でそうなる可能性はほぼないと思いますが、「生前退位」自体が皇室典範のルールに無いことだそうなので、これまでになかった話が出てこないとも限りません。
これまでの通例に則った形での元号変更ならともかく、全く違ったルールが採用されたりすれば大ごとに発展するでしょう。
どんな対応が発生するの？
とはいえ、現実にはこれまでとは異なる形にはならないでしょう。
通例通り元号が変更されると、具体的にはどのような作業が必要となるのでしょうか？
とりあえず、簡単に思いついたのは次の3つです。
新元号設定の追加
元号が変わること自体は考慮することができても、新しい元号が何になるかはわかりません。
そのため、新元号が発表されたら新しい元号をシステムに適用する必要があります。
一般の方でもイメージしやすいのは、会員サイトの生年月日入力でしょうか。
例えば、誕生年の元号を選択肢から選ぶ形式のものがあったとしましょう。
これまでは「明治・大正・昭和・平成」の４つが並んでいればよかったわけですが、そこに５つ目として新しい元号を追加する必要が出てきます。
元号設定の追加で改修が必要となる箇所自体はWebサイトによって様々です。
面倒なのは、元号設定が一括管理されていない場合。
例えば、元号で誕生年を入力させる欄が何か所も存在し、各箇所で元号の選択肢がハードコーディングされているときです。
各箇所がそれぞれ単独で元号の情報を持っているため、単純に改修するならば、すべての個所に新元号の選択肢を追加しなくてはなりません。
10か所あれば、10か所すべての変更が必要となるのです。
一括管理とは、例えば、すべての必要箇所で同じ元号情報を参照している場合です。
各箇所の元号入力欄の選択肢が共通する元号情報を参照していれば、参照元に新しい元号の設定を追加することで、各箇所にその元号が自動的に追加されます。
1か所の変更によって、10か所すべてに適用されるのです。
元号設定を加えるプログラムの修正を行う場合もありますが、作り込まれたシステムであれば元号設定追加用の管理画面が用意され、ブラウザ上で設定するだけといった場合もあるでしょう。
西暦と和暦の変換プログラム改修
2016年＝平成28年ですね。
例えば、帳票を出力するシステムでは、帳票内の日付表記に和暦が使われているものもあります。
でも、この帳票データに表示された日付情報は、システム内でも和暦で保持されているとは限りません。
というか、データベース上で日付の情報を持つ場合は、西暦で持つ場合が多いのです。
有名なデータベースソフトウェア「MySQL」ではDATE型という日付用のデータの型があり、基本的には’YYYY-MM-DD’（西暦4桁-月2桁-日2桁）というフォーマットで情報を格納します。
平成28年7月15日であれば、「2016-07-15」。
西暦でデータを持っているわけです。
西暦で持っているデータを、和暦で出力するためには、西暦と和暦を変換するプログラムが必要。
その変換プログラムを通すことで、西暦を和暦に変換した日付で出力されます。
もし、新しい元号が加わったとなれば、この変換プログラムに修正が必要です。
主には、新しい元号情報の追加と、平成の終了日の設定といったところでしょうか。
ちなみに、この変換プログラムの場合も、システム内で統一して同じプログラムを使用していれば1か所の改修で済みます。
でも、変換を行う各所で別々のプログラムを使っていたとすると、修正量は大きくなります。
動作確認
新元号にシステムを対応させるプログラム修正が終わったら、次にプログラムがちゃんと期待した動きをするかを確認しなくてはなりません。
例えば・・・
元号の選択肢に新しい元号が追加されているか？
データベース上に新しい元号のデータは正しく登録されるか？
現在の日時に対応した元号が表示されているか？
などなど、システムごとに確認しなくてはいけない項目は様々にあります。
あらかじめ元号変更に対応したシステムになっていれば、確認の範囲は最小限で済みます。
一方で、元号変更によって大幅な改修が必要な場合は、確認範囲も多くなっていきます。
デバッグなども含め、このあたりの作業が一番面倒で苦痛である場合が多いです。
エンジニアは何を恐れている！？
簡単にですが必要となりそうな作業や改修内容を取り上げてみました。
「こんなものなの？」と感じられた方もいると思いますが、実際はいろいろ面倒なんですよ。
もちろん上記は一例であり、システムの作りはそれぞれで異なるので、直面する問題も様々。
元号の変更に派生して、一見すると無関係にも思えるような箇所まで修正を迫られる場合もあり得るでしょう。
ただ、業界外の方に誤解しないでいただきたいのは、「元号変更対応そのものが困難」なわけではないということ。
そもそも、元号の変更自体に対応できないような作りになっているWebシステムは少ないハズなんです。
なぜなら、そもそも明治～平成まで元号は使って実装しているから。
元号の追加修正はまだ行ったことが無いシステムは多いと思いますが、多くは現時点で「明治～平成」をケースごとに切り替えて使うようになっているハズですよね。
そこに１つ新しい元号を追加することは、改修が発生するとはいえ、物理的に難しいことはありません。
では、ネット上のSEやプログラマーは何を恐れているのでしょうか？
簡単に言ってしまえば、「どうなるかわからない」ことです。
元号変更は30年近く変わっていないので、新しい元号の追加をしたことのないシステムは多いです。
元号が変わることは非日常的なことである印象が強いため、開発時にそのことを考慮してシステムを作っていないケースもあるでしょう。
また、考慮していたとしても、その点についての十分な動作確認をしていないかもしれません。
考慮していなかったり、そこまで重要視していなかったことって、後から検討する場合に結構面倒なんです。
絶対的に満たさなければいけない要件は、担当者がしっかり認識していたり、ドキュメントも細かく作られていることが多い。
しかし、あまり意識されていなかったことは情報が不足し、システム内における影響度がはかりづらいのです。
そのため、全体的に見直して影響範囲や修正箇所を洗い出すなんてこともあるのです。
ちなみに、システムの改修作業って依頼主が思っている以上に時間も手間もかかります。
これくらい簡単でしょ？と思われるようなことでも、その改修をするために想像の何倍もの作業量がかかることもあるんです。
「元号変更って意識してなかったから、どのくらいの影響が出て、どれくらいの作業量になるのか読めないなぁ。だから怖いよね。」
それが、元号変更におびえるSE・プログラマーの心情なのではないでしょうか。
システム開発会社の事情
システム改修が必要となる社会の流れというのは、システム開発会社からすれば稼ぎのネタになります。
変な言い方になりますが、今回のケースの場合は元号変更に対応していないシステムを作っておいた方が仕事になるのです。
元号変更は起こり得るもの。
だから、対応できるように作っておくべき。
このようなことを言っておいてなんですが、それをしてしまうと元号変更時に顧客から改修の依頼が来ないわけです。
ケースにもよりますが、「元号の変更時にも使い続けられること」が最初から条件にある案件はそれほど多くありません。
顧客側も「元号が変わった時にちゃんと動くかな？」なんてことを気にしません。
また、元号の変更はいつ起きるかわかりませんし、そうそう起こるものでもないので、優先順位が低いのです。
最初から考慮して実装するにこしたことはないけど、要件に含まれていないからマストではないよね。
必要になった時に、改めてお金貰って改修すればいいんじゃないの？
このようなことは、よくあるのです。
もちろん、該当機能分のお金をいただいているのなら、最初から実装しますよ。
でも、必須で求められていないことについては、別案件として事後対応にすることも珍しくありません。
つまり、必要となった際に仕事を受注するため、あえて対応していない場合も無きにしも非ずなのです。
まぁ、顧客との間にこのあたりの認識のズレがあるとトラブルになることもありえるんですが・・・。
「それくらい、実装しておくのが当然じゃないのか！」ってね。
何にしても、改修時に困ることがないよう、最初からそれを見越した対応しやすい作りにしておくことは重要です。
大きな問題にはならないのでは
筆者が「大騒ぎするレベルのようには感じない」のは、元号変更へのシステム対応はあくまで個別の問題だからです。
元号の変更自体は起こりうることであり、それを考慮して作られているシステムはたくさんあります。
考慮されていなくても、部分的なメンテナンスで解決される場合も多いでしょう。
とんでもない事態になるのは作り方のマズかった一部のシステムのみ。
もちろんそこで、たくさんの作業を抱えて忙しくなる人は出てくるでしょう。
ただ、それはそのシステムだけの問題です。
もちろん、元号変更によって、何かしらの作業が発生する人は少なくないと思います。
しかし、そのほとんどは比較的小規模なものと予想します。
SE・プログラマーの需要が増えるといった話も聞きますが、あまり大きな動きにはならないのではないでしょうか。
ちなみに、「天皇の生前退位」が実現すると、エンジニアサイドとしてはありがたいのではないでしょうか。
天皇が崩御されていきなり元号が変わると、性急な対応に迫られます。
しかし、退位されることが予定されていれば、時期なども事前に発表される可能性が高いでしょう。
そうなれば、システム業界は事前に対応準備ができますから、ある程度混乱は避けられるハズなのです。
また、生前退位が実現するかどうかは別として、今回この話題が持ち上がったことで、今から元号変更時の対応を練ることができますよね。
問題が提起されたのは大きい
今回の「天皇が生前退位の意向」報道によって、元号変更が発生する可能性が注目されたことは大きいと思います。
少し前の消費税アップがあり、そのときにもシステム改修の話題が持ち上がりました。
消費税は今後も変更される可能性がありますから、単に「8％に対応させる」ということだけでなく、「消費税率変更時に柔軟に対応できる」ように改修されたシステムも多いはずです。
数年後に10％になった際に、また改修作業を開発会社に依頼するのは面倒ですからね。
※商品ごとに税率が変わることも検討されているので、そのまま使えるかわかりませんが。
よく起こることは多くの開発者の頭の片隅にあるため、柔軟な対応ができるように作られているもの。
しかし、あまり起きないことは見落としがちですよね。
30年近く平成が続いていたために、元号が変わる可能性について意識から抜けてしまっている人も多かったはず。
今回の報道によって、元号変更の可能性があることを意識した人は多いと思います。
※これまでも元号変更の可能性を認識して開発をされていた方も多いと思います。
今回の報道をきっかけに元号変更を考慮したシステム開発がより意識されるのではないでしょうか。
まぁ、個人的にはなるべく元号を使わずに西暦のみでシステムを作りたいところ何ですけどね。
和暦が使用するとなると特別な処理を組み込むことになりますから、その分工数もかかるんです。
必要性が無ければ、（システム内では）西暦で統一しちゃった方が良いと思います。
ちなみに印象で言えば、元号変更の対応は消費税変更の対応に比べれば軽そうなんですよね。
さて、生前退位報道が出ているとはいえ、どうなるかはわかりません。
明仁天皇には1日でも長く日本の象徴であっていただきたいと思います。
