【IT】新元号は2019年5月1日からの見通し、富士通は「洗い出しとテストの負荷が大きい」
■ このスレッドは過去ログ倉庫に格納されています
政府は2017年12月8日、天皇陛下の退位日を2019年4月30日に定める政令を閣議決定した。「平成」は31年までとなり、2019年5月1日以降は新元号に変わる見通し。
富士通は新元号のシステム対応について、「個別開発したアプリケーションの影響を特定する洗い出し作業に手間がかかる」(広報)と話す。さらに「元号改正による修正作業そのものよりもテストの工数が増えそうだ」と見通す。システム環境を2019年5月1日以降の未来日付にして、修正内容が正しいかを画面や帳票などで確認する。
http://itpro.nikkeibp.co.jp/atcl/news/17/120802832/ 年号の変更の影響なんて、設計時に考慮して、
それをそのままアプリのテストの仕様書に反映するんじゃないんかい。
年号が変わるときに洗い出しとか、真面目に仕事してる?
「お金がかかります」という理由付けとしか思えんが?w
それに、修正作業なんて、文字数同じだし、一瞬で終わるでしょ?
まさか、ソースコードに「平成」という文字列がそこらじゅうにないよね?w SIerに就職してすぐに昭和→平成の対応をした記憶があるが、
具体的に何やったか全く覚えてないわ。 社内見ててもテスト云々で大変そうなのは分かるが、
それしきの事にそんな時間かけてて世界相手にやってけいけるのか? とも思う >>291
昭和→平成の対応を力業で乗りきったプログラムがまだ動いてたりするからな。
DBの中身が(昭和)90年なんてのもしぶとく生き残ってるし (*゚∀゚)この機会に西暦に統一しまーす!
(*゚∀゚)するとこの誕生日の元号に○を付ける自作のコントロールはどうしましょう?
( ゚д゚)・・・
( ‘д‘⊂彡☆))Д´) パーン 天皇が換わるたびに
超絶無駄な作業に忙殺されるのか
日本の凋落が止まらないのも道理 >>302
確かにw その可能性はゼロではないからなぁ… >>295
おまえんとこは平成35年とか平成40年とかで帳票出力し続けるのか(笑) It系のカスどもはこれを理由に
新しいシステム導入しろとかボッてくるんだろ
怒鳴り付けて格安の値段でやらせてやるわ >>308
うちの職場にアニメが好きで日本に来たフランス人が入ってきたぞ >>329
人手が足りないから安くでは請け負わないよ
もう時代が違うんですよ、爺さん >>308
あれをああしてうまく動くようにしてくれ。でわかる能力がなうからな。 通常は急に変わるから「後手の対応」でそもそも考え方が違うのかな >>302
その時は「限られた時間内で最大限のテストをします。」と言える
今回みたいに時間的に余裕がある時に
「100%大丈夫な事をテストで確認しろ」とか言われるとテスト費用と時間がとんでもない事になる 西暦使うのを禁止すればいい
文句いう非国民SEは死刑でいいよ そんな暴君みたいな事をしたらお前が真っ先に一般人に処刑されるだろうがねw
ていうかさ、元号を強要するのが愛国とか頭おかしいから。
本当に優れた良い為政者なら、かつては意味はあったかもしれないが、現代においては国家国民のためにも、
元号の強要は否定的になるのが当然だと思うけどね。日本が今も専制君主あるいは封建制度でかつ、
その人が優れた人ならこんなものは確実にやめさせてただろう。
国のためにならないし、国民にこんなものを押しつけるのは名君ではないと言ってね いいか?
自分でなおせばただなんだぞ?
治せない?ならこっちの言い値を金払え 天皇が突然死して、システムが突然死。エンジニアも突然死。会社も傾いて突然死。
西暦で。 とりあえず、影響あるのは金融システムか
誰かも書いてたけど、全銀とやりとりするところは和暦あったな
今日見ておく
お金は重要だからな 西暦から和暦に変換するところは問題ない
官公庁や金融機関と外部データをやりとりする中に、和暦を使ってるところはある
そしてそのまま西暦変換せずにDBに入れてるのはあるかも
並び替えに使ってる場合は要注意だね 和暦でやりとりするってありえんだろと普通は思うが
それを平気でしてしまうのが日本のIT >>343
いや、米国だって昔はやってた。
ただあそこはシステムをイチから作り直すことが多いから、どこかで直せる。
日本は現行通りだから、昔の考えてないソースが残ってる。 平成がハードコーディングされているシステムってあるのかな? w 流石にマスタ更新で終わりだろ
元号ベタで使ってるシステムなんてみたときない >>283
導入時に和暦変換箇所のテストなんてすんでるはずだろ >>348
当たり前じゃん
元号をベタ書きしてる訳なくてマスタ管理でしょ
マスタ更新で元号が切り替わるテストをしない訳がない >>1
いやいやいや。
元号って明日変わるかもしれないのに
何を言ってるのか理解できません。 官公庁とか金融で元号マスタに対応してないとか和暦でデータ管理してるなんてレガシーシステムをリプレイスしてないなんて美味しい話がある訳ない ベンダー:元号変わる時のためにその点も含めて要件決めますよ。
顧客:そんなに直ぐ変わんないから決め打ちでオケ。
で、今に至ると。ウチの会社なんだけどね。
ユーザ部門も謎のシステムで業務回してるし、調べんのマジでキツイ。これに増税タイミングが重なるとホント困る。 今日わかったこと
和暦を使ってるとこ調べないといけない
しかし、どうやって全て調べるんだろ 元号マスタって大層なものではないけど、西暦を引数に和暦を返す関数があるのでそれを修正します
明治〜平成で4択しかないけども、皆さんとこはテーブル化してるの? 振込振替は和暦6桁でくるから困るね
平成と新暦が混ざったらどう判定しようか
お金のやり取りがないシステムは関係ないと思うけど
クレジットは大丈夫そうだった こっちは悪くなくても貰うデータが和暦の場合もある
しかも元号のない和暦 >>321
昭和100年問題がマジで心配。
プログラムよりデータの更新で問題が起きそう。 結局Y2K問題とか何もなかったし、金巻き上げるために叫んでるだけだろ 変更しなきゃいいじゃん。
そうすりゃ無償。
修正液とハンコで対応。 修正作業ってのは、元号の文字列を変更するだけのこと。
テストはその元号が正しく表示されるか確認すること。
元号が使われてるあらゆる画面、帳票を確認しなければならない。
まあ、正しく動くとは思うけどやらないといけない。 ■ このスレッドは過去ログ倉庫に格納されています