品質・バグ管理の必要性についてご意見をお聞かせください。

Question

品質管理の必要性について

お疲れ様です。いつもお世話になっております。

タイトル通りですが、品質管理・バグ管理の必要性について質問させてください。
個人的には、「100%必要ない！」とは思っていませんが、厳重に管理したバグ票やらを必死に分析して最終的に何に使うのでしょうか？

私の今までの現場の作業としてはメインとして設計・製造がメインですので管理というのをあまりやったことがありません。
そして、今までの大まかな流れは、以下のとおりです。
①設計or製造
②設計・製造バグが見つかる
③故障票などに記載（Redmine的なものです）
④分析
⑤故障票の確認
⑥分析が足らなければ更に分析（繰り返し）
⑦原因を突き止めたらやっと故障改修（分析してからでないと改修をコミットできない）

という感じです。いわゆる、なぜなぜ分析ですね。
なぜなぜ分析は、真の原因が突き止めたらそれに対して改善策を提示することが大事なようですが。。。

分析が必要ことは重々承知ですが、かなり時間がない状況でも故障の改修を後回しにしてでも分析を行うのがわかりません。分析した結果をいつを使うのでしょうか？大体プロジェクトが終了すればエビデンスとして格納してあるだけなような気がします。
品質報告も規模とステップ数、バグ件数で計算してるだけな気がしていて数字だけでしか管理されていないような気がします。

例えば、「あるexceptionによるシステムエラー」が起きたとしたら
１.なぜバグが起きたのか？
→exceptionをキャッチしていない
2.なぜcatch文をいれていないのか？
→設計書から見落とした
3.なぜ見落としたのか？
→凡ミス
4.なぜ凡ミスが起きたか？
→疲れていた、作業効率の低下、特に理由なし

ここで最後の回答をしたところで、管理者は「なるほど、気をつけて」としか言いようが無いし、作業者としても「疲れていた」とは言いにくいものもあります。
バグの内容にもよりますが、明らかに大したバグではない、凡ミスのようなものに追及していく必要はあるのでしょうか？
それより、さっさと改修しても良い気もします。
一つの現場だけでなく、だいたいどの現場も同じ漢字なので不思議です。

話が脱線して、質問もごちゃごちゃな気もしますが皆さんの品質管理についても率直な意見をお聞かせください。
よろしくお願いします。

Answer 1

こんにちは。

品質分析、品質会計の基本的な考え方はotnさんが仰っているように、
後どれだけバグが埋まっているかという考え方に基づいています。

分析が必要ことは重々承知ですが、かなり時間がない状況でも故障の改修を後回しにしてでも分析を行うのがわかりません。

分析が完了した時点で、類似バグや起因するバグ（設計バグとか）の抽出と対応を行うことが出来るからです。表面的な問題点の改修はすぐ行うことが出来ますが、発生したバグに対する分析を行うことで品質を大きく向上することが目的です。

分析した結果をいつを使うのでしょうか？

これはそのプロジェクトや会社によるでしょう。
大企業では品質管理チームが別にあり、品質の合否をもらう必要があったりします。
その際で「バグは全て抽出された」という点を判断する必要があり、
どれだけバグの分析を行うことが出来たかが重要になります。
分析が不十分であれば、「他にもバグがあるのではないか」という考えに至ります。

品質報告も規模とステップ数、バグ件数で計算してるだけな気がしていて数字だけでしか管理されていないような気がします。

多くの職場で実際にある話でしょう。私も経験したことがあります。
その多くは管理者ひいては品質管理チーム自身が品質分析を「やらされている」ケースでした。

3.なぜ見落としたのか？
→凡ミス

属人化していない分析が求められることが多いでしょう。
上記であれば「設計書がわかりにくい構成になっていた」「見落とさないための見直しや、第三者によるチェックが開発プロセスとして抜けていた」など（現実的なプロセスかは置いておいて…）
実際の原因として属人化している場合でも「二人以上でフォローする体制が必要だった」とか。

「他に設計書にわかりにくい記述になっているところは無いか？そこでも見つかっていないがバグが潜んでいるのでは？」というところも分析に含まれます。

4.なぜ凡ミスが起きたか？
→疲れていた、作業効率の低下、特に理由なし

こういった部分も、細かく見ると
慢性的な残業、過密なスケジュール、など理由としては沢山あったりします。

---

私の考えとしては、品質分析は良い仕組みだと思います。
ソフトウェアの品質を体系的に証明するというのは中々難しいことですから。
もし、自分のチームが形式的な品質分析作業を行っているのであれば、
撤廃するか、または何のためにやっているのか意識改革から必要になるでしょう。
形式的になるとこの手のプロセスは無駄なだけです。

ただ、私はめんどくさがりなので、嫌いです。
やりますけどね。ちゃんと…。

Answer 2

バグ管理 の使い方には主に２つのレベルがあると思います。

1. 現状の管理

2. 将来の管理

3. 現状の管理 とは、どんなバグが報告され、その修正作業の優先度と、修正担当を決め、修正の確認 ...といったもの回していき、リリース時の修正漏れをなくすための使うことです。

4. 将来の管理 とは、リリースできるレベルになるのはいつ頃か予想する、リース後に報告されるバグ数の予想 するために 過去の情報を使うために使うことです。

プロジェクトことに BTS の使い方は異なってくるとおもいます。
(ゲームの開発と、銀行系のシステムでは、バグ管理,品質管理,保守の方針,コストは異なる価値感・トレードオフがあります)

いくつか参考情報を紹介します。

• なぜバグ管理システムを使うのか？ http://thinkit.co.jp/free/article/0712/4/1/

• BTSって何？http://gihyo.jp/dev/serial/01/bts/0001

• BTSを制する者がソフトウェア開発を制する http://forza.cocolog-nifty.com/blog/2010/12/bts-1474.html

...
BTSの利点の一つは、過去の障害データが一括管理されているので、そこから各種のメトリクスを出力できることだ。
よく使われるのは、信頼度成長曲線(SRGM)、別名はバグ収束曲線だろう。
実際のテスト工程では、テスト消化曲線とバグ発生曲線を一つのグラフでまとめると、テストプロセスの品質が一目で分かる。
...

Answer 3

人間が作ったものである限りバグはなくならないと思います。その前提で書かせていただくと、なぜバグが起こってしまったかという議論はあまり意味がなくて、既知のバグ、起こりうるバグについてのレビューが形骸化しているところに問題があるのではないでしょうか。

チェック項目がちゃんとドキュメント化されていれば、catchの入れ忘れはないはずだし、そこは他の人のだからいいやっていうのではなくて、ちゃんと最後にチェックする人が必要だと思います。単体テストは人がチェックするものという考え方から脱してなるたけ自動テストできるようにするのも大切だと思います。

Answer 4

「見つかったバグを全部直したら完成」と思っていませんか？見つかっていないバグも含めてシステムの品質です。見つかっていないバグがどの程度あるのかを推測するために、分析は必要です。
場合によっては前工程のテストをやり直したり、設計書のレビューからやり直したりも必要です。
あ、これは品質の高いシステムをリリースしたい場合です。

そこそこ動けばリリースして、ユーザーにバグを見つけてもらいながら改善するというシステムであれば考え方が異なるでしょうね。

ただ、改修を後回しにして分析というのはやり過ぎでしょう。並行してやるべき。

Answer 5

引用テキスト例えば、「あるexceptionによるシステムエラー」が起きたとしたら

の例程度の分析でいいのだったら、速い人なら30秒程度、遅い人でも2～3分で書ける内容でしょう。
それくらいやりましょうとしか言えませんね。

逆に「分析不足」とされてしまうのは、その例程度の分析すらできていないということなのですよね。それはつき返されて当然です。社会人ならば、この程度の内容は1分以内に一発で書けるようになったほうがいいと思いますよ。

バグの内容にもよりますが、明らかに大したバグではない、
凡ミスのようなものに追及していく必要はあるのでしょうか？

ありますよ。原因を分類・集計・分析することに意味があります。生産効率というのは人によって劇的に変わります。特にバグ発生時に生じる戻り作業によって大きく生産効率は低下します。その個人の能力による生産効率差は17倍程度と分析するレポートもあれば、100倍以上と分析するレポートもあります。

バグは人によって埋め込む率が大きく異なります。1年に1件ほどしか埋め込まない優秀な人もいますが、1日1件程度埋め込むレベルの人もいます。

・プロジェクト特有の事情によりバグが発生しやすいのか
・フレームワーク特有でバグが発生しやすいのか
・誰がどの程度バグを埋め込みやすいのか
・複雑であるのでやむをえないのか、凡ミスを繰り返えしているのか

など傾向を明確にすることは非常に重要です。そして
フレームワークに原因があるならフレームワークを変えようとか、
特定の人がバグを埋め込みまくっているのならその人を教育しようとか、
普段はバグを埋め込まない人がそのプロジェクトだとバグを埋め込むというのなら、
プロジェクト自体に問題があるのでそれを改善しようとか。
プロジェクトの環境改善や中期的教育計画などに反映させるのです。

それより、さっさと改修しても良い気もします。

そうですね。何が何でも分析をしなければ修正してはいけないというルールは厳しいと感じます。普通なら後でまとめて書けばいいという程度だと思います。

しかし人によって自分のミスを隠してごまかそうとする人もいます。そういう人がいるプロジェクトや会社だと、「後でいいよ」というと書かないことがあるから、先に書かすことにしたのかもしれませんね。もしそうなら、その原因となった隠蔽性向の人を恨みましょう。

Answer 6

私自身はドキュメントベースの対応は無駄だと思っています。（でも書きますよ）

分析情報は自分で使います。本来自分で使う上では報告書の類は要りません。
報告書自体は「これを書いておけば給料がもらえる」ぐらいに思っておくといいでしょう。
問題は貴方がもしも設計者ならその情報を自分で使っているかということです。

バグの内容にもよりますが、明らかに大したバグではない、凡ミスのようなものに追及していく必要はあるのでしょうか？
それより、さっさと改修しても良い気もします。

上のサンプルでいえば、「あるexceptionによるシステムエラー」が凡ミスで起きたために解決策が考えられないというのは本当にそうでしょうか。
「catchを書かなくていいように基底クラス側で改善を吸収する」などして今後の必要な作業コストを下げることはできないでしょうか。

設計者が模索すべき解決策は「共通となるコードに手をいれて作業を簡易化する」方法です。
コーディング上発生した問題自体が発生しえない環境作りを進めることです。
それが設計者の、ひいてはソフトウェアアーキテクトの対応すべき仕事だと考えています。

貴方が無駄だと思っているように、私も「馬の耳にドキュメント」ぐらいにしか思っていません。
規約を充実させたところでたいしてバグは減りません。
「何故ドキュメントは有効に働かなかったのか」などとつらつら考えるのは時間の無駄です。
理由は様々です。規約の実効力が作業者のレベルに依存すること、そもそも制作したドキュメントの内容が伝わらないこと、etc...
作業者自身に気を付けさせるのは、基本的に無理なことだと私は思います。
もし仮にドキュメントが有効に働いたとするなら、それは作業者のレベルが相応に上がったということでしょう。
企業にとっては不幸なことに、作業者は育成しても辞めます。

規約を追加するのは簡単です。
簡単だから皆規約を追加して解決しようとします。
しかし、規約の追加とは作業の複雑度を増す行為とイコールです。
作業者視点にたてば、不具合を出した結果仕事がより難しくなるわけです。
これは、不具合を出した結果次からは仕事が簡単になるようにしなければいけません。
基本的に報告書が形骸化している企業で働く場合、ここがまともに動いてません。

最も良いプログラミング体制はどのようなものだと思いますか。
私は「一人で設計もコーディングもする」ことが最良だと思っています。
もしも自分がコーディングするなら「こんな風に自動化したら楽だな」「これなら絶対ミスしない」と思うことを取り入れていくことが重要です。

「バグが無い状態にする」というのは不可能です。
「バグが発生しにくい状態にする」ことはできます。
そういう意味では、分析自体はしっかりやる必要があるでしょう。

Answer 7

基本的にバク管理は時間を短縮するために使います。

バク管理を行ったために、開発効率が落ちるのであればやらないほうが良いと思います。
簡単に想像がつくのですが、短期的にはバグ管理を行うと開発効率は落ちます。
バグ票の起票と管理の時間がかかるからです。

また、個々のバクへの対応は、バグトラッキングの対象ではありません。これは、バグ表を書く前に対応をしてください。バグトラッキングの目的は、バグを作らなくすることです。（迅速なバグ対応に関しても有効かもしれませんがそれは副次的なものと考えています。）

バグ票には、調査・対策にかかった時間、ほかの人に迷惑をかけた時間を適当でいいので、記入しましょう。書いたら、一度忘れてもいいです。

その後、対策の深堀をしましょう。一軒ずつはマヌケがまたポカをやらかしたのかもしれませんが、並べてみると傾向なりがわかると思います。分類して、対応時間や影響度を集計すると対応すべき問題かどうか浮彫になってきます。

ここまですると、個人のバグは、全員に共通した問題点になっています。そのうえで対策を考えます。（できる限り属人性を排除するのが重要です。）例えば、コンパイルログの警告を見るようになっていますか？例えば、クロスレビューで注意点として挙げられていますか？そういったことです。

対策を考えたら、今度はまた一つずつのバグに立ち返りほんとに対策として有効なのか考えます。対策はよく理想論になって、現実的でないことが多いからです。

バグの影響がちゃんと集計されていれば、対策の重要性は周知しやすいと思います。

このようにして、対策を打てば、経験上たぶん半年から一年ほどでバグを半減することができます。バグトラッキングがもちろんなかなか定着しない場合もっとかかりますが。。。

バグトラッキングの運用に関しては、ＩＴＩＬのインシデント管理が詳しいですので参考まで。