はじめに
- 品質は問題ないか？
- 生産性は発揮できているのか？
- 予定通りリリースできるのか？
私はプロジェクト開発を進める中で、常にこのような疑問に直面してきました。QCD（品質・コスト・納期）はプロジェクト成功の鍵ですが、「問題ない」とは何を基準に判断するのか？ という問いに明確な答えを出すのは容易ではありません。
業界標準を参考にするため、IPAが公開している「ソフトウェア開発データ白書」を参照しました。しかし、指標値との比較では、乖離があるものもあれば範囲内のものもあり、比較して問題ないか？という疑問は解消されませんでした。
そこで着目したのは、白書の目的に記載された以下の一文です。
本書の目的のひとつは、「定型化された統計分析を毎年継続し、モノサシとしての精度を高めていくこと」
Copyright 2018 IPA
弊社の開発は、機能追加を繰り返すエンハンス開発が主流です。
したがって、毎回の開発で指標を集計し、過去の自分たちと比較して改善されているかを確認することが、継続的なQCD向上につながると考えました。
本記事では、特にテストフェーズにおけるQCD改善に焦点を当て、「過去と比べて改善しているか」 という視点を軸に、品質・コスト・納期それぞれの指標に対しての定量的な分析手法と考え方について紹介します。
※以降の内容では各テストフェーズを、UT（単体試験）、IT（結合試験）、ST（シナリオ試験）、RT（リグレッション試験）として記載します。
Q（品質）について
背景
テスト工程は、ソフトウェア品質を最終的に保証する重要なフェーズです。ここでの品質低下は、リリース後の不具合や顧客満足度の低下につながります。品質を定量的に把握し、改善を継続することが不可欠です。
指標
- テスト密度（件/KLOC） = テスト件数 ÷ 修正ステップ数
- バグ密度（件/KLOC） = バグ件数 ÷ 修正ステップ数
件数ではなく密度を用いることで、開発規模が異なるエンハンス開発でも同じモノサシで比較可能です。
手法
- 各エンハンス開発で修正ステップ数、テスト件数、バグ件数を工程毎に集計
- 工程毎にテスト密度、バグ密度を計算
- グラフ化し、バージョンを重ねるごとに品質が向上しているかを確認
- 過去平均の近似曲線と比較し、改善傾向を確認
結果として、以下のような集計表とグラフを描くことができます。
- テスト密度
- バグ密度
考察ポイント
テスト密度は、過去と同等レベルを維持できているかを確認基準とします。エンハンス開発を重ねると母体ステップ数が増加し、影響範囲が広がるためテスト件数は増える傾向にあります。ただし、右肩上がりに密度が増えると工数が無限に膨らむため、効率的なテストパターン設計が重要です。
バグ密度は、過去と比べて低下傾向にあることが望ましいです。修正ステップ数が多いほど難易度が上がり、バグ密度は高くなる傾向がありますが、エンハンスを重ねるごとに近似曲線が下がっていれば改善と判断できます。
まとめると、テスト密度を維持しつつバグ密度が低下していれば、品質は改善傾向にあると考えられます。
C（コスト）について
背景
テスト工程は、プロジェクト工数の大部分を占めることが多く、効率化がコスト削減に直結します。特にエンハンス開発では、テストケースの増加や環境構築の負荷が課題となります。
指標
- テスト生産性（件/人日） = 実施テスト件数 ÷ テスト工数
テスト工程に特化した生産性を測定することで、効率改善の効果を定量化できます。
手法
- 各エンハンス開発で修正ステップ数、開発工数を工程毎に集計
- 工程毎にテスト生産性を計算
- グラフ化し、バージョンを重ねるごとに生産性が向上しているかを確認
- 過去平均の近似曲線と比較し、改善傾向を確認
結果として、以下のような集計表とグラフを描くことができます。
考察ポイント
工程ごとに生産性を確認することで、過去と比べて同等以上の効率で試験が実施できているか判断できます。
エンハンス開発を重ねると機能が増え、テスト工数が肥大化するため、試験項目のパターン化や自動化などの改善施策が必要です。
上記例ではUT工程で生産性が向上していますが、これはテストコードの追加により既存部分の自動化が進んだ結果と考えられます。
D（納期）について
背景
テスト工程の遅延は、リリース全体に影響します。特に、テストケースの消化や不具合対応の遅れは、納期リスクを高めます。進捗を定量的に管理し、早期に問題を検知することが重要です。
指標
- テスト消化率（テスト消化数/日）
- バグ発生率（バグ発生数/日）
日々の消化率、発生率を把握することで、納期へのリスクをいち早く検知できます。
手法
- 試験件数と試験期間から、1日あたりの試験消化数を算出
- バグ密度の過去実績を基に、バグ発生数を算出
- 前半は消化率、発生率を高め、後半は低めに設定する戦略を採用
- デイリーで進捗を確認し、消化数、発生数を集計
- 予定曲線との乖離状況を分析し対策を講じる
結果として、以下のような集計表とグラフを描くことができます。
考察ポイント
予定曲線の基本的な考え方は、前半に消化率、発生率を高めに想定しておくことにありますが、過去実績による消化速度や曲線の傾向を分析することで、より過去実績に近い予定を立てる事が可能となります。
また、デイリーでの予定と実績がグラフで確認できる状態にすることで、予定していた消化数や発生数に到達していない状況をいち早く検知する事ができ、対策を打つことができるようになります。
特に、バグ発生率の予測精度向上は、テスト計画の妥当性確認にもつながります。
まとめ
本記事で紹介した取り組みは、「過去の自分たちと比べて改善する」 という視点を軸にしています。
特にテストフェーズは、品質・コスト・納期すべてに影響するため、ここでの改善がプロジェクト全体のQCD向上に直結します。
次回以降の開発では、ここで紹介した指標を継続的に集計し、改善サイクルを回すことで、品質・コスト・納期のバランスを高めていきましょう。
数値化による見える化を行いながら、着実に改善を進めることが重要です。