NDS43の発表資料です。

1. ◆攻めの品質、守りの品質◆
平成27年7月25日 in NDS
@2G_KSK

2. 4月のNDSの発表より…
やってみました！
＠自社

3. 受講者アンケートより
歯ごたえなし
記名式アンケートが
悪かった？

4. 受講者アンケートより
[品質]についてのコメントがなかった
→[作業内容]や[納期]に比べ、理解が難し
かったと思われる

5. 「品質」をもう一度考えてみる
PMBOK的品質は…
【特性（機能）の集まりにより、要
求事項を満たす度合、要求事項への
適合、使用適合性】
ユーザの要望を満たす＝品質が良い
ということらしい

6. 「品質の良い服」とは？
手触りがよい
洗っても傷みにくい
サイズがぴったり
→やわらかくて肌触りの
よい服を望んでいる
→ひと夏着れることを望んでいる
→表示通りのサイズであることを
望んでいる

7. 品質は、要求や使用目的がスター
トである
ユーザの要求の内容によって、「品
質」が決まる
伸縮性はないけど、
ロゴや背番号の加工が
しっかりしているので、
満足。

8. システム開発における品質
真っ先に浮かぶのが「バグ」
バグがいっぱい出ると、「品質が悪
い」と判断される
バグにより、本来満たされるべきで
あった機能（要求）が阻害されるた
め、「品質が悪い」となる

9. 品質対策…
目標と比べて、バグの数が多いか少
ないかをチェックする
バグの数が目標より多い場合、品質
が悪いと判断し、再点検を行う
ぴったりくらいだと、十分な品質が
確保されているといえる
△

10. なぜ噛みついたのか？
上述の対策は、出来上がったものに
対する対策である
→リアクティブな対策
プロアクティブな対策
→【攻めの品質】を紹介したい

11. なぜ、プロアクティブな対策が
必要か？
品質は、ものづくりのときに決まっ
てしまうから
あとのフェーズは、品質を保証する
というスタンス
意図的に、品質を操作することがで
きるのはものづくりのフェーズだけ

12. どこで不具合を作っている？
自動車の組み立てを考える
車両の設計
→部品の設計
→部品の作成
→車両の組み立て
→組み立てチェック
→動作テスト
→走行テスト
→納品
設計・製造
（ものづくりの
フェーズ）
その後の確認・テス
トでは不具合は作り
こんでいない
※新入社員向け研修より、抜粋

13. システム開発でも…
基本設計
概要設計
詳細設計
製造
単体テスト
結合テスト
総合テスト
設計・製造フェーズ テストフェーズ
不具合を作るのは、
ものづくりの
フェーズ
不具合を摘出し、
品質に問題ないことを
保証するフェーズ
※新入社員向け研修より、抜粋

14. 攻めの品質：まずは弱点を知る
ものづくり時に不具合を作りそうな
箇所を考える
チーム開発の弱点→つなぎ目
多くの人が携わるため、ほころびが
生じやすい
具体的には：
フェーズ間、設計書間、機能間、…

15. チーム開発の弱点
(1)フェーズ間の情報欠落
基本設計で検討していた仕様が、
詳細設計で担当者が変わったため、
それが盛り込まれなかった
基本 詳細

16. 弱点の対策
(1)フェーズ間の情報欠落
 基本設計で検討していた仕様が、
詳細設計で担当者が変わったため、それが盛り
込まれなかった
調査した結果など、有用な資料があ
るのであれば、それを次工程のイン
プットにする！
テキストファイルでも、手書きのメ
モでも何でもよいので、残す・受け
渡すことを意識する！

17. チーム開発の弱点
(2)設計書間の記述差異
一緒に直さないといけない設計書
が、片方しか直っていない
DB
10桁
FILE
8桁
直した！ 直し忘れている…

18. 弱点の対策
(2)設計書間の記述差異
 一緒に直さないといけない設計書が、片方しか
直っていない
お決まりのパターンを洗い出し、
チェックリスト化する！
チェックの仕組みを構築する！
ものづくり時に間違えないよう、事
前教育する！

19. 弱点の対策
(2)設計書間の記述差異
例えば…
帳票に項目追加したら、ファイルに
も必ず項目が追加されていること
→必ず両方直っていること
DBの項目長より、intで受けるか
longで受けるかを決定する
→安易にintとしない、必ずチェック
する

20. チーム開発の弱点
(3)機能間の不整合
仕様変更が設計者間で伝わっておら
ず、不整合が発生
処理１ 処理２
ファ
イル
項目（A、B、C） 項目（A、B、C）項目（A、D、C）
処理２
項目（A、B、C）
出力内容を変更 項目を誤って読み込み、
処理が不正になる

21. 弱点の対策
(3)機能間の不整合
 仕様変更が設計者間で伝わっておらず、不整合
が発生
だまって仕様変更しない！リーダは
変更内容を把握し、必要な担当者に
伝える！
こういった問題が起こらないよう、
担当者間のコミュニケーションを推
進する！

22. 攻めの品質とは？
以上の対策は、ものづくり前：計画
段階に実施できる
事前教育・コミュニケーション
これらをメンバ全員が理解し、不具
合を作りこまないようにする
計画段階で、品質を上げる策を打つ
ことを、【攻めの品質】と呼ぶこと
としました

23. （参考）PMBOKガイドの言葉
品質は、検査ではなく計画（設計）
によって達成すべきである
欠陥ゼロを目指す
検査よりも予防（コストの方が安
い）
検査の強化が品質改善の最善策とは
見なされない

24. ⇔守りの品質
不運にも、出来上がったものの品質
が悪かった場合に、どう対応するか
さらにテストを追加する、CDIを実
施する、…
→手当たり次第では、キリがないば
かりか、効果がない可能性も
→いかに効率よく、バグを除去する
かが重要

25. ウィークポイントを探せ！
効率を上げるためのヒント
→開発時に摘出したバグが手掛かり
になる
摘出したバグは、これまでの開発の
クセであり、
同じようなバグが潜んでいる可能性
が高い

26. 摘出したバグの分析方法：
複数の軸で分析する
原因別：あいまいな記述、初期化漏
れ、実装漏れ、…
混入工程別：要件定義フェーズ、基
本設計フェーズ、製造フェーズ、…
作成者別：はじめて開発に入る○○
さんが多く出している
機能別：規模が大きいもの、他シス
テム連携部分

27. 摘出したバグの分析方法：
パレート図にしてみる
0
0.2
0.4
0.6
0.8
1
0
5
10
15
20
25
記述曖昧 仕様誤り 実装誤り 規約違反 IF不整合 初期化漏れ
バグの主な原因：
設計書の記載内容が
悪いようである

28. 分析結果を元に、対策を打つ
各分析軸における上位の原因は、誤
りやすいものと言える
→まだ同原因のバグが潜んでいる
可能性がある
上位の原因から、順に対策する
→設計書に曖昧な部分はないか？
仕様（ロジック）誤りはないか？

29. 分析結果を元に、対策を打つ
さらに…原因×機能で、深堀りして
みる
→規模の大きい機能×曖昧な記述
→この機能の中で、曖昧な部分は
ないか？
かけられるコストと相談しながら、
方針を絞って対策する

30. 守りの品質→攻めの品質
ここで摘出した弱点を、次の開発に
活かす
誤りやすいところ
→チェックシート、事前教育へ

31. まとめ
攻めの品質
品質はものづくり時に決まる
ものづくり前に、計画により品質を
向上させる
守りの品質
弱点をあぶり出し、そこを中心に再
チェックを行う

32. 終わりに…
バグ数による品質判断は、これまで
の開発経験からの推測でしかない。
目標値通りだから大丈夫、とは必ず
しも言えない
こう計画して作ったから、こう確認
したから大丈夫、というふうに、品
質を説明できるようにしていくべき

33. ◆攻めの品質、守りの品質◆
～終わり～
平成27年7月25日 in NDS
@2G_KSK