品質という王道を行こう
2010年 1月 29日
日本電気株式会社
誉田 直美
Page 1© NEC Corporation 2010: Naomi Honda

人と地球にやさしい情報社会をイノベーションで実現する
グローバルリーディングカンパニー

NECグループビジョン2017
Page 2© NEC Corporation 2010: Naomi Honda

目次

1. 品質という王道を行く とは 王道を行く 品質
 ソフトウェアの特徴

2. 事例
 ユニットテスト分析事例
 オフショア開発改善事例
 2つの組織の比較分析
Page 3© NEC Corporation 2010: Naomi Honda

品質という王道を行くとはPage 4© NEC Corporation 2010: Naomi Honda

「王道を行く」▐ 王道＜広辞苑 など＞
 儒家の理想とした政治思想で、古代の王者が履行した仁徳を本とする政道をいう。
• 王道（徳で導く政治） ⇔ 覇道（力で制する政治） 楽な方法。近道。
• 例：学問に王道なし

 正攻法。正道。物事が進んで行くべき正当な道▐ 王道を行く＜誉田＞ 本質を理解した上で、決意を持って狙い達成に向けて行動すること• ソフトウェアの本質を理解し、その理解に基づいて判断する• ×手段、○目的• ×短期、○長期• ×やるべきことを手抜きする ○やるべきことを効率化してすべて実施する• ×いつも新たな気持ちでスタートラインに立つ ○先人の知恵を使う
Page 5© NEC Corporation 2010: Naomi Honda

「品質」とは▐ 「お客様の満足」が最終ゴール▐ ソフトウェアにおける品質確保の鍵 明示的ニーズと暗示的ニーズの両方を考慮する• 本来備わっている特性の集まりが、要求事項を満たす程度<ISO9000>• 指定された特定の条件で利用する場合の、明示的または暗示的なニーズを満たすソフト
ウェア製品の能力<ISO/IEC25000>

 立場によって、ニーズは異なる• 品質は誰かにとっての価値である<Gerald M. Weinberg>

 時間の経過とともに、ニーズは変化する• システムが本稼動するとき、どこまで真のビジネス(ユーザ）ニーズにあっているかということ<James Martin> システムやコンポーネント等の結果の品質だけでなく、プロセスの品質を問う• 機能および性能に関する明示的な要求事項、明確に文書化された開発標準、および職業的に開発が行われた全てのソフトに期待される暗黙の特性に対する適合<Roger S.
Pressman> 広義の品質を管理する• 狭義の品質（製品の品質）⇔広義の品質（仕事の質、サービスの質、工程の質、人の質..）<石川 馨>

Page 6© NEC Corporation 2010: Naomi Honda

理解しておくべき本質：ソフトウェアの特徴▐ 人間的要素がソフトウェアに決定的に影響する
 モチベーション、コミュニケーション、リーダーシップ…

▐ 変換（詳細化）を繰り返して作っていく 行間がある▐ 自由度が高い 素人でも作れる すぐに修正できるように見える▐ 目に見えない 違いがわかりにくい• 例：出来が良い/悪い、進捗が進んでいる/進んでいない…
Page 7© NEC Corporation 2010: Naomi Honda

王道を行く・行かない事例▐ 私はテスト担当者です。私の仕事はテストをしてバグを見つけることなので、バグを見つけて報告しました▐ テストでのバグ摘出目標値を達成したので、テストを終了しました▐ 外部設計をすればプログラムを書けるので、内部設計は省略しました▐ 生産性向上のため、テストケースを一律削減する目標を設定しました。
目標達成に向けて、All-pair法の使用を義務付けました▐ データを取ればすべてが見える化できます。だから、データを収集してつじつまが合わないところを追及します▐ オフショアを使いたいので、オフショアにわかる仕様書の書き方を教えてください。仕様書を渡したらプログラムが返ってくるようにしたいのです。
Page 8© NEC Corporation 2010: Naomi Honda

＜注意＞品質という王道を行く とは▐ 品質のみを追求するという意味ではない▐ 品質を追求すれば、コストも納期も改善する コストを追求すると、品質は改善しない。低下する
 品質を追求すると、後戻りが減少する。これにより、コストや納期が改善する

Page 9© NEC Corporation 2010: Naomi Honda

事例Page 10© NEC Corporation 2010: Naomi Honda

事例

テストの手抜きは、品質に表れる*～ ユニットテスト分析事例 ～Page 11© NEC Corporation 2010: Naomi Honda

ユニットテストを手抜きすると、確実にフィールドバグは増える＜ユニットテスト実施レベルとフィールドバグ発生の関係＞
ユニットテストの実施レベル*
きちんと実施

やや手抜き

手抜き

43％

57％

バグ有り**
バグ無し

91％

9％

73％

27％

*ユニットテストの実施レベル：ユニットテストの実施内容により、プロジェクトを3つに層別**バグ有り：１件以上のフィールドバグが発生したプロジェクトを 1プロジェクトとカウント

Page 12© NEC Corporation 2010: Naomi Honda

プロジェクト数（全体：29)

手抜きして摘出されなかったバグは、出荷後まで残存するユニットテストの実施レベル
きちんと実施＜ユニットテスト実施レベルと残存するフィールドバグ＞
UTで摘出すべきバグ
UT以降で摘出すべきバグ

流用部分に潜在していたバグであり、ユニットテスト方法の改善が必要

やや手抜き

手抜き

ユニットテストをきちんと実施すれば出荷前に摘出可能なバグ（2件除く）は、全バグの62％を占める
Page 13© NEC Corporation 2010: Naomi Honda

バグ数

事例
品質を追求しよう！
生産性は後からついてくる*～ オフショア開発改善事例 ～*出典：日本電気 SWQC（Software quality control) 理念
Page 14© NEC Corporation 2010: Naomi Honda参考：日本企業におけるオフショア開発の主要課題
63.8％
46.8％
25.5％
14.9％
17.0％
17.0％

出典：経済産業省 2009年版組込みソフトウェア産業実態調査

Page 15© NEC Corporation 2010: Naomi Honda

オフショア開発改善事例
概要■目標：海外子会社が日本国内並の品質/生産性のSW会社となる■期間：約2年■特徴：海外と日本が一体となったWin-Winの改善プロジェクト
・品質・日本語力※各々具体的な数値目標■数値目標
・生産性・コスト削減率

推進の経緯

スタート

③設計・マネジメント力の修得①枠組み作り②基礎開発技術の修得

日本語力向上Page 16値を設定© NEC Corporation 2010: Naomi Honda

完了：経営視点でのチェック④組織力の強化

施策：日本の開発プロセスの徹底 と 地道な改善活動の定着
スタート

完了

①プロセス構築②基礎開発作法・ノウハウの徹底＜開始時の状況＞
・いつまでもバグが枯れない
・コミュニケーションがとれない・変更した仕様が反映されない…

ステップ１：共同開発
日本指導のもとであれば問題なく開発可能③設計力④マネジメント力⑤保守力

ステップ３：自立開発

ステップ２：準自立開発
開発工程の一部（機能設計～機能ﾃｽﾄ）を自主管理可能

国内同等
レベル！

国内子会社と同等の開発力を持ち、製品担当として主体的に開発

仕組み見直し計画◆目標/実績の差異分析◆アセスメントによる弱点抽出と改善◆プロジェクト別
改善計画◆Face to Faceの反省会◆施策実施◆教育の充実PDCAサイクル①プロジェクト毎のPDCAサイクル
評価実施②出荷後バグによる改善③失敗プロジェクトのフィードバック
Page 17© NEC Corporation 2010: Naomi Honda

成果
＜品質＞

良 9

品質3倍改善STバグFTバグ

876良706050＜日本語＞
日本語3 級以上
日本語力3倍改善

40

5430

3220

1100開始時

良2002°下62003°上2003°下＜生産性＞

2004°上良

生産性３倍改善540目標

4540開始時

2002°下 2003°上 2003°下 2004°上 最終目標

開始時

2002°下 2003°上 2003°下 2004°上＜コスト削減率＞
コスト削減率
14％改善

35
330
225

1200開始時

2 0 0 2 °下■改善前

2 0 0 3 °上

2 0 0 3 °下

2 0 0 4 °上目標

最終目標

＜海外子会社 管理職の変化＞ ■改善後

「こんなに上工程で品質見直しばかりしていてはA課長：
生産性があがりません。意味ないです。」「品質を上げるには上工程でしっかり見直しするのがポイントです。そうすれば生産性も上がります。本当ですよ。」

B部長：「目標値がたくさんあって、どうすればいいのかわかりません。」「改善のしかたがわかりました。目標を設定し分析と施策実施を繰り返していけばいいのです。
これで自分達でも改善が進められます。」

Page 18© NEC Corporation 2010: Naomi Honda

事例「データ」は現場を補足するために使う～

Page 19

2つの組織の比較分析 ～© NEC Corporation 2010: Naomi Honda2つの組織の特徴<組織Aと 組織B >•開発条件がよく似ている•ビジネス領域, ビジネス規模•開発規模, 開発者数

•ソフトウェアプロセス, 開発技術・管理技術※どちらもＣＭＭＩレベル5をほぼ同時期に達成

Page 20© NEC Corporation 2010: Naomi Honda

開発プロセス
製品

BD:基本設計工程
BDD：基本設計

システムテスト項目

ＳＴ：システムテスト工程

BDR：基本設計レビュー
基本設計仕様書

FD:機能設計工程
FDD：機能設計

コード一式

ＦＴ：機能テスト工程

機能テスト項目

FDR：機能設計レビュー
機能設計仕様書＜上工程＞

DD:詳細設計工程
DDD：詳細設計単体テスト項目

コード一式

ＵＴ：単体テスト工程＜テスト工程＞DDR：詳細設計レビュー
詳細設計
仕様書

コード一式

CD:コーディング工程
CDC：コーディング
CDI：ｺｰﾄﾞｲﾝｽﾍﾟｸｼｮﾝ

Page 21© NEC Corporation 2010: Naomi Honda

BD: Basic Design
FD: Function Design
DD: Detail Design
CD: CoDing
UT: Unit Test
FT: Function Test
ST: System Test

どちらの組織のほうが品質が良いか？
注意: すべての数値は、組織Ａの平均値を１００とした相対値

No. データ項目
123
4
5
6789単位

全工数
設計・製造工数
レビュー工数
テスト工数
全バグ数
レビュー摘出バグ数
テスト摘出バグ数
上工程バグ摘出率
テスト項目数

人Ｈ/ＫＬ
人Ｈ/ＫＬ
人Ｈ/ＫＬ
人Ｈ/ＫＬ
件数/ＫＬ件数/ＫＬ
件数/ＫＬ％
項目数/ＫＬ

組織Ａ平均
100.00100.00100.00100.00100.00100.00100.00100.00100.00

組織Ｂ
平均
64.46
106.25
47.56
47.43
80.92
82.46
81.92
98.94
52.77

＜上記から観察されること＞•Ｂは、Ａより設計・製造工数はやや多いがレビュー・テスト工数は半分くらいである。（Ｎｏ.1～4より）•Ｂの（出荷までの）バグ件数/ＫＬは、Ａの80％である（Ｎｏ.5～7より）•全バグ数に対する上工程（設計～コーディング）までのバグ摘出率は、ＡとＢはほぼ同じである•Ｂのテスト項目数は、Ａの約半分である

Page 22© NEC Corporation 2010: Naomi Honda

「データ」でできること・できないこと▐ データのみでは、良いか悪いか判断できない
 組織Ｂは、プロセスを改善すれば工数やバグ数は減るはず、と解釈していた▐ 現場で実際に起きていることを把握したうえでデータを使うべきである
 開発途中で発生した問題とその解決状況
 コミュニケーション
 メンバのスキルレベルと職務割り当ての適切性 リーダーシップ
 お客様との調整状況 などなど

データは「現場」を補足するために使う
Page 23© NEC Corporation 2010: Naomi Honda

事例

同じプロセスでも、結果は異なる～

Page 24

2つの組織の比較分析 ～© NEC Corporation 2010: Naomi Honda

分析方法 1

悪い

品質

品質

良い良い
Page 25

レビュー工数© NEC Corporation 2010: Naomi Honda

分析方法 2

品質

レビュー工数良いPage 26

少ない

多い

レビュー
不充分

レビュー
充分

レビュー工数© NEC Corporation 2010: Naomi Honda

分析方法 3

品質

品質が悪い

Ⅰ Ⅳ
レビュー
不充分

レビュー
充分

Ⅱ Ⅲ
品質が良い
良い
Page 27

レビュー工数© NEC Corporation 2010: Naomi Honda

レビュー工数 vs. 品質
注意: すべての数値は、組織Ａの平均値を１００とした相対値（以降、同じ）

800

品質A600

品質B

400

200

良い0050

100

150

レビュー工数

レビュー工数
Page 28© NEC Corporation 2010: Naomi Honda200

レビュー工数 vs. 品質
800

B

品質

回帰直線600

AB

品
質400

A
回帰直線200

良い0050100150

レビュー工数

レビュー工数
Page 29© NEC Corporation 2010: Naomi Honda200

比較 1-1

品質品
質

800

800

800

600

600

600

品
質

400

400

品
質

200

200

200

00050

良い100150

レビュー工数

レビュー工数

200

400

050

100

150

テスト工数

200 00100

200300

テスト項目数

テスト工数

テスト項目ABPage 30© NEC Corporation 2010: Naomi Honda

比較 1-2

品質
800

800

800

BB
600

600

品
質品
質400

B600

400

品
質400

A200

200

200

A

A00050良い100150

200050100

150

テスト工数

レビュー工数

レビュー工数

テスト工数

20000100200300

テスト項目数

テスト項目
AB

Page 31© NEC Corporation 2010: Naomi Honda

比較 2-1
差し替え
品質

品
質

800

800

800

600

600

600

品
質

400

400

品
質

200

200

200

00050

良い100150

レビュー工数

レビュー工数

200

400

050

100150

テスト工数

200 0050

100

150

200

設計・コーディング工数

テスト工数

設計・製造工数
AB

Page 32© NEC Corporation 2010: Naomi Honda

比較 2-2

品質
800

B

B

600

品
質

800

800

600

600

400

品
質品
質

400

B

400

A
200

200

00050

良い100

150

レビュー工数

レビュー工数200

200

AA0050

100

150

テスト工数

テスト工数

200050

100

150

200

設計・コーディング工数

設計・製造工数AB

Page 33© NEC Corporation 2010: Naomi Hondaなぜ、同じプロセスでも結果が異なるか▐ 基準値遵守の考え方の違い
 基準値の設定そのものは必須である
 「基準値遵守」は、逆に弊害（公認の言い訳）にもなりうる⇒「形骸化」への早道▐ 現場による主体的な判断を重視する
 状況をきちんと分析してそのソフトウェアに適した施策（基準値）を考えて実施する
 「言われたとおり」ではなく、現場が自分の問題として「本気」で考える

Page 34© NEC Corporation 2010: Naomi Honda

事例同じ手法を適用しても、成果は違う～

Page 35

2つの組織の比較分析 ～© NEC Corporation 2010: Naomi Honda

事例：1+n 施策- 出荷製品の予防保守活動 -<目的>▐ フィールドバグと同一原因の残存バグを出荷製品から摘出すること同種バグ
フィールドバグと同一原因の残存バグ

Page 36© NEC Corporation 2010: Naomi Honda

1+n 施策とは- 出荷製品の予防保守活動 出荷製品“Z”
フィールドバグ

1同一原因で作りこみ・残存同種バグn

追加テスト・レビュー(バグの真の原因分析に基づく)

バグの真の原因分析

なぜ、そのフィールドバグ を作りこんだか？
なぜ、そのフィールドバグ はレビューで摘出できなかったか？
なぜ、そのフィールドバグ はテストで摘出できなかったか？
Page 37© NEC Corporation 2010: Naomi Honda

1+n 施策とは- 出荷製品の予防保守活動 出荷製品“Z”
フィールドバグ

1

同種バグ

同一原因で作りこみ・残存nn ≧ 1 のとき

追加テスト・レビュー
成功(バグの真の原因分析)

n = 0 のとき

バグの真の原因分析

失敗
なぜ、そのフィールドバグ を作りこんだか？
なぜ、そのフィールドバグ はレビューで摘出できなかったか？
なぜ、そのフィールドバグ はテストで摘出できなかったか？

Page 38© NEC Corporation 2010: Naomi Honda

1+n 施策成功率<算出式>
1+n 施策成功率
成功した “1+n 施策” 実施件数=
全 “1+n 施策” 実施件数
注意:n ≧ 1 : 成功
n=0

Page 39© NEC Corporation 2010: Naomi Honda

: 失敗

Case
事例 study
フィールドバグ▐ ある入力フィールドへ範囲外の値を入力したところ、プログラムが異常終了

追加テスト・レビュー▐ 他の入力フィールドに対して、範囲外の値のテストをする充分か?
Page 40© NEC Corporation 2010: Naomi Honda

Case study バグの真の原因分析 (1)フィールドバグ▐ ある入力フィールドへ範囲外の値を入力したところ、プログラムが異常終了
1 なぜ このフィールドバグは発生したか?

▐ 割る数が０のときのエラー処理実装漏れ2 なぜ その実装漏れがおこったか？

▐ その担当開発者は、割る数が０のケースがあることを知らなかったため
Page 41© NEC Corporation 2010: Naomi Honda

Case study

3

バグの真の原因分析 (2)

なぜ その開発者は割る数が０のケースが発生することを知らなかったのか?
▐ その開発者は、開発途中に急に交代した交代要員だったため
 旧開発者は、詳細設計書へ割る数が０のケースについての仕様を記載していなかった。（通常、設計と実装は同一開発者が担当するので、細かい仕様は記載していなかった）
 現開発者は、設計仕様書に基づいて実装した。
 真の原因は、“書かれざる仕様”
 このプログラムは、旧開発者によりレビューされなかったため、“書かれざる仕様”の未実装は発見できなかった。
 誰も“書かれざる仕様”を知らないので、テストもしなかった
Page 42© NEC Corporation 2010: Naomi Honda

Case study 1+n 施策

フィールドバグ▐ ある入力フィールドへ範囲外の値を入力したところ、プログラムが異常終了
追加テスト・レビュー▐ 現開発者が実装したすべてのプログラムを、旧開発者がレビューする
他に“書かれざる仕様”の未実装がないかを確認する▐ 以下の観点からのテスト
レビューにより摘出された 全“書かれざる仕様 ”
すべての入力フィールドへの範囲外の値指定
Page 43© NEC Corporation 2010: Naomi Honda

1+n 施策成功率 vs. 品質X軸:同種欠陥の摘出率 Y軸:品質A

800

B
n=11r=-0.651

品質n=8r=0.000

AB

600

400

200

良い00100

2003000

良い1+n 施策成功率
Page 44© NEC Corporation 2010: Naomi Honda

100200300

良いAB1+n 施策成功率 vs. 品質X軸:同種欠陥の摘出率 Y軸:品質A

800

B
n=11r=-0.651

品質n=8r=0.000

A

B600

400200良い00100

2003000

良い1+n 施策成功率

100200300

良いAB

Page 45© NEC Corporation 2010: Naomi Honda

考察①“バグの真の原因分析” の能力は組織の改善に大きな影響を及ぼす★バグの真の原因分析能力＝問題の真の原因を分析する能力
ＰＤＣＡサイクルを効果的に回すためには、真の原因分析能力が必須である。
Page 46© NEC Corporation 2010: Naomi Honda

考察②▐ なぜ、組織Ｂでは「なぜなぜ分析と1+ｎ施策」が品質向上に効果がないのか？
ルールだから実施している▐ なぜ、組織Ａでは効果があるのか？
成果がなければ実施しても意味がないと思って取り組んでいる

この違いは何を意味するのか？

Page 47© NEC Corporation 2010: Naomi Honda

事例

品質中心の組織文化は大きな成果を生み出す～Page 48

2つの組織の比較分析© NEC Corporation 2010: Naomi Honda～

疑問

なぜ、組織Ａと組織Ｂは、このように大きな差異が生じたのか？

Page 49© NEC Corporation 2010: Naomi Honda

考察
品質を最優先に位置づける
組織の雰囲気、価値観や考え方“QCC” 品質中心の組織文化(Quality-Centric software engineering Culture)

品質中心の組織文化は高品質を継続的に維持向上するための基盤を提供する
Page 50© NEC Corporation 2010: Naomi Honda

ＱＣＣ（品質中心の組織文化）とは丸投げ文化
ルールの考え方ルールだから実施する判断基準 組織基準値に従って判断する
仕事への 決められた通りに取り組み 仕事を進める
価値観
ＱＣＤのうち、場面によって優先順位が変わる
Page 51

ＱＣＣ（品質中心の組織文化）
目的を理解したうえでルールを使おうとする
自ら最終目的を想定して判断する
常に仕事のしかたを改善しようとする
常にＱ中心である対極© NEC Corporation 2010: Naomi Honda

どうすればＱＣＣ（品質中心の組織文化）を構築できるか▐ トップの指導
 ぶれないＱ優先の価値観• 「1に品質、2に品質、3,4がなくて、5に品質」▐ 「現場」の共有
 本当の現場はどこで、現場で何が起きていて、何が本当の問題かをトップからボトムまで全員が把握する▐ 何のためのプロセスかを常に考える土壌作り プロセス改善の目的を明確にし、組織全員が共有する▐ 主体的な考え方：ルールを単なるルールにしない やらせるだけのスタッフは退場
 自らの言葉で問題を説明できないリーダーも退場 技術者が工夫できる自由度を確保

Page 52© NEC Corporation 2010: Naomi Honda

まとめ▐ 品質という王道を行く とは本質を理解し、決意を持って、狙いを達成すべく、品質改善の正攻法に則って行動すること▐ 品質という王道を行こう
本質を理解すれば迷わない品質という王道は、すべてに大きな成果をもたらす
形だけまねても同じ成果は得られない達成する決意が、行動の差を生む▐ 目線をあげて進もう最終ゴールは「お客様の満足」
Page 53© NEC Corporation 2010: Naomi Honda