博士

ロボ子、今日はソフトウェアのバグ修正コストに関する面白い話をするのじゃ。

ロボ子

バグ修正コストですか、興味深いですね。一体どんなお話でしょう？

博士

よく「バグは要件定義段階で見つける方が、実装段階より100倍安く済む」って言うじゃろ？

ロボ子

はい、よく聞きますね。手戻りが少なくなる分、上流工程で発見する方がコストが低いというのは、なんとなく理解できます。

博士

ところが、その根拠とされてきた「IBM Systems Sciences Institute」の研究が、どうやら存在しない可能性があるらしいのじゃ！

ロボ子

えっ、そうなんですか？それは驚きです。

博士

Roger S Pressmanの著書で引用されたIBMのコースノートも、内部トレーニング用で、データも古いものらしいぞ。

ロボ子

なるほど。ということは、私たちが信じていた根拠が、もしかしたら曖昧だったということですね。

博士

そういうことじゃ。さらに、バグの発見が遅れるほど修正コストが高くなるかどうかも、研究によって結論が違うらしい。

ロボ子

それはなぜでしょう？

博士

欠陥の定義が違ったりするからの。実証的ソフトウェア工学（ESE）では、証拠に基づいて開発を進めるべきなのに、学術的なインセンティブ構造が業界と一致してないのが問題なのじゃ。

ロボ子

アカデミックな研究と、実際の開発現場では、重視するポイントが違うということですね。

博士

そういうことじゃ！でも、良いニュースもあるぞ。コードレビューはバグを見つけるのに有効で、短いイテレーションサイクルとフィードバックループは高品質なソフトウェアにつながるらしい。

ロボ子

それは良いですね！やはり、レビューやアジャイル開発は重要なんですね。

博士

そうじゃ。あと、Statistaの調査を引用したPRエージェンシーの「調査」には注意が必要じゃ。

ロボ子

Statistaは一次調査機関ではないから、他の情報源からのデータをまとめているだけですもんね。

博士

そういうこと！一次情報にあたるのが大事じゃぞ！

ロボ子

肝に銘じます！

博士

というわけで、バグ修正コストの話は奥が深いんじゃ。ところでロボ子、バグって英語でなんて言うか知ってるか？

ロボ子

えっと、bug ですよね。

博士

正解！じゃあ、バグが多いプログラマーは？

ロボ子

うーん、なんでしょう？

博士

バグだらけ！…って、つまらんかったかの？

ロボ子

…博士、たまにはそういうこともありますよ。