1. リアルタイム波形を用いた
Writing by Nakajima PS-Team
設計品質分析手法と
総合分析環境提案
SQiP 2011.9.9
ＮＴＴデータＭＳＥ
ＮＴＴデータＭＳＥ
データ
モバイルソリューション事業部
モバイルソリューション事業部
中島 憲一郎
http://www.flickr.com/photos/cmlburnett/4994716354/
Copyright (C) Nakajima NTT DATA MSE Corporation

2. 自己紹介
• 株式会社 ＮＴＴデータＭＳＥ
• 携帯端末の無線伝送系開発を約10年
• プロジェクトリーダ
社 名 株式会社NTTデータMSE （英文名：NTT DATA MSE CORPORATION）
株主構成 株式会社NTTデータ60％
パナソニックモバイルコミュニケーションズ株式会社40％
事業内容 （1）クラウドソリューション事業
（2）モバイルソリューション事業
（3）基盤ソリューション事業
（4）ソリューションサービス事業
2

3. 目次
• 背景
• 課題1 設計の品質分析判断が難しい
• 提案 設計品質分析手法改善
• 課題2 分析のための負荷
• 対策 プロセスに沿った分析環境構築
• 導入効果
• まとめ
3

4. バグは上流で発見したい
$1000+
$100
Cost to Fix A Bug
$10
$1
Specification Design Code Test Release
Time When Bug is Found
参考：Lessons Learned in Software Testing (by Cem Kaner, James Bach and Bret Pettichord, Dec 15, 2001) 4

5. 品質管理体制を強化
専任の品質管理
担当者を設置
PL
分析結果報告 QA
改善要望
SL
SL SL 毎週メトリクスデータ
SL 集計報告
SL
SL
5

6. メトリクスデータ情報
SL
6

7. データ分析
データ分析
レビュー欠陥検出率 レビュー工数率 ゾーン分析
QA
7

8. 課題１
8

9. 分析結果に対する深堀が進まない
詳細設計工程分のメトリ
詳細設計工程分のメトリ
クス集計が完了しました
クス集計が完了しました
QA
サブシステムXの指摘
サブシステムXの指摘
密度が高いけど？
密度が高いけど？
PL
難易度が高かった。レ
難易度が高かった。レ
ビューを十分実施した結果
ビューを十分実施した結果
SL
9

10. 実際に、レビューに問題が
なかった詳細に確認するに
QA
は、現場担当者の協力が
必要
フィードバックが薄い
メトリクスデータ報告に対
SL
するモチベーション低下
10

11. 工程完了時点の品質分析確認では遅い
短納期化
FD:機能設計 コンカレント開発
DD:詳細設計
複数イテレーション
M:コーディング
UT:単体テスト
次の工程に
次の工程に
着工している
IT:結合テスト
着工している
品質分析判断 time
11

12. ベースの設計が重要と認識していて
も、コストや納期の制約から、
「設計を見直す」判断は難しい
FD:機能設計 見直し可能とするため、
見直し可能とするため、
工程途中で都度分析、
工程途中で都度分析、
DD:詳細設計 検査・点検をしていく
検査・点検をしていく
M:コーディング
UT:単体テスト
工程途中における分析判断の精度を
向上させる IT:結合テスト
time
12

13. 推移状況を確認していく
正規化した最終デー
正規化した最終デー
タは指摘の多い時・
タは指摘の多い時・
少ない時含め平均化
少ない時含め平均化
されている。
されている。
time
13

14. 多角的観点
別
重要
要因
度別
ｰｱ別
ﾚﾋﾞｭ
機能
別
観点 ﾚﾋﾞｭ
ｰｲ別
程別
ﾚﾋﾞ
入工
量
混
実施
ｭｰ工
ｭｰ
数
ﾚﾋﾞ
14

15. 分析の粒度をより細かくすると，
データ確認量が増える
リアルタイムな品質状況のトレース
が負荷になってくる
実用面で継続性や確認精度が低下
15

16. 心電図
地震予知
兆候を
兆候を
掴む
16

17. リアルタイム
リアルタイム見える化
見える化
える化
17

18. ヒストグラム
ヒストグラム→面グラフ
面グラフ
18

19. 施策
波形で
波形で診断
見える化
える化 19
http://www.flickr.com/photos/aldoaldoz/1438838260/

20. Ｒ Ｒ
Ｔ Ｔ サブシステム別
波 波
形 形 重要度別
分 分
析 析 レビューア別
手 手
法 法
レビューイ別
要因別
20

21. 3つのグラフを活用
時系列で見る
実績で見る 割合で見る
21

22. レ
ビ
レビュー状況 重要度別
ュ
ー 標準モデル（想定）
状
況 怪しい？
22

23. レ
ビ
レビュー状況 重要度別 重要度大の問
重要度大の問
題は少ない
題は少ない
ュ
ー
状
況
23

24. レ
ビ
レビュー状況 問題要因別 毎回、考慮漏れと
毎回、考慮漏れと
非バグ指摘が多い
非バグ指摘が多い
ュ
ー
状
況
24

25. レ
ビ
レビュー状況 混入工程別 前工程のバグは検
前工程のバグは検
出できていない
出できていない
ュ
ー
状
況
25

26. レ
ビ
レビュー状況 サブシステム別
ュ
ー
サブシステムのレビュー
サブシステムのレビュー
指摘数は適切か？
指摘数は適切か？
状
況
ブシステム 26

27. レ
ビ
レビュー状況 レビューア別
ュ
ー
状
況
前半と後半でレビューで活躍している
メンバーが変わった？
→病欠？
ューア 27

28. レ
ビ
レビュー状況 レビューイ別
ュ
ー
状
況
ューイ 28

29. レ
レビュー工数
ビ
ュ レビュー工数に
レビュー工数に
ー 偏りあり
偏りあり
工
数
山が続いている
→休出しているチームがある
ュー 29

30. レ
レビュー枚数
ビ
ュ サブシステムＸに
サブシステムＸに
ー 関してレビュー枚
関してレビュー枚
数に偏りあり
数に偏りあり
枚
数
ュー 30

31. レビュー状況 重ねてみる
レビュー 31

32. 多面的に
重ねてみる
32

33. レビュー状況
レビュー 33

34. • 計画値との差異ベースでなく、周囲との
相対的見地から分析判断し、即見直し
をしていくアプローチとした。
• 波形の形と色の偏りに着目することで、
細かな変化に気付くことが可能になった。
• 波形と構成成分を併せて確認すること
で、異常兆候に関してすぐに詳細分析
が可能となった。
34

35. 課題２
施策に対する課題
35

36. 品質分析のために負荷
がかかっている
• メトリクスデータの集計と報
告作業
SL • ＱＡ担当者からのヒアリング
対応作業
• 分析結果指標に対する詳
細分析、回答作成作業
36

37. 策
中で
中で
プロ スを え
を
る情報
情報を
ㅻ る情報を
る を る
ソフトウェア開発の鉄則201 原理147 押し付けがましいデータの集め方をするな
37

38. リアルタイムフィードバックシステム
リアルタイム
ヷ ヷ
フ ードバック
システム
で
を 施
38

39. レビュー記録票
・指摘数 テスト成績書
・指摘数 バグ票
・指摘分類
・指摘分類
設計書
設計書 ・工数
・工数 ・試験項目
進捗報告書 ・ﾚﾋﾞｭ枚数 ・試験項目 ・バグ要因
・ﾚﾋﾞｭ枚数 ・試験種別 ・バグ要因
・試験種別 ・原因工程
・ランク ・原因工程
・ランク ・重要度
・実施日 ・重要度
・作業計画 ・実施日 ・発生日
・作業計画 ・発生日
・作業見通
・作業見通
・見通し
・見通し ソース
・実績規模 ソース
・実績規模
サーバー上
プロ 開発者は計画書で決めた場所
セス に計画書で決めたフォーマット
で成果物を置いていくor決め
た管理ツールで作業するだけ。
39

40. レビュー記録票
・指摘数 テスト成績書
・指摘数 バグ票
・指摘分類
・指摘分類
設計書
設計書 ・工数
・工数 ・試験項目
進捗報告書 ・ﾚﾋﾞｭ枚数 ・試験項目 ・バグ要因
・ﾚﾋﾞｭ枚数 ・試験種別 ・バグ要因
etc ・試験種別 ・原因工程
etc ・ランク ・原因工程
・ランク ・重要度
・実施日 ・重要度
・作業計画 ・実施日 ・発生日
・作業計画 ・発生日
・作業見通
・作業見通
・見通し
・見通し ソース
・実績規模 ソース
・実績規模
etc
etc
夜間定刻で自動集計・分析
設計規模推移状況
設計規模
設計規模
自動 Quality Analysis
分析
Page
Page
まとめ
まとめ
ソース規模推移状況 試験バグ検出状況
ソース規模 バグ
ソース規模 バグ
Step レビュー指摘状況 テスト実施状況 件数
件数
Step
ﾚﾋﾞｭ指摘 テスト実績
ﾚﾋﾞｭ指摘 テスト実績
件数
件数 件数
件数
40

41. 設計規模推移状況
設計規模 全体レポート
設計規模
Page まとめ
Page テストバグ検出状況 まとめ
ソース規模推移状況 バグ
バグ
件数
ソース規模 件数
ソース規模
Step
Step レビュー指摘状況 テスト実施状況
ﾚﾋﾞｭ指摘 テスト実績
ﾚﾋﾞｭ指摘 テスト実績
件数 件数
件数 件数
サーバー上
結果データをプロジェクトメンバ
全員に毎日リアルタイムに
見え
フィードバックする。
る化
プロジェクトメンバ全員がリアル
タイムに品質状況を確認。
41

42. Ｒ Ｒ
Ｔ Ｔ
品
質 分
分 析
析 Ｆ
Ｆ Ｂ
Ｂ Ｓ
Ｓ
42

43. 対象 記録表 成果物 報告書
工程 レビュー バグ票 設計書 ソース テスト仕 進捗報
記録票 コード 様書 告書
要件定義
○
機能設計
○ ○ ○
詳細設計
○ ○ ○
コーディン
グ ○ ○ ○ × ○
単体試験
○ ○ ○ ○
結合試験
○ ○ ○ ○
システムテ
スト
受け入れ
テスト
43

44. テスト 施 44

45. テ
テスト実施状況 優先度別
ス
ト
実 試験がなかな
試験がなかな
施 か進まない
か進まない
状
況
45

46. テ
ス
テスト実施状況 作成種類別
ト
実
施
状 ㆺ
況
46

47. テ
ス
テスト実施状況 サブシステム別
ト
実
施
状 ブシステム
況
47

48. テ
ス
テスト実施状況 サブ機能別
ト
実
施
状 ブ
況
48

49. テ
ス
テスト実施状況 実施者別
ト
実
施
状 施
況
49

50. テストバグ状況
テストバグ 50

51. バ
グ
バグ発生状況 問題要因別
発
生
状
況
51

52. バ
グ
バグ発生状況 機能別
発
生 サブシステムEの
サブシステムEの
バグが続いている
状
バグが続いている
況
52

53. テ
ス
バグ発生状況 緊急度別
ト
バ 緊急度の高い
緊急度の高い
バグが発生
バグが発生
グ
状
況
53

54. バ
グ
バグ発生状況 重要度別
発
生 重要度の高い
重要度の高い
バグ発生
バグ発生
状
況
54

55. バ
グ
バグ発生状況 混入工程別
発
生
状
況
55

56. バ
グ
バグ発生状況 担当別
発
生
状
況
56

57. バ
グ
バグ発生状況 処置者別
発
生
状
況
57

58. バ
グ
バグ発生状況 発見者別
発
生
状
況 見
58

59. 設
設計書枚数推移
計
書
枚
数
推
移
59

60. リ
リリース状況
リ
ー
ス バグ改修が多い
バグ改修が多い
状
況
バグ改修が多い
バグ改修が多い
60

61. 集計のための追加の負荷はなし
メンバ
集計・報告作業→０ｈ
SL 従来プロセスの履行のみ
集計・分析作業→０ｈ
QA ツール作成作業→１人月
プロセス履行状況の確認
PL
61

62. 重要度別
多次元的
観点
要因別
ｲﾃﾚｰｼｮﾝ3
ｲﾃﾚｰｼｮﾝ2
仕様R 機能設計R 機能別 詳細設計R
ｲﾃﾚｰｼｮﾝ1
混入工程別
ション
レー ﾚﾋﾞｭｰｱ別 工程
イ テ
ﾚﾋﾞｭｰｲ別
62

63. 分析事例１
FDレビューとDDレビューが輻輳している状態
ＦＤレビュー工数状況
やり直し？
やり直し？
ＤＤレビュー工数状況
レビューのピーク状況を合わせてみることで、
変調が見て取れる 63

64. 分析事例２
異常系試験ではあま
異常系試験ではあま 単体テスト実施状況
りバグが出ていない
りバグが出ていない
単体テストバグ検出状況
試験の終了判断、妥当性判断の補完
64

65. 導入効果
65

66. 欠陥除去率向上
99%
95%
■適用グループ 85%
■非適用グループ
65%
66

67. バグ発生率（件/KLOC）
流出バグ低減
1
13
67

68. 市場バグ
リリース後約6ヶ月(2011/8/31時点)
件
顧客満足度向上
顧客満足度調査結果
68

69. 開発者の品質意識向上
プロジェクトふりかえりKPT分析結果
プロセス フィードバック
集計
分析
プロセス品質・品質データ向上
69

70. まとめ
70

71. 上流工程の品質分析で早
期に設計見直し判断を可
能としたい。
品質分析に工数をかけず、
分析の迅速化を図りたい。
71

72. Ｒ Ｒ
Ｔ Ｔ サブシステム別
波
形 波
分 形 重要度別
析 分 レビューア別
手 析
法 手 レビューイ別
法 要因別
72

73. Ｒ Ｒ
Ｔ Ｔ
品
質 分
分 析
析 Ｆ
Ｆ Ｂ
Ｂ Ｓ
Ｓ
73

74. 今後の展開・課題
74

75. 今後の展開・課題
リアルタイム波形データのＤＢ化
• プロジェクト特有傾向の形式知化
• 費用対効果について検証
75

76. nakajima.kenichiro@nttd-mse.com
@imaichiro
76