C2C2-4

アジャイルインスペクションの実際欠陥密度と評価判定基準について

ソニー株式会社
奈良先端科学技術大学院大学

永田 敦
森崎 修司
2010年１月28日

ソフトウエアテストシンポジウム

JaSST‘10 Tokyo copyright (c) 永田 敦

目次
インスペクションの課題
アジャイルインスペクションの期待ケーススタディ
結果と効果考察
アジャイルインスペクションが成功する条件

ソフトウエアテストシンポジウム

JaSST‘10 Tokyo copyright (c) 永田 敦

自己紹介

3 ソニー株式会社 永田 敦
 JSTQB Foundation Level 取得 ２００８ JaSST 東京 ソフトウエアテストシンポジウムベストスピーカー賞

訳書
ソフトウェアテストの基礎―ISTQBシラバス準拠
JSTQB用語集付き

ソフトウエアテストシンポジウム

SonyTokyo
Corporation
JaSST‘10copyright (c) 永田 敦

謝辞
今回、JaSST
今回、JaSST‘JaSST‘10 Tokyoで発表させていただくことにつきましては、Tokyoで発表させていただくことにつきましては、さまざまの方にご支援をいただきました。
Agile Inspection を教えていただきました、Tomを教えていただきました、Tom Gilb 様、Kai様、Kai Gilb様
Gilb様
Agile Inspection Pilot をやらせていただいた 皆さま
Agile Inspection Workshopに参加してWorkshopに参加していただいた皆さまに参加していただいた皆さま
Agile Inspection Communityに参加していただいた皆さま
Communityに参加していただいた皆さま
そして、ご意見ご感想をくださった
そして、ご意見ご感想をくださった皆さま、ご意見ご感想をくださった皆さま
この場をお借りして、深くお礼を申し上げます。

ソフトウエアテストシンポジウム

JaSST‘10 Tokyo copyright (c) 永田 敦

インスペクションの課題
インスペクションの課題

形骸化
読み合わせ目的： 承認イベント
修正で品質が向上したことが確認されていない手戻り効果がわかりにくい
ソフトウエアテストシンポジウム

JaSST‘10 Tokyo copyright (c) 永田 敦

Inspection Facts:
to help you make good decisions to do
Software Inspections and Reviews properly

JUSE Tokyo September 2008• Tutorial by Tom Gilb
•Copyright: © Gilb 2008•••

Tom Gilb

Sources: Gilb, Competitive Engineering (2005),

Gilb and Graham, Software Inspection (1993):Japanese Edition

 Tom Gilb : Inspection_for_Managers_JUSE_08”よりkyoritsu-pub.co.jp

ソフトウエアテストシンポジウム

JaSST‘10 Tokyo copyright (c) 永田 敦

アジャイルインスペクションの期待
アジャイルインスペクションの期待作成中のドキュメントの改善を促す
チェックし，書き直してもらうチェッカーの読む時間と負担を軽減するメトリクスでレビュープロセスを管理する

ソフトウエアテストシンポジウム

JaSST‘10 Tokyo copyright (c) 永田 敦

Agile Inspection Policy

AVOID CLEANUP リビューの目的を、欠陥を取り除き修正することとしてはいけないバグゼロの法則
優秀なレビューアーがどんなに頑張っても２割から６割程度しか見つからない

やり直して“元から”ドキュメントの品質を上げてもらう
Engineer Your Review Process : Tom Gilb 2008
ソフトウエアテストシンポジウム

JaSST‘10 Tokyo copyright (c) 永田 敦

Agile Inspection Process
次のフェーズ

EXIT
インスペクション

Agile Inspection
Iteration

ロギングENTRY

サンプリング

No EXIT

書き直し

ソフトウエアテストシンポジウム

JaSST‘10 Tokyo copyright (c) 永田 敦

役割
チェッカー
ルールに従ってドキュメントをインスペクションし，欠陥を検出していく人
ライター
ドキュメントの書き手
Agile Inspection Leader
アジャイルインスペクションにおけるモデレータ

ソフトウエアテストシンポジウム

JaSST‘10 Tokyo copyright (c) 永田 敦

用語 論理ページ(Logical Page)
３００語
 欠陥(Major Defects)
 後工程で重大な障害を生じるリスクがあるもの
 欠陥密度
論理ページあたりの欠陥数

 ユニークな欠陥
複数のチェッカーでダブりを除いた欠陥の数

ソフトウエアテストシンポジウム

JaSST‘10 Tokyo copyright (c) 永田 敦

今までの活動までの活動
 ワークショップ 社内外でのべ ２１４人が受講
 アジャイルインスペクションの概要と効果を体験してもらう

 社内でのコミュニティ活動
 ガイドラインの検討

 社内のパイロット適応
 本日の話題

ソフトウエアテストシンポジウム

JaSST‘10 Tokyo copyright (c) 永田 敦

ケーススタディー：
ケーススタディー：計画
Inspection ID
Display1
Inspection Leader
永田 敦
AuthorXXXXXXX
Date Inspection requested:
Productｘｘｘｘｘ
No.Pages
11Status
Entry Criteria with Apply
Current Entry Status
No Exit
Entry Criteria with Apply
10Unique defects/LPDocuments
ドキュメントイテレーション
1st2nd3rd
ルール

ソフトウェア要求仕様書
時間
人数
1時間
8
1時間
13
1時間
9

ページ数

11ページ
プロファイル
設計，設計内評価
設計，設計内評価，SQA
設計，設計内評価，SQA

サンプリング
2種類
2種類
2種類

イテレーションの内訳

非曖昧性

ガイド

20分

明確性

チェッキング

20分

非矛盾性
設計表現なし
その他

ロギング

20分

ソフトウエアテストシンポジウム

JaSST‘10 Tokyo copyright (c) 永田 敦

ログ
メジャー欠陥の数

設計事項の数（要求仕様の場合）

分析した語数

ページ・行ID

1理由

1. 曖昧, 2.不明確, 3.矛盾, ４.設計, 5.その他

問題の個所
修正提案
ページ・行ID

2

理由

1. 曖昧, 2.不明確, 3.矛盾, ４.設計, 5.その他

問題の個所
修正提案
ページ・行ID3

理由

1. 曖昧, 2.不明確, 3.矛盾, ４.設計, 5.その他

問題の個所
修正提案
ページ・行ID

4

理由

1. 曖昧, 2.不明確, 3.矛盾, ４.設計, 5.その他

問題の個所
修正提案
ソフトウエアテストシンポジウム

JaSST‘10 Tokyo copyright (c) 永田 敦

アジャイルインスペクションの結果例
Inspection Data Summary
Date
2009/9/24
Product Document Reference
Total Page
15PageID

D-01
Inspection Leader 永田 敦
xxxxxx
ソフトウェア要求仕様書
no-comment page
11pageIndividual Checking Results
No.
12
3
4
5
6
7
8300

Checker sample pageabcdefghAAAAB
B
B
B

No. ofwords

checking
time (min)MajorIssues

Major/LP

Checking rate(words/h)

301
301
301
301
301
301
301
301

2020
20
20
20
20
20
20

5
7
10
64
94
7

5.0
7.0
10.0
6.0
4.0
9.0
4.0
7.0

903
903
903
903
903
903
903
903

Defect Average
Max number

6.5
10.0

Estimated Unique Major Defects
Unique Major Defects
偏差

21.8
22.0
1%

Edit time

5hoursAverage of defects
A
7.0
B
6.0
Actual Unique Major
Defects
A24
B
20

ソフトウエアテストシンポジウム

JaSST‘10 Tokyo copyright (c) 永田 敦

欠陥密度の変化「箱の上端×四分位範囲×１．５」の範囲で一番大きいデータ

75%点 (第3四分位点)

中央値 50%点 (第2四分位点)

25%点 (第1四分位点)「箱の下端×四分位範囲×１．５」の範囲で一番小さいデータ

ソフトウエアテストシンポジウム

JaSST‘10 Tokyo copyright (c) 永田 敦

Agile Inspection Calculation
合計
チェッカ
1234
56
788
21.8
33%
66.2
11728
240
92161

52
1
欠陥数 設計事項 時間
5020
7020
10020
6120
4020
9020
4020
7020

平均
トータル

301
2408
語数
301
301
301
301
301
301
301
301

1.0
8.0
Page/LP
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0

6.5
51.8
欠陥密度
5.0
7.0
10.0
6.0
4.0
9.0
4.0
7.0

チェッカの数ユニークな欠陥の密度% effectiveness
論理ページあたりの実際の欠陥数の推定値
ドキュメントのページ数（論理ページ換算）
ドキュメントに含まれるトータルの欠陥の推定値
1/3 actually occur/hit/go-wrong
後工程に漏れた時の欠陥あたりの平均コスト
今回推定した欠陥による遅れの推定値（時間）ソフトウエアテストシンポジウム

JaSST‘10 Tokyo copyright (c) 永田 敦

ユニークな欠陥の密度の推定方法

ユニークな欠陥の密度は，欠陥密度の平均値から推定することができる．

ソフトウエアテストシンポジウム

JaSST‘10 Tokyo copyright (c) 永田 敦

チェッカーのメンバーと欠陥密度との関係

８名

１３名

９名

オリジナルのメンバーでのユニークな欠陥密度の変化

共通メンバー６名

共通のメンバーでのユニークな欠陥密度の変化

ソフトウエアテストシンポジウム

JaSST‘10 Tokyo copyright (c) 永田 敦

チェッカーのメンバーと欠陥密度との関係(2)共通のメンバーにおけるユニークな欠陥密度と欠陥密度の関係

 チェッカーの人選を初めから適切にすること イテレーションではできるだけチェッカーを変えないこと
ソフトウエアテストシンポジウムJaSST‘10 Tokyo copyright (c) 永田 敦

ライターが見直しをした内容

１回目の結果により直された内容

２回目の結果により直された内容

ソフトウエアテストシンポジウム

JaSST‘10 Tokyo copyright (c) 永田 敦

修正しなかった指摘の内容の変化

ソフトウエアテストシンポジウム

JaSST‘10 Tokyo copyright (c) 永田 敦

修正しなかった
修正しなかった指摘
しなかった指摘
 関係者以外の人の指摘
 関係者以外の人
製品ドメインの詳細や背景の深い部分は知らない ライタ：関係者に冗長にならずに的確に伝えたい⇒ある程度の詳細や背景は書かない ドキュメントの目的による

 修正しなかった部分が増えていく 修正が飽和していく → 修正の限界 → 終了条件

欠陥の密度以外にも，ライターのフィードバックが終了条件となると思われる ⇒ 課題

振り返りを行い合意形成をする
ソフトウエアテストシンポジウム

JaSST‘10 Tokyo copyright (c) 永田 敦

どこの範囲どこの範囲まで範囲まで修正まで修正するか修正するか
 指摘されたところ以外も直してくれるか？
 指摘されたところの周辺
全てを見直しているわけではない．

 変更されたところ，追加されたところは，直されている．
欠陥密度は減っている

 ドキュメントが小さいうちから，インスペクションを行うと効果がある

ソフトウエアテストシンポジウム

JaSST‘10 Tokyo copyright (c) 永田 敦

Agile Inspection Policy

REVIEW EARLY リビューは早いうちにできているところからやる。

全部そろうまで待つ
Engineer Your Review Process : Tom Gilb 2008
ソフトウエアテストシンポジウム

JaSST‘10 Tokyo copyright (c) 永田 敦

アジャイルインスペクションが成功
アジャイルインスペクションが成功する
成功する条件する条件チェックする方
チェックする方もされる方もされる方もドキュメントの質ドキュメントの質を上げることを考えている
チームビルディングができている

ソフトウエアテストシンポジウム

JaSST‘10 Tokyo copyright (c) 永田 敦まとめ
 アジャイルインスペクションは，ドキュメントの品質を向上させる効果があります．
 判定基準のカギとなるユニークな欠陥の密度は，検出された欠陥密度の平均値で推定できます チェッカーは途中で変えないようにしましょう アジャイルインスペクションは早いうちにできているところからやりましょう

ソフトウエアテストシンポジウム

JaSST‘10 Tokyo copyright (c) 永田 敦

ソフトウエアテストシンポジウム

JaSST‘10 Tokyo copyright (c) 永田 敦