197
藤原かずえ @kazue_fgeewara
毎日新聞 元号の変更に伴う官民のシステム改修は短期間での綱渡りとなり、混乱を招く可能性は少なくない 30年も猶予期間があったのにITはまだ年号のモジュール化ができていないのですか。元号がすぐにわからないと生活に困るという実例を挙げて下さい mainichi.jp/articles/20190…
ykamita @ykamita
@kazue_fgeewara いつ改元かが分かってるんだから新しい元号が何かが分からないと改修出来ないなんて言うシステム屋なんかと付き合うのが間違い
ナウいヤング!(^^)!チョベリグ @nauiyangu
@kazue_fgeewara >年号のモジュール化 そこです。昭和時代には実感がなくても、平成元年に気付いていないとおかしい話しです。
@J IN9973 @In9973J
@kazue_fgeewara 本当は、元号廃止を主張したいが、文章力と反発への対応根性がないから、こういう文章になる、のが少なくない。 それにしても、現場の取材くらいしてから書けよ。取材費は中国から出るでしょう。反日系のネタみたいな。
草柳 昭貴 @morality_slave
元号とはいずれ変わるものなわけで、それを考慮してないシステムを設計・構築すること自体、無能なエンジニアだと思う。 新元号は4月1日発表 現役エンジニアからは懸念も(BuzzFeed Japan) - Yahoo!ニュース headlines.yahoo.co.jp/hl?a=20190104-… @YahooNewsTopics
REC @rebasashi_ism
新元号の発表が遅いと騒いでいるが、本来改元は崩御と共にされる。その際は当日の発表となるわけで、1ヶ月前の発表でも異例中の異例なのだ。それに対応できないシステムなんて、最初から破綻している。その程度のイレギュラーくらい想定してナンボだろ。いつからそんな我が儘になったんだ?
REC @rebasashi_ism
新元号の発表についてギャーギャー騒いでる連中は、主にシステム屋以外の印象。ごく普通のシステム屋は、改元程度でそんなに騒いだりしない。騒いでいるのはシステム屋以外、主に役所の連中。システム屋が騒いでいたらただのバカ。印刷屋なんて逆にウハウハだろ。
クレーム処理入門 @e2rRKfZZ4hiQlyH
> 社内システムを担当するエンジニア(31歳女性)はこう憤る。 なんでこいつら嘘記事書くんだろう? そもそも事前に知れるのが異常で、天皇がいつ亡くなっても良いように設計してるから問題ない。明日の可能性もあるのに。 新元号は4月1日発表(BuzzFeed Japan headlines.yahoo.co.jp/hl?a=20190104-…
un1d0n @un1d0n
新元号へのシステム対応はすでに準備されていて、あとは決まったら新元号を登録して、正しく出力されるか確認するだけの状態にしてあるか、している途中だろう。もし、いまだに準備を始めていないならその経営者や所管の責任者、システム部門は間抜けというほかない。
杉本悟 @sugimoto_satoru
今のシステムは日本の元号は変わらない前提で作られているのか? 信じられないことだ? 新元号は4月1日発表 現役エンジニアからは懸念も(BuzzFeed Japan) - Yahoo!ニュース headlines.yahoo.co.jp/hl?a=20190104-… @YahooNewsTopics
ariruted @ariruted
なんで元号を事前発表しないことに文句を言っているのか? 退位などなければ、本来なら事前発表されることではないことは分かっていることではないか?そういうことを考慮してシステムを作っておくべきではないか。 headlines.yahoo.co.jp/hl?a=20190104-…
John_kit_tea @John_kit_tea
「天皇陛下の退位が決まって以降、各システム会社は影響範囲の確認を進めてきているはずです。消費税と同様、元号は変わるものだという意識はある。よほどのことがなければ、適切に変更できるようになっていると思います」 これなんだよな。
まりも3号 @gyappa36
元号なんて明日にも変わる可能性があるのにシステムに関しそのケースの議論がないのは何故なんだろ?新元号は4月1日発表 現役エンジニアからは懸念も(BuzzFeed Japan) headlines.yahoo.co.jp/hl?a=20190104-…
シーランド公国伯爵賀茂花梨 @kamosinensis
コンピューターのシステムについても、元号が変わることなんて想定されてしかるべきだったのだし、そもそも改元を想定していなかったシステム会社の問題であって、元号の公表時期がそれに左右されるというのも理由としてどうなのだろうかね。
夏恋♪ @totoro081295
元号が変わるくらいでシステム改修しなきゃいけないのってシステムとしてダメだよね 元号って不定期に変わるものだし
In Need of a Break @tableSalt0117
「元号が何になるか直前までわからないとシステム屋が困る」説がもっともらしく回覧されている国の技術水準に新年早々不安を覚えるなど。
_y_s @_Y_S
新元号の発表が1ヶ月前ですらSEが大変とか言ってるシステムって利用価値あるの?条件分岐1つ増やすだけじゃん… もし譲位じゃなく崩御からの改元とかなったらSEも一緒に死ぬつもりだったの?
ロック @iwarock21
新元号、4月1日公表を表明(共同通信) - Yahoo!ニュース headlines.yahoo.co.jp/hl?a=20190104-… 1ヶ月で何とかなるのか! って騒いでる人らは本当にシステムに関わる人らなのかは分からんが 和暦、元号をシステムに組み込むから改元処理もあらかじめ積んでるから検証は1年もあればどうにかなるって話。
虚実歴史、漢字論、固有名詞問題、昭和平成懐メロ、元号の話 @kyojitsurekishi
このコメントには同感。 rap***** >そもそも改元が迫ってからシステム改修ガー、とか騒ぐほうがおかしくない?今回はたまたま今上天皇が譲位を表明して改元の日付が事前にわかってるから、元号はよ!とかなってるけど、本来和暦なんかいつ変わるかわからない性質のものなんだから、…
虚実歴史、漢字論、固有名詞問題、昭和平成懐メロ、元号の話 @kyojitsurekishi
rap***** >システム設計の時点で簡単に改元対応できるようにしておくべきでしょ?仮に譲位が無かったとして、おまえら平成があと何十年続くと思ってたんだよ、って話。 >もちろん陛下には長生きして頂きたいのですが。 「4月1日」決定打はウィンドウズ更新 新元号公表日(産経) - Y!ニュース
がっでむ @goddem123
元号は話が逆で、そもそも変わるときに発表するのが本来だから・・・。 で逆なのでシステムはむしろ対応しなくていいんじゃないの? っていうか元号って変わるものなのに変更できるようになってないシステムのほうがおかしいんじゃないの。
きむらー🐣 @negitoro503
だからなんでシステムに元号を組み込むんだよってば。元号はラベルにすれば瞬時に対応できるんじゃないの?日本のシステム開発っていつまでこんなショボいの? という感想しか出てこないんだけど実際のところどういうことなんでしょうね。騒いでる人がショボいだけ?
祭文 @myth_of
みんな、せっかちだな。なぜ、新元号発表をそう急ぐのか?システムがー、なんて言い訳でしょ? もう1年も前から、「変わる」ということがわかっているのだから、いくらでも手の内用はあるはず(西暦統一を含め)。
やどかり隊 @S7UKz9isd8xLrER
そもそもシステムの開発段階で日本の元号が変わったときに簡単に修正できる設計をしておけば済む問題なんですがね。 システム屋は仕様以外のことはしません。 #虎8
残りを読む(17)

コメント

yuki🌾4さい⚔ @yuki_obana 2019年1月8日
仕様として要求されないものをつけるならそれなりの金を積んでおけ、以上だ(´・ω・`)
数奇屋勝手屋 @korekuutokooru1 2019年1月8日
そもそも自社開発とかでない限りシステム屋が備えてなかったんじゃなくて、おおもとの企業が備えてなかっただけの話のはずなんだが……。自社開発の場合も人的・時間的猶予があったのかって話もあるわけでとても近視眼的な意見
dag @digital_dag 2019年1月8日
前の会社は改元を考慮に入れたシステムだったしサマータイムまで完備してた。改元でシステムがって言ってる人は本当にシステム屋さんなのかね?
たし @punimuchiya 2019年1月8日
「新元号を登録して、正しく出力されるか確認するだけ」のことにどんだけの労力がかかると思ってんだこの素人どもは
聖夜 @say_ya 2019年1月8日
そもそもカレンダーは1月1日、スクールカレンダーですら4月1日から使うもので印刷や発売はそれ以前だというのにどうやったら対応できるというのか。年の半分以上を間違った元号のカレンダーで過ごすのは不敬ではないのん?
dag @digital_dag 2019年1月8日
punimuchiya 素人なんで分からんから詳しく教えてくれ。
dag @digital_dag 2019年1月8日
say_ya 俺が昨日会社に支給されたカレンダーは昭和93年とか書かれてるんだが
なにぬねののこ @game_achi 2019年1月8日
昭和の時代にこんなに一般家庭にも普及するほどPCはありましたか…?
tanasinn @tanasinn88 2019年1月8日
俺の知ってるとこは仮の新元号でテストまでやってあるけど正式な新元号で充分テストしないと対応できたとは言えない。 上に訂正シールを貼るのとは訳が違う。 バカ政府と軽く考える物言いをする輩は、この手の混乱を最小限にしよう、国民に負担を掛けない様にしようとお考え下さった天皇陛下のお心を踏みにじる奸臣にして逆賊。
おろろ @fYe39CoQsPrbZVK 2019年1月8日
digital_dag いつ開始でいつ終了か分からんし、外部システムが対応してんのかしてないのか間違ってんのか分からん状態で「サマータイム対応済みです!」て報告するエンジニア抱えてて、お前それ信じてるんだろ?お前のところは大丈夫だ、問題ない。今エスパー抱えてない現場の話なんでどっかいけ
dag @digital_dag 2019年1月8日
fYe39CoQsPrbZVK 具体的なものがないならいいや。お疲れ。
tamama @tamama666 2019年1月8日
digital_dag ある自動車メーカーの開発したディーラー向けシステムは元号対応で2月にメンテナンス予定ですしねぇ 今まで年だけプリントして用紙に元号印刷してたのをようやく元号もプリントするシステムに改修されます 現実はこんなもんですよー
案山子 @Scarecrow_AP 2019年1月8日
新年早々にあったエクセルの不具合の原因を考えるとなぁ…
哲学的会計士 @AnteaterTamerAC 2019年1月8日
無能は必ず存在するので、無能でも大丈夫なように配慮するのが有能なやり方なのでは。
たし @punimuchiya 2019年1月8日
digital_dag [c5831982] パッケージならアップデート受けて検証しなきゃならんし、内製なら処理系、データ、フロントでそれぞれ西暦元号紐付けしてる箇所ごとに最低限一機能ごとは確認しなきゃならんし仮に例えば保険とかの古めで長スパン日付計算のある業務なら計算ロジック検証は一通りやっておきたいし、マクロなんてあった日にはOAにWindowsパッチあててから検証しなきゃならん
お豆さん @feijao0131 2019年1月8日
他人の作ったシステムを対応済みにする魔法なんて使えないし
たし @punimuchiya 2019年1月8日
punimuchiya 検証の結果仮にプログラムに手が入るともなれば他の業務機能改修をどっかのタイミングて凍結しなきゃならんしその調整もユーザ含めて合意を取らなきゃならん。そしてこれらのタスクの洗い出しをするだけで中規模以上ならそれなりの労力だし、その労力のために予算立てて承認受けるのに更にすげぇ労力がかかるね
以前敵 @izenteki3y 2019年1月8日
私は現場離れて久しいので偉そうなこと言えませんが、 モジュール化とかそんなの知るか全部検証しろというシステム部の人とか 罫線ぎちぎちの帳票で NNN99年99月99 日 となると発狂する人とか 古臭い現場だったかもしれないけど
dag @digital_dag 2019年1月8日
punimuchiya それだけの労力しか必要ないのかという印象だなぁ。元号が変わる事を考慮したシステムであること前提の作業でそれだけならまぁそんなもんだろとは思う。
以前敵 @izenteki3y 2019年1月8日
[c5832132] コード上で大丈夫だから検証しなくていいよっていうユーザはうらやましいですね
たし @punimuchiya 2019年1月8日
digital_dag 素人の印象論だとそんなもんなのかもね。俺も他の分野じゃそんなもんだと思うし
おろろ @fYe39CoQsPrbZVK 2019年1月8日
まあこういうのにエンジニア側から警鐘鳴らしてやるサービスも辞めたらええんやろな。問題出たら当時の要件に含まれていませんでしたので。で切ればいい。そっから機能追加で金取ったらええねん
dag @digital_dag 2019年1月8日
punimuchiya 少なくともその作業内容だけなら発表から実際の改元までの1月で作業が終わらないという事はなさそう。もちろんシステムによるんだろうが。
以前敵 @izenteki3y 2019年1月8日
[c5832173] そりゃあそうですし、クソ案件しかなかったですし…
tamama @tamama666 2019年1月8日
digital_dag ただ改修費用をきちんとクライアントが払う前提ですしねぇ 払わない(払えない)クライアントや渋るクライアントだと当然、作業に取り掛かれないのでタイムスケジュールは厳しくなるし、そもそも何十年も前のシステムでもう作った会社がないとか、仕様書がない、下手するとソースすらないとかあるので…
dag @digital_dag 2019年1月8日
tamama666 そりゃもう改元の問題じゃなくなってるしなぁ。
よず @sp1185 2019年1月8日
元号だけじゃなくて「元年」問題もあるし、汎用機系はもう何十年も動いているプログラムがあるし、ちょっと稼働させるつもりがいつの間にか重要なシステムになることもあるから無能と断定するのは乱暴に感じる…
たし @punimuchiya 2019年1月8日
digital_dag その素人の「そんなにかかることはなさそう」というのは分野に関わらず全くあてにならないから、まかり間違っても実際の現場では言わないようにね。馬鹿にされて終わりだから
ねこ博士 @kazukazu_ex 2019年1月8日
仮の名前おいといてあとから置き換えるんじゃ駄目なの?(´・ω・`) #素人質問で恐縮ですが
rice_of_sato @gohan_of_sato 2019年1月8日
他システムとのIFをいくつも抱えてるシステムだと、自分のところのシステムはオーケーでも後続に流して後続側で問題ないかの確認も必要だしな
east @1963_east 2019年1月8日
しかし他所のよく知りもしない業界について、よくもこう簡単にバカだの無能とか罵れますなあ(遠い目)
ぷりん @printai100 2019年1月8日
なんか片手で足りるだけしかシステム保守してないと思われてるようだ
ラヌ @25ranai 2019年1月8日
「元号いつ変わるか分からないけど備えておきますか?その分工数や費用はプラスですが」 「いらないんで安く早くやってください」 くらい想像できないもんかね
rice_of_sato @gohan_of_sato 2019年1月8日
kazukazu_ex 例えば、等角でないフォントで年号を出力するような帳票があれば、新しい年号では表示位置が微妙にずれたり、ひどければ変なところで改行されたりする。本来はそんなことはあらかじめ吸収した仕様にしておくべきだが、他人が作ったシステムの保守とかやるときにはそんなことも言ってられない。ほぼ問題は起きないが、それでも品質担保の観点でテストは必要なんだよ。
dag @digital_dag 2019年1月8日
punimuchiya おーありがとう。一応それなりの地位にいたこともあるんで大丈夫とは思うが。
rice_of_sato @gohan_of_sato 2019年1月8日
他にも、文字コードや使う文字によっては、ダメ文字問題に当たることもあるかもしれない。 https://sites.google.com/site/fudist/Home/grep/sjis-damemoji-jp 俺ならそんなシステムは作らない、と言える人でも、他人が作ったシステムについて品質を保証しなければいけない、となったら? 自分ならテストするよ。
rice_of_sato @gohan_of_sato 2019年1月8日
テスト抜きで改元を迎えられるのは、改元に対応する仕様をきちんと実装してある、単体で動くシステムだけだと思う。
ねこ博士 @kazukazu_ex 2019年1月8日
gohan_of_sato あーなるほど…確かにフォントによって改行の位置や一行あたりの文字数かわるもんなあ… 分かりやすい説明ありがとうございます。
酸素喰う一文/h+JP @kzfm1mon 2019年1月8日
[c5831977] ね 今回はむしろいつ変わるかって分かってるからまだマシでしょ
たし @punimuchiya 2019年1月8日
digital_dag マジか。あんまり自信満々に「そんなにかからない」って言うもんだから、素人のふりして専門知識を忍ばせてどこかでハメようとしてるのかと思ってたけど、そんなこともなかったの?
east @1963_east 2019年1月8日
まぁ、1ヶ月前に教えてくれるだけいいよな……って確かにそうだけどさ! 逆になんで変わるの決まってるのに、今教えてくれないの?やっぱあれかな?ギリギリまで教えないほうがワクワクするからかな?早めに教えてくれればそれだけ全国のシステム屋さん楽になると思うんだけど、そんなことよりみんなで「次の元号なにかなー?なんだろなー?」ってワクワクするほうが大事なのかな?? 記事には「新元号を早めに発表すると二重権威が生まれるとか保守派がなんとかかんとか」ってあるけど、まさかまさか、本当にそれだけじゃないよね??
高峯めいしゅきしゅきbot @hiyoshism 2019年1月8日
ブロック対象の人たちリストがまとまってて助かる。
dag @digital_dag 2019年1月8日
punimuchiya 裏読み過ぎよ。仕事だったら完遂に必要なものヒアリングしてフォローしてぶん回すけど、ただの息抜きなんだから仕事でのやり取りと同じようにしない。やるならどれだけの工程が必要なのか把握する必要があるけどこっちは酒入ってるしそんな事考えんわ。ただの興味だよ。
rice_of_sato @gohan_of_sato 2019年1月8日
まあ、発表後すぐにテスト着手できないところは準備不足やねえ 既存システムの融通のきかなさとかで、どうしても正式発売後でないとモジュール改修できないようなところには同情するが
ziggy @zigizagu 2019年1月8日
ないことを証明するいわゆる悪魔の証明ってやつ。 自分が作ったものならともかく他人のなんてバグがない保証なんてできなさそう。
マクガン @Makugan32 2019年1月8日
テスト用の期間が長い方が安心…って言うのはありますけど、一ヶ月ってそれなりに妥協した期間な気もしますけどね…いずれにせよ、落ちるシステムは落ちます…
アリステロス @maboroshi840 2019年1月8日
改元でIT労働者しばくつぶやきがこのまとめで挙げられていますが、これ一般化してですよ、「子どもは個人差が大きいんだからそれに応じてちゃんと対処できない教師は無能」とか、「トイレで出てけと言われて傷つくトランス野郎は自分の身の程をわきまえてない無能」だったらどうなんです?結局IT労働者の男が弱者でたたきやすいからそこたたいてるだけでしょ?
h.kazami @Chicken2R 2019年1月8日
???「1ヶ月ですべてのプログラムやDTPデザインその他を齟齬なく変更してテストまで完遂できるもの、またはいつ発生するかわからないものに関してあらかじめ準備する稟議を通せるものだけが石を投げなさい。」
瑞樹 @mizuki_windlow 2019年1月8日
新元号を仮に『ほげ』とでもしてシステムの改修をさっさと始めて、元号が発表されたらその文字列を『ほげ』とで置換すれば大きな問題は発生しないと思うけどなぁ……元号は漢字二文字って決まってるから、それでシステムに不具合が出るって言葉よっぽど奇妙なシステムでもない限りないあまりないと思うんだけどなぁ……新元号の“文字列”は発表されるまでシステムの改修を始められない理由ってなに?『昭和』も『平成』も『ほげ』も『天保』プログラム上で見ればそんなに大きな違いはないでしょ?
bluemonkshood @bluemonkshood 2019年1月8日
とりあえず、西暦の下2桁で年を表示していた2000年問題にくらべたら、コンピューターの性能が高くなっているんだし、もう年号は、西暦4桁で表示していて、あとはそれを以下に年号表記するかという問題だと思う。陛下が55歳で即位された時から、平成は、40年は続かないことは生物的に明らか、当然、平成の次もその次も、どう考えても、30年以上続かない可能性が高いんだから、いつ年号が変わってもいいようにしないと
mina @mina_BDR529 2019年1月9日
mizuki_windlow んなこたぁない システム的に合字を使っていたら新しい合字を登録してすべての画面や帳票出力で正しく表示されることをテストしなきゃなんない 実際に使う字でないとずれたりすることもあるし、何より”本番と異なるデータ”ではテストしたことにならないのよ・・・。
モノトーン @l0nMtCKC8j0gIfA 2019年1月9日
コメント欄もシステム屋(笑)の言い訳を疑う声が強いし、これはシステム屋の負けってことでいいでしょ 元号に対応できないシステム屋が悪いわ
かつま大佐(対象年齢10歳) @kamiomutsu 2019年1月9日
ちゃんとしたエンジニアは仮の新元号でテスト済みだからもう大丈夫ってことらしいから、仮の新元号を確定にしちゃえばいいんだよ。
ごんべえ @no_name_man_ 2019年1月9日
たとえ準備万端やったとしても10連休の間システム関係の人らは働き詰めでのんびりできんやろうしなあ。余裕が僅かでもある分、平成31年5月1日みたいなちょっとの間の経過措置OKとはしてくれないところもありそうやし、素人目からしてみても大変なんやろうと思うわ。
dag @digital_dag 2019年1月9日
mina_BDR529 文字出力でそこまでテストさせて貰えるような仕事ってやった事あるの?あくまでも技術者としての理想的な仕事を語ってるように思える。
フローライト @FluoRiteTW 2019年1月9日
そもそも改元が事前にわかる状況が特殊なんだよ。普通は改元されてからの対応になる。本来なら平成の次もそうだった。・・・・この前提条件を理解できてないヤツ多くないか?不思議だ。
フローライト @FluoRiteTW 2019年1月9日
[c5832650] digital_dag 何言ってんだお前ら、帳票出力って言ったら「全部出してぜんぶ目視確認」が基本だぞ。突き合わせて、重ねて、定規持ち出して・・・・すげえ地味で地道な作業だけど、それだけ大事なんだぞ帳票系。物事の重要性理解してんのか?お前らが知らない、わからないだけで、裏で誰かがやってんだぞ。仕事ナメてんだろ
べにやごろう @56Ven 2019年1月9日
おう、金と時間を人員をくれたらいくらでもやったるで
dag @digital_dag 2019年1月9日
FluoRiteTW あー、帳票はたしかにそうだろうね。想定してたシステムが違ったわ。
マシン語P @mashingoP 2019年1月9日
大上段の高みから物申している人ら、自分の親兄弟や妻子が今日倒れたりこの世を去っても慌てず動じず遺産相続や納税バッチリなんですよね?人間いつ死ぬかわからないんだから備えていて当然なんですよね?
sako @SSako86 2019年1月9日
知識がない人が、何が難しいんだろうって疑問に思うのはわかる。難しいはずがないと思うのは全く分からない。
saku @sakuuuuuuune 2019年1月9日
今作ったものが、3年、5年、10年、20年と運用する視点がないプロジェクトもそこそこあるだろうなあと思う 予算とか、そもそも観点漏れだったりとか
くまラブ @yuki_korotyan 2019年1月9日
Web系だの工場システム系だの、担当分野によって事情は違うんだから、一律に元号変更なんて簡単だろうとは言えないでしょう。 業務、工場系のシステムなんて、古い上にコストカットで適当な下請にやらせた結果、仕様書なくて改修のためにコード解析が必要なヤバい案件もあるんだぞ。 でもって、その尻拭いは当時の担当者でなく押し付けられた引き継ぎの場合が多いし。
gaheki @gaheki 2019年1月9日
和暦で日付入力するプログラム作ると普通は元号から入力させるもんだけどユーザーが面倒くさがると平成前提で数字二桁だけで和暦年入れられるようにしてくれとか言い出すんだよなぁ… 多分これ新元号と平成両方入れられるように直しても数年経てば新元号だけにしてくれとか言い出しそう
ふひひっ☆ @satoda3104s2 2019年1月9日
公表前の新元号なんか国家機密事項だしそう簡単に知るわけできないだろ。
glitch @kwe6nt 2019年1月9日
まあ大変なんだろうなとは思うけどそれが政府の責任かって言われたらそういうわけでもないよなとは思う
Mill=O=Wisp @millowisp 2019年1月9日
対応自体は想定してるところが大半だろうし、元々のシステムが崩御という短期間で対応することを前提としたシステムなのも分かる。なんだけど、折角余裕を持てるように陛下が与えてくださった時間を、もったいぶって無駄に浪費する連中のことはそれはそれとして許せない、と言うのも別の話だよ。
undo(おネムだよ) @tolucky774 2019年1月9日
帳票は客に出すので文字がかけただけでも賠償問題になることあるやで
nekosencho @Neko_Sencho 2019年1月9日
簡単に言っちゃうと、「対応してる、そのつもりで作ってる」ものですら、実際やってみたら変なバグやエラーが出たなんて話は、元号に限らずいくらでもあるんで(最近だとスマートホンのアプリケーションがちょくちょくバグ対応のアップデートしてるよね、あれだよ)元号決まってるなら一刻も早く発表してテストできるようにするべきです
undo(おネムだよ) @tolucky774 2019年1月9日
あとね、納期優先で突発で作られたプログラムが一時的な使用の予定だからと標準化されてなくて元号、和暦計算や消費税がオンコーディングということがあるんだよ…。それが長期間使われるとあとはわかるな?
mogmog @mo9mogg 2019年1月9日
さすがにお上もわかってて避けるだろうが、もし頭文字MTSHに被る元号になったら、SI屋の悲鳴は数十倍になると思う。とはいえ、サマータイムであれだけ荒れたので、お上がわかってるかどうか怪しい。
汝、翼を与える@ばってん先に翼ばくれんね イベント・・(出た、出たが最初から居るとまでは・・・) @ryunosinfx 2019年1月9日
紙で残る箇所があるとねー、本当に紙で想定通りに出るのか確認しないと。プログラムは「書いたとおりに動く、空気は絶対読まない。」なのでね。あとほぼ確実に無駄になる機能に払うお金は削るのが定石。
mogmog @mo9mogg 2019年1月9日
まとめで気勢を上げている方々にはなんだか説明しにくいな、こういう事情って。理解できるように説明しろと言われても多岐にわたりすぎていてツイッターではやりたくないし対面ではもっとやりたくない
undo(おネムだよ) @tolucky774 2019年1月9日
画面(帳票)フォームで元号が固定文字でした(専用エディタで開くまでわからない、検索できない)とか
ウラリー㌠ @urary777 2019年1月9日
mo9mogg 元号が26重なるまでにはなんとかせにゃなりませんねぇ(何百年後の話ですけど
高見ちえたん @TakamiChie 2019年1月9日
新元号周りのウェブ記事で「」に囲まれた文字を見ると「え、それが新しい元号?」と思ってしまう。
🙊 @myrUgFExJHByahm 2019年1月9日
このコメント欄にいる大した作業じゃないだろって言ってる人達が営業上司だったら転職考えるレベルだよ。自分のこと有能だと思ってるところが手に負えない。本人は気持ちよく仕事できるだろうけどさ
ねこ博士 @kazukazu_ex 2019年1月9日
mo9mogg 所謂『名前のない家事』に通じるところでしょうね。 業界違いどころか社内でも部署が違えばなかなか理解されにくかったり(´・ω・`)
Carz @o_Carz_o 2019年1月9日
そんなトコまで面倒見る契約してないから、ってのは置いといて。オフラインでクローズドな環境に出張対応するとか、やらかしてる古いシステムが駆け込みで対応しなきゃならんとか、周りのシステム屋は既にデスマーチの様相を呈してるわ
アルフィア@なんということでしょう @alfia 2019年1月9日
まとめ本編でいろいろ言ってる人たちを適当な銀行のデータセンターに放り込んで帳票テストしてもらえば良いんじゃないかな?中間書類含めて下手すると100を超える帳票の、各々ウン万ウン十万みたいな件数の帳票と格闘して、改変前後の確認、改変による旧項目への影響有無調査も含めた調査結果の資料まで作ってまとめる作業をちょちょいで終わらせてくれるんでしょ?すっごい優秀じゃない(白目
アルフィア@なんということでしょう @alfia 2019年1月9日
当然だけど、こっちが話に挙げている金融系の帳票のテストは、本番プログラム変更後の影響調査(実務で印刷された大量の帳票からテスト対象データの印刷されたページを発掘&確認が必須)等、政府関連機関への報告が必要なレベルの物もあるので、 テストデータ突っ込んでテストして あとは当日名前変えて終わり が通用しない案件だよ。(万一何かあれば即行政処分以上のものが飛んでくる厄介な代物)
ネガティブレインボゥ @PizzaElbow 2019年1月9日
まあ元号が変わることも想定できないシステム屋は間違いなく無能だよな。これがどれくらい無能かと言うと「想定はできたが費用・納期との兼ね合いで対応機構は入れなかった」という事も想定出来ずに「想定できたはずだ!」とかしたり顔で言う奴くらい無能。
( ╹﹃╹) @10621229 2019年1月9日
マイクロソフトの元号対応ブログにもありますけど、プログラムによっては出力だけじゃなく入力も対応しないといけないです。現行のプログラムはありえない「昭和100年」などはエラーにするものが多いそうなのですが、「平成32年」をエラーにするわけにはいかず、2020年に変換しないといけない。プログラム間で元号を使った日付データをやり取りする場合もあって検証が大変…という話でした。あと「㍻」のような合字の問題も。
( ╹﹃╹) @10621229 2019年1月9日
「元年」という出力、入力への対応は、平成元年の頃はITが普及してなかったのでそんなに必要性はなかったけど今回は必要だろう、とか。 https://blogs.technet.microsoft.com/jperablog
LCO @f_lco 2019年1月9日
事前準備段階でOFFICE2010を2回もぶっ飛ばしたマイクロソフトさんの悪口は許さんぞ!!! 1回目「https://forest.watch.impress.co.jp/docs/news/1154457.html」 2回目「https://forest.watch.impress.co.jp/docs/news/1160992.html
おろろ @fYe39CoQsPrbZVK 2019年1月9日
元号が変わるのは予測できるだろて奴は、いつか病気になって死ぬだろうけど病院と葬儀場予約済みなん?変わるのが分かっても「いつ」「何に」変わるか分からんなら対策できる範囲に限界はあるんやで
ならづけ @nara_duke 2019年1月9日
あと、これの対応がGWになるんじゃねーの?という話をしたばっかりだよ。
ぷほるず@やらなきゃ意味ない @homerunutuyo 2019年1月9日
変わる想定はちゃんとしてるとこでも、それのテストをするから時間は要るんやで
(・ิω・ิ)もろきう(・ิω・ิ) @moroQ_mayuge 2019年1月9日
(ヽ´ω`)ケースバイケースだしおそらく4月〜5月は死人がたくさん出る
三富@mi7omi @mitomislilylove 2019年1月9日
変えるのが大変というより、新元号がちゃんと反映されてるか、ぜーんぶ確認するのにそれなりに時間がかかるんですよね。スケジュールを組む必要があるので、「発表する日を早く発表して欲しかった」って人もいるかも・・・
トモマサ🔞 @Mattyan_shida 2019年1月9日
うちの職場は元号が変わってもしばらく平成を使い続けるそうな。どうやって?と思ったが…
三富@mi7omi @mitomislilylove 2019年1月9日
後、前任者が設計したものを受け継いでる人も多いので、「システムが悪い!」というのは嘆いてる人も多分思ってます(´;ω;`)
monolith@フォロー外から失礼します @se_monolith 2019年1月9日
素人考えでシステム屋を叩いたあげく、それを踏み台にして新聞まで叩いてる(こっちが本丸?)奴ら、いい度胸だな
🈂トリ @satori_Lv35 2019年1月9日
tanasinn88 最近のサヨクって天皇の権威の根強さを思い知ったらしくて”虎の威を借る狐”をガチでやってる、いい加減うざい。「天皇陛下のお心は~」って言いながら歪曲したり捏造したり自分に都合のいい事言ってるだけだったりするんだよな。
( ╹﹃╹) @10621229 2019年1月9日
何を試験すべきかを洗い出すのは先行してできるとして、実際の試験は4月以降にやるしかない。対象のプログラムは一つ二つじゃなく、サポート中のもの全部。それを考えると大変だろうなあと同情します。合字の評価はフォントができあがってからだから、なおのこと改元まで余裕がないし。
FRKW808 @annex38 2019年1月9日
新元号は「新元号X」でいいと思うミステリアスパートナー
🈂トリ @satori_Lv35 2019年1月9日
そもそも突然の崩御で元号が変わるという事もあり得るし実際昭和が終わるときはそうだったわけで、前もって変わる日がわかってるだけでもだいぶ楽なはずなのに、さらに前もって元号教えといてくれないと出来ないとか、もしかしてこれゆとり教育の弊害ってやつじゃないのか。
🈂トリ @satori_Lv35 2019年1月9日
システム屋が困るんだっていう話はあるけど、実際システム屋が出てきて困るって言ってるのは見たことないんだよなぁ。ぶっちゃけ、難癖つけてお上に余計なお金使わせたり手間を掛けさせたりするのが目標になってる連中がモンスタークレーマーやっただけだろう。
アリアワース @aotororo 2019年1月9日
今言われてるの「夏休みの宿題は、2学期の始業式に渡すことにした。なあに準備していれば慌てる事はない」みたいなものだよね
たし @punimuchiya 2019年1月9日
まあ「想定していた造りでも実対応には労力がかかる」という話をされても理解する頭を持たず「想定してないのが悪い」を連呼するクソ馬鹿は置いとくとして、死ぬ死ぬ言ってる連中もどうかと思うけどね。施行当日全対応が無理ならやれる範囲と優先順位つけて調整するのがシステム商売だろうに
vandalise @vandalise7 2019年1月9日
時間と金くれないとこういうリスクがありますよと話して、落とし所まで見つけるのが仕事だと思うけどね。 海外なら「顧客がこれを想定した要求書だせ」で終わりだけど。
くじら @kujira_desu 2019年1月9日
本来は予告なく突然変わるものだから、元号を使うシステムを作る時点で、即時反映が必要か、遅れても良いので変わってから考えるのか仕切ってるはず。それなのに「事前に発表するんだから5月1日に間に合わせろ」って空気に流されたら悲劇を招くんじゃないかな。 まともなシステム屋が作った物は問題ないとして、現場が勝手に作ったExcelマクロとかは覚悟しといた方が良いと思うの。
sako @SSako86 2019年1月9日
突然の崩御っていつのことを言っているんだろう?
wissen0304 @wissen0304 2019年1月9日
Mattyan_shida 例えばだけど「年度表記でして4月時点の年度基準で表記するルールなんです」とかは言える。
コン蔵 @konzopapata 2019年1月9日
言ってるほど対応できてないところは少ないんじゃない?ただくるである作業でバタバタするのをゆび咥えてまってるより、さっさと時間がある時期に行ってしまいたいのが人情だろう
たし @punimuchiya 2019年1月9日
digital_dag じゃあマジで素人だったのね。ちなみに「サマータイム完備」が2020年に日本でやるって話題になってたそれのことだとしたら、君たぶんシステム屋に騙されてるよ
石の中のワグナス @funoji134 2019年1月9日
人間知らない業界のことではいくらでも傲慢になれるんやな
おろろ @fYe39CoQsPrbZVK 2019年1月9日
元号が変わるなんてのは誰にでもわかる事で、その上で当時の『客』が変わってもいいように依頼してなかったて話なんやで。今回新元号になるけど、新元号から新新元号になる時の対策も含めて『客』が金積んで依頼するんやで。今現場にいるエンジニアも、将来新新元号になる時に現場にいるエンジニアも関係ないんや
しょーた @shota243 2019年1月9日
1ヶ月ってのがまた微妙だよな。事前だしダミーデータを本番に差し替えるだけでから充分だと思われちゃうかもしれんけど実際のところシステムによっちゃきつきつ。Windowsのカレンダー機能が修正されるのが4月半ばで最終テストはそれ以降。改修の時間的余裕は無しだからなあ。
nekosencho @Neko_Sencho 2019年1月9日
というかさ、もう西暦にするとか、ずっと平成(あるいはその次の)で行くとか、改元そのものを廃止する方向でいいんじゃないかなあと思うよ。
ウラリー㌠ @urary777 2019年1月9日
まあ、前回元号が変わった時(昭和→平成)はここまで電子化が進んでいなかったわけで。根幹のシステムは西暦で作っているとして、所々問題が起きる「かも知れない」ならば早くに元号を知りたい、って話ですわな。ウチの飲食店も伝票全部取っ替えねば…
深月 慧🌧️巡星レイヴンと化したにゃつめいと @Key_Hukatuki 2019年1月9日
突然崩御しててんやわんやになるよりかはマシってとこか
spin_out @spin_over 2019年1月9日
システム側の対応としては、基本的には西暦使うことで回避。問題になるのは、未だに明治大正昭和平成とかを丸させて内部で変換してる末端のインターフェース部分。例えば、伝票系の印刷業務なんて、細かな差分も合わせれば、1業務のシステムで100パターン以上の印刷フォーマット持つこともあり、その全てで出力テストが必要。
spin_out @spin_over 2019年1月9日
入力側のインターフェースも、年号変換自体は共通部品を使用して、修正はDBのインアウトとその共通部品の修正だけでいいが、試験は、その共通部品を呼び出す全ての画面が正しく呼んでいることを確認する必要がある。これが民間会社毎に独自システム持っていて、また官公庁のように未だにVB(.NETですらない)ものの回収まで考えると、年号系の回収業務が発生している会社は気が遠くなるだろうなとは思う。
easyiizi1111 @easyiizi1111 2019年1月9日
使われる文字によっては、文字コードまわりで問題起こす可能性もあるから、どんなに「想定」していても、実際の元号が決まらない限り最終テストは行えない。で、最低限改元日の当日と前日、普通なら前年と翌年のデータでもテストする必要があるから、テスト項目数としては元号が入出力される機能数×4。当然、バグを直す時間も見込む必要がある。
spin_out @spin_over 2019年1月9日
あと、DBに新元号と適用年月の入力するだけで対応できるシステム組んでたとしても、現時点での顧客の担当者がその機能を知らず、も普段触らない本社のシステム担当者の隠しモードになっていたりする場合、システム製造会社も現在運用中の顧客もわからず、結局DB直に書き換えてという依頼が来たりする。
easyiizi1111 @easyiizi1111 2019年1月9日
もし従来通り、新元号が「当日発表」なら、システムオーナーごとの都合に合わせて、「できるペースで対応」が許されただろうけど、なまじ事前発表することになったために、「なにがなんでも当日までに間に合わせないと駄目」って雰囲気になってる感はある。
spin_out @spin_over 2019年1月9日
開発環境によっては、現在はそのコンパイルすら難しい場合もありうる。30年前のmakeファイルが残ってればいいよね。
IT土方 @s_takepon 2019年1月9日
PC系の1SEとしては内部は西暦つうかUTC、表記もかなりの物が西暦、元号表記でもしばらくは平成31年でも怒られないのでのんびり直すって感じだな、銀行とかお堅い所はそうもいかないんだろうけど
spin_out @spin_over 2019年1月9日
平成はバブル後ずっと不況の時代だったから、本来ならやっていただろうシステムのアップデートが行われず、古い環境でも「動いているから」で使っていたシステムがこういうとき足引っ張る。
あずいち@10夜11夜サーカス @lovely_fishes 2019年1月9日
satori_Lv35 30年前はインターネットなんて普及して無いし、身近にそんなにコンピューター無かったろ。お前が今Togetterに書き込んでいるデバイスの30年前の姿はどんなんだったよ?
きゃっつ(Kats)⊿7/20乃木坂福岡ドーム @grayengineer 2019年1月9日
『ITはまだ年号のモジュール化ができていないのですか』 この「モジュール化」という用語の用法の不適切さを見ただけで、ああ細かい内容よくわかってない人っぽいなぁと感じる
AB1QQ @AB1QQ 2019年1月9日
個々の課題はともかく、政府ですら情報システム改元対応改修の入札公告を先月も出していることがすべてを物語っている。
きゃっつ(Kats)⊿7/20乃木坂福岡ドーム @grayengineer 2019年1月9日
元号を割とクリティカルな用途に使っているのはおもに官公庁系のシステムで、ほとんどの場合、設計上、内部では西暦やシリアル値を用いて、出力時に共通化された機能で元号に変換する、というふうになっているはず。少なくとも自分が関わったシステムではすべてそうなっている。そして運用面においては、たとえ平成31年6月1日と表記されてしまっても、それが新元号元年6月1日を指すものである、という認識があれば特に大きな問題となることはないし、現に運転免許証などはすでに平成32年以上の表記のものはある。
きゃっつ(Kats)⊿7/20乃木坂福岡ドーム @grayengineer 2019年1月9日
ちなみに補足すると、内部的にシリアル値を使わないと、元号のままでは日数や期限などの計算ができないので、そうせざるを得ない。平成10年4月1日が昭和55年3月10日から何日後か、というのを、元号のままで計算するのは無理なので、基本的に西暦やシリアル値にいったん変換してから計算している。なので、これについては例外は存在しないはず。
spin_out @spin_over 2019年1月9日
grayengineer それって、Java以降の日付計算系の共通モジュール使ってる言語で開発してるシステムなら言うとおりなんだけど、CやCOBOLで組んでるようなシステムの場合、中見ると年月日でそれぞれDBの項目持ってて手計算してるモジュールは結構生き残ってる気がする。DB内でもdate型ではなくて年号コード、年、月、日でデータ持ってるシステムは普通に生き残ってて、そういうのが問題になるシステムだと思う。
きゃっつ(Kats)⊿7/20乃木坂福岡ドーム @grayengineer 2019年1月9日
spin_over そういうのも含めて言ってます。共通化というのは、DBの「元号テーブル」などを参照する「元号変換メソッド」のようなものがシステム内で共通的に(グローバルに)利用できる、という意味です。
🐌 @kota2muri 2019年1月9日
Unicodeなシステムじゃないと表示できない漢字が元号に使われたら大変なことになるな
きゃっつ(Kats)⊿7/20乃木坂福岡ドーム @grayengineer 2019年1月9日
で、『DBの「元号テーブル」などを参照する「元号変換メソッド」』については、基本的にはその元号テーブルのメンテナンス機能がついてるはずなので、改元時はそれを使用することになるかと。
spin_out @spin_over 2019年1月9日
grayengineer 古いシステム(平成一桁台)だと、「次の改元時にこのシステムが使われてるわけない(笑)」で元号メンテが機能として存在しないシステムは私が見た範囲でも複数あります。その後回収されてるものもあるでしょうけど。そもそも元号がオンコード(定数扱い)のシステムもあります。javaでも要件として環境設定ファイルにオンコードで書かれメンテは直接ファイルを修正とケースも複数知ってます(客がDB書き換えなくてもいいようにという理由で)
エリ・エリ・レマ・サンバディトゥナイ @mtoaki 2019年1月9日
lovely_fishes 2000年問題・2038年問題だって30年以上先の「遠未来の話」だから起きちゃったしなぁ。
きゃっつ(Kats)⊿7/20乃木坂福岡ドーム @grayengineer 2019年1月9日
spin_over そうですか。あるんですね。自分は見たことがなかったので、ちょっとショックです。
ま   す @ryuta100kg 2019年1月9日
電子カルテなんかのシステム更新も大変だろうな。放射線部、検査部、薬剤部、手術室、ICU、医事会計、医療連携とあちこちの二次システムに紐付けされてるし、出力される帳票も多い。
spin_out @spin_over 2019年1月9日
古いクラサバだとクライアントの(元号選択の)ラジオボタンとかはハードコーディングが多そうですね。POSのシステム更新してない所とかが問題起こしそう。
みながわ あおい @Minagawa_Aoi 2019年1月9日
改元しても前の年の年数を引き継ぐように改めりゃいいんだけどな。平成31年の翌年が○○(新元号)32年になる。絶対に保守派は反対すると思うけど。
tamama @tamama666 2019年1月9日
grayengineer そもそも未だに昭和の時代に設計されたCOBOLベースの基幹システムを手直ししつつずっと使ってる企業や訳書もあるわけで… ブログラム内でで元号直接なんてのも残ってます 去年〜一昨年あたりにオープン化に失敗して大混乱の京都市役所のシステムもCOBOLでこのパターン 更にソースも仕様書もない
エリ・エリ・レマ・サンバディトゥナイ @mtoaki 2019年1月9日
spin_over 平成一桁だったらPC98のMS-DOSからWindows95の頃だからそんなもんだろうなー。
縄文柴顔の冷泉さん @JosephYoiko 2019年1月9日
『年号のモジュール化』って笑う所なんですか?
ボドロー @kochi_boardgame 2019年1月9日
[c5831977] 客が要求しないし、追加の金も出さないから
cinefuk 🌀 @cinefuk 2019年1月9日
元号システムは3桁対応してないので、もし長寿の結果「[新元号]95年」くらいになると「退位させるべきだ」「在位のまま改元すべき」「民間にシステムを更新させるべき」といった不敬な議論が起きると思うと愉快。
七枝七夏 @7eda7ca 2019年1月9日
システム屋さんが有能でも、クライアントが、改元対応とか要らんから安く済ませて(で、あとで困る)っていう無能というケースの方が多そう(偏見
spin_out @spin_over 2019年1月9日
mtoaki 流石にもう生き残ってないと思いたいけど、そもそもハンディ系の機器への組み込みはDBに相当する記憶領域がテキストファイルのものも多かったですからね。独自規格の疑似DBとか変換ツールとか残ってるのかいな。
#53 @hsgwkyt 2019年1月9日
まあ「元号はなるべく使用しないこと」若しくは「元年は無視して構わない」というのが保守派の希望なんだろうなw
エリ・エリ・レマ・サンバディトゥナイ @mtoaki 2019年1月9日
spin_over メンテナンス性だとか可読性だとか言い出して浸透したのってメモリもCPUパワーも潤沢になって気にする必要が無くなってからで、せいぜい10年ちょっと前くらいからですもんね。
#53 @hsgwkyt 2019年1月9日
カレンダーも「西暦のみ」が「平成31年」で押し切るのが殆どだろうし。役所の書類も生年月日以外は元号欄が無いものが増えてるしね。
jiji @kumattasan 2019年1月9日
改元対応も万全だったはずのシステムが、新元号の漢字コードからおかしな挙動が発生してシステムダウン、みたいな話は絶対起こると信じてる
エリ・エリ・レマ・サンバディトゥナイ @mtoaki 2019年1月9日
cinefuk 「帝都物語」や「ジオブリーダーズ 」世界ではそういう事やってたのかもなー。
sako @SSako86 2019年1月9日
サマータイム騒動の時と同じ話をしている。その時に指摘されたのにそれを理解できずに同じことを言っている人もいる。
ざわ @zawayoshi 2019年1月9日
不謹慎な話だが、退位予定の4月30日までに陛下が突然崩御されたら…ってこと考えるとぞっとするわな。
おろろ @fYe39CoQsPrbZVK 2019年1月9日
一ヶ月で全てのシステムが対応完了すると思ってる輩がウジャウジャいる方がぞっとするわ
たし @punimuchiya 2019年1月9日
grayengineer 日付変換や計算をいちいちサーバサイドに投げるほど悠長なシステムばっかじゃないし、全機能共通ってのは無理な場合が多いよ
tamama @tamama666 2019年1月9日
hsgwkyt 保守派ならこの機に「皇紀」に統一!くらい言ってほしいですね
ねねっとテックダイナー【スマホゲーム発売中☆】 @nenet_techdiner 2019年1月9日
(´-`).。oO(2000年問題みたいでなんとなくオラわくわくしてきたぞ) 元号自体は時代を掴むという意味で面白い風習だなと思ったりするので合理のために廃止する必要はないと思う。一方システムで扱ってる人は厄介だと思いがちだけど…昭和がたまたま長かっただけだし可用性をもった仕組みで組んどけばいいってだけでは?
かつま大佐(対象年齢10歳) @kamiomutsu 2019年1月9日
easyiizi1111 まったくこの通りで、通常は改元してからの作業なんだから、今回だって別に新元号開始に間に合わせなくてもいいはずなんだよね。でも今さらそんな話にはできない。「裏目に出る」とはまさにこのことだ。
ぼにゅそむ @yokoshimanaruko 2019年1月9日
satori_Lv35 satori_Lv35 satori_Lv35 普段のあなたのキャラクターからの想像を一歩もはみ出ないコメントに感服します()
あいしー★ @aicm2 2019年1月9日
二桁は0埋め表示だけど1年は元年で表示とか切り替え日の処理とかいろいろ面倒だし。 表示だけでもまさかの3文字だったりプロポーショナルフォントで表示したら微妙にレイアウトがずれるとか。
まっくろなねこ @blackcat009 2019年1月9日
「例え新元号を「ほげ」でプログラムしてたって、実際の文字が帳票に出た際に正しく印字されるかどうかはテストが必要」->わかる 「例え新元号を「ほげ」でプログラムしてたって、実際の文字に置き換えた際にプログラムが正しく作動するかどうかはわからない」->わからない。 なんで?
trycatch777 @trycatch777 2019年1月9日
「システム屋」なんて一括りにした言を放っちゃう人間の発言を見た時に脱力感しか感じないんで、自社システムにそれなりの保守費を払ってたり、クラウド使ってるんで大丈夫、とか、心配のない方々は黙っておいた方が皆様の健康のために良いとしか思えないな。
ねこ博士 @kazukazu_ex 2019年1月9日
urary777 流石に次のタイミングでMは外せるでしょ
JIT_MIRUMIRU @JIT_MIRUMIRU 2019年1月9日
クソアカウントのお勉強(しかも的外れな批判つき)に付き合ってあげるおやさしいコメント欄…。なんで金ももらってないシステムの作りこみをせにゃならんのだ。全部が全部なんらかのミドルウェア上で動いているとでも思っているのだろうか。
ぢゃいける@厚真町 @jaikel 2019年1月9日
なんで事前に対応しておかないんだ、っていわれてもお金も人月もかかるし、財布握ってるところが首を縦に振らなきゃ何もできないんだよ…
ぢゃいける@厚真町 @jaikel 2019年1月9日
kumattasan この文字を印刷するとジョブが落ちる、ってのはありましたね…
undo(おネムだよ) @tolucky774 2019年1月9日
grayengineer 元号オンコーディングはありますよ…
坂崎太郎 @sakaxtaro 2019年1月9日
パソコンのことは全部システム屋さんでやってくれる世界線のお話。
白鷺 @helsigh 2019年1月9日
2000年問題とかクリアしたあたりの次期以降に作ったシステムならメソッド化してそうだから改修は楽そう。だけど昔から保守してるならともかく、別会社に依頼とかなら調査からだからしんどいね。なによりテストがしんどいね!依頼された皆さんがんばろうね。
白鷺 @helsigh 2019年1月9日
個人的に予定にあるながれで一番ドキドキしてるのはサマータイムと消費税対応(割引もあるよ!)の方。サマータイムは適用微妙だけどposシステム開発陣の不安はいかほどのものか…
しょーた @shota243 2019年1月9日
昭和→平成の時には内部では昭和でデータを保持したままにして入出力時に元号変換するように改修したシステムもあったと聞くが、どうしてるかなあ。昭和100年問題発動まであと6年。
monolith@フォロー外から失礼します @se_monolith 2019年1月9日
改元対応で大変になるシステムは、大昔のプログラムをハードウェア更新を越えて継承して使い続けてるケースだろうなあ。昔は1ビットでも節約するのが大正義だったから、改元の備えなんかプログラムされてない。勿論今のハードウェアなら性能的に余裕だけど、止めたら毎分何億円と損害の出るシステムだと、エンジニアが改元の備えをプログラムしたいからメンテ時間をもっとくれ、と上に掛け合っても相手されないだろうし。
undo(おネムだよ) @tolucky774 2019年1月9日
しかし改元も頭が痛いけど、サマータイムに伴う回収を簡単というなんて一体どんなシステムなのだろう。自社で全て完結するクローズドなシステム?外部からの送信データが一切ないの?
spin_out @spin_over 2019年1月9日
helsigh 今システム屋は人手不足でして、ぶっちゃけ現在お付き合いのある会社以外からの依頼は受けられないのです。
undo(おネムだよ) @tolucky774 2019年1月9日
平成への改元の際は帳票の元号はゴム印で訂正してたので、ゴム印屋さんがてんてこ舞いだったけど、今回も改修漏れの帳票はそうなるのかねえ。手書きの帳票が多くて、帳票のフォームも印刷屋に発注してたから、直接元号が印刷されてたものも多かった。今も役所の印刷物はそうじゃない?
spin_out @spin_over 2019年1月9日
消費税は3から5の時点で軽減税率の話が出てたし、商品個別の税率に在庫管理とかもかなりのものは対応雨してるはず。だが、同一商品が店で食うか外で食うかで税率変わるは対応してないものが多そう。同一商品を登録する場合、JANとかで分けられないよね。あれ。
undo(おネムだよ) @tolucky774 2019年1月9日
システム屋さん「和暦の調査しないとやばいで」 ユーザー「大丈夫だ問題ない」 (直前になって)ユーザー「ごめん、やっぱり調査して」もあるある
ナナシ @nanashist 2019年1月9日
[c5831977] 改元が10年後ならそもそも今のシステムに組み込んでおく必要ない可能性あるし、10年後必要な機能を今対応する余裕を持って開発出来てる会社の方が少数派では。
新しい名前が思いつきません @NewName_NoIdea 2019年1月9日
世の中ってみんなが思ってるより大分古めのシステムが主体になって動いてると思ってたんだけどなあ。それ取り換えようとするとこの前のみずほ銀行の一件みたいな大騒動がいくつか追加で起こりそうだし
kartis56 @kartis56 2019年1月9日
年一しか出さない帳票とか大変なんだよな
しいたけ @ctake147 2019年1月9日
この場合のシステム屋さんは基幹屋さんなので安全性の考え方が段違いなんだよなぁ。 Web屋さんのノリで考えたらダメなのです。
fai into VR @faifx 2019年1月9日
8月31日に夏休みの宿題に追われる小学生みたいなもん・・・。
Foo @x8I48mibYNrdgi5 2019年1月9日
nanashist 2000年問題のときも今作ってるシステムを30年後も使うわけないからヘーキヘーキって対策されなかった
BIRD @BIRD_448 2019年1月9日
私が持ってるカレンダーソフトは2000年問題がクリアできず日付表示されないが、作られたのは1995年である…
堀石 廉 (石華工匠) @Holyithylene 2019年1月9日
blackcat009 上でも書いてる人が居ますが、ちょっと古いシステムだといわゆるダメ文字っていって一筋縄の対応では難しい文字があるんですよ。
GEN @gent9310 2019年1月9日
実は一番問題なのは、メンテナンスも何もせずに「動くから」で使い続けてる中小企業の業務システムってかなりの数が動いていて、それが新元号で問題が出る、あるいはその可能性があることに気付いてないユーザーが結構いるって話なんだと思ってるんだが。
クリスセドン @sedooooooon 2019年1月9日
それなりの地位にいたで笑った
堀石 廉 (石華工匠) @Holyithylene 2019年1月9日
しかしこれ、1か月あればって言ってる人は4月の通常業務はどうなると思ってるんだろう……
あきなすび @akkonline 2019年1月9日
mizuki_windlow それ、マスタデータだけ次の元号に置き換えてテストなしで対応完了して、本番で万万万が一「ほげ」が表示されて例えば客先に送られたとして、笑って許して貰えるかな? 笑って許せるならそれでいいがそこで問題になるなら本番環境適用前のテストは必須になる。開発機で実装レベルのテストやって環境かえて環境依存問題の排除して、それで初めて本番環境に適用して最後に簡易確認してやる必要があるよな。
まっくろなねこ @blackcat009 2019年1月9日
Holyithylene すんません。テスト用ダミーデータって、そういうのも含めて作るモンやと理解してたんですけど、違うの? そりゃ本番で未知のモンが出たらどうしようもないのはわかりますけど、それ既知のモンの対応をしないってのは、理解できんです。
むさむさ @babatune06 2019年1月9日
もう何度も出ただろうけど、たった一単語置換するだけで、その文字列が使われるあらゆるパターンの動作をテスターが確認するわけで。その文字列がプログラム内でどんなイタズラをするかは完全に想定できない。もちろん、簡単にやって済ますこともできるだろうけど、そんなことするのはシステム屋として二の線だろう。テスターを20人30人雇えば1ヶ月もかからないだろうけど、お金があまり出せないシステム屋だと2人、3人が関の山だろうしねぇ……。
フルバ @furubakou1 2019年1月9日
…もう西暦でいいじゃん、とも思うのだが、そうか…元号で現状動いてるシステムをどうすればいいか、って事情があるのか…
あきなすび @akkonline 2019年1月9日
なお大抵の日本企業では4/1から年度が変わる!全社基幹システム的には年次決算~連結報告まではそもそも繁忙期です!システム屋は夜間待機(コールドスタンバイ含む)とかも必要なケースがありそもそもピリピリしてる。そのタイミングのどこで決算に不要な改修を本番環境に適用しろっての、決算処理に影響でたら損害賠償ものだ。
kumonopanya @kumonopanya 2019年1月9日
馬鹿の極み、30年に一度なら良いかもしれないが、数日、数カ月後にも変わるかもしれないものとかにいちいち予測して用意するのは極めて不合理。(一応言っておくと死ぬ以外でも変わった例がある)
あきなすび @akkonline 2019年1月9日
単体決算やって組織変更対応して連結決算やっての前、3月中に元号対応できるんなら、システム屋さんのヘイトを稼がずに済んだかもね。決算関係ないシステムは2か月確保できるし。知り合いは「GWは10連勤だ」って言ってる奴もいる。
kumonopanya @kumonopanya 2019年1月9日
IT業界だけでも5年ぐらいは平成をそのまま使っていいだろ。
あきなすび @akkonline 2019年1月9日
↑「多少は」稼がずに済んだ、の間違い
VRAM01K @VRAM01K 2019年1月9日
平成以降、改元を想定した設計が普通だと思いますが、今回の件で言えば存命中の改元が有りうることで、毎年変わる事を考慮した試験とか追加してますね。まぁそれも想定しとけよという話もありますが
あきなすび @akkonline 2019年1月9日
blackcat009 十分な金と時間くれたらやるよ!だけど、それが確保されないのが現実
おりひら @k_orihira 2019年1月9日
これ見て「三角関数は使わない」「歴史なんて無意味」「絵描きなら、ちょっとやってよ」と同じと感じたよ。
野獣後輩 @yaju5123 2019年1月9日
[c5833177] 元号に依存しないシステムを導入した結果、弊社では顧客から和暦に対応せよとのクレームが入って作り直し。 しかも契約書に関連するシステムだったから、システム部だけでなく法務部、役員会まで決済を貰う事態になりました
Lotus @Lotus19810101 2019年1月9日
OSアップデートしないといけないから大変だねぇ ネットワークから切り離されてるOSが一体いくつあるのやら…
野獣後輩 @yaju5123 2019年1月9日
tamama666 更に言えば古いシステムを使ってるのは大抵官公庁や金融機関なんかの重要な組織。 いやヤバいだろ
Lotus @Lotus19810101 2019年1月9日
よっしゃ!新元号は\x5Cが含まれる漢字を使ったろ!
堀石 廉 (石華工匠) @Holyithylene 2019年1月9日
blackcat009 そこ手を付けるとテストも膨大になるし改修が必要になったら規模が大規模になりがちで、そのわりにダメ文字が来なかったらダメ文字対応にかけた膨大なコストは全部無駄、ってことで対応出来るか出来ないかで言えばできるけど現実的には想定した対応は無理、もう実際の文字でやってみるしかない、というはなしです。恰好だけ良い言い方すると「コストとリスクを天秤にかけてリスクを取る」というはなし。
野獣後輩 @yaju5123 2019年1月9日
非IT関連の業種だが、本職がこれだけヤバいと言ってる以上、まあ相当にヤバいんだろうなという予想ぐらいは出来るよ。
ECHO @echo2944 2019年1月9日
対応しないというのも対応の一つではあると思いますけどね
愛媛人と大阪人のハーフ @TmtRj 2019年1月9日
自分がやらないからって他の業種の仕事を軽くみるのはやめよう(自戒)
ECHO @echo2944 2019年1月9日
要するに逆に考えて平成32年って表示されても別にいいじゃんと開き直るのです
樹望 @itsukinozomu 2019年1月9日
新元号は2文字ではなく3文字にしてみました! これで爆死するシステム屋は結構いると思う…
spin_out @spin_over 2019年1月9日
echo2944 最悪民間はそれでもいいんだけど、お役所関連の書類が問題。役所が柔軟に対応してくれるといいんだけど。
稟@馬主ライフ @Rin_chaaaaaaaan 2019年1月9日
年号のモジュール化なるワードが気になりすぎてやばい。この世の全ての言語に使える共通のモジュール(笑)なるものがあるとでも思ってるのかね?
神崎ユーリはここに在る @Euri_K 2019年1月9日
急に死んで元号が変わる分には「急だからなるべく急いでやるけど時間くれ」で言い訳できるからいいんだよ。問題は予算外という名目でそんな対応なんか考えてないプログラムなんか掃いて捨てるほどあることと、事前に言われてるからケツが決まってるのに発表時期と必要工数が噛み合わないことなわけで。
堀石 廉 (石華工匠) @Holyithylene 2019年1月9日
欧米系の会社が作ったパッケージ入れた所はほんと面倒な予感はある。基本的にあいつらの多言語対応ってあてにならないからダメ文字で問題出たりとかありそうだけど、ダメ文字チェックして問題が出たとして修正してもらえるかわからんだろうし……。
アルリルラルル @aruriruraruru15 2019年1月9日
こういうこと言うのはアレかもしれんが、元号っている?いらなくない?全部西暦でよくない?
spin_out @spin_over 2019年1月9日
和暦に対応してる各言語対応のカレンダーライブラリは最近の開発言語なら普通はあるんだけど、どう考えても5/1までにアップデートされない気がする。ライブラリをカスタマイズして以降独自のモジュールとして扱うか。準公式なものとしてアップデートを待つか。そして客は納得するのかw
つりーべる @tada_suzu 2019年1月9日
これについては、今上天皇陛下が明確にいつ退位しますよ、と仰ってくれてるので新元号が何になるかは兎も角として準備する時間は十分取れるはずだと思ってる。ベタ書きしてるプログラムだらけなら、サブルーチン化するとかさ。
稟@馬主ライフ @Rin_chaaaaaaaan 2019年1月9日
ひょっとして西暦日付を投げると和暦日付を返すWebAPIとか今なら需要があるのか…!?
あらたか @ara_taka_yama 2019年1月9日
『新元号を「ほげ」でプログラムして、実際の文字に置き換えた場合にプログラムが正しく作動するかどうかはわからない』の凄く極端な例なんですけど、例えば新元号が「𠮷野」(さむらいよし(吉)ではなくつちよし(𠮷))になったとすると、UTF-16非対応の環境では文字化けする(というかそもそも文字が存在しないので外字対応になる?)んですよね。(まあ、実際にはShift-JISで表示可能な範囲内で選ぶとは思いますが)
fai into VR @faifx 2019年1月9日
システム改修に予算をつけられなかった経営者が無能だったという話。エンジニアは注文を受ければいつでもウェルカムだった。
Lotus @Lotus19810101 2019年1月9日
tada_suzu 結局1か月で正式な元号で実装してテストまで終わらせなければいけないからなぁ 日本の元号使ってるシステムって海外含めて何百万あるんだろうね
#53 @hsgwkyt 2019年1月9日
多分システムの改修が簡単にできるなんて思ってるのはみずほ銀行以外のユーザーなんだろうなあ…ニガニガ
団扇仙人 @uchiwamaster 2019年1月9日
今すぐは難しいというのは承知の上で言うけど、「いずれ元号が変わることを想定したシステムづくりを」というなら社会のシステム全体で元号を使うこと自体を廃止していく以外の正解なんてないんじゃないかなあ
まっくろなねこ @blackcat009 2019年1月9日
Holyithylene akkonline なるほど、理解。「今、最短でできること以外は、全部ぶっつけ本番で」ってことですな。そりゃ「それで本番環境でのテストが短期間で終わると思うなよ?」になりますわな
ア・ソコ @yochie0891 2019年1月9日
システム制度に縛られてる状態で元号が変わるってのが初めてだからかね。特に官公庁は元号使ってるからピリピリしてるとか聞くけど、元号変わるシステム入れてなければ「平成」が続くだけでエラーが吐かれるわけでもなければシステムダウンするようなことはない。 一端の底辺PGですが、もっと楽観的になれといいたい。これまで色々な所に行ったが、元号はいつからいつまでが明治でとかいうデータベースがあるからそこに開始日と元号を登録すればいいだけ。はっきり言ってテストすら必要ないよ。
エリ・エリ・レマ・サンバディトゥナイ @mtoaki 2019年1月9日
Holyithylene 大昔のWindowsアプリで、ファイル名を大文字にする仕様なのはいいんだけど2バイトコードを想定してなくてSJISが文字化けするってのがあった。
moramora @MoraMora_FF14 2019年1月9日
責任を取らなくていい底辺PGは気楽でいいなぁ
クリスセドン @sedooooooon 2019年1月9日
まとめを良く見ると ◯◯だろう 自分ならこうする 簡単に変更できる仕様にすればいい 的な意見が多いけど典型的なツイッターでよく見るクソリプの類いじゃん
あらたか @ara_taka_yama 2019年1月9日
Lotus19810101 新元号の侮ヲがバグるじゃないですかーやだー
🈂トリ @satori_Lv35 2019年1月9日
aitsuki2 サヨクの話をしてるんだよ。むしろ右翼は言わない。
gaheki @gaheki 2019年1月9日
客の要望で年の所に1と入力したら自動的に平成元年になるようにしてくれってパターンがね… 元号入れるようにしてれば最初から問題無かったのにと歯痒い思いしたりする
uroboros🌯 @code_uroboros 2019年1月9日
自分ちの職で急に大口の案件(キャパ超えて無理レベル)が来て 金と時間くれれば対応できますor前もって言っていただければ何とかなりますと言ってる所に 周りが専門職だろ何で対応できないんだと騒いでるようなもん 騒いでる組はすぐその場で何でも完璧に対応できるのかな?
茗荷昇紘 @masilite 2019年1月9日
他人が作ったバグだらけのシステムを改修するから完璧にできないなら、全部自分で作り直せばいい。
堀石 廉 (石華工匠) @Holyithylene 2019年1月9日
mtoaki そういうのいまだにありますよ。Windowsでユーザー名やファイル名を日本語にすると不具合起こすソフトとか……。そもそもマイクロソフト自体がわりとやらかしてた過去がありますし……。 https://support.microsoft.com/ja-jp/help/933528 https://support.microsoft.com/ja-jp/help/2219526
xi @accountLINKonly 2019年1月9日
現状存在しないであろう単語を漢字を出力するってだけで胃液がせり上がってくるわ…ましてや帳簿だの契約書だの…_| ̄|○、;'.・ オェェェェェ
もつまつ @fursultiamine 2019年1月9日
よくある制度対応の一つに過ぎない。過去に当局が出してきた数々のキチガイ要件を見せてやりたいわ。
spin_out @spin_over 2019年1月9日
blackcat009 問題なのは、改元に対応する改修できちんとテスト環境作ってテストするような工数に対するお金を客が払うかなんだよね。個人的にはちゃんとやるべきだと思うけど、画面(帳票)の端っこの二文字を入れ替えるために100万払うことを客が納得できるかって話で。多分多くの客は納得しないので提示されたお金でできる応急処置だけになる。見積もる時は当然そういうテスト体制まで考えて工数出すけどね。
cocoon @cocoonP 2019年1月9日
「見た目も機能も全く変わりませんし、現時点では御社にいいことは一つもありませんが、この改修は必要なので結構な額のお金を払って下さい。メンテでシステムも止まります」と言って「わかった払うし止めてもいい」と改修させてくれる会社ばかりなのだったら「素人考えなんだけど」って言ってる人たちの言う通りなんだろうね。
ヒロセジロウ✏️ @denjiro13 2019年1月9日
姉のチームが引き継いだシステムも「平成」がハードコーディングされてたらしくて、えらく憤慨してた
lion5557 @lion55571 2019年1月9日
元号変わることを想定ねぇ……平成元年(平成10年でもいいけどさ)に作ったシステムの要求仕様に、そういう仕組みをコストかけて入れようとする顧客ってそんなにいないと思うけどなぁ。しばらくは平成と新元号が混ざってる状況になるのかもしれないけど。
🈂トリ @satori_Lv35 2019年1月9日
lovely_fishes じゃぁ、突然の崩御で元号が変わったら日本は崩壊するんか、30年前と違ってこんぴゅーたーがいっぱいだから日本壊れてなくなっちゃうのかよ、アホかと。
signal9.jp @Signal9J 2019年1月9日
そもそも新「元号」が漢字二文字という前提で大丈夫なのかしらん。
まうみん @maumin66 2019年1月9日
年初めのexcel2010の不具合は新元号対応が原因とのこと。microsoftは無能だった...?
齊藤明紀 @a_saitoh 2019年1月9日
新元号をセットして四月一日にプログラムは作業完了したとしても、客先へのインストールと動作確認が1ヶ月で終わるんだろうか?夜間とか週末しかシステム止めちゃダメという顧客が多数いると、人手が足りなくて全顧客のシステムをアップデートしきれないとか
あなぐま @badger2635 2019年1月9日
文句言う人はたとえ元号が半年前に発表されたとしてもグチグチ言ってそうな気がする。
kartis56 @kartis56 2019年1月9日
mtoaki 古いAmazonのレビューが文字化け(おそらく文字コード変換ミス)していて、報告したらレビューまるまる消されたっていう話が複数あったり。togetterまとめがどこかにあるはず
ウラリー㌠ @urary777 2019年1月9日
satori_Lv35 「前もって教えてくれないと出来ない」ではなく「前もって教えてくれないとコストが嵩むから、分かってるなら教えておいてくれ」って話では? 昭和天皇がお隠れ召された時の様に、商店から銀行から全て閉めても良いのなら円滑に出来るでしょうけど。
spin_out @spin_over 2019年1月9日
urary777 ただでさえ忙しい期首に手間ばかりやたらかかる作業ぶち込んでんじゃねえ。通常業務の合間に対応するから今すぐ発表しろボケが本音。
三富@mi7omi @mitomislilylove 2019年1月9日
万が一発表が延期になってスケジュールが破綻しても政府が責任取ってくれる訳じゃありませんしおすし
ウラリー㌠ @urary777 2019年1月9日
spin_over それofそれですね。飲食も2〜3月が暇なので、今の内に教えて欲しいです
funpan @funpan2015 2019年1月9日
いうても、西暦から1988を引いて表示してるだけってシステム、相当多そうな。一行で済むのに変換用の関数名を調べるのめんどい、ぐらいの勢いで設計者の考えが無視されてるのとかもありそうだし。結局、事前にわかるから阿鼻叫喚ではなく慌てる程度で済む、みたいな感じだろうな。
無式MT @MxxTxxxx 2019年1月9日
何年か前に同じ内容つぶやいたら炎上したことあったなぁ プログラマっていつも残業自慢社畜自慢してるくせになんで改元対応のプログラム組まないのか本当意味わからないよね。一体なんのために一日数時間もパソコンの前に座ってるわけ?マインスイーパやってんの?
偽うどん王 @nnsi_mr 2019年1月9日
チョチョイのチョイでリソースをほとんど使わず元号に対応出来るシステムの具体案を提示出来ない時点でクソほども意味のない戯言だよなぁ。
無式MT @MxxTxxxx 2019年1月9日
ただ改元については政府の対応が悪いというか、反皇室極左であることを隠しもしない無知無教養安倍晋三が新元号通知を意図的にやらないのが元凶だろうな 譲位があって一世一元じゃなかった江戸時代は全国に新元号を通知して民衆が馴染んでから朝廷が正式に改元していた
無式MT @MxxTxxxx 2019年1月9日
天皇と国民の紐帯を切断したい安倍はその前例にならわず、元号を隠し、それはおろか天皇の改元権まで廃止しようとしている 安倍がゴミクズすぎるせいで少しはプログラマに同情できるようになったわ
spin_out @spin_over 2019年1月9日
DBの種類もコード体系もOSも開発言語も使用箇所もまちまちなものに対応できるプログラム組めたらすげーよな。
おろろ @fYe39CoQsPrbZVK 2019年1月9日
そらオメー、客が依頼してないのに勝手に対応したら犯罪だすけ客がはよ稟議通して依頼せいて話だわな
無式MT @MxxTxxxx 2019年1月9日
安倍晋三は自分で国家築いてそこの国王になってるんだよね 皇族身位の捏造、改元廃止とか極左民主党ですらやらなかったのに
ザンバ @akaikoudan 2019年1月9日
そもそも十分な準備期間があった上での改修でもデカい不具合特に珍しくないし、それが短期間で…ともなればそりゃ警戒もされるわな
電子馬@お腹いっぱい。 @Erechorse 2019年1月9日
でも、「元号廃止!」は勿体ない気がするのよ。だってみんな、「平成最後の」って言って盛り上がってたじゃないっすか。平成の30年をネット史と繋げて考えた番組もありました。やっぱり時代の区切りって感覚は重要じゃないかなあ。こういうムダなことは社会の潤滑油だと思う。
偽うどん王 @nnsi_mr 2019年1月9日
元号以上にシステムのノウハウもハードも社会形態も目まぐるしく変化するし、新旧混在する中それら全てに互換性のあるシステムなんか作れるワケないんだから、「新元号を早めに発表して、十分な時間とリソースを投入して具体的な次の元号に備える」が一番効率が良くて混乱が少ないと思うんだけど。
BABA Motoharu @calc3 2019年1月9日
システムは基本設計で改元対応できるようになっているけど、帳票類がレイアウトの都合により元号埋め込みになってるというパターンなら手元にある。
団扇仙人 @uchiwamaster 2019年1月9日
Erechorse 自分は元号そのものを廃止すべきとは思いませんが、これほど社会のシステムでがっつり使う必要あるのかな?って疑問があるんですよね。それこそ1年2年では変わりようのない部分だとは思いますが。「30年あって対応できてないの?」みたいな物言いってそういうとこにも跳ね返っちゃうんじゃないかと。
cocoon @cocoonP 2019年1月9日
「突然の崩御で元号が変わったら日本は崩壊するんか」って意見あるけど、突然の崩御で元号が変わったら前の元号のままでも許容されやすいって話じゃないかな。平成になった時二重線の下に平成って書いてあるゴム印作ってるようなところ結構あったし(あのころは紙が優位だったからそれでよかったわけで)
かつま大佐(対象年齢10歳) @kamiomutsu 2019年1月9日
結局「何でやってなかったの」と言われるべきはシステム担当ではなく金と仕様の決定権を握ったクライアントであって、システム担当は今から始まるであろうクライアントからの無茶振り地獄を思えば愚痴も言いたくなるだろう。それに対して「やってないやつが悪い」というのは敵を見失っている。「うちはちゃんとやってる」って言う人の「うち」ってどこなんだろうな。
funpan @funpan2015 2019年1月9日
文字によっては、システム屋さんより、改元の後にExcelで文字切れが大量発生して、先輩より引継ぎし伝統のExcelシートを使っている人達が大慌て、その人達から何とかしろと言われた部署内のパソコン大先生が涙目、みたいな事とか起こるかも。
cocoon @cocoonP 2019年1月9日
「自分が問題ないと思うから問題ない」みたいな考え方の人はたぶん他の事でも同じような思考をしているだろうから一緒に仕事したくないですね。
稟@馬主ライフ @Rin_chaaaaaaaan 2019年1月9日
プログラミングやったことある人じゃないと実装より検証にアホほど時間がかかるってことが想像できないのか 実装だけならそりゃ1ヶ月あれば余るくらいだけど、一般的にはその4倍は設計と試験にかかるんだよ
稟@馬主ライフ @Rin_chaaaaaaaan 2019年1月9日
Rin_chaaaaaaaan しかも、試験ってダミー文字列でやれば済むものじゃないから1ヶ月じゃ足りんって騒いでるんですよ
spin_out @spin_over 2019年1月9日
パワービルダーとかデルファイとか修正しろって言われたらやだなぁ。
KOYAJI@海兵隊最先任上級曹長 @deadanso 2019年1月9日
現代の知識と環境で、三十年前の事批判するとか草生やすしかない。
モフ・猫革命家 @Mofu_Master 2019年1月9日
無能!と仰る方が、自分で各種システムの仕様書を読んで、『平成』の文字列を変更すればいいんじゃない?
モフ・猫革命家 @Mofu_Master 2019年1月9日
あと、1ヶ月で発生する作業見積りやら受発注手続きに関する諸事務もやってね。
無式MT @MxxTxxxx 2019年1月9日
誰も短期間でやれなんて言ってないだろ 改元があるなんて分かりきってんのにその対応をしてこなかったのが批判されてんだよ
パスター丁 @takemon230 2019年1月9日
「仕様にないけど元号変わる可能性考慮して変更しやすいようにしておきました!」ってのは「プロの仕事」とか「配慮」じゃなくて「バグ」って言うんだよ
茗荷昇紘 @masilite 2019年1月9日
現状必要な短期的な対応以外を無駄と割り切る、原理原則を見ず結果のみを求める仕事マンが多いせい。始めに作る段階で、どんな元号が来ても対応できる完璧で「美しい」システムを作らないのが悪い。
パスター丁 @takemon230 2019年1月9日
ハンバーガー注文したときに「ハンバーガーだけじゃ喉が渇くからコーラもつけよう」なんて対応する店員には 少なくとも俺は仕事任せたくないな
ヘ夕レ @heyuure 2019年1月9日
改修をするエンジニアは気の毒ですが、元号変更でこれだけ大変なことになるシステムを作った企業かそういう仕様にしろと発注した客のどちらかは私も無能だと思います。
tamama @tamama666 2019年1月9日
MxxTxxxx クライアントがお金出さないとシステム屋はうこけないんですけどね
@_suna_ 2019年1月9日
そもそも元号が「二文字である」って仕様決まってましたっけ? 突然三文字になったらそれだけで表示崩れるし まず仕様を決めてくれ。
あごにー @Agony_01 2019年1月9日
どんな元号が来てもかまわない美しいシステムなのは別にいいんだけど、結局変更内容が確定して変更してテストできるのは1月しかない。この世の中にある平成の文字を使ってるシステムを全部テストするのにひと月しかないんだぞ。
あごにー @Agony_01 2019年1月9日
変更そのものの実装は大したことないんだけど、テストが間に合わねぇって言ってるんだが、わかってる人はどんだけいるんだろうか。
Yoshiyuki @HARAOKA 2019年1月9日
超ハードコーディングな他人のコードを改修メンテしろって言われて遣らされた事がないのかな?理想はポイントを決めて新しい元号を投入すればいい構造になってないといけないけど、実際にそうやって作られてない物を改修しろって命令されてあなたはやるの?って思う。まあ、そんな仕事を受けなければいいという話はあるだろうけど、そうも言えない事情ってみんなあると思うけどね。
TBT1102 @TBT1102 2019年1月9日
_suna_ 日本の元号では3文字はないが20年弱の間4文字だったことはある。中国でもあったはず。
Off Black @OffBlack1 2019年1月9日
たしかに、元号改修って一般企業にも普及して20年ちょっとな日本のIT業界からしたら未経験かも?汎用機系は仕方ないな…熟年ソース30〜40年くらいはわりとありそうだし…
spin_out @spin_over 2019年1月9日
_suna_ 一応閣議決定されてるらしいので、それの変更がない間は二文字確定かと。ただ直前に文字数変更の閣議決定される可能性は0ではないですが。
TBT1102 @TBT1102 2019年1月9日
磯野ー今度の元号は「民国紀元」か「インド国定暦」にしようぜー
spin_out @spin_over 2019年1月9日
最初からやってろという人は、このくらいただでやってよという客になりそう。
上下逆さまつげ @kitayokitakita 2019年1月9日
punimuchiya う〜ん… そもそもの話やが極端な話「元号:ああああああ」やろうが「元号:薔薇錣壱爾」やろうがその時になったら出力出来るようにしとけやって話やろ。 それが出来んというなら、平成の間何やっとったんやって言われてもしゃーない。
あごにー @Agony_01 2019年1月9日
kitayokitakita いやたぶんその年号だと帳票の枠からはみ出て表示できないっていうシステム山ほどあるで・・・?
無式MT @MxxTxxxx 2019年1月9日
tamama666 ならクライアントに改元対応を売り込まなかった側の責任やん
泥水 @doromizu_inoko 2019年1月9日
kartis56 今回はテストして確認して頂かなくてはいけないものも多いですから、優先順位の高いものを確実にこなして年度末処理の帳票テストは手が空いたときにしましょう(フラグ)
ぼにゅそむ @yokoshimanaruko 2019年1月9日
もういい加減諦めてみんな西暦使いましょうよ。元号は日本の伝統だっていうかもしれんけどもともと中国大陸から入ってきたもんでしょ?中国のおさがり使うのと西洋のおさがり使うの、今の日本の立場だったらどっちが得ですか?どうしても伝統にこだわるなら皇紀のほうがまだマシ。
おろろ @fYe39CoQsPrbZVK 2019年1月9日
MxxTxxxx 客が対応せんでええ言うからよ。今回の対応ついでに次々回の元号対応と2038年対応入れるから2億上乗せ言うたらお前稟議通してくれんの?
梅酢 @coasms 2019年1月9日
元号、干支くらいの扱いになってほしい。年賀状とかには使うけど書類なんかには使わない、くらいだと助かる
ヘリオドール @heliodor_ruby 2019年1月9日
ざっくり見た印象では、システム作る側で元号変更への対応は勿論出来る。ただし、その元号変更対応の仕様・工数(&費用)を依頼側が承認しないと無理なので、システムがそもそも対応してないのは”依頼元の責任”。あと、対応できてても新元号発表後に新元号での検証作業が結構掛かるのでとっとと発表しろ! こんな感じの理解であってる?
spin_out @spin_over 2019年1月9日
SIerが取りまとめるような案件だと元号改定時の対応がシステム化してなくても、製造現場では付け足し提案もできないしね。最初の機能要件で顧客と折衝がされてないと、共通機能にすらならず、現場でなんとかしろという声のもと、個々の機能で元号選択ロジック作ってる可能性すらあるという。
spin_out @spin_over 2019年1月9日
heliodor_ruby そう。あと、今は開発側は他の案件がだぶついてる(システム開発したくても引き受けてが居ない)状態なので、実は改修引き受ける会社も少ないも追加で。
泥水 @doromizu_inoko 2019年1月9日
元号変更も検証がめんどいけど、4月28日(日)~5月5日(日)に平日が無いのもちゃんと覚えとかないとね、自分がやったとこだと平日処理で作った連携ファイルを土日の休日処理で取り込んで編集するってのがあって、平日が無いとファイルが作られて無かったり(0バイトファイルすらないから、これはこれで落ちる)消されずに前の週のファイルを読んで誤編集したりしたぞ(白目) あとから気がついて改修予算を計上されてもあげないんだからね! #突然のツンデレ
uenoshin @uenoshin 2019年1月9日
システムよりもUIが打撃を受けるのでは? 無数にある神エクセルの日付欄とか。
ぱんどら @kopandacco 2019年1月9日
(まとめタイトルに対して)いや、だから何? システムが予定通りに動いて予想通りにしか反応しないなら、この世にバグなんぞ出んよ。実装して運用しだしたら何かしら想定外の出来事が起きてしまうのがバグ。そもそもバグの原因って設計ミスや論理ミスだけじゃないかんね?
cocoon @cocoonP 2019年1月9日
まあ、シンギュラリティが訪れるまでの我慢ですよなあ
sk @sk_exe 2019年1月9日
既にサポートが終了しているバージョンの(新元号対応のアップデートの対象外となる) Office がインストールされている Windows PCで動作しているレガシーなシステムの場合、最悪「ハードウェアの買い替え」にまで発展するんだけどな。
あごにー @Agony_01 2019年1月9日
変更日に合わせてきっちり全部切り替えるのは相応に難しい。つーか普通なら突然変わるんで対応されてないのが当たり前。むしろ今怖いのは「なんでひと月も余裕あったのに対応できてないんだ」っていう人たちだろう。
cocoon @cocoonP 2019年1月9日
「元号のモジュール化で万全」みたいなことを言ってる人はたぶん内部的には西暦を使っているシスㇺの、かつ出力部の事しか考えてないよね。
キタムラシステム @kitasys 2019年1月9日
既存システムの新元号対応については、事前にはなかなか予想しづらい部分があるが、「なんで想定してないの?」とか言い出す人に対するテンプレ説明対応は準備しておいた方がいいかも知れない。そっちの方が想定しやすく、今後も使う機会はなくならないだろう。
おろろ @fYe39CoQsPrbZVK 2019年1月9日
想定はしたが、当時のクライアントは対応不要と判断したため未実装。が正しいんやろな。あと10年以上前で生前退位と対応期間一ヶ月を予測できてた人間はいないと思うで。更に言うなら当時の改元の認識は、崩御によって副次的に起きる突発的なもので多少混乱や遅れがあっても社会的合意の得られるものや
セマフォ @NoMoreLivesOne 2019年1月9日
流れ全く読んでないけど、現場から言わせて頂きますと、元号対応をしたシステムを用意するだけの金を積んでくれなかった人達の仕事をしなきゃいけないエンジニアの悲鳴だと思うよ。 デカいシステムなら余力があるからやってるだろうけど、そうじゃないミニシステム(言ってみりゃエクセルマクロ)の面倒見てる人たちの話と理解するもんじゃないの、これ。
刑事長/理事長 @DekatyouNy 2019年1月9日
ていうか急いで改修する必要あるの?ってのが本音。「改修完了まで『平成31年』で運用し、印刷等するときに修正する」じゃダメなのか?と。訂正印とか訂正の仕方とかあるんだから「運用でカバーできるところはカバー」、それじゃいかんのか?
稟@馬主ライフ @Rin_chaaaaaaaan 2019年1月9日
MxxTxxxx こういうこと言うやつはいざ客になったら提案を却下するからな。死ねばいいのに
セマフォ @NoMoreLivesOne 2019年1月9日
もっと言うならば、こんな人、リアルに大量に居るとは思えない。つまり、元記事は「可哀想な人たち」が居る事を想像し、自分は可哀そうではないと認識して悦に至るための文字列であって、これを事実と仮定して論じた挙句、無能と誹って喜ぶ精神性が問題じゃないのかねぇ。 究極、開発担当者と言うのは、やらねばならなくなったらやる生き物だから、大変だろうが何だろうが、やるよ。そう言う仕事を強いられる人たちを、無能と言うなら言えばいいさ。
茗荷昇紘 @masilite 2019年1月9日
cocoonP そうじゃないシステムがあるなら教えて。全てのコンピューターは西暦・英語が基準で、多言語向けにガワだけラッピングして対応してると断言できると思うけど。
エンプラ🍸@令和元年 @65cvn1 2019年1月9日
簡単だってこいつ等言ってるけど、コメント欄見るとそうでもないみたいだな。一ヶ月以内で一通りバグが無いかをテストし終えるまでやり終える事が出来る奴だけシステム屋やIT労働者に石投げやがれ。
CAW=ZOO@喪中 @CAWZOO 2019年1月9日
昭和はまあ仕方ないにしても平成は天皇自ら退位を求め、実行されることになったんだし本来去年のうちにさっさと発表してるものをどんどん遅らせたんだから、そこは政治が無能としてもそれに対応する時間はたっぷりあったやろ。あ、お金がなかったのか・・・
tanasinn @tanasinn88 2019年1月9日
satori_Lv35 文句ならまとめられた連中に言ってくれ。俺に言われても知った事じゃねえ。どうでもいいけど、あんた偽前澤に引っ掛かってるぞ。
おろろ @fYe39CoQsPrbZVK 2019年1月9日
masilite 役所の内部システムとかは和暦で入力してそのままテーブル突っ込んでるのあるな。あと公的書類の「明治・昭和・平成」とかなってんのは大体ベタ打ちで枠キッチリなんで、新元号どこに入れんのみたいなのもある。軽々しく断言しちゃう奴は関わらん方がええで、みんなの迷惑や
無式MT @MxxTxxxx 2019年1月9日
fYe39CoQsPrbZVK だからそれプログラマ側の視点だろ なんで自分の意見だけが正しいと思っちゃうんだよ お前いまコメント欄に自分だけの国家築いちゃってんの。なんで自分のこと国王だと思ってんの?
🈂トリ @satori_Lv35 2019年1月9日
tanasinn88 紛れもなくお前に言った、お前が書いたコメントに対して言った事だ。偽前澤情報はありがとう。
spin_out @spin_over 2019年1月9日
masilite システムはそうでもアプリ(モジュール)は違うんだよ。DBの生年月日から和暦変換するようなロジックで、一度UCTに変換して共通化しているものも当然あるけど、UCTを考慮してない(使ってない)アプリはいくらでもある。上で出てる西暦年-1988とかね。DBのコードがSなら昭和、Hなら平成とハードコーディングで出すようなロジックは現存する。
Live long & prosper @titan3xFnfxte 2019年1月9日
考慮するのと実際の対応は別物だからな。プルダウンメニューで、明治:M、大正:T,昭和:S、平成:Hに新しい「新平成:S」が追加されたら、アッサリバグになる。そこでSじゃなくてS2にしたり、Zにしたりして回避はできるがね。
Live long & prosper @titan3xFnfxte 2019年1月9日
もちろんラジオボタンで選択する方式で、項目がずらりと並んでるところに一個追加した結果レイアウトがずれるとかもあるし。未だに漢字二文字かどうかさえ公式発表がない時点で、ふざけんなだよなあ。
氷雨(鴎) @kamome54 2019年1月9日
「お前がそう思うんならそうなんだろうお前ん中ではな」シリーズ
たし @punimuchiya 2019年1月9日
kitayokitakita そんな馬鹿で無駄な拡張性を備えるためにその分の金を払ってくれる馬鹿で太っ腹なユーザなんていねぇよ
偽うどん王 @nnsi_mr 2019年1月9日
今まさに元号に対応するプログラムを作ったとしても、それを来る10年後20年後、若しくはもっと後の改元時に運用システムやハードと摺り合わせるにはそれなりのコストも時間もかかる…ってのはまぁ普通に仕事してたら分かりそうなもんなんだけど。そういうのすら理解出来ないヤツに先見性も有益な知見もあるワケないんだから偉そうに後出しでマウント取っても誰も聞かないでしょうね。
spin_out @spin_over 2019年1月9日
例えば未だに現役の銀行系のCOBOL85で機能拡張してない場合、UCTって引数以外の取得方法無いような気がするんだが。うろ覚えだけど。COBOLで帳票出すシステムまで生き残ってるかどうかは流石にわからんが。
あきなすび @akkonline 2019年1月9日
masilite 和暦で入力をするシステム画面ってのをご覧になったことありませんかね?内部的に西暦で持ってても内部値と外部値の変換はOUTPUTだけでなくINPUTでもあるし、各I/F毎にチェックは必要なんですよ…
rti @super_rti 2019年1月9日
帳票があることを考慮していない時点でド素人の意見だよなあ。
jlzjlz @jlzjlz 2019年1月9日
MxxTxxxx とりあえず、このコメント欄内ですらあなたのコメント群は2・3周の周回遅れ感出てますよ。数時間、十数時間を経てあなたと同じようなこと書いてた人が何人も一定の理解を示した後っぽいです。
cacao10 @cacao80 2019年1月9日
まぁそういうのを考慮して作られてないものは多かったりするんだろうけど… 一部の人なんかしかしらない、一般の人の目に触れないけど無いとすごく困ったりするバックグラウンドで動いてるような謎の機器なんかは、アップデートも物理的にROM焼かないと出来なかったりするんです。itってパソコンだけじゃないからね。
funpan @funpan2015 2019年1月9日
masilite date型は言語で用意する物なんで、そういう変数型のないC言語とかでは和暦の年を整数型でもってるとかありそうな。
雑魚寝 @zakone_world 2019年1月9日
これからの懸念を表しただけで「無能」と断じるのは僕にはちょっと出来ないですね… まだ何も起こっていないのに
たし @punimuchiya 2019年1月9日
kitayokitakita つーか根本的に勘違いしてるみたいだけど、システムは元号マニアが元号変換して遊ぶためのものではなく業務目的のために作るんであって、そのためには元号拡張性とバッティングする制約だって山ほどあるんだよ。システム分野ではその中でバランス取ってなるべく簡単に変えられるようにしようって話にしかならんし、「元号拡張性こそが第一、どんな文字列でも即時対応出来なきゃね」なんて話は分野が違うから、同好の元号マニア同士でしてくれ
憑かれた大学隠棲:再稼働リプレイスに一俵 @lm700j 2019年1月9日
ようするに「担当者が有能かどうかはさておき、前任者が有能だったかは改修してみない限りわからない」という
Zinc in Osaka @zincinosaka 2019年1月9日
元号の不便を強調したり現在の皇太子同妃両殿下を揶揄する記事を載せるのには皇室の権威低下という迂遠なる隠れた目的があるのではないかと勘ぐってみたくもなる
以前敵 @izenteki3y 2019年1月9日
一つの独立したシステムで西暦対応はまだ自前でどうにかできるかもしれないけど、 10のシステムが連携していて、連携に和暦部分と西暦部分が混じっているのが複数あることを想像してほしい いまだに元号を必須としている業界のシステムはそうなんだよ…
寺田33 @tera3333 2019年1月9日
仕様書に「改元に対応」相当のたった数文字をいれられるのにいれられなかった発注者とか要件定義に関わった人間の責任だと思う。システム屋は期間内に仕様を満たしてるものをつくるのが仕事。むしろ仕様書にない改元対応機能をいれて工数オーバーする方が無能という見方もできる。
寺田33 @tera3333 2019年1月9日
5年くらいで使い捨てる想定で改元がなくてそっちの方が結果的によかったケースも多いはずなので改元対応仕様にしないという選択肢も完全否定できないとも思う。
黄色いかまぼこ @yellow_chikuwa 2019年1月9日
最終的にエンジニアや関連業界の血みどろの努力で事なきを得たとき、「な?大したことなかっただろ?」って言いそう。
中崎まこと @makutu555 2019年1月9日
Unicode で新元号のコードポイントは「U+32FF」らしい。まぁ、役所の元号システムは「元号が変わった場合、既に発行した物は現元号に自動的に合わせて解釈する」らしいけど、IT屋をやっていた口からは「大丈夫」とも「駄目だ」とも云えん。ただ、解っている改元なら「間に合わせられる様に早くしてくれ」と思う。
まうみん @maumin66 2019年1月9日
なお即位後の発表にすべきとする勢力がいた模様
鹿 @a_hind 2019年1月9日
偉そうに意見垂れてる奴等はシステム開発なんぞやったこともないで吹いてるただのアホ素人と前もって周知出来るのにやらずにシステム屋苛々させてる国が無能なだけ。 そんなに昔から準備しておく金と時間支払ったものだけが文句を言いなさい。
ジャカルタ読み専ブラザーズ @_oinarisan_ 2019年1月9日
新元号が「The end of genesis」になって「ほげでテストすればいいだろ」とか言ってるアホの帳票が全部爆死する未来こないかしら
スーパーNOOB @hippop2 2019年1月9日
いや、元号の改修自体は割りとあっさりできるかもだけど、検証が更にあって 通常のトラブル業務、開発なんかをこなしながら 平成に変わってから納入したシステムのうち何件改修依頼がくるかわかんないんだから、 そら改元よりもかなり前からやっておきたいやろ ネットワークに繋いでない遠隔出来ないシステムだって山ほどあるやろうし、客先訪問の時間だってあるんだから
papa_wolf(PA製作所)@求職活動中 @PA_papa_wolf 2019年1月9日
例えば面接で「キミね~平成70年から昭和25年まで働いたって書類作るほど無能なの?バカなの?」っていうのを無くすために色々システム屋はテストしてるわけで……。クレームが来ても人材担当が「お前がチェックミスするのがバカなんだよ」って言える会社ならいいけどそういう会社は少ない。そしてそういうのを素通りさせるような会社とそんな所に頼む下請けは死ぬ。というかシステム要綱に書いてあるから就職したらテスト要因として1度は読むはずなんだけど?
tibigame @tibigame 2019年1月9日
江戸時代~もっと前の出来事を表すのに元号しか使っていませんという人だけがシステム屋に石を投げなさい。
undo(おネムだよ) @tolucky774 2019年1月9日
3月決算の書類を4,5月で用意しなきゃいかんのですけど、この時期の決算の書類は重要なんで、納期に間に合わないとクビが飛ぶやつが…。それもあって経理はかなり怖いよね
undo(おネムだよ) @tolucky774 2019年1月9日
ないと信じたいけど、期間指定のfrom toを和暦で判断してると当然不具合でますよ
Bauer @WorldLeaf 2019年1月9日
なら有能なシステム屋を屏風から出してみるが良いさ。そうでなくても有能なシステム屋を作る先行投資を怠っただろうに
undo(おネムだよ) @tolucky774 2019年1月9日
今年の秋には消費税増税と軽減税率が待ってるぞー。消費税率1桁で…とかあるんやろなー(汗)
undo(おネムだよ) @tolucky774 2019年1月9日
消費税率が8%になった時に、システム改修がお金がなくてできないから潰れたスーパーがあったよねえ
麻樹・あるいはまお @maki_miquette 2019年1月9日
元号を明治→1大正→2昭和→3平成→4ってしてる場合の方がまだましなのかなぁと思いつつアルファベット頭文字にしてる所とは別の問題が出る事位はいくらメカ音痴でも想像はつくぞ。そして医療事務も可哀想な事になってるなぁ、発表も改元も見事にレセ請求の山場と被っとるやんけ。
tibigame @tibigame 2019年1月9日
MxxTxxxx 江戸時代のように10年程度でころころ元号が変わっていればこんなことにはなってなかったと思うのですよ。
tibigame @tibigame 2019年1月9日
マジレスすると今時元号とか使っている仕事場(政府)が無能だから転職しろになってしまう。
しぇりりん(平成ジャンプ無限大組) @m_sheririn 2019年1月9日
あー、と思ったのは自動車税の通知の話かな…平成31年度と書いてあっても有効ですから!って事(そもそも僕の車の次の車検は平成32年だからなぁ…そんな年はない
undo(おネムだよ) @tolucky774 2019年1月9日
kitayokitakita 帳票は画面と違って限られた面積に多くの情報を配置するのでそんな冗長なことは大抵できません
野獣後輩 @yaju5123 2019年1月9日
tolucky774 そー言えば決算まとめる時期とシステム更新が被るのか……。 酷いことになりそう
undo(おネムだよ) @tolucky774 2019年1月9日
画面は拡大できるからデフォルトの表示サイズのフォントがでかくてもいいけど、帳票の面積は有限だし、フォントサイズもこれ以上は小さくできないというサイズはあるので。大体客に出す帳票は確認後の意味があるから虫眼鏡をつかわないと読めないフォントサイズにはできんのよ
深月 慧🌧️巡星レイヴンと化したにゃつめいと @Key_Hukatuki 2019年1月9日
つかここ元号についてのまとめなのになんで消費税の話が出てくんだろ。 あれ場合によっては回避できるって聞いたけど
spin_out @spin_over 2019年1月9日
masilite Cの場合、そこから和暦にするには各業務で定義するしかないし、DBやヘッダに既に定義がある場合それを使うかそこに追加して分岐を書くなど業務毎のカスタマイズになる。結局共通化というのは一つの言語と仮定しても困難。
RGB000 @19666_61 2019年1月9日
昭和は60年以上続いたってことも加味したい
funpan @funpan2015 2019年1月9日
masilite あれはある瞬間から何秒たったかって形で時間を表す物で、それから西暦何年ってのを出すのにはちょっと計算しないといけなかったかと。
茗荷昇紘 @masilite 2019年1月9日
Cは組み込み系に使われる。元号の関係する業務系ソフトの場合、もっと高級な言語が使われる(Date型も当然ある)から、あまり関係ないのでは。Microsoft Accessの場合VBAが使われる。
spin_out @spin_over 2019年1月9日
masilite C/C++のクラサバ系業務なんていくらでも生き残ってるよ・・・。
Denullpo S. Hammerson @denullpo 2019年1月9日
まー、昭和時代の常識で組まれたどレガシーなシステムが未だに残ってたりもするわけで、世の中そんなに甘くないってやつ。んで、そのどレガシー突然持ち込まれて1ヶ月で対応しろ案件とか捻じ込まれるのやだぞ。もし遭遇したら自称有能くんに全部丸投げしてあげるから名乗り出ときなさい。
ウメ(モッコス) @ume_86 2019年1月9日
言われてみればなるほど、今年元号が変わっても来年また元号が変る可能性もあるのだからな。そして何度元号が変っても更に変る可能性は続くという…
ハラタイラ @harataira0301 2019年1月9日
改修は出来るよ。お前らが金を出せばな。 口しか出さない部外者は消えて。 って感じ? 改修の難易度と、それを実際にやってもらえるかは別問題なんですよ。
G@回転中 @G_rolling 2019年1月9日
年間で平均5プロジェクト=5つの顧客のシステムを手掛けているシステム屋さんが過去6年間で30顧客のシステムを担当していた、というケースだと一か月しかない場合は30顧客のシステムの対応を一か月でやることになるんだけど、どう考えても無理ゲー。
Denullpo S. Hammerson @denullpo 2019年1月9日
それよか、明治から平成まで合字のアレ使っててShift_JISで2バイト固定とか、既に詰んでるような仕様にどう立ち向かうのか興味
茗荷昇紘 @masilite 2019年1月9日
akkonline 役所だと生年月日を和暦で入力するシステム(元号は番号で入力)は普通だね。共有化モジュールを作るとしたら当然、入出力双方向に対応したものをセット(西→和・和→西)で作るのを想定する事になる。
都幾川 沙月 @SatsukiFox 2019年1月9日
無能なのは30年間システムをほったらかしたエンジニアではなく、彼らに金を払わなかった経営層なのです。しかるべき金を払えばエンジニアは改修してくれますし、それができなければ切り捨てて別の人を雇える程度には世の中に溢れてます。
民衆を導く自由のぱるえふ @paruehu 2019年1月9日
punimuchiya 漢字2文字で読み書きしやすくて、いつから始まるかはっきりしてるけどそれでも駄目なんですか、、?
T.Nakagawa @nora1962 2019年1月9日
元号が変わるのは分かっていても、そのために費用いくら使うかはITエンジニアだけで決められない。誰も触れない塩漬けものもあるし、入力関係がどう作られてるかもある訳で。
都幾川 沙月 @SatsukiFox 2019年1月9日
paruehu たとえ漢字2文字でも、現行のWindowsとか使ってる限りShift_JISは存在する(≒ダメ文字のリスクとかも然り)ので、とりあえず日本社会がWindowsに依存しない状態になれば駄目じゃないかもしれませんねぇ。
ゆうき @F001Yuki 2019年1月9日
ちゃんとしたプロ「完璧に作ったが、完璧に動くかは実際やってみないとわからない」アマチュアなプロ「完璧に作ったから大丈夫」っていう話やろ。いままでただのひとつも間違えたことないんかい……
tgttr @tgttr4 2019年1月9日
技術的難易度で語る費遠いけどそうじゃなくて障壁はコストの話なんだよね。 誰が金払うの?誰が作業するの?
SAKURA87@多摩丙丁督 @Sakura87_net 2019年1月9日
まぁまとめでいっている事は間違ってはないんですよ。ただ末端で嘆いている人がどうにか出来る範囲じゃないっていうだけで。実際柔軟性を持たせたシステムを開発する事も技術的にはできるんだけど。「対応できる」と「できる対応」というのは別物だからね。まぁ叩くなら末端じゃ無くて上流を叩けって話やな。
民衆を導く自由のぱるえふ @paruehu 2019年1月9日
SatsukiFox なるほど、素人ですがなんとなく理解出来ました。ありがとうございます。
パスター丁 @takemon230 2019年1月9日
簡単にできるから自社改修すればずっと安いし打ち合わせもいらないから早く済むよ!元号1つ追加するだけだから簡単簡単! なお弊社で行った改修ではないため不具合発生時に対応することはできません
都幾川 沙月 @SatsukiFox 2019年1月9日
ぶっちゃけ文字コードとかの話になると、極論すればJIS X 0208の制定(1978年なので今からちょうど40年前)のあたりから「ダメ文字」のフラグは立ってたわけでして。とはいえ裏を返せば「40年後の社会のIT化や労働力不足、エンジニアを取り巻く就労環境を予想して問題を起こさない規格を作れ」なんて無理ゲーも甚だしいので、どうしようもないでしょうねぇ。
gaheki @gaheki 2019年1月9日
「そっちの方が入力しやすいから」「この入力方法でないと困る」で変則的な入力方法強く要求されれば仕様に盛り込むしかないんだよなぁ…  単純な gee/mm/dd 方式ならどれだけ楽に出来た事か
TD-M18もっこㄘん @Mokko_Chin 2019年1月9日
過去事例より60年や30年程度で一回変わるものの対策を金と時間かけて予め組み込んでも一度も使わずに終わるかも知れないしな。コストとリスクの天秤。
blade0@オッ㌠ @blade0 2019年1月9日
とりあえず漢字3文字にすんなよ、っていうプレッシャー掛ける方々はいるはず。…奈良時代まで戻れば4文字あるみたいだけど
おらおら@ @oraora1966 2019年1月9日
じゃあ元号が変わる時に工数的な余裕が何ヶ月あればいいんだろ?それとも何年? もちろんシステムによって大きく違うだろう事はわかるけど。 サマータイムの時は専門的知識を持った人達が検討し「最低5年かかる!2年じゃ無理!」と大々的に声明を出したから頓挫してくれたけど、元号についてはそういう話は聞かないし…。
あごにー @Agony_01 2019年1月9日
平成32年のまま運用してかまわないものはしばらくそのままになりそうですねぇ・・・
spin_out @spin_over 2019年1月9日
IT技術者の絶対数も減ってるしね。
nismo @NnismoO 2019年1月9日
初手の想定してなかったの?はビジネスシーンでアホが頭使わずに賢ぶるために有効なワードだからな
spin_out @spin_over 2019年1月9日
中国なり韓国に発注して直してもらえばー?(かつて海外にアウトソーシングすると言って弊社とのお付き合いがなくなった客に対して)
JIT_MIRUMIRU @JIT_MIRUMIRU 2019年1月9日
「立法機関に通報」ボーイ(MxxTxxxx)が周回遅れのコメントつけてるね。参考:https://twitter.com/JIT_MIRUMIRU/status/1082988132146892800
鹿 @a_hind 2019年1月9日
コストかけ過ぎない範囲で改元対応どうする?ってのは影響調査も対応検討もしてる所の方が多いだろうよ。 薄っすらこうすりゃいいよね、って絵面はあるから毒づいてもそこまで慌ててない。 ただし、実際の元号が発表されないと改修出来ないものはあるし略称がM・T・S・H以外になればいいけどこれら(特にHと)被せてきたらアビ・インフェルノが顕現するかもしれないのに発表が改元一か月前だからふざきんななわけで。
たし @punimuchiya 2019年1月9日
paruehu いや、俺のレス先の人はもっと多い文字数でも対応しろって言ってたからそういう言い方になったけど、二文字の制約があるならだいぶ話は違うね。まあそれでも層分けとパフォーマンス考えたら変換も計算も設定も完全に一ヶ所って訳にはいかないし即時対応出来る実装は基本無理よ
初瀬 神楽 @Kagura_d34272 2019年1月9日
元号の場合、システム修正の有無はともかくテストは発生するし、エンジニアの数は急には増やせないから「発表から改元実施までの期間が短いと、その間にテストできるシステムの数」はどうしても不足するんよね。それも含めて「1ヶ月は足らん」のとちゃうん?
お茶漬け @cha_zuke_ 2019年1月9日
どうして部外者はこうイキってしまうのか
dag @digital_dag 2019年1月9日
punimuchiya うーん…。例えば制作途上のシステムで顧客の立会を受けて、顧客が途中で「この単語実状に合わないから変えて」って言われた場合は改修になるんだろうけど、その場合改修後の表示を本当に全部チェックしてるの?全部きっちりやろうとしたら天文学的な作業量になると思うんだが。
鹿 @a_hind 2019年1月9日
oraora1966 サマータイムを考慮していないシステムにサマータイムの仕組みを組み込む+連携する他のシステム、他社の手を出せないシステムも同時期に改修されないとうまく動かない可能性があるのでいくら時間があっても足りないです。足並み揃える必要があります。お偉いさんの一時のお気持ち風情で着手する話ではありません。 一方改元対応は和暦表示したり日付変換したり、って仕組みは元々存在するものなので負荷のレベルが全く違います。ただし影響範囲はきちんと調べないといけない。
たし @punimuchiya 2019年1月9日
digital_dag 「単語を変える」という素人らしく曖昧な聞き方をされるとはっきり答えづらいんだけど、仮に元号みたいにその単語からの逆変換や計算があるようなものならマジで全部やるし、別に天文学的にもならないよ
都幾川 沙月 @SatsukiFox 2019年1月9日
digital_dag システムの重要度によりますが、金が絡むシステム(銀行とか証券会社とか)なら全部テストやり直しですよ。普通はそうならないように事前にネゴってきちんと設計しておくわけですが。
dag @digital_dag 2019年1月9日
punimuchiya 何故変更の可能性のある元号で計算させてるシステムにしているのか分からない。そういうのは西暦に負わせる役割に思えるんだが。>仮に元号みたいにその単語からの逆変換や計算があるようなものなら
spin_out @spin_over 2019年1月9日
digital_dag 西暦だと年のエリアは4バイト必要だけど、年号(コード)+二桁なら記憶容量は3バイトで済む。という時代があったんです。
dag @digital_dag 2019年1月9日
SatsukiFox やっぱりケースバイケースだよなぁ。
spin_out @spin_over 2019年1月9日
西暦でも下二桁で記録というシステムがあったために2000年問題も起こったわけだし。
rice_of_sato @gohan_of_sato 2019年1月9日
digital_dag 入出力は年号、内部管理は西暦orシリアル値みたいなシステムだと、どうしても変換がはいるからね。ユーザの要望があれば、入出力に年号を使えるようにせざるを得ない。
たし @punimuchiya 2019年1月9日
digital_dag 言ってることがよくわからない。変換して西暦で計算するにせよユーザIFが和暦なら初動は和暦なんだから計算に噛むのは不可避だと思うが