新元号から改元まで1カ月でシステム対応は間に合うか エンジニアたちの本音
レス数が1000を超えています。これ以上書き込みはできません。
https://headlines.yahoo.co.jp/hl?a=20190304-00000024-zdn_n-sci
新元号の発表が近づいてきた。IT業界には、改元に伴って必要となる情報システムの改修を前に戦々恐々としているエンジニアが多いのではないだろうか。
政府は2018年5月に、改修が間に合わない場合は混乱を避けるためしばらくは「平成」を使うという対応もあり得ると発表しているが、あるエンジニアは「5月1日を過ぎても『平成31年』と記載された帳票類をやりとりするのは、組織として恥ずかしいのでは」と苦笑する。
一方で、改元前に和暦から西暦に切り替えを進めている企業もあるようだ。例えばみずほ銀行は、18年から幾度かにわたって実施してきたシステム更新で、預金通帳などの表示を「30-9-28」（平成30年9月28日）といった和暦から「18-10-4」（2018年10月4日）といった形で西暦に切り替えている。
改元対応については、複数のエンジニアが「平成以後に構築されたシステムであれば、元号、消費税、うるう秒など、将来的に変更や対応が求められる事案を考慮してあるのが普通だ」と口をそろえた。「日本人のエンジニアであれば、構築時に改元を意識して当然」という人もいたが、中には「勘定系のシステムや大規模なシステムの場合は、問題点を洗い出して改修するのに1カ月以上かかる」と肩を落とす人もいる。
今回は「2019年5月1日から新元号に切り替える必要がある」と事前に分かっているので、4月1日まではダミーの元号を設定してテストしておき、公表後に新元号に入れ替えて、確認テストを実施すればいいものだと思っていたのだが、話はそう単純ではないらしい。改元を考慮したシステムであっても、機能の追加や改良といった「後付け」により、テストしてみないとどこに問題点が潜んでいるか分からないケースもあるという。
記憶に新しいところでは、1月にMicrosoftが新元号に対応するためのアップデートを適用したところ、各地で「Excel 2010」が強制終了するといった不具合が報告された。改元対応というものは、思惑通りには進まないものなのかもしれない。
■終わらない仕様書との戦い
システムの規模が大きければ大きいほど、多くのリソースを割いて改元対応を進めなければならない。あるエンジニアは「膨大な数のプログラムを相手に、チームで調査、改修、テストを繰り返している。時間はいくらあっても足りない」とため息をつく。
自分が構築時に関わったシステムなら仕様書を遡り、比較的短時間で問題を特定できるのだが、彼が担当しているのは、すでに離職した先輩が手掛けたシステム。「仕様書に記載されていない変更箇所を見つけると、その洗い出しだけでも一苦労。先輩に恨み言のひとつもぶつけたくなる」そうだ。
■行政は意外に苦労しない？
一方で、もともと西暦を使っているためそこまで影響はないと答えるエンジニアもいる。となると影響が大きそうなのは、行政機関や金融機関と関わりがあり、和暦または和暦・西暦を併用する仕組みを構築している企業だろう。特に行政機関は慣例的に和暦が使われていることが多い。
さぞ改元対応には苦慮しているだろう――と、首都圏にある県庁のIT部門の責任者に尋ねたところ、予想とは異なり安堵の笑みが返ってきた。「地方の行政機関の多くは、自治体向けのパッケージシステムを導入しているところが多い。ベンダーがしっかり対応してくれるので、大きな問題は起きないと思う」。別の関係者も「パッケージのシステムをそのまま使っているところなら、OSやベンダーが対応してくれるはずだ」と話していた。
■ベンダー企業のエンジニアはどうなる？
では、パッケージシステムをそのまま使わず、カスタマイズしている企業はどうだろうか。あるエンジニアによれば、従業員数が数百人から千人程度の中堅企業では、業務に合わせてシステムをカスタマイズしていることが多く、開発や保守を外部のベンダーに丸投げしているケースがほとんどという。丸投げされたベンダー側はたまったものではないだろう。
また、あるベンダーの責任者は「有事に備えて、ゴールデンウィークは最低でも自宅待機しなければならない」と話す。世間では「10連休で海外旅行にGO!」などという浮かれた話も聞こえてくるが「休めるかどうかは、事前のテスト結果次第」とのこと。
状況が芳しくなければ、当然ながら休みは期待できない。改元対応に携わるエンジニアたちに、果たして休みはあるのだろうか。 聖武天皇が出家するために退位したあとの元号が4文字だったはず。
この年はさらにもう一回改元した。 >>896
といいつつ、当日ひっくり返すお役人様がいないことを祈ってる人たちがいそうww >>857
この場合cとdは拡張だから
aとbで縮退運転できるように組むべきなんだわさ
全システムストップする必要ないでしょうと
そのaが元号のハードコーディングだったりして >>897
＞システム屋は予算が出ればやるし、出ないならやらない
バグだーで騒がれる。
新元号対応してないシステムって今時ないだろーｗ
という当たり前のルーチンワーク >>898
そうだよ。エンドユーザ。
だからシステムでどうのこうのじゃあ通じないからハードコピーとって説明書いてる(´･ω･) >>895
だから改元なんて想定してるのは当然っていってんだろ。
その上でテストが必要なんだよ。
金融関係で元号扱わないシステムのほうがレア物だ。
現実見れないガキは黙っとけよ。 >>894
そういうテーブルは存在するが参照が徹底されていない、
そんなシステムはあるある >>897
お前みたいな下請けSEの責任じゃないってことでしょ
その通りだよ
底辺SEは悪くない >>903
開発元と現保守担当が違う企業の場合揉めるだよ、カネの問題で マイクロソフトがレジストリに元号刻むとか
どんだけ国を取り込むつもりなんだよ。 スタンドアローンが多いから、
ｄｂ接続ねぇわで定数に定義してるんだろ。 たまたま問題の少ない環境で仕事している人が、
すべてを理解しているような発言を繰り返しているな >>905
エンドユーザーの実機テストが終わってないのでリリースできません
えんど「てすとするひまありません(^q^)」
JYOUSHI「はい、間に合わなかった
ね。ボーナスなしだYO!」 このせいでオフィス2003を365に変える羽目になった
勘弁して欲しい どうせみずほはシステム障害で30連休くらいするんだろ？
利用者も経営層もみんなわかってるよこれまでの経験から >>915
マイクロソフト「お買い上げありがとうございます」 >>916
一昨年、法人なりをして「平成」と印刷された領収書がたんまりとあるわ。 >>225
OA関係は前回の元号対応とか2000年対応とかで手が入ってないものは殆んどないだろ。
FA関係の方が、たまにしか使わない機器の方が危ないが、それが30年以上まだある方があり得ん。 改元がどうこうよりエンドユーザーのシステム音痴の問題だろ
コレ >>915
Office2003のサポート切れてるのにまだ使ってたのかよw
こういう会社があるから新元号対応で炎上するんだよww >>920
98のFAとか普通に稼働してると思う。
ただ元号扱ってはないだろう。西暦だと思うがね。 元号はあってもいいけど無駄に引っ張るのが迷惑だわ
さっさと発表しろ >>894
その素晴らしい設計思想が末端のプログラマに伝わってない且つ確認も怠ってしまったシステムが世の中に存在するんだよ >>925
総理大臣が天皇より偉いということを恣意的に
知らしめるため伸ばしてるんだよ。 >>902
素人だけど縮退運転という用語でなんとなくわかった
ありがとう >>895
結局、本番前のテストは必要なんだよ。
本番で上手く動かなかったら、ユーザー側の担当者のクビが飛ぶ。 空欄を表示するようにして手書き前提にしとけｗ
暫くはな。 >>906
理解するつもりもない無能に説得したって無駄よ無駄
こいつの駄レスだけで開発音痴の小規模システムしかやってないのが嫌ってほどわかるでしょ
ほっときなさい 安の字来い！！
>>884
↑こういうヤツを数十年暗澹たる気持ちに叩き落したいｗ 今回を機に西暦に移行したようちの会社。元号使用廃止 >>243
去年だっけ？最高齢の人が女性にかわって115才とか。
あと、10年くらいすれば明治生まれも殆んどいなくなるだろうな。 >>927
万一、5/1より前に陛下が崩御されたらとか、それも暗殺だったらとか、新元号にそいつの名前と共通の文字があったら、とか
あと、普通にあり得るのが、国民全員を敵に回すような犯罪者が出て、新元号とそいつの名前に共通の文字があったとか 元号は2600年以上の伝統がある
止めるなんてあり得ない >>936
今年107歳で7万人超
まだMはいるなあ そもそも行政が元号法に基づいて莫大な税金使って元号を考えるのってどうなの？
元号法って憲法・政教分離に反するんじゃないのか？
明治のころ作った下らん法律のひとつだろ、これ。 システムは１人で作って無いから、
マスタから元号を取っている個所、
ハードコーディングしている個所、
マスタから取ってはいるが固定長配列で追加するとメモリ破壊したりする箇所、
そういうのを全部調べてどうするか決めなきゃならん。
全部統一すると修正量は半端なかったりする。 >>821
星新一も同じようなことを考えたらしい
2001年に「にせん」と読む元号に変えればいいと……
https://www.hoshishinichi.com/list/list10.html
【わ行】 和暦と西暦（われきとせいれき） を参照 >>939
どちらにしろ過去データとして残ったりするから、
Mが同じ元号が来ない限りそのままにしておくと思うぜ。
さすがに入力フォーマットからは明治は消えるかも知れんが。 改元と10連休でてんやわんや
通常案件は後回しになってる >>250
そう言うのは、平成で2000年対応頃に新規で作ったシステムだろうな。
消費税も任意にかえられたりするんだろうな。 〜するだけだろって奴が作ったシステムがゴロゴロしてるんだよ >>931
そうだね
現実を知らないお子ちゃまには理解出来ない話だったわ 1ヶ月でできないとかいってるのはまじでアホ
新元号決まるまで口開けて待ってるのか
適当な二文字でいまからテストできるだろ 後で正式な年号と入れ換えるつもりで不謹慎な
年号を仮設定してテスト！
手違いで正式な年号に入れ換えられないままリリース
そんなこと起こり得るよね？ >>98
VB6のシステムとかで和暦変換を元号マスタ使用せずに、Format関数で手抜いているところは、阿鼻叫喚だな。 なまじ猶予を与えるからこんなことになる
発表と同時に改元でよかった >>879
こういう安易な考えの中には
5/1になるまでは平成31年5月1日と表記したいとか
平成32年の日付のデータ入力が来たときなど
は考慮されてない >>953
こういうアホが、根拠のない大体一か月あれば終わる論で発表時期決めたんだろうことは容易に想像できるな
ちなみにこういうアホは5月に障害が起きなかったとき「それみたことか」と言うのも想像に難くない
リスクの問題だっつーの ？？？「お前らは好きなこと仕事にしてるんだから、文句いうな、アニメーターを見習え」 会社辞める予定だけど元号案件がしばらくはありそうだな （元号リリース）は、入りました！
あぁ…次は消費税だ
ところでこれ（税率計算ソース）を見てくれ…どう思う？
すごく…（修正範囲が）大きいです… 無能実装されてない限りベタで書いてるわけでもないのに
ほとんどは開始日と新元号の名称いれるだけですむに決まってる
問題は三文字だった時のレイアウトについてくらいだな システムはいったん平成貫けばおっけー
そのうち帳票から廃止されるからそのとき西暦にかえるだけ >>268
そんなのは昭和のシステムだろうな。
平成になってから手を入れたのはMTSHの元号の記号をいれたり抜本的にデータは西暦、表示・印刷時に変換する様に
大規模な変更したりした。 改元はほぼ終わってるが
どちらかというと
連続10日の非営業日の方が騒ぎだったわ。 ソフトウエアが
設計道理に動いてくれるなら
どんなにか良いだろうに反語 >>30
世の中には現場に張り付く担当者がいないシステムの方が多いだろ。 >>970
軽減税率って今後も1種類だと思うか？
何パターンも出てきたら、どうしようかね？ プログラムは作ったプログラマーがずっと管理すると思ってるのは、
一度も会社に関わったことがない人だというのが分かるいい目印になるな >>962
最初は統一されてるんだ。
長年運用していくうちにいつの間にかぐちゃぐちゃになる。 >>970
昭和→平成の時も１月改元で４月から消費税新規導入だった 最初から作り込んでるだろ。記事の通り。改元も含めてテストをする。 何のためのシステムやねん ワンクリックでOKなものにしろよ >>982
動いてるシステムを更新するまともな経営者や首長が多くないから 今頃動いてるやついないだろ。
穴だけ開けて決まったら定義して終わり。 平成って書いて「おぴょぴよ」と読むくらいでも対応出てるように作っとけよな。 今簡単だとか言ってる人は作るときにもそれ言ってるから
まともなの出来てなくて苦労したりする >>992
立てたって全く同じ流れで話題がループするだけだろ・・・ いけるだろ
ワンチャン白紙で出るようにしとけばいい
後で訂正かけろ >>978
課目で分けるか新規に追加するか
面白いところ >>656
ねーよカス 慣習として二文字だっただけの話。ボケが >>304
前回以降、どれだけそうなってるのかは知らない レス数が1000を超えています。これ以上書き込みはできません。
