※品質保証のエンジニアである筆者が自省・戒めのために書いた記事になります
品質管理（Quality Control）、品質マネジメントは国内では製造業を中心に発展し、プロダクトの競争力向上に貢献してきました。
JTCと呼ばれる旧来からのメーカーでは、その実績・年功の蓄積に応じて、独立性を保った品質管理・品質保証部門が権威を獲得し、今でもソフトウェア開発に強い影響力を保持するようになっています。筆者は複数のメーカーを転職やコンサルで巡って来ましたが、例えば品質保証部門が承認しないとマイルストーンで開発がブロックされる、プロダクトがリリースできないといった権限を持つ体制が、今なお普遍的に見受けられます。
この品質保証部門が権力を持ち、品質ゲートの門番として振る舞う体制は、今であっても、ある面で恩恵を提供しています。例えば次のようなものです：
- 法規制対応、標準化対応、その他公的なガバナンス要求への対応の徹底
- そうしたものは、力があり独立性が保たれた品質保証部門が推進するのが有効です。開発者任せにすると、開発の遅延や能力不足でガバナンスが乱れることがあるためです。
- QMSや製造プロセスの継続的な改善、品質技術の継続的な蓄積
- 品質保証に特化した部門を維持することで、QMSやプロセスの継続的な改善・蓄積が容易になります。特にQMSは中長期の継続的な整備と改善が重要であるため、プロジェクト型の組織では、プロジェクトと離れた旗振り部門があった方が都合が良くなります。
- 客観的な品質情報の報告や品質改善提案
- 開発チーム内の情報収集・課題認識は、遅延・炎上などで運用が乱れる場合があります。開発チームから独立した品質担当部門があると、開発状況に引っ張られずに客観的に品質を評価し、課題識別する運用が守りやすくなります。
ただ、ソフトウェア開発のようなプロダクトの様相が劇的に変化している状況下では、品質保証部門が旧時代的な品質管理・品質保証を権力をもって強制し続けているせいで、ソフトウェア開発に悪影響を与えている事例が一部であります。
典型例として、最近メーカーで多いのが、デリバリーの高速化・高頻度化対応の阻害です。
旧来は、ソフトウェアを完成させ、しっかり品質保証してから（品質熟成の期間を長く確保してバグを取りきってから）、工場や顧客に納入したり、パッケージ化して市場展開したりする、ウォーターフォールベースの開発プロセスが少なくありませんでした。
ただここ20年超、プロダクトの形態が、パッケージからSaaS等のサービスに変わったり、OTA等で継続的にアップデートしてプロダクトを改善し続けたりするものに変わってきています。それに伴い、開発アプローチとして、継続的デリバリやDevOpsのような、開発のリードタイム短縮、デリバリの高頻度化、ユーザの要求対応の迅速化（いわゆるDORA Four Keysがその典型です）が重要になってきました。
しかし、品質保証部門が、その変化に対応できずに、旧来のウォーターフォールプロセスを実質的に強制するような、長大な時間・コストを要する品質保証を強制し続けて、開発アプローチの改革を困難にしてしまう事例が、JTCにて今でも見受けられます（もちろん時代の変化にうまく対応し適切なソフトウェアの品質保証を行っているところも普通にあります。今回は、長年の年功で獲得した権威から、変化をうけいれられなくなっている特に悪い例について解説します）。
品質保証部門の陳腐化は品質を棄損する
求められる品質が大きく変わり、それに応じて開発の体制やプロセスの改革が求められているのに、権力を持った旧来の品質保証部門が改革をブロックしている状態は「品質保証部門の陳腐化」というべきものです。
この品質保証部門の陳腐化が悪化すると、プロダクトの価値を大きく棄損します。
まず鈍重なアプローチの強制は、開発のスピード・コストをダイレクトに悪化させ、ビジネスの機会や利益を棄損させます。
さらにプロダクトの品質も低下させます。必要最低限の有限な開発リソース（コスト、時間、人）を、重厚長大な品質保証対応で浪費させて、本当に必要な品質の確保・保証のためのリソースを不足させてしまうためです。これは品質の向上・保証のために膨大なリソースと時間の投入を強制しているのに、逆に品質を悪化させているという、いびつな構図を生み出します。
品質保証部門の陳腐化の兆候
この権力ある品質保証部門の陳腐化には、次のような兆候・傾向があります：
プロダクトへの価値貢献ではなく、旧来のプロセスの権威化で自分たちの存在価値を確保している
過去の実績に基づいて構築した品質保証プロセスをトップダウンで守らせ続けることで、自分たちの影響力・権力を維持する傾向です。
一方で「今の自分達がこれからのプロダクトへの価値貢献に貢献できているか」という責任からは逃避します。
また、旧来の品質保証プロセスを、最新のプロダクト状況に合わせて改善することは、自分たちの能力不足を隠すために、暗に抵抗します。
この傾向の副次的な特徴として、自分たち品質保証部門のプロセスやルールに従わないと、開発をやたら不必要にブロックする（次工程に着手させない、品質保証部門の是正要望対応にリソースを全投入させる）というのもあります。これは、現場に対して、陳腐化してなお品質保証部門の権威付けを行おうという強迫観念が顕在化したものです。
また、プロセスの背景となる方法論や哲学への信仰もよくある特徴です。JTCでは長年の蓄積で品質管理の方法論や考え方（例えば品質会計など）を構築していることが少なくありません。
それらが一概に悪いというわけではないのですが、陳腐化した品質保証部門は「その方法論を完璧にこなしてこそ価値を出せる。逸脱すると価値が棄損する」という盲信に近い姿勢で、企業の伝統的な方法論・プロセスから逸脱させない姿勢を徹底することがしばしばあります。
本質的な品質理解を行わなず、旧来のメトリクスの数字で品質を判断する
ソフトウェアの品質が妥当か、本質的な判断を行わず、旧来のメトリクスの数字が基準以上かで品質判断する傾向です。
この傾向でありがたられるメトリクスの定番としては、テストカバレッジ、テスト密度、バグ密度、レビュー密度、レビュー指摘密度などがあります。
例えば、本質的にテスト設計が適切か判断できないため、テスト密度やバグ密度の数字が基準を満たしているかでテスト品質の判断を確定します。
この傾向の副次的特徴として、影響力の保持のため、必要以上にメトリクス基準を厳しくすることがあります。
例えば典型例としてテストのコードカバレッジ100%があります。コードカバレッジ100%は一部の高信頼性製品開発を除いて、難しさ・手間の大きさに対して得るものが少ない、現場に見合わない基準です。しかし陳腐化した品質保証部門は、「テストで網羅しない箇所が問題ないか判断できない能力不足」をごまかすため、一律100%義務化といったことを強制します。
プロダクトバリデーションを放棄して、プロセスバリデーションに偏重する
能力不足により、本質的に必要な品質の確保・保証（プロダクトバリデーション）に手を出せない状態です。かわりに、旧来のプロセスルール（ドキュメントテンプレート、構成管理、レビュー量、承認プロセスなど）の遵守をもって品質保証の判断を行う傾向を強めます。
本来プロセスバリデーションも品質保証で重要な活動です。ただ陳腐化においては、能力不足で本当に妥当なプロセスか判断ができなくなっており、旧来のプロセス定義に沿っているかでもって判断を行おうとします。
この特徴の副次的特徴としては、テンプレート違反や内部工程の承認不備といった、本質的な価値貢献から離れた指摘の比率が大きくなる傾向があります。
なおプロセスバリデーションによる品質評価は、工場の製造プロセスといった対象ならば有効です。ただソフトウェア開発は製造プロセスと比べて非決定的要素、属人的要素が大きいため「プロセスがしっかりしていればよい」という判断だけではリスクが残留します。
能動的な品質理解を行わず、受け身で品質を判断する
能力不足により、自立して主体的に品質を評価できない傾向です。
自力で評価できないリカバリとして、自分たちが品質を理解できるまでの説明責任を、開発部門に負わせます。そこでは自分たちの能力不足で理解できないものは、開発部門の説明不備に責任転化します。
この傾向の特徴として、品質保証のエビデンスを数多く開発部門に負わせるというものがあります。開発過程で生み出されるドキュメントや、日ごろの開発部門の報告を聞いていれば本来わかる情報についても、品質保証用に説明した追加のエビデンスを要求します。
また、品質理解を、品質保証のマイルストーンが近づいてから着手する、という特徴もよく見られます。日ごろから開発部門に入り、そこでの報告や作成資料を読んで品質情報を把握しておく、といったアクションが能力不足でとれません。
開発のリードタイム高速化による品質改善を評価しない。品質ゲートによるバグゼロ志向に傾倒する
時間をかけて（テストやレビューを増やす等）品質を改善するアプローチしかとれないという傾向です。
近年のDevOpsといった開発スタイルでは、DORA Four Keysに代表されるように開発のリードタイム高速化で、サービスを高品質化するアプローチが取られます。バグが見つかっても、高速に修正してユーザへの悪影響を軽減する、というアプローチです。
注意として、このアプローチであっても、リリースにバグを残さない・市場にバグを出さないという品質保証活動が重要なのは間違いありません。高品質な開発をしつつ、開発も高速化して、バグを出さない・出してもすぐ改善するのを両立する形を目指します。
これは、リリースして終わりではなく、継続的に運用や改善を続ける現代的なプロダクトで、常識的に目指すべき基本方針となります。
しかし陳腐化した品質保証部門は、能力不足で品質保証業務を高速にこなせない制約により、仕事の高速さ・リードタイムの短さを価値におくことを避けます。品質活動の速さを評価基準にすると、自分たちの能力不足が露呈するためです。
品質保証活動による開発遅延で実害が出たら、しばしば開発の見積もり不足・リソース計画不備に責任転嫁します。
この傾向の副次的な特徴としては、大規模な承認会議や、鈍重なエビデンスの構成管理といった、やたら時間のかかる儀式の強制をしがちというものがあります。
ビジネスやユーザにとっての品質をリードせず、内向きの品質のみを扱う
ユーザの要求を満たしたり、ビジネスに成功したりするのに必要な品質を見出して、その実現のために開発をリードするアプローチを取らないという傾向です。代わりに、旧来のプロセス定義との合致性や、開発部門が検出した不具合の解消といった、品質要求の変化の影響が少ない品質活動に閉じこもります。
この傾向はどんどん変化する品質要求に、能力不足により追従できなくなった結果発生します。この傾向が悪化すると、リソースや時間をビジネスの成功に紐づかない方向で浪費することで、プロダクトの機会損失リスクを高めがちになります。
品質保証部門の陳腐化の改善アプローチ
品質保証部門の陳腐化の主要因は、品質要求の変化で自分たちが有害なレベルまで能力不足な状態になったのに、権力を維持していることです。
この改善には、時代にあった品質保証能力を確保し、維持し続けるのが重要になります。そのためには、次のような改善アプローチが有効です：
