PR

品質評価基準だけの評価では不十分
　前ページまでは，製品を定量的に評価するため，品質評価基準を評価項目ごとに到達度を示したり（図1），機能別に沿って到達度を示したりしました（図2）。それは，各開発段階で目標や到達点を明確にして作業を進められるので，重要なことです。ところが，それだけが，製品評価の“物差し”というわけではありません。


イラスト：岡本 敏

　製品評価のもう1つの重要なツールは，「障害報告」です。私たちの開発モデルでは，実装とテスト作業がほぼ同時に始まります。特に初期段階では，様々なところに障害が潜んでいるので，テスターは発見した障害の一つひとつを報告する必要があります。品質評価基準に沿ってテスト作業をしていたとしても，機能全体を見ていくうちに焦点を置いている機能以外の個所に障害を見つけることも多々あります。テスターの責務は品質の管理であり，品質を低下させる障害を見つけたら必ず報告しなければなりません。


データベースで障害報告を管理
　マイクロソフトでは製品別に，報告された障害を記録するためのデータベースを持っています。テスターは，担当する製品に障害を発見すると，このデータベースに障害の内容を登録します。データベースに障害が登録されると，担当のプログラマが解決方法を検討し，しかるべき処理を施します。解決方法は品質管理の観点だけでなく，必要であれば出荷管理や開発管理などの観点からも検討されます。さらに，製品に関する提案，顧客からのフィードバック，テスト・ツールのトラブルについても，データベースに記録します。

　障害報告による製品評価というと，どうしても障害報告件数に焦点が集まりがちです。しかし，私たちVisual Studioチームでは，単純な報告件数だけで評価をしているわけではありません。日常のテスト作業で報告された一つひとつに対して，障害の内容に加えて，障害の修正方法，他の障害との関連性，障害か仕様か，繰り越しといった判断を行うための情報を登録しています。

　さらに，Visual Studio開発チームでは，データベースに記録されたそれらの情報の件数から，開発中の製品状態やテスターの作業状態などを定量的に判断しています。

　それから，重大な障害が多ければ品質評価が下がるのは当然ですが，障害報告と品質評価基準の間には明確な相関関係はありません。重要でない報告件数がいくら増えても，必ずしも品質評価が下がるとは限りません。また，重要な障害が見つかっても，その開発段階（例えばベータ1）ではなく，のちの開発段階（例えばベータ2）で処理するべき内容と判断されれば，その段階の品質評価には影響を与えないことになります。


△　図をクリックすると拡大されます
図3●障害報告件数の内訳

「処理済み」も3つに分類される
　データベースに登録された障害報告は，どのような内訳に分類されるのかを見てみましょう（図3）。

　まず，現在の開発段階で処理するべき課題か，次期開発段階で処理する課題かといった判断をします。次期開発段階で処理するべきと判断されると，これは「繰り越し」として登録されます。現開発段階で処理するべき課題は，プログラマやプログラム・マネージャによって，「修正済み」「重複」「仕様など」などと判断・処理されます。それぞれ以下のような内容です。
・修正済み：報告された障害が，修正しなければならないものだと確認され，何らかの修正が実装された場合
・重複：テスターは障害だと認識し報告したが，実際には既に同じ障害が報告されていた場合
・仕様など：テスターは障害だと認識し報告したが，実際には機能の動作は仕様に沿っていて障害とは扱われない場合

　また，「未処理」はまだプログラマやプログラム・マネージャが処理していない“在庫”になります。



△　図をクリックすると拡大されます
表1●機能別障害報告件数内訳

品質評価基準から見た障害報告
　表1は図2に示した機能A～Dまでの，同じ開発期間（ベータ1）における障害報告件数の具体的な内訳です。ここでは内訳の件数に加えて，その機能の開発チームの負荷を見るため「1日当たり」あるいは「1人当たり」の件数も指標として使います。「処理済み」に関しては，その開発チームが「1日当たりに処理した件数」を示し，「未処理」と「繰り越し」に関しては「1人当たりが処理しなければならない件数」を示しています。


　では，表1の機能AからDまでの障害報告件数の傾向から，この開発段階での評価基準到達度がどのように関連しているかを，機能AとCを例にとって見ていきましょう。

●機能A 　機能Aのデータを見ると，障害報告件数は4つの機能のうち最も少ない代わりに，現開発段階（ベータ1）の未処理の件数を最も多く抱えています。このことは，図2の機能別の評価基準の到達度と比べてみると，品質評価基準に到達していない部分（未到達＋テスト不可）が62.5％と，最も多かったことを反映しているといえます。また，機能Aは，ほかの機能よりも現開発段階で解決しなければならない障害を多く抱えていますが，次期開発段階で解決しなければならない問題は，ほかの機能よりも少なくなることが予測できます。

●機能C 　これに対して機能Cのデータを見ると，障害報告件数が機能A～Dの中で一番多く，さらに処理済みの件数も最も多いのですが，未処理の件数は2番目とはいえ，3番目以降と大差ありません。また，現開発段階から次期開発段階に繰り越している障害件数は一番多くなっています。この点から，機能Cでは，現開発段階で品質評価基準に触れる障害が，あまり報告されていないことが分かります。これは，図2で品質評価基準の到達度が66.7％と多いことに該当するといえます。また，機能Cは，現開発段階では機能Aよりも処理しなければならない障害が少ないものの，次期開発段階になると解決しなければならない問題を機能Aよりも多く抱えることが予測できます。

　このように機能AとCの，現時点での製品の評価は相反するものとなっていますが，実際にはこれらのデータは，各構成要素チームの大きさ（人数）にも左右されます。

　現開発段階での開発者1人当たりの未解決障害報告件数を見ると，機能Aは4つのチームの中で一番多いので，この機能を担当する開発者が，ほかのチームよりも少ないことが分かります。一方，機能Cは機能Aよりも多くの開発者が障害の解決に当たっていることが分かります。

　このような製品の評価を通して，現時点での各機能または製品全体の評価基準の到達度を把握することができ，開発段階とテスト作業の次期計画（内容，人員割り当てなど）を立てるときの参考に役立てられます。

　既に述べましたが，これらの数値は，製品の評価は毎日更新されて各自に電子メールで送られてきます。毎日更新されるので1日ではそれほど変化しないだろうと思われるかもしれませんが，実際には1日で大きく変わることも多々あります。そのため，この電子メールを毎日きちんと読んでいないと，開発の進行から置いていかれます。また，この製品の評価を通じてVisual Studio開発チームは，次に何をするべきか，また現状よりもさらに製品品質を向上させるには何をするべきかを，日々念頭に置いて動いています。