品質管理の基礎――QAとQCは何が違うのか

品質に問題が出たとき、真っ先に決まるのは「テストを厚くしよう」という対策です。しかしテストを増やして変わるのは、見つかる不具合の数だけです。作り方そのものが変わらなければ、次のプロジェクトでも同じ数の不具合が生まれます。

品質管理を考えるうえで、最初に押さえるべきはQA（品質保証）とQC（品質管理）の区別です。日本語ではどちらも「品質管理」と呼ばれがちですが、見ている対象がまったく違います。

QA品質保証とQC品質管理の違いを示した図

QAはプロセスを見ます。正しいやり方で作っているか、レビューの基準は決まっているか、体制は妥当か。不具合が生まれないようにする活動です。

QCは成果物を見ます。出来上がったものが基準を満たしているか。テストやレビュー、検収がこれにあたり、不具合を外に出さないようにする活動です。

両方が必要ですが、順序があります。QCで出た不具合の傾向をQAに戻し、作り方を直す。この循環がないと、品質活動は「毎回たくさん見つけて、毎回たくさん直す」で終わり、プロジェクトをまたいで蓄積していきません。

品質とは、高機能であることでも、丁寧に作り込まれていることでもありません。合意した要求を満たしていることです。

ここを取り違えると、依頼されていない作り込みが始まります。「よかれと思って」の追加は、コストと日程を消費したうえに、テスト対象を増やし、かえって品質リスクを高めます。品質を上げる活動と、スコープを膨らませる活動は別物として扱う必要があります。

また、品質には等級（グレード）という別の軸があります。機能の少ない製品でも、要求どおりに動けば品質は高い。逆に、高機能でも不具合だらけなら品質は低い。「低グレードは許容されうるが、低品質は許容されない」という整理は、顧客との会話で役に立ちます。

品質活動の重心を上流に置くべき理由は、コストで説明できます。

不具合を発見する工程が遅いほど修正コストが増えることを示した図

要件定義の段階で見つかった食い違いは、文書を直すだけで済みます。同じ食い違いが本番稼働後に見つかれば、改修・再テスト・再リリースに加え、業務停止や信用の損失まで発生します。

倍率そのものは文献によって幅がありますが、後工程ほど跳ね上がるという傾向は一致しています。だからこそ、限られた工数はテストの追加よりも、上流のレビューを機能させることに投じたほうが効きます。

形だけのレビューは、時間を使うだけで品質に寄与しません。最低限、次の4つを満たしているかを確認します。

とくに3つ目は、品質活動の成否を分けます。不具合の報告が評価に直結する環境では、報告そのものが減ります。数が減っても、実態が良くなったわけではありません。

機能の不具合はテストで見つかりますが、性能・可用性・セキュリティ・運用性といった非機能の問題は、テスト工程で見つけても手遅れになりがちです。

応答速度が要件を満たさないと総合テストで分かった場合、直すべき場所はアーキテクチャであることが少なくありません。この段階での作り直しは、日程にもコストにも致命的です。

非機能要件は、要件定義で数値として合意し（「3秒以内」「稼働率99.9%」など）、設計段階でそれを満たす構成になっているかをレビューで確認します。ここは上流でしか手を打てない領域です。

感覚で語らないために、いくつかの数字を置きます。

数値目標を先に決めて、そこに合わせて報告させるのは逆効果です。目標未達を隠す動機を作ってしまいます。指標は判断の材料であって、評価の道具ではありません。

品質にかかる費用は、2つに分かれます。

適合コストを削ると、不適合コストがそれ以上に膨らみます。レビュー時間を削って日程を守ったつもりが、結合テストで倍の時間を失う ―― 多くの現場で経験があるはずです。品質活動は削減対象ではなく、投資対象として扱うのが適切です。

予算交渉の場でも、この整理は使えます。「レビューに工数を使わせてほしい」ではなく、「上流で1かけるか、後で15かけるかの選択です」と示すほうが、相手にとって判断しやすくなります。

品質は、最後に検査して足すものではありません。作る過程に織り込まれているかどうかで決まります。テストは品質を確認する手段であって、品質を作る手段ではない ―― この区別が、QAとQCを分けて考える理由です。

ユーザーコメント（0）