JTCと呼ばれる旧来からのメーカーでは、その実績・年功の蓄積に応じて品質管理・品質保証部門が権威を獲得し、今でもソフトウェア開発に強い影響力を保持するようになっています。筆者は複数のメーカーを転職やコンサルで巡って来ましたが、例えば品質保証部門が承認しないとマイルストーンで開発がブロックされる、プロダクトがリリースできないといった権限を持つ体制が、今なお普遍的に見受けられます。
典型例として、最近メーカーで多いのが、デリバリーの高速化・高頻度化対応の阻害です。
[...]
しかし、品質保証部門が、その変化に対応できずに、旧来のウォーターフォールプロセスを実質的に強制するような、長大な時間・コストを要する品質保証を強制し続けて、開発アプローチの改革を困難にしてしまう事例が、JTCにて今でも普通に見受けられます。
[...]さらにプロダクトの品質も低下させます。必要最低限の有限な開発リソース（コスト、時間、人）を、重厚長大な品質保証対応で浪費させて、本当に必要な品質の確保・保証のためのリソースを不足させてしまうためです。これは品質の向上・保証のために膨大なリソースと時間の投入を強制しているのに、逆に品質を悪化させているという、いびつな構図を生み出します。
求められる品質が大きく変わり、それに応じて開発の体制やプロセスの改革が求められているのに、権力を持った旧来の品質保証部門が改革をブロックしている状態は「品質保証部門の老害化」というべきものです。
プロダクトへの価値貢献ではなく、旧来のプロセスの権威化で自分たちの存在価値を確保している
過去の実績に基づいて構築した品質保証プロセスをトップダウンで守らせ続けることで、自分たちの影響力・権力を維持する傾向です。
一方で「今の自分達がこれからのプロダクトへの価値貢献に貢献できているか」という責任からは逃避します。
また、旧来の品質保証プロセスを、最新のプロダクト状況に合わせて改善することは、自分たちの能力不足を隠すために、暗に抵抗します。
本質的な品質理解を行わなず、旧来のメトリクスの数字で品質を判断する
ソフトウェアの品質が妥当か、本質的な判断を行わず、旧来のメトリクスの数字が基準以上かで品質判断する傾向です。
この傾向でありがたられるメトリクスの定番としては、テストカバレッジ、テスト密度、バグ密度、レビュー密度、レビュー指摘密度などがあります。
例えば、本質的にテスト設計が適切か判断できないため、テスト密度やバグ密度の数字が基準を満たしているかでテスト品質の判断を確定します。
プロダクトバリデーションを放棄して、プロセスバリデーションに偏重する
能力不足により、本質的に必要な品質の確保・保証（プロダクトバリデーション）に手を出せない状態です。かわりに、旧来のプロセスルール（ドキュメントテンプレート、構成管理、レビュー量、承認プロセスなど）の遵守をもって品質保証の判断を行う傾向を強めます。
能動的な品質理解を行わず、受け身で品質を判断する
能力不足により、自立して主体的に品質を評価できない傾向です。
自力で評価できないリカバリとして、自分たちが品質を理解できるまでの説明責任を、開発部門に負わせます。そこでは自分たちの能力不足で理解できないものは、開発部門の説明責任の不備に責任転化します。
開発のリードタイム高速化による品質改善を評価しない。品質ゲートによるバグゼロ志向に傾倒する
時間をかけて（テストやレビューを増やす等）品質を改善するアプローチしかとれないという傾向です。
ビジネスやユーザにとっての品質をリードせず、内向きの品質のみを扱う
ユーザの要求を満たしたり、ビジネスに成功したりするのに必要な品質を見出して、その実現のために開発をリードするアプローチを取らないという傾向です。代わりに、プロセス定義の合致性や、開発部門が検出した不具合の解消、インシデント対応といった、品質要求の変化の影響を受けない妥当性確認・検証に閉じこもります。