VBAer的視点で新元号「令和」について真剣に考えてみた

今回はVBAer的視点で新元号【令和】について考えてみました。

---

新年度おめでとうございます。

みなさん、新年度あけましておめでとうございます。

さて、新元号【令和】発表されましたね！

私としては美しい響きで良いんじゃないかと思ってます。

政府やニュースメディアから【令和】の由来や、記念品が爆売れやら、同名の漢字の人がいるやら、令和ちゃんを擬人化してみたやら、令和18年生まれはR18でかわいそうだ、さらには令和の018をひっくり返すと810=野獣だ。等と大変盛り上がっているようですが、

そんなことはどうでもよろしい！！！

私は実務的な側面で新元号について収集したまとめをここに残したいと思います。

それとExcelの数式による令和の表示の対応については、有名な情報サイトが解説してくれると思うので、

そんな普通のことを私は書きません！！

お手数かけますが、令和　excelググってくださいな。

令和に関する実用的な情報

すでにTwitter他メディアでも記事になっているためご存知の方が多いとは思いますが、私が収集した令和に関する実用的な情報はこんな感じです。

• 令和＝れいわ＝Reiwa＝018＝イニシャルはR
• Rはアルファベットの18番目である。
• 西暦=令和+2018
• 令和=西暦-2018

令和のすばらしいところ

年号変換

まず令和に限った話ではありませんが、改元によって西暦と和暦の変換の際に、平成では31-12+2000=2019みたいな面倒な計算をしていたところが、新元号では西暦の繰り上がりが無いため簡単になりました。

西暦	令和	令和→西暦
2019	令和元年	1+18+2000=2019
2020	令和02年	2+18+2000=2020
2021	令和03年	3+18+2000=2021
2022	令和04年	4+18+2000=2022
2023	令和05年	5+18+2000=2023
2024	令和06年	6+18+2000=2024
2025	令和07年	7+18+2000=2025
2026	令和08年	8+18+2000=2026
2027	令和09年	9+18+2000=2027
2028	令和10年	10+18+2000=2028

そして変換に必要な定数「18」という数字は、「れいわ」という名前からも、外国人が「Reiwa」のイニシャルからも思い出せます。（外国人が和暦使うわけがｒｙ）

どう考えても令和ほど実用的な元号は他に思いつかないでしょう。

まさに十八番と呼ぶべき元号です。これ考えたやつ天才だろっ（笑）

ソート順序

先の通りアルファベットを順番に数えていくと、平成のHは8番目、令和のRは18番目です。

A	B	C	D	E	F	G	H	I	J
1	2	3	4	5	6	7	8	9	10

K	L	M	N	O	P	Q	R	S	T
11	12	13	14	15	16	17	18	19	20

U	V	W	X	Y	Z
21	22	23	24	25	26

つまり、和暦年号を文字列で管理しているような場合に、単純にソートをすればH→Rの順に並ぶということになります。

特にソートアルゴリズムに手を加えることが出来ないファイル名などにおいては、仮にA～Gが開始となった場合は不便になるだろうと予想していました。

これは一部の和暦を使う人にとっては地味に助かります。（え？そんなの意識してないって？）

まあ昭和以前も混ざると崩壊するんですけどね。

No	記号	元号	順位
4	H	平成	8
1	M	明治	13
5	R	令和	18
3	S	昭和	19
2	T	大正	20

またこのルールで行くと、STUVWXYZしか残らないので、次の元号では破綻する可能性は極めて高いでしょう。

ですから、それまでに和暦でデータ管理するのは止めましょう。

注意しなければならないこと

一方で、和暦を使う極々僅かな人には注意すべきことがあります。

変数名・関数名

以前(たぶんTwitterにて)「R」という単一文字変数はExcelVBAにおいて危険ワードなので止めましょうと警告しましたが、新たにReiwaが加わることでより一層危険度が増したと言えます。

• セル　Range
• 行　　Row
• 令和　Reiwa

さらに従来は問題ではなかった「例＝Rei」も危険ワードとなりました。

• 例　　Rei
• 令和　Rei

今後はローマ字読みの変数なんて止めて、英語使いましょ。英語。Sampleね。

コードとしての使用

システムの管理番号に次のように令和を振り直すと次のような問題が起こる可能性があります。

問題となりうるのは主にCSVデータをExcelで開いた時、Excelでセルの書式設定を文字列に変更せずに入力した時だと思います。

これが

コード	Val1	Val2	Val3
010001	あ	か	さ
010002	い	き	し
010003	う	く	す
・・・
020001	ああ	かか	ささ
020002	いい	きき	しし

こうなったり

コード	Left(コード,2)
10001	10
10002	10
10003	10
・・・
20001	20
20002	20

今まで問題なかったこれが

コード	Val1	Val2	Val3
30-01	あ	か	さ
30-02	い	き	し
30-03	う	く	す
・・・
31-01	ああ	かか	ささ
31-02	いい	きき	しし

こうなると

コード	Val1	Val2	Val3
01-01	あ	か	さ
01-02	い	き	し
01-03	う	く	す
・・・
02-01	ああ	かか	ささ
02-02	いい	きき	しし

こうなるかもしれません。

コード	Left(コード,2)
43466	43
43467	43
43468	43
・・・	・・
43497	43
43498	43

管理コードを令和で振り直すなんてことをするアホな企業は弊社だけだと思いますが、今後日常的に日付データを1-1などと入力する一般の方はいると思いますので注意したほうが良いかもしれません。

せめて先頭にアルファベットH、Rを付けてくれればこんな問題は起こらないのですが・・。

Excel上での和暦の置換えにおける注意

これもマイナーだとは思いますが、私の管理しているエクセルでは和暦年号を文字列で記憶させている場合があります。

例えば、（標準の）「平成31年5月1日」※文字列　とか「'平成31年5月1日」とかね。

前者は普通に入力したらシリアル値となるため、2019/5/1や43586になるはずですが、例えば次のようなVBA

selection.value = "平成31年5月1日"

を実行した場合は話は別で、セルの書式設定が標準になっていても文字列として入力が可能です。

そして、こういった帳票を出力している大元のプログラムは（既成のexeだったりして）手を加えられないことが多く、手動で置換してあげなければならない場面があります。

そこで多くの人は次のように置換するのではないかと予想します。

そしてVBAのサワリだけ齧った人はこうするでしょう。　（※マクロの記録そのままの状態）

    Cells.Replace What:="平成31", Replacement:="令和01", LookAt:=xlPart, _
        SearchOrder:=xlByRows, MatchCase:=False, SearchFormat:=False, _
        ReplaceFormat:=False

しかし、Excelの置換はセルの書式設定を考慮しないため、セルの書式設定が「標準」であろうが「文字列」であろうがお構いなしに全てシリアル値に変換されます。

ところが、執筆時（2019/4/2）現在はMicrosoftのアップデートが適用されていないため、「令和01年5月1日」や「令和元年5月1日」と入力してもシリアル値に変換されません。

つまり、現在急いで和暦置換プログラムを書いている人に忠告です。

今は正常に動くプログラムでも、近い将来、動かなくなります。

必ずCells.Replaceではなく、VBAのStrings.Replaceを使用してください。

そのためにはマクロの記録ではなく、自力でのコーディングが求められます。これを機にちょっと頑張ってみてください。

まとめ

以上が私の収集した令和に関する情報です。

とりあえず、日本人の皆さん、和暦使うのはもう止めよ・・・？

私はこの先10年は、和暦からは離れられそうにないですが。

以上、ここまで読んでいただいてありがとうございました。

---

何か御座いましたらコメント欄、またはTwitterからどうぞ♪

それではまた来週♪　ちゅんちゅん(・8・)