医薬品設備建設における「オーナーのプロジェクトマネジメント2nd改訂版」【第18回】

試運転ステージのプロジェクトマネジメント

(4)プロジェクト品質に関する要求値と期待値の決定
　製品の開発、試験、製造、あるいはテストに関する規制要件や、プロジェクトのビジネス要件に対応したものとすることが計画策定において決定されるが、プロジェクトの試運転ステージでは医薬品の製品品質やプロジェクト品質は基本的に変更されることはない。しかし、スケジュール、スコープや予算は変更することができる。プロジェクト品質とは、各要件への適合を意味する。
　瑕疵とは、製作または施工された部分のうち、何らかの欠陥や不具合などを指す。その瑕疵をゼロにするという品質要件あるいは品質目標とすることも可能だが、不具合許容度ゼロといった要件がプロジェクトに課された場合、プロジェクト予算とスケジュールへの影響が非常に大きなものとなることは間違いなく、現実的ではない。
　テストは、設備が仕様どおりに動作することの、最終的な文書化されたチェックである。テストの計画策定時点において、プロジェクトへの要件を確実に理解し、それらの要件が以下の内容を満足しているべきである。

• テスト可能性 － テストが可能であり、具体的で、定量的で、計測可能な要件であること。例えば、「A」時間当たり「B」回の換気という室内換気回数を計測することはできるが、室内空気の品質が意図した目的通りのものであるということを計測することはできない。
• 実現性 － 実現可能な要件であること。例えば、コンピューターシステムの故障時にバックアップが正常に作動するかをテストすることはできるが、絶対に故障してはならないという要件をテストすることはできない。
• 追跡性 － 仕様、手順、あるいはガイダンスに関連する要件は、設計やテストを通じて追跡することができるが、承認されたプロジェクト文書や企業の指定する参照文献に記載されていない要件は、追跡することができない。

　このチェックは、試運転ステージ以前に実施しておくこと。これを無視すると、要件達成ができない可能性があり、その結果、プロジェクトのスケジュールと予算に大きなリスクをもたらす可能性がある。プロジェクトの基本設計ステージにURSが確定するが、そのURSを基にし、プロジェクト品質の要件を明確にする必要がある。

(5)テストスコープの策定
　プロジェクトの品質要件が設定されたら、テストスコープを決定し文書化すること。「テストスコープには何が含まれ、何が含まれていないのか？」といった単純な質問が、より詳細な以下の 3 項目につながる。

• プロジェクトの規制要件を満たすには、スコープの一部としてどのようなテストを含める必要があるか？データの明瞭性に対するリスクのために、検証が過度にならないような、適切なテストの量はどれくらいか？
• プロジェクトのビジネス要件を満たすには、スコープの一部としてどのようなテストを含めることが望ましいか？データの明瞭性に対するリスクのために、検証が過度にならないような、適切なテストの量はどれくらいか？
• 現在対象としているプロジェクトの範囲に、なぜそのテスト項目が含まれていないのか？どのチームからの提案によるのか？会社の指示によるのか？過去の類似プロジェクトに無かったのか？規制上の要求事項の変更か？事業動機の期待事項の変更か？

　スケジュール延長や予算オーバーとなるようなテストスコープの拡張を防ぐために、上記3 項目の質問について、プロジェクトの早い段階で、文書化し、プロジェクト組織全体の合意を得ること。テストスコープの決定に必要な作業レベルは、プロジェクトによって異なるが、以下のようなプロジェクト文書、あるいはその組み合わせで決定される場合もある。

• 基本設計（BOD）
• テストマスタープラン
• プロジェクト実行計画
• 標準作業手順書（SOP）
• バリデーションマスタープラン
• 操作マニュアル
• P&ID