One Point

現在、新型コロナウィルスによるパンデミックが発生し、終息の目途が立たない。このパンデミックによって事業縮小を余儀なくされたり、倒産に至った企業も存在する。また従業員の雇用が保てず、また新規採用の取り消しも発生している。ところで読者諸氏の企業では業務継続計画書（BCP：Business              Continuity Plan）を作成しているだろうか。実はBCPには2種類ある。1つは「激甚災害編」であり2つ目は「パンデミック編」である。激甚災害とは、地震や津波などである。実は、「激甚災害編」と「パンデミック編」では対応方法が真逆であることをご存じだろうか。 激甚災害編地震の特徴としては 局所的である 予告なく発生する（予測不可能） インフラ（携帯電話、メール）などがダウンする などがあげられる。地震が発生した際に必要なことは、如何に早く人を集めるかである。あらかじめBCPで指定して置いた場所（郊外のオフィス等）に地震発生72時間後に集まり、災害復旧本部を立ち上げるのである。集合場所には、パソコン、ノート、筆記類、食料・飲料水、寝具などをあらかじめ備えておく。またあらかじめ代替サイトを決めておき、製造などを継続させる。さらに重要な医薬品等は90日程度の備蓄を持っておくことが必要である。 復旧の手順は、おおよそ以下の通りである。１．インフラ（メール）２．勘定系・営業系システム３．製造系システム４．開発系システム パンデミック編パンデミックの特徴としては あらかじめ予測できる（例：日本で1症例目が発生すると2～3ヶ月後にピークを迎えるなど） 全国（世界中）に蔓延する 終息がある程度予測できる などがあげられる。パンデミックが発生しても休業できない業種は数多く存在する。例えば、警察・消防・医療機関・役所などである。パンデミックの発生が予測される際に必要なことは、如何に人を集めないかである。例えば、部長以上はテレワークとし、従業員の半数を自宅に待機させ、重要な製品に限って残りの従業員で製造を継続する。その場合、本人または家族が罹患した際に自宅待機に切り替え、代替の要員を出社させるのである。つまり、常に50%のマンパワーで操業することが重要である。また、オフィスワーカーの場合はテレワークを実施する必要がある。ネット会議などに不慣れな人や、忌み嫌う（食わず嫌いな）人も存在する。そのため、例えば部長職以上は年に1回テレワークの予行演習を実施しておかなければならない。自宅から適切に業務の指示が行え、決済・承認などを実施しなければならないからである。 今回のパンデミックを機にテレワークを採用する企業も増えた。今年からは5Gのサービスも開始される。今後はテレワークがより進むのではないかと感じている。 ]]>

生データとは 生データの定義はFDAのGLP規則である21 CFR Part 58.3(k)に記載がある。 “生データ”とは、実験室内のワークシート記録書、覚え書き、注意書き、またはその正確なコピーをいい、これは非臨床試験の原観察結果およびその業務についての成績であり、この試験の報告の再構成および評価のために必要である。生データの正確な転写（例えば、そのまま転写され、日付をつけ、署名によって正確であると確認されたテープ）が用意された場合には、その正確なコピーまたは正確な転写を生データとしてもとの資料と置き換えることができる。生データは写真、 マイクロフィルムまたはマイクロフィッシュ、コンピュータ記録、観集結果を口述した磁気記録および自動装置から記録されたデータでもさしつかえない。” つまりそれ以前に記録がなく、初めて記録されたものが生データである。しかしながら、感熱紙などに記録が印刷される場合、そのままでは経年劣化し茶けてしまう。その場合、正確なコピー（またはスキャン）をとり、コピーをした人の署名、日付を付すことによって生データに置き換えることができる。このような生データの正確な転写を”True Copy”または”Certified Copy”と呼ぶ。 動的電子記録と静的電子記録 動的電子記録とは例えば動画（ビデオ）である。静的電子記録とは例えば静止画像（写真）や紙コピー である。静的電子記録（写真や紙コピー）が生データとなる場合は多くある。しかしながら、生データがビデオ（例：スモッグテストの記録）である場合、その1シーンを切り出した写真は”True Copy”とはならない。したがって生データではない。 クロマトグラムのバイナリーデータ（動的電子記録）は、再解析が可能でベースラインや隠れている領域を拡大してみることができる。しかしながら、紙媒体に印刷したチャート（静的データ）ではそれらの操作が不可能である。したがって、規制当局はクロマトグラムのチャートは生データまたは”True Copy”とは認めない。 本邦においては、クロマトグラムのチャート（印刷）を生データとして保存し、バイナリデータを破棄しているケースが多くみられる。しかしながら、FDAやMHRAなどの規制要件では、クロマトグラムのチャート（印刷）は生データとは認めないので注意が 必要である。バイナリデータは決して削除してはならないのである。 ちなみに、クロマトグラフィに相等するデータベース形式の動的電子記録であれば、データを追跡調査、傾向調査、クエリーすることができ、適切なアクセス権限があれば、レビュワーは再解析し、隠れたフィールドを表示し、ベースラインを引き延 ばし積分をさらに詳細に見ることができる。 動的電子記録の”True” Copyは、オリジナル記録の内容と意味が保存され、適切なリーダーと複写装置（例、メディアリーダーを含むソフトウェアやハードウェア）が容易に入手可能であることが条件で、オリジナル記録の形式あるいは互換性のある形式で作成し維持することが

FDAをはじめ世界の規制当局は、製薬企業、医療機器企業に対して統計的手法（データ分析）を要求している。ではなぜデータ分析が必要なのかを考察してみたい。 なぜデータを収集するのか？ まずなぜデータを収集しなければならないのかというと、「直感」ではなく「証拠」ベースの品質保証活動を行うた めである。例えば、 この機種の苦情原因のトップ３はA,BとCである。であるから、A,BおよびCに対して重点的に対応すべきだ。 ここのところ、Dを原因とする苦情が多い気がする。EとFに関する苦情も近頃見 かけるようになってきた。なのでD,EおよびFに重点を置いた対策をすべきだ。 1.は正しい。2.では対策に根拠がなくやみくもに対処しても効果が出ない可能性が高い。 じゃあ、データって何？ 次にデータとは何かを考えてみよう。データ（Data）とは「整理されていない情報」のことである。「生データ」とも呼ばれる。データのままでは使えないだろう。なぜならば、データそのものは数字の羅列だからである。つまり整理されていない情報であるため、人間の頭では理解できない。 そこで「Data」を「Information」に変換する必要がある。そのために「統計的手法」を使用する。 一般にデータ（Data）は、情報化（Information）し知識化（Knowledge）し、最後に有効に生かすための知恵（Wisdom）となる。これをDIKWモデルと呼ぶ。（図参照） なぜ統計が必要か？ 次になぜ統計が必要かを考えてみたい。統計においては、人間の頭で理解できないデータをビジュアライズする。数字を統計的に処理・ビジュアライズすることで、人間の頭でも数字の示すところが理解できるようになるのである。統計には以下の2種類が存在する。 1．記述統計 あるデータを集めて、表やグラフを作り、平均や傾向を見ることでデータの特徴を把握する。工程の状態の把握、苦情率、不適合率推移の把握、苦情原因等の把握 2．推測統計 母集団からサンプルを抜き取って、そのサンプルの特性から母集団の特性を推測し、それが正しい かどうかを検定する。（図参照）製造における抜き取り検査、サンプリングを伴う設計検証、妥当性確認等 なぜ規制要件で「適切な」統計的手法が要求されるのか？

ITアプリケーション（ソフトウェアシステム）の開発・導入には機能仕様書の作成が必須である。一方において、構造設備においては機能仕様書を作成する機会はほとんどない。その理由は単純である。ITアプリケーションには、数多くの機能が存在する。一方で、構造設備は、1プロセス：1機能：1システムである。例えば、「打錠プロセス」は「打錠機能」のみで「打錠機」によって実行される。また「造粒プロセス」は「造粒機能」のみで「造粒機」によって実行される。滅菌プロセスも、充填プロセスなどもほぼ同様である。 1システム＝1機能であるため機能仕様書の作成は必要ないのである。 2010年10月21日に発出された「医薬品・医薬部外品製造販売業者等におけるコンピュータ化システム適正管理ガイドライン」において要求仕様書や設計仕様書とは異なり、機能仕様書の記載内容（コンテンツ）に関する要求事項が記載されていない。 筆者は本ガイドラインが発出される前のパブリックコメントにおいて、機能仕様書に関してもコンテンツ要求を明確にするべきであると主張した。しかしながら、厚労省 監視指導麻薬対策課からの回答は現状で問題ないとの見解であった。 そもそも本ガイドラインを作成したメンバーは、構造設備の専門家ばかりである。したがって、機能仕様書には馴染みがなかったのではないかと推察する。 ガイドラインでは、機能仕様書に関する要求事項が以下のように示されている。 ４．開発業務　4.4　機能仕様に関する文書の作成 開発責任者は、供給者に要求仕様書に記載された要件に対応した具体的なコンピュータ化システムの機能と性能を記載した機能仕様に関する文書（以下「機能仕様書」という。）を作成させ、承認するものとする。 つまり、機能仕様書は供給者（サプライヤ）に作成させるが、そのレビュと承認はユーザ企業（製薬企業、医療機器企業）の責任である。したがって、機能仕様書の表紙には少なくとも5名の署名が入ることとなる。供給者側：作成者、レビューア、承認者ユーザ企業側：レビューア、承認者 機能仕様書は、URSに記載した要求事項をコンピュータ化システム設計に対する要求事項として十分なレベルまで定義するものである。機能仕様書は、承認されたURSをもとに作成しなければならない。通常、機能仕様書は通常、要件定義フェーズにおいてユーザとサプライヤが打合せる事によって作成する。つまりユーザがURSを説明し、サプライヤがその実現方法について検討する。いわば機能仕様書は、ユーザとサプライヤとの合意書であるといえる。 つまり多くの仕様書の中で、機能仕様書がユーザも供給者も理解できる唯一の文書なのである。したがって非常に大事な文書であるともいえる。 リリース後の変更などは、機能仕様書をもとに検討するのが良いだろう。また変更回数も機能仕様書に対するものとしてカウントすることが適切である。 機能仕様書執筆時に、URSと機能仕様書のトレーサビリティマトリックスを作成することによって、ユーザの要求事項がもれなく機能仕様書において定義されたことを保証すること。 ]]>

製薬企業や医療機器企業は規制要件を遵守する必要がある。また供給者も同様に規制要件に適合する原料・材料・資材等を製造し、供給する責任がある。しかしながら、供給者に規制要件を教育し、また要求される品質を担保させることは容易ではない。 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であっても、ビタミン剤や栄養剤を製造するならば、バリデーションの程度は低くて済むであろう。読者諸氏もカテゴリ分類の呪縛から解かれることを願ってやまない。 ]]>