cc-melonの日記

26歳SEがまじめにブログ書こうとした結果、SEの話題は消えてマタニティブログに。

目に見えるデスマの話。元号変更の可能性とその対応案

昨日、大いにニュースで話題になった、天皇陛下の譲位の可能性について。

 

元号変更といえば、SEにとっては鬼門。

画面インターフェースから帳票インターフェース、コード定義、内部ロジック…etc.

ありとあらゆる元号を使用する箇所に対する修正が発生する可能性があります。

 

かくいう私も、元号大好き機関のシステムにかかわっているので

元号が変更されたら影響をうける派閥です、、、

 

 

この目に見えるデスマに対して、少しでも打つ手を考えてみました。

(ふざけて考えていますので、まじめに読むのはやめてください)

 

 

1 元号の使用箇所の洗い出し

  これはすでにやっている方も多いかもしれません。

  

  すべてのロジックを確認し、元号の追加に伴う影響が発生する箇所を内部ロジック込みで洗い出し、

  修正にかかる工数をあらかじめ顧客に調整しておく方式です。

  

  私も少し前にやったのですが、1つ考え忘れていた点がありました。

  「3文字以上の元号が来たらどうするのか?」

 

  ・・・その場合、さらに工数がかかるので、首をつりかねません。

 

 

2.元号なんて使わない

  これはすでに完成したシステムでは打ちづらい手だとは思いますが

  そもそも西暦があるのになぜ元号なんて使うのか。

 

  お客様が自治体系だから、とか、色のついた銀行だとか

  そういう場合避けて通りづらいのかもしれませんが

  いっそ今回の回収にあわせて元号なんてやめてしまうのも手かもしれません。

  (もちろん、工数は増えます)

 

3.平成ごり押し

  俺の辞書に新元号は存在しない、のパターンです。

 

  元号の追加はせず、平成○○年を続けてもらいます。

  BtoBだったらどうにかなるんじゃないですかね。BtoC?あきらめましょう。

   (ただし、他社IFから元号が送られてくる場合には、これもどうしようもないです)

 

4.海外逃亡

  日本のプロジェクトなんて携わっているからダメなんです。

  いっそ皆で海外に逃亡してやりましょう。

 

 

以上、目に見えるデスマに対する愚痴でした。

どうせ正攻法で対応することになるのでしょうが、、、