【話題】元号変更で「2019年問題」は起こるのか?

1: 2017/11/28(火) 16:16:51.79 ID:CAP_USER9

https://headlines.yahoo.co.jp/hl?a=20171128-00000059-zdn_ep-sci
報道によると、平成の時代は2019年4月30日で幕を閉じ、5月1日から新元号が施行されることに決まったようです。

 「5月1日が祝日になれば、まさかの10連休」という話が盛り上がる中、IT関係者の間では、「2000年問題の悪夢」を思い出した人も少なくないようです。

●2000年、システムに何が起こったのか

 2000年問題とは、1999年から2000年になった時に、それまで稼働していたプログラムが2000年を認識できずにさまざまなトラブルを起こすというもの。「なぜ、そんなことで問題がおきるの?」と思うかもしれませんが、当時のプログラミングテクニックでは、メモリを節約するために西暦の下2桁しか記録していないケースも多く、1999年から2000年になった瞬間にシステム側が「1900年」と認識してしまうことも多かったのです。

 こうした事態を防ぐために、多くのエンジニアが2000年問題の対処に動員されたのです。当時、エンジニアだった私は、停電やテレビの放送が止まるくらいのことは覚悟していたのですが、結果として大きな問題はほぼ起きなかったように記憶しています。

 もう18年近くも前の話ですが、当時、大変な思いをしたエンジニアは、今回の元号変更の発表を聞いて対処の大変さが頭をよぎったはずです。2000年問題ほどではないにせよ、帳票の出力を調整する作業量に思いを巡らせたり、待機を考えたりしたのではないでしょうか。個人的には2019年が平成と新元号を両方持つ特別な年になるため、範囲指定の処理が複雑になるのではないかと思っています。

 10連休などは夢のまた夢――。そんなエンジニアの皆さんには感謝しかありません。

 2000年問題はシステムの根幹部分にあり、さまざまな影響があると予想できたことから大きな問題になったわけですが、今回の元号変更に伴う影響はそれに比べると軽微なものになりそうです。

 なぜなら、今、稼働しているシステムは西暦をベースにしたものが大半でしょうし、元号を使っていたとしても変更を想定しているものがほとんどです。

 実際、私が担当していた海外製の会計パッケージソフトでも、元号設定どころか、消費税の税率期間設定を含む各国の特殊な事例を吸収するための設定項目が網羅されていて、しっかりと対応できていました。

 「新元号問題」はシステムが止まるような大きな問題ではなく、個人的には帳票の出力がおかしくなるといった小さな問題にとどまるのではないかと考えています。

●元号変更に伴う脅威とは

 しかし、元号の変更には、もう1つ大きな問題があります。それは「元号変更を使った詐欺」です。

 2000年問題の際にも、「2000年を境に電話やFAXが使えなくなるから買い換えよう」という、関係者を装ったセールスが行われたという話がありました。そういった悪質商法は、当時は訪問販売や電話が主な手段でしたが、今ではメールやフィッシングサイトを通じて行われる可能性があります。

 例えば、Webサイトを見ていると突然ポップアップ画面が表示され、「あなたのスマートフォンは新元号に対応できません。アップデートするにはここをクリック!」という表示が出る――といった手口が予想されます。

 さらに、金融機関をかたる差出人から「元号に対応する銀行口座に変えるにはここからログインを!」というようなメールが来るかもしれません。ほかにも、「クレジットカードが新元号に対応していません」「パスワードが新元号に対応していません」……など、あの手この手でアプローチしてくるでしょう。

 今のシステムでは、利用者側が新元号に対応するために行うべきことは、ほぼないと思っていいでしょう。もし、「元号が変わるのに伴う対処が必要」という指示が来たら、まずフィッシング詐欺をうたがってください。

 真偽の確認は、メールやポップアップで表示されたURLやボタンをクリックするのではなく、自分で当該サービスのURLをWebブラウザに入力し、トップページにそのような指示があるかどうかを確認してください。

 こうした対応は、この記事を読んでいる皆さんにとっては当たり前かもしれませんが、あなたの「家族」は知らないかもしれません。この暮れに帰省する人はぜひ、この記事の内容を説明して注意を喚起してください。オレオレ詐欺ならぬ「元号変わる詐欺」にだまされる人が一人でも減ることを祈っています。

3: 2017/11/28(火) 16:17:15.91 ID:vuLx07UB0
何も起こらない。うちは西暦しか使わないから。

 

4: 2017/11/28(火) 16:18:09.76 ID:ZQwdLPig0
表示がバグるだけでデータがおかしくなるとかはないよ

 

5: 2017/11/28(火) 16:18:54.61 ID:URTNg05s0
馬鹿しか懸念を持たない

 

9: 2017/11/28(火) 16:19:09.96 ID:TMtoBBbV0
>>5
手形、小切手、は元号以外は使えないんだぜ

 

15: 2017/11/28(火) 16:21:39.74 ID:rdN7NkpW0
>>5
一般人は西暦使用だけど役所関係はほぼ元号だから他人事じゃないんだよ。

 

16: 2017/11/28(火) 16:21:41.71 ID:Ns2KlW650
>>9
お役所、郵便局関係は元号だよね
書類書くたびに会社にある新聞の日付見ていたわ

 

35: 2017/11/28(火) 16:32:59.48 ID:URTNg05s0
>>9,15,16
そう言やそうだな
あれかな?日本人なのに西暦を使うなんて!とか変なプライドから西暦使わないのかな?
だったら皇紀使えばこんな問題起きないんじゃないの?

 

47: 2017/11/28(火) 16:39:35.18 ID:kTl6a0pt0

>>15
知ったことか

クソ役人どもが勝手に苦しめばいいだけ

 

50: 2017/11/28(火) 16:41:35.99 ID:FGTM197P0
>>15
西暦でもOKって法改正すりゃ済むだけなんだけどな。

 

52: 2017/11/28(火) 16:42:14.20 ID:Mcg1t0K/0
>>50
そうなんよ。めんどくさい。

 

74: 2017/11/28(火) 16:57:19.82 ID:d78FkNZn0
>>50
法改正で元号変更の際にそうなるやろ、外人は知らんしな
国際化&ネット社会で、元号表記は終了でええな
まあこれも時代の流れだ

 

6: 2017/11/28(火) 16:18:54.73 ID:L2p/iHog0
消費税と元号くらい専用のテーブル作っとけばいいんじゃないの?

 

7: 2017/11/28(火) 16:18:57.46 ID:gGyHMIjH0
「平成31年」って表示されるだけで問題は起きない

 

8: 2017/11/28(火) 16:19:07.14 ID:zxxQ9YLf0

2000年問題の時さんざか「何かが起こる!」といって脅されたが何も起こらなかった俺たちには免疫がある

ガラッ 話は聞かせてもらった とか な、なんだってーーのAAのモトネタ

 

67: 2017/11/28(火) 16:52:35.59 ID:RmSwsNZO0
>>8
ロートルコボラーがその分地獄を見たんだよ
今時のシステムで元号くらい問題を起こすなんて新人が作った物くらいだろ

 

10: 2017/11/28(火) 16:19:49.52 ID:Ns2KlW650
元号なんて廃止しろや
結局、平成は何も見ずに今年は何年と答えられなかったわ
昭和は大丈夫だったのにw

 

17: 2017/11/28(火) 16:22:41.04 ID:3J7qR04q0
今さらそんなだめなシステムないと思うけど

 

19: 2017/11/28(火) 16:24:16.23 ID:zPqWac5X0
2000年問題と一緒にするのはおかしいだろ。
元号が昭和→平成に変わった時と
比べるのが正しい。

 

85: 2017/11/28(火) 17:04:24.66 ID:8k+FKhIi0
>>19
しかも昭和→平成も89年だったしな
既にUNIXやMS-DOS下でのシステムが普及してた頃だし
未だに元号チェンジに対応できないシステムなんてそうそうないわ

 

22: 2017/11/28(火) 16:25:13.78 ID:30wYEEe+0
「平成生まれ」は年寄り扱いに

 

23: 2017/11/28(火) 16:25:42.19 ID:OCRdgTAH0
うち和暦でしかも平成になった時にその場しのぎの対応しかしてなかったらしく
数千あるプログラム全部見直す羽目になったわめんどくさ
新元号になって新天皇が早々に崩御した時の事も考えないとダメだしやる気しねー

 

27: 2017/11/28(火) 16:28:57.65 ID:yZMJh/q40
>>23
そりゃ30年もシステム使うとか考えないし。

 

65: 2017/11/28(火) 16:51:06.58 ID:olpSVNsb0

>>27
歴代のプログラマが毎度毎度それをやっているんだよな。
数十年前に「まさかこのプログラム何十年後も使っているはずがないよな」と思って作ったのを
結局何十年も使い続けることになって、ずっと後の人が困るとか。

「自分はまさかそんなことしないよ」と思っている人がいるなら、聞いてみたい。
じゃああなたは、自分が書いたプログラムが1000年後に使われることを想定して作ってますか?
「まさか1000年もこのプログラムを使い続けるわけないよな」と思ってませんか?

 

25: 2017/11/28(火) 16:27:13.54 ID:9HFP0Yho0

あるに決まってんだろ

どの程度に抑えるかの話をしろよ

 

29: 2017/11/28(火) 16:29:13.97 ID:Uhzop0Qc0
Windowsは現状でもレジストリの和暦好きに書き換えれえるしな

 

30: 2017/11/28(火) 16:29:29.65 ID:Pb7xnaim0
何で元号を使うんだよ
もうやめろよ

 

31: 2017/11/28(火) 16:30:20.23 ID:u3TqOywJ0
元号が変わるのはいいけど
もう公式書類は西暦で統一してくれないかね…

 

38: 2017/11/28(火) 16:34:18.27 ID:tnngsv2r0
こういうところで儲けないとな
しっかり予算確保しとけよ

 

51: 2017/11/28(火) 16:41:50.42 ID:Mcg1t0K/0
普通の会社でひっかかりそうなのは財務システムくらい?

 

66: 2017/11/28(火) 16:51:36.20 ID:y5n8de/T0
まともなシステムなら、DBはUTCで、表示する直前に変換してるだけだから、
元号がどうなろうと、なんの問題も起こらない

 

70: 2017/11/28(火) 16:53:57.02 ID:vG1Z/ChS0
>>66
いつまでも平成のままカウントアップしつづけるのが「問題点」に該当しないならなー。

 

73: 2017/11/28(火) 16:56:29.01 ID:H4jJHsiVO
SEの努力でそんなに問題はおきないきがする

 

87: 2017/11/28(火) 17:05:58.38 ID:bLREa55+0
おいエンジニアなのに停電とさテレビ止まるとか認識あったのかよwww
せいぜい並び変わるくらいだろ
あたま大丈夫か?

 

引用元: http://asahi.5ch.net/test/read.cgi/newsplus/1511853411/