8.1 はじめに
本章では，ソフトウェア品質会計の工学的価値を論ずる．ソフトウェア品質会計は，バ グ数の摘出目標管理を軸とした品質管理技法である．品質会計の第一の価値は，このバグ 摘出目標管理というわかりやすい方法を採用している点である．これが，品質会計の導入 を容易にしている．当然のことながら，品質会計の価値は，そのような表面的な価値にと どまらない．
第 3 章の図 3-4 に示した品質会計の原則を下記に再掲する．これらの原則が，品質会計 技法においてどのように実現されたのかを述べながら，その工学的価値を論述していく．
＜品質会計の原則＞
• バグは作り込まない．作りこんだバグは素早く摘出する．
＜上工程品質会計の原則＞
• 作り込んだバグは次工程までに摘出する．
– 作り込み工程で80％摘出 – 次工程で残り20％摘出
＜テスト工程品質会計の原則＞
• 作り込んだバグは，すべて摘出してから出荷する．
＜目標＞
• 上工程バグ摘出率 80％
図8-1 品質会計の原則（再掲）
8.2 レビューによる早期品質確保
レビューによるバグ摘出を推進することによって，ソフトウェアライフサイクルの早期
に品質を確保しようという考え方は，ソフトウェア品質会計の核となる考え方の 1 つであ る．負債は利子で膨らまないうちに早期に返済するほうが経済的であるのと同様に，1件の バグが複数のバグを生まないうちに，設計・製造で作り込まれたバグを早期にレビューで 摘出するほうが後戻りが少なくて済む．品質会計は，上工程品質会計を考案することによ って，それを実現した．
上工程品質会計の大きな特徴は，バグ 1 件毎に作り込み工程と摘出工程という２つの情 報を明らかにすることにより，作り込み工程と摘出工程の 2 つの面からマネジメントする 点である．バグの作り込み工程からのマネジメントは，品質管理領域における源流管理と 同じ発想である．当該バグを作り込んだ工程を分析することによって，原因工程を明らか にする．バグ作り込み件数の多い設計工程は，そのソフトウェアの問題工程であるから，
当該設計工程の成果物を再度見直す必要がある．それを上工程途中の早い段階で検出でき る点が，品質会計の大きな強みである．さらに，上工程品質会計の原則で述べるように，
作り込んだバグは次工程までに摘出するという考え方は，作り込んだバグによる影響を次 工程までにとどめ，早期に品質確保することを意味する．それを，単なる考え方にとどま らず，バグ数を数値として表し，作り込み工程と摘出工程の 2 つの面からマネジメントす ることによって，実際に分析可能としている点に価値がある．
源流管理の視点でマネジメントしていないプロジェクトでは，上流の設計工程の原因で あるほどテストの後半にならなければ問題の認識が困難である．残念なことに実際の開発 現場では，問題を認識する場面の多くが，最終工程であるシステムテストである．その結 果，システムテストで摘出された設計問題を修正するため，多くの後戻り作業が発生する．
再度，設計・コーディングを実施し，関連する周りの部分を含めたテストを実施しなけれ ばならないからである．それまで順調に進んでいたはずのプロジェクトが，システムテス トに入って，突然，数多くのバグが摘出され，止まらなくなる事態の多くは，上流の設計 で作り込んでしまったバグに気が付かずに開発を進めてしまったことに起因する．ソフト ウェア品質会計は，そのような設計問題に起因する失敗プロジェクトを防止し，ソフトウ ェア開発の早い段階からの品質確保を実現する．
上工程品質会計では，レビュー工数（人・時間（Ｈ）/KLOC）とレビューによる摘出バ グ数（件数／KLOC）という 2 つのメトリクスを使用して，品質確保状況を分析可能とす る．品質を判断するための技術が，作り込み工程別バグ分析と品質判定表である．品質確 保状況の視覚化のために，上工程品質会計票グラフを提供している．
品質会計が目標として掲げる上工程バグ摘出率80％も，重要な目標値である．第7章の A組織とB組織の事例を参照すればわかるように，両組織とも，上工程バグ摘出率が80％
を超えた時期に出荷後バグ数が大きく低減した．これらの経験から，品質会計の掲げる上 工程バグ摘出率80％は，出荷後バグ数の低減に対して意味のある基準値と考える．
ソフトウェア開発において，レビューによる品質確保の重要性は古くから提言されてき
は乏しい．そのようななかで，ソフトウェア品質会計技法は，レビューによるバグ摘出を 的確にマネジメントできる手法および基準値を提供している．ソフトウェア品質会計は，
レビューによる早期品質確保を実現する技法であり，その目標である上工程バグ摘出率 80％は，出荷後バグ数の低減に対する１つの具体的な基準値を提供していると言える．
8.3 的確なテスト完了判断
品質会計の原則のうち，テスト工程品質会計会計の原則では，「作り込んだバグは，すべ て摘出してから出荷する」としている．これは，品質会計の考案当時からある考え方であ る．もともと品質会計は，「バグを負債とみなしてその負債をすべて返してから出荷する」
という考え方から発展してきた．この「負債をすべて返したか」を判断するためのテスト 完了判断技法を提供している点が，品質会計の大きな特徴の1つである．
品質会計では，計画したテストをすべて実施した後にテスト完了判断をするために，「バ グ傾向分析」，「バグ分析と1+n施策」，および「バグ収束判定」という３つの技法を使用し て，テスト結果を分析する．３つの技法には，各々目的がある．「バグ傾向分析」は，摘出 した全バグをさまざまな観点から層別して分析することで，テスト観点の大きな抜け漏れ がないかを確認する．「バグ分析と1+n施策」は，テスト終盤に摘出した重要なバグに対し て実施するものであり，重要なバグがテスト終盤まで残存した理由を明らかにし，その原 因に対して対策を打つ．バグ分析と1+n施策は，バグ1件毎に注目することにより，細か い視点での重要なテストの抜け漏れを防止するための技術である．さらに「バグ収束判定」
により，実際にバグが収束傾向にあることを確認する．この３つの技法の分析結果がいず れも問題なしとなったとき，「負債はすべて返した」と判断し，テストを完了する．負債と は残存課題，すなわちその残存課題により残存するバグを意味する．
ソフトウェア開発では，緻密さと正確さを要求される．1箇所の見落としが致命的な問題 を引き起こす．顧客での致命的な問題の発生は，それまでの品質確保のための積み重ねを すべて無に返してしまう．それを未然防止するための技法が，品質会計が提供する 3 つの 技法の組み合わせによるテスト完了判断である．テスト完了判断は，ソフトウェア開発組 織にとって，難易度の高い問題である．B組織の事例（第7章の7.3節参照）が示すように，
品質会計の適用を徹底することにより，精度の高いテスト完了判断が実施できるようにな る．品質会計の重要な特徴は，3つの視点から判断し，いずれも問題なしと判断したときに テスト完了と判断する点にある．ソフトウェアは複雑であり，目に見えず，人間的要素の 影響を大きく受けるという特性をもつ．このような特性をもつソフトウェアのテスト完了 を，一面的な結果だけで判断するのは困難である．その意味で，総合的かつ具体的なテス ト完了判断方法を提示している技法はほとんど見当たらない．そのようななかで，品質会 計がテスト完了判断方法を提供しているのは価値がある．
8.4 バグ分析による課題解決能力の向上
第4章において，バグ分析と1+n施策の技法としての特徴を述べた．品質会計の技法の １つを取り上げて詳細に説明したのは，特にバグ分析の能力が，プロセス改善に与える影 響の大きさを考慮したからである．
的確にバグ分析ができる技術者は，事実に基づいて原因と結果の因果関係を整理して考 える能力があると言える．この原因と結果の因果関係を分析できる能力は，プロセス改善 においても，的確に問題点とその原因を分析し，原因に対して対策を打つことができると いう課題解決能力につながる．この因果関係を分析できる能力が乏しい場合は，思い込み による根本原因分析になってしまう場合が多い．B組織の事例（第7章の7.3節参照）にお いても，改善前には思い込みによる勘違いの改善活動が見られた．例えば，データを見て 考える習慣のない技術者が，パレート図で比率の多い順に原因を表示しているにもかかわ らず，それを使わずに自分の思いこんだ原因に対して改善活動を実施したために，成果が あがらないケースが実際に散見された．しかし，B組織の品質向上活動を開始し，1+n施策 成功率が向上するにつれて，データや事実を見て因果関係を考える習慣ができ，課題解決 能力が増したものと推察される．1+n 施策成功率の数値は，ある意味で問題点と原因の因 果関係の能力を表すものと考えてよい．
品質会計におけるバグ分析は，同種バグを摘出するという目的のために，根本原因の構 造を整理して，バグの作り込み原因と見逃し原因の２つの視点から分けて分析する方法を 提供している．さらに根本原因のうち，固有根本原因を意識して分析し，共通根本原因は 同種バグ摘出には効果が低いため，根本原因の対象には含めないとしている．固有根本原 因とは，技術情報の欠落による設計ミスなど，そのバグを作り込み見逃した直接の原因で ある．共通根本原因とは，教育不足など，そのバグを作り込み見逃した間接的な原因であ る．共通根本原因は間接的な原因であるため，共通根本原因に対して施策を実施しても，
確実に同種バグを摘出できるとは限らないのである．このような，バグ分析の目的を意識 して根本原因の構造を整理する考え方は，プロセス改善の場面においても応用可能である．
バグ分析は，ソフトウェア開発の現場でよく用いられる技法の１つである．しかしながら，
現場で最も適用されているのは，どのような場面でも使える汎用的な技法であるため，時 間をかけているわりに効率的に根本原因を分析できない．汎用的な技法であるトヨタ式「な ぜを５回」をソフトウェア領域へ応用する方法の提案は多いが，なぜの導き方のコツを示 しているものがほとんどで，根本原因の構造を整理する考え方を提示しているものは見当 たらない．そのようななかで，ソフトウェア品質会計は，根本原因の構造を整理する考え 方を示したうえで，同種バグの摘出という目的に絞ったバグ分析技法を提供している点に 大きな価値がある．さらに，バグ分析と1+n 施策の適用により培ったバグ分析の能力は，