12月1日の皇室会議にて、譲位の日程は平成31年（2019年）4月30日と決定した。これにより、改元日は5月1日となった。
ゴールデンウィークが10連休化するのではないか？ との憶測も飛び交い、歓迎ムードが漂っている感がある。
同時に全国のIT企業における「新元号対応」の対応期限も決定した。ゴールデンウィーク10連休化の喜びの声も聞こえる中、微妙な表情をしている人がいたら、もしかしたらその人はシステムエンジニアという、なんとも因果な職業についた人なのかもしれない。
自分も金融系のシステムエンジニアをやっているため、大変微妙な表情をしている。そもそも事前に対応の準備ができる事自体大変良いことだし、迷惑なのではなく、むしろ業務としてはとても良い日程なのだが、それでもやはり5月1日は微妙なのだ。
改元と情報システム周りへの影響
日本国は元号を公式な年号として使用している、世界でただ1つの国である。言うまでもなく、公的な書類に元号が使われている場合がある。役所など公共機関の物や、金融関係の物には特に多い。
そして、そうした書類の出力やそれに関連する業務で、現代においては当然ながらコンピュータシステムを使用している。
つまり、元号が変わると、コンピュータシステムの元号に関わる部分に、様々な対応が必要になるのだ。
三菱東京ＵＦＪ銀行は、口座などの契約書類に印刷されている「平成」の元号を新元号に作り直す。国内の取引履歴などを参照するシステムで和暦が使われているケースが多く、元号を更新する必要がある。
総務省はマイナンバーカードに改元の影響が出るかシステムを確認中だ。生年月日のデータに元号を使用しているためで「新たな元号で生まれた人のデータを追加する際にシステム改修が必要なのか、設定変更で済むのかを洗い出している」（住民制度課）という。
システム会社は楽観的だ。富士通は「システムの基盤は西暦で動作しているため大きな変更はない。和暦を使っていても改修作業は一晩で終わる」とみる。
富士通の楽観は何を根拠にしているのかよく分からない。まあ一晩で終わるというか、一晩で終えなければならない作業が多いわけだが、そんなにアッサリした対応で終わるはずはない。
もちろん、先帝陛下がお隠れになることで生じた30年前の改元と比べて、今回の改元は影響範囲の見極めや対応方針の検討に時間を費やせるので、その点では都合が良い。だが、30年前の改元の時とくらべて、日本のシステムの数は膨大なものになったし、複雑さも比べられないレベルのものになったのだ。
簡単には把握できない影響範囲
何しろシステムの作りにもよるが、古くからある金融系のシステムは、膨大な数のシステムとシステムを組み合わせて作っている場合が多い。
自分の勤めている会社は某カード会社のシステムを構築・保守・運用しているのだが、システム全体の構成としては、メインフレームの基幹システムを中心に、周辺にオープン系サーバのシステムが何十個も接続している構成なのだ。*1
それらが複雑に連動しあって、システム全体を構成していたりするのである。よそのシステムをそんなに知っているわけではないが、うちだけがそんな構成というわけではないだろう。
上の絵がざっくりとしたクレジットカードのシステムの構成だが、構成は会社によって大きく異る。
「メインセンタ」の囲みがカード会社のシステム全体で、「業務系システム」と書いているところは基本的に一個の「メインフレーム」の上に複数の乗っかっている「基幹システム」で、その周りはシステムごとに何個かの「オープン系のサーバ」で構成している「周辺システム」と解釈してほしい。「何十個も接続している」と書いたのはこの「周辺システム」の方だ。
「周辺システム」は、「基幹システム」の情報を参照・更新する画面を提供する為にも存在していたりする。メインフレームは滅多に壊れることなく大変堅牢なのが素晴らしいので、会社の根幹に関わるデータを管理したり処理したりする基幹システムに採用されることが多い。だが、色々あって画面のインターフェースが下記のようにしょぼく、使いにくいことが多いのと、細かなシステムの改変が簡単にできなかったりするので、オープン系の「周辺システム」を挟んで利用していたりするのだ。*2
で、これらのシステムの一つ一つに大体データベースが存在し、データベースには何十～何百個も表の形でデータが格納されていて、その中に日付の入ったデータが色んな所に存在する。また、これらのシステム一つ一つの中に、西暦と元号を変換する仕組みが存在する。
また、これらのシステム同士が何十～何百種類ものファイルやら電文やらで連携を取りながら密接に連携していて、その中に日付の入ったデータが色んな所に存在する。
そんなこんなで、元号が変わる場合、システム全体の影響の可能性がある箇所はもう何千箇所もあったりして、その影響範囲の洗い出しがエライ大変だったりするのである。
他所の会社では、もう最初の譲位報道のあとに影響調査やらやって、やることを決めていたりするのか知らないが、少なくともうちの会社には、この間ようやくお客さんから対応の見積依頼が来た。
つまりこれから影響範囲を調べて、やることを決めなければならないのである。やれやれ。
これから見積もりに何ヶ月かかかり、対応とテストにも1年位はかかるだろう。つまり、今日の改元日の発表くらいが普通の負荷で乗り切れる、ギリギリちょうどのタイミングなのである。
どんな事をする必要があるのか？
影響範囲は当然システムの作りやデータの持ち方によっても異なるが、ざっと下記のことは考えなければならない。
和暦変換テーブルへのパッチ当て
どの情報システムも基本的にデータは西暦の形で持っている。そのため、データベース上に西暦何年何月何日を和暦の切れ目か判定するテーブルを持っていれば、そこを参照して元号を設定できる。ここに新しい元号のデータを差し込んでやりさえすれば、簡単に切り替えられる。
どのシステムもこういう仕組みを採用していればいいのだが、現実的にはそうではなかったりする。
和暦変換プログラム改修
システムの作りによっては、プログラムの中に元号の切れ目が直接埋め込まれていたりする場合がある。そんな場合は、プログラム自体に手を入れてやる必要がある。基本的にこんな作りをするべきではないのだが、納期の問題とか、お金の問題とか、元々のシステムの作りがクソだったりとか、大人には大人の事情があるんだよ！！
元々平成までの和暦には対応した作りになっているので、その仕組にあとから新しい元号の仕組みを追加してやるだけなので、大した改修にはならないのだが、テーブルへのパッチ当てに比べて面倒ではある。
ワークテーブル・ワークファイルへのパッチ当て
多分これがすごく大変。さっき上で「これらのシステム同士が何十～何百種類ものファイルやら電文やらで連携を取りながら密接に連携していて」と書いていたが、その中に日付の項目があったりするが、その中には元号が直接記載して埋め込まれてしまっている箇所なんかがあったりする。
何でそんな事になっていたりするかというと、これも色々考えられるのだが、ありがちなのが印刷用のデータに印刷する文字がそのまま埋め込まれている場合だ。
例えば帳票の印刷がクソ安直な作りになっているシステムだと、印刷用のデータは印刷用のレイアウトそのままに文字が打ち込まれているただのテキストファイルになっていて、そこに予め罫線など基本的なレイアウトがされた紙をプリンタに差し込んで、印刷するときはただテキストを印刷するだけだったりする。
これ、作りとしては直感的で分かりやすかったりするが、印刷データが出てしまったら最後、元号がそのまま書かれているので、ファイルの一個一個に対して直接文字を書き換えてやらなければならない。
そんな対象を、何千ファイルもの中からの何十個を見つけ出して、いい感じに修正を加えてやらなければならない。もちろん1ファイルの中には何万レコードもデータが入っていたりするので、自動的に修正する方法を考えなければならないし、そのためのテストも必要だ。*3
もちろん、こういうファイルができる前にデータベースやプログラムを改修してやれば良いのだが、データの締めのタイミングとか、ユーザーの都合を優先する……というか調整が面倒臭いみたいな理由でクソ客が言う事聞かなかったりとか、色々あって出来なかったりするんだよ！ クソが！！*4
各システム間の連携テスト
情報システムは、基本的に何らかの対応をした場合、必ずテストを実施しなければならない。情報システムにおけるテストとは、開発用のシステム環境にデータを入れてやり、実際に動かしてみてその動きを確認することだ。
年月日が関係するデータは当然ながら多数に及ぶのと、年月日のデータは複数のシステム間で行き来していたりするので、各システム間の連携テストが必要になる。
場合によっては他所の会社との連携が必要になるので、テスト日程やテスト内容の調整何かがあれこれ発生し、管理が大変になったりする。
関連する全システムをすべて接続した試験を実施するとなると、関係先の数が膨大になる。上にも書いたとおり、同じシステム内でも基幹システムと連携し合うシステムが何十個もあり、更に会社の外にも連携先のシステムが有り、その連携先のシステム内にも何十個も連携システムが有り……と、情報システムの曼荼羅は果てしなく続いていて、しかもその数や複雑さは前の改元の時より遥かに大きくなっているので、連携テストは色々大変だったりするのである。
リリース後の立会
データベースのパッチ当てなり、プログラム対応なり、ワークデータへのパッチ当てなり、情報システムに何かの変更を加えた場合、基本的に変更箇所が実際に正しく動いていることを確認するために、改修部分のアウトプットの実物を最終チェックする必要がある。
また、チェックした結果、おかしい箇所が一つでもあったらシステム障害なので、会社の上司やクソ客への報告のほか、アウトプットに対するパッチ当て、障害原因の究明、障害対応、障害対応箇所のテスト、障害対応箇所のリリースが必要になる。
これらのことをやるためには当然予め出社をし、スタンバっていなければならない。
これまで色々やらなきゃいけないことを書いたが、「5月1日は微妙」と書いた一番の理由がこれ。10連休のさなか、システムエンジニアは皇室関連の特番を見ることもなく、出社しなければならないのである（涙）
スタンバイの体制は、各社とも壮大なものになるだろう。「移行本部」などと銘打ち、担当部署のフロアの一番でかい会議室を貸し切り、そこに各システムの担当リーダーや課長クラス、報告を待ち受ける部門のお偉方がずらりと並び、クソ客のシステム部の会議室ともテレビ電話なんかで常時繋ぎ、緊張したやり取りがずっと続くことになるだろう。*5
流石に「移行本部」に来ることはないだろうが、不測の事態に備えて社長も待機していたりするはずだ。何しろこの日は、全社の全システムが同日に元号対応を実施するのだ。あちこちから障害報告が上がってきてもおかしくない。
「10連休のさなかに」とネガティブなことを書いたが、ポジティブな側面もある。長期休暇の真ん中に改元が来ることで、システムの利用部門が休みに入っているので、最悪何らかの障害が発生した場合でも、影響を最小限に食い止めることができる。また、ユーザー業務に制限を掛ける必要も少ないので、移行作業そのものも制約の少ない中でやれるという利点がある。
冒頭に「むしろ業務としてはとても良い日程」と書いたのはそういうことだ。
実際、改元以外でも、大規模なシステム更改や統合案件などの移行は、正月休みなど、長期連休の中で行うことが多い。また、5月1日は年末締めや期締めとも重複せず、システム的な意味での特殊イベントが少ないため、影響が見極めやすい。そういう意味では、今回の改元の日程はなかなかナイスな日程なのである。安倍ちゃん、やるじゃない。
新元号へのシステムエンジニアの心配事
新元号についての心配事は他にも色々ある。
例えば、「元号のイニシャルが、M、T、S、Hや、明、大、昭、平と被らないよな？」とか、「過去には『天平宝字』とか、4文字の元号が存在したけど、今回も2文字ってことでいいよな？」とか、元号のUnicodeの枠もう空いてないんだけど（空いてるは空いてるけど、お隣にない）、新元号はどうするんだろう、とか。
まあ、流石にイニシャル被りや4文字はないよな。政府も流石にそれくらいは意識して対応するはず……。
改元という国家的なイベントに仕事で関われるということ
ネガティブなことばかり多く書いてしまったので、最後に少しはポジティブなことを。
我々システムエンジニアの多くは、改元に関わる皇室行事を見たり、皇室特番を見たりすることはできないだろう。だが、我々は改元というその状況を消費する側ではなく、作り出す側になることができる、数少ない職業の一つである。
譲位や即位のイベントに、警察や宮内庁の方々は、当日大わらわで、時代の切り替わりに思いを致す暇など到底ないだろうが、だからといってそのことに愚痴をこぼすだろうか？ 多分、多くの人はそんなことはないと思う。この歴史的なイベントに観客としてではなく、主体的に関わりを持てるということを、誇りに思っている人も多いだろう。
システムエンジニアも、上記の公職の方々と土俵は違えど、同じイベントの中で、観客としてではなくイベントを切り盛りするメンバーとして、間違いなく日本の土台を支える事になるのだ。そのことに思いを致しながら、障害0で、この「新元号対応」を乗り切りろう。改元について、そのように思った次第である。
*1:「メインフレームとは？ オープン系サーバとは？」ということを事細かに書くと、それだけでもすごい量の文章になるので省略する。ざっくりいうと、メインフレームは巨大なコンピュータで、超高価だが稼働の安定性と処理の高速性がダントツで高い。オープン系サーバはメインフレームより安価だが安定性と高速性では劣る。
*2:メインフレームの画面のこと、「黒画面」なんて言い方したりしますね。
*3:下手すると数GBの固定長のテキストファイルを、HULFTとか使ってシステム間でやり取りしてたりするからね。秀丸とかで開こうとしても開けないよ！w
*4:俺に書類の束を投げつけたことがある某クソ客の口癖は「XX部長にご説明できると思っているのか！」だった。今はもう関わり合いがなくなったが、こいつの家が燃えたら赤飯を炊いてお祝いをする予定である。
*5:もちろん担当リーダーは本番端末室と会議室を行ったり来たり。
