品質評価基準だけの評価では不十分
製品評価のもう1つの重要なツールは,「障害報告」です。私たちの開発モデルでは,実装とテスト作業がほぼ同時に始まります。特に初期段階では,様々なところに障害が潜んでいるので,テスターは発見した障害の一つひとつを報告する必要があります。品質評価基準に沿ってテスト作業をしていたとしても,機能全体を見ていくうちに焦点を置いている機能以外の個所に障害を見つけることも多々あります。テスターの責務は品質の管理であり,品質を低下させる障害を見つけたら必ず報告しなければなりません。
データベースで障害報告を管理 障害報告による製品評価というと,どうしても障害報告件数に焦点が集まりがちです。しかし,私たちVisual Studioチームでは,単純な報告件数だけで評価をしているわけではありません。日常のテスト作業で報告された一つひとつに対して,障害の内容に加えて,障害の修正方法,他の障害との関連性,障害か仕様か,繰り越しといった判断を行うための情報を登録しています。 さらに,Visual Studio開発チームでは,データベースに記録されたそれらの情報の件数から,開発中の製品状態やテスターの作業状態などを定量的に判断しています。 それから,重大な障害が多ければ品質評価が下がるのは当然ですが,障害報告と品質評価基準の間には明確な相関関係はありません。重要でない報告件数がいくら増えても,必ずしも品質評価が下がるとは限りません。また,重要な障害が見つかっても,その開発段階(例えばベータ1)ではなく,のちの開発段階(例えばベータ2)で処理するべき内容と判断されれば,その段階の品質評価には影響を与えないことになります。
「処理済み」も3つに分類される
まず,現在の開発段階で処理するべき課題か,次期開発段階で処理する課題かといった判断をします。次期開発段階で処理するべきと判断されると,これは「繰り越し」として登録されます。現開発段階で処理するべき課題は,プログラマやプログラム・マネージャによって,「修正済み」「重複」「仕様など」などと判断・処理されます。それぞれ以下のような内容です。 また,「未処理」はまだプログラマやプログラム・マネージャが処理していない“在庫”になります。
品質評価基準から見た障害報告 では,表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開発チームは,次に何をするべきか,また現状よりもさらに製品品質を向上させるには何をするべきかを,日々念頭に置いて動いています。 |
Visual Studioの開発現場から(第4回)p2
あなたにお薦め
注目のイベント
日経クロステック Special
経営
- ものづくりと経営をデータでつなぐ試みとは
- 企業をまたいでERPを連携? 何が起こる
- 全方位DXを推進する意義。カバー範囲は
- DXを内製で実現する「3ステップ」
- 平等より特別の方がビジネスに有利な理由は
- 「データのサイロ化」の原因とその解決法
- 中小企業がDXで効果を上げるには?
- 深い業務理解で顧客を支援≫キヤノンMJ
- 製造業DXを成功に導くための3つの勘所
- 富士通と日本IBMがローカル5Gで協業
- コロナ禍のデジタル活用=DXではない理由
- 経営層に求められるDXの船“進水”のコツ
- 少量の学習データでもAI活用が可能に!?
- つなぐポイントシステムが地域を盛り上げる
- 2021年は「MESH」が花開く時
- IT人財の真価を発揮する人を軸とした戦略
- DX先進企業は何を考えているか?
- 顧客の再来店と常連化を実現した施策を探る
- IBM、ビジネスパートナー14社を表彰