パスワードを忘れた？ アカウント作成
Close
13475883 journal
日記

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

日記 by argon

#「改元対応」の一言仕様書部門より

2019年5月に予定される改元にあたって、その対応について大手システムベンダーがコメントを出しました。

2019年5月1日に新元号、NTTデータや日立は「対応難しくない」
http://itpro.nikkeibp.co.jp/atcl/news/17/120102783/

　NTTデータは「元号改正による修正は限定的」（同社広報）とみる。システム内部で保持する西暦日付を和暦日付に変更するテーブルの修正が必要とする。

　日立製作所は「平成から新元号への対応は比較的容易」（同社広報）と話す。新元号の公表から元号改正までの時期に余裕があるため、変更作業を計画的に実施できるほか、昭和から平成への元号変更の際に培ったノウハウを生かせるためだ。

新元号は2019年5月1日からの見通し、富士通は「洗い出しとテストの負荷が大きい」
http://itpro.nikkeibp.co.jp/atcl/news/17/120802832/

富士通は新元号のシステム対応について、「個別開発したアプリケーションの影響を特定する洗い出し作業に手間がかかる」（広報）と話す。さらに「元号改正による修正作業そのものよりもテストの工数が増えそうだ」と見通す。システム環境を2019年5月1日以降の未来日付にして、修正内容が正しいかを画面や帳票などで確認する。

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

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

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

  • 海外では和暦なんて使ってない (スコア:5, おもしろおかしい)

    by OnlyInJapan (48277) on 2017年12月12日 0時26分 (#3327984)
    大学院時代にアメリカに留学して驚いたのだが
    アメリカでは誰も昭和とか平成は使わず、年は西暦を使っていた
    なので平成が終わってもアメリカでは何の混乱も起きない

    和暦なんて海外ではもうどこも使ってない
    アメリカを見習って和暦なんていう時代遅れなものは廃止すべきだろう

  • ところで、 (スコア:3)

    by manmos (29892) on 2017年12月11日 17時56分 (#3327683) 日記

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

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

    ＃来年だと思ってた。

  • 元号がradioボタン選択 (スコア:3)

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

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

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

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

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

    • Re:日立のコメント (スコア:1)

      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年近くたっても基本的にやり方変わってないの？

    • Re:平成の時と同じ…とな (スコア:1)

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

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

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

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

      シェア
      親コメント

      • DelphiもVBも.NETも平成になってから生まれたものなので、アプリケーションソフトでは改元を想定していないものが腐るほどあって、そのうち何割かは今でも現役だろうなー
        さすがにVB6の改元対応ランタイムなんて提供しないだろうし。

        --
        うじゃうじゃ
        シェア
        親コメント

  • 改元の影響を「洗い出す」とは・・・ (スコア:1)

    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

長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds