えくせるちゅんちゅん

ことりがエクセルをちゅんちゅんするブログ

MENU

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」のイニシャルからも思い出せます。(外国人が和暦使うわけがry)

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

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


ソート順序

先の通りアルファベットを順番に数えていくと、平成の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が開始となった場合は不便になるだろうと予想していました。

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

f:id:Kotori-ChunChun:20190402222001p:plain

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

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」も危険ワードとなりました。

今後はローマ字読みの変数なんて止めて、英語使いましょ。英語。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/143586になるはずですが、例えば次のようなVBA

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

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

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

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

f:id:Kotori-ChunChun:20190402222004p:plain

そして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ではなく、VBAStrings.Replaceを使用してください。

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


まとめ

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

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

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

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


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

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

プライバシーポリシー