多くの場合、ユーザニーズに合った市販のパッケージソフトウェア（COTS: Commercial Off the Shelf）を購入し、構成設定やカスタマイズを行うことによって、ユーザ要求に適合させることになる。
市販パッケージを導入する場合、一般にユーザとサプライヤが要件定義において、ユーザの要求する機能要件が以下のいずれであるかを決定する。
1) パッケージの機能のまま利用する機能
2) 構成設定（パラメータの設定）により変更する機能
3) カスタマイズ（又は外部開発）により変更する機能
4) 利用しない機能
上図は、パッケージソフトウェアの機能を展開したものである。
- パッケージ製品を変更せずにそのまま利用する機能に緑のチェックを入れる。
- パッケージ製品を構成設定して利用する機能に赤のチェックを入れる。
- パッケージ製品をカスタマイズして利用する機能に黄色のマークを入れる。
- パッケージ製品の機能を使用しない場合は、赤の斜線を入れる。
いったいこれは何をしたかお分かりだろうか。緑のチェックを入れた機能はカテゴリ3であり、赤のチェックを入れた機能はカテゴリ4であり、黄色のマークを入れた機能はカテゴリ5である。
つまり機能毎にカテゴリ分類を行ったのである。
このように、多くの場合、市販パッケージを利用するとカテゴリ3～5が混在することになる。
2)に該当する機能については、機能仕様書および構成設定仕様書を作成することになる。また3)に該当する機能は、機能仕様書および設計仕様書を作成することになる。
繰り返しになるが、ITアプリケーションにおいて、カテゴリーは混在するのである。
したがって、カテゴリ分類は意味をなさない。カテゴリ分類が有効なのは、構造設備や分析機器なのである。
ソフトウェアのバリデーションを実施する際に重要なことは、カテゴリ分類ではなく、リスクベースドアプローチをとることである。
カテゴリ3であっても、抗がん剤や向精神薬などのリスクの高い医薬品を製造するならば、それなりのバリデーション 活動を要する。
カテゴリ5であっても、ビタミン剤や栄養剤を製造するならば、バリデーションの程度は低くて済むであろう。
読者諸氏もカテゴリ分類の呪縛から解かれることを願ってやまない。
Comment