上工程における品質会計の適用方法

開発作業

テスト工程品質判定表による品質分析

目標どおりの品質か？

バグ目標値の 見直し

目標どおりの品質である 目標より品質が良い

または，

目標より品質が悪い

開始

工程別バグ目標値を 達成したか？

終了

達成 未達成

品質分析

不合格

合格 工程移行判定

（最終工程は出荷判定）

バグ傾向分析 バグ分析と1+n施策

バグ収束判定 作り込み工程別バグの分析

上工程品質判定表による品質分析

＜上工程＞ ＜テスト工程＞

図3-5 品質会計の手順

α

i ： バグへの影響要因(i=1,2,…,n)，

S ： 開発規模（KLOC）．

上記式（3-1）は，バグ予測値が，基本的には開発規模と標準バグ件数（定数）の積により 求められ，バグへの影響要因により補正されることを示す．Ｃは，重回帰分析の結果得ら れる定数である．バグへの影響要因

α

_iは，バグ件数への影響度の強い要因 i を選択して使

用する(i=1,2,…,n)．品質会計では，これまでの運用実績および現場への適用のしやすさを

考慮した結果，現在は，開発者の「技術力」および開発の「難易度」の 2 種類の影響要因 を原則として採用している．これらの影響要因は5段階で評価する．5段階評価の各段階で 使用する数値は，統計解析の結果に基づいて設定する．図3-6に，回帰型バグ予測モデルに よるバグ予測値算出例を示す．

現場への適用のしやすさのため改善した例を示す．バグへの影響要因の１つである「技 術力」は，当初，5段階評価ではなく，計測可能なメトリクスとして，技術者の開発経験年 数を用いた定量化を試みた．しかし，開発経験年数は技術力とは関連がないことがわかっ た．一方，開発現場のプロジェクトマネージャからは，担当する開発プロジェクトに対す る見解をバグ予測に取り込みたいという要望が強かった．これらの経緯を経て，技術力を5 段階評価とし，プロジェクトマネージャが評価する現在の方法とした．

回帰型モデルである式（3-1）は，ミドルソフトウェアや OS などのソフトウェア製品毎 に，蓄積された過去のデータを使用して求める．ソフトウェア製品毎に作成する理由は，

ソフトウェア製品毎にプロジェクト特性やソフトウェア特性などが異なるためである．

さらに，上記の過去データを参考にして，今回の開発での改善目標を考慮し，「摘出工程 別バグ目標比率」を設定しておく．摘出工程別バグ目標比率は，上工程バグ摘出率 80％を 達成できるように設定することが原則である．式（3-1）により算出したバグ予測値に対し て，摘出工程別バグ目標比率を乗じて，摘出工程別の「バグ目標値」を設定する（図 3-7 参照）．

3.3.2 バグの作り込みと摘出

品質会計では，バグを作り込み工程と摘出工程に分けて管理する．上工程品質会計では，

特にこの作り込みと摘出の考え方が重要である．図3-8は，バグの作り込みと摘出の例であ る．

バグは，上工程の設計またはコーディングで作り込まれ，レビューまたはテストで摘 出される．バグの作り込み工程を的確に判断できるかどうかが品質会計の適用効果を高め る１つのポイントである．技術レベルの低い開発者の場合，プログラムを修正するという 行為に惑わされてほとんどすべてのバグをコーディングバグと判断してしまうことがある．

コーディング工程の作り込みバグが多い場合には，作り込み工程の再確認が必要である．

一般に上流の設計工程ほど高い技術レベルをもつ開発者が担当することが多いため，バグ

＜回帰型バグ予測モデル＞

Ｂ＝Ｃ・α

₁

・α

₂

・Ｓ

Ｂ ：バグ予測値

Ｃ ：標準バグ件数 Ｃ＝15.0とする α₁：技術力（右表参照）

α₂：難易度（右表参照）

Ｓ ：開発規模(KLOC)

技術力

難易度

＜対象プロジェクトの情報＞

– 計画開発規模：20.0ＫＬＯＣ – 技術力（α₁）：5（技術力がある）

– 難易度（α₂）：4（やや難しい）

＜バグ予測値の算出＞

Ｂ＝ Ｃ

×

α

₁ ×

α

₂ ×

Ｓ

＝15.0 × 0.80 × 1.10 × 20.0

＝264

∴ バグ予測値＝264件

段階 技術力（α1） 数値 5 技術力がある 0.8 4 やや技術力がある 0.9

3 普通 1.0

2 やや技術力がない 1.1 1 技術力がない 1.2

段階 難易度（α2） 数値

5 難しい 1.2

4 やや難しい 1.1

3 普通 1.0

2 やや易しい 0.9

1 易しい 0.8

図3-6 回帰型バグ予測モデルによるバグ予測値算出例

上工程:８０% テスト工程:２０%

総バグ予測値

回帰型バグ予測モデルにより算出 Ｂ＝Ｃ・α1・

α

2

・ ・α

ｎ

・

Ｓ

配分

摘出工程別バグ目標値

配分 配分

使用

＜摘出工程別バグ目標比率（例）＞

注意：上工程バグ摘出率 80％が達成できるように 設定する

摘出工程 目標比率（％）

基本設計工程 4

機能設計工程 18

詳細設計工程 20

コーディング工程 40

テスト工程 18

計 100

作り込み工程の誤判断は少ないが，下流の工程に進むにつれてさまざまなレベルの開発者 が関与するため，バグ作り込み工程の判定妥当性を常に注意する必要がある．バグ作り込 み工程の誤判断が多いと，誤った品質状況判断をしてしまう危険性がある．

ＳＴ：システムテスト工程

＜上工程＞

＜テスト工程＞

BDD：基本設計 BDR：基本設計レビュー

BD:基本設計工程

FDD：機能設計 FDR：機能設計レビュー

FD:機能設計工程

DDD：詳細設計 DDR：詳細設計レビュー

DD:詳細設計工程

CDC：コーディング CDＲ：コードレビュー

CD:コーディング工程

ＦＴ：機能テスト工程

ＵＴ：単体テスト工程

システムテスト項目

基本設計仕様書

機能テスト項目

機能設計仕様書

単体テスト 項目

詳細設計

仕様書 コード一式

製品

コード一式 コード一式 作り込み 摘出

作り込み 摘出

摘出

作り込み

＜ケース③＞

作り込み工程：ＣＤ 摘出工程：ＣＤ

＜ケース①＞

作り込み工程：ＢＤ 摘出工程：ＳＴ

作り込み

摘出

＜ケース②＞

作り込み工程：ＦＤ 摘出工程：ＤＤ 要件

＜ケース④＞

作り込み工程：ＤＤ 摘出工程：ＦＴ

BD: Basic Design FD: Functional Design DD: Detail Design CD: Coding UT: Unit Testing FT: Functional Testing ST: System Testing

図3-8 バグの作り込みと摘出（例）

3.3.3 作り込み工程別バグの分析

「作り込み工程別バグの分析」では，レビュー実施毎の形式でデータを整理する（図 3-9 参照）．ここでの分析観点は，以下の3点である．

① レビュー回数に対する摘出されるバグ件数の推移

・ レビュー回数の増加につれて，バグ件数の合計が増加または横ばいの場合は，その ままレビューを継続しても成果が出ない危険性がある．レビューを一旦打ち切って，

その原因を分析する．

② 前工程の作り込みバグの摘出状況

・ 品質会計の原則を実現するためのおおまかな目標値では，作り込み工程で 80％，次 工程で残り 20％を摘出するとしている．この目標値を超えて前工程の作り込みバグ が摘出されている場合は，前工程の成果物の作り込み品質が悪いと判断し，前工程 に戻って前工程の成果物を確認する．

・ 作り込み工程で80％，次工程で残り20％を摘出するという目標値を達成すれば，上

工程終了時に残存するバグは，コーディング工程の作り込みバグ 20％のみとなる．

よって，品質会計の目標である「上工程バグ摘出率 80％」を確実に達成することが できる．

③ 前工程より上流で作り込まれたバグの摘出状況

・ 品質会計の原則に則ると，前工程より上流で作り込まれたバグは，既に摘出されて いるはずである．それにもかかわらず，前工程より上流で作り込まれたバグが摘出 される場合は，その作り込み工程の成果物の品質が悪いと判断し，その作り込み工 程の成果物を確認する．

上述の 3 つの観点から分析することにより，当該工程より前の上流工程での成果物の品 質問題を早期に検出して対処することが可能となる．特に，②や③で得られる結果は，上 工程の設計段階で作り込まれる問題であるため，一般に結合テスト以降でなければ気がつ かないことが多い．それを上工程で検出できることが，品質会計の大きな利点である．ま た，バグが多く作り込まれる工程は当該プロジェクトの弱点であるため，当該工程の問題 点を集中的に解決することにより，大きな品質改善効果が期待できる．

-58 46

23 8

累計

58 5

23 15

8

合計

38 5

16 13

詳細設計

-バグ

18 0

5 2

機能設計 8

バグ

2 0

2 0

基本設計 0

バグ

累 計 レビュー

（n回目）

レビュー

（2回目）

レビュー

（1回目）

詳細 設計

＜分析観点＞

1. レビュー回数を重ねるにつれて，摘出されるバグ数は減少しているか 2. 前工程の作り込みバグが多く摘出されていないか

3. 前工程より上流で作り込まれたバグが摘出されていないか

…

…

…

…

…

…

図3-9 作り込み工程別バグの分析のためのデータ表（詳細設計工程の例）

3.3.4 品質判定表による品質分析

表は，レビュー工数またはテスト工数に対する摘出バグ数の状況を分析することにより，

当該時点の計画に対する実績の品質を判断する．上工程においては，レビュー工数，テス ト工程ではテスト工数を使用する．さらに，バグ目標値の見直しのために，バグ目標値の 見直し式を提供している（図3-10参照）．

レビュー工数/KLOCまたはテスト工数/KLOC

品質判定表

摘出バ グ数 /KLOC

実績＜計画-a％

＜バグ目標値見直し式＞

①式：新バグ目標値¹＝旧バグ目標値¹×

②式：新バグ目標値¹＝旧バグ目標値¹×

計画+a％＜実績 実績＜計画-a％

品質を判断する時期 ではない

⇒レビュー継続 計画より品質が悪い

⇒①式で見直し 計画より品質が悪い

⇒①式で見直し

計画より品質が悪い

⇒①式で見直し 計画より品質が良い

⇒①式で見直し

計画より品質が良い

⇒②式で見直し

計画より品質が悪い

⇒②式で見直し 品質は計画通り

計画+a％＜実績 計画-a％≦実績≦

計画+a％

（注意）・バグ目標値¹は，上工程では総バグ目標値，テスト工程ではテストバグ目標値を使用する．

・開発規模²は，実績開発規模の確定時は実績開発規模，未確定時には計画開発規模を使用する．

レビューまたはテストによる摘出バグ数の当該工程実績値 レビューまたはテスト工数の当該工程実績値 レビューまたはテストによる摘出バグ数の当該工程目標値

レビューまたはテスト工数の当該工程目標値 レビューまたはテストによる摘出バグ数の当該工程実績値

開発規模²

レビューまたはテストによる摘出バグ数の当該工程目標値 計画開発規模

品質は計画通り 計画-a％≦実績 ≦ 計画+a％

図3-10 品質判定表

レビュー工数およびテスト工数は，別途提供する回帰型の工数予測モデルにより計画値 を設定する．品質判定表のしきい値a%は，20％を基準として，組織の実力に応じて設定す る．品質会計の適用実績期間が短いと，計画に対する実績のばらつきが大きくマネジメン ト精度が低くなる傾向があるため，aを大きい値に設定する．品質判定表による品質分析は，

各工程終了時に実施されることが多い．工程途中で実施する場合には，品質判定表の計画 値に進捗率を乗じた値を使用する．

レビューおよびテスト方法が従来と変わらないと仮定した場合，レビュー工数およびテ スト工数は，バグ摘出努力の程度を表し，摘出バグ数は，レビューまたはテストの結果を 表す．品質判定表による品質分析の狙いは，計画時に考慮していなかった，開発途中に発 生する品質上の変化の把握と対応である．この「変化」は，レビューまたはテストの状況 に最も現れると考えられる．その変化の把握の考え方は以下のようなものである．

・ 計画通りの品質であれば，レビューまたはテスト工数とそれに対する摘出バグ数の実 績値は，計画値に沿った数値が計測されるはずである．

ドキュメント内 博士論文 (ページ 46-52)