MasterControlのお客様は、当社の特許取得済みの検証技術を利用することができます。この技術により、検証時間が数百時間短縮され、ユーザーは数分で検証を行うことができます。このプロセスの次のステップである自己検証ソフトウェアについて、私たちが話しているのを聞いたことがあるかもしれません。現在、これらの機能を開発中で、最終的にはすべてのMasterControlユーザーがその恩恵を受けることになります。

MasterControlの製品管理担当副社長であるErin Wrightは、以前にもこのトピックについて発表しています。最近の発表では、参加者から多くの質問が寄せられました。それらの質問の回答は以下の通りです。

Q: リスク評価をより良く行うために、ソフトウェア会社から何が提供されますか？
バリデーションパッケージ一式と、移設運用適格性評価（TOQ）や移設性能適格性評価（TPQ）など、ベンダーから活用できるすべての文書があれば、ベンダーから活用できるものと自社で作成する必要があるものを判断しやすくなります。また、ベンダーは、最新のアップグレードで何が変更され、それが他のソフトウェアにどのような影響を与えるかを教えてくれます。

Erin Wrightは、リスクのレベルが大きく異なる2つの変更点を対比して説明しました。「特定の画面に限定された変更なのか、それともソフトウェア内のすべてのデータに関わる検索機能を完全に変更したのか？」

また、「この新機能を利用するために、検証済みの状態で何を変更する必要があるか、また、ソフトウェアの他の部分とどのように相互接続しているか」についても質問してください。

Q: リスクベースアプローチをとる場合、必要な文書が違うのですか？
リスクベースド・アプローチでは、理由と批判的思考を文書化する必要があります。いつものようにバリデーションプランを作成することになるでしょう。そして、リスクを判断するために、どのようなリスクモデルを使用しているかを文書化することです。どのような変数を考慮に入れているのか？その変数の定義は何なのか？そのモデルを定義し、バリデーション計画に組み込んだら、そのモデルを使用目的に沿って分解したリスクアセスメントを作成します。

文書化の一部には、各レベルの改善策を含める必要があります。低リスクの場合、ユーザー受入テスト（UAT）だけを行うかもしれません。中リスクの場合は、具体的にテストしたい事柄のチェックリストを使って、ガイド付きの探索的テストを行うかもしれません。高リスクの場合は、テストスクリプトを使った正式な検証を行う必要があるかもしれません。

そしてもちろん、最終的な検証レポートが必要です。

Q：バリデーションは製品以外のソフトウェアにも適用できますか？
他のすべてのものと同様、それはそれはあなたの用途によります。Microsoft Excelのスプレッドシートを使って、「バッチ記録のレシピの処方と収量を計算する」のであれば、絶対にバリデーションを行うべきです。なぜなら、製品の品質と患者の安全性に直接影響を与えるビジネス上の意思決定を行うためにそれを使っているからです。

しかし、エクセルのスプレッドシートを使って、誰がどのSOPを更新するように割り当てられたかを追跡しているのであれば、（それは）少し重要度が下がるかもしれませんし、検証は必要ありません。

Q: ソフトウェアテストにおいて、より効果的になるためにどのような戦略を推奨しますか。
当然のことながら、Erin Wrightは、過去のデータに基づくリスクベースのアプローチをとることを提案しています。過去にソフトウェアで問題が発生した場所を調べることで、どこに焦点を当てるべきかが分かります。

どんなソフトウェアにも欠陥はありま。過去の傾向を把握し、コードのどの部分がもろいかを把握し、それを考慮して個々のコンポーネントのリスクを評価することが重要です。

過去に、ある機能が他の機能よりも問題が多い傾向があることに気づいたかもしれません。そのようなものは、あなたの経験に基づいて、より高いリスクとみなされるでしょう。リスクの高い領域は、もう少し的を絞った検証テストを保証します。

Q：コンピュータソフトウェア保証（CSA）に向けて、どのような計画を立てているのでしょうか。
Wright氏は、CSAのガイダンスを待っている間でも、この考えは新しいものではなく、FDAの「General Principles of Software Validation」ガイダンス文書に由来していると指摘しています。「FDAは、2002年からまったく同じことを言っています。これは新しい考え方ではありません。これは、2002年に彼らが言っていたことを理解するための新しいガイダンスです。

彼女は、ギャップアセスメントから始めることを提案しています。組織の現状、規制上バリデーションが必要なソフトウェアシステムは何か、どれが自社製でどれがサードパーティベンダー製かを確認するのです。

そして、意図する使用方法を文書化します。Erin Wrightは、「意図する使用方法とは、必ずしも『毎日どう使うか』ではなく、『そのソフトウェアをどう使うか』である」と明確に述べています。リスクの高い重要な使い方は、たとえ日常的でないとしても考慮する必要があります。

次に、あなたにとって重要なリスク変数を把握する必要があります。MasterControlでは、規制による影響、検証済み状態の変化、および主観的な評価を使用します。その後、リスク変数とその測定方法を定義する必要があります。

まとめ
Erin Wrightのバリデーションに関する前回の記事を見逃した方は、こちらをご覧ください。また、録画は下記からご覧いただけます。

本投稿は、英語の文献を元に翻訳または抄訳及び校正を行っており、本サイトに掲載されている全ての情報や画像の著作権は、当社（マスターコントロール株式会社）に帰属します（他社提供のクレジット表記入り画像等を除く）。コンテンツの再発行及び再配布は、個人利用の場合を除き、当社より許可を得た場合のみ可能です。また、本ブログを含む当社のWebコンテンツを利用することで発生する損害やトラブルについて、当社は一切の責任を負いません。