バグと不具合は別々の管理が必要
バグと不具合とは対応に必要な事が違います
バグと不具合は良く似ているので混同される事も多いのですが、ソフトウエアの品質を良くする上では明確に分けて対応を考えたほうが判り易いです。バグに対応する時に大切なのは、再現方法や問題を引きす仕組みやソースコード上の問題箇所や対策案の効果の確認方法等です。一方で不具合に対応する時に大切なのは、発生する範囲や条件、影響する範囲や問題からの回復方法や回避策です。この分類ではバグ管理と不具合管理についてどんな事を考えてどんな対策をしていくのが良いのか、神戸のグータラ親父がこれまで実践してきた事を紹介していきます。
バグと不具合
ソフトの開発をやっていると必ずバグや不具合とのお付き合いがあります。どんなに避けようとしても、ソフト開発でバグや不具合との遭遇を完全に回避する手段はありません。まあ、最初から完璧なソフトを作れば不具合やバグと無縁になれますが、神様でもスーパーエンジニアでも無い私たちのような普通のソフトウエアエンジニアは、不具合やバグとは切っても切れない赤い糸で結ばれています。
ところで、バグと不具合って何が違うのでしょうか、皆さんはバグと不具合とを明確に分けて考えた事はありますか？ バグと不具合の定義も世間一般にはいろいろありますが、グータラ親父は次のように考えていました。
- バグ ：ソフトウエアが仕様どおりに動かない事態を引き起こすソースコードの間違い
- 不具合：市場で製品が使われた時に起こる何等かの問題
実際にソフトが使われている場面で、ユーザが困るような問題点が不具合です。例えばソフトがバグで誤動作するのも不具合ですが、反応がとっても遅くて使い物にならないとか、使い方が難しすぎて使うのが嫌になる、というのも製品の不具合です。一方で、Aのボタンと押すとBの処理が始まるという仕様なのに、Cの処理が始まるようにソースコードが間違えて作られていたら、それはバグですね。要するに、バグは不具合を引き起こす原因の１つです。
また、見つかる時点を基に考えると、不具合はユーザがソフトウエアを利用する本番環境で見つかりますが、バグの多くは社内のテストで見つかります。まあ、社内テストをすり抜けたバグが本番環境で見つかってその結果として不具合を引き起こす事もよく在って、これが一番の困りものなのですが。。。
という訳で、不具合とバグをざっと分けるとこんな感じです。 そして、ソフトウエアエンジニアはこの不具合やバグと赤い糸で結ばれているので、この不具合とバグが暴走しないようにしっかりと管理する事も大切なお仕事です。 では、不具合管理やバグ管理て、どんな事をするのでしょうか？
バグ管理って何でしょう
まずは簡単なほうのバグ管理を見てみましょう、ところでバグ管理ってどんな事をやれば良いのでしょうか？ バグ管理と一言でまとめていますが、その実態はバグ情報の管理とバグ情報を利用する作業の管理の２つに分けて考えると判り易いです。
バグ情報の管理とは、①バグ情報としてどんな項目があるのか、②各々の項目を誰が/何時/どんな細かさで記録するのか、③情報の記録はどこにするのか、④記録された情報はどうやって見たり修正したりするのか というような項目を管理する事を指します。 言い方を変えると、バグを記録するデータベースの運用管理という言い方もできます。
バグ情報を正しく管理するためには、バグ情報を使う目的に沿って、a) 必要な情報が、b) 必要な正確さで、c) 必要な時に簡単に取り出せるように、d) 常に情報の鮮度が保たれて、e) データベース等に記録されいる状態に、するために色々な作業の方法や手順を決めます。それらの方法や手順が正しく運用されてはじめて、正しいバグ情報として使う事のできるバグ情報になります。 そのような状態を作り出すのが、バグ情報の管理です。
一方で、バグ情報を利用する作業の管理というのは、記録されたバグ情報を使ってソフトウエア開発として必要な作業を行う場合の作業管理です。バグ情報を使って行う作業と言えば、まずはデバッグ作業です。バグ情報に従って ①バグを再現し、②再現したバグを引き起こすソースコード上の間違い箇所を見つけて、③その間違い箇所を修正して、④修正内容が正しいか確認し、⑤修正がソースコードの他の箇所に悪影響を及ぼさないかを確認して、⑥ソースコードの修正内容を本番のソースコードに反映する、というのが一連のデバッグ作業ですね。
しかし、バグ情報を使って行うのは、デバッグ作業だけではありません。ソフトウエアのリリース判定の時には、テスト状況とバグの検出状況から信頼度成長曲線（いわゆるバグ曲線ですね）を作成して、もう十分にテストをしてバグを出し尽くしているかの判断を行います。 この時に使う元情報は、何時、何件のバグが発見されかた、というバグ検出の情報です。 また、ソフトウエアの開発作業が終わった時に、今回の開発ではどんな工程でのバグが多かったのか、設計ミスで入ったバグが多いのか、実装で入ったバグが多かったのか、バグ修正で入った二次的なバグが多かったのか、昔から潜在してたバグが新たな使い方で顕在化しただけなのか、などのバグが入りこんだ原因を分析する事もあります。 この分析によって、自分達の開発チームがどんなバグを良く作ってしまうのかが判れば、次の開発からはそこに気を付ければ、少しでも楽にバグの少ないソフトウエアを作れるようになります。
バグ情報を使って、どのような目的の作業を、ソフトウエア開発プロジェクトのどんな時期に実施するのか、その計画を立てて、実施の実績を確認して、計画からズレがあればそれを修正する、というのがバグ情報を利用する作業の管理です。
このように、バグ情報の管理とバグ情報を利用する作業の管理の２つの面があるバグ管理ですが、どちらもソフトウエア開発の設計や実装やテストというメインの実務とは少し異なっていて、メインの実務を裏で支える裏方的な管理業務とも言えます。裏方の業務なので、注意していないと十分な工数が割り当てられないというような事態が起きる事も多いのですが、このバグ管理がちゃんと出来ていないと品質の良いソフトウエアは出来上がらないのです。 ですので、バグ管理とは、ソフトウエア開発にとって、とても重要性の高い管理業務なのです。
不具合管理って何でしょう
不具合にはソフトウエアのバグが原因になっていものも多いのですが、それ以外にも性能の問題だったり使い勝手の問題だったりいろいろんな問題があります。どの問題にも共通する事は、実際にそのソフトウエアを使ているユーザにとって今起きている問題だという事です。大きな不具合が適切に処置されずに放置されていると、そのソフトウエアはユーザに愛想を尽かされて使われなくなり、最悪の場合にはビジネスが無くなります。そのような事にならないように、不具合への対処を適切に進めるのが、不具合管理です。
ですので、不具合管理に関しては以下のような項目の確認や処置が大切になってきます。
- 不具合により影響を受ける内容（ユーザは何に困るのか）
- 不具合を起こす条件（どんな時に、どんな事をすると不具合が起きるのか）
- 不具合の影響範囲（この不具合は全製品で起きるのか、一部の製品だけか）
- 不具合の回避策（何かをしておけば、この不具合が起こらなくできないか）
- 不具合の対策時期（何時になったらこの不具合が起こらなくなるか）
起きている不具合がその内容や影響範囲の広い重大な不具合だった場合、その不具合に遭遇するユーザの数をできるだけ減らすために、不具合の内容、起こす条件、回避策 が判った時点で早急にユーザに公開する事も、対応方法の選択肢の１つです。 ソフトウエアのバグが原因の不具合だったら、そのバグを修正したバージョンのソフトウエアを緊急にリリースしたり、次のバージョンのリリースまで待ってそこに修正内容を入れ込んだりします。
このように、不具合によるユーザへの影響をできるだけ減らす事を目的に、情報の開示も含めてどんな対策をするのか、を管理するのが不具合の管理です。
不具合管理とバグ管理の概要は判りましたでしょうか？
グータラ親父の考える不具合管理とバグ管理について概要を紹介してきました。世間一般の考えとは少し違い所もあるかも知れませんが、まあこんな考え方もあるな～程度で読んでいただければと思っています。
もう少し時間が取れましたら、グータラ親父の考える不具合管理とバグ管理について、具体的な内容を別の記事で書き足していこうと思っています。記事が書けたら、この下に具体的な記事のリストが見えるようになりますので、興味のあるかたは参照ください。