1. 5th World Congress for Software Quality – Shanghai, China – November 2011
問題のリアルタイム検出による品質改善
－ プロジェクト失敗を防止する開発予報 －
Quality Improvement by the Real-Time Detection of the Problems
－ DevCast (Development Forecast) for the Failure Project Prevention －
Takanori Suzuki（鈴木 貴典）
Acroquest Technology Co. Ltd, （アクロクエストテクノロジー株式会社）
Kanagawa, Japan
takanori@acroquest.co.jp
Abstract
ソフトウェア開発において，定量的管理を実施していても，実際は属人性により不
十分な分析となっている場合がある．例えば，テストで品質を十分に確保できてい
ることを判断するために，バグ検出密度やバグ収束度で評価することが多いが，テ
ストの結果には，テスト項目の精度やテスト担当者のスキルなども影響しており，
単純にバグの結果だけでは評価できない．
そのような状況を打開するためには，後から品質分析を行うのではなく，リアルタ
イムに分析を行い，問題を検出することで，プロジェクトの失敗を未然に防止する
手法が必要である．
本稿では，その取り組みのひとつとして，多角的な静的品質解析の有効性，および，
テスト結果との関連性を評価した．
1. はじめに
ソフトウェア開発プロジェクトにおいて，プロジェクトの成功率は約 30％しかな
い[1]．ここで言う「成功」とは，品質／コスト／納期が，当初の計画範囲内で完了
したことを指すが，成功する確率よりも失敗する確率の方が圧倒的に高い，という
状況は本来異常である．しかしながら，この傾向は，日本国内だけでなく海外でも
同様であり，さらに，何年も変わらず低い水準に留まっている[2]．
品質分析／改善は常に重要視されてきている分野であるが，それでも大きな変化が
ないということは，それだけ有効な手法が確立できていないと考えられる．
特に，昨今は品質問題の発生により失敗するプロジェクトが多い．品質問題が発生
したプロジェクトは，開発側や依頼元だけの問題ではなく，社会に対する影響も大
きくなってきている．そのため，本稿では品質に着目し，問題をリアルタイムに検
出・改善していく活動について提案する．
2.
“ 見えない ” 品質問題
ソフトウェアテストにおける品質を評価するために利用されるメトリクスとして，
バグ検出密度（＝バグ検出数／テスト対象規模）やバグ収束率（＝総バグ検出数／
バグ予測件数）などを利用することが多い．しかしながら，これらのメトリクスは，
テスト項目の網羅度や信頼度，テスト実施の精度などとは無関係である．
テスト完了の判断基準としては，上記のメトリクス以外にも，以下のような影響因
子を考慮する必要があるはずである．
・ テスト項目の入力成果物となる仕様書の質
・ テスト項目の質
・ バグの質

2. 5th World Congress for Software Quality – Shanghai, China – November 2011
・ テスト担当者の質
しかしながら，これらの因子を全て適切に考慮することは困難である．そのため，
あるテスト工程で基準値は満たしていたとしても，その後の工程やリリース後で想
定以上のバグが検出され，品質問題で失敗となるプロジェクトが後を絶たない．
Figure 1. テストの完了基準と影響因子
プロジェクトの基本的な管理指標として QCD（Q：品質／C：コスト／D：納期）
が利用されるが，コストや納期は，比較的容易に算出することが可能なのに対して，
品質は単一のメトリクスとして評価することが難しい．結果，品質問題は必然的に
見えにくくなり，問題を検出できたとしても，納期などを考えると既に手遅れとな
っている場合が多い．
また，実際の開発現場では，コスト・納期の制約により，品質が犠牲になってしま
う場合が多い．

3. 5th World Congress for Software Quality – Shanghai, China – November 2011
Figure 2. テスト工程における理想と現実のギャップ
このような状況を打開するためには，現状をリアルタイムに把握し，そこから将来
を予測し，改善していく手法が必要だと，筆者は考えている．
3. プロジェクト成功への道を見通す
1950 年代ごろに，ウォルター・シューハート（Walter A. Shewhart）、エドワー
ズ・デミング（W. Edwards Deming）らによって，PDCA サイクルというマネジ
メントのサイクルが提唱され[3]、ソフトウェア開発プロジェクトでも広く利用され
るようになった．しかしながら，現代のソフトウェア開発プロジェクトは，大規模
化・期間短縮化され続けている上に，必要となる技術要素も日々変化し，開発の体
制もオフショア／ニアショアなどの分散拠点となっている．そのため，複雑性・不
確実性は増すばかりであり，改善どころか最初の計画自体を立てることでさえでき
ず，失敗してしまうプロジェクトも多い．
そのような状況に対して，筆者は，過去から現在までの状況を測定・評価すること
から改善に繋げる
「開発予報」
というアプローチを提案している．これは，計画あり
きのプロジェクト管理ではない．ツールなどを活用し，事実（成果物）に基づくデ
ータを自動で収集・分析することで，プロジェクトの失敗に繋がるリスクをリアル
タイムにフィードバックしていくアプローチである．
Figure 3. 失敗防止のためのアプローチ
今回，本アプローチをソースコードの静的解析に適用して考え，そこで得られた結
果と，その後の工程で行われたテストとの関連性を考察した．
4. ソースコードの多角的分析に関する考察
静的解析を行うことは品質向上に有効である，といった旨の研究は多く成されてい
るが，テストとの関連性を評価した研究は余りない．
本稿では，Java 言語を用いたあるソフトウェア開発プロジェクトについて，ツー
ルを利用したソースコードの静的な品質解析を実施し，テストにおけるバグ件数に
基づいた品質評価との関連性を評価した．

4. 5th World Congress for Software Quality – Shanghai, China – November 2011
4.1 分析内容
本稿では，
「Table 1. 静的品質評価」
に示すメトリクスでソースコードの品質を評価
した．ここでは，それら複数の観点での評価全体をまとめて
「静的品質評価」
と呼ぶ
こととする．
No
メトリクス
Table 1. 静的品質評価
利用ツール
説明
1)
コーディング規約違反
Checkstyle
プロジェクトで定められたルールで検出された致命的
なエラー件数をカウント。
2)
静的解析エラー
FindBugs
ツールで検出されたエラー件数をカウント。
3)
複雑度
JavaNCSS
McCabe の循環的複雑度（CCN）が 30 以上の関数の
件数をカウント。
4)
コードクローン
CPD
重複されるコードのライン数をカウント。
上記で利用したツールは，オープンソースのツール[4]であり，開発の現場で一般
的に利用されているものである．
これらの解析結果を機能間で比較できるようにするために，1)～3)のエラー件数の
合計値，および，4)のコードクローンのライン数を，機能毎の規模（ライン数）で
割ることにより，それぞれ，密度，および，割合を算出するようにした．
さらに，上記の静的品質評価の結果と，同じプロジェクトに実施されたテスト・出
荷判定で検出されたバグとの関連性を分析することで，静的品質評価の有効性を評
価した．
4.2 静的品質評価とテスト結果との関 係
評価対象のプロジェクトでは A～E の 5 つの機能が存在したが，静的品質評価を実
施したところ「Figure 4. アプローチ静的品質評価結果」に示すような結果となった
エラー検出密度
Figure 4. アプローチ静的品質評価結果
コード
クローン率

5. 5th World Congress for Software Quality – Shanghai, China – November 2011
次に，同機能に対して，結合テストと出荷判定で検出されたバグをまとめると，
「Figure 5. 結合テストと出荷判定のバグ検出結果」に示すような結果となった．
試験でも
バグが多いが、
まだバグを検出し
切れて
いなかっ
た
バグ密度（
結合テスト
）
試験ではバグ密度が目標値に
達し
ていたが、
実は、
バグの
検出漏れが多かっ
た
バグ密度（
出荷判定）
目標値
試験、
出荷判定共に、
バグが少ない
＝高品質
Figure 5. 結合テストと出荷判定のバグ検出結果
「Figure 5. 結合テストと出荷判定のバグ検出結果」を見ると，以下のような傾向が
見て取れる．
・ 結合テストでバグが多い機能が出荷判定でもバグが多く検出されるもの
（機能 A）もあれば，結合テストで目標値を超過していない機能であって
も出荷判定では多く検出されるもの（機能 D）もある．
・ 上記の逆で，結合テストで目標値に達しておらず出荷判定でも検出が少な
い，つまり高品質であったと考えられるもの（機能 C）もある．
この結果を考えると，テストだけで品質を評価することが如何に難しいかが分かる
（※ただし，テストによる品質評価が無意味，ということではない）．
一方，
「Figure 4. アプローチ静的品質評価結果」 「Figure 5. 結合テストと出荷判定
と
のバグ検出結果」とを比較すると，静的品質評価で問題が多かった機能（機能 A／
機能 C／機能 D）は，出荷判定で問題が多かった機能と一致していることが分かる．
検出された問題の件数に線形的な関係が見られるわけではないが，問題となる機能
が一致するという傾向が見られるのは，静的品質評価は，テストを実施する前に，
リスクのある機能を特定するには有効な手段のひとつであると考えられる．
つまり，コーディング工程の段階で，成果物であるソースコードに対して静的品質
評価を行い，問題のある機能を特定することで，その後のテスト工程における漏れ
などのリスクを避け，品質改善をすることが期待できる．
5. おわりに

6. 5th World Congress for Software Quality – Shanghai, China – November 2011
本稿では，プロジェクトの失敗を未然に防ぐ手法のひとつとして，プロジェクトの
失敗に繋がるリスクをリアルタイムにフィードバックしていくアプローチ，および，
その具体的な手法として，多角的な静的品質解析の有効性を評価した．その結果，
テストを実施する前に品質的なリスクのある機能を特定でき，その後の改善に繋げ
られることが分かった．
これは，成果物自体をツールで解析しているため，属人性の排除とリアルタイム性
を期待できる品質分析手法である．進行中のプロジェクトに対して，失敗を防止す
るためにはこのような手法が有効であると，筆者は考える．
今後の課題としては，以下のようなことが考えられる．
1. 多数のプロジェクトを対象にした統計分析
2. メトリクス種別による影響の傾向分析
3. 設計工程における同様の分析手法の検討と検証
References
[1] 日経コンピュータ（2008 年 12 月 1 日号）特集 1 “第 2 回プロジェクト実態調
査 800 社”, 日経 BP 社, 2008.
[2] Jorge Dominguez, The Curious Case of the CHAOS Report 2009, Project
Smart, 2009
[3] Wikipedia [Online], http://en.wikipedia.org/wiki/PDCA (accessed on 2008/12)
[4] Checkstyle(http://checkstyle.sourceforge.net/),
FindBugs(http://findbugs.sourceforge.net/),
JavaNCSS(http://javancss.codehaus.org/),
CPD(http://pmd.sourceforge.net/cpd.html)

7. 5th World Congress for Software Quality – Shanghai, China – November 2011
本稿では，プロジェクトの失敗を未然に防ぐ手法のひとつとして，プロジェクトの
失敗に繋がるリスクをリアルタイムにフィードバックしていくアプローチ，および，
その具体的な手法として，多角的な静的品質解析の有効性を評価した．その結果，
テストを実施する前に品質的なリスクのある機能を特定でき，その後の改善に繋げ
られることが分かった．
これは，成果物自体をツールで解析しているため，属人性の排除とリアルタイム性
を期待できる品質分析手法である．進行中のプロジェクトに対して，失敗を防止す
るためにはこのような手法が有効であると，筆者は考える．
今後の課題としては，以下のようなことが考えられる．
1. 多数のプロジェクトを対象にした統計分析
2. メトリクス種別による影響の傾向分析
3. 設計工程における同様の分析手法の検討と検証
References
[1] 日経コンピュータ（2008 年 12 月 1 日号）特集 1 “第 2 回プロジェクト実態調
査 800 社”, 日経 BP 社, 2008.
[2] Jorge Dominguez, The Curious Case of the CHAOS Report 2009, Project
Smart, 2009
[3] Wikipedia [Online], http://en.wikipedia.org/wiki/PDCA (accessed on 2008/12)
[4] Checkstyle(http://checkstyle.sourceforge.net/),
FindBugs(http://findbugs.sourceforge.net/),
JavaNCSS(http://javancss.codehaus.org/),
CPD(http://pmd.sourceforge.net/cpd.html)