ゆるゆるメモ

日ごろ感じたことや学んだことをゆるゆると書いていく日記です。

とある並行世界の元号対応奮闘記

「新しい元号は、レイワであります。」

官房長官がそう発言するのを、テレビを囲ったたくさんのチームメンバーが見つめていた。

私たちは帳票を扱うシステムの保守開発チームだ。お客様のシステムで出力する帳票には和暦を用いた日時表記がある。そのため、この数ヶ月をかけて、新元号に対応するためのシステム改修を行ってきた。和暦変換の処理は、システム内で直接処理しているもの、帳票ツールの処理を使ったものなど、帳票によって別れていた。改修はそれなりに大変だったが、なんとか3月中にテストを終え、いくつかの設定ファイルを発表された新元号に変更するだけで良い、という状態だった。

「え、今なんて言った?」

「エイワ?とかそんな感じ?」

「頼むから簡単な漢字であってくれ…!」

次の瞬間、官房長官は伏せていた額縁を上に揚げた。

*1

これを見たチームメンバーは安堵の表情を浮かべた。

「命令の令に、平和の和だって」

「あー、レイワ、ね。」

「よかった、小学校でも習う簡単な漢字だ。」

元々、どんな新元号になるのか、というのは世間で度々話題になっていた。様々な予測が飛び交う中、「漢字二文字である」「書きやすく、読みやすいもの」「イニシャルがMTSHではない」など、条件もありそうだ、という噂もされていた。

ただ、これらはあくまで噂に過ぎなかった。当日になっていきなり3文字の元号が発表されたら、日付を固定長で確保しているDBの改修が必要になる。難しい漢字が使われていたら、SHIFT_JISでの処理を捨てきれていない一部のモジュールで扱えないかもしれない。そんな不安を抱えていた。(想定外の文字に対応するところまでは、流石にコストパフォーマンスが悪いということで見送っていた)

だから、「令和」という2文字かつ簡単な文字の組み合わせで構成されている新元号を見て、みんなホッとしたのである。

官房長官の発表会見を見終わったチームメンバーは、それぞれ自席に戻り、各々に割り振られていた新元号の対応作業を始めた。 新元号の設定ファイルを発行し、それぞれのサーバーに配置。午後からテストに入る予定だ。

作業は順調に進み、午後から新元号対応部分のテストが始まった。

テストを初めて数時間後のことだった。

「なんかちょっと違うよなぁ?」

そう声を上げたのは新人のSくんだった。心配になった私は、Sくんに話を聞いてみた。

「発表された『レイ』の文字と、帳票に印字されてる『令』の字形が違うんすよね。これ大丈夫ですかね?」

Sくんの主張は正しかった。昼に発表された「レイ」の字は、下の部分が「点+マ」になっていたが、帳票上には「横棒+アみたいなやつ」の形の「令」が印字されている。

Sくんには、とりあえず文字の違いは一旦無視してテストを続けるように伝え、私は2つの文字の違いについて調べることにした。

調べたところ、2つの文字は単に書体が違うだけであって、基本的には同じ漢字らしい。*2

「同じ漢字なのであれば、まぁ、大丈夫だろう」と思い、少し安心した。念のため、上司に報告することにした。上司からは次の答えが返ってきた。

「一応、発表どおりの文字で表示できないか、調べてもらえるかな?」

面倒なことになった。このテストさえ終われば元号対応は無事終了となるのに、書体の違う文字が表示できるかどうかの調査とは。しかし、文句ばかり言っていても仕方ない。調べよう。

調査には数日を要した。何ぶん知見のない分野だったため、思っていたよりも時間がかかってしまった。

「令」の書体を変えて見せる方法はどうやら以下の3通りの方法がありそうだという結論に至った。

  1. フォントを変える
  2. 外字を利用する
  3. 異体字セレクタを使用する

1は、使用しているフォントを変更するというもの。フォントの中には「点+マ」の令の字を表示してくれるものがあり、そのフォントに切り替えれば表示も変わる。 他の令の字も変わってしまうのが懸念ではあるが、フォントを変える対応だけで済むため、他の2つよりも工数が少なくて済みそうだ。だが、「点+マ」の形式で出力できるフォントのライセンスについては別途調査が必要だ。

2は、外字として令の字を登録し、それを帳票に埋め込むというもの。方法として存在することは理解したが、クライアントでの表示がどこまで担保できるのかが怪しい上に、検索性も落ちるのであまり得策ではない。

3は、異体字セレクタと呼ばれる情報を付与することで文字の見た目を変更できるというもの。対応しているフォントは多くないが、1つのフォントで両方の「令」を表現できる。一応、「IPAmj明朝」というフォントが対応しているらしい。 しかし、この異体字セレクタが鬼門で、「令」の後にUnicodeの「U+E0102」に該当するコードの文字を出力する必要がある。「U+E0102」はサロゲートペアとかいう技術を使う必要があるらしく(?)正直良くわかんなくなってきたので一旦ここで調査をやめた。

私は、これらを踏まえた上で、やはりここは対応無しとしたいことを上司に告げた。上司は納得し、事なきを得た。

2週間後、政府から発表があった。「新元号名で使用する文字コードについて(周知)」と題された文書が公表されたのだ。*3

資料には以下の記載があった。

元号で使用される文字である「令」及び「和」に対応する文字コードは、以下の通りと考えられます。
JIS X 020846区 65点4E61(JIS)97DF(シフト JIS)
JIS X 021346区 65点4E61(JIS)97DF(シフト JIS)
ISO/IEC 10646U+4EE4
(中略)新元号で使用する文字を情報システムで扱う際には、上記の文字コードを用いることが推奨されます。

勝った、と思った。政府発表の中で「令」の文字コードが明示されたのだ。設定ファイルに記載した文字コードとも合致している。

こちらの資料も、念のため上司に報告した。上司はこう言った。

「この下の説明は読んだ?」

下の説明?最初は何を言っているのかわからなかった。よく見てみると資料の下部に以下の説明が書いてあった。

「令」の文字に関しては、上記の文字コードのほかに、Unicode において、U+4EE4 に続けてU+E0102 の文字コードを使用することで、元号発表時の令󠄂󠄂󠄂󠄂の文字を表現できます。フォントにも依存しますが、こちらの表現が相応しい場合にはこちらの文字コードを使用することも推奨されます。*4

不覚だった、読んでいなかった。

「どう…しましょうか?」

「まぁ今回の場合はいいんじゃないか?E+U0102 無しの表現に関しても推奨されているわけだし。お客さんに説明してみるよ。」

数日後、上司が顧客に事情を説明した。説明用の資料は私が作成し、打ち合わせにも同席した。顧客には内容を了承いただき、この問題は今度こそ収束した。

私の場合は上司や顧客に理解がある職場だったから良かったものの、この問題に苦しんだSEは、少なからずいるのではないだろうか。その人たちはきっとあの額縁の文字を書いた人を恨んでいるんだろうなぁ。

※この物語はフィクションです。登場する人物・団体・名称等は架空であり、実在のものとは関係ありません。

*1:しょぼい字ですんません

*2:みなさんは学校でどちらの漢字で教わりましたか?私は「点+マ」でした。

*3:現実世界の資料はこちらhttps://www.meti.go.jp/policy/it_policy/kaigen/20190405_kaigen_code.pdf

*4:この記載は現実の資料にはありません