バグ分析のすすめ

Tweet

みなさまこんにちは。
エコモットの板橋です。

今回は唐突に本題に入りますが、皆さんのチームでは、開発工程で発生したバグの情報をどの様に活用していますか？
え？　納品物にしか使っていない？
それはもったいないお話ですね。
バグの情報は、プロジェクトのバイタルサインとして使える事を皆さんは知っていますか？
新年度を迎えたという事で、新たなプロジェクトの立ち上げ準備を進めている方もいるかと思いますので、この機会に是非「バグ分析」にトライしてみてはいかがでしょうか。
進捗を管理するだけの退屈な「管理作業」が、アグレッシブな「知的業務」に代わるはずです！

なお、今回の話は、前回のブログと根底では関連していますので、まだ読んでいない方は先に読んで頂く事をお勧めします。
「品質」というマジックワードの正体を掘り下げて考える

バグ情報ってなに？

この記事でのバグ情報とは、「システム開発におけるテストまたは、それ以外の手段により発見された修正するべき挙動の情報」と言えば分かり易いでしょうか。
修正されるべき挙動とは何か、重要なポイントなので事前に整理しておきましょう。

• 仕様通り動かない　→　修正対象
• 仕様通り動く①　→　設計漏れの場合（設計漏れにより、実装すべき処理自体がないケース）
• 仕様通り動く②　→　処理も挙動も仕様通りで問題ない。でもユーザー観点では修正したほうが良い挙動（※詳細はいつか）

ざっくりと、上記の3パターンがあるのではないでしょうか。
意外かもしれませんが、「仕様通りでもバグ」という判定があります（私たちのチームでは）。
恐らく、皆さんのチームでもそのような判定になる事があるのではないでしょうか。
これらのバグがテストにより検出された際に、その詳細を記録しておき、修正担当者（実装担当者、テスト担当者とは限らない）が後日、検証や解析を進められるようにするためのものです。

バグの情報としてどの様な情報を記録しているの？

私たちのチームでは、バグの情報として以下の様な内容を記録しています。

…とまぁ、たくさんありますね（苦笑）
バグを検出した際は、現象に関する情報を詳細に集め、それを情報として残すようにしています。
皆さんのグループではどの様な項目を記録しているのでしょうか。
これらの項目は、バグ情報を登録する際に全てが記入されるわけではなく、調査や解析、対応が進むに連れて追加で記入される形になります。

バグの情報を使える情報に変換する

皆さんのチームでは、作ったテスト項目をただひたすら無心で消化し、バグが出たらチャットでサクッと連絡して、修正するといった「作業」になっていませんか？
そうなのであれば、それは、とてももったいない事です。
実は、バグの情報をしっかりと収集して分析を行う事で、プロジェクトの改善点、システムの抱えている課題や、担当者個人のスキルがかなり見えてきます。

• 作成したテスト項目でバグを出せているか？
• 設計変更が多発していないか
• 現象に偏りがないか
• 現象発生時の操作に偏りがないか
• 特定の機能に集中していないか

集計や分析を行う事で、こういった傾向を把握する事が可能になるのです。
これらの情報を集計し、複数の視点から状況を把握できるようにする事で、見えにくい状況を可視化できるのです。

• 重度別
• 設計変更の有無
• 検出区分（項目内/項目外）
• バグ分類（過去案件の潜在バグ/本案件の新規バグ）
• 現象別
• 要因別

など…
これらは私のチームで集計している情報の一例ですが、こういった具体的な数値から状況を読み取り、致命的な状態になる前に、有効な対策を打つための根拠として利用しています。（対策の効果測定にも使用します）

計測は改善への第一歩

プロジェクトの進行に関して、改善する必要があると思っている方は結構多いのではないでしょうか。
一方、具体的に「何」を「どの様に」すれば、改善が見込めるかという、効果的で具体的なアクションプランを持っている方は意外と少ないと思います。
その原因の一つが、プロジェクトで抱えている問題点を客観的にあぶりだすための「計測」を行っていないからです。

計測していないものはコントロールできない

何をするにしても、まずは現状をできるだけ正確に把握して、効果的な対策を考え出す事が大事という事ですね。
では、計測には何が必要か、まとめてみます。

システム開発のプロジェクトでは、特にテスト工程での思わぬ不具合の多さに、チームも混乱することが多いと思います。
逆に、当初は「少し難しいかなぁ」と思っていたプロジェクトが意外とすんなり前倒しで終わることもあります。
プロジェクトの反省会などで、ただ感想を述べるだけでは、その要因を正確に把握することはできないので、効果的な対策に繋げることはできません。
こういった場面で、バグ分析の結果から見える具体的で客観的なデータに基づいた考察をすることで、効果的な改善策を打つことができるようになります。
そういう意味で、バグ分析の結果はプロジェクト状況の計測データと言っても良いかもしれません。（もちろん、全てが可視化できる万能なものではない事は認識しておく必要があります。）

バグの分析をしてみる

テスト工程などでは、日々色んなバグ情報が登録されますので、それらの情報を分析する事で様々なことが見えてきます。
その一例を挙げてみましょう。

1. テストは進捗しているがバグの検出が少ない
   効果的なテスト実施ができていない（テスト品質が悪い）可能性があります。
   状況によっては、テストをいったん止めて、テスト項目の内容を点検したほうがよさそう、、、と私は判断するかもしれません。
2. 「設計変更あり」が多い場合
   上流工程に問題をはらんでいる可能性が高いと考えられます。
   本来、設計レビューで指摘してフォローするべき仕様の欠陥が、製造フェーズでプログラム化され、テスト工程で露見しているのかもしれません。
   このままテスト実施を継続して工程を進めて良いか、判断するべき場面かもしれません。
3. 現象別の「データのソート」に関する不具合が多い場合
   一覧画面などに表示する際のソート順に関する設計が 外部設計や内部設計で、明確に仕様として盛り込まれていない可能性があります。
   早い段階で、初期表示やソート順に関する仕様の点検を行うきっかけになるでしょう。

上記は、記事として分かり易い架空の指標を書き出してみましたが、実際には、もっと具体的なものが見えてきます。
状況によっては、すぐに対策を講じる必要がある状況が見えてくることもしばしばあります。

（バグ分析の実例）
※個別の状況が特定できそうな部分はマスクさせてもらっております（お察しください）

何がうれしいのか

プロジェクトの状況を多角的な面から可視化できることは既に書いた通りです。
可視化する事もバグ分析の目的ではありますが、本当の目的はそこではありません。

プロジェクトの状態を把握することで掌握し、潜在的なプロジェクト破綻のリスクをコントロールする

バグ分析の価値はこの一点に尽きます。
プロジェクトマネージャー（もしくはリーダー）は、品質（Q）、コスト（C）、納期（D）の観点で、プロジェクトに対しての責任があります。（いわゆるQCDというものです）
ただ進捗の管理をするだけでは、納期に対する観点しかない為、どうしても品質とコストで難しい局面を迎えることがあります。
特にテストが開始されるプロジェクトの後半では以下の様なリスクが表面化してきます。

上記は、絶対に避けるべき最悪のシナリオの一部ですが、それを未然に防ぐためのトリガーとして、バグ分析を行いましょうという事です。
正直、この観点に比べて、プロジェクト完了後の振り返りの材料として使うという話（先にも話しましたね）は、その副産物でしかありません。おまけです。笑

まとめ

このように、開発工程後半でのバグ分析は、プロジェクトの状況を示すサインがたくさん含まれているものです。
その情報を上手く使う仕組みを構築するのは大変ですが、それに見合うリターンがあると思いませんか？
どの様な状況を検知したいかによって収集するメトリクスも変わりますので、プロジェクトの開始時（若しくは序盤）に計画しておくことが大事です。

とは言え、記録情報を増やし、分析のメトリクスを細かくすると、その分の作業負荷が増えますので、そこはプロジェクトの状況に応じて、トライ可能な粒度にカスタマイズして、無理のないところから始めて頂くのが良いかと思います。
また、あえて言いますがバグ分析が万能だという訳でもありません（爆
バグ情報が登録されてから分析する訳ですので、場合によっては、対策が後手に回ることもあります。
あくまでも、補助的な手法の一つとして捉えて、無理なく初めて頂ければと思います。

新年度が始まりましたが、今年こそはボーナスステージ（らくちん）であって欲しいですね。
ではまた。
※次は何書こうかな…

私たちと一緒にモノづくりをしていく仲間を募集しています。 弊社に少しでも興味のある方は、ぜひ下記の採用ページをご覧ください。

• Wantedly
• 募集要項（当社HP）