QAエンジニアが思うところの品質＝コスト

※まだまだ未熟な部分あります。記事は随時アップデート予定です。

結論から言ってしまいますが、品質＝コストと考えて頂いて良いかと思います。
皆さんが日々の業務でどれだけ障害対応、バグ対応、ユーザ対応に追われていますか？
そこを削れば、工数（コスト）がどれだけ空くか考えたことありますでしょうか？

品質＝コストの関係性はご存じの方も多いと思いますが、改めて整理含めてまとめます。

【品質とコストの関係性、なんでイコール（＝）になるのか？】

　まずは、コストの種類からです。
★品質コストの種類
・予防のコスト：品質管理や進捗管理、改善活動
・評価のコスト：テスト、第三者検証
・損失のコスト：障害対応や不具合対応（本来かからなかったコスト）

　ここで注目するべきが損失のコストです。
ここのコストが削減できる部分（極端に言えば品質が良ければ発生しない部分）です。
品質が悪いとこの部分のコストが膨らんでしまいます。
では、品質が悪いことで膨らんでしまうコストをリリース前、リリース後で見ていきましょう。

●リリース前
・開発中のバグが終息せずに、追加対応（追加でのテスト等）が入る
・前工程への手戻りが発生する
・デグレード検出のための回帰テスト、リグレッションテストの工数が増加する
・考慮漏れ、仕様漏れによる再開発対応が入る

●リリース後
・本番障害（流出バグ）での緊急対応
・ユーザ問い合わせ対応、調査対応（バグや使い勝手の悪さが問い合わせ数の増加に繋がる）

　これらのコストが膨らんでしまう（工数が予定より超過する）と、プロジェクト遅延や納期へのプレッシャー、他タスクの遅延（優先度の低いタスクが永遠に後回しにされる）、チーム内のギスギス感・・・が生まれてしまいます。
そして、結果として、プロジェクト炎上、バグが取りきれない、リリース遅延・・・、リリースしたとしてもトラブル対応と、良いことが一つもない状態になってしまいます。

【無駄なコストを発生させなければ、品質は上がる】

テストをすれば、品質が良くなる（プロダクト品質）という考えをお持ちの方が多いかもしれません。
確かにテストをしてバグを検出し修正すれば品質は良くなります。
ですが、テストはあくまで手段の一つです。
例えば、
・的を得ていないテスト（テストスコープのズレ）、不十分なテスト数→バグを検出できない
・テストのやりすぎ→実装量に見合わないテスト工数（俗に言う過剰品質）
のようなテストを実施したとしても品質が良いとは言えないと思います（このようなテストをしたという事実が残るだけ）。
では、品質を良くするためにはどうすれば良いかですが、プロセス品質、プロダクト品質の両方にフォーカスをしていく必要があります。

ポイントとしては、
・各工程間でトレーサビリティが担保されいるか
・各工程での品質の作り込みが十分か（プロセスに準拠しているか、レビューは妥当か）
・テスト工程での検出バグは妥当か（品質基準、検出工程妥当性、検出件数）
が中心になるかと思います。

●各工程間でトレーサビリティが担保されいるか（プロセス品質）
要件定義→基本設計→詳細設計・・・と進んでいくなかで、前工程の全量が次工程に反映されているかを確実に担保する必要があります。
ここでの漏れが要件漏れ、仕様漏れに繋がり、テスト工程でバグとして検出されることになります。
例えば、基本設計の中でAという要件を考慮していかなった、詳細設計の中で条件パターンが漏れたなど・・・。

●各工程での品質の作り込みが十分か、プロセスに準拠しているか、レビューは妥当か（プロセス品質）
前提としてプロジェクトとして各工程での作業内容、ルールを定義していることがありますが、
ここでのプロセス違反が作業漏れ（確認漏れ）になりバグを作り込む原因になります。
例えば、SQLを作成するプロセスを無視したことによりスロークエリが生まれる、レビュー工程を勝手に簡略化することで見逃しや齟齬が生まれるなど・・・。また、レビュー精度の問題もありますが、人間がレビューする以上は100％のレビューは不可能です。
そのため、機械的なチェックやチェックリストでの確認等ある程度ルール化や自動的にレビューできるようにすることが望ましいかなと思います。

●テスト工程での検出バグは妥当か（品質基準、検出工程妥当性、検出件数）（プロダクト品質）
　テストではバグを検出するために実施するものであり、バグが出た＝品質が悪い、問題があるではありません。
ただし、バグの内容、原因が非常に重要になってきます。
また、テストとバグの話をする上で理解しておくポイントがあります（JSTQBのシラバスに記載もある内容です）。
　・バグ０件でのリリースは不可能
　・全数のテスト実施は、まず不可能
　・テストでバグが見つからなかった＝バグがないではなく、テストでバグが見つからなかった＝テストした部分ではバグはないと言えるだけ
　　→すなわち、「問題ないだろう」と見解を出すことはできますが、「バグはありません」と断定はできません。
　・バグは使われなければ出ない
　当然のことですが、使われなきゃバグは出ません。
　
　では、バグの内容、原因に関して詳しく見ていきます。
■妥当なバグ
◎検出工程が適切
結合テストで、検索結果不備のバグを検出した（実装不備）。
総合テストで、要件に記載があるメッセージ表示がないバグを検出した（要件取り込み漏れ）。
■要注意なバグ
×検出工程が不適切
結合テストで、そもそも機能が動いていない（単体テストで検出すべきバグ）。
×バグ件数が多い（品質基準から逸脱している）。
　そもそも品質基準が曖昧というプロジェクトも多いのが実態だと思いますが、バグ件数が多いと基本的には品質が悪です。
　ただ、この「多い」の定義が非常に難しいです。プロジェクトで開発しているプロダクトの性質や規模に依存してしまうため、一概にx件と言えないですが、バグ検出率（バグ数／テスト実施ケース数）が3％を超えるか否かが一つの基準になるかなぁと思います（あくまで経験上です）。
　バグ件数が多い場合は、バグを作り込んだ原因を探ることが重要になってきます。根本原因を特定し他に同様の箇所がないかを水平展開でチェックが必要です（同じミスをしていることが多い）。
　上記のような無駄なコストを発生させなくするような取り組み（手戻りを防止するための施策等）をすることが品質向上の第一歩になります。
これの積み重ねが品質向上に繋がり、結果として品質が良いと言われるようになっていきます。

【では、品質を良くするには？】

　最終ゴールは、「コストを下げる」です。
すなわち、品質改善とは、最終的にコストを下げることです。
（プロセス改善をする→プロセスが重くなる→コストが増えることに関しては、プロセス改善で別記事で書こうと思います。）
厳密にはバグ数を減らしたから品質改善したとは言えず、それによってどれだけコストが下がったにフォーカスする必要があります。
そのため、改善の指標値として、コスト換算が必要（いくらコストを下げられたか？）になってきます。
品質を良くする活動のスタートとしては、
・開発中のバグだったら、どれだけ設計、実装の工数を減らせたか
・リリース後の保守対応なら、本番障害にかける工数をどれだけ減らせたか、問い合わせ対応の工数をどれだけ減らせたか
を見える化することからがスタートになるかなと思います。
上記を踏まえた上で、品質向上施策の進め方として、以下のイメージになります。
・ここら辺の数字を取って見える化する→継続的に監視する→コスト（工数）が減ってる→品質が安定している（良い品質）
・ここら辺の数字を取って見える化する→継続的に監視する→コスト（工数）が増えている→バグが多い、本番障害／お問合せ多発（悪い品質）
　このように、コスト（工数）の推移を見える化、コスト（工数）を下げる施策をすることが品質向上に繋がってくる活動になります。
　また、品質向上活動はすぐに成果が現れると言うよりも、長期的に取り組むことにより、未来のコスト（工数）削減に繋げることをイメージして欲しいです。
品質向上は積み重ねであり、継続であり、一時的なその場凌ぎの活動ではありません。
長期的なサイクルで品質向上を目指していく（将来のコストダウンの施策をする）ことが最も重要です。

【おまけ　最後に、品質の向上が給料アップに繋がるカラクリ】

　給料アップはちょっと言い過ぎかもしれませんが（笑）、
品質向上は、
品質が良い＝コストが低い（不要なコストがかかっていない）＝より利益を出せている
と言えるのではないかなと思います。
（利益が上がれば、その分給料も増やしてほしいですよね-_-何も経営学分かってないけどƪ(˘⌣˘)ʃ）

以上、長く諸々記載しましたが、
・品質＝コスト
・品質向上は一人ではできない（複数部署、チーム、プロジェクトでやっていく必要がある）
・品質は積み重ね
を意識して開発をしていきましょう。
（上手く締めれたかな？？）