不具合追跡でよくある間違い：開発プロセス再入門（9）（2/2 ページ）

よくある間違い

　不具合を追跡するうえで筆者がよく見かける間違いについては、第8回「ソフトウェアの不具合を追跡するには」でも解説しましたが、いくつか追加がありますので、ここで紹介をします。

・ビルド番号が管理されていない

　 実行可能なソフトウェアにビルド番号／バージョン情報を付加していない事例は非常によく見ます。ソフトウェアテストは、その結果をきちんと文書で残す必要があるとき、そのテスト対象も明確に記録しておかなくてはいけません。単に「いついつの時点でこのテストケースを実施したら結果がOKだった」といわれてもすごく困ります。重要なのは、いつテストしたのかではなく、どのビルドをテストしたかです。テスト対象を一意に特定できるように、ソフトウェアには必ずビルド番号／バージョン情報を付加してください。

・開発者とQA間のコミュニケーションが密でない

　効率よく不具合を解決していくには、開発者（Developer）とQAとの間で密に段取りを付ける必要があります。根回しをおろそかにすると、不具合報告書がたらい回しになり、いつまでたっても解決できません。顔を合わせることなく、報告書だけでやり取りをすると、

　　1：QA「直して」
　　2：Dev「不具合じゃない」
　　3：QA「いや不具合だ」
　　4：Dev「直してみた」
　　5：QA「いや直ってない」……

　これだけのコミュニケーションを取るために、ビルドを5回もリリースする必要が出てきます。この不具合を解決するまで何回のビルドをリリースしなければならないのでしょうか。これでは解決できるどころか、最終ビルドを手に入れる前に、人間関係が崩壊してしまいますね。開発者は、QAにより報告された不具合が「不具合でない」と考えるなら、まずその報告者であるQAに対して「これこれの理由で、この不具合を修正せずに［解決済み］とするけど、いいかな？」と確認を取るべきですし、QAが開発者の解決に合意できないときにも、同様の丁寧さ、慎重さが必要でしょう。

・深刻度と優先度を一緒くたにしている

　不具合報告書は、各担当者のタスクリストのような形で処理しますから、どんな組織でも不具合報告書に優先度（らしきもの）を付けることはしているようです。しかし、深刻度と優先度はまったく別の概念ですから、優先度（らしきもの）だけで不具合報告書を処理しようとすると、人や開発のフェイズに依存してその重み付けの基準が変わってしまい、不具合報告書を正しく順序付けることができなくなります。それぞれ別の側面に注目し、適切な尺度を与えることができるように、深刻度と優先度は独立して準備しておくべきです。

・QAのモチベーション管理に失敗する

　テストはエンドレスな作業ですから、QAメンバーのモチベーションを維持するのは困難です。「どんなに頑張っても、自分は開発中のソフトウェアの品質向上には貢献できないのではないか」といった無力感を感じると、QAはやる気を失います。QAが報告した不具合に対して、開発者が適切なタイミングで適切なアクションを取ってあげなければ、QAは不具合報告書を記述する作業に価値を見つけることができません。せっかく多くの不具合を報告しても、これらに対して何のアクションも取られないまま、それらの再現手順が古いものになってしまっていくと、QAは転職を考え始めます。

　また、ソフトウェア開発をよく理解していない組織では、不具合を多く報告するQAを不当に低く評価することがあります。不具合が多く見つかるほど、それらを修正するコストが多く掛かりますから、不具合は見つからない方がいいというわけです。しかし、これは明らかに誤りです。テストは、不具合を発見するために実施するのですから、むしろ1週間に発見するべき不具合数のノルマを決めて、各QAのモチベーションをケアすべきです。毎週、不具合を一番多く発見したQAをMVPとして表彰する、といった工夫も有効です。

　QAは、仕様の詳細化について強い権限を持つ係です。顧客のドメインに明るく、開発中のソフトウェアの仕様についてコミットできる人がQAを担当します。顧客の要求を獲得するプロセスにも、レビューなどに参加するなどで、QAがかかわっていくべきです。残念なことに、日本では「テスター」に強い権限を委譲することは少ないため、プロ意識を持ったQAが育つ土壌が乏しいのが現状です。テストと開発プロセスには密接な関係がありますから、QAは開発プロセスを改善する責務をも担うべきなのです。いかにQAという仕事が生産的で創造的なものか、理解していただけるでしょうか。もちろん、網羅性のあるテストケースの設計と実装という困難な仕事も、QAの責務です。どうです、QAの皆さん、やる気が出てきましたか？

不具合追跡システム

　これまで、不具合を追跡する方法や考え方について説明してきましたが、この方法を開発プロセスという形で組織に実装するにはどうしたらよいのでしょうか。開発規模が小さければ、MS Excelなどのソフトウェアを使っても十分です。しかし、複数人でより効率よく不具合を追跡するには、不具合追跡システム（Bug Tracking System：BTS）を使うと便利です。ソフトウェアを開発する組織は、そのドメインに適したBTSを独自に開発・実装してしまうことがあり、そのためいままでに非常に多くのBTSが開発されています。残念ながら、いまのところは事実上標準といえるBTSはないようですが、オープンで現在人気があるBTSを紹介しておきます。

　おそらく、現在BTSとしては最も有名なものでしょう。もともと、Mozillaの不具合管理のために開発されました。不具合の追跡について良いガイドラインやドキュメントがあるので、一度は上記のURLを訪れてみることをお勧めします。

　Bugzillaをいまどきの技術できれいに作り直したような位置付けのもので、Windows環境でもインストールが簡単です。名前の由来となったスカラベ（フンコロガシ）は、不死のシンボルです。この昆虫は、掘った穴の中でフンに卵を産み付けて生涯を終えますが、次の年には生き返って（卵がかえって）穴から出てきます。死んだはずのバグがまた出てくるなんて、しゃれていませんね。

　上に紹介したScarabはバックエンドDBにMySQLを使っていますが、これを構成管理システムSubVersionを使うように、Scarabを書き直そうとしているものです。残念ながらまだ計画段階のようですが、筆者が個人的に期待しているものなので、ご紹介しておきます。

　日本で開発されたBTSで、Rubyで実装されています。安心して日本語を利用できます。

　このほかにも、たくさんのBTSがあります。どんなBTSを使うかによって、ソフトウェア開発プロセスの下流工程は大きく影響を受けます。逆にいえば、BTSを導入するだけで、皆さんの開発プロセスをドラスティックに改善できる可能性があるのです。ここに挙げたBTSは、評価してみる価値はあるのではないでしょうか。ただし、オープンソースのBTSは、オープンソースのソフトウェア開発を意識したものが多いので、クローズドな製品の開発には向かないこともあります。BTSには有償の製品やSourceForgeなどのようにASP（Application Service Provider）という形で提供されているものもありますので、探してみるとよいでしょう。

トリアージ（triage）

　いよいよ開発中のソフトウェアが完成に近づき、最終ビルド候補のリグレッションテストが終わったと考えてください。この結果、不幸にも不具合を発見したときは、利害関係者を招集してトリアージミーティングを行い、発見した不具合を直すべきか、それともそのままリリースすべきかを判断します。トリアージとはもともと野戦病院で使われていた言葉で、傷病兵の負傷の程度による治療の優先順位を指します。転じて、危機的状況における優先順位の決定原理を意味しています。

　野戦病院では、決定的にリソースが足りません。医者、看護婦、ベッド、薬、包帯…… 、何もありません。可能な限り多くの兵隊さんを助けるため、治療の対象とする兵隊さんを選別する必要が出てきます。治療の優先度に応じて、兵隊さんに黄や赤のタグ（トリアージタグ）を付けていきます。ひん死の兵隊さんは治療の対象になりません。治療するためのリソースは限られているのですから、どんなに手を尽くしても助けられる見込みがないような深刻度の高いけが人は、優先度が一番低いことを示す黒いタグを付けます。ひん死の人を見捨てるという、つらい判断をしなければならないのです。逆に、死なない程度に重傷の人であれば、やはり優先度も低くなりますが、それがたった1人しかいない通信兵なら、深刻度は低くても、治療の優先度が高くなることもあるでしょう。

　ソフトウェア開発の現場も戦場です。決定的にリソースが足りません。時間、人、マシン、ライセンス、お金……、何もありません。可能な限り最終ビルドに含まれる不具合を減らすため、修正の対象とする不具合を選別する必要が出てきます。深刻な不具合だからといって、修正の対象になるとは限りません。修正するためのリソースは限られているのですから、修正に大きなコストが掛かるような不具合は優先度としては低くなります。深刻な不具合を開発の末期段階まで残してしまうと、ひん死の人を見捨てるのと同様の、つらい判断をしなければならないのです。逆に、許容できる程度に深刻度が低い不具合であれば、やはり優先度も低くなりますが、深刻度とは違う視点から（マーケティング上の理由などにより）、修正の優先度が高くなることもあるでしょう。

　このような判断は、最終ビルド候補以外のビルドでも常に行うべきですが、特に最終ビルド候補ではこの観点が重要となります。最終ビルド候補のリグレッションテストで発見した不具合は、なるべくなら修正の対象としたくはありません。修正してしまえば、新たな不具合を埋め込んでしまう可能性があるので、次の最終ビルド候補でリグレッションテストを全部やり直さなければならないからです。その結果、やはり新しい不具合を埋め込んでしまったことが判明したら、これを修正して最終ビルド候補をリビルドし、またリグレッションテストを全部やり直すというとんでもない工数が掛かります（さらにその修正により、次の最終ビルド候補に、新たな不具合を埋め込んでしまったら？）。ですから、トリアージミーティングでは、修正しないとリリースできない不具合（ショーストッパー）があるか（どれか）を、利害関係者間で調整・判断することになります。このとき、不具合の深刻度と優先度が重要なインプットとなることが、お分かりいただけると思います。修正の対象としなかった不具合は、制限事項として最終ビルドのリリースノートに記述します。

　トリアージのほかにも、緊急を要する救急患者の移送プロセスを参考にした、緊急を要するソフトウェアの補修プロセスや、品質バイタルサイン（quality vital sign）など、医療にヒントを得たソフトウェア開発・保守の話題があります。興味のある方は調べてみてください。

　次回は大詰め、ついに最終回です。開発プロセスを改善するアプローチを紹介し、これまでのまとめとします。お楽しみに。