ソフトウェア品質データ分析を通じた
組織的改善の促進
東洋大学経営学部 野中 誠
2014年2月4日
ソフトウェアジャパン2014
IPA/SEC ソフトウェア高信頼化センター
• 所属 – 東洋大学 経営学部 経営学科 准教授 • 背景 – 工業経営／経営システム工学，ソフトウェア工学，品質マネジメント • 主な学外活動 – 日本科学技術連盟 SQiPソフトウェア品質委員会 運営委員長 – IPA/SEC 高信頼化定量管理部会主査（『ソフトウェア開発データ白書』） – 組込みシステム技術協会実装品質強化WG メンバー – 日本SPIコンソーシアム 外部理事 – 国立情報学研究所 特任准教授 （トップエスイー講座，メトリクス講義担当） • 主な著書 – 野中・小池・小室著 『データ指向のソフトウェア品質マネジメント』 日科技連出版社 (2012) 2013年度日経品質管理文献賞受賞 – 野中・鷲崎訳 『演習で学ぶ ソフトウェアメトリクスの基礎』 日経BP社 (2009)
– SQuBOK策定部会編著 『ソフトウェア品質知識体系ガイド－SQuBOK Guide－』 オーム社 (2007)
• 研究教育
– ソフトウェア品質マネジメント（メトリクスを中心に） – 情報システムと経営の関わり
デー
タ指向のソフトウェア品質マネジメン
ト
（デート本） メトリクス分析による「事実にもとづく管理」の実践 ソ フ ト ウ エ ア 品 質 メ ト リ ク ス で 、 日 本 に お け る気 鋭 の 研 究 者で あ る 野 中 誠 氏 に よ る 解 説 書 。 ソ フ ト ウ エ ア の 品 質 デ ー タ （ メ ト リ ク ス ） は 、 そ の 収 集 自 体 が 目 的 化 し て は な ら な い が 、 そ の分 析 は 開 発 現 場 で は な く て は な ら な い も の で あ る 。 本 書 は そ の 収 集 ・ 分 析 方 法 、 用 い る べ き モ デ ル な ど を 、 統 計 学 の 初 歩 的 解 説 と と も に 述 べ て い る 良 書 で あ る 。 2012年11月8日号 p.125 書評 ソ フ ト ウ エ ア の 品 質 を 高 め る に は 、 開 発 の 過 程 で 問 題 を い ち 早 く 把 握 し 、 適 切 な 対 策 を 打 つ こ と が 不 可 欠 で あ る 。 そ れ に は 、問 題 を 可 視 化す る こ と が 大 事 だ 。 本 書 は 、 事 例 を 基 に 、 品 質 デ ー タ の 測 定 項 目 や 分 析 手 法 を 解 説 し て い る 。 ソ フ ト ウ エ ア 品 質 に 関 わ る 多 様 なデ ー タ を 測 定 し 、 分 析 を 繰 り 返 す こ と は 容 易 で は な いが 、 分 析 手 順 を 詳 し く 説 明 し て い る 。 事 例 を 読 者 自 身 の 開 発 に 当 て は め て 実 践 し て み れ ば 、 必 要 な 知 2012年11月号 p.110 書評 ・品質メトリクス分析の実践的入門書 ・11
の分析事例 ・データと分析手順の解説をダウロード できる（同じ分析手順を手元で行える） 野中 誠（東洋大学） 小池 利和（ヤマハ） 小室 睦 （元 日立ソリューションズ、 現 富士フイルムソフトウエア） 2012年9月19日発行 主要目次 第１章 品質データ分析の基本 第２章 品質状況の把握 第３章 影響要因の把握 第４章 静的予測モデルの構築 第５章 動的予測モデルの構築 第６章 測定方法 付録講演概要
ソフトウェア信頼性の確保と向上には，ソフトウェア開発に関わる
固有技術
に加え，組織的かつ継続的なプロセス
改善
が必要である．
プロセス改善を実践する一つの鍵は
「事実に基づく管理」
である．
ソフトウェア品質データを分析して「事実」を把握し，これに基づいて
品質目標とその達成方法を計画し，達成状況をデータで確認し，
プロセス改善などの適切な処置をするというPDCAサイクルの実践
が必要であり，
その原動力が品質データ分析
である．
本講演では，組織的改善に結びつくソフトウェア品質データ分析の
具体例を紹介する．
本講演の内容が組織的改善を促し，信頼性の高いソフトウェアを
継続的に開発できる組織能力の涵養につながれば幸いである．
品質データ分析は改善の推進力
• 「事実に基づく管理」は品質管理の基本原則
• ソフトウェア開発における「事実にもとづく管理」は容易でない
– データの測定・収集プロセスが、
人に大きく依存
している
– 目的と整合性のあるメトリクス分析をし続けることが難しい
• ソフトウェア開発において「事実に基づく管理」を進めることが、
中・長期的には品質向上の有効な施策である
– 品質向上（または悪化）のメカニズム
を解明する
– データが示す客観的事実の力
を活用し、改善の推進力とする
– データを手がかりに
原因を特定
し、
アクション
をとり、
効果を確認
する
そして、
– 再発防止のためにプロセスを改善し、失敗プロジェクトを撲滅する
– 顧客価値の向上につながる活動に注力し、顧客の満足度を高める
データが示す客観的事実が改善の推進力になる例：
上流での欠陥摘出と下流での欠陥検出の関係は？
上流工程での欠陥摘出密度（欠陥/規模）
下流工程での欠陥検出密度
（欠陥/規模）
• 実際には 「正の相関」 に
なることも（その方が多い!?）
• 期待している因果関係と
現実のデータが一致して
いるとは限らない
• 自組織のデータを分析した
結果を組織内で共有する
ことで改善が進む
2% 22% 31% 38% 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% 大いに貢献している まあまあ貢献している 貢献しているかどうか何とも いえない あまり貢献できていない まったく貢献できていない
品質部門の活動に対する自己評価
開発部門に対して
（N=42）
顧客／エンドユーザー
の満足に対して（N=42）
経営に対して（N=42）
自己評価結果は
組織によって様々
http://www.juse.jp/sqip/symposium/2013/program/files/happyou_shiryou_E2-1.pdf0 1 2 3 4 5 対開発 対顧客 対経営 品質管 理 信頼性 生産性 0 1 2 3 4 5 対開発 対顧客 対経営 品質管 理 信頼性 生産性
自己評価の高い組織・低い組織
上位３組織
下位３組織
自己評価の高い組織と低い組織では，『面積』に大きな開きがある
上位１０組織 vs 下位９組織の比較
比較項目
上位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
自己評価の高い組織において，
これらの活動は品質部門のミッションであり，ルーチンとして実施されている
http://www.juse.jp/sqip/symposium/2013/program/files/happyou_shiryou_E2-1.pdf実績データの収集・分析：市場流出欠陥のベンチマークデータ
項目 インド 日本 米国 欧州他 合計 or 平均 調査対象のプロジェクト数（件） 24 27 31 22 104（合計） 新規コード行数（KLOC, 中央値） 209 469 270 436 374 出荷後の欠陥密度（中央値） 0.2630.020
0.400 0.225 0.150日・米・欧・印のパフォーマンス比較 （Cusumano et. al., 2003）
新規開発 (N = 520) 改良開発 (N = 349) 出荷後不具合 / KLOC （中央値） 0.016 0.000 出荷後不具合 / KLOC （平均値） 0.106 0.123 IPA/SEC 『ソフトウェア開発データ白書2012-2013』
• 組織横断での比較は，「眉唾」 に思うかもしれない
• 測定方法がほぼ揃った同一組織において，開発の結果をデータで把握し，
その分布や変化を知ることが，改善サイクルを回していく第一歩
例： 「欠陥1件の数え方」 は揃っているか？
Q1：何件の欠陥と数えるか？
設計レビューで、設計仕様書の誤記を発見した。
当該個所
1個所
を修正したのち、これに伴って変更を要する
2個所
（設計仕様書内）を修正した。
設計仕様書 … … … … … … × … … … … … … … … … … … … … … … … … … … … … … … … … … … … …この場合、何件の欠陥として
カウントしますか？
1? 2? 3? それ以上??
野中・小池・小室 『データ指向のソフトウェア品質マネジメント』 日科技連出版社 (2012)Q2：何件の欠陥と数えるか？
結合テストで、プログラムの振る舞いの問題を発見し、
原因が設計仕様にあることが分かった。
設計仕様書の当該個所
1個所
を修正したのち、
これに伴って変更を要するソースコード
2個所
を修正した。
設計仕様書 … … … … … × … … … … … この場合、何件の欠陥としてカウントしますか？ 1? 2? 3? それ以上?? ソースコードA … … … … … … … … … … … … … … … … … … … … … … ソースコードB … … … … … … … … … … … … … … … … … … … … … … … 野中・小池・小室 『データ指向のソフトウェア品質マネジメント』 日科技連出版社 (2012)Q3：何件の欠陥と数えるか？
（続き）その後のシステムテストで、
(2)と同じ対応をし忘れたソースコード
2個所
を発見し、これを修正した。
この場合、全体として何件の 欠陥としてカウントしますか？1? 2? 3? 4? 5? それ以上??
設計仕様書 … … … … … × … … … … … ソースコードA … … … … … … … … … … … … … … … … … … … … … ソースコードB … … … … … … … … … … …… … … … … … … … … … … … ソースコードC … … … … … … … … … … … … … … … … … … … … … … ソースコードD … … … … … … … … … … …… … … … … … … … … … … … (2)での対応の範囲 野中・小池・小室 『データ指向のソフトウェア品質マネジメント』 日科技連出版社 (2012)参考：SQiPシンポジウム2010メトリクスSIGでのアンケート結果
・ 数え方は組織によって様々 なので、このグラフのように 結果がばらつくのは仕方ない ・ しかし、同一の組織内で これだけばらついていたら、 欠陥のデータは意味をなすか？Q1
Q2
Q3
ソフトウェア欠陥1件の数え方の例
原則 ：
プロダクト
の原因部分で集約して１件と数える
原因部分が1個所のみの場合 → 1件 – 要求仕様書の記述に誤りが1個所あり、要求レビューでこれを除去した 原因部分の修正が、ほかの個所に影響する場合 → 1件 – 仕様の問題個所を修正した後に、関連して修正しなければならない仕様書の記述2個所を 修正した … Ｑ１、Ｑ２のパターン 原因が成果物ではなくプロセスにある場合 → 修正個所を別々にカウント – Ｑ３の例は、デバッグプロセスにおける修正漏れという問題のために、2個の欠陥が 新たに入り込んだと解釈する – Ｑ２で識別した１件と、Ｑ３で新たに識別した２件を合計する → ３件 ※ 開発プロセス全体で欠陥の粒度に一貫性を持たせ、 欠陥除去工程のパフォーマンスを正しく評価したい場合 野中（2010）「ソフトウェア品質の定量的管理における曖昧さ－ソフトウェア欠陥測定の原則－」『経営論集』pp.99-109，東洋大学経営学部欠陥の分類：欠陥の数を扱う前に考えなければならないこと
• 欠陥の定量的管理の前提として、欠陥の分類を考えておく必要がある
• 欠陥除去のフロントローディングを議論するときは、機能性欠陥に着目する • 将来の機能性欠陥につながる発展性欠陥は、早い段階で芽を摘んでおく • 欠陥の分類に着目して、プロジェクトの状況を把握する
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)
実績データの収集・分析：
欠陥除去比率 (DRE: Defect Removal Efficiency)
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% 例：詳細設計インスペクションの DRE DRE = 729 / (122+859+939 – 730)
欠陥除去能力の低い工程を特定し、重点改善対象の候補とする
プロセス全体の DRE DRE：ある欠陥除去工程（フィルタ）に入り込んだ欠陥のうち，その工程で除去した欠陥の比率定量的な評価基準：ゾーン分析～レビューの十分性を判断
•
レビュー指摘密度：規模当たりのレビュー指摘件数（件／規模）
•
レビュー工数密度：規模当たりのレビュー工数（工数／規模）
レ
ビ
ュ
ー
指
摘
密
度
レビュー工数密度
① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ⑨ 問題がないと思われるのは？ なぜ？ 品質が悪い可能性があるのは？ なぜ？ 品質が良い可能性があるのは？ なぜ？ 品質を判定できないのは？ なぜ？ 問題があるなら，どのような対策が必要？定量的な評価基準：ゾーン分析の判定例
レ ビ ュ ー 指摘密度 レビュー工数密度 ① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ⑨ 『続・定量的品質予測のススメ』 評価 ⑤ 一応，品質は良好 ⑥ レビューの進め方，体制の点検が必要 ⑧ レビューの進め方，体制，漏れの点検が必要 ⑨ レビュー効率が悪いため，レビューの進め方，体制，漏れの点検が必要 ② 設計不良のため，前工程設計不良，検討不足の点検が必要 ③ 設計不良のため，前工程設計不良，検討不足の点検が必要 ① レビュー不足のため，レビューの進め方，体制， 漏れの点検が必要 ④ レビュー不足のため，品質不良，設計・レビュー点検が必要 ⑦ レビュー不足のため，追加レビューで指摘増となる可能性がある SQiP2012 『SQiP品質保証部長の会 からの情報発信』 評価 ⑤ 問題は発生していない ⑥ ⑧ 品質が良い可能性がある ⑨ ② 品質が悪い可能性がある → 成果物を見直して再レビュー ③ ① ④ ⑦ 品質を判断できる状況にない → 追加レビューが必要か否かを判断モニタリングとアクション：システムテストの状況把握例
対応のアクション案 不具合検出率 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 不具合件数 オープン クローズ 検出された不具合の 内容を確認したところ 序盤としては瑣末な ものが多かった • 開発者の不具合修正対 応が追い付いていない • 検出件数も増加傾向 • 序盤では，重箱の隅を つつくような瑣末なもの よりも致命的な不具合の 検出に注力すべき • テスト担当者に新たに 瑣末な不具合を検出する のではなく，デグレードの 確認に注力させる • 開発者には不具合に 優先度を付けて，重要な ものから確実な対応を 促す グラフと不具合内容確認 からの所見 不具合件数／テスト工数不具合検出率 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日間移動平均 不具合オープン－クローズチャート 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 不具合件数 オープン クローズ
モニタリングとアクション：システムテストの状況把握例
対応のアクション案 不具合の内容は レアケースな手順 によるものが多く， 致命的なものは 殆ど無い • オープンとクローズの 乖離も全く見られないこ とから，検出率の一時的 な増加（２月上旬）にも 余裕をもって対応できて いることがわかる。 • 検出率が安定し，基準内 の数値に収まったことと， 未解決の不具合が無い ことを確認して，リリース 判定の準備をする。 グラフと不具合内容確認 からの所見プロダクトメトリクスにも目を向けよう
•
スタッフ部門が着目するのは、多くの場合、プロセスメトリクス
– 例） レビュー工数、レビュー指摘欠陥数、テスト密度、… – プロセスに着目すること自体は悪くなく、むしろ推奨すべき → プロセスを制御してプロダクト品質を制御するのは品質管理の基本 – しかし、プロセスだけを見て、プロダクトを見ないのはいけない → レビュー工数が足りない、レビュー指摘数が足りない、…が足りないと 言われても、「どの部分に着目して対処すべきか」の解にならない → プロセスメトリクスは、分解能に限界がある•
ソフトウェア開発技術の道理を踏まえた改善を推進しよう
– 凝集度、結合度、複雑度などは、70年代、80年代から言われ続けている ソフトウェアエンジニアリングの基本 – これらの特性を測定するメトリクスは90年代までに数多く示されていて、 ツール化されているものも多い – 保守性を疎かにしていると、後でたいへんな「ツケ」となって回ってくるプロダクトメトリクスの分析例：Twitter４Jのメトリクス分析
（クラスファイル単位で測定）
メトリクス 記号 説明
総メソッド行数 TMLOC Total Method Lines of Code
各メソッドのソースコード行数の合計
重み付きメソッド数 WMC Weighted Methods per Class
各メソッドのサイクロマチック複雑度の合計
結合度 CBO Coupling Between Object Classes
結合関係にある他クラスの数
凝集度の欠如 LCOM Lack of Cohesion in Methods
属性に対してクラス内メソッドが網羅的に
アクセスしていない度合い
応答処理の多さ RFC Response For a Class
応答に用いるメソッド呼出しの種類の数
修正の有無 Modify リリース後に欠陥修正が生じたか否か
（0: なし 1: あり）
注1） これらの無料ツールを用いて測定
- Eclipse Metrics plug-in 1.3.6, http://sourceforge.net/projects/metrics/ - Chidamber & Kemerer Java Metrics, http://www.spinellis.gr/sw/ckjm/
注2） LCOMにはさまざまなバリエーションがあるが，ここではHenderson-Sellersの定義を用いた Henderson-Sellers, B., Object-Oriented Metrics, Prentice-Hall, 1996.
散布図行列で，メトリクスどうしの関係性を俯瞰する
n = 102 TMLOC 0 100 2000.90
0.58 0.0 0.4 0.8 0.170.92
0.0 0.4 0.8 0 400 100 0 0.21 0 1 0 0 200 WMC 0.41 0.180.87
0.24 CBO 0.40 0.58 0 1 02 03 0 0.41 0.0 0 .4 0.8 LCOM 0.24 0.47 RFC 0 100 200 300 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 ) 野中・小池・小室 『データ指向のソフトウェア品質マネジメント』 日科技連出版社 (2012)プロダクトメトリクスと欠陥見逃しの関係分析によって得られた知見
•
コード行数が
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
であった。
レビューやテストの重点化を進めるにあたって，
このようなデータから得られた客観性の高い知見は
プロセス改善の推進力になる
野中・小池・小室 『データ指向のソフトウェア品質マネジメント』 日科技連出版社 (2012)“I‘d rather be vaguely right than precisely wrong.”
正確に誤るよりも、漠然と正しくありたい
– John Maynard Keynes
私たちのメトリクス分析は 「正確に誤って」 いないか？
（自戒の念も込めて）– 理論モデルの洗練や予測精度の向上が目的になっていないか
