あなたは「バグ」をどう数えていますか？ 組み込みソフトウェアの品質管理を考える：＠IT MONOistゼミナール・レポート（3/3 ページ）
あなたの現場では、ソフトウェアの品質管理の考え方をきちんと生かし切れていますか？ ＠IT MONOist編集部では組み込みソフトウェアの品質管理をテーマにしたゼミナール「組み込みソフトウェア開発で問われる品質力」を開催。組織における品質管理の考え方や、実際の開発現場におけるツールの活用・導入に関する事例などが披露された。
「バグ」をどうやって数えるか（2）
では、野中氏の考え（回答）を見てみよう。
野中氏は「開発プロセス全体でバグの粒度に一貫性を持たせる。例えば、ソースコードレビューで見逃した1件を、後工程で発見したのなら『1件』とする。たとえ、その影響でソースコードを30カ所修正したとしても『1件』とすべきだ」という。野中氏が掲げる原則は以下の通りである。
- 原則：プロダクトの原因部分で集約して1件と数える
この考えを先ほどのQ1〜3に当てはめてみると、以下のようになる。なお、この野中氏の考え方が絶対（必ず正解）というわけではない。組織として一貫性を持った定義がなされていればよいのだ。
野中氏の考えの一番のポイントは、少なくともレビューでの見逃しによる原因と、デバッグプロセスにおける修正漏れによる原因は切り分けて考えるべきであるということだ。修正したものを“1件1件記録として残す”ということもある意味では大切なことかもしれないが、開発プロセス全体で、それが“バグ”であるかどうかを組織の定義の下できちんと判定し、その数を数えることが、正しいバグの測定・管理につながるというのが野中氏の考えだ。
また、バグの数え方に関連し、そのバグをどのように分類するのかも重要だという。バグの分類は大きく2つある。機能そのものに関するバグ「機能性欠陥」と、現段階で機能としては問題ないが、ソースコードが分かりづらい・記述がおかしいなど、将来のバグ発生につながる「発展性欠陥」である。
上流工程でのバグ除去率を“数”としてだけで捉えると、発展性欠陥を多く含んだ状態でバグ除去率の目標を達成してしまうかもしれない。「バグ除去のフロントローディングを考える場合は、まず、機能性欠陥に注目すること！ それを防ぐためにもバグの分類をきちんと考えて管理すべきである」（野中氏）。
では、発展性欠陥の除去を完全に後回しにしてもいいのか。それは「No（ノー）」だ。機能性欠陥を除去する一方で、当然ながら、将来の機能性欠陥（修正コストの増加）につながる発展性欠陥を早い段階でつぶしておくことも大切である。
ここで紹介したのはあくまで野中氏の考えだが、バグの粒度（数え方）の定義だけでなく、バグの分類を意識した上で、品質評価の基準を組織としてきちんと定義しておくことが、正しい品質管理の第一歩といえるのではないだろうか。
東芝グループにおける製品の高品質化への取り組み
では実際に、組織としてどのように“品質”に取り組むべきか。事例講演として、東芝 ソフトウェア技術センター プロダクツ開発部 第一担当 参事 古賀国秀氏が登壇し、「東芝のソースコード静的解析による製品の高品質化の取り組み」に関する講演を行った。本稿では、ソースコード静的解析ツールの導入推進の部分にのみフォーカスし、その概要をお届けする。
古賀氏が所属するソフトウェア技術センターでは、東芝グループ全体における製品の高品質性の追求の1つの手段として、“ソースコード静的解析”に着目しているという。自社開発による解析ツールはもちろんのこと、例えば、コベリティが提供する解析ツール「Coverity Static Analysis」などのような他社製品を含め、複数のツールの特性（得意・不得意など）を常に分析・把握している。そして、そのノウハウを活用した品質活動を東芝グループ全体に展開し、多くの製品の品質向上に効果を上げているそうだ。
組織への導入のポイントについて、古賀氏は「静的解析ツールやそれを支援する仕組みを単に現場に提供しただけでは運用してくれない。導入先の部門の人員を巻き込んだ導入プロセスの構築が必要となる。そこに誰が・いつ・何をしてくれるのかを明確にし、きちんと役割を持ってもらうこと。そして、教育を行い、試行して、その部門の開発プロセスにきちんと合うようにカスタマイズして、初めて運用できる」と語る。
また、「われわれは、何でもやる」と古賀氏がいうように、ソフトウェア技術センターでは、開発プロセスの中に、ソースコード静的解析による品質評価を“定着”させるための取り組みとして、組織への導入サポートを徹底して行っている。
具体的には、ソースコード静的解析ツールの解析結果を3段階のリスクレベルに分類。さらに、誤検知や過剰指摘などをできるだけ省いた形で用意・提示するようにしているという。「まず、開発者に解析作業そのものをさせるのではなく、こちらで用意した解析結果を見てもらうことから始める。そして、“ハイリスク”と分類された指摘内容の修正を最優先してもらい、日々の業務として徐々に取り込んでもらうようにする」（古賀氏）。また、組織として使えるようなツールを自ら開発したり、あらゆるコンパイラをサポートしたり、面倒な解析ツールの設定作業の代行や定期的な解析作業の代行までも行うというから驚きだ。
ここまでしっかりとした体制を整備し、導入・運用・定着まで徹底できる東芝グループの体力に驚かされると同時に、組織が大きければ大きいほど、品質管理体制の整備や明確な基準の徹底がより重要になるということを感じることができた。
Copyright © ITmedia, Inc. All Rights Reserved.