第3回：要件定義の精緻化

第3回目となる今回は、GxP適用システム導入時のコンピュータ化システムバリデーション（CSV）において非常に重要でありながら、書き方に慣れないとつまずきやすいタスクの一つである「要件定義」がテーマです。
 

画像

システムの選定や導入前の初期段階で行われるこのプロセスは、その後の設計、構築、テスト、そして最終的なシステムの品質と規制適合性に直接的な影響を与えます。要件定義が曖昧であれば、手戻りやコスト増大、さらには期待通りのシステムが構築できないといった問題に直結します。

今回は、要件定義の深淵に迫り、顧客が見落としがちなポイントや、どのように「漠然とした要求」を「明確なバリデーション対象」へと具体化していくかについて深掘りしていきます。

システムの選定や導入において、ユーザー部門からの要求が出発点となります。しかし、これらの要求が抽象的な表現に留まり、具体的な業務要件やシステム要件に落とし込まれないことが多々あります。要件を文書としてまとめたユーザー要求仕様書（URS: User Requirements Specification）での要件記載が曖昧であると、その後の工程での大きな混乱を招きます。

• 認識のずれ: 求めるシステムについて、ユーザー、IT部門、ベンダーといったプロジェクトの参画者ごとに、システムの機能や振る舞いに対する認識が異なることにより、期待とのミスマッチが生じる場合があります。
   
• 手戻りの発生: 導入・検証が進んだ段階で「こんなはずではなかった」という状況が判明し、大幅な修正が必要になることがあります。これはコストやスケジュールの遅延に直結します。
   
• テストの困難さ: 要件が曖昧な場合、何をどのようにテストすればシステムが意図通りに動作するかを検証しにくくします。
   
• バリデーションの非効率化: 検証すべき対象が不明確な場合、バリデーション活動が非効率になり、その正当性も揺らぎます。 

URSは、ユーザーがシステムに何を求めているのかを、プロジェクトに参画するすべてのステークホルダーが等しく認識でき、かつ評価可能であることを意識して記述することが重要です。そのため、最初の要件出しはユーザー部門が自由に行うべきである一方、URSとしての清書はユーザー部門に任せきりにするのではなく、CSVの経験のあるIT部門や有識者が関与して行うべきです。

• 業務プロセスの具体化: 現状の業務プロセスを深く理解し、システム導入によって解決したい課題や目標を具体的に洗い出します。例えば単に「一覧画面があること」といった大雑把な要件ではなく、その一覧を業務でどう使いたいか、どのような表示要素や操作が必要かといった、具体的な操作や結果を示す業務要件として明確化することが必要です。
   
• 「なぜ」を深掘りする: 各要求に対して「なぜそれが必要なのか？」と問いかけることで、その要求の背景にある真のニーズや、製品品質・患者安全性への影響度を理解できます。従来の手順や自社のルールに拘り過ぎないことも大事です。この深掘りにより、要求の優先順位付けや、リスクベースアプローチへの適用が容易になります。
   
• 検証可能性の確保: 記述された要求が、後続のテストフェーズで検証可能であるかを確認します。例えば、「システムは高速であること」ではなく、「システムは〇〇の処理を△秒以内に完了すること」のように、具体的な基準値を設定します。
   
• 規制要求とガイドライン要件の考慮: GxP適用のシステムの場合、業務要件だけを満たすものではなく、ER/ES指針やデータインテグリティ面が充足されているかの考慮も必要です。改ざん不可の監査ログはあるか、電子署名には署名の目的を付すことができるか、データのエクスポートなどによる自力でのバックアップ手段はあるか、なども踏まえた要求を組み込みます。
   

最終的なPQのテストスクリプトは、URSに記載された要求事項（Requirement）を根拠として作成されます。特にパッケージやSaaSの導入において、URSはベンダーへの要求と、適合性評価、検証活動の土台となるため、次のような一定のルールに従った記載が重要になります。

• ルール１：すべての要求に一意のIDを付番する
  各要求事項には、必ず一意の識別子（ID）を付番しなければなりません。このIDは、システムの適合性評価（Fit/Gap）、PQのテストケース、変更管理や逸脱管理、そして最終的なバリデーション報告書に至るまで、プロジェクト全体を通して共通の「管理番号」として機能し、トレーサビリティを確保します。
   
• ルール２：機能名や用語を全体で統一する
  URS内で使用する機能名、業務用語、データ項目名、そして規制要件に関する用語は、文書全体を通じて統一される必要があります。特定の業務の名称や機能の名称が要件ごとに異なっていると、書いた人以外が誤解しやすくなり、特にベンダーが認識を誤ると、製品やサービスの不適切な構成や設定を提案する原因となります。
   
• ルール３：各要求に優先度を設定する
  すべての要求事項に対し、「業務遂行上絶対に必要なもの」（必須/Must-have）から、「なくても業務は遂行可能だがあればよいもの」（任意/Nice-to-have）まで、優先度を明確に設定すべきです。優先度が未設定の場合、重要度の低い要求のために高額なオプション利用料を検討してしまったり、真に重要な機能を重点的に検証するリスクベースのバリデーションアプローチを取ることができず、リソースを過剰に割いた結果、プロジェクトの長期化を招く原因となります。
   

要件定義というと、システムの「何ができるか（機能要件）」にばかり目が行きがちです。しかし、システムの使いやすさ、安全性、安定性といった「どのように動作するか（非機能要件）」も、CSVにおいては非常に重要なバリデーション対象となります。これらの非機能要件の考慮が漏れると、運用開始後に予期せぬ問題が発生し、システムの信頼性や業務効率に大きな影響を及ぼします。

• 性能要件: 「〇年間で累積〇万件の文書を格納、管理できること」「同時に〇人まで利用できること」といった要件を記載します。「将来のデータ増加に対応できる十分な処理能力を持つこと」といった、何がどのように十分であるのかが曖昧な記載だと、ベンダーはその性能を具体的に保証できず、結果として業務に支障をきたす可能性があります。
   
• セキュリティ要件: 「ユーザーの役割に応じて必要最小限の権限のみが付与されるアクセス制御ができること」「システムで扱う電子文書に対して、作成、変更、削除を含むすべての操作を自動的かつ永続的に記録する監査ログを備えること」といった要件を記載します。「不正アクセスを防ぐこと」「データが改ざんされないこと」といった曖昧な表現で、何を以てそれを実現するのかが分からないと、機密情報の漏洩やデータの破壊、規制違反のリスクが高まります。
   
• 可用性要件: 「システムは年間〇%の時間稼働していること」「障害発生時は△時間以内に復旧すること」といった、自社の業務として許容できる目標稼働率や目標復旧時間を明記します。「システムはいつでも利用できること」といった「いつでも」の定義が不明確な記載は、認識の違いにより、メンテナンスのためのシステム停止が頻発するなど、業務が中断されるリスクがあるため避けるべきでしょう。
   
• 保守性要件: 例えばSaaSの場合、本番環境と分離された検証環境で、構成変更等の事前検証が可能か、システムアップデート時にはIQ/OQに相当する検証文書がベンダー側で作成され、閲覧可能かなどを記載します。システム起因のトラブル（逸脱）発生時の原因特定に備え、システムログが記録されているかなども、GxP適用時には重要です。
   
• ユーザビリティ要件（Usability Requirements）: 「操作が簡単であること」「直感的に使えること」といった主観的な表現では、結果的にユーザーの習熟に時間がかかったり、操作ミスが多発したりする原因となります。

非機能要件は、システム設計の根幹に関わるため、要件定義の非常に早い段階から検討を開始する必要があります。また抽象的な要求記載ではなく、測定、評価可能な指標を示すことが大事です。
 

URSは、プロジェクトの初期段階で作成されたものがステークホルダーに共有されますが、一度作成したら終わりという静的な文書ではありません。CSVプロジェクトの期間中、特にベンダーとの仕様検討やリスク評価に伴い、要件が追加、修正される場合もあります。このとき、正しく変更管理（版管理）を行うことが大事です。

このような事態を防ぐため、プロジェクトの初期段階でURSの版管理ルールを明確に定める必要があります。

• 承認と確定: プロジェクト開始以降もURSに常時変更が加えられている状態はムービングゴールポストと同じで、何が最終的な条件であるかが定まりません。特定の時点で承認して確定させる必要があります。逆に、版の確定が適切に行われず、任意のタイミングで修正が続けて行われる状況では、閲覧する時点によってURSの内容が異なってしまったり、要件の追加・変更・削除に気づかないまま作業を進めてしまうなど、認識の齟齬が生じる恐れがあります。
   
• 変更履歴の記録と監査ログ: 特に改訂版の編集作業中は、「誰が、いつ、どこを」修正したのかという文書内の変更履歴は非常に重要です。次版の確定時は、承認者がこれらの変更に合意したことを意味します。関係者には適切に変更点を周知して全員が同じゴールの認識を持つ必要があります。
   
• 一元管理と周知: URSのマスターファイルは一元管理し、改訂時には必ず全ステークホルダーに最新版が周知されるプロセス（例：文書管理システムでの通知、定例会議での確認）を確立します。できる限りマスターファイルを直接参照する方式をとり、関係者各自の手元に過去版のコピーを残さない手順を検討します。

第3回では、CSVのスタート地点でありゴールの条件でもある「要件定義」のフェーズに焦点を当て、ユーザー要求の具体化、作成時のルール、非機能要件の考慮、そして版管理の重要性について掘り下げてきました。

要件定義は、単に「システムが何をするか」を書き出す作業ではありません。それは、ビジネスニーズと規制要件を深く理解し、将来を見据えたシステム品質の基盤を築くための、戦略的な活動なのです。このフェーズで十分な精度のURSを作成することで、後続のCSV活動を円滑に進め、最終的に高品質で信頼性の高いコンピュータ化システムを構築し、維持することが可能になります。

次回は、CSVの検証活動の中核である「テスト戦略と実施」に焦点を当て、効果的なPQ計画の策定や、テストデータの重要性、逸脱管理の勘所について解説していきます。どうぞご期待ください。

著者紹介

2015年までの約20年間、製薬企業向けコンサルティング会社にてシステム開発に従事。Part11制定当初よりCSVの実施に携わる。
CROへの移籍とそこでのシステム部門長としてのCSV文書レビュー等を経て、2020年よりシーエーシーに在籍。
同業界における経験を活かし、GxP適用のクラウド環境構築・運用サービスの立ち上げや、CSV支援サービスに携わり、現在に至る。

関連リンク：
Webサイト「Innovation Hub」に、株式会社シーエーシーのCSV支援サービスの記事が掲載中です。

皆様のお役に立てる情報を発信するため今後の参考にさせていただきたく、下記アンケートへのご協力をお願いできますと幸いです。
（所要時間：1〜2分程度）

なお、ご回答いただいた方には、2025年12月10日に実施いたしましたWebinarのオンデマンド配信を、一般公開に先立ちご視聴いただけるURLをご案内いたします。