「検査コストの削減方法」でも指摘したように、現代のソフトウェア開発において大きな課題になってきている事項として、検査項目数が膨大になってしまっているということがあります。これに対する具体的な対策はあるのでしょうか？
二つの代表的な方策
検査項目を削減するための方策として、よく採られるものは以下があります：
- 信頼性工学 — FMEA など
- 品質工学 — 直交表など
背景の説明
検査項目が増えれば、当然それにつれ検査のコストもかさむ事になりますし、工数が掛かることですから時間も掛かることになります。そのためしなくて済む検査は避けたいということがあります。しかしながら、この「しなくて済む」という判断を誤ると検査していれば簡単に判別されていた不具合を見逃して出荷することになりかねません。
新製品の場合は、基本すべての検査をせざる得ません。ただし、機能などの組み合わせ検査に関しては、すべての組み合わせをもとにして検査項目を作成はせず、品質工学の直交表などを利用して組み合わせを減らす工夫をした上で必要十分な検査項目に絞り込むなどは結構知られた手法であると思います。これは直交表を使うことで重複した検査をしないようにしようということでしょう。
これとは別に新規開発ではなく、変更開発、追加の開発などの場合は、多くのソフトウェア開発プロジェクトで変更と連動したテストケースの刈り込みを行っているのが現状であると思います。変更の影響範囲に関連したテストを実施するということで、以前すべての検査をしたソフトウェアのバージョンから変更をした箇所、モジュールに関連する検査項目（テストケース）のみを検査するという手段でなされているはずです。
このやり方は、新規開発の場合でも全検査を実施した版（検査向けのリリースなど）の後の版（検査結果を受けての修正リリースなど）に関しては、通用するやり方になります。
このやり方の場合、「変更をした箇所、モジュールに関連するテストケース」を判別可能な状態でないと適切なテストケースが選ばれないことになります。しなくてもよい検査をしてしまうか、しなければいけない検査をやらないかということになります。
しなくてよい検査をする分には、それがプロジェクトを圧迫するほどのコストのものでもない限り少しコストと工期が増すだけですが、しなければいけない検査をしないということは、製品の品質に直結しかねないですし、場合によっては安全などに関わってきます。安全とまでいかないまでも、製品利用者に経済的損害など及ぼすことはあるでしょう。
上で「それがプロジェクトを圧迫するほどのコストのものでもない限り」と書きましたが、現代の製品の複雑さからすると往々にしてこの条件は満たされず、しなくてよいはずの検査がいっぱいありすぎて、これを全部やっているとすぐにそのコストはプロジェクトを破産に追い込みますし、工期は話にならないほど遅延してしまうはずです。
更にそういう膨大な検査項目がある場合、どの検査項目が必要で、どれは必要ないかの判定にも工数が掛かるので、検査項目の洗い出しだけでも結構なコストと時間が掛かってしまうことが問題になってきます。
ハードウェアの開発設計の場合は、設計時 FMEA などを実施していれば、これを判断材料にして検査項目刈り込みのコストを下げることが出来るでしょう。
ソフトウェアの開発設計の場合は、残念ながら FMEA などを実施しているという例を見たことがないので（やっているところは、ちゃんとやられているのでしょうけれど）、新たにコストを掛けてソフトウェアを対象にして設計時 FMEA を実施する必要が出てきます。これはコスト増に見合う結果を提供するでしょうか？
ソフトウェアの場合の FMEA では、一部の、例えば広域に被害をもたらすポインタの計算間違いとかバッファー・オーバー・ランなどのバグなどを除けば、比較的モジュール間の関係性が捕らえ易いので FMEA の実施は案外低コストに済むような気がします。このことを考えれば、ソフトウェアの品質がビジネスへのインパクトを与えないとか、人命や安全に関わらないとかなら FMEA まで実施する必要も無いかもしれませんが、多くのケースではモジュールのバグが最終的に何を引き起こすかを予め追っておくのは良い習慣でしょう。
もちろんその結果は、後の大々的な検査フェーズにおいて検査項目を刈り込むのに使えるので、どのモジュールがどの機能に関与しているか程度でよいので簡単にチェックしておくのは十分ペイする行為だと思えます。
そうなると「自動化」が対策案として浮上してきます。
＜続く＞