品質管理ごっこ
QAのエンジニアのリーダと話をしていたとき、ふと以前の大規模プロジェクトでの品質管理で聞いたことを思い出した。
その大規模プロジェクトは更改プロジェクトで（当時）稼働していたシステム（と言ってもそのシステムはサブシステムでサブシステム自体の規模が大きい）を当時のイケてるアーキテクチャでリプレースするものだ。
更改プロジェクトで品質管理の実施要領や品質を作り込む作業プロセスのデザイン、指標値の検討をしていたとき、稼働していたシステムの構築プロジェクトの品質管理で何が起きたかを教えてくれた。
指標値という言葉がある。エンジニアなら知っていて当然だと思うので説明は不要だと思うが、ここでいう指標値とは品質管理の基準値でソースコードの単位あたりのバグ検出数やテスト項目あたりのバグの発生数などがある。
金融のシステムであるから元々品質をコントロールしているし、エンジニアのマインドも高かったのだろう。品質管理の指標値以下にする、指標値を中心値として上下のバンドの中に収まるように作業品質をコントロールする。
そのプロジェクトは開発も長いが運用に入ってからも長い。リリース後も年次で機能を移植する。
すると何が起きるか。
バグ検出率などの指標に届かないケースが出てくる。今なら、それはよかったではないか、そこまできたら、指標値を見直すか、異常値がないかを見るくらいにするか、など考えるだろう。
ところがその稼働していたシステムのプロジェクトはそうはしなかったらしい。何をしたかというと、指標値に収まるように『バグを混入させた』のである。意図的にバグを混入させ、それを摘出できるかを見ることで品質管理が適正に行われているかどうかを測る考え方もあることは知っているが、それは外部からの観点であって、内部の、エンジニア（やチームのリーダ）による数字合わせとは違う。
どうしてこのようなことが起きたか。
それは品質管理の実施要領に従い評価をし続けることで品質が一定のレベルで安定したため、指標値をクリアすることができない事態になってしまった。それにより品質評価で説明が難しくなってしまった。
まるでコントそのものだ。活動により品質が期待以上まで高まった。一方、品質の基準となる指標値は見直されないから、改修されるプログラムは指標値に満たない。
バグを意図的に混入させるのではなく、品質管理の要領を見直し、新規プログラムと改修プログラムの指標値を分けて定義することが正しかったのだろう。
そんなことを会話したことを思い出した。
今風にいえば品質管理ごっこである。
目的を見失うとおかしなことをエンジニアもやり始める。多分、論理的なエンジニアがいれば『それやる意味あるか』と尋ねたのだろうが、標準化のチームまで声が届かなかったに違いない。
とはいえ、新規プログラムは分別しやすいが改修プログラムも本当に品質レベルが期待の品質を備えているかどうかは別の話である。たまたまバグが出てこないだけで潜んでいるだけなのかもしれないのである。
