アカウント名:
パスワード:
でもそれはスペックには現れないのでなかなか評価されず後回しになるものです。 特に予算が決まっているお話(って事はほぼ全てだけど)では。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ研究家
でもさ・・・ (スコア:1)
衝突したりするわけですよね。以前も、航空管制の人的ミスで
ニアミス起こすわ急激な高度変化で乗客に怪我が出たりしま
したよね?
私も
-- gonta --
"May Macintosh be with you"
Re:でもさ・・・ (スコア:2, すばらしい洞察)
ずいぶん簡単に考えていた、ではなく、簡単にその影響を調べることが
できなかったのではないか、ということではないかと気になります。当
のNECが影響の大きさを検証できていなかった、または、検証できる環
境がなかったのではないか、と。ケアレスミスだった場合は、弁護の余
地はありませんが。
航空管制のハードっておそらく、そんな二つも三つも用意できるもので
はないですよね?全く本番とハードウェア的にも、入力データについて
も同じ環境構築を用意できないと、どれだけ単体テストをしても本番実
施までみえないことがあります。特に、
Re:でもさ・・・ (スコア:1)
影響の想定が甘かったのかそうでなかったのかはわかりませんが、結果としてはバグの存在を全く報告しなかったのが問題のように思います。
もしバグの存
Re:報告していても(でもさ・・・) (スコア:1, 興味深い)
仕様上あり得ない。事実、(他の部分の)仕様が変わるまでなかった。
将来に渡ってあり得ないと断言できなくても、発生する可能性も断言できない。
手を加えることのリスクとコストを考えれば、顕在可能性の低い穴は放置が基本。
これはソフトに限らず、ハードでも、人事でも、何でもそうです。
あり得そうにない事態に対処するために、必要かどうかもわからない
冗長性を新たに追加するなんて、常識ではあり得ないことです。
国土交通省に報告が行っていても、同じ判断になったでしょう。
あり得そうにない事態を想定した時に起こる不具合なんてのは、いくらでもあります。
そんなものをいちいち報告していたら、妄想癖のレッテルを貼られて病院送りです。
NECが報告を上げてなかったと言っても、それが当然で、もしいちいち報告したら
国土交通省の業務はそれだけでパンクするでしょうね。
Re:報告していても(でもさ・・・) (スコア:1)
穴がある間、その周りを通る人は注意深くなります。
今回と同じ結果になる確率はそれなりに下がるでしょう。
>そんなものをいちいち報告していたら、妄想癖のレッテルを貼られて病院送りです。
それはただの言い訳ですな。
Re:報告していても(でもさ・・・) (スコア:0)
可能性のあるBUGは、必ず発現する。
コストで一番大きいのは (スコア:0)
でもそれはスペックには現れないのでなかなか評価されず後回しになるものです。
特に予算が決まっているお話(って事はほぼ全てだけど)では。
Re:報告していても(でもさ・・・) (スコア:0)
仕様上ありえない、ていったいどういうこと?
仕様を守っていない他のサブシステムの影響を受けない様にするのはよくあることだと思うけど。
今回の件に関して、NECに肯定的な意見が多いけど、汎用機のプログラムを開発してきたおじさんからすると、
信じられませんなぁ。
Re:報告していても(でもさ・・・) (スコア:1, 参考になる)
私も汎用機10年くらいやったことあるが、他システムから渡ってくるデータはファイルレイアウトをを信じてプログラムしてたよ。
それで数値項目に数値以外のものを入れられてたらABENDするはずだが、だからといって入り口のプログラムで全数値項目に対してNUMERICチェック入れたりはしなかったがなぁ。
なんせCOBOLの時代では1行いくらって費用計算もあったわけで、仕様上不要な処理をぼんぼん入れてたら「水増しするな」って言われることもあるし。