ヘッドライン(RSS)

エンジニアに激震 「元号変更か」に「怯える」

1: 名無しさん@おーぷん 2016/07/15(金)09:12:38 ID:qzW
「天皇の生前退位報道」に日本中が騒然とした2016年7月13日の夜。驚き、安心、さまざまな感情が渦巻く中、
最も憂鬱な気持ちになったのはシステムエンジニア(SE)かもしれない。

昭和から平成への改元時はパソコンも一般に普及しておらず、システム上で膨大なデータを構築、管理する習慣はなかった。しかし、
社会のすみずみにシステムが入り込んだ現代で、それは通用しない。仮に改元となった場合、速やかな対応を迫られるであろうSEは
ネット上に「色々とプログラム絡みの事の方で頭いっぱい」「年号変更に怯える」といった不安の声を寄せている。

「プログラム」のことで頭がいっぱい

SEたちの「悲鳴」は、NHKで「生前退位」が報じられた直後から寄せられた。ツイッター上は

「年号変更に怯える」
「SEやプログラマーの仕事増えそう」
「色々とプログラム絡みの事の方で頭いっぱい」
「とてもじゃないけど改修間に合わない」

と阿鼻叫喚の様子だ。

http://www.j-cast.com/2016/07/14272551.html

2: 名無しさん@おーぷん 2016/07/15(金)09:27:37 ID:kLe
いや…予想の範疇でしょ
平成(次の元号)が何年続くんだろうなんてのは昭和後期でも出てた話

3: 名無しさん@おーぷん 2016/07/15(金)09:35:08 ID:e5C
最低でも元号と消費税率は変わるものとして設計してないとダメでしょ
平成みたいに月の途中から切り替わるよりは、生前退位で区切りのいい日から切り替えになる方が対応は楽だと思うけどね

4: 名無しさん@おーぷん 2016/07/15(金)09:51:38 ID:Nhr
>>3
そうでないシステムが山ほどあるんだよ、、、

5: 名無しさん@おーぷん 2016/07/15(金)09:53:39 ID:kLe
ってか一般PCは西暦だよね
元号使ってんのってどこのアホやねん

6: 名無しさん@おーぷん 2016/07/15(金)09:58:47 ID:a5N
つか、これまで通り崩御で元号変更なら
もっと予測が難しいんだが何をオタつくんだろう
むしろ先に予想がつくから歓迎だの言えば良いのに

7: 名無しさん@おーぷん 2016/07/15(金)09:59:51 ID:kLe
あ、銀行とかか
西暦から平成の数値割当てて表示してるだけだけど
追加しないといけないのか

まあしばらく平成のままで良いんじゃね
年明けまでに更新で

8: 名無しさん@おーぷん 2016/07/15(金)11:35:11 ID:ovY
ベースは西暦で表示上元号変換してるでしょ、元号テーブルにぶつけて

9: 名無しさん@おーぷん 2016/07/15(金)11:58:06 ID:e8X
官庁で使ってるPC用のソフト全部アップデートしないといけないじゃない

10: 名無しさん@おーぷん 2016/07/15(金)12:39:47 ID:EnT
西暦と併用してるからシステム変更しない
表示上平成何100年になってもええわ

11: 名無しさん@おーぷん 2016/07/15(金)15:09:11 ID:rpT
>>10
それなら皇紀◯◯年でもいいな.

15: 名無しさん@おーぷん 2016/07/15(金)22:23:10 ID:NQ9
>>11
ぶっちゃけプログラマーからすると元号をやめて皇紀で統一してもらいたい
下一桁が西暦と一緒だから覚えやすいし

12: 名無しさん@おーぷん 2016/07/15(金)15:17:14 ID:rh6
また新しい元号の活字が売り切れて
入荷待ち状態になるのですね・・・
http://i.imgur.com/v39jZy2.jpg

13: 名無しさん@おーぷん 2016/07/15(金)16:40:45 ID:ACV
スマホゲとかは即対応できそうだが、
銀行はヤバそうだなぁ・・・旧世代からの遺物の蓄積だし
チベットのポタラ宮って知ってる? 昔の上にずっと建てまししてる建造物
アレと一緒。

14: 名無しさん@おーぷん 2016/07/15(金)16:55:56 ID:EnT
>>13
みずほ銀のシステム統合が更に遠のくw
ジャンケンで勝ったシステムでゼロから作り直す方が早くて安いのにね

21: 名無しさん@おーぷん 2016/07/16(土)01:34:56 ID:dQX
>>13
銀行の方が、逆に昭和64年→平成元年の時代も既に電算化してたから経験あって大丈夫だろ
西暦しか使ってないシステムなら問題ないけど、
ユーザーの誕生日を明治・大正・昭和・平成を選ぶようになってるシステムとか(最近は明治がなかったり、西暦19、西暦20が書かれてる登録用紙も増えてきてるが)、
年号表示で文書作成している明細書とかはやばそう

あと、㍻の次はどこに割り当てるんだろ

23: 名無しさん@おーぷん 2016/07/16(土)10:24:12 ID:aeC
>>21
元号を文字コードに割り当ててたのか
アホすぎる

16: 名無しさん@おーぷん 2016/07/15(金)23:17:35 ID:Nfn
言語ベースやライブラリベースで元号をサポートしている物ってあるのかな

17: 名無しさん@おーぷん 2016/07/15(金)23:21:52 ID:Nfn
.NETフレームワークはそういうクラスがあるらしい
JapaneseCalendar クラス
https://msdn.microsoft.com/ja-jp/library/system.globalization.japanesecalendar(v=vs.110).aspx
Calendarクラス Calendar.Eras プロパティ
https://msdn.microsoft.com/ja-jp/library/system.globalization.calendar.eras(v=vs.110).aspx
Javaあたりもそういう機構あるのかな

18: 名無しさん@おーぷん 2016/07/15(金)23:28:14 ID:Nfn
Class JapaneseChronology
https://docs.oracle.com/javase/8/docs/api/java/time/chrono/JapaneseChronology.html
ググると文句垂れてるブログもあるようだけど、これらのクラスを使っておけば勝手に切り替わってくれるのかな
VMのバージョン上げたくないとかまた別の葛藤がありそうだけど

19: 名無しさん@おーぷん 2016/07/15(金)23:46:36 ID:T96
ぶっちゃけ間に合わないわけが無いんだよなぁ

20: 名無しさん@おーぷん 2016/07/16(土)01:33:56 ID:QOw
不意打ちでくるよりいいやろ

22: 名無しさん@おーぷん 2016/07/16(土)07:46:32 ID:n61
内部で和暦のまま処理してるシステムなんてないでしょ
表示や印字、範囲チェックと和暦西暦変換ロジックいじるだけですみそうなもんだけどな
その辺が関数化されてないのは論外

新元号が3文字なるとレイアウト変更とか大変かもしれんけど

24: 名無しさん@おーぷん 2016/07/18(月)19:10:27 ID:8rk
エクセルのgeeeはどう対応するんや?

シェアする

  • このエントリーをはてなブックマークに追加

フォローする