政府は2018年5月に、改修が間に合わない場合は混乱を避けるためしばらくは「平成」を使うという対応もあり得ると発表しているが、あるエンジニアは「5月1日を過ぎても『平成31年』と記載された帳票類をやりとりするのは、組織として恥ずかしいのでは」と苦笑する。
一方で、改元前に和暦から西暦に切り替えを進めている企業もあるようだ。例えばみずほ銀行は、18年から幾度かにわたって実施してきたシステム更新で、預金通帳などの表示を「30-9-28」（平成30年9月28日）といった和暦から「18-10-4」（2018年10月4日）といった形で西暦に切り替えている。
この記事では、複数のエンジニアに取材して分かった「現場の声」と、IT業界の悲喜交交（こもごも）のストーリーを拾っていきたい。
連載：平成のうちに知りたい元号のこと
https://www.itmedia.co.jp/news/series/12465/
改元対応については、複数のエンジニアが「平成以後に構築されたシステムであれば、元号、消費税、うるう秒など、将来的に変更や対応が求められる事案を考慮してあるのが普通だ」と口をそろえた。「日本人のエンジニアであれば、構築時に改元を意識して当然」という人もいたが、中には「勘定系のシステムや大規模なシステムの場合は、問題点を洗い出して改修するのに1カ月以上かかる」と肩を落とす人もいる。
今回は「2019年5月1日から新元号に切り替える必要がある」と事前に分かっているので、4月1日まではダミーの元号を設定してテストしておき、公表後に新元号に入れ替えて、確認テストを実施すればいいものだと思っていたのだが、話はそう単純ではないらしい。改元を考慮したシステムであっても、機能の追加や改良といった「後付け」により、テストしてみないとどこに問題点が潜んでいるか分からないケースもあるという。
記憶に新しいところでは、1月にMicrosoftが新元号に対応するためのアップデートを適用したところ、各地で「Excel 2010」が強制終了するといった不具合が報告された。改元対応というものは、思惑通りには進まないものなのかもしれない。
□終わらない仕様書との戦い
システムの規模が大きければ大きいほど、多くのリソースを割いて改元対応を進めなければならない。あるエンジニアは「膨大な数のプログラムを相手に、チームで調査、改修、テストを繰り返している。時間はいくらあっても足りない」とため息をつく。
自分が構築時に関わったシステムなら仕様書を遡り、比較的短時間で問題を特定できるのだが、彼が担当しているのは、すでに離職した先輩が手掛けたシステム。「仕様書に記載されていない変更箇所を見つけると、その洗い出しだけでも一苦労。先輩に恨み言のひとつもぶつけたくなる」そうだ。
筆者は「仕様書に変更点が書かれていないことがある」ことにまず驚いたが、他のエンジニアもその可能性を否定しない。「最近は監査が入るのでそうした事例は少なくなったが、古いシステムであれば仕様書を確認しても変更点が書いていないことはあり得る」と証言する人もいた。改元対応に限らず、前任者たちがシステムの増改築を繰り返した結果、迷路のように入り組んだ“後任泣かせのシロモノ”になったという話は枚挙に暇が無いという。
ある50代のエンジニアは改元対応に「2000年問題」の記憶を重ね、「黄ばんだ仕様書と悪銭苦闘しながら古いシステムの問題点を洗い出し、改修するのは気の遠くなるような作業だった」と当時を振り返る。
2000年問題の対応にかかった時間は3年ほど。未解決事件を解き明かすコールドケース捜査官になった気持ちで、プリントアウトした数十万行というソースコードを、ラインマーカー片手に1行1行確認していったそうだ。既に一線からしりぞいた彼は「改元で似たような対応を迫られているエンジニアもいるのでは」と後輩を憂える。
長いので >>2 に続きます
2019年03月04日 07時00分 公開
ITmedia NEWS
https://www.itmedia.co.jp/news/articles/1903/04/news047.html
アプリとかOSって多言語仕様で、簡単にいろんな国の言語に切り替えられるよね？
元号も変わることを想定して、設定一つで簡単に切り替えってできないの？
作り手による
今が平成何年かも知らない。平成であることは知っているけど。
システム変更なんて何もいらない。
元号なんて２文字固定なんだから最悪でも全文検索して全置換するだけで終わるだろ。
4/30以前は平成にせにゃならんから、単純に置換すればいいわけではない
元号追加の実績は無いから、
バグは結構でてくると思うよ。
今回みたいな1年以上の猶予期間と事前に変わる日付がわかってる改元でさえこんなに大変なんだったら
もし天皇陛下が崩御となったらデスマとかじゃ済まない大パニックじゃね?
はっきり言って今回のはLevel1だろ
面倒臭いのはユーザー対応だけだな。
予想できるような不具合は予め対策出来る。問題は誰も予想しなかったことが起きた場合。
古いシステムは大変そう
だよなあ
別に生活に困らないのにわざわざ導入して苦しんでるんだもん
ほんとアホな奴らだと思うよ
こっちはSE含め見世物小屋の珍獣を見るように楽しませてもらってるわｗ
リレーショナルデータベースと言うのがあってだな
そういうのは簡単にできるはず
在チョンは黙っとけよ
平成01年とかでええんちゃう？w
検索できんし、かさばるだけで扱いづらいし、
エディタで編集してるよりいいことは一つもない
せいぜい、仕事してますよアピールくらいかw
お前んとこの祖国はバカだから漢字を捨てて、ちょっと前の自国の公文書も読めねーんだろw
そういうバカは黙っとけw
客に仕様の文句言っても何一つ得するわけじゃない。
水増しすんなと言われるのがオチ。
そりゃそのとおり計算して、おとなしくその帳票を納品するわな。
えぬてーてーとかひたちとかうじつうとかえぬいーしーとかぱなそにつくとかきやのんとか後めんどくさ略
名だたる大手やその子会社人身売買企業どもの設計能力じゃこんなもんだな
いやいや プログラムの話でしょ?
どんな古いシステムでも
そのプログラムはある訳で、unuxに持って行って
置換かけてからまた古いシステムに再インストールすれば
良いのでは?ダメなの?
元号をプログラムの頭で変数定義しておけば
一か所の修正で済むし、その行を#でコメントアウトしとけば
次に見る人も分かると思うし
コストを考えない人は理想を追い求めればいいんじゃないかな
元号決まってから修正とかどんだけ無能なんだよ
DB繋いでるシステムはいいけど単体で動く帳票を和暦で大量に抱えてたらめんどそう
超バカ
天皇陛下が崩御なされる前提なので不謹慎だ。
発表されてから対応すべき。
でスタンスが変わるな
多少の実務経験があればヤバイことになりそうなプロジェクトは有り得るという事は認識出来る
西暦しか使ってないシステムしか作ってないけど過去の流用資産で発生したトラブルやなんでもない修正に対する顧客の過剰
なまでの検証作業や打ち合わせ・説明の要求を経験してりゃそのへんが重なった場合の最悪のケースは容易に想像出来る
それはツールレベルの話。
大抵の大規模システムはwindowsだけアップデートされても
他でされずにその差異でコケる。
‏
@kininaru2014111
18分18分前
その他
籠池さんの初公判に合わせてゴーンを保釈したとしか思われない。なるべく籠池氏
の裁判のことがゴーン保釈で影に隠れると思ったのだろう。それにしてもゴーンの
下手な変装、サングラスをかけるだけでいいと思うが。なんだよ作業服に帽子って。
祝日対応とかローカライズされてたらワヤやな
処理されるたびに通信負荷がかかり相手のサーバダウンや通信障害でシステムがエラー停止
元号に変換するだけのことでそんな仕組みにするなんて真性のクソシステムやんｗ
是非この機会に
>先見性のあるソフトウェア技術者は、８０００年ほど先の西暦１００００年問題に対処しているかも。
そういうのを無能な働き者って言うｗ
すればいいだけ。
元号違いを理由とした受領拒否を禁止することも忘れずに。
491じゃないけど、日本語読めてるか？
