【頑張れシステム屋さん】システム改修、改元までに完了 国民生活影響なし 政府「省庁･独法･地方自治は適切に対応しろ」
■ このスレッドは過去ログ倉庫に格納されています
2019.3.14 12:37
政府は１４日、天皇陛下の譲位と皇太子さまの新天皇即位に伴う５月１日の改元に向けた関係省庁連絡会議（議長・古谷一之官房副長官補）を開いた。各府省庁が管理する情報システムの改修作業は５月１日の改元日や１０連休明けとなる７日の開庁日までに完了し、年金や納税、雇用など国民生活への影響は出ない見通しになったことを確認した。
政府は各府省庁や独立行政法人が管理する計５７６システムの調査を実施した。いずれも効率的に作業を進めて改修を終え、改元・開庁日までに新元号での対応が可能になると判断した。地方自治体にも住民に混乱が生じないように適切な対応を求める。
また、民間企業では金融や交通機関などのインフラ事業者でも改修に向けた対応が進んでいることも確認した。対応が把握できていない一部の企業には今後も周知・広報を徹底する。
会議は４月１日の新元号の事前公表まで１カ月を切ったことを踏まえて開催され、各府省庁の官房長級が出席した。古谷氏は「各府省庁では今後の改修計画を着実に実施してほしい。民間にも引き続き必要な対応を行うように周知してほしい」と指示した。
https://www.sankei.com/smp/life/news/190314/lif1903140021-s1.html 運転免許証の更新は、４月２日以降なら新しい元号で印字してくれるのかな？ うそつけ。
これで元号が安永（2回目）になったらパニクるんだろう？ どーせ
１＝明治
２＝大正
３＝昭和
４＝平成
５＝「」
６＝「」
７＝「」
８＝「」
みたいに数字で管理してるんだから、大丈夫。
発表されたら５番に漢字２つ入力してENTER押すだけのお仕事です。
中学生プログラマが作ったら
まったく常識を超えたミラクルなモノを作り出してそうだが。。。
いや、飛行機の計器プログラムが間違えてて
ジャンボ旅客機が墜落する時代、どこにバカがいるか分からん 元号が何に変わろうが、例え元号が４文字どころか１０文字になろうが
元号廃止になろうが、どうなっても設定だけで対処できるように作っておけばよくね(´・ω・｀)？ 公的には西暦をメインにすれば良いだけ
くそめんどくさい元号を
庶民に押し付けるなよ馬鹿が 改元までにオウムも片付けたしあとは3月中にピエール瀧の残党だけですね
とひたすらのんきな小室圭さんであった 税金タカリの独法なんてどうせ大した仕事してないんだから、自分たちでさせりゃーいいだろ。 >>10
実際にはそうなってたとしても改修費用をふんだくるために・・・ アホくさ
とっとと全部西暦にしろよ
元号なんて行事の時だけ使えばいいようなもんだろ 平成って30年あったんだ
つまり最初期30年前ぐらいのシステム
1990年頃のシステムなんて……
あーやだやだ知らない知らない
取引先のソフトが元号ベースで動いてた リボンUIに馴染めなくてExcel2003で使ってる人、終了のお知らせ、か? 民間は問題無いだろうね
そして何かやらかすのは必ず官 本当に怖いのは元号表記じゃなく元年表記を強いられること >>10
全くその通りの作りなんだけど、
関連する画面約150画面、帳票約350帳票を
全部テストが必要なので
テストに3ヶ月かけてようやく2月末に完了したよ。 >>12
最近作ったのは大体なってる
未だに95とか場合によってはXPで動いてるようなシステムでも個別にプログラムなおす必要がある 西暦だってまあ新たな主が出てきたら改元される可能性はあるんだけどな
キリスト前（BC）と主の後（AD）と大きく2つに割れてるだけで >【頑張れシステム屋さん】
いいカモ・・・もといお客さんだな
元号は昔あった2000年問題と違って影響なんてどこも無いに等しいし概ねチョロい作業だぞ >>12
使わない機能ですが対応するからには、初期開発費用をその分たくさん下さい
ケースが増えるのでバグが入るのも増えます
実際に使う時にテストするのならその分の費用も下さい。しなくてもいいならその覚悟で >>15
商売が儲かるようになる対応ではない
両方とも予算がたくさんは出なくてふっかけられない 民間はもう元号切り捨てて西暦のみになってるところも多いよね 去年から西暦にしたけど、年間数回の過去ファイルの検索できなくて文句言われた あ？何もしねーよ
平成35年表記は間違いじゃねーんだから
余計なことして事故増やすな >>31
閏年は四年に一度しか知らなかった→セーフ
閏年は百年に一度無いんだとドヤった→アウト
閏年は四百年に一度あるんだよなと愚痴った→作業員 大変なのはまともなシステムじゃないところだけ
そういう所のは仕事を受けるだけで面倒 >>2
NHKのニュースみたが基本ソフトを作っているメーカーとも協調し、となってたので本番は4月12日の定例とwin10の春の大型アップデートが終わってからだな >>35
コンピュータの中では1970年からの経過時間でしかカウントしてないから、
西暦だろうが和暦だろうが結局は変換してるのよ〜
どっちでもいいねん >>1
元号発表からが勝負だから
システム屋に猶予を与えるためにＧＷ10連休にしたのか >>12
文字数は難しいな
帳票の場合レイアウトの問題がある
それがなければ余裕だし、今どきのシステムはみんなそうなってる >>1
もうシステム改修は終わってる
あとは文字を入れるだけ >>27
なんで共通化してないんだ
だからシステム屋はボッタクリといわれるんだよ
本当は1ヶ所修正するだけなんだろ？ >>49
IT時代になったんだし、
日本の産業省とかも日本標準関数、なんてのを
javaなんかで記述して公表すればいいんだよね。
仕様のたぐいは全てプログラム化できるんだから。 直前に発表したい理由と
リスクを負ってまで直前に発表する価値があるのかどうかの議論がまったくない >>51
Java8以降なら既に
JapaneseDate や JapaneseEra クラスあって和暦をサポートしてるよ。
5月以降のSDKアップデートで新元号にも対応するはず。 元号自体廃止しろや
こんな非効率、前時代的なもの
何の意味があるんだよ >>12
元号が3文字になったらシステム屋が爆発するわ >>49
お前の考えるような単体のプログラムじゃねえんだよ。
複数のシステム、ハードウェア、ネットワーク、運用拠点から構成された巨大なシステムなんだから
設定が一ヶ所ですむわけがない。
おまけに稼働から20年以上経過してて当時の担当者は全部入れ替わってる。その間に改元関連のバグが埋め込まれる可能性も高い。
しかもテストは顧客側の要望でありシステムがぼったくりとか的はずれの批判もいいとこ。
なにも知らない癖に批判だけはいっちょまえなお前のような人間が居るから世の中の無駄なコストが発生するんだよ。
反省して隠居でもしたら？ >>61
サブシステム2ヶ所で消費税使ってるけど同時期の開発だし
消費税マスタも修正画面があるくらいだからそこで設定直すだけでいいよね？
と思ってマスタを変更したら
片方は×0.05べた書きだったって言う事件がありましてね…
改元でそういうことがないと言い切れる奴はいないはず うちの会社は去年のうちにテストしたけどな
M,明治,18680126
T,大正,19120730
S,昭和,19261225
H,平成,19890108
G,元禄,20190501
ってマスターにして20190501いこうの日付は全部「元禄」になることを確認した >>60
でも過去に3字、4字、6字の組み合わせの元号あったんだよなぁ・・・ よっぽどバカじゃないかぎり仮想新元号(漢字２文字、アルファベット頭文字１文字など)を使って
ロジック検証は終えていなければおかしい。 心配ない。昭和から平成に変わったときに経験済みだから、平成で運用しているシステムは改元対応済みだよ
システム発注時の仕様要件に、改元対応が入っているんだもの >>66
ここだけの話、京都市役所のメインフレームのACOSをリプレースしてオープン化する作業、10年近く前からやってるけど
COBOLのマイグレーション失敗して元号対応間に合わないかもしれんのやでw
今必死で元のACOSのCOBOLのソースにパッチ当てしてる >>66
最近は考えて組んでるからそうそうないが
元号の文字のせいで誤動作するってパターンもあふから
公表が遅いせいで二度手間に >>70
そんなことされたら全国のシステム屋が
政府焼き討ちしに行くと思う
マジで >>65
過去はどうあれ、現在は漢字2文字と閣議決定で定められている
あと、日本の元号は2文字と4文字しかないと思うが、3文字や6文字元号は知らないな システム屋ってバカチョンって言われてるよね
馬鹿でもチョンでも出来る単純作業 >>70
閣議決定で「明治以降のアルファベット頭文字と重複しないこと」と決められてる >>67
昭和から平成の時代はそんな需要皆無だった。
今は単体システムでなく様々なシステムが連携してるから、
単体テストだけでなく統合テストせないかん。 >>75
そんなのとはない
どれだけ遅れてる企業なんだよ
1989年時点だって他者とデータ通信してたし、社内システムだって連携してたわ >>75
他システムと和暦でデータ連携してるシステムなんてあるのか？
少なくともうちの会社にはそんなシステムないから関係ない 和暦は大体印刷、表示周りくらいだよなあ
データは基本西暦だろし。まあないとは言わんけど >>77
元号コード+和暦年で日付わたすシステムもあるんやで..
まぁ、知ってるとこは殆どが西暦化したけど。 てゆうか今動いてるシステムで
元号想定してないシステムってあるの？
常識的に考えて三個くらい追加を想定して
試験もしてるよね？ >>82
ほとんどないだろうな
30年前に改元があったわけだから、その当時に動いていたシステムはその時に改修してる。
その後に立ち上がったシステムは当初から改元を想定した作りになってるだろうし
平成になってから作ったシステムで改元を想定してないなんてシステムを作った組織は潰れればいい なんかシステム屋を批判してる人が多いけど
和暦使ってる、全ての帳票、画面のエビデンス
和暦西暦変換、テストが膨大で
顧客がそれを要求するんだよ
売り上げに関係ないから安い値段で交渉するし
暇な奴いないし、やりたいとは思わないだろ IT土方が不眠不休で頑張るから国民生活に影響なし！！！！ >>77
ヨタのディーラー向けシステムは経理、車両システムが和暦でデータ持っててサービスは西暦でデータもってた
DBからデータ抜くのでデータレイアウト集みてひっくり返った
今回の元号対応に伴う大規模メンテナンスを10月と2月にしてようやく全システム西暦でデータ持って表示だけ和暦対応になった >>82
実は結構あるで
平成にできたシステムなので伝票入力画面とかそもそも元号欄なくて平成しか想定してないとかw
去年から今年にかけて慌てて対応した >>84
仕事がたくさんあるのは喜ばしいことじゃないか
羨ましい限り
うちの会社はもうとっくにテストが終わってる
価格交渉力がないのは自分の会社を恨むしかないな この前車検うけたら
平成33年とかありえない年が書いたステッカー渡された
免許も平成34年までとかなってるし
なんなんだこれ？
こんなアホみたいな年号とかさっさとやめろよ 期限切られたら間に合うようにデスマーチなのはいつものことだし
どうせ実際使い始めれば不具合出て修正するためにデスマーチなだけだし >>84
売上に関係あるかないかで改修のコストが違うのか？
それを受ける側もブラックだな 宇宙世紀に変わった時は世界中のシステム屋が大量に死んだのかな？ 何を今さら
３０年前にも「改元」あったじゃないか
当然、それに備えて構築しておくべき >>92
法的には改元されてないので、現在は平成33年だろうが
平成100年だろうがなんの問題もない。 >>92
西暦だって永遠に使われる保証はないんだぜ？ >>96
マジレスすると当然、そう客には提案するが金が出せんとかただでやれと言われてやってないとこ多数
金がでないならわかっててもやらんぞ >>99
金を出されても、客が希望する期限内にリソースが確保できなきゃそんな仕事は受けないわ ■ このスレッドは過去ログ倉庫に格納されています
