■

第1回　ソフトウエア改造力が足りない：変更ミスがトラブルの温床に
http://itpro.nikkeibp.co.jp/article/COLUMN/20071102/286258/

当日に入れ替えたプログラムに余計な変更を加えていたことが原因。
あるチェック・ロジックを改良する作業において，送金処理には不要だったチェック・ロジックを誤って適用してしまった。
テストは行ったが，エラーになるパターンが漏れていた

改造力・・・ねぇ。
単なるテスト漏れの話だな。

見れば真新しい事など何も無く、昔というか開発当時から開発者は分かっていたこと。
きっと記者が書き散らすお題不足でようやくこんなこともネタにし始めたかって感じですが。

個別事例で興味を引いた箇所

ミサワホームの受発注システムには，年間で約200件の改造案件が寄せられる。

200件も！？！？
そんなに業務がゴロゴロ変更されるのか！？
ってんなわきゃねーわな。
半数以上が使いにくいUIがらみとかそんなんやろと勝手に思ってみた。

案件をさばく松尾昇氏（情報システム部 基幹開発グループ マネージャー）は，
「仕様の取り違えなどで，年間に十数件は対応したことによる不具合が出る」と話す。

1割も対応できてねぇ！！！
っと思ったら自分の読み間違いだった。

改造力とか変な言葉作る前に、基本的な要件確認をスケジュール内できっちりこなすってことを見直したらいいのに。
勝手にスケジュール変更して勝手に予算決めて勝手に間に合わせろ！とか無茶言ってりゃ
開発現場の力量に関係なくコケるわな。