18

限定公開の新機能が大好評!

プライベートなツイートまとめの共有がもっと簡単になりました。フォロワーだけに特別なまとめを公開しませんか?メンバー限定はメニューから設定可能です。詳細はこちら

ログインして広告を非表示にする

コメント

  • ひふみよいつ @hihumi_yoitu 29日前
    2000年問題みたいにまたインドのシステム屋が人知れず活躍するのか?
  • 緑川だむ @Dam_midorikawa 29日前
    これを期にゼロベースでシステム構築しようと言ってさらにデスマ発生
  • 柏木彰二 @GmailShoji 29日前
    いい加減全ての書類を西暦でOKにしてほしい、でもってシステムは西暦x年x月x日に元号設定して計算できる方式にすれば手間もかからんと思うけど・・・・全部作り直しだよねー
  • まさかなまき @MASAKANA_MAK 29日前
    ワイ、昭和生まれ。2つ3つの元号をまたぐことになるのって、明治生まれのおばあちゃんだけかとおもってた。ワイにとっては明治って歴史上の元号でしかなかったんだけど、ある世代からみたら昭和も歴史上の元号になっちゃうんだろうなぁ。
  • ISW @ISW007 29日前
    平成になったときに、これからは社内文書は西暦で統一するという通達を出したくせに、結局は元号を使い続けた某大手電機メーカーにいたことがある。それが原因で潰れかかってるわけではないだろうが、なんとなく思い出した。
  • なんもさん @nanmosan 29日前
    元号使わなきゃいけないのは公官庁と出入りの業者さんですな。そこは法律で決まってるんでしょうがないんですけど、この法律ができたのが1979年でして、すでに元号を使わない世代が増えてた時期でもあり、元号を使い続ける根拠づくりためだけの法律として制定当時も批判は多かったです。
  • なんもさん @nanmosan 29日前
    いっそ新元号の頭文字だけ先の先まで決めておけばいいのに。
  • LCO @f_lco 29日前
    現在のWindows7以降はレジストリで元号管理してるので、皆様お手持ちのPCに関してはいつも通りWindows Updateを掛けるだけで新元号対応します
  • くりあ/CLEA-R-NOT-3 @Clearnote_moe 29日前
    「頭文字がMTSH以外」「漢字二文字」を守ってくれたら大丈夫です!守ってくれなかったら死にます!
  • いくら @YamadaIkra 29日前
    2020年1月にはWindows7のサポート切れも来るよー
  • 野良馬 @nobody_oyaji 29日前
    「win7のサポート切れてもXPみたいに使い続けるからへーきへーき」という企業はある(確信
  • Tsuyoshi CHO @tsuyoshi_cho 29日前
    新年号はおいておいて....行政業務の書類のデータとしては西暦、賞状とかみたいに、記念の記述として残すときだけ年号にしてほしいんだけどね...文化としてはそれで問題ないと思うんだけどな~。
  • × @cv45ValleyForge 29日前
    元号テーブルに新元号のレコード追加と、現元号レコードの対応日付の修正だけで工数1人日を1人月位に見せるテクニックが求められている。で良いのかな。
  • 毛海王 @masu_ooyama 29日前
    あと一月ずらして連休に合わせてくれればよかったのに
  • アルビレオ@炙りカルビ @albireo_B 29日前
    cv45ValleyForge 修正量だけで工数見積もったりしないよ。テーブル更新だけで大丈夫か(元号が増えることを想定していない実装が紛れ込んでたりする可能性)の事前チェックと変更点のリストアップ、それと修正後のテストを無視した見積もりは正気とは思えないです
  • seidou_system @seidou_system 28日前
    でも事前にわかるだけ崩御よりマシなんだろうな…
  • かめっち@稀に飯テロ @N_Cults 28日前
    事前に元号わかるだけでもマシじゃないかなぁ…(社畜感)
  • 想 詩拓@文芸サークル『文机』 @sou_sitaku 28日前
    みんなが恐れるほど大変なコトじゃないよ。大抵のシステムではデータベースの元号マスタに1つデータが加わるだけだと思うし。あるいは、元号を変える小さなモジュールに変更を加えるだけ。
  • Naruhito Ootaki @_Nekojarashi_ 28日前
    不敬とかいわれるかもしれんが、私が開発してた戸籍のシステムは昭和天皇が元気で平成のへの字も出る前から対応してた。ま、新規開発だったからね。
  • 想 詩拓@文芸サークル『文机』 @sou_sitaku 28日前
    それに2000年問題の時は00年が1900年と勘違いしてしまう弊害があったけど、新元号元年を平成30年と間違えても大した弊害は生まれないと思うので、徹夜で対応なんてこともしなくていいと思うよ。
  • Naruhito Ootaki @_Nekojarashi_ 28日前
    そして既存システムは平成のときにすべて洗い出してるはずだから、今ゴタゴタなのは無能の証明だな。「もう増えないだろう」なんて思い込みとか馬鹿の極みだ。
  • フローライト㌠ @FluoRiteTW 28日前
    いや、前評判の「元日改元」よりも正月休み取れる分だけありがたいと思うよ。こちとら別に2018年4月からでも良かったけどな。
  • フローライト㌠ @FluoRiteTW 28日前
    ここで新元号が「Tから始まる3文字」だったりすると地獄の釜の蓋が開く。さすがにそれは無いだろうが。
  • phantive @phantive 28日前
    平成改元とかy2kとか経験してきてるのに、、、 こんなことを言ってるのは、若い人達なのかな?
  • 虐殺仮面 @TruthorDare1984 28日前
    もう改定後3年くらいを猶予期間として「元号併用可」にしねえ?w
  • × @cv45ValleyForge 28日前
    albireo_B それ、平成対応時に潰さなかったの?( ゚д゚ )ポカーン>元号が増えることを想定していない実装が紛れ込んでたりする可能性
  • ○○もへじ @marumarumoheji 28日前
    未使用の平成 31 年硬貨が後で高く売れるかもしれんぞ。
  • アルビレオ@炙りカルビ @albireo_B 28日前
    cv45ValleyForge DelphiもVBもとっくに平成になってから生まれたものです。そういったプログラムのすべてが元号の追加を考慮してるなんて考えてるんですか?VBでUI作ってたら年号が三択固定なんていくらでもありそうじゃないですか。90年代に作られたものでも2000年問題に対応していなかったのがたくさんあったのですよ
  • アルビレオ@炙りカルビ @albireo_B 28日前
    設計上は年号の変更に対応しているシステムでも実装の手抜きやミスで一部が対応していない可能性はいくらでもある。テストではそこまでチェックしていないことも多い。だから「ちゃんと対応してるはず」のものでも再チェックは必要。しっかりしたとこなら修正箇所ゼロのはずでもチェックとテストの予算を計上する案件です
  • アルビレオ@炙りカルビ @albireo_B 28日前
    一例としてC#やVB.NETで使われている.NET Frameworkは和暦に対応しているので書式指定のみで年号を表示できる。新しい年号が確定したらMicrosoftがライブラリを更新するはずで、プログラム側の変更なしで新年号に対応可能。でも「平成」や「平」は表示できるけど「H」のような英字表記は出力できない仕様なので、英字で年号表記したい場合は変換のためのプログラムを組む
  • アルビレオ@炙りカルビ @albireo_B 28日前
    年号をプログラム側で管理していればテーブルなどで変更可能だけど、.NETだとライブラリに管理させた方が楽だし問題も起きにくい。漢字年号→英字年号の変換テーブルを作っておくのが理想だけど、年号をテーブルで管理するならともかく「ただの文字変換表(それも3レコードのみ)のためにわざわざテーブルを作るのは手間がかかるため、ハードコーディングしているものはたくさんある
  • アルビレオ@炙りカルビ @albireo_B 28日前
    そういうコードを組んだ人がすでに去っていて「ライブラリを更新すればプログラムの変更はいらないはずだよね」と思ってたらプログラムは「知らない年号」のためにエラーになったりする。みたいなことはあちこちで起きると思うぞー
  • くりあ/CLEA-R-NOT-3 @Clearnote_moe 28日前
    「自分の作業を簡単にするために適当に作ったものが、なぜか全社展開されている」とか「すぐリプレイス予定があるもののつなぎ対応ということで納期最優先で作ったのに、そのまま十数年使ってる」とか「原型を作った会社も改修した会社も飛ぶか消えるかしてて、ソースも仕様書もなにもない」とか「人間が入門書を理解してるかすら怪しいレベルの公称ベテラン派遣が出してきたバイナリが受け入れ試験なしで稼働中」とかの話がちょくちょくあるこの業界で、「テーブル変えるだけ、できないのは無能の証」って遠い目になる。
  • くりあ/CLEA-R-NOT-3 @Clearnote_moe 28日前
    「平成対応時にやってるはずだから」でぶっこめるのは、自分で作ったか同等に動作把握してる小規模システムだけだと思う。さすがにメインフレームは消えてても、古いシステムのラッパーだけで対応してたなんてのは世の中にゴロゴロしてるんじゃないの。他人が作った手を入れた部分は信用できない。それこそ「エンドユーザーのちょっと詳しい人が手を入れて、マスターから参照せずにハードコーティングされている」などの可能性も考えたら、全システム一から再チェックですよ。
  • くりあ/CLEA-R-NOT-3 @Clearnote_moe 28日前
    たとえばさー、元号漢字三文字にされるだけで、帳票印刷回り全部書き換えじゃん?テーブルやライブラリ変えるだけで、枠からはみ出だすとか文字が重なるとかのレイアウトの問題だけでなく、それに起因して変なコンフリクトやオーバーフローおこして全体止まったりしない?最低でも再チェック必要でしょ?
  • くりあ/CLEA-R-NOT-3 @Clearnote_moe 28日前
    予測できる可能性を考えいないのは無能、と他人を批判している人間が、元号三文字の可能性はない、と言い切るならはあそうですか、ですが。
  • 泥水 @doromizu_inoko 28日前
    わかりやすいのだと選挙のはがきとかの役所から送られてくるやつだな。 はがきに「平成」の文字は探せたかな?これが1文字や3文字になったときにデザインが崩れないかな?さあ他にもシステムで出してる通知や納付書がないか探して打ち出してみよう!もちろん元号切り替え日にはトラブル対応で朝から役所につめてもらうし、夜間処理は何かあったら困るから立会いお願いねSEさん(死
  • sako @SSako86 28日前
    Clearnote_moe 可能性の有無のように雑な分類をするようではだめでしょうね。可能性の高さとその可能性に対応コストを掛けた期待値の見積もりが適切にできるかが重要で、元号が3文字になる可能性は非常に低いからそれよりも可能性の高いことにコストを掛けるという判断は妥当です。
  • くりあ/CLEA-R-NOT-3 @Clearnote_moe 28日前
    SSako86 それよりも可能性の高いところにコストかけてやることが「元号変化に対応できないシステムの存在を懸念し問題が起きないように事前確認すること」ではなく、それをしようとする人を小馬鹿にすることというあたりを批判してるんですが通じませんでしたか?
  • くりあ/CLEA-R-NOT-3 @Clearnote_moe 28日前
    元号三文字なんて「システムが想定してなくて問題発生する場所がわかりやすい例」の一つでしかないのに、そこにこだわられてもな。
  • sako @SSako86 28日前
    Clearnote_moe 元号の文字数じゃなくても何でもいいのですが、事前確認する項目にほとんど起こりえない項目を入れて、重要な項目の確認にかけるリソースを削ることになったら、小馬鹿にされても仕方がないでしょうね。
  • くりあ/CLEA-R-NOT-3 @Clearnote_moe 28日前
    SSako86 「ほとんど起こりえない」と言い切れるのは、「リスクとして洗い出され、それがリスク評価された結果」であって、それもせずに「ほとんど起こりえない」というのは根拠を示せない個人の感想ですね。元号の文字数が過去どうだったか、と調べることも、調査の工数です。
  • tamama @tamama666 28日前
    そういえば聖武天皇のときに四文字元号がありましたね もし四文字とか来たらシステム改修大変かもw
  • sako @SSako86 28日前
    Clearnote_moe 元号が英語になるリスクを考慮しますか?しないとしたら3文字になるリスクを考慮することとの違いは何ですか?
  • くりあ/CLEA-R-NOT-3 @Clearnote_moe 28日前
    SSako86 いやそもそも論として、あなたの主張は「検討コストをかけることの批判」なのに、「元号が英語になるリスクを考慮しますか?しないとしたら3文字になるリスクを考慮することとの違いは何ですか?」などと、「検討コストを私に要求してる」時点で、持論が破綻してると気づいてますか?
  • くりあ/CLEA-R-NOT-3 @Clearnote_moe 28日前
    「なんで?」という疑問が出て、その疑問を解決するために動いたなら、それは工数が増えたってことです。それを計上することの批判してる人がいるから、「リスクアセスメントシート1枚つくるのもタダじゃない」って話してるんです。「LA評価で和暦が他国言語になる確率は低い」って判断するのも工数計上すべきです、特に「考慮しますか?」なんて問われたらなおさら。「自分が一瞬で判断できるから工数計上しない」なんていうのは「絵かけるんでしょ、ちゃっちゃと書いてよ、タダで」と変わりません。
  • アルビレオ@炙りカルビ @albireo_B 28日前
    albireo_B albireo_B なぜ元号の選択肢を「3」にした…こういう時はコメントの修正機能が欲しくなりますね
  • sako @SSako86 28日前
    Clearnote_moe あれを「検討コストをかけることの批判」だと思われるようではこれ以上いっても無駄ですね。
  • くりあ/CLEA-R-NOT-3 @Clearnote_moe 28日前
    SSako86 ええまあ、「平成対応などですでにシステムが対応しているはずだから検討工数の形状は必要ない、それ必要なのは無能だから」という意味のコスト不要というコメントに対する批判を見て、「元号が3文字になる可能性は非常に低いからそれよりも可能性の高いことにコストを掛ける」とまるでコストの振り替え先があるかのような読みをされた時点でわかってました。
  • sako @SSako86 28日前
    フレーム問題なんて知らないんだろうなぁ。

カテゴリーからまとめを探す

「システム管理・運用」に関連するカテゴリー

ログインして広告を非表示にする
ログインして広告を非表示にする

「システム管理・運用」の注目キュレーター

カテゴリーを見る