ステップ数による不良検出は悪か

システム開発のアウトプットの品質を検証するためにプログラムソースコードのステップ数を母数として何件の不良を検出するかという品質を検証する手法があります。

まあ、とても評判が悪い手法です。

物理的なモノづくりでは生産した後に検査工程を設けて機能するかとか、傷がないかとか、仕様の許容値に収まっているかとかを品質要求に準じて検証します。検証する数量は過去の不良率からこれだけやっておけば不良が見つけられる分だけやるとか、品質要求が厳しいので全量やるとか判断するわけです。

さてその不良検出の手法ってどんなものでしょうか。

誰が要求するか

まず、誰がステップ数あたりの不良検出による品質管理を求めるのでしょうか。某記事では、多重請負構造のトップであるベンダが要求するとありました。そのケースはあるのでしょうけれど、誰が生産物に対する品質状況を説明する責任を負っているかで考えないと見誤ります。

生産物の品質状況を知りたいのは、生産する責任を負う事業者です。元請けによっては、品質要求を示すだけで製造元の委託業者が管理すべきものであるとするところがあります。これは偽装請負に当たらないように考慮されているやり方でしょう。某記事の多重請負の構造で且つ派遣でないのに作業指示をしていると危ない契約ではないかと思います。

何が要求されるか

ステップ数あたりの不良検出は、ステップ数の単位、検出する不良の上限、下限を工程の開始前に決めておきます。実際に生産が始まったら、生産物のステップ数と不良検出件数と計測し、開始前に定義した検出範囲に収まっているかを定量的に検証します。

検出範囲に収まっている場合は、品質を良好と判断し、範囲を超過若しくは未達の場合は、作業工程に何らかの問題があると判断し、原因を突き止め、工程内で品質確保の対処を行うものです。

工程中の品質状況を測定し、定量的且つ客観的に品質の良し悪しを判断する仕組みとしては適当だと思います。

不良検出で何が問題か

ところで品質状況を機械的に判断できるなら便利でいいね、となりそうなところがそうでないのは何かしら問題があるからです。

それを認識した上で生産物の品質状況の判断をしなければ顧客の品質要求を満たしていることを生産する側のSIerが何一つ説明できなくなってしまいますし、代替案を提示することもできません。

言語による違い

言語の世代により不良が混入する差異があります。

開発環境による違い

開発フレームワークの有無や開発支援ツールの有無により、不良の混入の差異があります。マシン語に近い言語によりフルスクラッチで開発する環境と開発支援ツールにより静的チェックが働く環境では変わってきます。

SEレベルによる違い

プロジェクトチームの技術レベルにより不良の混入の差異が生じます。未経験者が多ければ不良が通常より多いです。ただ、一概に言えないのはベテランであれば不良が少ないかと言えばそう言えないのはエンジニアの品質に対する認識の違いがあるからです。

自動生成されるコードの扱い

開発支援ツールにより自動生成されるコードがあります。こうしたコードを不良検出の対象とするかしないかを工程が始まる前に決めなければなりません。対象外とする場合は、SEがコーディングした正味のコード量を計測できる必要があります。

何か他の品質検証を定量的に行う手法があるかどうかですが、コードの業務ロジックについてはSEが書いたものは人という不条理な生物により作られているため、一定の品質を保証することは誰1人できないと思います。

つまり、代替する手法は現状ないのです。問題提起するのは結構ですが、じゃあどうするのを一緒に考えないと単なるガス抜きにしかならないです。