ここでの品質は、信頼性（正常に稼動する確率）と
いった方が分かりやすいと思う。
土曜にあったウィルスバスターのバグによるトラブル
http://dailynews.yahoo.co.jp/fc/computer/virus_buster/
今日の脱線事故
http://dailynews.yahoo.co.jp/fc/local/jr_fukuchiyama_accident/
前者はバグコード＆ＳＰ２でのチェック怠り。後者は速度超過時にブレーキが
自動的に動かないタイプ＆経験不足の運転手。ミスが重なって事故が発生した。
列車事故について訂正
事故現場に白い粉のようなもの（砕けた石の可能性も）があったようです。
悪質な置石の可能性もあります。
今週の日経ビジネスは･･･
品質崩壊 クルマも電機も鉄道も
http://nb.nikkeibp.co.jp/free/NBINDEX/20050421/107606/
タイムリーすぎる。
広告の見出しによると、システムの巨大化によりバグの発見が困難になった事、
不具合発生時のダメージも巨大化していることが書いてある。
一方システムの開発現場では、作業が複雑化＆伝達事項が上手く伝わらずに
死屍累々の惨状。
【軍曹が】携帯電話開発の現状【語る】
http://s03.2log.net/home/programmer/archives/blog20050409.html
携帯のソフトウェアの開発現場のお話です。
仕様書がデタラメ、開発環境が貧弱、倒れ行くスタッフ、午前様は当たり前･･･。
運用面でも、オペレーター（運転手や踏切の中の人）に、過労や
経験不足などの無理がかかって事故に繋がる。
ソフトウェアの開発には大学からの教育が言われています。
私もシステム開発やプログラムの授業は受けましたが、そこで感じた事は
・まず最初に、システムの目的が何であるかを正確に決める必要がある。
・私を含め、何かプログラムを作成するときにいきなりコードを書き始める
人が多いが、これだと途中で頭がこんがらがるので、仕様を固めてから
（青写真を描いてから）作成を始める。
・作成したプログラムは、他の人にも分かるようにする。情報処理の授業では、
ソースコードにコメントを書く事を勧められた。コメントがあると、後で
修正をかける時にも分かりやすい。
・コンピューターゲーム大手のＥＡ（アメリカ）は、ゲームソフトを作るときに
予算などを管理する人を置き、企画の暴走を防いでいる。また、ソフト作りの
ノウハウを社内で共有する事によって、開発の労力を省いている。
といったところです。
