はじめに

『バグ』はすでにじゅうぶんに一般化している用語ですね。「不具合」のことです。「不具合という現象」を指して用いられることが多いと思いますが、それの「原因」を指しているときもあります。

取り扱い注意！

プログラミング業界では『バグ』はしばしば「攻撃的」に響きますのでご利用の際はご注意ください。 「バグを見つけたよ」＝「おまえの不完全な仕事の証拠を見つけたぞ」 と聞こえてしまうわけです。

バグ報告の仕方

ちょっと横道にそれますが、バグ指摘のコツを書きます。

• ① 発生している事実を伝える
• ② 報告に至った背景を伝える
• ③ 原因についての推測を伝えない

バグ報告のフォーマットを決める

①についてはチームでフォーマットを決めることをお勧めします。自身にとって自明なことを誰かに伝えるのはいつでも難しいです。

そもそも認識相違が無いかを確認

ある人には不具合である人には仕様通り、そういう認識相違のケースがあるので②のように背景を知らせることはとても重要です。

推測しない

③ですが、初報で推測を伝えると混乱が起きがちです。調査が始まり状況が分かってきたうえで、もしまだあなたの推測が助けになると思うなら伝えましょう。

特に②と③とがちゃんとしていないと、バグ報告はただの「揚げ足取り」になりがちです。

バグの実際

バグ＝虫なので、なにか有機的なもの、不思議な生命体が突然変異でコードの中に生まれてしまった？ そんな印象を受けるかもしません。しかしながら実際のバグはしばしば「うっかりミス」程度のものだったりします。

if (good) doOne(); doTwo();

例えば上のような単純な書き間違いです。「"good"だったらoneとtwoを実行」のように見えますが、実際の動作は「"good"だったらoneを実行。その後無条件にtwoを実行」になります。

仕様バグ

『仕様バグ』という用語もあります。これは、そもそも仕様に間違いや矛盾があったのだが、それがプログラムの動作テストの段階になってようやく発見された、そのような場合に使用されます。

『仕様バグ』は政治問題化しやすく扱いが難しいです。ウォーターフォール的な現場だと「バグを含む仕様がなぜ承認され下流工程へ渡されたのか」の責任追及が起こったりします。

「仕様策定にエンジニアが参加」と「全員野球」のような情緒的な文脈で言われる時が多いですが、エンジニアには漏れなく抜け目なく考えるのが得意な人が多いので、これは実務的に有効な方法だと私は思います。

バグを防ぐ方法

チームにあった方法論を採用し磨き上げてゆくことが大事だと思います。方法論は各メンバーが「正しさの確信」にたどり着くための助けにならなくてはなりません。

たとえばプロダクトオーナーが一貫した考えを語ることは大事だと思います。考えがブレれば仕様バグを生むでしょう。

エンジニアはプログラミング言語を要求分析の方法としても使いこなすべきです。そして美しく仕上がったコードは仕様そのものです。醜いコードには誤解があり、きっとバグが潜んでいるでしょう。

おわりに

『バグ』の話より、バグをめぐるコミュニケーションとチームワークの話になりました。

『バグ』が攻撃的に響くのを回避するために『イシュー』という言葉を代わりに使用することもおすすめです。「なにかしらの理由で起きた不可解な出来事」のニュアンスなので誰かを責めたりしません。

ウォーターフォールについては別に書きたいと思います。ウォーターフォールの問題点は「政治問題」が起きやすい点です。古めかしい点ではありません。

最後までお読みいただきありがとうございました。

◇

初出は note です。