オフショア開発での品質管理（管理限界による管理）

品質の良いシステムを構築するのは非常に難しいことです。

当たり前のことをコツコツと確実に行えばある程度の品質は確保できますが、それがなかなかできません。

99%の仕事を真面目にやっていたとしても1%の漏れがあれば、その1%でシステム全体の品質評価が下がってしまいます。しかも、品質は目に見えないので漏れを見つけるのは大変です。

同じ場所で仕事をしていても難しいのですから、オフショア開発で場所が離れていればなおさらです。

そこで今回は、テスト仕様書や不良件数から品質の状況を監視する手法（管理限界）をご紹介します。

管理限界による品質管理の概要

管理限界による品質管理は、テスト仕様書や不良件数が標準値からある程度離れていた場合、品質が悪い可能性があると考えるやり方です。
工場での品質管理の考え方が土台になっており、メーカ系のベンダなどでよく使われている手法です。

オフショア開発では、後工程になって不良が多発して問題になるプロジェクトがよくありますが、この手法を適用すれば、問題のあるプログラムを早期に摘出して対策することが可能となります。

どの程度基準値と実績値が離れている場合に問題とするかはプロジェクトにより異なるのですが、基準値の2倍超なら多い、基準値の半分未満なら少ないと判定するのが良いと思います。

実際の判定方法を例でご説明します。
あるプログラムの単体テストを行ったときの結果は以下の通りでした。

ここで密度と言っているのは、プログラム1000ステップ当たりの件数のことです。
ksというのはキロステップで、プログラム1000ステップを表しています。

まず、テスト仕様書密度を算出します。
(テスト仕様書作成件数(D))120件 / (プログラム規模(C))3.0ks =　40件/ks(F)

つぎに不良密度を算出します。
（摘出不良件数(E)）12件 / (プログラム規模(C)）3.0ks = 20.5件/ks(G)

テスト仕様書密度（40件/ks）は、テスト仕様書密度基準値（100件/ks）の半分未満です。
不良密度（20.5件/ks）は、不良密度基準値（10件/ks）の2倍超です。

それを以下の表ににあてはめると評価は✖️で「少ないテストケースで多数の不良を摘出。プログラムの作りが悪く、不良が残存している可能性大」という判定になります。

つまり、テストをさぼっているにも関わらず、多くの不良を検出したということは、まだたくさんの不良が隠れているに違いないと判断するわけです。

限界値を超えたプログラムについては、テスト仕様書やプログラムを見直し、必要に応じて追加テスト実施などの対策をとります。限界値を超えた理由や対策は、一覧表に記録します。

適用に当たってのポイント

この手法を適用する際に注意しておくべき４つのポイントをご説明します。

• あくまでも目安として使う
• 仕様変更など変更規模が小さな案件には適用しにくい
• 全体で評価せずにプログラム１本単位に評価する
• 同じ理由をコピーして使うことが多くなってくるので注意

あくまでも目安として使う

この手法で摘出できるのは、品質が悪い可能性が高いプログラムです。
可能性でしかありません。
担当者によっては、机上確認をあまり行わず、実機でたくさんの不良を出して基準値を外れてしまうかもしれません。でも品質が悪いとは限らないのです。

基準から外れたことを大問題のように扱うと、正しい報告が上がってこなくなる恐れがあります。
不良をたくさん見つけても、わざとバグ票を作成しないようになったら最悪です。

確率的に一定の割合のプログラムが限界値を超えるのは当たり前のことなので、むしろ限界値を超えるプログラムが少ない場合に問題とすべきです。

仕様変更など変更規模が小さな案件には適用しにくい

変更規模が小さいと目標不良件数が0.2件〜0.6件の間というようなことが起きます。
そうすると0件でも1件でも限界値を超えてしまいます。
このようにプログラム１本当たりの規模が小さいと、この手法は適用が難しいです。

全体で評価せずプログラム１本単位に評価する

よくシステムやサブシステム全体の値で評価するＰＭがいました。
しかし、評価はプログラム１本ずつに対して行わなくてはなりません。
優秀な担当者が作成したプログラムＡと未熟な担当者が作成したプログラムＢを足して評価しても意味がありません。全体的に数値が良好だったとしても、プログラムＢに不良が残存していれば、このシステムの品質は悪いのです。
評価はプログラム単位で行いましょう。

同じ理由をコピーして使うことが多くなってくるので注意

オフショア開発でこの手法を適用していると、いつも同じ理由がコピーされて「問題なし」とされてくることが増えてきます。国内でも同じようなことは起きますが、オフショア開発だと書いてあることが理解できていないまま、コピーしてくるケースが多く見られます。
このような場合は、オフショア開発の委託先が記入してきた理由や対策を細かくチェックして、まめに指摘するしかありません。