政府は2017年12月8日、天皇陛下の退位日を2019年4月30日に定める政令を閣議決定した。「平成」は31年までとなり、2019年5月1日以降は新元号に変わる見通し。
富士通は新元号のシステム対応について、「個別開発したアプリケーションの影響を特定する洗い出し作業に手間がかかる」（広報）と話す。さらに「元号改正による修正作業そのものよりもテストの工数が増えそうだ」と見通す。システム環境を2019年5月1日以降の未来日付にして、修正内容が正しいかを画面や帳票などで確認する。
http://itpro.nikkeibp.co.jp/atcl/news/17/120802832/ ,;:⌒:;,
8(･ω･)8 システムの移行は既存システムは保留でもいいんじゃないのかな
平成表記が続いても仕方ないと思うわ
システムの改変とか入れ替えがあるときに変えるスタンスでいいんじゃないん
元号の変更なんて最初から想定されるべきに決まってんだろ
今になってテストだの言ってんのはただのヘボ
システムの内容による
例えば契約書とか元号入りの書面の場合締結日に存在しない年が書かれてちゃまずいだろ
この程度のことに対応できない
ジャパンの技術者
そら世界に取り残されるわけだ
ゼロ始まりと1始まりとか普通に間違えそうだな
ほんとシステム屋さんは気が休まらない
平成になった時と比較したら準備期間が十分にあるやんけボケ
,;:⌒:;,
8(･ω･)8 昭和から平成よりも今はシステムが複雑化して大規模になってるからな
修正箇所は膨大でほかに及ぼすリスクの影響も大きいと思うわ
本気で言ってるなら富士通ってマジクソだろ
普通は前回の元号切替時に仕掛けを組み込んでテストまでしてるわ
以前陛下がご入院されたときに、Xデー対応確認をしたことがあるな
そもそも元号が必要なのはマンマシンインタフェースのところだけで内部は全て西暦で作れる
一体何が大変なのか全くわからない
銀行のデータとか、平気で和暦使っているよ。しかも元号なしで
政府が音頭を取って
みんなが目くじら立てない
という国民的合意を形成してくれれば
問題が起きたら対応で済ますことが出来て
IT業界が助かって売り上げが減ってうぃんうぃんうぃん
文字数が変わらない限りマスタに新元号のデータを追加したり、共通ロジックを修正するだけだろ。
と簡単にはいかないのがジャップIT。
>>3
しーっ
お客から（実際作業なんて何もしないのに）カネを巻き上げる一大チャンスなのだよ 2000年問題を過ぎて尚今更、
元号がかわると云々文句をたれ
時間と金をくれって
システム屋として屑
富士通もなんか虚偽的なことしてそう
いいなー西暦だけでやってける人たちは
どうやっても和暦管理しなきゃいけないシステムってあるからねえ
特に官公庁系絡むのとか
「元号の変更にあわせてソースコードを修正して」って命令すれば
ちゃんと直してくれるＡＩはまだないんだね
>>29
ただ君がダメなエンジニアだと言ってるようにしか聞こえない ○○1年と印刷されたら、それバグたから。
○○元年でないといけない。
>>31
悪いが君が小さいシステムしかやってないと思う そんなの西暦元号変換ロジック一箇所に記述するだけだろ
>>33
大変申し訳ないがあなたがやっている仕事がヘボなのだと思うね 平成になる時に候補に挙がった元号
修文 しゅうぶん
正化 せいか
永安 えいあん
乾徳 かんとく
昭徳 しょうとく
天興 てんこう
興化 こうか・きょうか
光文 こうぶん
完全に西暦で管理してて
表示するときだけ和暦変換した文字列をとってきて印刷に使う
ぐらいなら改修も簡単！
に見えても、そのモジュールを使ってる個所を全部リストアップして
全部差し替えないといけないしな
こういう何のイノベーションも生み出さない仕事をしている間に
中国や韓国にドンドン先をこされるわけだが
>>33
むしろ大きなシステムほどコンフィグ化してるだろw 2000年のような騒ぎにはならんけど元号絡むとこで場合により即時対応が必要なシステムは万が一の障害にそなえてるよ
いいよね、特に気にしなくていい層は
そこらわからん奴らとわかりあうつもりもない
どうせ子会社と請負こき使うだけのくせに、何が大変なんだか
大変さは年末にやったって年度末にやったって同じだろ
「明日から」が大変に決まってる
仕様から何から、全部下請任せだから何がどうなってるか分からんのだろ。
しかも、プロジェクトごとにライブラリやら共通関数やらバラバラだから、全部のシステムを
個別に直していかないといけないんだろうな。
>>40
オンコーディングするしか知らない奴をそんなにいじめちゃダメ >>1
彡⌒ ヾ
( ＾ω＾)こういう対応も有償扱いだろ、儲かりまんな >>1
彡⌒ ヾ
( ＾ω＾)富士通の奴はとんでもないプログラムしやがるから、信用できんわ >>44
あたり、わかってるね
1社じゃ対応できないシステムなんで5社ぐらい絡んでる
単体のシステムの元号変更なんて別に気にしてない 平成切り替え経験して、
事前に元号切り替え対応を汎用的に設計してないってこと？
嘘でしょ？？？
仮の元号でテストすりゃいいじゃん。安晋でも何でもいいんだからさ。
>>29
キャリア系の帳票無関係なサーバーサイドに偏重したシステムやってると和暦使うこと無いから完全に他人事だわ
一方で今時和暦使うのって大抵は官公庁系か金融だから客としても最悪の部類で明らかに不要なテストなんかもやらされるハメになるだろうから実際大変だと思う >修正内容が正しいかを画面や帳票などで確認する。
念のためにテストしておく、とかのレベルじゃなくてプログラム修正しなきゃならんのな。
どういう設計なんだろ。
テストは時間かかるだろうけど
シウテム設計がダメダメで移行できないかただお金ぼったくりたいだけでしょ
当然変更のテスト仕様なんかは過去の使えるわけだしアウトプット確認する時間や労力がほとんどでしょ
富士通もNECもNTTデータも自分らでは何もできず、
全て下請けに丸投げの糞企業らしいなｗ
普段はろくなテストやってないから洗い出しも出来ない
さすが富士通
>>39
しかも中国も韓国もとっくに元号なんて廃止してるし 面倒くさいからうちは西暦しか使ってない
もしくは国家全体を皇紀で統一しろ
お前らがシステム知らないのはわかった
本番環境あげるのに、テスト環境でテストしないで直にマスター改変できるシステムなんてあんの？
簡単、難しい関係なく本番いじるなら一度テスト環境でテストしないと申請もあげられないだろう
金融システムだとこうだが、いきなり本番環境いじれるシステムってどういう管理してるか興味あるわ
そら必死だよ
過労で死ぬからな
テストで忙しいのは耐えられるが、バカな客がドヤ顔で口出して来る対応するのは心底イラつく
彡⌒ ヾ
( ＾ω＾)そもそも元号をプログラム本体に使うとかアホだろ
彡⌒ ヾ
( ＾ω＾)caseとかで西暦と比較参照して処理に直接関与しないようにしとけば簡単な事だろ
元号いらんだろ
それだけで生産性がどれだけ落ちてるか
本番で出来ない環境だと普通はテストやデモ機の環境があるはずなんだけどね
２４時間稼働以外なら時間外にテストできるだろ
>>72
彡⌒ ヾ
( ＾ω＾)俺はずっと言い続けているんだけどな
彡⌒ ヾ
( ＾ω＾)昔と今は違う、西暦だけでよい >>72
IT産業にとっては一種の公共事業だからなぁ。
でもこういうことが重なって海外のクラウドにどんどん顧客が逃げていくことになりそうだな。 だいたい設計上はデータは西暦管理で出力や判定時だけ共通ルーチンで変換が普通じゃないか
元号改正に伴うシステム改変で数百億の見積り出すんでしょｗ
2000年問題の時と一緒で、またアホなエンドユーザーが要らん金払わされるのかな？
要約すると処理能力のない人たちには負荷が大きいということだね恥ずかしい
＞「個別開発したアプリケーションの影響を特定する洗い出し作業に手間がかかる」（広報）と話す。
＞さらに「元号改正による修正作業そのものよりもテストの工数が増えそうだ」と見通す。
「随意契約の請求金額水増し」の言い訳にしか聞こえない
>>15
渾身のボケがスルーされててかわいそうｗ
真面目な話、VBとかJavaの関数そのまま使って元号表示しちゃってる場合、
対応はランタイム更新待ち、
でも古いバージョン固定で指定してるアプリは更新されないわけなので対応不可、
みたいなことはあり得る。
どーすんだろねホントｗ むかし仕事してたときは、IBMなんぞぶっこ抜くぞ、と言ってた富士通がこれか
俺の疾患でなにもかも駄目か
>>87
彡⌒ ヾ
( ＾ω＾)富士通は大昔から大タコ でも、むかしNEC9801 NS/Tを使った、というだけで言いがかりで
疾患を負わされ仕事をしてない、首
富士通だと元号は完璧に対応して2038年にバグ出しまくるイメージ
俺の仕事なんかで元号を決めるのはやめてくれ
イタニウムは失敗してインテルで細々やってるらしいが、平成
>>68
なんでテスト無しであげると思ってんのかが謎w 元号はいらない 西暦に統一しろ
当たり前だろ 行政のムダを省け！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！
西暦なら変える必要はない！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！
国会でも問題にすべき
>>1
急遽変更となる場合は多少のミスは許されるかもしれないが、
今回の様に事前に変更日が決まっていると言い訳できない。
そもそも昭和から平成への変更と2000年問題を対応した経験がありながらその言い訳は酷すぎる。
平成対応世代の若手が今の部長級、2000年問題対応世代の若手が今の課長級になっていて
若手が老害と呼んでる世代がノウハウを持っている。 >>97
その前に元号はいらないから
野党は
「公文書における元号廃止法案」でも提出すべき
カスどもに儲けさせる必要はない。血税だという認識がなさすぎる
いい加減にしろ！！！！！！！！ 元号変更はいいが、
西暦と併記せよ。
いちいち西暦変換するのが
煩わしい。
そもそも今の時代に元号必要か？
西暦に統一せいよ
平成何年とか言われても分からんっちゅーに
>>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の人が負荷でかいつったのは、たまにデータ上の問題で画面遷移しづらい画面がいくつかある場合を想定してるのかも
しれないけど、単ﾃなら直接作ればいいし、それより上なら客にデータそろえさせとけとしか言えませんねえ 富士通って馬鹿なの？
プログラム動かすのは西暦で、和暦での表示を新元号に書き換えるだけだろ。
（笑）
>>164
そうだよな。
西暦でプログラム組んでないんですか？って聞くわ。（笑） >>171
西暦でプログラム組むだろ。普通。（笑） >>169
普通そうするよな。
世界中でシステム組むんだろうし。 フジツー「洗い出しとテストの負荷が大きい」
客「は？なんで」
フジツー「バラバラに作って一ヶ所で管理してないから」
客「は？」
これはどちらが悪いか・・・
下請けに丸投げするだけの糞がなに言ってらっしゃいますか
>>29
和暦管理ってなに？
インプット時とアウトプット時に西暦に変換するだけじゃ済まないの？ >>183
それがいいと思うんですけどねー
和暦でないとあかんって客は
問答無用で切り捨てるのもアリかもしれないと思ったけど
どうだろう
そんな客リスクでしか無い気もする。 IT関連は全て西暦でいいだろ。
ウチは元号対応はしません。
西暦表示しか対応しません。
元号対応したければ、どうぞ外資系に頼んで下さいで良い。
外資系は物凄い金額を請求しそうだけどな。
こないだは「余裕で対応出来るっす」みたいに言ってたよね
官公庁で共通のライブラリ作ってそれを使えば済む話なんだけどな
車輪の再発明が好きな国民性だから無理か
>>188
プログラム内部では西暦で処理して、画面に出すときに和暦に変換して出すんじゃなくて、
よく分からんけどさ、プログラムの内部の処理を和暦で処理してるとか、そんなのあんの？ 全然問題ねーよ
昭和→平成時にＩＴ業界で仕事中（全社共通カレンダールーチン担当）
まあ昭和の継続を選択した業務もあったが
>プログラムの内部の処理を和暦で処理してるとか
何故か存在する。富士通でも多分あるだろうな。
年を西暦で計算する様に統一するのがセオリーだと
言われているが、（自分も、周りもそうしてる）
何故和暦で計算しようとしたのかは不明。
社内政治の問題かもしれん。
正直、赤字覚悟でも計算する時は西暦に統一するべきだと思う。
そのままにしていれば今日は黒字でも明日は赤字になるだろう。
どう考えてもこれで詐欺を働こうとしてるヘボが紛れ込んでるな
カレンダー計算をわざわざ関数で仕込むから面倒なんだよ。
西暦ベースにして、あとは100年分くらいの
元号テーブルを参照させればいい。
元号変わったらテーブル差し替え。
どうせ100年以上も持ちこたえる
システムなんて無いんだからこれで十分。
つまらないことに労力かけるのが日本が敗退した原因
>>195
昭和から平成に変わる時点でこの世に存在する人間は
現場で働いているのだろうか？
そんな高齢者を受け入れる現場は稀有だと思われる。 昭和→平成を経験した者は、必ず内部は全て西暦４桁で設計している
表示に和暦が必要なときは共通ルーチンをコールして元号・年を得て「表示にのみ」使用している
共通ルーチンはダイナミックリンクなので共通ルーチンのテーブルさえ修正すれば
リコンパイルの必要も無くそのまま使える
>>201
現場に居なくても共通ルーチンのテーブル変更だけなんだよ
誰でも出来るし、俺の居た会社は「全社共通の１本」だけ 実は、ソフトの対応はとっくに終わっている。
消費者に喚起するのが企業としての役割。
2000年問題では、富士通は、対応手法を特許にとったが無料で利用をした企業。
今回の問題でも、ユーザー側がパニックにならないように事前に周知させるのが大事だと分かっている。
下請け、孫請で人を大量調達して、人間単価に粗利2割積むだけのお仕事。
元号を使わなければいい。
役所が止めればみんな止められるよ
X 2000年問題では、富士通は、対応手法を特許にとったが無料で利用をした企業。
O 2000年問題では、富士通は、対応手法を特許にとったが無料で利用をさせた企業。
だいたいコンピュータの時刻表示が
デフォルト西暦なのに
わざわざ元号に変えようとする思考が分からん
>>3
元号マスタテーブルじ新しい元号登録するだけやんけ
今すぐにでもできる 普通に西暦をもとに新年号を合わせれば良くない？
無理かあの富士通だもんな
で？いくら（笑）
西暦に変換するのが面倒だから和暦のまま計算しちゃえ
というクソプログラムがないとも限らない
>>192
言ってたやつはそのポストから外れたんだろ 理由は「当時の社員と仕様書が残ってないから」
頑張ってコードを精査してくださいｗ
>>210
元号マスタないやつあるんだよなあー。平成以後に作られた統計を取ってるシステムや
そのデータを後続で取り込んでるのがね。それもホストレベルでw
最低でもテーブルレイアウトとロジック変更は確実だし、今更マスタ作るかもね。
難しくはないがデータ移行と無影響確認で時間は取られるだろうな。 客はちゃんと相手の怠慢を指摘するような議論をしないといけないですよ。
レビューしてないんですかとか作業者を問い詰めないと
いや、別に平成がでてもいいじゃんそんなに気にすんなよ。
仕様書を探すのもレビューするのもテストするのもいいけどさ
それ全部あんたらの作ったシステムの瑕疵だよ
>>219
うん、実際に昭和→平成の時に昭和を続ける決断をした業務があった これを機に新システムやハードの移行を売り込みたいだけでしょ
元号使うのは法律でそうなってるから
もう散々頭のいい奴らが元号廃止しね？って検討し続けてるのに廃止できないのは
問題がシステムではなく法律と契約の話だから
そこを理解せず無関係の人間が元号なんてマスタ変えればすぐだろとか言い出す
元号が変わるなんて1000年以上前からわかってる事なのに
富士通の偏差値っていくつなんだ？
>>223
プログラム内部の処理を西暦じゃなくて元号や和暦で処理することまでが契約になってる
ってお前は言っているの？ 最近、大企業のリナックス開発手伝ったんだが、
同じPC内のデータをやり取りするメッセージの構造体が、
ソースコードファイル毎に定義されている事が分かった時は笑ったぞ。
富士通レベルでもリナックス系統のコードは昭和、平成表記の定義値が、ファイルごとに定義されているんだろうなぁ・・・・・。
アホみたいなコーディングルール作ってる暇があったらルールの一行目に和暦の使用禁止って書いとけ
>>225
そもそも元号廃止しろよに対する反論
システム的には元号で契約書印刷および送付するシステムとかきら元号表記は無くせないだろという主張
新元号ぐらいシステムで簡単に対応できるだろ無能論と、
すでに平成開始か2000年問題の時に対応してるだろうには反論してない
レガシーシステムでドキュメント散逸してて洗い出しが大変とかにも反論してない
このすれだと、元号廃止過激派と、ロジック対応してて当たり前派と、テストなんて簡単にできるから工数そんなにかからないだろう派ととかぎそれぞれ自己主張してるから噛み合わない
ITの打ち合わせ並みに議論が噛み合わない 2000年問題の時に大騒ぎしたのに、元号の変更に対応してないシステム作ってるって何なの？ｗ
>>229
そりゃ2000年問題以前から継続してる一子相伝のソースだからだろ まぁ天皇陛下が退位日前に突然崩御され、またやり直しとかなったりｗ
新元号を5月1日からにすると、
法案附則に「この法律は平成31年4月1日から施行する」と記載できる。
それに「平成31年度予算案」も堂々と国会に提出できる。
昭和→平成のときは、「昭和64年度予算案」を「平成元年度予算案」として出し直したり
それぞれの法律の施行日を改正する法案を通したりと面倒だった。
じつのところ、5月1日に決めた理由はそんな立法府と行政府のご都合なんです。
簡単ではないだろな
だから元号を決める話題がこうして先行して出てくるんだから
怪しいおこめセシウムさんみたいに架空のデモデータで開発進めるしかない
>>2
そう思う
即時対応する前提でギャンギャン騒いでるけど何で？
徐々に変えていけばいいだろって ５次請け「マスターに１つ追加するだけ、でもまあ最小で１人月では注してよ」
４次請け「５次請けに１人月でうちの管理工数他マージンが１人月必要」
３次請け「４次請けに２人月でうちの管理工数他マージンも２人月必要」
２次請け「３次請けに４人月でうちの管理工数他マージンも４人月必要」
１次請け「２次請けに８人月でうちの管理工数他マージンも８人月必要」
富士通「元号替えるだけでも16人月もかかる。負荷が大きい」
>>236
なまじ事前に決められてるから完璧を求められるんだよなあ
システム開発側もそれが分かってるから影響範囲の洗い出しとテスト工数がネックだと言ってるわけで
修正3秒テスト一週間とかままあることで 来年、運転免許の更新なんだけど、「平成35年まで有効」って記載になるのかな？
実際、新元号っていつ発表するのかね
まさかそのときまで決めない発表しないってことはないよね
>>243
元号を形式的に使うのはかまわないんだけどね
実務は西暦でさせて欲しい >>242
流石に丸一年前には発表して欲しいが、「当日発表をわくわくしながら見守りたい」とか言い出すアホが世の中にはいるんだよなあ… >>244
元号自体は残してほしいが書類とかは全部西暦にするべきだよな、やっぱり 勤め先の会社の日付印、西暦下二桁と和暦が混在してるｗ
「16.12.-9」って捺してあると、2016年か平成16年かわからない
まあ、書類の内容を読めば分かる場合が多いけど……
批判が高まるからそういうことは絶対しないだろう、学者がそれを持ってきてもやり直せ、というはずだ
MTSHなどの頭文字とも違うものにするはずだ、とにかく元号を続けたいから、
わずかでも批判されそうなことは可能な限りしないと思うね
政府は元号を使わないとならない。
そういう法律があるから。
>>1
レス全く読まないで書き込むが、普通、参照元のテーブルやらファイルを書き換えるだけでイケるように設計するだろ？そんな低レベルなこと言ってて驚いたわ この切り替え時期に役所や銀行行って色々出してバグチェックする楽しみもあるぞ
元号なんか数十年に一度しか変わらない要件をわざわざ考慮するのもおかしな話だな
>>152
聖武天皇は法律違反したんか？
17条しか憲法なかった時代やけど >>164
法律の改正には対応とか契約にあればとにかくやれ世の中にはユニシスもあれば沖電気もあるんだよ。とムリヤリやらす。 今の現場は、西暦を渡すと邦歴の年号と年を返す仕組みだから、
何の苦労もない。テストはするけど洗い出しはいらん。
Fはご苦労なこった。
修正は簡単だが元号が出力される画面と帳票の洗い出しと確認は(ちゃんとした仕様書なんて無いしあっても紙だしで)それなりの時間がかかると言っているだけ。
簡単ですなんて言ってる手配屋と現場で怒鳴られてる本物の土方親方との差がコメントの差。
仕事増えるんだからいいじゃん
有償サービスとして修正しろ
日本がこんなことをやってる間に世界はもっと先へ行っている
>>125
彡⌒ ヾ
( ＾ω＾)世の中は変わったんだよ
彡⌒ ヾ
( ＾ω＾)コンピューターでの運用は西暦と記述すればよい
彡⌒ ヾ
( ＾ω＾)必然的に役所の印刷物も西暦になる >>264
通常のメンテの枠内にすぎんがな
こんなので大変とか言ってるなんて実力が無いって告白してるようなもの >>268
彡⌒ ヾ
( ＾ω＾)元号が変るのは絶対に有るので
彡⌒ ヾ
( ＾ω＾)ワンタッチで変更できるようにするのが常識だよなぁ
彡⌒ ヾ
( ＾ω＾)こんなんでプログラム修正とか、カネなんて払えんわ ＞個別開発したアプリケーションの影響を特定する洗い出し作業に手間がかかる
いつ作ったシステムなんだよ
対応できるように設計しとけよ
>>252
この機会に、その法律を改正して欲しいところ ガソリンスタンドの給油機とトラックの安全何たらとかステッカーって平成31年以降で平気で書いてあるよな。
>>16
実はその時にお隠れになってしまい、
いまは複数の偽物がやってるという
比較画像つけたサイト見かけたな。 >>6
日付の表示形式で和暦関係のはアップデートされるね。 どうせ富士通は仕事だけ受けて金だけかすめ取って下請けに丸投げするだけだろう
下請けになる身にのも考えろ
安い日当でこき使いあがって
(´･ω･｀)これを機にシステムで和暦使うの辞めようや
つーか、いつでも変えられる仕様に最初からしとけよｗ
そのうちアルファベットも足りなくなるね。
桁増やすんかな?
F が運用保守してる全てのシステムで新元号への対応を確認するのはかなり
大変な作業だと思うよ。
一つの大規模システムは複数のサブシステムで構成されていて、それぞれで
和暦変換のロジックもマチマチ。
日常的に行う作業じゃないからどのマスターテーブルにどういうデータを
書いて対応するのかも調査しないとわからないだろうね。
開発当初は和暦変換共通ライブラリーで新元号に対応できることを確認できて
いたとしても、度重なる改変とメンバーの入れ替わりでそのライブラリーを
使っていないソースがあるかもしれない。
>>280
変えれるようには作ってあるが、「2019年5月1日から新しい元号」って定義の追加は必要
そして、試験するのが大変
いやー、まいったまいった、全部の帳票がちゃんと出力されるか試験しないと
それだとコレだけお金かかるなー、いやいやたいへんだなーー
ってな感じ >>32
仕様は、
平成元年 たただし略すときは、H1となっていてプログラムが面倒だった。
あれから30年か・・・ >>283
そういうみっともない言い訳しないでくれよ
一体いつの時代のエンジニアだよ いわゆる単純労働は単純じゃないし、
いわゆる知的労働は単純だという話。
1件あたり1時間くらいの作業だろ？
ジャップにとっては難しいのか？
>>289
一時間他の作業出来ないだろ？
損失じゃん >>286
お前、シロートだろ、富士通がいつからあると思ってる？
お前の会社みたいに創立数年じゃないんだよ。
作った人が全員鬼籍に入ったような生きた化石みたいなシステムだってあるんだぞ。
それを現代の人間が洗い出すんだぞ。
現代では簡単に実装できることでも、当時もそうとは限らない。
>>13
＞修正箇所は膨大
ｗｗｗｗｗｗｗｗ
お前がそういうクソコード書くのは分かった。
>>5
そんなあほなｗ
契約書なんて締結前にプリントアウトして署名捺印だろ。
文面が自動で生成されるような電子書類の、これにまま電子署名して契約書？
絶対無いとは言えんが、それやってそういう問題が起きたら、
それはそういう使い方をした側の問題。
>>291
歴史ねえ、所詮昭和じゃないか。
平成になった時きっちり対処できてれば今回だって問題無い筈。
・従前のコードを見直す
・以降の開発では元号変更を前提として作り込む
もしそんなに大きい問題が頻発したなら、
平成に入っても、昭和の時と同じように、
元号変更を意識しない作り方をしていたって宣言するのと同じｗ
俺が発注者だったら、元号変更なんか開発項目に入れたら削除させるけどね
削除するのは構わんがそんな請け負ってない仕様はオタクで勝手に直してくだしゃんせ？
って言われて窮地に陥るわいよ
プログラマにとっては朝飯前でも経験不足のパンピーじゃ
ソースから和暦のカルチャ情報すら見つからないでエンドだろ
腐ってもプロにおまかせ
生前退位というものが考えられなかった時代においては
元号の変更というものが発生する状況は
それすなわち天皇陛下の崩御を意味することであって
最大の忌み事とされた
いまでこそ国民の価値観が多様化、そしてそれが容認化され
かつてのような行き過ぎた天皇信仰はなりを潜めたが
1980年代はまだまだ頭の堅い人間が上に陣取っていて
元号変更をシステムに盛り込むなどと言ったら
天皇陛下様への敬意が足らないということで
目の敵にされたであろうことは容易に想像できる
それに当時はコンピューターのスペックもそこまで高くなく
必要最小限を超える余計な機能は嫌われた
もちろん、戦後日本は天皇崇拝を義務とする国家体制ではなくなった
ので表向きにあれこれ言われることはなくなった。
だがそれは建前というもので、1980年代どころかつい最近までは
そのような話題を口にすること自体憚られたのである
口にすることすら忌まれるのであれば
システムとして盛り込む事なんて尚更である
1989年のシステムにそれが実現可能だったとは思えない
2000年問題でこの手の案件は終わったハズなのにｗ
富士通は無能だなｗ
ITと元号って相性が悪いのは確か。
仕事では、もう西暦に統一してほしい。
その前に崩御したら、翌日から新元号だぞ。
何を今更って感じ。
新元号対応ってのは
Windows OSだと
メインストリームサポート案件なのか
それとも
延長サポート案件なのか
どっちだろうな
Windows7は既に
メインストリームサポート終了してるから
延長サポート期限は2020年1月14日まであるけど
新元号対応しなくても
OSの脆弱性に関わらない問題となれば
新元号対応しない可能性もあるよね
つまりWindows7は
実質的に2019年4月30日で
元号使う人向けのサービス終了ってことになる
まぁ30〜40年前に作成したプログラムが動いてるからな。
その頃は元号改正なんて考えて無かった。
そうなると対応に和暦を潰して西暦にしてくれってのも当然あるんだよな
これまでのデータも変換したいって要望も出てくる
>>1
検算みたいな作業だが必要だからな(´・ω・｀) >>303
彡⌒ ヾ
( ＾ω＾)単純なパッチ程度のものだ
彡⌒ ヾ
( ＾ω＾)サポート終了したものでも対応するものは多い・・・MS そういえば日本の下請に海外の企業が入ることって激稀だよな
やっぱりオタクとは仕事できないって断られてるのかな？
官公庁の書類が全て西暦になれば日本の元号問題も解決する
>>291
全くお話にならない
本当にこれなら富士通のレベルの低さヤバイな 大変なのは常に動いてるシステムだろうな
例えば硬貨には元号が入ってるが元号発表の後に急いで変えなきゃならないんじゃな？
富士通とかそのあたりやってるのかもな
プログラムが大変とかじゃなく万が一でも不具合起こさないための洗いだしとテストが面倒
下っ端「そんなソースも書けないの？」
SE「ソースとかじゃないんだよなぁ」
>>3
システムが大きい事と技術力が高いとは無関係なのだよｗ >>312
ｗｗｗ
ジャップITってほんとレベルが低いね
洗い出しとテストｗ手動でｗｗ 悲しくなるよな
こんなんマジで書いてる奴がいるとしたら
あほかよ。
もし今天皇が死んだらその大変な作業は今すぐやらなきゃいけないんだぜ？
前もって退位がわかって時間をもらってるというのになんという言いぐさ。
年号の変更の影響なんて、設計時に考慮して、
それをそのままアプリのテストの仕様書に反映するんじゃないんかい。
年号が変わるときに洗い出しとか、真面目に仕事してる？
「お金がかかります」という理由付けとしか思えんが？ｗ
それに、修正作業なんて、文字数同じだし、一瞬で終わるでしょ？
まさか、ソースコードに「平成」という文字列がそこらじゅうにないよね？ｗ
SIerに就職してすぐに昭和→平成の対応をした記憶があるが、
具体的に何やったか全く覚えてないわ。
社内見ててもテスト云々で大変そうなのは分かるが、
それしきの事にそんな時間かけてて世界相手にやってけいけるのか？ とも思う
>>291
昭和→平成の対応を力業で乗りきったプログラムがまだ動いてたりするからな。
DBの中身が（昭和)90年なんてのもしぶとく生き残ってるし (*ﾟ∀ﾟ)この機会に西暦に統一しまーす!
(*ﾟ∀ﾟ)するとこの誕生日の元号に○を付ける自作のコントロールはどうしましょう？
( ﾟдﾟ)・・・
( ‘д‘⊂彡☆))Д´) ﾊﾟｰﾝ
天皇が換わるたびに
超絶無駄な作業に忙殺されるのか
日本の凋落が止まらないのも道理
>>302
確かにw その可能性はゼロではないからなぁ… >>295
おまえんとこは平成35年とか平成40年とかで帳票出力し続けるのか(笑) It系のカスどもはこれを理由に
新しいシステム導入しろとかボッてくるんだろ
怒鳴り付けて格安の値段でやらせてやるわ
>>308
うちの職場にアニメが好きで日本に来たフランス人が入ってきたぞ >>329
人手が足りないから安くでは請け負わないよ
もう時代が違うんですよ、爺さん >>308
あれをああしてうまく動くようにしてくれ。でわかる能力がなうからな。 通常は急に変わるから「後手の対応」でそもそも考え方が違うのかな
>>302
その時は「限られた時間内で最大限のテストをします。」と言える
今回みたいに時間的に余裕がある時に
「100%大丈夫な事をテストで確認しろ」とか言われるとテスト費用と時間がとんでもない事になる 西暦使うのを禁止すればいい
文句いう非国民SEは死刑でいいよ
そんな暴君みたいな事をしたらお前が真っ先に一般人に処刑されるだろうがねｗ
ていうかさ、元号を強要するのが愛国とか頭おかしいから。
本当に優れた良い為政者なら、かつては意味はあったかもしれないが、現代においては国家国民のためにも、
元号の強要は否定的になるのが当然だと思うけどね。日本が今も専制君主あるいは封建制度でかつ、
その人が優れた人ならこんなものは確実にやめさせてただろう。
国のためにならないし、国民にこんなものを押しつけるのは名君ではないと言ってね
いいか？
自分でなおせばただなんだぞ？
治せない？ならこっちの言い値を金払え
天皇が突然死して、システムが突然死。エンジニアも突然死。会社も傾いて突然死。
西暦で。
とりあえず、影響あるのは金融システムか
誰かも書いてたけど、全銀とやりとりするところは和暦あったな
今日見ておく
お金は重要だからな
西暦から和暦に変換するところは問題ない
官公庁や金融機関と外部データをやりとりする中に、和暦を使ってるところはある
そしてそのまま西暦変換せずにDBに入れてるのはあるかも
並び替えに使ってる場合は要注意だね
和暦でやりとりするってありえんだろと普通は思うが
それを平気でしてしまうのが日本のIT
>>343
いや、米国だって昔はやってた。
ただあそこはシステムをイチから作り直すことが多いから、どこかで直せる。
日本は現行通りだから、昔の考えてないソースが残ってる。 平成がハードコーディングされているシステムってあるのかな？ ｗ
流石にマスタ更新で終わりだろ
元号ベタで使ってるシステムなんてみたときない
>>283
導入時に和暦変換箇所のテストなんてすんでるはずだろ >>348
当たり前じゃん
元号をベタ書きしてる訳なくてマスタ管理でしょ
マスタ更新で元号が切り替わるテストをしない訳がない >>1
いやいやいや。
元号って明日変わるかもしれないのに
何を言ってるのか理解できません。 官公庁とか金融で元号マスタに対応してないとか和暦でデータ管理してるなんてレガシーシステムをリプレイスしてないなんて美味しい話がある訳ない
ベンダー:元号変わる時のためにその点も含めて要件決めますよ。
顧客:そんなに直ぐ変わんないから決め打ちでオケ。
で、今に至ると。ウチの会社なんだけどね。
ユーザ部門も謎のシステムで業務回してるし、調べんのマジでキツイ。これに増税タイミングが重なるとホント困る。
今日わかったこと
和暦を使ってるとこ調べないといけない
しかし、どうやって全て調べるんだろ
元号マスタって大層なものではないけど、西暦を引数に和暦を返す関数があるのでそれを修正します
明治〜平成で４択しかないけども、皆さんとこはテーブル化してるの？
振込振替は和暦６桁でくるから困るね
平成と新暦が混ざったらどう判定しようか
お金のやり取りがないシステムは関係ないと思うけど
クレジットは大丈夫そうだった
こっちは悪くなくても貰うデータが和暦の場合もある
しかも元号のない和暦
>>321
昭和100年問題がマジで心配。
プログラムよりデータの更新で問題が起きそう。 結局Y2K問題とか何もなかったし、金巻き上げるために叫んでるだけだろ
変更しなきゃいいじゃん。
そうすりゃ無償。
修正液とハンコで対応。
修正作業ってのは、元号の文字列を変更するだけのこと。
テストはその元号が正しく表示されるか確認すること。
元号が使われてるあらゆる画面、帳票を確認しなければならない。
まあ、正しく動くとは思うけどやらないといけない。
