ははは･･･思い当たる
問題なのは、バグ密度ですよ。いまどき、「これくらいの行数なら、これくらいのバグが含まれているはずだから、その数に足らない場合はテストが足りない」なんて管理はないでしょう。「バグの数が少なかったら、無理やりバグを仕込んで数を増やす」なんて意味のない行動を引き起こすことになる。
ここ思い当たる。大手相手だとこれ強要されるんだよね。100行だったかなもっと少なかったかな。それくらいで1つは必ずエラーが発生する箇所があるのだそうです。バグがない場合どうするんですか、と聞いたらバグをわざと仕込むんだそうです。バグの数のみ管理するので最初100あったのが10になって、0になったという変化があればがんばったという評価なのだそうです。
あほらし。
これ、机上でコーディングシートに書いて、あとでそれを打ち込んでエラーが出ましたとかいう報告が返る時代のものだよね。いまだとエラー等をしっかり排除して単体テストが終わってはじめて「できました」というのでかなり現実と合わないんだよね。
あとは内容と関係ないですが、いいかげんプログラミングファーストというオレオレ造語使うのやめませんか。プロトタイピング技法という単語がすでに正式に存在しています。
ここから話がそれます。
でもそれでも業務系アプリの開発現場は恵まれているかもしれません。ゲーム開発となると最近のバグが多いのはデバッグ部隊を使わないからだ、という風潮のせいで大量に外部や内部のデバッグ部隊を使うのが主流のようです。で、そのデバッグ部隊ってバグ修正しないで探すだけなんですね。
それデバッグですらないやん。
プログラマなどの開発者人数を大幅に削減してでも、大量にデバッグ屋（皮肉をこめて）に金払ってさがしてもらうのだそうです。真っ当なテストするかと思えば、単なる実機で動かしてバグを探すだけ。
これ、Webアプリに置き換えると例えば単体テストや設計のチェックはしないけど、実際にブラウザ開いて画面を遷移させてバグを発見するということですよね。いったいいつの時代の開発ですか。これってバグを減らすための方法としてはあまりにお粗末すぎる。それにデバッグ屋には設計やアルゴリズム等をちゃんと公開してデバッグ探してもらうんですかね？そういうのがあればこのへんがバグでそうで入念にチェックしなくちゃ！とかあるのでしょうけど、それすらないとひどいことになりそう。
どう考えてもバグは技術者が出すのだから、技術者増やしてソースコードやアルゴリズム、設計のレビュー等を徹底的にしたほうがはるかにバグが減るでしょう。
最近のすぐにプレイするとわかるような大量のバグはデバッグ屋にまるなげしている開発会社の問題だよね。システムの仕組みを知っていればある程度バグは特定できるのに。つまり、テスティング（もはやデバッグとよぶことすらしたくない）する側にも高度な技術を要するということ。激安の時給のバイトをふやして改善されるものじゃないんだよね。（このへんはある意味業務系の大規模開発にもいえるところか。）
コンシューマ製品はパッチで修正されることがほとんどないのでバグはかなり致命的にもかかわらず、大金をどぶに捨ててわざとバグを増やす構造にしてるのは納得いかないよなぁ。
