【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/ そもそも今の時代に元号必要か？
西暦に統一せいよ
平成何年とか言われても分からんっちゅーに >>66
内向きの仕事に貴重なリソースが空費されるのは嘆かわしいな てゆうか
そもそも和暦って
必須なのか
この際、廃止しては 戸籍関係、不動産関係の法律が和暦前提だから
システムの問題ではなく法律の問題
法律が西暦でやりますってなれば変えられる
法律が要件であり仕様
設計の問題ではない グループにたくさん社員がいるんだから役員、部課長もひら社員も含め全員でやったらできるぞｗ 前回突然の崩御立ったのに乗りきれてる。
今回は、一年以上前に通告してるのにできないなんて富士通はもうアウトだろ。
富士通製品はもう買えない。
買ったことないけどな。 話としては簡単
元号かえます
ってだけだけど
関連していろいろおこるしな
入力画面で元号つかってたら、選択肢ひとつ増やさないといけないし
平成４０年って入力は、今まではＯＫだったけど、あるときからはダメになるわけで
どのタイミングで不正と判断するように切り替えるのか、ルールを決めないといけないし
まあいろいろ これはぼったくる為の嘘だな。
平成の元号改定の時はもっと混乱して
貨幣に存在しない昭和年が刻まれたぐらいなのに 実際に作ったところにちゃんとチェックしてねっていうだけなんじゃないかな ２文字だと思ってる？
MTSHとダブらないと思ってる？ 新元号とＣ言語って似てるね！
このダジャレ使っていいよ！
デーブスペクター！ 昭和から平成に変わったときは不意打ちだったが、
西暦が2000年代に入ったときは「2000年問題」と話題になった。
この2つのイベントを通過したのに、今さら「新元号への対応が…」
とか言ってるシステム屋さんは新規の受注できんだろ。
と言うか、発注する側もその辺を見て選別の基準にしないと。 人手不足で外注要員不足
富士通社員は手配師ばかりでスキルなし
富士通無能
終わり >>119
発注側は役所だぞ。金使ったモン勝ちだ
一方のシステム屋は金使わせたモン勝ち
まさにwin-win
無関係な一般人だけlose もう、新元号は「西暦」にして、
2019年からはじめちゃえばいいのに。 >>41
奈良時代にあった4文字元号だとフォーム屋も景気よくなるかと、3文字だとフォントで2文字の幅とかでできそうだが 年号切り替える機能はあっても平成から年号変えてみるテストなんて要件入ってないことも多いから
動くのか不安やろ
帳票とか埋め込みで平成入ってる可能性もあるしな 前もって日時が判ってるんだから贅沢言うなよ
そもそも今まで何してたんだと
議論が始まってどれだけの時間が過ぎてるのかと
予防線張るにしてもあまりに程度の低い事を言ってる自覚がないのか コンピュータ処理上では、西暦だけでいいやん
なんで元号を組み込む必要性があるんだ あー、京都の自治体の基幹システムがヤバいだけだろ？ 天皇陛下の国・日本の文化である元号に対応してない企業。
経営陣のお里が知れますな。 今回は、1年半の準備期間がある。
普通は、ある日突然、改元される。
いつ改元があっても、すぐに対応できるようにシステム組んでおくのが当たり前だろ。
改元を前提にシステム作っていないのがアホバカ。 >>130
客の要望
作る側は手間増えるから誰も好きでいれないよ 何回同じことやってんだ？
前回から途中に2000年問題とかもあったろ
洗い出しとか自動的にできるようにしとけよ 作るときは他の要件満たすので一杯一杯やから
そんな真面目にテストしてないんやで
しかも富士通は外注に作らせてるから中身も知らんやろうし、あらためて全部テストし直さないとわからんやろ まあ自分がそれをやる業務に就いてたらここで言ってる奴らは勿論、続けるのを強制している政治家連中ですら
大半がこんなのやらんで良い、西暦だけで良い、というようになるだろうね。自分は何もせずに外野で命令だけ
している立場だから、勝手なことをほざいていられるだけ、自分の嗜好のみで語り日本や国民のことなど考えてないからな >>102
世界には、イスラム歴だってあるんですが。
イスラム教は、ほぼ世界最大の宗教で、
イスラム歴はイスラム教徒には当たり前の歴ですけど。 漢字も滅ぼした方がいい
こんな原始的な文字にこだわる必要はない 俺の会社なんか
未だにOffice2003使ってるからな
対応してくれるんだろか(°°;) >>138
ほかにもあるよ、独自の暦を建前上は存在してる国は。
もっとも業務で使ってるとかコンピュータで処理してるようなところとか、強制してるとこはまずないけどね
そのイスラム諸国にせよ、コンピュータが絡むところは西暦ですよ どれだけきっちり元号テーブルや略称変換ライブラリを用意していても
それを使わずに固定値の処理で実装されたら何の意味もないからなあ。 Excel2010、新元号に対応してくれないと困る。 もう文書とかコンピュータを使うシステムとかで使う年号は西暦に統一したらいいのに >>134
要望しているのは、政府や役所のコンピュータシステムだけやろ。税金の無駄
民間では、銀行のATM・クレカ決済・在庫管理などの端末はほとんど西暦表示だし
グローバル社会で、ネットで世界と繋がっている世の中で、元号なんか使わないしいらないし邪魔 まぁ許してやれよ、
ポチョポチョするだけで大変そうに見せるのも演技力が必要だし、
相対的にはだが、マスゴミが正義アピールするよりは罪が軽いw >>1
なんかこの記事の書き方だと富士通一社の問題のようだ 昭和から平成に変わった時にどんなトラブルがあったか正直覚えてない 2019年中は移行期間ってことで、平成でも次の元号の表記でも良いことにしたらいいじゃない >>150
システム的にはどっちもありの方が困ると思う >>124
日本には、元号法と言うのがあってわずか２項ほどの条文だが
それには、元号は二文字と明記してるらしい。
あ、条文は２項だが付記も２項あるらしい。どちらかに元号二文字の明記があるらしい。 例えば、改修後のプログラムで2020年を変換して平成32年ってプログラムが出したとするよね。でもそれは見た目上そう出てしまうだけで
実際の業務に支障はでないじゃん。でも、こういう些細なバグを気にしすぎるから、こんな本来速攻で終わるような改修もテストや調査でクソほど工数盛られて
本来もっと気にするべきバグを隠蔽されたりするんだよね。
それにＩＴ土方も客もリファクタリングの価値をしっかりと理解して日頃からちゃんと手入れしていれば、こんなクソみたいな問題は発生しないことは当たり前の話であり
要するに、どちらの側も、どのような作業に価値があるのか分からないから、かけるべき所に工数をかけないで、不要にバグを恐れて、客側からしたら些細なバグに怒り散らして、
ＩＴ土方側も作業が雑で、確認も適当で、客に対して必要な事を必要と説明できず本当にどうしようもない有様としか言いようがない。
ジャップにＩＴは早いんじゃないのか 免許とかも有効期限が平成で書いてあるけど
元号を跨いだ後はいつまでが期限か分かりにくくなるよねw >>153
所詮親方日の丸の仕事なんてそんなもんよ 直すべき所は直し、整理されていない所は整理する。
この当たり前がジャップには出来ない。
つまり、直すべき所は直さず、整理しないまま作業して、見た目だけ問題を無くしておく。
これがジャップの仕事。勤勉さや誠実さは微塵の欠片も無いと言っていい。 >>146
そういえば、年号が印字されているのは役所のものばかりだな
免許証に年金や税金のお知らせ払い込み票とか NTTデータは余裕のよっちゃんですって言ってたのに 「洗い出しとテストの負荷が大きい」とか言われたら、俺が客なら、
修正はどこかのテーブルかｘｍｌか何かのファイルのいずれか一ヵ所に他の年号と同じように新しい年号追加して
テストは画面のコピーを年号出してるところは全部エビ取るだけ
それだけですよね？え、負荷大きくなるのはなぜですか？って聞きますね。 >>134
客の要望だとしても 日付の計算コードに数行足すだけでしょ
大してむつかしくないやん >>153
ほんとこれ 次の年号いくらでも追加できるようにしておいて変わった元年で吐き出すだけ
システム上は西暦で動かして問題なし
こんな簡単なことをなんで大変そうに語ってるのか謎 >>167
それはそうだが、その情報も同じファイルかなんかどこかの一ヶ所で管理してるでしょ。 >>164
それは負荷大きいなあ。
>>166
どひゃー。全ての機能に影響しそう。
しかし、富士通にしてはまとも過ぎる気がする。
何があった？
・・・・って思ったらこの前秋草が死んだんやったな。
それで少しずつ良くなってるのかな？ プログラム内で年号を参照している部分が場所によって異なる変数を参照しているようなシステムがあるんだよきっとw >>170
この手のソフトはいろんな外注に出してるから作りが全部バラバラモジュールごとに作りが違うのもよくある >>173
分かる。
まさに直すべき所は直さず、整理しないまま作業して、見た目だけ問題を無くしておく。
多分あなたは悪くないと思うが、ジャップ流の仕事だよね。 >>157
というか、あの元号をイニシャルで表記する文化はいつからあるんだ？
あんなことやっておきながら元号にこだわるのはおかしいと思う。
民間役所レベルからは元号は極力排除でいいと思うが。
天皇と内閣の手書き書道くらいだけでいいよ。
ニュースとか教科書とかカレンダーとかは簡単見た目で直すんだから。
民間公文書の記入欄からは排除しろ。 おそらく>>171の人が負荷でかいつったのは、たまにデータ上の問題で画面遷移しづらい画面がいくつかある場合を想定してるのかも
しれないけど、単ﾃなら直接作ればいいし、それより上なら客にデータそろえさせとけとしか言えませんねえ >>174 >>177
そしてどんどん修正が難しいシステムになってゆくっていうねw 富士通って馬鹿なの？
プログラム動かすのは西暦で、和暦での表示を新元号に書き換えるだけだろ。
（笑） >>164
そうだよな。
西暦でプログラム組んでないんですか？って聞くわ。（笑） >>171
西暦でプログラム組むだろ。普通。（笑） >>169
普通そうするよな。
世界中でシステム組むんだろうし。 フジツー「洗い出しとテストの負荷が大きい」
客「は？なんで」
フジツー「バラバラに作って一ヶ所で管理してないから」
客「は？」
これはどちらが悪いか・・・ 下請けに丸投げするだけの糞がなに言ってらっしゃいますか >>29
和暦管理ってなに？
インプット時とアウトプット時に西暦に変換するだけじゃ済まないの？ >>183
それがいいと思うんですけどねー
和暦でないとあかんって客は
問答無用で切り捨てるのもアリかもしれないと思ったけど
どうだろう
そんな客リスクでしか無い気もする。 IT関連は全て西暦でいいだろ。
ウチは元号対応はしません。
西暦表示しか対応しません。
元号対応したければ、どうぞ外資系に頼んで下さいで良い。
外資系は物凄い金額を請求しそうだけどな。 こないだは「余裕で対応出来るっす」みたいに言ってたよね 官公庁で共通のライブラリ作ってそれを使えば済む話なんだけどな
車輪の再発明が好きな国民性だから無理か >>188
プログラム内部では西暦で処理して、画面に出すときに和暦に変換して出すんじゃなくて、
よく分からんけどさ、プログラムの内部の処理を和暦で処理してるとか、そんなのあんの？ 全然問題ねーよ
昭和→平成時にＩＴ業界で仕事中（全社共通カレンダールーチン担当）
まあ昭和の継続を選択した業務もあったが >プログラムの内部の処理を和暦で処理してるとか
何故か存在する。富士通でも多分あるだろうな。
年を西暦で計算する様に統一するのがセオリーだと
言われているが、（自分も、周りもそうしてる）
何故和暦で計算しようとしたのかは不明。
社内政治の問題かもしれん。
正直、赤字覚悟でも計算する時は西暦に統一するべきだと思う。
そのままにしていれば今日は黒字でも明日は赤字になるだろう。 どう考えてもこれで詐欺を働こうとしてるヘボが紛れ込んでるな カレンダー計算をわざわざ関数で仕込むから面倒なんだよ。
西暦ベースにして、あとは100年分くらいの
元号テーブルを参照させればいい。
元号変わったらテーブル差し替え。
どうせ100年以上も持ちこたえる
システムなんて無いんだからこれで十分。
つまらないことに労力かけるのが日本が敗退した原因 >>195
昭和から平成に変わる時点でこの世に存在する人間は
現場で働いているのだろうか？
そんな高齢者を受け入れる現場は稀有だと思われる。 ■ このスレッドは過去ログ倉庫に格納されています
