「事実にもとづく管理」によるソフトウェア品質の改善ｰヒンシツ大学 Evening Talk #04

「事実にもとづく管理」によるソフトウェア品質の改善

東洋⼤学経営学部野中誠2015年2⽉13⽇

ヒンシツ⼤学 Evening Talk #04

• 所属– 東洋⼤学経営学部経営学科教授

• 背景– ⼯業経営／経営システム⼯学、ソフトウェア⼯学、品質マネジメント

• 主な学外活動– ⽇本科学技術連盟 SQiPソフトウェア品質委員会運営委員⻑– IPA/SEC ⾼信頼化定量管理部会主査（『ソフトウェア開発データ⽩書』）– ⽇本SPIコンソーシアム外部理事– 国⽴情報学研究所特任研究員（トップエスイー講座、ソフトウェアメトリクス）– 厚⽣労働省職業安定局ハローワークシステムに係る調達案件審査委員会委員

• 主な著書– SQuBOK策定部会編『ソフトウェア品質知識体系ガイド第2版－SQuBOK Guide V2－』オーム社 (2014)– 野中・⼩池・⼩室『データ指向のソフトウェア品質マネジメント』⽇科技連出版社 (2012)

（2013年度⽇経品質管理⽂献賞受賞）– 野中・鷲崎訳『演習で学ぶソフトウェアメトリクスの基礎』⽇経BP社 (2009)– SQuBOK策定部会編『ソフトウェア品質知識体系ガイド－SQuBOK Guide－』オーム社 (2007)

• 研究・教育– ソフトウェア品質マネジメント（メトリクスを中⼼に）– 情報システムと経営の関わり

22015/2/13 Makoto Nonaka、 Toyo University

「事実に基づく管理」は改善の推進⼒

ソフトウェアにおける「事実に基づく管理」は難しい– 測定プロセスが⼈に依存していて、データの量と質に問題がある– 多くのメトリクスは⼆⾯性があり、単⼀で良し悪しを判断できない– コード⾏数に対する批判など、古典的な問題が解決されていない

これらの課題を踏まえた上で「事実に基づく管理」を推進することは、継続的な品質改善に向けた有効な施策である

– データが⽰す客観的事実の⼒を活⽤し、実態を把握する– データを⼿がかりに原因を特定し、対策を講じ、効果を確認するそして、– 再発防⽌・未然防⽌のプロセス改善を⾏い、失敗コスト⽐率を下げる– 顧客満⾜度の向上につながる活動に注⼒し、「品質」の向上を図る


「データが⽰す客観的事実の⼒」の例：上流⽋陥摘出と下流⽋陥検出は正・負の相関のどちらか？

4

上流（レビュー）での⽋陥摘出密度（⽋陥/規模）下流

（テ

スト

）で

の⽋

陥検

出密

度（

⽋陥

/規模

）

2015/2/13

負の相関？

• 期待している因果関係と現実の状況が⼀致しているとは限らない

• ⾃組織の状況をデータで把握し、その結果を組織内で共有することが改善への第⼀歩

正の相関？

Makoto Nonaka、 Toyo University

品質部⾨の⽀援業務に対する開発部⾨の評価

5

・組込み系で、「プロジェクト実績データの収集と定量的分析」の有益度評価が低い・品質部⾨が集めたデータを、開発部⾨にうまくフィードバックできていないのが原因？

エンタープライズ系（人数 =< 300) 組込み系（人数 =< 300)

野中・脇⾕「SQiPソフトウェア品質管理・品質保証実態調査」SQiPシンポジウム2012講演資料2015/2/13 Makoto Nonaka、 Toyo University

0

1

2

3

4

5対開発

対顧客

対経営

品質管

理

信頼性

生産性

0

1

2

3

4

5対開発

対顧客

対経営

品質管

理

信頼性

生産性

ソフトウェア開発組織における品質管理能⼒の⾃⼰評価上位３組織 vs. 下位３組織

6

上位３組織

下位３組織

⾃⼰評価の⾼い組織と低い組織では、⾯積に⼤きな開きがある

http://www.juse.jp/sqip/symposium/2013/program/files/happyou_shiryou_E2-1.pdf

2015/2/13

信頼性信頼性

⽣産性⽣産性

品質管理品質管理

開発組織への貢献

開発組織への貢献

顧客への貢献

顧客への貢献

経営への貢献

経営への貢献

（N=42）


2%

22%

31%

38%

7%生産性は高く、経営課題として挙げら

れることはほとんどない

生産性が高いとはいえないが、経営課

題に挙げられるほど低い水準ではない

生産性が高いとはいえないが、少なく

とも今の水準を維持することが経営課

題の一つである生産性が低く、その向上が経営上の重

要課題の一つである

生産性が低く、その向上が経営上の最

優先課題である

ソフトウェア開発組織における品質管理能⼒の⾃⼰評価

2015/2/13 Makoto Nonaka、 Toyo University 7

組織の品質管理レベル（N=41）

信頼性レベル（N=42）

⽣産性レベル（N=42）

10%

29%

24%

37%

再発防止に加え、未然防止

策が有効に機能している

是正措置に加え、再発防止

策が有効に機能している

発生不具合に対する是正措

置が有効に機能している

発生不具合に対する是正措

置が不十分である

5%

21%

48%

24%

2%リリース後不具合はほとんど発生しておらず、経

営課題として挙げらることはほとんどない

リリース後不具合は発生しているが、経営課題

に挙げられるほどの水準ではない

リリース後不具合は発生しているが、少なくとも

今の水準を維持することが経営課題の一つであ

るリリース後不具合が多く、その低減が経営上の

重要課題の一つである

リリース後不具合が多く、その低減が経営上の

最優先課題である


⾃⼰評価結果は組織によって様々

16%

62%

12%

5%5%

7%

48%21%

17%

7% 7%

52%

29%

10%

2%

大いに貢献している

まあまあ貢献している

貢献しているかどうか何とも

いえない

あまり貢献できていない

まったく貢献できていない

ソフトウェア品質部⾨の活動に対する⾃⼰評価

8

開発部⾨に対して（N=42）

顧客／エンドユーザーの満⾜に対して（N=42）経営に対して（N=42）

⾃⼰評価結果は組織によって様々



ソフトウェア開発組織における品質管理能⼒の⾃⼰評価上位１０組織 vs 下位９組織

9

⽐較項⽬

上位1/4の組織下位1/4の組織

実施率ミッション認識率実施率ミッション

認識率

完了済プロジェクトの実績データの収集と分析 0.90 0.80 0.33 0.33

定量的な評価基準・判断基準の策定 0.90 0.60 0.56 0.22

進⾏中プロジェクトのモニタリング 0.90 0.60 0.50 0.13

モニタリング結果の分析とアクション 0.90 0.60 0.25 0.13

不具合の収集と原因分析 0.80 0.60 0.50 0.25

⾃⼰評価の⾼い組織においては、定量的品質管理を軸とした活動を品質部⾨のミッションと位置づけ、ルーチンとして実施している


2015/2/13

（N=42）


リリース後の⽋陥状況：⽋陥密度のベンチマークデータ

10

項⽬インド⽇本⽶国欧州他合計・平均

調査対象のプロジェクト数（件） 24 27 31 22 104（合計）

開発規模の中央値（KLOC） 209 469 270 436 374

リリース後⽋陥密度の中央値（KLOC当たり） 0.263 0.020 0.400 0.225 0.150

⽇・⽶・欧・印のパフォーマンス⽐較（Cusumano et. al., 2003）

Cusumano, M., et. al., “Software Development Worldwide: The State of the Practice,” IEEE Software, Nov/Dec 2003, pp.28-34.

項⽬新規開発(N = 520)

改良開発(N = 349)

リリース後不具合密度の中央値（KLOC当たり） 0.016 0.000リリース後不具合密度の平均値（KLOC当たり） 0.106 0.123

IPA/SEC 『ソフトウェア開発データ⽩書2012-2013』

• この指標で組織横断的に⽐較するのは眉唾かもしれない• 測定⽅法が揃った同⼀組織において、製品を提供した後の状況を把握し、

その分布や変化を知ることが品質改善の第⼀歩


システムテストにおける⽋陥収束状況を把握する不具合オープン・クローズチャートと不具合検出率推移グラフ

アクション案不具合検出率

12/1 12/8 12/15 12/22 1/5 1/13 1/20 1/27 2/3 2/17 2/24 3/3 3/10 3/17 3/25

不具合検出率日毎 5日間移動平均

不具合オープン－クローズチャート

12/1 12/8 12/15 12/22 1/5 1/13 1/20 1/27 2/3 2/17 2/24 3/3 3/10 3/17 3/25

不具合件数オープンクローズ

検出された不具合の内容を確認したところ、序盤としては瑣末な

ものが多かった

• 開発者の不具合修正対応が追い付いていない

• 不具合検出件数も増加傾向• 序盤では、重箱の隅をつつ

くような不具合検出よりも、致命的な不具合検出に注⼒すべき

• テスト担当者には、瑣末不具合の検出ではなく、デグレードの確認に注⼒してもらう

• 開発者には、不具合に優先順位を付けて重⼤なものから確実に対応するよう促す

グラフと不具合内容に対する所⾒

注）検出された不具合が瑣末なものではなく、致命的なものが多い場合は異なるアクションとなる

不具合件数／テスト⼯数


不具合検出率＝不具合検出件数／テスト⼯数

①傾きに着⽬

②乖離に着⽬

③内容に着⽬

④移動平均グラフを描いて傾向を把握

野中・⼩池・⼩室著『データ指向のソフトウェア品質マネジメント』⽇科技連出版社 (2012)

参考：不具合検出率のチャートそのものは昔から使われている


不具合検出率

12/1 12/8 12/15 12/22 1/5 1/13 1/20 1/27 2/3 2/17 2/24 3/3 3/10 3/17 3/25

不具合検出率日毎 5日間移動平均

不具合検出率＝不具合検出件数／テスト工数

Defect Rate= Defects per 1000 Hours

• 現場での様々な⼯夫は、先⼈の誰かがすでに⼿がけていることが多い• そこで諦めるのではなく、「⼩さな⽯」を積み上げ続けていくことが⼤事

野中誠・小池利和・小室睦（2012）『データ指向のソフトウェア品質マネジメント』日科技連出版社

Grady, R.B. and Caswell, D.L. (1987) Software Metrics: Establishing a Company-wide Program, Prentice Hall

テスト進捗状況の把握例テスト進捗管理図

13

オープンチャートに次の要素を追加

• テストケースの消化状況• 管理限界

0.0

0.2

0.4

0.6

0.8

1.0

0.0

0.2

0.4

0.6

0.8

1.0

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

未消

化テストケース数

の比率

累積

欠陥

摘出数

の比率

テスト経過週数（週）

未消化テストケース数

UCL (Upper Control Limit)LCL (Lower Control Limit)累積欠陥摘出数

UCL (Upper Control Limit)LCL (Lower Control Limit)

複数メトリクスの組み合わせで、問題となっている状況を検知する

• 累積不具合検出推移が管理限界を超えている

• テストケースの消化状況が管理限界を下回っている


テスト進捗管理図からのドリルダウン例コンポーネント別テスト進捗状況のモニタリング

14

・コンポーネントCから、多くの不具合が検出されている・コンポーネントCの詳細設計レビューやコードレビューが⼗分ではなかった

可能性がある ⇒ それぞれのレビュー記録を確認

コン

ポー

ネン

ト別

のテ

スト

進捗

（％

）

参考：L. M. Laird and M. C. Brennan, Software Measurement and Estimation: A Practical Approach, John-Wiley and Sons, 2006.（野中・鷲崎訳：演習で学ぶソフトウェアメトリクスの基礎、⽇経BP社（2009））

前スライドの6週⽬時点


⽋陥除去⽐率（DRE: Defect Removal Efficiency）ある⽋陥除去⼯程の開始時点で残存していた⽋陥を、その⼯程でどれだけ除去できたかを表す

15

Laird, L. M. and Brennan, M. C., Software Measurement and Estimation: A Practical Approach, John-Wiley and Sons, 2006 (野中誠・鷲崎弘宜訳：演習で学ぶソフトウェアメトリクスの基礎, ⽇経BP社, 2009).Kan, S. H., Metrics and Models in Software Quality Engineering, 2nd ed., Addison-Wesley, 2002 (古⼭恒夫・冨野壽監訳, ソフトウェア品質⼯学の尺度とモデル, 共⽴出版, 2004).

混⼊除去

要求定義

機能設計

詳細設計

ｺｰﾃﾞｨﾝｸﾞ

単体テスト

結合テスト

ｼｽﾃﾑテスト運⽤合計 DRE

機能設計ｲﾝｽﾍﾟｸｼｮﾝ 49 681 730 74.4%

詳細設計ｲﾝｽﾍﾟｸｼｮﾝ 6 42 681 729 61.3%

コードｲﾝｽﾍﾟｸｼｮﾝ 12 28 114 941 1095 54.8%

単体テスト 21 43 43 223 2 332 36.7%

結合テスト 20 41 61 261 － 4 387 67.1%

ｼｽﾃﾑテスト 6 8 24 72 －－ 1 111 58.1%

運⽤ 8 16 16 40 －－－ 1 81

合計 122 859 939 1537 2 4 1 1 3465 97.7%

例：詳細設計ｲﾝｽﾍﾟｸｼｮﾝの DREDRE = 729 /

(122+859+939 – 730)

⽋陥除去能⼒の低い⼯程を特定し、重点改善対象の候補とする

プロセス全体のDRE


何を⽋陥として捉えるのか？

16

⽋陥（defect）（IEEE 982.1:2005の定義）

障害（fault）

故障（failure）

誤り（error(4),mistake）

把握すべき『⽋陥』の範囲

実⾏される

混⼊される

・故障の原因である障害(fault)と、

・誤りの誘発要因である標準との乖離(anomaly)に着⽬

標準との乖離（anomaly）

誘発される

• 技術要因• マネジメント要因• 組織要因


⽋陥状況を把握するにあたり、⽋陥分類を標準化するとよい

17

• ⽋陥の定量的管理の前提として、⽋陥の分類を考えておく必要がある• ⽋陥除去の前倒しについて議論するときは、機能性⽋陥に着⽬した⽅が望ましい• 将来の機能性⽋陥につながる発展性⽋陥も、その混⼊・摘出状況を把握し、

早期に摘出できていることを確認した⽅が望ましい• ⽋陥の分類に着⽬して、プロジェクトの状況を把握する

Mäntylä, M. V. and Lassenius, C., “What Types of Defects Are Really Discovered in Code Reviews?,” IEEE Trans. Softw. Eng., vol. 35, no. 3, pp. 430-448, 2009.

⼤規模⽋陥

サポート

タイミング

チェック

リソース

ロジック

インタフェース

構造

視覚的表現

ドキュメンテーション

機能性の⽋如、⼤幅な追加・修正が必要

ライブラリの⽋陥

マルチスレッド環境で⽣じる問題

妥当性確認ミス、不正な値の検出ミス

ライブラリ、デバイス、DB、OS等とのインタフェース不整合

⽐較演算⼦、制御フロー、計算などの誤り

データ、変数、リソース初期化、解放などの誤り

コード構造

コードの読みやすさ

コードの説明

参考：コードインスペクション指摘の約70%は、発展性⽋陥を検出(Mäntylä, 2009)

機能性⽋陥(functional defects)

発展性⽋陥(evolvability defects)

障害 (fault)に相当標準との乖離(anomaly)に相当


⽋陥の数をカウントするにあたり、その⽅法が標準化されているとよい

例：システムテストにおいて、結合テスト時に発⾒した設計仕様ミスの修正対応をし忘れたソースコード2個所を発⾒し、これを修正した。

2015/2/13 18

この場合、全体として何件の⽋陥としてカウントしますか？

設計仕様書

… … … … … … … × … … … … … … …

ソースコードA

… … …… … … …

…… … … … … … …

… … … …

ソースコードB

… … …… … …… … … …… … … …… … … …

… …

ソースコードC

… … …… … …… … … …… … … …

… … … … … …

… …

ソースコードD

… … …… … …… … … …… … … …

… … … … … …

… …

結合テストでの修正対応の範囲


詳しくは「ソフトウェアジャパン2014

ソフトウェア品質データ分析を通じた組織的改善の推進」などをご覧ください。

http://www.youtube.com/watch?v=IU7cqPHUuEY

考え⽅の⼀例・プロセス上の問題は２件・構成管理の単位に着⽬した

プロダクト上の問題は３件→ プロダクトの原因部分に

集約して⽋陥を数える

レビューの終了条件を明確化するゾーン分析〜レビューメトリクスの組合せによる判断

• レビュー指摘密度：規模当たりのレビュー指摘件数（件／規模）• レビュー⼯数密度：規模当たりのレビュー⼯数（⼯数／規模）


レビュー指摘密度

レビュー⼯数密度

① ② ③

問題あり？

？

問題なし

⑧ ⑨

SQiP2012『SQiP品質保証部⻑の会からの情報発信』

品質良好？

問題あり？

問題なし

品質良好？

問題あり？

判断不能

上⽅管理限界

下⽅管理限界

上⽅管理限界下⽅管理限界

「この⼯程の⽋陥除去能⼒を⾼めましょう」とだけ⾔って／⾔われて、正しく対処できるだろうか？

20

IPA/SEC「重要インフラ情報システム信頼性研究会」報告書（2009）に⾒る、再発防⽌のための指⽰

・重要インフラ情報システムの障害事例の収集（約100事例）・原因の分析（ソフトウェア⽋陥／運⽤ミス／ … ）・問題構造の分析（障害事例の当事者ではないが、専⾨家が時間をかけて議論）・再発防⽌のポイントを分類・整理例：「複数の経験者によるレビューを徹底し、仕様、プログラムなどを

充分レビューする」

http://sec.ipa.go.jp/reports/20090409.html

重点評価／改善すべき箇所を特定できるソフトウェア品質技術が必要

現場では、「徹底」「充分」とだけ⾔われても困る


⽋陥のありそうなモジュールを特定する：fault-proneモジュール予測

21

ソフトウェア開発プロセス（V字モデル）のコーディング／単体テストが終わった時点で、

機能テスト／システムテストで⽋陥が⾒つかりそうなモジュールを、

ソースコード等から測定可能なプロダクトメトリクスやプロセスメトリクスを⽤いて、

⽋陥がありそうな度合いによってモジュールを⾊分けして、

優先的／重点的にレビューしたりテストしたりすることで、レビューやテストの効率／効果を⾼めたい


CKメトリクスとfault-proneモジュール予測 (Zhou and Leung 2006)


研究言語 WMC DIT RFC NOC CBO LCOM SLOC 備考

Basili 1996 C++ ++ ++ -- + LRBriand 1999 C++ + ++ LRTang 1999 C++ + 0 + 0 0 LRBriand 2000 C++ + ++ ++ - ++ ++ LRBriand 2001 C++ ++ - ++ 0 ++ LRYu 2002 Java ++ 0 + + + + + OLS+LDAEl Eman 2003-1 規模未調整 C++ + 0 ++ + ++ LREl Eman 2003-2 規模調整 C++ 0 0 0 0 ++ LRSubramanyam 2003-1 C++ + - + + OLSSubramanyam 2003-2 Java 0 - - ++ OLSGyimothy 2005 C++ ++ + ++ 0 ++ ++ LR+MLZhou 2006-1 重⼤度⾼ C++ ++ 0 ++ ++ ++ ++ LR+MLZhou 2006-2 重⼤度低 C++ ++ 0 ++ -- ++ + ++ LR+ML++: 強い有意（正）、+: 有意（正）、0: 有意でない、-: 有意（負）、--: 強い有意（負）、空⽩: 未計算または計算⽅法が異なるため未評価LR: ロジスティック回帰モデル、OLS: 最⼩⼆乗法、LDA: 線形判別法、ML: 機械学習

WMC, RFC, CBOは、クラスのフォールトプローン性に対して、ほぼ⼀貫して統計的有意である

Zhou, Y. and H. Leung (2006). "Empirical Analysis of Object-Oriented Design Metrics for Predicting High and Low Severity Faults." IEEE Trans. Softw. Eng., Vol. 32, No. 10, pp. 771-789.

コードの複雑度、結合度、凝集度の⽋如、応答メソッド数

23

1

2

3

5 67

8

9

4

R1R2

R3

R4

WMC ＝ Σ 各メソッドのサイクロマティック複雑度

CC (Cyclomatic Complexity)• 領域の数• 辺の数－ノード数＋ 2

CBO ＝結合関係にある他クラスの数

Class A-attrib A-attrib B-mthd A-mthd B

Class Y

-mthd A-mthd B

Class X

-mthd A-mthd B

Class Z-attrib A-attrib B-mthd A-mthd B

LCOM ＝属性に対してクラス内メソッドが網羅的にアクセスしていない度合い

Class A-attrib A

-attrib B

-mthd A-mthd B

LCOM = 1Class A

-attrib A-attrib B

-mthd A-mthd B

LCOM = 0

CBO = 3

CC = 4

RFC ＝応答に⽤いるメソッド呼出しの種類の数

Class A

-mthd A-mthd B

Class Y

-mthd A-mthd B

呼出元

-mthd A-mthd B

• メソッドAの RFC = 2• メソッドBの RFC = 1 → Class Yのmthd Aはメソッド

Aでカウント済、クラス単位で集約するときは数えない※ 他クラスの属性を直接読み書き

するメソッドは好ましくない

RFC = 3


2015/2/13 Makoto Nonaka、 Toyo University 24参考 http://sonarqube.15.x6.nabble.com/Calculation-of-Response-For-Class-metric-td5000313.html

public class ClassA {private ClassB classB = new ClassB();public void doSomething1(){System.out.println("doSomething");

}public void doSomething2(){System.out.println(classB.toString());

}}

public class ClassB {private ClassA classA = new ClassA();public void doSomethingBasedOneClassA(){System.out.println(classA.toString());

}

public String toString(){return "classB";

}}

RFCの実際の計測例クラスAの RFC = 6

• 外部から呼び出されるメソッドも計測する→ doSomething1, doSomething2

• コンストラクタも計測する→ ClassA

• 重複するメソッド呼び出しは1つのみ計測する→ System.out.prinltlnは⼆重カウントしない

Twitter4Jでの分析例：クラスファイル単位で測定した結果

25

どこに着⽬しますか？n = 102

TMLOC

0 100 200

0.90 0.58

0.0 0.4 0.8

0.17 0.92

0.0 0.4 0.8

040

010

00

0.21

010

020

0 WMC0.41 0.18 0.87 0.24

CBO0.40 0.58

010

2030

0.41

0.0

0.4

0.8 LCOM

0.24 0.47

RFC

010

020

030

0

0.33

0 400 1000

0.0

0.4

0.8

0 10 20 30 0 100 200 300

Modify

参考：R の psych ライブラリのpairs.panels関数で作図

pairs.panels(data, smooth=FALSE, density=FALSE, ellipses=FALSE, scale=TRUE

)

・規模の⼤きいクラス・LCOMの分布

修正

あり

修正

なし


Twitter4Jでの分析例：規模について外れ値を除外し、LCOM > 0 で絞りこんだデータ

26

この散布図⾏列から何が読み取れますか？

n = 53TMLOC

20 40 60

0.90 0.63

0.2 0.6 1.0

0.46 0.89

0.0 0.4 0.8

010

020

030

0

0.12

2040

60 WMC0.44 0.36 0.86 0.075

CBO0.50 0.62

010

20

0.40

0.2

0.6

1.0

LCOM0.44 0.18

RFC

2060

100

0.14

0 100 200 300

0.0

0.4

0.8

0 10 20 20 60 100

Modify

・修正有無の⽐率⇒ 修正率が⾼い

・CBOと修正有無の関係

修正

あり

修正

なし


Twitter4Jでの分析例：LCOM = 0で絞り込んだデータ

27

この散布図⾏列から何が読み取れますか？

n = 47TMLOC

0 50 150 250

0.98 0.27

0 50 100 150

0.85

020

040

060

0

0.29

050

150

250

WMC0.26 0.82 0.30

CBO0.28

05

1015

20

0.30

050

100

150 RFC

0.44

0 200 400 600 0 5 10 15 20 0.0 0.4 0.8

0.0

0.4

0.8Modify

・修正有無の⽐率⇒ 修正率が低い

修正

あり

修正

なし


Twitter4Jのコードメトリクスと、⽋陥発⽣モジュールの対応分析によって得られた知⾒

• コード⾏数が380⾏以上という⼤きいクラスは3個あり、これらはすべてリリース後に⽋陥修正があった（⽋陥修正率3/3 = 1.0）。

• 凝集度の⾼いクラスは46個あり、このうちリリース後に⽋陥修正があったのは15個であった（⽋陥修正率15/46 = 0.33）。

• ⼀⽅、凝集度の低いクラスは53個あり、このうちリリース後に⽋陥修正があったのは42個であった（⽋陥修正率42/53 = 0.79）。

• 凝集度が⽋如していたクラス53個について、結合度の値が中央値の5以下では⽋陥修正率が17/28 = 0.61であったのに対して、中央値より⼤きい場合では⽋陥修正率が25/25 = 1.0であった。

2015/2/13 28

レビューやテストの重点化を進めるにあたって、このようなデータから得られた客観性の⾼い知⾒はプロセス改善の推進⼒になる


参考：Twitter4Jのデータを分類⽊で分析分類⽊の⽣成・表⽰（Rのコマンド）

library(rpart) data.ct <- rpart(Modify~., data=data,

method=“class”) print(data.ct, digit=2)

# 分類⽊をグラフィカルに表⽰plot(data.ct, branch=0.6, margin=0.05)text(data.ct, all=T, use.n=T)

実⾏結果


node), split, n, loss, yval, (yprob)* denotes terminal node

1) root 99 42 1 (0.424 0.576) 2) CBO< 5.5 67 27 0 (0.597 0.403) 4) LCOM< 0.1 39 10 0 (0.744 0.256) *5) LCOM>=0.1 28 11 1 (0.393 0.607) 10) RFC>=26 14 6 0 (0.571 0.429) *11) RFC< 26 14 3 1 (0.214 0.786) *

3) CBO>=5.5 32 2 1 (0.062 0.938) *

|CBO< 5.5

LCOM< 0.1

RFC>=26.5

142/57

040/27

029/10

111/170

8/61

3/11

12/30

合計件数修正なし件数？（修正なし比率修正あり比率）

• CBO<5.5 & LCOM < 0.1 → 修正なし29件(74.4%)• CBO<5.5 & LCOM >= 0.1 & RFC >=26.5 → 8件(57.1%)• CBO<5.5 & LCOM >-= 0.1 & RFC < 26.5 → 3件(21.4%)• CBO>=5.5 → 2件( 6.2%)

修正なし件数 / 修正あり件数

結合度、凝集度、応答メソッド数で修正有無の傾向を説明している※過学習をしてしまっていないか注意が必要（データに特化しすぎて汎⽤性が低い状態）

“I‘d rather be vaguely right than precisely wrong.”

精密に誤るよりも、漠然と正しくありたい

– John Maynard Keynes

私たちのメトリクス分析は精密に誤っていないか？（⾃戒の念も込めて）

– 理論モデルの洗練が⽬的になっていないか– 現場にとって分かりにくい分析結果やモデルになっていないか– その分析結果やモデルは品質向上に貢献するのか

漠然と正しい情報が得られているか？– 意思決定の役に⽴つレベルの精度が得られているか– 正しい意思決定に役⽴つ、正しい⽅向感の情報を⽣み出しているか


品質データ測定・分析のアクションプラン• 上位レベルの⽬的を定める

– 顧客満⾜のために、製品・サービスとして重点管理すべき品質特性は何か例）ISO/IEC 25010:2011 システム／ソフトウェア製品品質モデル

– 事業戦略および製品・サービス戦略の上で重視すべきKPIは何か

• 品質データ測定・分析の直接の⽬的を定める– 製品・サービスに対する顧客の評価（またはその代替指標）を把握したい– 開発中のプロジェクトの品質状況を把握したい– 開発⼯数の⾒積りの妥当性を評価したいなど

• ⽬的達成に必要なメトリクスとその可視化・分析⽅法を検討する– 製品・サービスのリリース後の状況を把握する指標として何を測定するか– プロセス指標・プロダクト指標として何を測定すればよいか– どのような統計量／グラフを⽤いれば必要な情報が得られるか

• 可視化・分析によって得られた情報に基づきアクションをとる– データを通じて把握できた事実に基づき、どのような施策につなげるか


ソフトウェアの品質モデル ISO/IEC 25010:2011 (JIS X 25010:2013)

32

システム/ソフトウェア製品品質

機能適合性

機能完全性機能正確性機能適切性

移植性

適応性設置性置換性

保守性

モジュール性再利⽤性解析性修正性試験性

性能効率性

時間効率性資源効率性容量満⾜性

使⽤性

適切度認識性習得性

運⽤操作性ﾕｰｻﾞｴﾗｰ防⽌性

UI快美性アクセシビリティ

信頼性

成熟性可⽤性

障害許容性回復性

互換性

共存性相互運⽤性

セキュリティ

機密性インテグリティ

否認防⽌性責任追跡性

真正性

＜製品品質モデル＞

2015/2/13

• 明⽰／暗黙ニーズを満たして顧客満⾜／顧客歓喜を実現するために、どのような品質要素／品質特性を重視するのか

• 競争戦略上、どのような品質要素／品質特性を重視するのか

• 戦略的観点も含めて品質要求を定義し、品質要素の達成状況の評価をプロセスに取り⼊れる


当たり前品質と魅⼒的品質

33

特性値が不充⾜特性値が充⾜

⼼理的に満⾜

⼼理的に不満⾜

魅⼒的品質

当たり前品質

⼀元的品質

ある特性が充⾜されることは「当たり前」であり、⼼理的な満⾜度の向上には結びつかないが、それが充⾜されていないと不満を引き起こすような品質要素

ある特性が充⾜されていなくても不満とは思わないが、ひとたびそれが充⾜されると⼼理的な満⾜度が向上するような品質要素

ある特性の充⾜/不充⾜が⼼理的な満⾜/不満⾜と連動するような品質要素


プロセス改善により失敗コスト⽐率を下げ、総品質コストを抑制する

1. 外部失敗コストの低下– テストを重視し、テスト状況を把握し、

外部失敗を内部失敗へと振り分ける

2. 内部失敗コストの低下– レビューを重視し、レビュー状況を把握し、

⽋陥を早期に除去できるようにする

3. ⽋陥除去プロセスの効率向上– レビューとテストの効率向上に努める– リスクベースで活動の重点化を図る– プロセス改善、知識蓄積、教育に投資する

4. 総品質コストの低減・安定化– リスクベースによるレビューとテストの「間引き」が

機能不全に陥らないように注意

34

• ⼀定の品質コストはつねに必要である• その効率向上を追求する必要がある• 安易な品質コストの削減は、取り返しのつかないところまで組織能⼒を衰退させる

品質マネジメント能⼒の成熟度

プロ

ジェ

クト

に占

める

品質

コス

ト

外部失敗コスト

内部失敗コスト

評価コスト

予防コスト


品質にしっかりと取り組めば、組織は賢く、強く、幸せになれる

• 品質にしっかりと取り組む– ソフトウェアを通じて顧客に提供する価値を考える– 価値を提供し続けるために、組織的に必要な活動をデザインする

• 対象とするニーズを定める／新たに掘り起こす• ニーズを満たす製品・サービスの品質要素を計画する（ねらいの品質）• 品質要素の実現度合い（できばえの品質）を保証するプロセスを確⽴する• 品質要素の実現に係る固有技術と、管理や品質保証に係る技術を進化させ、

価値提供のスピードを加速する• 提供した価値に対する顧客満⾜の度合いを評価する• 「事実に基づく管理」を主軸にして、プロセスを継続的に改善する• この過程で得られた知識を、組織的に活⽤する

• 組織が賢く、強く、幸せになる– 価値提供の結果／⾃社独⾃の経験／失敗に学び、組織が賢くなる– 組織独⾃の知識・技術／継続的改善能⼒は、競争優位の源泉である– 賢く強い組織は、幸せになる


Software

「事実にもとづく管理」によるソフトウェア品質の改善 ｰ ヒンシツ大学 Evening Talk #04

「事実にもとづく管理」によるソフトウェア品質の改善ｰヒンシツ大学 Evening Talk #04