品質管理

項目内容
品質定義潜在バグを潰せた割合を品質とする(エンジニアが感じる完成度でもある)
 潜在バグの存在数は算出不能だが、感覚値としてバグを潰せた割合で評価
品質定義の根拠関連書籍数冊を読了した上での経験則(信頼度は割と高い印象)
バグの遭遇確率品質95であれば、95%の潜在バグを潰せた状態( 5%の確率でバグに遭遇)
 品質80であれば、80%の潜在バグを潰せた状態(20%の確率でバグに遭遇)
 上記例で、品質の差は15ptだが、バグに遭遇する確率の差は4倍にもなる
 そのため、品質80で満足しては問題で、品質95くらいを目指すのが理想的
 なお、潜在バグ自体を消すことは不可能なので、品質向上には限界がある
 また、品質を上げるために必要な工数は指数関数的に増えていくので注意
目指すべき品質潜在バグの存在数は不明なので、低品質でもバグに遭遇しないこともある
 それでもバグに遭遇しやすい状態で危険なので、品質は可能な限り高めるべき
 リリース後の不具合対応は下流工程の人材にとって、非常に負担が大きいので
 ただ、現実的な工数は有限なので、以下のような品質を目指すことになるはず
 期間優先:品質70から90(品質70未満は、おそらくリリースを延期すべき)
 品質優先:品質90から95(品質95超過は、おそらく現実的な工数で不可能)
理想の品質遷移特殊ケース(スキルレベルの高い人材だけが集まると、稀に実現可能)
 企画提案品質20:バグなし、または軽微バグ(要件定義で修正)
 要件定義品質40:バグなし、または軽微バグ(外部設計で修正)
 外部設計品質60:バグなし、または軽微バグ(コーディングで修正)
 内部設計品質60:工程省略
 コーディング品質95:バグなし(外部設計や要件定義のバグも解消)
 単体試験品質95:バグなし
 結合試験品質95:バグなし
 機能試験品質95:バグなし
 保守運用品質95:バグなし
現実の品質遷移通常ケース(実際の品質は確認困難なので適当な数値)
 企画提案品質20:バグなし、または軽微バグ(要件定義で修正)
 要件定義品質30:軽微バグ(外部設計で修正)
 外部設計品質40:軽微バグ(コーディングで修正)
 内部設計品質50:軽微バグ(コーディングで修正)
 コーディング品質70:軽微バグ(レビューで修正)
 単体試験品質75:軽微バグ(レビューで修正)
 結合試験品質80:軽微バグ(外部設計からやり直し)
 機能試験品質83:軽微バグ(要件定義からやり直し)
 保守運用品質85:軽微バグ(要件定義からやり直し+緊急対応)
重要事項見積もり時に、品質を向上するための工数も確保するべき
 要件定義の不備は速く見つけないと致命的な影響が発生する
 外部設計通りにコーディングできるよう、仕様書のみ信じる
 外部設計完了後に、結合試験仕様書を作成すると効率が良い