標準業務手順書(SOP)の意義と、その作成の考え方


ウェブセミナー システム信頼性保証の考え方

システム信頼性保証の考え方を研究するページです。

*万が一文中に解釈の間違い等がありましても、当社では責任をとりかねます。
 本文書の改訂は予告なく行われることがあります。

標準業務手順書(SOP)の意義と、その作成の考え方

1. はじめに

信頼性保証をおこなうにあたって、重要な文書に標準業務手順書(以下、SOP)がある。SOPがなくては、場当たり的な対応となり、成果物品質保証が望めない。
SOPがないままのCSV実施や、21 CFR Part11および日本版ER/ES指針(以下、ER/ES規制)対応は、下記のような問題があるといえる。

  1. 成果物の内容・品質が一定せず再現性に乏しい。
  2. 規制要件・指針等に照らして、適合性があるかどうかが判断できない。
  3. 実施記録に妥当性があるかどうかの判断ができない。
  4. 品質保証ができない。(QAプロセスが確立できない)

今回はコンピュータシステム信頼性保証を実施するにあたって、SOPの意義を解説し、作成すべきSOPを明らかにする。

2. ISO9000における信頼性保証

コンピュータシステム信頼性保証を実施するにあたって、「適合性の確認」が重要となる。広義の「適合性の確認」には、狭義の「適合性の確認」と「妥当性の確認」がある。(図1参照)
まず適合性があるとは、SOP作成段階において、「規制要件」と「標準業務手順書(SOP)」の間に“差”がないことをいう。
また妥当性があるとは、CSV実施やER/ES規制対応実施段階において、「SOP」と「実施状況(成果物)」の間に“差”がないことを言う。
このことはQAを実施する際、しいては査察対応の要となる。

このようにQA実施は、「適合性の確認」と「妥当性の確認」という2段階でおこなわれる。前者を「システム監査」と呼び、後者を「プロセス監査」と呼ぶ場合がある。ここでいうシステムとは、品質管理システム(Quality Management System:QMS)を指す。
つまりシステム監査は、品質保証の仕組み(SOP)が法規制(レギュレーション)に準拠していることの保証であり、プロセス監査とは、適合性のあるSOPのもと、適切に品質管理システム(QMS)が履行されていることの保証である。
SOPがなければ、「適合性の確認」も「妥当性の確認」も行うことができず、信頼性を保証することができなくなる。つまり、たとえ実施記録(成果物)の品質が高いという自信があったとしても、品質の保証が取れないということである。
品質が高いということと、品質を保証するということは別次元であることに注意が必要である。

3. SOPの意義

SOPは、CSV実施やER/ES規制対応実施に根拠を与え、品質保証システムを確立するものである。
SOPは標準業務手順書である。第1回でも述べたが、QCとはQuality Controlのことである。ここで言うControlとは、プロセスが「標準」からずれてしまったり、ずれそうになった際に、「標準」に戻す作業を言うのである。
では「標準(Standard)」とは何であろうか。例えば10個の事象中、8個までが該当すればおそらく「標準」といえるであろう。逆に言うと、2割の例外が存在することになる。
重要なことは、例外までをSOPに記載しないことである。あらゆる例外を記載するのであれば、もはや「標準業務」ではないからである。
また実施段階において例外が発生したからといって、SOPを容易に改訂してはならない。「標準業務」がしばしば変更されると、信頼性保証の根幹が揺らいでしまうからである。
では、実施段階において例外が発生(つまりSOPからの変更)した場合は、どう対処すればよいのであろうか。
例えば、バリデーション計画書において、SOPに定められた成果物とは違った成果物を作成(あるいは非作成)することになったとしよう。この場合、計画を実施に移す前に、QA担当者のレビュを受け、同意を取った上で、プロジェクトオーナー(プロジェクトの責任者)の事前承認を取り付けておくことが必要である。
この際、バリデーション計画書には当該の例外事項(つまりSOPからの変更)が、正当化でき、成果物等の品質において問題がないという根拠を記載していなければならない。QA担当者はその根拠を第三者的に検討しなければならない。
また結果的にSOPを逸脱してしまった際はどうであろうか。
例えば、バリデーション報告書において、SOPで定められた成果物を作成していなかった旨を明らかにした場合を考えてみよう。この場合は、バリデーション報告書に当該成果物を作成しなかったことを正当化できる理由を記載しなければならない。またそれらを根拠に、結果としてCSV等の実施において品質に影響がないこと、システムが利用開始できる理由を記載するか、またはシステム利用上の制限を記載しておくこと。
QA担当者はそれらの記述を第三者的に検討し、同意できれば、信頼性を保証することになる。プロジェクトオーナーはこれらプロセスを承知した上で、承認することになる。
これらの例に示すようなプロセスが正しい信頼性保証のあり方である。SOPからの逸脱を恐れて、安易にSOPを改訂したり、無理やりSOPに合わせるというやり方では、本末転倒である。目的は信頼性を保証するということであり、SOPに違反しないということではないはずである。

4. SOPの階層化

SOPは階層的に作成することが望ましい。(図2参照)

Policy(ポリシー:方針)は、法や規制要件を遵守するための会社としての方針とコミットメントを記述する。したがって、Policyは全社で1つのものであり、その承認者は社長(または経営者)である。つまりPolicyにはWhyを書くことになる。
Policy以下の文書は、Policyに記載された方針に相違することなく作成されなければならない。いわばPolicyは憲法的なものであるといえる。また一度制定されたPolicyは、法や規制要件が改定されることがない限り、変更するべきではない。Policyがしばしば変更されるとすれば非常に奇怪である。
ちなみに外国の会社による監査や、当局の査察では、このPolicyの提示と説明を求められることが多い。日本企業では、Policyを作成していない場合が多く見られ、平気で「Policyはありません。」と回答してしまうのである。考えてみれば、会社に方針もコミットメントもないというのは、やはり奇怪である。
R&R(Roles & Responsibilities;役割と責任)には、Policyによって会社がコミットした遵守事項を実行するために、権限委譲された組織や役割とそれらの責任を記述する。R&Rという権限委譲文書がなければ、全ての実施の責任は社長になってしまうのである。つまりR&RにはWhoを書くことになる。
ちなみに役割とは、バリデーションマネージャ、プロジェクトオーナーなどのような名称を指す。しばしば「役割」という用語と「責任」という用語が混同して用いられていることがあるので注意したい。
SOP(Standard Operation Procedure:標準業務手順書)では、R&Rで定義された役割が、その責任に応じて実施すべき手順を記載する。手順には、R&Rで定義した役割を主語とし、実施する時期、実施すべきタスクを明らかにする。つまりSOPにはWho、When、Whatを書くことになる。
ちなみにSOPには、フローチャートを記載すること。フローチャートが描けない場合は、おそらく記載事項が手順ではない可能性がある。PolicyかWPDなどの多分書に記載すべき事項である可能性が高いのである。
WPD(Working Practice Document:テンプレート)では、実施のための方法を記載する。つまりWPDにはHowを書くこと。Howは経験をつむにつれ、改善され、進化する。したがって、WPDはしばしば改訂され得ることになる。
一般に、上位文書の方が概念的に記載し、下位文書の方が具体的に記載される。したがって、上位ほど改訂頻度が少なく、また上位レベル(例:社長や役員)の承認が行われ、下位ほど改訂頻度が多く、下位レベル(例:部門長)の承認で済ませることになる。

5. 作成すべきSOP

システムの信頼性を保証するために、作成するべきSOPには、表1のようなものが考えられる。

カテゴリー

種 類

備 考

CSV関係

CSVポリシー

CSVを実施する際の方針を明らかにする。

CSV役割と責任

CSVを実施する組織、役割を定義し、それぞれの責任を明らかにする。

CSVガイドライン

CSVを実施する際の方法論を明らかにする。CSV実施において作成すべき成果物を定義する。

CSV標準業務手順書

CSVを実施する際の手順を定義する。(表2参照)

CSVテンプレート

CSV実施において作成すべき成果物のテンプレートを定義し、成果物作成のためのインストラクションを記載する。

ER/ES規制関係

ER/ESポリシー

電磁的記録・電子署名を利用する際の方針を明らかにする。

ER/ES役割と責任

電磁的記録電子署名を利用する際の責任者、管理者、組織を定義する。

ER/ESガイドライン

ER/ES規制(21 CFR Part11、日本版ER/ES指針)の条文を解釈し、機能面における要求事項、運用面における要求事項を明らかにする。

情報セキュリティ関係

情報セキュリティポリシー

情報セキュリティに関する会社としての方針を明らかにする。

情報セキュリティガイドライン

情報セキュリティに関して、企業として取るべき姿勢を明らかにする。

災害対策関係

災害対策ポリシー

災害が起きた場合に、ビジネスを復旧させる為の会社としての方針を明らかにする。

災害対策ガイドライン

災害が起きた場合にビジネスを復旧させる為に、企業として取るべき姿勢を明らかにする。

災害対策計画書

事業所で災害が発生した際に各社員が業務及びシステム復旧に従事するために必要な準備、災害発生時の行動計画及び日常運用計画を記す。

災害時システム対策本部行動基準

災害対策計画書で定義された事業所の災害復旧チームの行動手順を記載する。

インフラ復旧マニュアル

ネットワークや全社共通システムが災害により停止した場合に復旧作業を行うための手順を記載する。

アプリケーション復旧マニュアル

各部門で導入しているアプリケーションが災害により停止した場合に復旧作業を行うための手順を記載する。

システム停止時の業務代替マニュアル

災害によるアプリケーション停止時でも業務を継続しなければならない状況において、アプリケーション以外の手段で業務を遂行するための手順を記載する。

表1 システム信頼性保証のために作成すべきSOP

本連載では、主にCSVに関する検討事項を解説してきたが、コンピュータシステムの信頼性を確保するためには、ER/ES規制対応のための文書や、セキュリティ関係、災害対策関係に関する文書の整備が望まれる。
CSVの目的は、コンピュータシステム(主にソフトウェア)が、ユーザの要求を満たすことを保証することである。つまりコンピュータシステムというしくみの信頼性保証である。
ER/ES規制対応は、信頼性が保証されたしくみの上において利用される電磁的記録電子署名の信頼性を保証するためのものである。電子化された業務の信頼性保証は、CSVER/ES規制対応により実現されるといえる。
またコンピュータシステムによって保持されたり送信されたりする電磁的記録は、プロトコール情報や症例データなどの非常に機密性の高いものが多く存在する。情報のセキュリティは非常に重要である。セキュリティの多くはシステムの機能により維持されるが、印刷物を適切に管理するとか、パスワードを口外しないなどの人的なセキュリティも重要である。
災害対策については、最近関心が高くなってきた。多くの業務は電子にゆだねられ、またデータのほとんどはコンピュータシステムの上に存在するのである。万が一の火災や地震などの激甚災害時において、コンピュータシステムが破壊された際に、業務が継続できることおよびシステムが迅速に復旧できることは重要である。そのためには日々のデータのバックアップや、災害時におけるリカバリー手順を定義しておかなければならない。
CSVのSOPは、例として25種類のものが定義できる。この連載で解説してきたとおり、CSVコンピュータシステム品質を保証するための証拠となる文書(成果物)を作成する過程であるといっても過言ではない。したがってCSVの手順書の多くは、文書を作成する手順を記載することとなる。上位のCSVガイドラインに定義された約50種類のCSV成果物すべてに関して、著者、レビューア、承認者を明らかにするのである。したがってCSVSOPは、複雑なものではない。各々のSOPは簡潔なものとなる。
このように多くのSOPは、文書(成果物)の作成手順を記載するが、一部の例外もある。「パッケージ調査」「ベンダーオーディット」「データ移行」「定期監査」「変更管理」「障害管理」などは、文書の作成の手順のみならず当該業務の実施のプロセスを明らかにする。たとえば、ベンダーオーディット実施の手順や定期監査実施の手順などである。それらプロセスの結果として、ベンダーオーディット報告書や監査報告書等が作成される。

No.

SOP名

成果物

1

ユーザ要求仕様書

ユーザ要求仕様書

2

リスク評価

リスク評価報告書

3

バリデーション計画及び報告

バリデーション計画書

バリデーション報告書

システムリリース通知書

4

パッケージ調査

パッケージ調査計画書

パッケージ調査報告書

5

ベンダーオーディット

ベンダーオーディット報告書

6

機能仕様書

機能仕様書

機能リスク評価

パッケージコンフィギュレーション

7

システム設計

設計仕様書

8

DQ報告

DQ報告書

9

テスト計画

テスト計画書

10

データ移行計画及び報告

データ移行計画書

データ移行報告書

11

移行計画及び報告

移行計画書

移行報告書

12

IQ計画及び報告

IQ計画書

IQスクリプト

IQログ

IQ報告書

13

OQ計画及び報告

OQ計画書

OQスクリプト

OQログ

OQ報告書

14

PQ計画及び報告

計画書

PQシナリオ

PQスクリプト

PQログ

PQ報告書

15

システムアクセス計画

システムアクセス計画書

16

ユーザドキュメント

システム利用手順書

システム運用マニュアル

17

サービスレベルアグリーメント

サービスレベルアグリーメント

18

サポート品質計画及び報告

サポート品質計画書

サポート品質報告書

19

定期監査

定期監査報告書

20

システム廃棄計画及び報告

システム廃棄計画書

システム廃棄報告書

21

変更管理

変更管理計画書

変更要求書

変更要求一覧表

22

障害管理

障害対策計画書

障害報告書

障害一覧表

23

ドキュメント管理

ドキュメント管理計画書

ドキュメント進捗管理表

24

トレーニング計画

トレーニング計画書

25

トレーサビリティマトリックス

トレーサビリティマトリックス

表2 CSV実施のためのSOPと作成すべき成果物

6. 作成すべき成果物の最小セット

このようにCSV実施においては、多くの成果物を作成しなければならない。しかしながら、開発または導入するソフトウェアの種類によっては、作成すべき成果物の種類を限定することができる。
ソフトウェアの種類をカテゴリーによって区別する必要がある。(図3参照)
例としてカテゴリーには、1から5までのものがある。

システムのカテゴリー
図3 システムのカテゴリー

通常、CSVはカテゴリー3からカテゴリー5のソフトウェアに対して実施する。つまりOSやファームウェアはその対象としない。
また各カテゴリーにおいて、作成すべき成果物の最小セットを定義しておく必要がある。つまり、必ず作成しなければならない成果物SOPにおいて定義しておくのである。
このことは、SOPにおいて定義されている成果物は、必ずしもすべて作成しなければならないものではないことをあらわす。
このようにCSVのSOPでは、CSV実施において作成すべき成果物を省略できる根拠を明らかにしておくことも重要である。
もちろん前述したとおり、このSOPで定義した成果物の最小セットからさらに作成を削減する場合には、当該バリデーション計画書において正当化できる理由を記載し、事前にQA担当者の同意およびプロジェクトオーナの承認を必要とする。

計画フェーズ

CATEGORY

成果物名(日本語)

1

2

3

4

5

ユーザ要求仕様書

 

 

×

×

×

リスク評価報告書

 

 

×

×

×

バリデーション計画書

 

 

×

×

×

パッケージ調査計画書

 

 

 

 

 

パッケージ調査報告書

 

 

 

 

 

ベンダーオーディット報告書

 

 

 

×

×

要求フェーズ

CATEGORY

成果物名(日本語)

1

2

3

4

5

機能仕様書

 

 

 

×

×

機能リスク評価

 

 

 

×

×

パッケージコンフィギュレーション

 

 

 

×

×

設計フェーズ

CATEGORY

成果物名(日本語)

1

2

3

4

5

設計仕様書

 

 

 

×

×

DQ報告書

 

 

 

×

×

テスト計画書

 

 

 

 

 

データ移行計画書

 

 

 

 

 

移行計画書

 

 

 

 

 

導入フェーズ

CATEGORY

成果物名(日本語)

1

2

3

4

5

IQ計画書

 

 

×

×

×

IQスクリプト

 

 

×

×

×

IQログ

 

 

×

×

×

IQ報告書

 

 

×

×

×

OQ計画書

 

 

 

 

×

OQスクリプト

 

 

 

 

×

OQログ

 

 

 

 

×

OQ報告書

 

 

 

 

×

PQ計画書

 

 

 

×

×

PQシナリオ

 

 

 

×

×

PQスクリプト

 

 

 

×

×

PQログ

 

 

 

×

×

PQ報告書

 

 

 

×

×

システムアクセス計画書

 

 

 

 

 

システム利用手順書

 

 

 

×

×

システム運用マニュアル

 

 

 

 

×

サービスレベルアグリーメント

 

 

 

 

 

データ移行報告書

 

 

 

 

 

バリデーション報告書

 

 

 

×

×

システムリリース通知書

 

 

 

 

 

サポート品質計画書

 

 

 

 

 

運用フェーズ

CATEGORY

成果物名(日本語)

1

2

3

4

5

定期監査報告書

 

 

 

 

 

移行報告書

 

 

 

 

 

サポート品質報告書

 

 

 

 

 

廃棄フェーズ

CATEGORY

成果物名(日本語)

1

2

3

4

5

システム廃棄計画書

 

 

 

×

×

システム廃棄報告書

 

 

 

×

×

各フェーズ共通

CATEGORY

成果物名(日本語)

1

2

3

4

5

変更管理計画書

 

 

 

 

 

障害対策計画書

 

 

 

 

 

ドキュメント管理計画書

 

 

 

 

 

変更要求書

 

×

×

×

×

変更要求一覧表

 

 

 

 

 

障害報告書

 

×

×

×

×

障害一覧表

 

 

 

 

 

トレーニング計画書

 

 

 

 

×

ドキュメント進捗管理表

 

 

×

×

×

トレーサビリティマトリックス

 

 

 

×

×

表3 成果物の最小セット

7. おわりに

コンサルテーションを実施するなか、筆者が多く体験するのは、SOPを作成しないままのCSV実施を行っている企業が非常に多いことである。繰り返し述べたとおり、テストを繰り返し、成果物を充実させたとしても品質は向上するであろうが、品質保証のレベルはなんら変わらない。なぜならば各活動には根拠がなく、また何度やっても同じことができる、つまり同じ品質を作り出せるという再現性がもてないからである。
本シリーズ最終回となる次回は、厚労省ER/ES指針に対する最新の解釈と対応すべき課題を解説する。

参考
  • 「GAMP 4, GAMP Guide for Validation of Automated Systems」 ISPE, 2001