標準業務手順書の作成

標準業務手順書（SOP）の作成という業務を担当することはあまりないと思います。というのも、SOPは通常は業務担当者に作成する権限はありません。もし、手順書を作ったとしたら、それは基本的には内規という扱いになります。内規に逸脱したとしても、逸脱管理の対象とはなりません。逆に、SOPに違反した場合は、逸脱管理のSOPに従って会社に報告し、是正措置・予防措置を実施することになると思います。
ITの分野では、システム開発SOP、コンピュータ化システムバリデーションSOP、コンピュータシステムの変更管理SOPのような手順書が問題になります。システム開発SOPには、要件定義、計画書作成、設計、実装、テスト環境構築、テスト、ユーザ受入テスト、報告書作成、本番環境構築（リリース）までのプロセスを記述します。コンピュータ化システムバリデーションSOPにはDQ（設計書のレビュー）、IQ（環境構築の検証）、OQ（テスト）、PQ（ユーザー受入テスト）といったプロセスを記述します。SOP作成で難しいのはどの単位でSOPを作るかが問題になります。例えば、システム開発とコンピュータ化システムバリデーションを別々に作ることが多いと思うのですが、これは完全に切り離すことが難しく、分離するとPQとユーザ受入テストのように重複するプロセスができてしまって、馬鹿正直に実施すると同じことを2回するようなことになっていしまいます。他にも、CAPA（是正措置・予防措置）の手順と、ITILをベースにした問題管理の手順を別々の人が作成すると、これまでシステムトラブルが発生して、顧客に迷惑をかけて、原因がわからないといった場合、CAPAの報告書と問題報告書をそれぞれ作成し、別の責任者に同じような経緯を2つのフォーマットで報告するといったことになりがちです。なので、SOPを作成する者は社内にどんなSOPがあって、同じような趣旨のコントロールがだいたいISOにも、QMSにも、ERES/CSVのようなコンプライアンスにも、GAMPにもITILでもあるので、これらを理解して、整理する必要があります。現場の方が苦労しないようにコンプライアンスといっても日本の規制、米国の規制、ヨーロッパの規制がそれぞれあるので、社内のSOPさえ遵守すれば、すべてクリアできるように考えて、SOPを作成します。
なので、SOPを作成するというのは、結構難しい作業で、勉強になります。ぜひ経験する機会があれば、経験してほしいと考えています。