統計的品質管理の功罪

Transcript of "統計的品質管理の功罪"

1. 1. 統計的品質管理の功罪
2. 2. 自己紹介 久納　工 永和システムマネジメント ITS事業部所属 2007〜2014までおカタイお客さんのプロジェクトに 従事 2014〜 Ruby書いてます
3. 3. 受託開発
4. 4. 受託開発に置いては、 開発者が環境や言語、開発 手法などを自由に決められな い場合がある
5. 5. 受託開発 (自由なパターン) 顧客 開発者
6. 6. 受託開発(不自由なパターン) 顧客 開発者
7. 7. 大規模なプロジェクトでは 品質管理担当が置かれること がある
8. 8. 受託開発(不自由なパターン)
9. 9. 受託開発(不自由なパターン)
10. 10. 「パンは危険な食べ物」
11. 11. 「パンは危険な食べ物」 ・犯罪者の98%はパンを食べている。 ・パンを日常的に食べて育った子供の約半数は、テストが平均点以下である。 ・暴力的犯罪の90%は、パンを食べてから24時間以内に起きている。 ・パンは中毒症状を引き起こす。被験者に最初はパンと水を与え、後に水だけを与える実験をする と、2日もしないうちにパンを異常にほしがる。 ・新生児にパンを与えると、のどをつまらせて苦しがる。 ・18世紀、どの家も各自でパンを焼いていた頃、平均寿命は50歳だった。 ・パンを食べるアメリカ人のほとんどは、重大な科学的事実と無意味な統計の区別がつかない。
12. 12. 「パンは危険な食べ物」 ・犯罪者の98%はパンを食べている。 ・パンを日常的に食べて育った子供の約半数は、テストが平均点以下である。 ・暴力的犯罪の90%は、パンを食べてから24時間以内に起きている。 ・パンは中毒症状を引き起こす。被験者に最初はパンと水を与え、後に水だけを与える実験をする と、2日もしないうちにパンを異常にほしがる。 ・新生児にパンを与えると、のどをつまらせて苦しがる。 ・18世紀、どの家も各自でパンを焼いていた頃、平均寿命は50歳だった。 ・パンを食べるアメリカ人のほとんどは、重大な科学的事実と無意味な統計の区別がつかない。
13. 13. 統計的品質管理 とうけいてきひんしつかんり statistical quality control; SQC 統計的方法を用いて行う品質管理。品質管理においては，なんらかの突止 めうる原因による品質の「ばらつき」 (有意な変動) と偶然的な多数の小原因 による品質の「ばらつき」 (有意でない変動) >とを見分け，前者の原因を除 去することをねらいとするが，この見分けを統計的方法で行おうとするもの。 ブリタニカ国際大百科事典 小項目事典の解説
14. 14. コード n行に対して 原因 hoge のバグが 平均 m件の発生する
15. 15. 平均よりバグの発生が多い場合
16. 16. 何らかの原因で 品質が悪くなる傾向があると判断され、改 善策の検討が必要になる
17. 17. 平均よりバグの発生が少ない場合
18. 18. 極端に少ない場合は テストが不十分であると判断され、 テストパターンの追加が必要になる
19. 19. 例
20. 20. ある機能を実現するコード
21. 21. コードA 1. コピペの嵐 2. よくわからない命名(flg01, func_hoge みたいなの) 3. コーディング規約など存在しない 4. 単体テストなど存在した試しもない 5. 全400行 6. 単純バグを１件出しちゃった
22. 22. コードA 1. コピペの嵐 2. よくわからない命名(flg01, func_hoge みたいなの) 3. コーディング規約など存在しない 4. 単体テストなど存在した試しもない 5. 全400行 6. 単純バグを１件出しちゃった
23. 23. コードA’ 1. 局所化、再利用性等を考慮したDRYなコード 2. 読みやすい命名 3. コーディング規約を守っている 4. 単体テスト有り 5. 全100行 6. 単純バグを１件出しちゃった
24. 24. コードA’ 1. 局所化、再利用性等を考慮したDRYなコード 2. 読みやすい命名 3. コーディング規約を守っている 4. 単体テスト有り 5. 全100行 6. 単純バグを１件出しちゃった
25. 25. コードA はリファクタリング によって、どのくらい品質が 改善されたのか
26. 26. 前提条件 このプロジェクトでは以下の統計が既に得られている 200行のコードにつき、 平均1件の単純バグが発生す る
27. 27. コードA 平均に比べて コード行数あたりの単純バグ発生件数が ２分の１ である
28. 28. コードA’ 平均に比べて コード行数あたりの単純バグ発生件数が ２倍 である
29. 29. よって……
30. 30. 修正前のコードAの品質 の方が圧倒的に良い なんとリファクタリングによって 品質が４分の１に悪化した！！！！！
31. 31. そんなわけあるか！
32. 32. コードを良くすればするほど、品質が悪く なる という意味が分からない状況に
33. 33. 何故、こんなことになって しまうのか？
34. 34. 受託開発(不自由なパターン)
35. 35. 僕達が望んでいるもの
36. 36. 現実 Excel…
37. 37. ソフトウェアの品質を評 価するのにコードを一切 見ていない
38. 38. 統計とスケジュールしか 見ていない
39. 39. Do not put your faith in what statistics say until you have carefully considered what they do not say. 統計が示すことを信じる前に、統計に示されていないことを注意 深く考慮せよ。 William W. Watt
40. 40. この統計は優れた設計か、良 いコードか、パフォーマンスが 良いかなどは示さない
41. 41. 極端な話
42. 42. hoge = 100
43. 43. hoge = 100 × 100万行
44. 44. ものすごい高品質 に！！！！！！
45. 45. そんなわけあるか！
46. 46. 結論
47. 47. 結論 ● 統計は、用法用量を守って正しく使用し ましょう。
48. 48. 結論 ● 統計は、用法用量を守って正しく使用し ましょう。 ● ちゃんとコードレビューしましょう