今日のNHKクローズアップ現代は「ソフトウエア危機」。たまたま公衆電話トラブルの原因は「うるう年」というニュースも重なって，おもしろそう。
ソフトウェアのバグなどが原因で２万トン放流したダムとは中部電力(株)駒場堰堤のようですね。（リンクを張ろうと思ったのですが分からなかったのでURLを書きます）
http://www.mlit.go.jp/kisha/kisha02/05/050521_.html
どうもありがとうございます。
番組ではJR改札異常の具体的なコードも出ていましたね。まとめて書こうと思いながらなかなか果たせていません。
録画してたのをきのう見ましたが，規模が大きくて大変，人が足りない，という話で終わっていましたね。 先日の日本信号の自動集改札機のトラブルが，たった1行のミスで大規模なトラブルになる例として挙げられていましたが，逆に言えば事前に1台で試していれば問題は防げたわけで，本番系にデータを突っ込む前にテストしていないのが問題と，言ってほしかった。 発注側のまかせっきりの姿勢も問題だと思うのですが。
番組は「ソフトウェアを作る人が不足している」という結論になっていたのでしょうか？見られなかったので残念です。
でも、ソフトウェアを作る人の不足というより、suzukiさんのコメントと同じかも知れませんが、発注側の問題ですよね。つまり、「ソフトウェアがどのように作られているかを知らない人が発注していることが問題」ですよね。
だから、専門家のための教育の対象人数を増やすよりも、初等的なプログラミング教育を必履修（必修でない）にする方が、結果として効果が高いと思います。
どんなデバッガを使うのかと思ったら，全部印刷して手分して読んでいたのには驚きました。デバッガで見つからない場合はこれしかないのでしょうね。最終的に何百万行の中の1行に + offset が抜けていただけだったようです。しかしこれはちょっとテストしただけでは見つからない微妙なもののように見えました。実際そのときまでずっと異常なく動いていたのですし。
上はデータエラーを起こす原因となったバグですが，データエラーが起こるとデフォルトの動作をするのではなく止まってしまうコードになっていたことも大きな問題のように思います（番組ではこのことは言わなかったので事情を知らない私の勘違いかもしれませんが）。
つい先日，Moodleの最新版である操作をすると画面が真っ白になってしまうバグが入り込んだことがありました。原因となった部分はさておいて，止まってしまうのはどうしてかとよく見ると，
もしfooならあっちに行け。 そうではなく，もしbarならこっちに行け。 おしまい。
になっていてびっくりしました。もし何らかの理由でfooでもbarでもなければおしまいになって，画面が真っ白になるはずです。この「おしまい」は，「どこどこでこういうエラーが起きたので連絡してください」と表示するようにするか，あるいは，もし「こっちに行く」がより安全な挙動なら，
もしfooならあっちに行け。 そうでなければこっちに行け。
にしておけばとりあえず完全に止まってしまうことは避けられたはずです。これはプログラミングのセンスに属することです。
ちなみに，fooでもbarでもない状況が生じるのはマルチバイト環境だけで，作者の環境ではいくらテストしてもわからなかったということがあとでわかりました。
で，何が問題かというと，ソフトが肥大したのに納期が短く，マンパワーが絶対的に足りない状況で受注してしまうので，デスマーチが生じる。一つの解決策として他社とのソフトの共通化が挙げられていました。
なるほど…。でも、そういう意味でauの携帯電話の基本ソフトは、今後KCP+という名称のソフトに統一されていく方針になっているのですが、そのKCP+採用機種が大変なことになっています。
当初の発表通りなら、昨年秋に2機種が発売になっていなければならなかったのに、実際の発売開始は2月8日。しかも、片方は発売当日午後に不具合発覚で発売中止→回収となりました。
共通OSにすると、それなりの問題もあるようですよ。
*「W54SA 回収」でググってください。
OSの問題だったんですか？
それは、「基本ソフト＝ＯＳ」っていうことですか？
と聞き直してみる。
当日の夕方までに原因は特定できている http://www.itmedia.co.jp/news/articles/0710/12/news117.html ので，デバッガは使っているはずですよ。全部印刷してというのは，他に同じようなミスが潜んでいないか，コードレビューを実施したのでしょう。ひと月掛かったと言っていましたし。 原因部分はネガデータ（リボケーションリスト）の処理部だそうなので，異常データなら致命的な故障かクラックされていると判断して，先の処理に進まないのは悪いともいえないと思います。今回のソフトでそこまで考えられていたかは怪しいですけど。 補足ですが「事前に1台で試していれば」というのは，テスト工程のことではなく，ネガデータは日々変化するデータなので，日々の運用手順としてデータチェックがなかったのがおかしいのでは，という意味で書きました。実際，翌日からは先に「シミュレーション環境」に流し込んでみたと，先の記事に書かれていますし。
そうだったのですか。詳しい情報ありがとうございます。
クローズアップ現代 ２万トン放流ダム
ソフトウェアのバグなどが原因で２万トン放流したダムとは中部電力(株)駒場堰堤のようですね。（リンクを張ろうと思ったのですが分からなかったのでURLを書きます）
http://www.mlit.go.jp/kisha/kisha02/05/050521_.html
Re: クローズアップ現代 ２万トン放流ダム
どうもありがとうございます。
番組ではJR改札異常の具体的なコードも出ていましたね。まとめて書こうと思いながらなかなか果たせていません。
人手不足だけが原因?
録画してたのをきのう見ましたが，規模が大きくて大変，人が足りない，という話で終わっていましたね。
先日の日本信号の自動集改札機のトラブルが，たった1行のミスで大規模なトラブルになる例として挙げられていましたが，逆に言えば事前に1台で試していれば問題は防げたわけで，本番系にデータを突っ込む前にテストしていないのが問題と，言ってほしかった。
発注側のまかせっきりの姿勢も問題だと思うのですが。
ソフトウェアを作る人が不足しているのではなく、
番組は「ソフトウェアを作る人が不足している」という結論になっていたのでしょうか？見られなかったので残念です。
でも、ソフトウェアを作る人の不足というより、suzukiさんのコメントと同じかも知れませんが、発注側の問題ですよね。つまり、「ソフトウェアがどのように作られているかを知らない人が発注していることが問題」ですよね。
だから、専門家のための教育の対象人数を増やすよりも、初等的なプログラミング教育を必履修（必修でない）にする方が、結果として効果が高いと思います。
何が問題？
どんなデバッガを使うのかと思ったら，全部印刷して手分して読んでいたのには驚きました。デバッガで見つからない場合はこれしかないのでしょうね。最終的に何百万行の中の1行に + offset が抜けていただけだったようです。しかしこれはちょっとテストしただけでは見つからない微妙なもののように見えました。実際そのときまでずっと異常なく動いていたのですし。
上はデータエラーを起こす原因となったバグですが，データエラーが起こるとデフォルトの動作をするのではなく止まってしまうコードになっていたことも大きな問題のように思います（番組ではこのことは言わなかったので事情を知らない私の勘違いかもしれませんが）。
つい先日，Moodleの最新版である操作をすると画面が真っ白になってしまうバグが入り込んだことがありました。原因となった部分はさておいて，止まってしまうのはどうしてかとよく見ると，
もしfooならあっちに行け。
そうではなく，もしbarならこっちに行け。
おしまい。
になっていてびっくりしました。もし何らかの理由でfooでもbarでもなければおしまいになって，画面が真っ白になるはずです。この「おしまい」は，「どこどこでこういうエラーが起きたので連絡してください」と表示するようにするか，あるいは，もし「こっちに行く」がより安全な挙動なら，
もしfooならあっちに行け。
そうでなければこっちに行け。
にしておけばとりあえず完全に止まってしまうことは避けられたはずです。これはプログラミングのセンスに属することです。
ちなみに，fooでもbarでもない状況が生じるのはマルチバイト環境だけで，作者の環境ではいくらテストしてもわからなかったということがあとでわかりました。
Re: 何が問題？
で，何が問題かというと，ソフトが肥大したのに納期が短く，マンパワーが絶対的に足りない状況で受注してしまうので，デスマーチが生じる。一つの解決策として他社とのソフトの共通化が挙げられていました。
KCP+の納期遅れ事件
なるほど…。でも、そういう意味でauの携帯電話の基本ソフトは、今後KCP+という名称のソフトに統一されていく方針になっているのですが、そのKCP+採用機種が大変なことになっています。
当初の発表通りなら、昨年秋に2機種が発売になっていなければならなかったのに、実際の発売開始は2月8日。しかも、片方は発売当日午後に不具合発覚で発売中止→回収となりました。
共通OSにすると、それなりの問題もあるようですよ。
*「W54SA 回収」でググってください。
W54SAの不具合
OSの問題だったんですか？
それは…
それは、「基本ソフト＝ＯＳ」っていうことですか？
と聞き直してみる。
当日の夕方までに
当日の夕方までに原因は特定できている
http://www.itmedia.co.jp/news/articles/0710/12/news117.html
ので，デバッガは使っているはずですよ。全部印刷してというのは，他に同じようなミスが潜んでいないか，コードレビューを実施したのでしょう。ひと月掛かったと言っていましたし。
原因部分はネガデータ（リボケーションリスト）の処理部だそうなので，異常データなら致命的な故障かクラックされていると判断して，先の処理に進まないのは悪いともいえないと思います。今回のソフトでそこまで考えられていたかは怪しいですけど。
補足ですが「事前に1台で試していれば」というのは，テスト工程のことではなく，ネガデータは日々変化するデータなので，日々の運用手順としてデータチェックがなかったのがおかしいのでは，という意味で書きました。実際，翌日からは先に「シミュレーション環境」に流し込んでみたと，先の記事に書かれていますし。
Re: 当日の夕方までに
そうだったのですか。詳しい情報ありがとうございます。