厚生労働省が発出している規制要件では、要員の「教育訓練」を求めている。ここで注意が必要なのは、「教育」と「訓練」は異なるということである。英語では教育は「Education」であり、訓練は「Training」である。自動車免許の取得を考えてみよう。教習所において学科教習を受けるが、これが「教育」に相当する。しかしながら学科教習のみでは、自動車の運転は不可能である。次に大切なことは路上教習であるが、これが「訓練」に相当する。訓練では、上長や先輩社員が実際の業務をやってみせて、やらせてみるといったことを実施する。OJT（On the Job Training）とも呼ばれる。 筆者が多く監査をする中で発見する事項として、「教育」の記録はあるが、「訓練」の記録がほとんど作成されていないということである。 さらに、各要員の力量表（スキルマップ）を作成してくことが必要である。力量表の目的は、各企業においてどのような力量を持った者がどの部門に配置されているか、また将来のトレーニングニーズを把握するために重要である。 ところで「力量」とは「スキル」のことであると誤解していることが多い。ISO-19011によれば、力量の定義は以下のとおりである。 3.14　力量（competence)　意図した結果を達成するために知識及び技能を適用する能力。 すなわち「知識」も持っているだけではダメで、「技能」も持っていなければならない。さらに「知識」と「技能」を駆使して「意図した結果を達成」しなければならないのである。単なる物知りでは力量があるとは言えない。 力量表では、各部門で要求される力量を複数列記し、各項目に対して以下のように5段階で評価することが多い。 レベル１：完全に理解し指導する能力があるレベル2：一人で担当する能力があるレベル3：助手として担当する能力があるレベル4：指導されて担当する能力があるレベル5：担当していない 必ずしも、すべての要員が全ての項目に対してレベル5を目指す必要はない。部門の中でスキルセットを集めればよい訳である。 ]]>

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