Author name: ecompliance

製薬企業や医療機器企業は規制要件を遵守する必要がある。また供給者も同様に規制要件に適合する原料・材料・資材等を製造し、供給する責任がある。しかしながら、供給者に規制要件を教育し、また要求される品質を担保させることは容易ではない。 2008 年には、ヘパリン ナトリウムの副作用により米国で 81 名が死亡した。その原因は中国の原薬製造メーカーが偽薬を混入したためである。ヘパリンナトリウムは、抗血液凝固剤として使用される。もともとは原料を牛の腸の粘膜から採取していたが、BSE問題により豚から採取することに変更となった。しかし、四川大地震により豚の価格が高騰したため、中国の原薬製造メーカがHPLCのピークがヘパリンナトリウムとよく似た物質を混入させたのである。事件発覚後、FDA は 原薬を輸出した中国の製薬会社を一度も査察していな かったことが発覚した。 それ以降、FDAは2008年に上海を拠点に中国に4ヶ所の事務所を設置した。当初はFDAから7人と中国人8名の計15名で中国の製薬企業の監視を始めた。またインドに関しても同様の監視を行っている。現在では、米国外では珍しい非通知査察（事前の予告をしないで査察が実施される）が実施されている。 日経ビジネスONLINEに興味深い記事が掲載されていたので、以下、引用し一部変更して紹介したい。 「供給者管理に関しては、アップル社の取り組みが参考になる。アップル社のホームページには「サプライヤー責任」と題して取り組みを公開している。供給者の責任は「説明責任」「労働者の権利と人権」「従業員の支援」「環境、健康と安全」「報告書」の5つのパートで構成されている。 アップル社は供給者への監査を通じてサプライヤーの管理状況の掌握に取り組んでいる。注目すべきは、同時に行っている教育プログラムに代表されるサプライヤーへの支援だ。アップルのサプライヤー責任のトップページには「説明責任」についてアップルの考え方を明らかにしている。 供給者の管理レベルを設定し、一定期間ごとに監査を行っている企業は多いだろう。しかしアップル社は、そういった管理状況の説明責任を課しているだけではなく、供給者が自ら責任を全うするために必要なスキルを獲得する「サポート」を提供している。 アップル社が供給者への教育に代表されるサポートを前面に出すのは、取り引きを行っているサプライヤー数が少なく、ほぼすべてのサプライヤーに教育が行き届いているからであろう。2016年2月に公開された「Supplier List」によると、上位200社のサプライヤーで、購入額の97％を占める集中購買を実現させている。サプライヤー監査の回数は2015年で640件を数えており、これは97％を占めるサプライヤーを年3回監査している計算になる。」 ]]>

厚生労働省が発出している規制要件では、要員の「教育訓練」を求めている。ここで注意が必要なのは、「教育」と「訓練」は異なるということである。英語では教育は「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であっても、ビタミン剤や栄養剤を製造するならば、バリデーションの程度は低くて済むであろう。読者諸氏もカテゴリ分類の呪縛から解かれることを願ってやまない。 ]]>