第2回:計画段階における潜在的な課題

– CSV成功への羅針盤 –

第2回となる今回は、バリデーションの計画作成のフェーズを取り上げます。
 

画像
Column_CSV_2_202511_fix

 

コンピュータ化システムバリデーション(CSV)の道のりは、計画段階でその成否が大きく左右されると言えます。
この初期フェーズで適切な方向性を見定められなければ、後々の工程で想定外の事態が生じて手戻りとなったり、必要のない無駄な作業のためにリソースを消費したりする原因になりかねません。
特に近年、GAMP5に代表されるリスクベースアプローチがCSVの主流となり、その考え方をいかに計画に落とし込むかが、効率的かつ効果的なバリデーションを実現する鍵となっています。

今回は、計画段階で企業が見落としがちなポイントや、意外と苦労する側面を深掘りし、CSVプロジェクトを成功に導くための羅針盤とすべき考え方を提示したいと思います。

 

1.実効性のあるバリデーション計画書の作成

バリデーション計画書(Validation Plan, VP)は、CSV活動全体の設計図であり、プロジェクトに関わるすべての関係者が参照すべき中心的な文書です。しかし、この計画書が形式的なものに終わり、実務との乖離が生じてしまうケースもあります。真に実効性のある計画書を作成するためには、いくつかの重要な要素を考慮する必要があります。

 

計画の「目的」を明確にする

本コラムの第1回でも述べた通り、バリデーション計画書作成の最も重要なポイントの一つは、「なぜこのCSVを行うのか?」という問いに対し、関係者全員が納得する明確な答えを示すことです。単に「規制要件だから」という、義務的かつ後ろ向きな理由だけでなく、そのシステムが医薬品製造販売に至るプロセスにおいてどのような利益や利便性を提供するものか、何を担保しないと患者さんの安全性、製品品質、データの完全性確保を脅かすのかといった本質的な目的に着目して計画書に記述し、バリデーション活動に参加するプロジェクトメンバー全員がそれを支持することです。チーム全体に醸成される共通認識により各自の責任が理解され、その結果、リソースの最適配分を可能にします。

 

GAMP5とリスクベースアプローチの適用

現代のCSVにおいては、GAMP5が提唱するリスクベースアプローチの採用が不可欠です。これは、すべてのシステムや機能に一律の厳格なバリデーションを適用するのではなく、システムが患者さんの安全性、製品品質、データの完全性に与えるリスクの度合いに応じて、バリデーションの範囲、深度、文書化のレベルにメリハリをつけて最適化するという考え方です。

計画書には、バリデーションの方針としてリスクベースアプローチを採ることにより、リスク評価結果に基づき、高リスク機能には厳格なテストと文書化を、低リスク機能には簡素化されたアプローチを適用する方針を明記します。これにより、リソースを最も重要な領域に集中させることができます。

 

網羅性と柔軟性、そしてスケジュールの明記

バリデーション計画書は、網羅的でありつつ、変化にも対応できる柔軟性も必要です。リスクベースアプローチに基づき、真に重要なポイントにリソースを使うことを念頭に置き、バリデーション活動中の要件変更や構成設定変更が発生することも踏まえた変更管理等の対応プロセスを盛り込んで備えておくことで、活動途中での状況変化にも柔軟に対応可能な計画を策定します。

また、CSV活動全体を計画通りに進めるために、計画書には、各バリデーションフェーズ(例:計画、要件定義、設計、構築、テスト、報告)の開始と終了の予定日、主要なマイルストーンを具体的に記載します。特に、システムの本稼働(リリース)に向けた準備タスクはバリデーション報告書の承認の条件ともなり、そのタスクの進捗は製品の製造等にも直結するため、非常に重要です。システムの導入に伴う手順書の改訂、運用保守向けの規定策定、利用者向けの教育訓練の実施といったシステム運用開始に向けたタスクも含めて、網羅的かつ現実的なスケジュールを策定することで、スムーズなシステムリリースを実現することができます。
 

ご支援の事例から

一旦計画を立てたら、何が何でもスケジュール通りに進めないといけない、というものではありません。計画の目的を思い出してください。最終的にはシステムの品質の担保が目的です。検証の結果、要件通りに動作しない場合や、期待に沿わない結果への対応に時間を要する場合もあり得ます。当初予定の全体リリースが困難となるようなケースでは、「どのような方針で何を優先するのか?」を予め計画時点で盛り込んでおくとよいです。例えば、優先度の低い機能はリリースを延期する、などはあり得る選択肢の一つです。そういった場合に備え、コスト増も踏まえてプロジェクトオーナーと計画時点で合意しておくことも大事です。

 

2.リスクアセスメントの深化:見過ごされがちなリスクの特定

リスクアセスメントは、CSVの根幹をなす要素であり、リスクベースアプローチを実践するための要です。しかし、このプロセスが形式的なチェックリストの記入で終わってしまい、真に潜在するリスクを見過ごしてしまっては意味がありません。クリティカルシンキングに基づいて、より深く、多角的にリスクを掘り下げることが重要となります。

 

クリティカルシンキングをリスクアセスメントに活用する

クリティカルシンキングとは、目の前の情報や状況を鵜呑みにせず、あらゆる「起こっては困る障害の可能性」の仮説を、多角的に深く考える思考プロセスです。CSVのリスクアセスメントでは、システムの利用において通常通り利用できるという前提を崩して以下のような問いを自らに投げかけ、リスクの影響をより深く検討する際に役立ちます。

  • 「想定通りに動作しなかった場合、どのようなリスクが生じるか?」
  • 「誤った操作が重大なリスクにつながる可能性は?」
  • 「そのリスクが発生したら、直接、間接的にどのような影響があるか?」
  • 「そのリスクを防ぐ、または低減するための直接、間接的な手段はないか?」


例えば、昨今猛威を振るうランサムウェアに自社が感染したら…、自社とクラウドをつなぐ回線で通信障害が発生しシステムが利用できなくなったら…、操作ミスで重要なデータを削除してしまったら、といったイレギュラーな状況の想定を出発点として対策を考えてみます。
 

クリティカルシンキングを用いてリスクアセスメントを進めることで、単なるチェックリストへのYes/No回答に留まらず、システムの真の脆弱性や改善点を特定し、効果的なバリデーション戦略の立案にもつながります。

 

継続的な状況変化やリスクの見直し

リスクアセスメントは一度行えば終わりではありません。システムの構成変更、機能追加、利用状況の変化、あるいは新たな規制要件の発表などによってリスクプロファイルは変化します。また初期の検討時に考慮が漏れていたリスクが加わることもあり得ます。そのため、定期的なレビューや、重要な変更時の再アセスメントを通じて、継続的にリスクを見直す視点が大事です。

 

ご支援の事例から

システムの在り方や機能が無数に広がる中では、既成のチェックリストへの回答だけでリスクを正当に評価することは困難です。そのために、実際にシステムを利用するユーザーも含めてリスクアセスメントの議論を行うことは大事ですが、リリースまでの時間やリソースの制限のある中で、明確な答えのないリスクアセスメントに延々と時間をかけることもできません。ここでは、まずその議論をしてみること、リスクに対する対策を検討するプロセスを経験し、今後そのステップが定着することを目指せることが望ましいです。

 

3.責任と役割の明確化:スムーズな連携のために

CSVは、IT部門、品質保証部門、システムを利用するユーザー部門、さらには外部のシステムベンダーやコンサルタントなど、多くのステークホルダーが関与する一大プロジェクトです。これらの関係者間で責任と役割が曖昧だと、認識のずれ、作業の重複、あるいは責任の所在不明といった問題が生じ、プロジェクトの遅延や失敗につながりかねません。

 

主要な役割と責任:CSVプロジェクトを推進する力

プロジェクト開始時、あるいは計画書の策定段階で、CSVに関わる主要な役割と責任を明確に定義し、文書化することは極めて重要です。各タスクに対して誰が最終的な責任を持ち、誰が実行し、誰が承認し、誰に情報共有すべきかを明確にできます。具体的な役割としては、以下のような担当者が挙げられます。

  • プロジェクトオーナー: CSVプロジェクト全体の最終的な責任者であり、ビジネス上の目的達成とリソース配分を決定します。
     
  • プロジェクトマネージャー: CSVプロジェクトの管理と遂行に責任を持ち、スケジュール及び進捗、予算、スコープの管理を行います。
     
  • バリデーションマネージャー: プロジェクトマネージャーおよびチームメンバーに対して適切なバリデーションプロセスを指示し、作成したCSV文書および記録のレビューに参画します。
     
  • 品質保証部門(QA): CSV活動全体における独立した品質保証機能を果たし、バリデーションプロセスが規制要件や社内手順に準拠していることを確認・承認します。

この明確な役割分担により、それぞれの担当者が自分の責務を理解して円滑に作業を進めることが可能になります。

 

コミュニケーション計画の確立:情報共有の最適化

役割が明確になっても、情報共有が滞ればプロジェクトは機能不全に陥ります。効果的なコミュニケーション計画を確立することが、スムーズな連携の鍵となります。定期的な進捗会議の設定や情報共有ツールの活用により、必要な情報がタイムリーに、かつ正確に関係者に共有される仕組みを構築しましょう。社外のベンダーやコンサルなどの参画者に対しても、必要な情報の共有が滞らないよう留意いただくことも大事です。また、問題発生時のエスカレーションパスを明確にしておくことで、迅速な問題解決が可能になります。
 

ご支援の事例から

「業務プロセスは熟知しているが、CSVはよく分からない」という方は多く、そのために私たちにCSV支援のご依頼をいただけるのですが、CSVプロジェクトのメンバーに加わったり、特にプロジェクトマネージャーとなれば、よく分からないからと言って他人事で済ますことはさすがにできません。コンサルやCSV支援が可能なベンダーがいるなら、分からないことはどんどん聞いていただき、ご自身がお使いになるそのシステムに関心を持ちながら参画されることが望ましいです。これまでの経験では、プロジェクトマネージャーの方のやる気や向き合い方は、バリデーションプロジェクト全体の雰囲気になることも多かったです。

 

4.サプライヤーアセスメントの重要性:品質保証体制の確認

バリデーション計画に先んじて構想フェーズでの製品選定と同時に進めるべきであるのがサプライヤーアセスメントです。現代のCSVにおいては、外部のシステムサプライヤー(ベンダー)やクラウドサービスプロバイダーとの連携は不可欠です。そのため、サプライヤーの品質保証体制が自社のCSV要件を満たしているかを確認、評価するサプライヤーアセスメントは非常に重要となります。書面調査やオンサイト(訪問)監査といったサプライヤー監査もサプライヤーアセスメントの一部です。

どのような方法であれ、サプライヤーの評価が不十分な場合、GxP要件に適合しない場合など、導入後の品質問題、データインテグリティの脆弱性、監査時の指摘といったリスクを抱えることになりかねません。

 

サプライヤー選定の基準と評価

製品(サービス)とそのサプライヤーを選ぶ段階から、将来のCSVを意識した評価を行う必要があります。単に機能やコストだけでなく、以下の点を考慮しましょう。

  • 品質マネジメントシステム(QMS): サプライヤーがISO 9001などのQMSを確立・運用しているか、製品(サービス)のGxP適用を意識した品質管理が行われているかなど、自社の要求事項と整合しているかを確認します。
     
  • 開発ライフサイクル : サプライヤーのソフトウェア開発ライフサイクル(SDLC)とそれに紐づく開発関連の文書が、バリデーションの観点から適切であるかを確認します。バージョンコントロールの手順が文書として策定されているかも重要なポイントです。
     
  • データインテグリティへの対応 : 製品(サービス)が電子記録・電子署名やデータインテグリティに関する規制要件にどのように対応しているかを詳細に確認します。例えば、製品が電子署名の機能を有していても、ER/ES指針の要件を満たさないものでは規制対象企業での利用は困難です。
     
  • サポート体制とSLA : システム導入後のサポート体制、障害発生時の対応速度、バックアップの体制、稼働保証時間が許容範囲であるかなど、自社の運用要件を満たしているかを確認します。

 

監査の実施と評価:品質保証体制のさらなる確認

サプライヤー監査は、書面による調査とすることが多いですが、必要があればオンサイト監査を実施し、社外秘とされるベンダー保有の文書を確認することも検討します。

監査は事前に質問事項等を作成して計画します。監査の結果は詳細に記録し、指摘事項や改善提案をまとめた報告書を作成します。特に製品選定前の場合は、GxP適用に相応しい開発体制、品質保証体制であるかの観点で評価することが重要です。

 

契約における責任範囲の明確化:トラブルを未然に防ぐ

サプライヤーとのシステム導入に関する契約は、CSVにおける双方の責任範囲を明確にする上で非常に重要です。バリデーション活動における役割分担、バリデーション時に評価対象とするベンダー文書の提供可否、サプライヤーがアップデートなどでシステムに変更を加える際の事前通知や変更管理手順の取り決めなどを明確に盛り込むことで、トラブルを未然に防ぎます。
 

ご支援の事例から

可能性としてあり得るのは、当初Non-GxP領域業務に利用開始したシステムをGxP業務に拡大適用する際、ベンダー監査をGxP視点でしていなかったために、ベンダー側で十分な設計、検証系の文書を作っておらず、開発の品質体制として認められない、という状況に出くわすケースです。そのため、製品の選定前もしくはGxP適用前にベンダーの体制を確認しておくことは重要です。ベンダーとしてGxP適用を想定していない製品も存在するため、その点を確認せずに利用を開始すると、後にベンダーの体制や方針に不満を抱く結果になりかねません。

 

5.まとめ

第2回では、CSVの計画段階における重要な要素として、実効性のあるバリデーション計画書の作成、リスクアセスメントの深化、責任と役割の明確化、そしてサプライヤーアセスメントの重要性について掘り下げてきました。

これらの計画段階での準備を怠らず、適切なアプローチを取ることで、後続のCSV活動を円滑に進め、最終的に高品質で信頼性の高いコンピュータ化システムを構築し、維持することが可能になります。

次回は、CSVの成否を大きく左右する「要件定義」のフェーズに焦点を当て、見落としがちなポイントや、どのように「漠然とした要求」を「明確なバリデーション対象」へと具体化していくかについて深掘りしていきます。どうぞご期待ください。


著者紹介

小寺 正記(こてら・まさき)
株式会社シーエーシー エンタープライズサービス統括本部 エンタープライズP&S部

2015年までの約20年間、製薬企業向けコンサルティング会社にてシステム開発に従事。Part11制定当初よりCSVの実施に携わる。
CROへの移籍とそこでのシステム部門長としてのCSV文書レビュー等を経て、2020年よりシーエーシーに在籍。
同業界における経験を活かし、GxP適用のクラウド環境構築・運用サービスの立ち上げや、CSV支援サービスに携わり、現在に至る。

関連リンク:
Webサイト「Innovation Hub」に、株式会社シーエーシーのCSV支援サービスの記事が掲載中です。

導入に関するご相談・
各種お問い合わせ

製品・サービスに関する各種ご相談・お問い合わせ、無料トライアルへの申し込みはこちら