はじめに
「コンピュータ化システム適正管理ガイドライン」は発出されてから10年以上経過していますが、実践的な解釈ととも改めて体系的にこのガイドラインについて、いくつかに分けて記事にしていきたいと考えております。前回までに3.コンピュータ化システムの開発、検証および運用管理に関する文書の作成まで解説をおこないました。
今回は第3回としてガイドラインの目次上、4.開発業務を解説します。
なお、本記事にて抜粋されている文章及び図は、厚労省「医薬品・医薬部外品製造販売業者等におけるコンピュータ化システム適正管理ガイドラインについて」（https://www.mhlw.go.jp/web/t_doc?dataId=00tb6573&dataType=1&pageNo=1）より引用しています。
“開発計画に関する文書の作成”
“開発計画に関する文書の作成”は4.開発業務のうち、4.1に記載されています。
この文書は、CSVの初期段階で作成し、承認を得る必要があります。内容としては、対象となるコンピュータ化システムの概要や開発目的を明確にし、カテゴリ分類、その使用形態・他のシステムとのインターフェースやER／ESなどの適用ガイドラインなど開発における前提条件を記載します。また、開発を遂行する上での責任体制や役割をバイネームで明確にすることが必要です。この際、供給者（サプライヤ）の役割も含んで記載します。
スケジュールはマイルストーンを記載します。この際、開発するシステムのカテゴリやリスクから作成する文書や検証時の活動（DQやFAT・SATなどの実施有無や位置付け）も明確にし、それに沿って、開発・検証を進めていくことが必要です。監査・査察時には、まずはこの文書にて対象のコンピュータ化システムの概要やCSVの流れを説明することが推奨されます。
“要求仕様に関する文書の作成”
“要求仕様氏に関する文書の作成”は4.開発業務のうち、4.2に記載されています。
URS（ユーザー要求仕様書）になります。要求仕様書は、さまざまな観点でユーザーがシステムへ期待する要件を記載するドキュメントになります。基本的にはガイドラインにおける(1)〜(7)を記載するようにしますが、この文書の内容を以降の検証活動にて確認していくことになるので、品質に関わる重要な項目は漏れなく記載することが必要です。
検証中にURSの改訂にて項目の変更・追加や削除をおこなうことは可能ですが、変更によるリスクアセスメントを含む適切な変更管理を実行・ドキュメント化する必要があります。DQ以降での変更はDQの再実施も必要に応じて必要となる為、できる限り、以降での変更がないように記載をすることが重要です。以降の検証活動や変更管理を容易にするため、項目は個別にURS番号を振り、記載していくことが推奨されます。
運用要件の概要
この項では、コンピュータ化システムのプロセスフローを記載することが推奨されます。例えば、ログインのフローなどです。後々の検証が容易になることに加え、システムの使用方法が明確になるので担当者の理解や個別要件の検討にも役に立ちます。この項の記述は重要なポイントだと考えています。
データ
この項も重要なポイントになります。データの詳細はのちの詳細設計で明らかになるため、詳細な記述はできませんが、クリティカルパラメータなど帳票作成など管理上で重要なデータ項目は明記が必要になります。その為、時間をかけて検討することになります。
“システムアセスメントの実施”
“システムアセスメントの実施”は4.開発業務のうち、4.3に記載されています。
システムアセスメントはソフトウェアカテゴリ、製品品質に対するリスクアセスメント、供給者アセスメントの実施となります。初期段階における対象システム及び供給者へのアセスメントとなり、4.1の開発計画に関する文書を作成するにあたり、根拠となる活動になります。その為、実施時期は開発計画に関する文書の作成時となります。従って、開発計画に関する文書とは別の文書とすることも可能ですし、開発計画に関する文書と合わせて作成することも可能になります。
(2)製品品質に関するリスクアセスメントは、初期段階では、要求仕様書に基づいて実施をすることになります。従って、基本的には、システムアセスメントを含む開発計画に関する文書の作成時には要求仕様書も作成されている必要があります。なお、リスクアセスメントについては機能が複雑で詳細なアセスメントが必要と判断された場合、システム自体の機能に着目しアセスメント（機能リスクアセスメント）を実施する場合もあります。これを実施する場合は、開発計画に関する文書に実施の有無を明記します。
“機能仕様に関する文書の作成”
“機能仕様に関する文書の作成”は4.開発業務のうち、4.4に記載されています。
機能仕様に関する文書（機能仕様書）は供給者により作成される文書になります。内容は要求仕様を実現する方法を具体的に記載した文書になります。従って、要求仕様の各項目ごとにトレーサブルな形式で記載されている方がのちの検証作業が容易になる為、供給者へ要求することが推奨されます。また、その内容はのちの設計仕様書への展開ができるレベルで詳細な記述が必要です。たまに要求仕様書と同じレベル・解像度で記述した文書が提出されることがありますが、それでは機能“仕様書”とは呼べません。
機能リスクアセスメントを実施する場合は、この機能仕様書の作成時に実施します。アセスメントの結果、対応が必要な項目がある場合は、設計仕様書へ反映をおこないます。
“設計仕様に関する文書の作成”
“設計仕様に関する文書の作成”は4.開発業務のうち、4.5に記載されています。
設計仕様に関する文書（設計仕様書）は機能仕様書同様に、供給者により作成される文書になります。設計仕様書の内容はハードウェア、ソフトウェアそれぞれの設計仕様を詳細に明確にする内容である必要があります。また、機能仕様書のように要求仕様書とトレーサブルである必要があります。この段階で、URSに対する機能仕様書及び設計仕様書のトレーサビリティマトリックスを作成し、URSが設計に反映されていることを確認することを推奨します。このトレーサビリティマトリックスを利用することで、のちの検証作業（DQ）の実施が容易になります。
カテゴリ5のシステムにおいては、のちの検証作業を容易にする為、標準ソフトウェアである部分と、カスタマイズ部分をソフトウェア仕様書にて明確にすることが推奨されます。CSVはリスクベースアプローチであるため、たとえカテゴリ5での検証が必要であっても、標準ソフトウェアである部分はカテゴリ3または4相当の検証で十分であり、カスタマイズ部分に関してはプログラムテストなどより重厚な検証をおこなうなど、同じシステムでもその部分において検証活動を合理化して進めていくことが可能になります。この点は、機能リスクアセスメントや開発計画に関する文書で明文化できれば、なお説明がしやすくなります。
“プログラムの作成及びプログラムテスト”
“プログラムの作成及びプログラムテスト”は4.開発業務のうち、4.6に記載されています。
プログラムの作成においては、供給者はプログラムの仕様に関する文書（プログラム仕様書）の作成が必要になります。この仕様書に基づいてプログラムを作成が求められます。また、プログラムテスト計画書及びそれに従ったテストを実施することになりますが、この一連の開発作業は一般的に品証体制がしっかりとしている供給者であれば、自然な作業となるので、その提出を要求することで良いと思います。なお、この活動はCSV上はリスクの低いシステム（カテゴリ４以下）では不要になります。
“システムテスト”
“システムテスト”は4.開発業務のうち、4.7に記載されています。
システムテストは工場出荷前試験（FAT）や現地受入試験（SAT）の実施前に供給者が実施するテストになります。これもプログラムテストと同様に、テストスクリプトを計画したドキュメントを事前に作成し、それに従ってテストを実施します。位置付けとしては、工場出荷前試験（FAT）や現地受入試験（SAT）を補完するテストであり、基本的には全ての要求事項・設計内容に対して実施をします。
“受入試験”
“受入試験”は4.開発業務のうち、4.8に記載されています。
受入試験は、工場出荷前試験（FAT）と現地受入試験（SAT）があり、適時選択して実施を行います。この検査もテスト計画書とそれに基づくテストの実施が必要になります。
このFAT/SATの結果は、テスト実施環境などを考慮して、のちの検証活動（IQ/OQ）でその実施結果をリファレンスすることがあります。その場合、テスト環境がIQ/OQでの実施と相違なく、結果が変わらないことが条件となります。このあたり（テスト環境、IQ/OQでのリファレンス有無と項目、その根拠）はFAT/SATのテスト計画書にて明記をおこない、IQ/OQの承認者の承認を得ることが重要になります。
最後に
今回は、コンピュータ化システム適正管理ガイドラインにおいて、4.開発業務について解説をおこないました。次回は5.検証業務について記事にしようと思います。
もし、意見や質問、お気づきの点があればコメントいただければ幸いです。
コメント