パスワードを忘れた? アカウント作成
13477358 story
プログラミング

難しくはないが大きな工数が予想される改元対応 213

ストーリー by hylom
昭和と平成しか想定していないテーブルとかあるんじゃないですか 部門より
argon曰く、

政府が天皇陛下の退位日を2019年4月30日とする政令を決定、5月1日より新元号となることが決まりました(朝日新聞毎日新聞NHK)。

これに対し、その対応について大手システムベンダーがコメントを出しました(日経ITproの記事1記事2)。

これによると、NTTデータは「元号改正による修正は限定的」、日立製作所は「平成から新元号への対応は比較的容易」としているいっぽう、富士通は「洗い出しとテストの負荷が大きい」としています。

NTTデータや日立製作所は作業工数が不要だと受け取られそうな不用意なコメントですが、富士通は調査やテストの工数について言及していてさすがだなと思いました。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by OnlyInJapan (48277) on 2017年12月12日 0時26分 (#3327984)
    大学院時代にアメリカに留学して驚いたのだが
    アメリカでは誰も昭和とか平成は使わず、年は西暦を使っていた
    なので平成が終わってもアメリカでは何の混乱も起きない

    和暦なんて海外ではもうどこも使ってない
    アメリカを見習って和暦なんていう時代遅れなものは廃止すべきだろう
  • by manmos (29892) on 2017年12月11日 17時56分 (#3327683) 日記

    今、免許更新でも有効期限「平成」って書かれるんだよなぁ。

    次の元号が決まってからだとどうなるんだろう?
    てか、私の更新平成31年だ。多分決まってる時期だから確認できる!

    #来年だと思ってた。

  • by vax730 (32985) on 2017年12月11日 18時04分 (#3327692)

    だと,画面表示を調整しなくてはいけないのでいやですね。

  • 日立のコメント (スコア:2, すばらしい洞察)

    by Anonymous Coward on 2017年12月11日 17時50分 (#3327677)

    「NTTデータや日立製作所は作業工数が不要だと受け取られそうな不用意なコメントですが」
    ってあるけど
    元記事見ると「昭和から平成への元号変更の際に培ったノウハウを生かせるためだ。」
    ってあり
    一度元号関連の処理やっているので内規があるってことじゃないん?
    不用意ってのはちょっと悪意ありすぎるような

    • by Anonymous Coward on 2017年12月11日 20時16分 (#3327778)

      客:日立さん、ノウハウあって工数少なくて済むんだって?じゃ予算これだけだからあとはよろしく
      日立:おい、客の予算これだけだって。ノウハウあるだろ?どうにかしろ
      〇〇システム:あの頃の技術者はみんな定年でいなくなってます。今は派遣と〇国人ばかりです。
      日立:・・・。

      親コメント
  • 真面目に答えてロクな事は無い。
    NTTD、日立はそこを学んだんでしょ。
    --

    “人生の大半の問題はスルーカで解決できる...

  • 平成の時の対応の仕方によるよなあ。
  • 元号を取り扱うシステム開発を多数抱えてはいるはずだけど。
    おそらく社内で共通の仕様なりガイドラインが存在しなくて、場当たり的に各現場で対応していたとすると。

    >「洗い出しとテストの負荷が大きい」

    となりそうなのは分かり易い。

    そして大雑把に「問題点を洗い出せ」的な指示がうえから降ってくるだけだったりして。

    • 月日情報にアクセスせずに1989年→平成元年としているシステムがあります。これを 5/1 改元に対応させるのは大変です。

      月日情報が無ければ「平成31年/○○元年」と表示すべきところ、年数の前にしか文字を付加できないとか、文字数が問題になるとかもありそうです。実際問題 1989年1月を和暦で表示させるとか難しいですし。

      あと年度表示。2019年度の 5/1 は平成31年度とかも落とし穴になりそうに思います。

      # 入力はともかく、出力はすべて西暦で統一してくれればと思うけど…… 無理ですか、そうですか。

      親コメント
      • 全然知らんのですが、実際のところ
        > 「平成31年/○○元年」と表示すべきところ、
        とか
        > 2019年度の 5/1 は平成31年度
        とかって全部「○○元年」でも通りそうなもんですがダメなの?
        誰が何の根拠でダメだっていうんだろうそういうの

        親コメント
        • 2019年が〇〇元年でも許される場合もあると思います。でも〇〇元年1月1日〜12月31日だとダメだとされる場合もあるでしょう。

          年度の場合、報道では平成31年度は1ヶ月だけというのもありますね… でも昭和63年度が 8ヶ月だけで、平成元年度が 1989年1月ないし2月から始まったわけではありません。平成元年1月8日〜3月末日は昭和63年度であって平成元年度(零年度?)ではありませんでした。

          つまり昭和・平成の前例では年度は年度初日の年を書く、年が一年未満(昭和64年は7日間)で終わっても年度は常に 1年間であるというルールであり、年度途中で年の元号が変わっても年度の元号はかわりません。これに倣えば、平成元年1月8日が昭和63年度であるのと同様、〇〇元年5月1日は平成31年度になります。

          # 例えば 3月末が年度末決算だとすると、平成31年度が 4/30 で終わっては困るわけで。
          # 国の平成31年度予算は 2019年5月以降も執行できるでしょう。

          だとすると、和暦表示をするときに、1989年1月8日が年では平成、年度では昭和であったように、2019年5月1日も年では新元号、年度では平成と変換しないといけないのでは、という話です。

          間違っていたら、ご指摘ください。

          親コメント
    • 携る人を大雑把に
      (1)管理する人1(報告を受けて自分の手柄にするだけ)
      (2)管理する人2(現場の人が仕事をしやすいように対応の指針等を作る)
      (3)現場で実際に対応にあたる人

      に分けると、多分60:5:35位なのだろうと思う。
      親コメント
  • > 「昭和から平成への元号変更の際に培ったノウハウを生かせるためだ。」

    って30年近くたっても基本的にやり方変わってないの?

    • by Anonymous Coward on 2017年12月11日 18時21分 (#3327701)

      この前やったのは古いJavaで書かれたものだった。

      平成元年が1989年?
      Javaはたしか1995年からだし、Web系は今世紀入ってからだ。
      いくら古い奴でも昭和から動いてるJavaシステムはないだろう。。。

      しかもJavaで和暦対応したのは……Java6からか。しくしくしく

      親コメント
  • by Anonymous Coward on 2017年12月11日 18時31分 (#3327706)

    「さすが」って、それ毒されすぎ。

    改元なんて絶対に起きることのひとつであり、むしろ運用計画に入っていて当たり前。洗い出しに工数がかかるなんて、閏年の対応を洗い出しますと言っているようなレベルの話であり、改元の影響がわからないから洗い出すなんて、そんなことを平然と主張できる神経を疑う。

  • ・Unicode だと ㍻ ㍼ ㍽ ㍾ の前後空いてないけど、新元号は何処に追加するのだろう?
     もし ㍾ より後ろに追加されたら、㍻ ㍼ ㍽ ㍾ 新元号 という順番になってしまい、
     ㍻13.12.23 のような形式の日時を文字コード順にソートした際、新元号が㍾より過去の元号と扱われてしまう

    ・Unicodeへの文字の追加とIMEのアップデートが2019年5月1日までに間に合うだろうか?

    ・いっそのことデータベースのカラムを追加して 明治=1 大正=2 昭和=3 平成=4 新元号=5 みたいな数字化した方が良いかな?
     でも、Unicode の ㍻ より前に新元号がきちんと追加され、IMEのアップデートも間に合ったら、
     その工数が全部無駄になってしまう

    悩みが尽きないでしょうね

typodupeerror

計算機科学者とは、壊れていないものを修理する人々のことである

読み込み中...