ソフトウェア品質シンポジウム software quality...

ソフトウェア開発における品質分析・評価プロセスの改善とその効果

富士通九州ネットワークテクノロジーズ㈱第二開発統括部第五開発部

森川敏寛 [email protected]

ソフトウェア品質シンポジウム Software Quality Symposium

2015

Copyright 2015 Fujitsu Kyushu Network Technologies LIMITED

目次

1.はじめに 2.実施内容 3.実施結果 4.考察 5.振り返り

Copyright 2015 Fujitsu Kyushu Network Technologies LIMITED 1

目次



1.はじめに 2.実施内容 3.実施結果 4.考察 5.振り返り

2

1.はじめに


市場フェーズのクレームが多かったプロジェクトの出荷品質を改善させるべく、品質管理者として、「品質分析・評価プロセスの改善」を実施して参りました。この改善で特に工夫したこと、および得られたことについて事例を報告します。なお、主な改善は下記の通りです。・検出バグの真の根本原因追究、その根本原因に基づく類似調査と再発防止策定の作業プロセスの標準化

・診断で検出したその他の弱点プロセスの改善

3

目次



1.はじめに

2.実施内容・・・ 7つのプロセス 3.実施結果 4.考察 5.振り返り

4

新たな課題 ②改善計画

④改善施策の合意 (ネゴシエーションと説得)

⑤改善施策の適用 (形を造る)

⑥フォロー（魂の伝承)

開発現場へ

⑦改善施策の評価 (振り返り)

開発終了時

①品質プロセスの診断

標準化

③改善施策の検討

PDCA サイクル

ナレッジ化

品質分析・評価プロセスの改善

知恵の蓄え知恵の蓄え

２. 実施内容


品質プロセスの診断による改善前の品質分析・評価プロセス評価結果

012345

①定量評価プロセス

②工程移行判定プロセス

③PDCA改善プロセス (振り返り分析等)

④定性評価プロセス (問題傾向分析等)

⑤根本原因追究による是正

プロセス

改善前

弱点プロセスがあった

２. 実施内容【①品質プロセスの診断】

[3.5]

[0.7]

[1.5] [2.3]

[3]


(1/4)

6

品質分析・評価プロセスの診断チェック方法チェック観点

品質分析・評価プロセスの標準化と遵守状況をチェック(別紙1参照)

①定量評価：品質指標値の設定、乖離分析と対策など ②工程移行判定：工程移行判定 ③PDCA改善サイクル：品質目標達成状況の振り返りなど ④定性評価：定性評価、問題傾向に基づく品質強化 ⑤根本原因追究による是正：混入バグの根本原因追究など

評価方法数値データによる判定ではなく主観により5段階で評価 (適切:5,やや適切:4,どちらともいえない:4,やや不適切:2,不適切:1,プロセスなし:0)

主な確認資料開発計画書, 作業標準, 品質報告書, レビュー報告書, 問題管理簿


２. 実施内容【①品質プロセスの診断】 (2/4)

7

診断で抽出した開発フェーズの主な弱点プロセス２. 実施内容【①品質プロセスの診断】

Input

根本原因に基づく類似調査

検出バグの真の根本原因追究現物への対策 (品質担保)


⑤根本原因追究による是正プロセス [ 実態 ] ・検出バグの扱い → 開発者の裁量まかせ・レビュー報告書と問題管理簿の書式 → 根本原因/類似調査/再発防止の記入枠が無い [弱点ﾌﾟﾛｾｽ] ・類似調査による品質担保、再発防止策定のプロセスが無い → 品質担保状況、再発防止策定状況が不明 → 振り返りが無い/開発者の成長の妨げ/残念なﾌﾟﾛｼﾞｪｸ

J 開発作業 (工程作業、工程移行判定等) バグ検出

開発プロセスへのフィードバック

(再発防止)

開発計画 (標準化)

根本原因に基づく再発防止策定

(3/4)

8

④定性評価プロセス

２. 実施内容【①品質プロセスの診断】診断で抽出した開発フェーズの主な弱点プロセス

品質報告書(機能ブロックや開発項目毎)

レビュー報告書

問題管理簿

【定性評価】検出バグの分析結果



【定性評価】問題傾向に関する考察検出バグに関する考察

【定量評価(品質指標値)】バグ/レビュー/試験項目

品質報告書(全体)

積み上げ

積み上げ

品質データ集計結果

集計

土台


[実態] 品質報告書の考察

→ 記載レベルがまちまちバグ傾向分析の考察

→ 数値根拠が無く感覚的 [弱点プロセス] 品質報告書の各項は

分析・評価内容が不明確品質評価をする際の土台となるプロセスが不十分

(4/4)

9

1年目 2年目 3年目 4年目

Step1 (80%) Step2(20%)

品質分析・評価プロセスの骨格構築

品質分析・評価プロセスの改善施策スケジュール

Step3 Step4 Step5 Step6 Step7 Step8

品質分析・評価プロセスの改善と PDCA改善サイクルの取り組み

・設計や試験工程で次工程以降に流出したバグに対する真の根本原因追究、根本原因に基づく類似調査と再発防止策定のプロセスを標準化(流出視点)

・混入バグに対する真の根本原因追究、根本原因に基づく類似調査/再発防止策定のプロセスを標準化(混入視点)

・診断で抽出した弱点プロセスの改善・品質分析・評価プロセスの評価からの新たな課題の改善

品質プロセスの診断

２. 実施内容【②改善計画】


・品質目標達成状況の振り返り/工程作業の振り返りからの課題の改善(従来から継続)

※該当プロジェクトは半年毎にエンハンスする開発スタイルであったため、改善施策も半年スパンで進めた。

(1/2)

10

診断結果改善計画プロセス分類診断対象のプロセス 5段階

評価時期施策


品質指標値の設定 3 Step3 品質指標値の精度向上品質指標値の測定 4 - - 品質評価基準の妥当性 4 - - 乖離要因分析と対策 4 Step3 品質指標値の精度向上

②工程移行判定プロセス工程移行判定 3 Step1 工程移行会議の見直し

③PDCA改善サイクルプロセ

ス

予防措置 0 Step4 以降開発要件分析に対する予防

工程作業の振り返り 2 Step1 工程振り返り会の見直し品質目標達成状況の振り返り 5 - -


定性評価 2 Step1 品質報告書の書式見直し定性評価の見直し(数値化)

問題傾向に基づく品質強化 1 Step1 品質報告書の書式見直し

⑤根本原因追究による是正

プロセス

混入バグの根本原因追究 1 Step1

品質分析・評価プロセスの骨格構築

混入した設計工程で検出できずに次工程以降に流出したバグの根本原因追究 0 Step2

検出すべき試験工程で検出できずに次工程以降に流出したバグの根本原因追究 1 Step2


２. 実施内容【②改善計画】 (2/2)

11

他プロジェクト/他社事例を参考に検討工夫したこと

２. 実施内容【③改善施策の検討】

「続定量的品質予想のススメ(IPA)」からレビューア参加率(※1)の考え方を取り入れた

→ 有識者によるレビュー状況が明らかになった ※1:レビューアをランク分けし、レビューア毎の評価点と出席率を掛けて求める

④定性評価プロセスに対する改善課題レビューの質を定量評価する

品質考察に『有識者にてレビューを実施しているため問題なし』とあるが、有識者とは誰、どのような人？品質考察が具体的でないため、妥当性が判断つかない

【事例】


プロジェクトマネージャ(以下 PM)へのネゴシエーションとリーダへの説得

２. 実施内容【④改善施策の合意】

開発リーダから合意を得るために・・・ →PMへのネゴシエーション →そして、PMの協力を得て開発リーダを説得

開発者の作業負荷が増える改善施策 →各リーダから合意を得るのは非常に難しい

工夫したこと


レビュー報告書、問題管理簿現品対処と合わせて、タイムリーに根本原因追究と根本原因に基づく対策の実施が可能な書式に改善

品質報告書根本原因追究、根本原因に基づく対策、問題傾向に対する対策が見える化可能な書式に改善

レビュー報告書集計ツール多量のレビュー報告書を効率的に集計可能に改善

形を造る(道具を準備して形を造る)

２. 実施内容【⑤改善施策の適用】

№ 問題内容処置内容混入工程・・・根本原因 (要約と内容)

類似調査 (観点・範囲・結果)

再発防止策 (改善内容、改善時期)

1 2 既存への影響を抑え、既存の枠外に追加

工夫したこと


魂の伝承 (より良い効果を得るため、魂を注入する)

２. 実施内容【⑥フォロー】工夫したこと

その１：記載例を用いた展開その２：内容を見て直接アドバイスその３：コツコツとノウハウを文章化(ナレッジ化）そして教育(ノウハウ伝承）

評価パターン毎の考察事例を準備し、認識合わせを行い、考察レベルを統一

その1:記載例を用いた展開


(1/4)

15

スピーディに的外れのない根本原因追究方法を指導

【問題報告会※1の事例】根本原因追究に問題はないかを確認

検出バグに対して、実際の姿(行ったこと) の確認、あるべき姿(プロセス)の差異から根本原因を追究

類似調査による品質担保の妥当性を確認根本原因に基づいて混入と流出の視点で類似調査観点や範囲を絞り込みできているかを確認

再発防止策定の妥当性を確認根本原因の裏返しにより、現実的な対策としているかを確認

２. 実施内容【⑥フォロー】


その2:内容を見て直接アドバイス LM PM

品質管理者

レビューア担当者

リーダ現物確認、質問の順番で進めます

※1:上流工程の検出バグや機能試験以降の検出バグを対象に1件につき1時間実施

(2/4)

16


２. 実施内容【⑥フォロー】その3:ノウハウのナレッジ化とノウハウ伝承

※1:原理・原則から始まり、手順、根本原因追究の妥当性判断基準等を事例を含めて体系的に整理したプレゼン形式のナレッジ資料

(54頁,ナレッジ歴2年)

ノウハウをこつこつとナレッジ化開発者へナレッジを基にノウハウ伝承【事例1】

例えば「○○な考えで進めると上手く追究できる」等のノウハウをこつこつ『実践！根本原因分析手法※1』というナレッジにして、開発者へ展開

ver.10

(3/4)

17

【事例2】根本原因追究レベルの底上げとして、「根本原因分析手法」の考え方を『根本原因追究フローチャート※2』というナレッジにして、開発者へ展開


２. 実施内容【⑥フォロー】

※2:バグは開発作業のどのプロセスに起因するかを特定し、特定したプロセスに対して根本原因を追究する仕組み。単純ミス/思い込み/解釈誤りを根本原因とはしないで、あるプロセスの結果と捉え、結果に至るプロセスに対し、根本原因を追究する。

(4/4)

18

振り返り (効果を評価し、弱点があれば改善する) 開発完了時、計画前に掲げた数値目標に対する達成

状況を評価未達成時、継続課題として、次期開発にて課題解決に

取り組む

工夫したこと


２. 実施内容【⑦改善施策の評価】

19

目次



1.はじめに 2.実施内容

3.実施結果・・・４つの効果 4.考察 5.振り返り

20

0.11

0.15

0.04

0.12

0.00

0.05

0.10

0.15

0.20

0

5

10

15

20

1年目 2年目 3年目 4年目

類似

バグ

検出

密度

(件/K

s)

類似

バグ

件数

(件)

類似バグ件数(件) 類似バグ検出密度(件/Ks)

[改善後] 類似バグ検出密度:平均0.10件/Ks

検出バグと同種のバグが検出可能となり品質担保の状況が明らかになった

(根本原因に基づく類似調査するというプロセスの遵守状況が明らかになった)


３. 実施結果【効果①:類似調査の効果】

このバグは、改善前では試験工程で検出できていたとは言い切れず、市場フェーズへ流出していた可能性が高い → 効果④(市場フェーズのバグが減少)に作用

21

[改善後] 再発防止密度:平均1.0件/Ks

バグを混入させない/バグを流出させないとする開発プロセスへのフィードバック課題が明らかになった

(根本原因に基づく再発防止策定をするというプロセスの遵守状況が明らかになった)


③試験工程で流出したバグの再発防止 3％

②設計工程で流出したバグの再発防止 11%

①根入バグの再発防止

86%

３. 実施結果【効果②:再発防止の効果】

再発防止は、同様なバグの再発を防止するもの →効果③(開発工程のバグが減少)に作用

1.1

1.3

0.7

1.1

0.0

0.5

1.0

1.5

2.0

0

50

100

150

200

1年目 2年目 3年目 4年目再

発防

止密

度(件

/Ks)

再発

防止

件数

(件)

8431152011 21

0.00.51.01.52.0050100150200

1… 3… 再発

防止

率…①混入バグの再発防止

②設計工程で流出したバグの再発防止③試験工程で流出したバグの再発防止再発防止密度=(件/Ks)

(1/3)

22

1.4%0.9%

9.6%25.3%

13.7%49.1%

0% 10% 20% 30% 40% 50%

①設計書改善

②ツール導入

③プロセス改善

④設計観点追加

⑤レビュー観点追加

⑥自己チェック観点追加

設計工程/製造工程に対する再発防止策定状況 (バグ混入したこと、および混入工程でバグを検出できなかったことに対する再発防止の策定状況)

【特徴】 ①②の恒久対策は僅か2.3% ⇒ 恒久対策は難しい ⑥の個人対策は半数を占める ⇒ 全体共有不要な開発スキルレベル

有効性分類再発防止策定の概要・事例

高恒久的プロセス改善

①設計書の記載枠や章立ての改善 ②目視確認ミス防止のツール化

中プロセス改善 ③開発規約へプロセスの追加

低観点追加 ④設計規約へ設計観点の追加 ⑤チェックリストへレビュー観点の追加 ⑥個人チェックリストへレビュー観点の追加

2.3％

：流出視点の再発防止策：混入視点の再発防止策

３. 実施結果【効果②:再発防止の効果】


(2/3)

23

*1*2

*3*4

0%

5%

10%

15%

20%

25%

30%

35%

6%

11%

22%

33%

11%

17%

*1:試験実施観点追加 *2:試験確認観点追加 *3:項目抽出観点追加 *4:混入の再発防止でカバー

試験工程に対する再発防止策定状況 (検出すべき試験工程でバグを検出できなかったことに対する再発防止の策定状況)

【特徴】対策なし 17% ⇒ 混入の再発防止でカバーされるため

(設計工程の再発防止により項目抽出が可能等の理由) 機能試験への対策 61% (6+22+33)

⇒ 機能試験で品質確保するとしている方針の現れ (プロジェクトにより異なる)


３. 実施結果【効果②:再発防止の効果】 (3/3)

24

0

5

10

15

20

25

-3年目 -2年目 -1年目 1年目 2年目 3年目 4年目

バグ

密度

(件/K

s) -30%

-65%

-28%

-42%

-53%

24％

[改善後] バグ密度の平均:-53％減少

[改善前] バグ密度の平均:-29％減少：開発工程内のバグ密度(改善前) ：開発工程内のバグ密度(改善後)


３. 実施結果【効果③:開発工程のバグが減少】

・効果②再発防止による効果・Step1,2の副次的効果 (品質マインド/開発スキルの向上、開発プロセスの習熟度が高まった等)

相乗作用【減少要因】

25

0.00

0.01

0.02

0.03

0.04

0.05

0.06

-3年目 -2年目 -1年目 1年目 2年目 3年目 4年目

バグ

密度

(件/K

s)

[改善前] バグ密度の平均:0.04件/Ks

[改善後] バグ密度の平均:0.01件/Ks 改善前の1/4に減少(-75%)

：市場フェーズのバグ密度(改善前) ：市場フェーズのバグ密度(改善後)


３. 実施結果【効果④】市場ﾌｪｰｽﾞのﾊﾞｸﾞが減少】

・効果①類似調査による効果・Step1,2の副次的効果 (品質マインド/開発スキルの向上、開発プロセスの習熟度が高まった等)

相乗作用【減少要因】

26

012345

改善後改善前

３. 実施結果【①品質プロセスの診断】

品質プロセスの診断による改善後の品質分析・評価プロセス評価結果


②工程移行判定プロセス

③PDCA改善プロセス (振り返り分析等)

④定性評価プロセス (問題傾向分析等)

⑤根本原因追究による是正プロセス

[3.5→4.9]

[0.7→5?]

[1.5→5?] [2.3→4.7]

[3→4]


目次



1.はじめに 2.実施内容 3.実施結果

4.考察 5.振り返り

28

【Step1,2】バグの根本原因追究プロセスを構築

根本原因が明らかになった

【効果①】類似調査により検出バグと同種のバグが検出可能となった

【効果②】再発防止の策定によりフィードバック課題が明らかになった

開発者の成長・品質マインドの向上 (バグを根入させない/流出させないという意識の向上) ・開発スキルの向上・品質分析力の向上

【効果③】開発工程のバグが減少

【効果④】市場フェーズのバグが減少

直接的効果

副次的効果

PDCA改善サイクル

骨格構築

４. 考察

余裕が生まれ物造りに集中

開発プロセスの成長・習熟度が高まる

【Step3以降】品質分析・評価プロセスの改善

副次的効果

副次的効果

副次的効果


品質分析・評価プロセスの改善による相乗作用の効果

29

目次



1.はじめに 2.実施内容 3.実施結果 4.考察

5.振り返り 30

Plan 品質目標の設定品質施策の策定

Do 品質施策の実行

Check 実行結果の評価

(振り返り)

Action 見直しや標準化

新たな課題

標準化

目指す姿 (1段上の目標)

プロセス改善 (プロジェクトレベル)

負のスパイラルから抜け出せない

テコ入れするが、成果が出ない

対策するが的を得ていない

Do 作業標準の遵守

Action 作業標準の改善

標準化 Plan

プロセスの標準化

品質分析・評価による改善アプローチ ①バグの根本原因分析に基づく弱点プロセスの改善 ②工程振り返り分析に基づく無駄プロセスの改善 ③開発要件分析に基づく開発プロセスの改善

開発プロセスの成長

効果的な品質プロセスに改善！

さまざまな品質上の課題

５. 振り返り開発者と開発プロセスの成長は相互作用し品質維持/向上に繋がる


品質マインド、開発スキル、品質分析力の成長(個人)

Check 改善アプローチ（振り返り)

プロセス改善の仕組みが定着

品質分析力が向上

品質マインドが向上

市場フェーズ問題が増え開発を圧迫

ナレッジ化

開発スキルが向上

バグを混入させない/流出させないという意識

プロセス改善 (開発グループレベル)

31


『メッセージ』

検出バグの根本原因追究を契機に自らの過ちを振り返り何故間違ったのか

どうすべきであったのかを振り返ることで成長と発展に繋がる

この作用はどのプロジェクトでも

当てはまること

５. 振り返り

32

プロセス分類診断対象のプロセス診断チェック観点 5段階評価(※1)

改善前改善後


品質指標値の設定品質指標値の設定は、開発要件や開発特性を考慮した見直しを行うプロセスとしている 3

3.5

5

4.9 品質指標値の測定品質指標値の測定基準や測定方法を規定している 4 4 品質評価基準の妥当性妥当な品質評価基準がある 4 5

乖離要因分析と対策品質評価基準に満たないことの要因分析、その要因分析結果に基づく対策は工程内で遂行できている 4 5

②工程移行判定プロセス工程移行判定適切なメンバーにおいて、工程移行判定を行うプロセスとしている

- 規定した品質報告書の書式があり、品質報告書の作成から工程以降判定までの手順がある 3 3 4 4

③PDCA改善サイクルプロセス

予防措置開発開始前に開発要件・開発条件の分析から品質リスクを特定し、予防を実施するプロセスとしている 0

2.3

4

4.7 工程作業の振り返り開発完了時に工程作業を振り返り、次期開発に向けた改善課題の抽出と課題を推進するプロセスとしている 2 5

品質目標達成状況の振り返り開発完了時に品質目標達成状況を振り返り、次期開発へ向けた改善の抽出と課題を推進するプロセスとしている 5 5


定性評価数値による定量評価に加えて、バグ/レビュー/試験の質やバグの問題傾向分析による定性評価を行うプロセスとしている - 品質報告書等にバグ/レビュー/試験の質やバグの問題傾向分析の報告枠がある

2 1.5

5 5

問題傾向に基づく品質強化問題傾向に基づく強化策等により品質担保を行うプロセスとしている - 品質報告書等に問題傾向分析の内容や、問題傾向に基づく強化策の報告枠がある 1 5

⑤根本原因追究による是正プロセス

混入バグの根本原因追究各工程で検出する混入バグの根本原因を追究し、その根本原因に基づく類似調査および再発防止策定を行うプロセスとしている - レビュー報告書、問題管理簿に混入バグの根本原因、類似調査、再発防止の記載枠がある

1

0.7

5

5.0 混入した設計工程で検出できずに次工程以降に流出したバグの根本原因追究

混入した設計工程で検出できずに次工程以降に流出したバグの根本原因を追究し、その根本原因に基づく類似調査および再発防止策定を行うプロセスとしている - レビュー報告書、問題管理簿に上記の流出原因、類似調査、再発防止の記載枠がある

0 5

検出すべき試験工程で検出できずに次工程以降に流出したバグの根本原因追究

検出すべき試験工程で検出できずに次工程以降に流出したバグの根本原因を追究し、その根本原因に基づく類似調査および再発防止策定を行うプロセスとしている - 問題管理簿に上記の流出原因、類似調査、再発防止の記載枠がある

1 5

別紙１品質分析・評価プロセスの診断

※1: 5=適切、4=やや適切、3=どちらともいえない、2=やや不適切、1=不適切、0=プロセスなし


ソフトウェア品質シンポジウム software quality...

Documents