パスワードを忘れた? アカウント作成
13955234 story
バグ

広島市、令和対応システムの運用開始時期を間違えたために2019年生まれの乳幼児を0年生まれと誤認 59

ストーリー by hylom
コンピュータは指示されたとおりに動く 部門より

広島市で、ITシステムの不具合によって2019年(令和元年)生まれの乳幼児を西暦0年生まれと誤認し、誤って高齢者向けの書類を送付するトラブルが発生した(読売新聞日経xTECHハフィントンポスト)。

問題のシステムは令和元号に対応済みで、本来は2019年6月より対応済みシステムを運用させるはずだったが、システムを開発したNECが運用開始時期を誤って2019年7月に設定していたという。これにより、本来は令和元号に対応済みのシステムで対象者を抽出するはずが、実際には対応前のシステムで処理してしまい問題が発生したそうだ。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2019年07月10日 17時24分 (#3649646)

    未対応の元号を入れたら西暦 0 年扱いになったってことは、
    if (gengo == "大化") {
    ...
    } else if (gengo == "平成") {
    ...
    } else {
        seireki = 0;
    }
    という実装だったってことよね? これは例外吐いてエラー停止すべき状況なのでは。

    • 645年生まれ以前はどうするんだ!

      親コメント
    • int seireki;
      if (gengo == "大化") {
      ...
      } else if (gengo == "平成") {
      ...
      }

      かもしれない。

      親コメント
    • by Anonymous Coward

      > if (gengo == "大化") {
      吹いた。
      モデ権がない、ちょっと悔しいので AC

      • by Anonymous Coward on 2019年07月10日 20時53分 (#3649759)

        想定してる言語がCだったら大笑いだけど

        親コメント
        • > 想定してる言語がCだったら大笑いだけど

          C言語でもちゃんと動きますよ

          int gengo2seireki(const char * gengo)
          {
                int seireki;
                if (gengo == "大化") {
                      seireki= 645;
                } else if (gengo == "平成") {
                      seireki= 1989;
                } else {
                      seireki = 0;
                }
                return seireki;
          }

          const char *seireki2gengo(int seireki)
          {
                const char *ptr = NULL;
                for (ptr = メモリ空間の先頭アドレス; ptr !=メモリ空間の末尾アドレス; ++ptr) {
                      if ( seireki == gengo2seireki(ptr) )
                            break;
                }
                return ptr;
          }

          これで
          const char *taika = seireki2gengo(645);
          const char *heisei = seireki2gengo(1989);
          とすると "大化" と "平成"のポインタが取れるので,
          gengo2seireki(taika)) は 645
          gengo2seireki(heisei) は 1989
          gengo2seireki("大化") と gengo2seireki("平成") は 0
          という"意図した通り"の動作になります.

          親コメント
          • 元のコードでも動きますが,

            const char *seireki2gengo(int seireki)
            {
                        const char *ptr;
                        for (ptr = メモリ空間の先頭アドレス; ptr !=メモリ空間の末尾アドレス; ++ptr) {
                                    if ( seireki == gengo2seireki(ptr) )
                                                return ptr;
                        }
                        return NULL;
            }

            の方が良いですね.

            親コメント
          • by Anonymous Coward

            > for (ptr = メモリ空間の先頭アドレス; ptr !=メモリ空間の末尾アドレス; ++ptr) {

            ここで鼻から悪魔。

            > gengo2seireki("大化") と gengo2seireki("平成") は 0

            コンパイラーによっては同じ文字列リテラルを1つのアドレスにまとめるものがあるのでゼロになるとは限らない

    • by Anonymous Coward

      新システムを準備してたんだから、旧システムがそう動くのは分かってたんじゃないかな。

      新システム作って開始も2019年6月で何も問題ないはずだったんだから、わざわざ旧システム側にエラー処理を追加するはずもなく(旧システム作ったところが最初から入れておけっていう話だけど、旧システムもNECなのかな)。

      • by Anonymous Coward

        大筋、旧システムが異常値に対して例外吐かないのが問題って話だと思ったが……
        データの入力元が信用可能としてエラー処理無しだったのか、
        西暦0年がエラー値なんだけど受け側でそれをちゃんとチェックしないバグだったのか、
        何も考えずに異常元号で西暦ゼロになるバグだったのか、どれだろうな……

        異常データ入力として止まることなく全処理走りきってるのが不思議。
        和暦西暦変換以外一切元号触る処理が無かったのか…?

        • by Anonymous Coward

          どっかで
          catch (Exception e) {}
          してたとか

    • by Anonymous Coward

      システムが停止すると迷惑なので、スルーして走り続けさせろ。って言われるのは、よくある事。

    • by Anonymous Coward

      おそらく実際は先に MOVE ZERO TO SEIREKI. してるからだと思うよ。COBOL的に考えて。
      STOP RUNなんてせずに警告文をDISPLAYしておしまいで、バッチのSYSOUT見て異常データがあったら後から手動で修正しちゃうのが古典的運用法じゃないか。

  • by manmos (29892) on 2019年07月10日 17時21分 (#3649642) 日記

    本人はどう思うんだろう。
    内容を読んでも全然理解できないし。

    • Re:送られた (スコア:4, すばらしい洞察)

      by wish (6421) on 2019年07月10日 17時44分 (#3649662) 日記
      読める”本人”が居れば救世主になれるレベルかも!
      親コメント
    • by Anonymous Coward

      2019歳おめでとうございます!!

      • by Anonymous Coward

        キリスト「私の一年先輩ですね」

        • by Anonymous Coward

          野暮ながら、イエスの生年は西暦前4-7年頃とされている(過去に計算間違いがあった模様)。

    • by Anonymous Coward

      赤さん「2019年前から生きてる人間なんておるわけないやろ」

    • by Anonymous Coward

      そうだよね
      いくら元・西暦元年産まれの転生体に送付したとしても当時と今じゃ使用言語違うだろうから読めないよね

  • by Anonymous Coward on 2019年07月10日 19時30分 (#3649714)

    なにか根本的に駄目な感じがする(西暦1年の前年は紀元前1年で、0年は存在しない)

    • by Anonymous Coward

      駄目なのは世界(史)の方だ!

      // なんか1と-1の間に0が入らないと落ち着かない

      • by hjmhjm (39921) on 2019年07月11日 13時38分 (#3650094)

        なんか1と-1の間に0が入らないと落ち着かない

        西暦0「年」が存在しないだけで、西暦0「時間」はあるんだ、と思っとけば。
        紀元前から西暦に変わる瞬間、「年」の原点。

        # 「年」がきれいな整数列だというのは思い込み?

        親コメント
      • by Anonymous Coward

        キリスト教のせい
        Wikipediaだけど
        https://ja.wikipedia.org/wiki/0#0_%E3%81%AE%E8%B5%B7%E6%BA%90 [wikipedia.org]
        17世紀まで、ヨーロッパでゼロや無限を主張することは、キリスト教への冒涜であり、死刑宣告を意味した。中世ヨーロッパではゼロを悪魔の数字とみなし、ローマ法王により使用が禁じられた。1600年には、宇宙が無限であると主張した修道士のジョルダーノ・ブルーノが、異端の罪で火あぶりの刑にされている。

    • by Anonymous Coward

      暦を皆惜して西暦0年をいれるとして、0年は今の暦の西暦1年にするの?
      それとも紀元前1年?

  • by Anonymous Coward on 2019年07月10日 22時33分 (#3649806)

    日経xTECHの記事の一部から抜粋

    同サブシステムは和暦で登録されている生年月日を西暦に変換してから、70歳以上の対象者かどうかを判定する。

    悪いことは言わない。
    まずは、データーベースに新しいカラムを追加して、和暦で登録されている全員の生年月日を西暦(DATE型)に変換して入れろ。そして今後は、その新しく追加した方のカラムを見て全てを判断しろ。もちろん、新規ユーザーの登録時もこの新しいカラムにデータを入れるんだ。
    そうでないと、次に元号が変わった時に、またトラブるぞ。

    • by Anonymous Coward

      まっとうな意見なんだが、そういう意見を受け入れられるなら既にデータは整理されてる。
      されてないということは・・・わかるな。

  • by Anonymous Coward on 2019年07月10日 17時22分 (#3649643)

    どう見ても0歳。
    おあとがよろしいようで。

    • by Anonymous Coward

      子ほめでしたっけ
      まあこれに関しては事実0歳なのですが

      • あれは、数え(生まれた瞬間一つ)なので「半分」がオチ。

        親コメント
        • by Anonymous Coward

          数え年でもオチは「どう見てもただです」なんてバージョンもあるようですし、
          近年演じる際には満年齢版の「どう見ても生まれていません」もあるようですよ。

          • by Anonymous Coward
            上方版では「今朝生まれたばかりや」に対して「どう見ても明後日くらいや」というのも
  • by Anonymous Coward on 2019年07月10日 17時37分 (#3649657)

    これからは1000万円の新人さんが活躍してくれることを願ってます。

    • by Anonymous Coward

      NECもやばいと思ったから募集かけたんでしょ

      • by Anonymous Coward

        そんな新人さん使ってたら案件取れません

        • by Anonymous Coward

          無能なマネージャーを代わりに外せばコストは同じか下がるだろ。

  • by Anonymous Coward on 2019年07月10日 18時06分 (#3649672)

    >本来、申請書を送付する2019年6月とすべきところを、NECが誤って2019年7月と設定した

    0始まりだったんでしょうねぇ

    • by Anonymous Coward
      struct tm t = localtime(time());
      if (t.tm_mon == 6) { /* お、今日から6月か */ }
      みたいなコード書いたんだろうな・・・
    • by Anonymous Coward

      いえいえNECは0オリジンと1オリジンの処理を混在させるのが大好きです。
      せめてデータフィールド毎には統一してくれ。
      同じデータなのに送り先毎、送り元毎に1足したり引いたりするコード書くのは嫌だ。

      #後エンディアンを混在させるのも大好き。
      #16ビット単位ではビッグで、32ビットでは16ビットの塊がリトルで並ぶってのも大好き。

  • by Anonymous Coward on 2019年07月10日 20時31分 (#3649742)

    外注使ってたら開発スキルも疑わしいな

    • by Anonymous Coward

      そこは大して変わらないと思う

typodupeerror

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

読み込み中...