システム開発において、バグが多いと当然のように叱責されますが、驚くことに、バグが少なすぎても問題視されることがあります。
この矛盾する状況は、現場における「意味のないバグ管理」が原因であり、エンジニアたちを困惑させています。
本記事では、バグ管理の現実と、その背後にある理不尽なルールや文化について掘り下げていきます。
バグに振り回されないためには、どう対処すべきかを考えてみましょう。
結論、「適当にやるしかない」です。
バグだらけのシステム開発、バグがないシステム開発、どちらもテストでわかる
料理の後は「味見」をしますよね。
美容室の後は「鏡でチェック」しますよね。
論文執筆の後は「見直し」をしますよね。
プログラミングの後は、必ず「テスト」をします。
期待通りの動作をするか、変なところでエラーにならないかを確認する作業です。
要するに「バグがないかをチェックする作業」ですね。
でもそのマインドでテストをすると、潜在的にバグを見つけないようになってしまうので、「テストはバグを見るけるために行う」と教えられていることも多いと思います。
また、設計書を作ったり、プログラムを書いた時にも「レビュー」と呼ばれる第3者チェックが存在します。
ここで誤りを発見できれば訂正することは可能ですが、もし見過ごしてしまった場合、その誤りは後の工程まで残ってしまいます。
スルーされた誤りを発見するラストチャンス、最後の砦が「テスト」でとても重要なわけで、個人的には一番大事な工程が「テスト」であると思っています。
でもテストって面倒なんです。私も一番嫌いです。
では、どれくらい面倒か簡単な例をみてみましょう。
以下のような画面のテストをすると仮定します。
日付を入れて検索できるかテストするだけだから簡単では？と思いきやそんな単純ではないのです。
テストはあらゆるケースを洗い出して漏れなく行う必要があります。
実際にテストが必要だと考えられるケースは以下のとおりです。
・「開始日」が日付形式の場合、正常に検索されること
・「開始日」が日付形式でない場合、エラーメッセージが表示されること
・「開始日」がありえない日付の場合、エラーメッセージが表示されること
・「終了日」が日付形式の場合、正常に検索されること
・「終了日」が日付形式でない場合、エラーメッセージが表示されること
・「終了日」がありえない日付の場合、エラーメッセージが表示されること
・「開始日」、「終了日」いずれも入力された場合、正常に検索されること
・「開始日」が未入力、「終了日」のみが入力された場合、正常に検索されること
・「終了日」が未入力、「開始日」のみが入力された場合、正常に検索されること
・「終了日」が「開始日」より過去の場合、エラーメッセージが表示されること
・「開始日」と「終了日」が同じ場合、正常に検索されること
内容は置いておいて、たくさんあることはわかっていただけたでしょうか？
しかも多くの場合はテストをした証拠を残さなくてはいけません。
通常「エビデンス」と呼ばれます。
各テストの実行前と実行後の画面のスクリーンショットを取ってExcel等に貼り付けることが多いです。
正直、めっちゃめんどくさいです(笑)
ただでさえ面倒なのですが、さらにテストを面倒にさせる要因としてバグ管理があります。
システム開発でバグだらけなのかバグがないシステムなのかバグ管理でわかる。バグ基準値、バグ指標、バグ目標の存在
「テストはバグを見るけるために行う」と前述しましたが、バグは「〇件見つけなさい！」という基準値が設けられ、「基準値±5～10%にしなさい」とルールが定められていることが多いです。
例えば、「バグ目標値10件、許容値は±10%以内」というルールであれば9件～11件のバグを見つけなければなりません。
逆に言うと9件～11件にバグを抑えなければいけません。
もっと言うとバグが8件未満だとテスト不足、12件以上だと品質不足と判断されます。
基準値が10件なんだからバグが8件のわけない、基準値が10件なんだからバグが12件なんてプログラムおかしいだろ、という判断されます。
これを守れないと、「完了」になりません。
どうしても守れなければ理由の説明が必要になったり、再度テストを実施することになります。
これがバグ管理です。
これが面倒なのです。
バグ基準値、バグ指標、バグ目標ってどうやって決めるの？
はい、適当です。
いや、本当に適当なんです。
そもそもバグの数なんて事前にわかるわけないですよね。
未だに多いのは「プログラムの行数」や過去の似たような機能と比較して決めることです。
「これくらいの仕様ならプログラムは3000行くらいになりそうで、1000行に1件はバグあるだろうから基準値は3件」という考え方で、これ自体に明確な根拠はありません。
一般論であったり、過去の実績であったり考えた人なりの根拠はあるのでしょうが、難易度やプログラマによっても当然異なるので、ほとんど意味がありません。
では何のためにこんなことするのでしょうか？
それは
「上層部のためです。」
上層部は数値を気にします。むしろ数値しか気にしません。数値大好きです。
管理する立場上仕方がないのですが、ほとんど意味がありません。
自分たちやお客さんを納得させるために、定量的に表現したいだけです。
品質管理と銘打ってはいますが、本当にこのやり方で品質があがるとは思えませんよね。
仮に10件のバグ目標値に対して、20件のバグを見つけたとします。
すると、
「設計は大丈夫？」
「ほかにももっとバグあるんじゃない？」
「プログラミングに問題あるんじゃない？」
と突っ込みを受けます。
では仮に10件のバグ目標値に対して、5件のバグを見つけたとするとどうなるのでしょうか？
残念ながら「優秀だな」とは言われません。
「ちゃんとテストした？？」
「テスト設計は大丈夫？」
「もう一度テストしようか」
と突っ込みを受けます。
一体どうしろというのでしょうね（笑）
「人が作るからバグは必ずあるもの」
ということはわかりますが、
根拠のない適当な目標値と大きなブレがあったからといってＮＧなのはよくわかりませんよね。
システム開発でバグだらけでもないしバグがないわけでもないシステムにする裏技
バグが少ないとテストを心配され、多いとプログラミングを心配される。
こんな時、エンジニアはどうすると思いますか？
有無を言わせない方法がひとつだけあることにお気づきでしょうか？
それは
バグの数を基準内に収めること
です。
「バグ目標値10件、許容値は±10%以内」とルールであれば9件～11件に必ず収まるようにします。
そんなこと可能なのか？テストはしてみなければわからないよね？と思いますよね。
その通りです。
だからエンジニアはテスト結果を偽装します。
バグ数が足りなければ、バグがあったことにしたり、誤字や脱字等ささいなことをバグ扱いにしたりします。
手の込んだことをすると、バグをわざわざ埋め込むなんてこともします。
バグ数が多ければ、そのバグはこっそり修正して起きてなかったことにします。
そんなまさかと思いたいですが、やっているエンジニアは大勢います。
一番大事な作業なのに、一番適当にやられることが多いです。
こんな状態で完成したシステムの品質が高いと思いますか？
システム開発で無駄なバグ管理の弊害はお客様にも降りかかっている
バグ目標に合わせてテスト結果を捏造する。これほど無駄で無意味な作業はありません。
でもエンジニアが稼働している以上必ず発生しているものがあります。
そう、「コスト」です。
ようするにエンジニアの人件費ですね。
当然、この人件費を払っているのはお客様です。
見積金額の中にはこの無駄な工数も含まれているので無駄な費用を請求されていることになります。
まとめ 意味のないバグ管理の矛盾と実態を攻略する方法
細かい作業を黙々と繰り返すことが得意なイメージのエンジニアですが、実態はこんなものです。
以下の記事でも取り上げましたが
エンジニアに向いている人は「妥協できる人」だと思います。
※もちろんちゃんとやっている人もたくさんいますし、こんなことやっていない会社もいっぱいありますよ！
意味のないバグ管理の矛盾と実態を攻略する方法は、正論にこだわらず適当にやることです。
最後までご覧いただきありがとうございました。
