バグを愛したソース（ソフトウェア分析）
バグゼロの悪夢
「プログラムにバグはつきもの」「バグゼロは果たせない約束」というのがプログラマの本音です。上司も同僚も部下も知っている事実です。
もちろんバグはゼロまではいかなくても、少ないに越したことはありません。誰もバグを嫌っています。好きではありません。愛してなんかいません。だから「バグゼロ」という言葉が出てきます。
でもこのバグゼロは呪いの言葉で、この言葉で苦しんだプログラマは多いでしょう。責められた人は多いでしょう。まさにバグゼロの悪夢です。夢を食べる獏（バク）にバグを食べてほしいです。
バグを追い求めるソフトウェア分析
このNOTEで追いかけているソフトウェア分析では、二つの大きなテーマがあります。つまり、生産性と信頼性です。
そのうちの信頼性ははっきり言って、バグを追いかけています。どれだけバグがあったのか、まだ残っているのか、さらにバグを作ったプログラマの給料は適正なのかというような分析をしています（最後のは冗談です、たぶん、きっと）。
信頼性（というよりもバグ）の分析には色々あります。単純にバグ件数をプログラム規模で割ったバグ密度から、とある予測曲線に近似させて残存バグ数を類推する信頼度成長曲線（仲間内用語（ジャーゴン）ではバグ曲線）、色々な層別をして導き出したゾーン分析、下限と上限を定めた管理図分析など、人類の歴史とともに色々と発明されてきました。なんて執念深いことでしょう。
ソースプログラムはなぜバグを出すのか
ところで「プログラマがプログラムにバグを作りこむ」というのが定説ですが、そうでない場合も多くあります。つまりプログラマは犯人でなくプログラマ被害者説です。そこでここでは「プログラマを憎んでプログラムを憎まず」を実践していきます。あれ、逆だったかな。ギャグです。
バグの大きな原因は、二人の意思疎通、コミュニケーション不足です。事実、二つのモジュール間の「インタフェースミスマッチ」がバグの原因になっていることが多いです。これはどちらが悪いかという議論、責任の押し付け合いをしてもしょうがない話です。夫婦でじっくり話し合ってみてください。あれ、話がずれた？
でバグの別の大きな原因は、これもコミュニケーション不足で、要求と仕様のミスマッチです。正しく要求を確定できず、正しく要求を伝えず、正しく要求を理解できず、正しく要求を仕様にできないのが原因です。要求を出す側と受ける側のミスマッチです。要求×仕様のセメぎあいです（この×は可換ではありません）。
この結果、ソースはバグを愛するようになり、二人は離れられない関係になるのです。たぶん。
ということで今日の結論。「バグは不滅、だから分析して見守る」以上です。
マンガFAQの引用元：ソフトウェア開発分析データ集2022 | 社会・産業のデジタル変革 | IPA 独立行政法人 情報処理推進機構
いいなと思ったら応援しよう！
