第2回：理想を「要件」に変え、提案の「真実」を見抜く技術

前回の第1回コラムでは、システム導入のスタート地点として、現場の「困りごと」や「こうしたい」という生の声を広く集める「発散」のプロセスについて解説しました。
現場から集まったアイデアや希望は、プロジェクトを推進する貴重なエネルギーです。しかし、それらをすべてそのままシステムに詰め込もうとすれば、予算は膨らみ、スケジュールは遅延し、最終的には「元のパッケージ機能からかけ離れた、難解で複雑なシステム」が出来上がりかねません。
第2回となる今回は、膨らんだ希望を現実的な「要件」へと絞り込む「収束」のプロセス、そしてライフサイエンス業界特有の「規制遵守（コンプライアンス）」というフィルターをどのように通していくべきか、具体的な実務ステップを解説します。
 

━━━━

現場から集まった「あれもやりたい、これもやりたい」という要望リストは、そのままではベンダーに渡せる「要求仕様」にはなりません。まずはこれらを整理してURSの叩き台を作成し、ベンダーへ提案依頼を行うところまでが、収束プロセスの第一段階です。 

収束プロセスの第一歩は、集まったニーズの「仕分け」です。すべての要望をフラットに扱うのではなく、「Must（必須要件）」「Should（高優先推奨要件）」「Nice-to-Have（低優先推奨要件）」の3段階にメリハリを付けて分類します。

• Must（必須要件）：規制対応（GxP適合）に不可欠な機能、またはそのシステムを導入する主目的（手書き記録の廃止、二重入力の解消など）を達成する上で、代替運用が極めて困難または非現実的な機能。
   
• Should（高優先推奨要件）：業務効率化に大きく寄与するが、手運用や代替案でのカバーが一時的に可能な機能（例：他システムとの自動連携など）。
   
• Nice-to-Have（低優先推奨要件）：「作業時間が短縮できる」「画面が見やすくなる」といった、優先度は低いが、あれば利便性が向上する機能（例：画面の配色カスタマイズなど）。

この切り分けの際、現場からは「すべてMustだ」という反発がしばしば起こります。これを防ぐには、「もしこの機能がなかったら、どのような代替運用（ワークアラウンド）が可能か」という問いを立てることです。「手作業でカバーできるか」を検証し、リスクや業務負荷を踏まえて優先度の見直し（「Should」や「Nice-to-Have」への変更）を検討します。
この切り分けを曖昧にしたままベンダーに見積もりを依頼すると、過剰な提案（高額な見積もり）を招きます。プロジェクトの予算と期間は有限です。まずは「Must」だけでシステムが成立するかを検証する姿勢が重要です。

「ユーザー要求仕様書（URS：User Requirement Specification）」は、バリデーション（CSV）の起点となる重要文書です。これを「ベンダーが決まってから、ベンダーと一緒に作ろう」と考えていると、システム選定を正しく行うことができません。

構想段階の今、自社主導でURSの「叩き台」を作り始めるべき真の理由は、「自社の要求をベンダーに正確に示し、それに対する適否の回答を記入した『適合表』を提出してもらうため」です。自社の要求が明確であって初めて、ベンダーは自社製品で対応可能かどうかの正確な提案書を作成できます。

そのためには、URSにおける「言葉の曖昧さ」を可能な限り排除し、解釈のブレを減らすことが望まれます。例えば、「簡単にデータを出力できること」という曖昧な表現は、ユーザーにとっては「ボタン一つでExcel出力できること」であっても、ベンダーにとっては「CSVファイルとしてサーバーに保存されること」と解釈され、適合表に「対応可」と回答されてしまうかもしれません。このような認識のズレは、プロジェクト後半のテスト段階になって発覚し、設計のやり直しや追加費用の発生といった「ドミノ倒し」的な手戻りを引き起こします。

ベンダーに意図が伝わり、正確な適合表を回収するためのコツは、「何のために（Why）」「誰が（Who）」「何をしたいのか（What）」を客観的に測定可能な表現で記述することです。 例えば、「データ改ざんを防止するため（Why）、承認者が（Who）、画面上のボタン押下により監査証跡（オーディットトレイル）をCSV形式でエクスポートできること（What）」のように、背景にある意図と具体的な動作を言語化して記載します。具体的で研ぎ澄まされたURSこそが、精度の高いシステム選定と、プロジェクト後半の手戻り防止を両立させる鍵となります。

URSの叩き台ができたら、具体的なベンダーへのアプローチを開始します。 第1回の発散フェーズにおいて、広く浅く情報収集したシステムやベンダーのリストの中から、今回はさらに一歩踏み込み、「GxP領域での導入実績が豊富か」「自社の事業規模に適しているか」といった観点で、候補となるベンダーを3〜5社程度に絞り込みます。
候補を絞り込んだら、ベンダーに対して提案依頼（RFP：Request for Proposal）を行うのですが、この際、一般的なRFPのテンプレートをそのまま使うのではなく、「自分たちが作成したURS（要求仕様書の叩き台）」で自社の要求を伝えて提案を依頼するとともに、各要求事項に対する適否回答を以下の選択肢で求めて「適合表（Fit/Gap分析表）」とすることが実務上極めて有効なアプローチとなります。

• 標準機能（Out of the Box）で対応可能か
   
• 設定変更（コンフィグレーション）で対応可能か
   
• 追加開発（アドオン/カスタマイズ）が必要か
   
• 対応不可か

これにより、自社が求める要件に対して、各ベンダーの製品がどの程度適合しているかを同じ評価軸で比較評価するための「生きた情報」が手元に揃うことになります。
 

━━━━

ベンダーから提案書と適合表が届いたら、いよいよその内容の精査に入ります。GxP領域のシステム選定において、最初に通すべきフィルターは「データインテグリティ（DI：データの信頼性・完全性）」の担保と、現場の「使いやすさ」が両立しているかという視点です。適合表の「対応可」という回答を鵜呑みにせず、提案された仕様の「質」を評価するポイントを解説します。

「規制対応は必須ですが、そのために、操作手順や承認フローが極めて複雑になった」というのでは本末転倒です。操作が複雑であればあるほど、ユーザーは「裏道（非公式な手順、付箋への手書きメモ、アカウントの貸し借りなど）」を探そうとし、結果としてDIリスクが高まりかねません。
「使いやすさ（Usability）」は、単なる利便性の問題ではなく、誤操作や誤入力を防ぎ、DIを担保するための重要な要素です。 例えば、タブレット端末での入力を想定した大きなボタン配置、直感的なワークフロー表示、バーコードリーダーを用いたロット番号の自動入力などは、操作ミスを物理的に防ぎます。見やすい画面設計（視認性）とシンプルな操作性は、手順通りの正しい運用を現場に定着させる上で、極めて重要な評価ポイントとなります。どのような画面で、どういった操作をするのかまで、提案書に細かく記載されることは少ないですが、システムの使いやすさは常に留意すべきです。

GxPシステムでのデータインテグリティは、データが「作成」されてから「保管」「廃棄」されるまでのライフサイクル全体で担保される必要があります。提案書を精査する際、新規入力時の制御以上に厳しくチェックすべきなのが、データの「変更（修正・上書き）」が発生した際のシステム挙動です。
一度確定したデータを安易に書き換えられるシステムは、データの信頼性を著しく損ないます。提案書や仕様書から、データ変更プロセスにおいて以下の3つの必須要件がシステム的に制御されているかを見極めます。

• 変更権限の厳格な制御：データの変更が、あらかじめ許可された特定のユーザー（権限を持つ作業者や管理者）にのみ制限されているか。誰でも自由に修正できる仕様になっていないか。
   
• 変更理由の入力制御：データを修正する際、変更理由の記録が適切に行われる仕組み（クリティカルなデータ変更における理由入力の必須化など）が備わっているか。
   
• 変更前後の値（新旧値）の保存：変更前の値（旧値）が上書きされて消えてしまうのではなく、変更前の値、変更後の値（新値）、そして変更日時と実行者がセットで保存される仕様になっているか。 

適合表で「データ修正可能」とだけ書かれている場合、それが単に「上書き保存ができる」という意味なのか、それとも上記のような「厳格な変更プロセスをシステムが強制する」という意味なのか。提案書に記載されたデータ変更時の画面遷移やワークフローの記述から、その実装レベルを厳しく評価する必要があります。

このようなデータ変更プロセスを担保するために、以下の機能は、GxPシステムにおいて中核となる重要な要素です。

• アクセス権限管理：誰がどの操作を行えるかを明確に区分する（例：作業者、承認者、システム管理者）。「全員が共通のアカウントでログインする」といった運用は、トレーサビリティの観点から避けるべきとされています。原則的には個人に紐づくユニークなIDでのログインが必要です。
   
• 監査証跡：「いつ、誰が、何の操作をしたか」「いつ、誰が、どのデータを、どのように変更したか（変更前後の値）」といった情報が自動的に記録され、同時に「その操作の理由」の入力を求めることで、痕跡なく削除や改ざんができないことが求められます。 

ここで実務上見落としがちなのが、「監査証跡をどのようにレビュー（確認）するか」という要件です。ただ記録が残るだけでは不十分で、「レビュワーや承認者が、日々の膨大な監査証跡の中からクリティカルな変更（データの修正・再測定・削除など）を容易にフィルタリング（絞り込み）し、日常業務の中で形骸化せずに点検できる仕様になっているか」という点までURSに含めておく必要があります。可読性の低いシステムログがサーバー上にテキストファイルとして出力されるだけでは、監査証跡としての実効性に乏しく、日常的な点検業務が形骸化するリスクがあるためです。
 

━━━━

導入時に必要となるCSV（コンピュータシステムバリデーション）の実施規模やドキュメント量を決定する上で、世界的なデファクトスタンダードとなっているのが「GAMP 5」です。この中の「ソフトウェアカテゴリ」を正しく理解することは、プロジェクトのコストと期間をコントロールする上で極めて重要です

GAMP 5では、ソフトウェアをその複雑度やカスタマイズの度合いに応じて、主に以下のカテゴリに分類しています。

• カテゴリ1： インフラストラクチャ・ソフトウェア（OS、データベース管理システムなど）
   
• カテゴリ3： ビジネスプロセスに適合させるための環境設定（構成設定）ができないソフトウェア製品（標準的なパッケージソフト、分析機器に付属の解析用ソフトウェアなど）
   
• カテゴリ4：構成設定ができるソフトウェア製品（ユーザー固有のビジネスプロセスやワークフローに合わせて設定変更を行うERP、LIMS、MESなど）
   
• カテゴリ5： カスタム（個別開発）アプリケーション（自社専用にゼロから開発したプログラム、マクロなど）

カテゴリの数字が大きくなるほど、システムとしての複雑度が増し、設計誤りや実装ミス（バグ）が混入するリスクが高まるため、必要な検証（バリデーション）のボリュームも指数関数的に増加します。

よくある誤解は、「導入するシステムがLIMSだから、システム全体がカテゴリ4だ」と一括りで考えてしまうことです。 実際には、システムは複数の機能やモジュールで構成されています。
例えば、標準機能のまま使うマスタ管理部分は「カテゴリ3」、自社の承認フローに合わせて設定変更（コンフィグレーション）するワークフロー部分は「カテゴリ4」、どうしても標準機能で対応できずにアドオン開発する帳票出力部分は「カテゴリ5」といったように、機能やモジュール単位でカテゴリを切り分けてリスク評価を行うのが実務的なアプローチです。
実務では、このカテゴリ分類をもとに「リスクアセスメント」を実施し、バリデーションの方針を決定します。リスクの低い（カテゴリの低い）部分の検証はベンダーの検証資産を活用して自社の作業を合理化し、リスクの高い（カテゴリの高い）部分に実効性のある検証（クリティカルシンキングに基づくテスト）にリソースを集中させることで、全体の検証コストを最適化しつつ、規制適合性を担保します。

パッケージシステムを導入する際、「今の業務フローを変えたくないから」といった理由で現場の強い要望に押されて「個別カスタマイズ（カテゴリ5の開発）」を安易に行ってしまうケースが後を絶ちません。
パッケージをベースにした導入で、業務要件に合わせた個別カスタマイズを一切なくすことは困難である一方、以下のような相応のリスクや負荷を抱えることになるため、必要性の度合いやリスクを踏まえて、慎重に判断するべきです。

• 設計から検証に至る説明責任の多くを自社で負うことになる：パッケージの標準機能（カテゴリ3や4）であれば、ベンダーが実施した検証結果を一定程度活用できます。しかし、自社専用に個別カスタマイズした部分（カテゴリ5）については、仕様の妥当性から検証、変更時の影響評価に至るまで、自社主導で規制当局に対する説明責任を果たす必要が生じます。
   
• 変更管理の肥大化と保守費用の高騰：カスタマイズ箇所が増えれば増えるほど、システムの維持管理コスト（保守費）は跳ね上がります。さらに深刻なのは、導入後の「変更管理（Change Control）」の負担です。システムの一部を少し変更するだけでも、カスタマイズ部分への影響評価が極めて複雑になり、ささいな修正であっても膨大な再検証が必要になることが想定されます。
   
• システムのブラックボックス化と「ベンダーロックイン」のリスク：自社専用にカスタマイズしたプログラムは、開発を担当した特定のベンダー（さらに言えば、そのベンダーの特定の開発担当者）に強く依存することになります。将来、トラブル対応や軽微な修正が必要になった際、ベンダーの提示する保守費用を負担し続けるリスクが生じます。また、もしベンダーから当初の開発担当者がいなくなれば、システムが完全にブラックボックス化し、不具合が発生しても誰も原因を究明できないという致命的なリスクを抱える可能性も拭えません。

このような落とし穴を回避するためには、検討しているシステムのベンダーが、どのような方針で製品を提供しているのか、その設計思想の違いを正しく理解する必要があります。
ベンダーの中には、ユーザーの要望に対して安易に「ソースコードを書き換えて（アドオン/カスタマイズで）実装します」と回答してくるケースが多々あります。しかし、これは実質的に「自社専用の特注品（カテゴリ5）」を作っているのと同じです。 一方で、プログラム本体（ソースコード）には一切手を加えず、システム内のパラメータやマスタの設定を変更する「構成設定」によって、業務フローや画面表示を柔軟に変更できる設計のパッケージも存在します。これであれば、ベンダー側で検証済みの標準機能をそのまま使うため、カテゴリ4の範囲に収まり、CSVの負担も最小限で済みます。
ソースコードを書き換える「カスタマイズ」は、業務都合上どうしても標準機能ではフィットしないケースに限定し、基本はシステムの「構成設定」の範囲内で運用するか、あるいは業務フロー側をシステムの標準機能に合わせる決断をすることが、長期的にはプロジェクトのリスクを抑え、ライフサイクルコストを最適化するための賢明なアプローチと言えます。
 

━━━━

入手した提案書と適合表を、規制適合やGAMPカテゴリのフィルターにかけて机上評価すると、各システムの特徴や課題、そして「本当にこの通りに動くのだろうか」という疑問点が見えてきます。ここから、ベンダーヒアリング（デモ）を通じて、それらを実証するフェーズへと進みます。

ベンダーから提供された適合表をもとに、まずはプロジェクトチームで「自力評価（机上査定）」を行います。 この段階でのスクリーニングのポイントは、URSの「Must要件」に「対応不可」がないか、また「個別カスタマイズ（カテゴリ5）」を前提とした回答が多くないかをチェックすることです。

Must要件を満たせないシステムや、自社の業務に合わせるために大量のソースコード改修を提案してくるシステムは、導入後のリスクや検証コストを考慮し、評価を慎重に行う必要があります。場合によってはこの段階で評価を下げる判断も行います。一方で、机上評価を通じて、ヒアリングとデモを依頼すべき本命の候補を絞り込みます。ヒアリングの段階では、ライフサイエンス業界特有の事情やCSVについてのベンダーの理解度も併せて評価できるとよいです。

候補を絞り込んだら、すぐにベンダーを呼ぶのではなく、提案書を読み込む中で生じた疑問点や、適合表の「標準機能で対応可能」という回答の裏付けをとるための「質問リスト（確認事項リスト）」を事前に作成します。

例えば、「監査証跡の自動記録」について、「標準機能で対応可」と書かれていても、「具体的にどのような操作がトリガーとなって記録されるのか」「変更理由の入力画面はどのようにポップアップするのか」「監査証跡閲覧時の日時の範囲設定や特定操作の絞り込みは可能か」といった、実務上の運用イメージが湧かない部分はすべて質問事項として洗い出します。このリストを事前にベンダーに送付しておくことで、ヒアリング当日に「持ち帰り回答」になるのを防ぎ、限られた時間で深いディスカッションやピンポイントでのデモを行うことができます。 

ベンダーを招いてのヒアリング（デモンストレーション）は、プロジェクトチームだけでなく、QA（品質保証）部門の担当者も交えた「評価チーム」で実施します。ここでの最大のポイントは、ベンダーの営業トークや用意されたスライド資料を一方的に聞く場にしないことです。事前に送付した質問リストに基づき、実機デモが可能であれば「実際のシステム画面」を操作してもらいながら、ユーザー目線で確認します。

• 監査証跡の閲覧機能：「DI対応の監査証跡は、具体的にどのような画面で、どのように確認・レビューできるか」を説明してもらう。
   
• 入力エラー時の挙動：「入力エラーが発生した際、どのような警告が表示され、それがどのように記録されるか」を、実際にわざとエラーを起こした例で示してもらう。
   
• アクセス権限の分離：「ユーザーアカウントと役割（ロール）に応じたアクセス権限の分離（例：作業者、承認者、システム管理者でメニューや操作権限がどう変わるか）」が、実際の画面上でどのように制御され、設定変更できるかを確認する。

こういった、規制適合と使いやすさの核心部分を、実機デモとベンダーとの質疑応答を通じて詳細に検証します。ベンダーの「できます」という言葉を鵜呑みにせず、実際の動作とエビデンスを客観的に確認する姿勢を持つことが、実効性の高いシステム選定につながる重要なアプローチです。
 

━━━━

第2回では、現場のニーズをURSへと収束させてベンダーへ提案依頼を行い、入手した提案書（適合表）に対してデータインテグリティやGAMPカテゴリといった規制適合のフィルターをかけて机上評価するプロセス、そして候補を絞り込んでヒアリングやデモを通じて実際の挙動を検証するステップまでを解説しました。

最終回となる第3回では、いよいよ構想フェーズの総仕上げである「システム選定（適格性評価）」に踏み込みます。 主観や金額だけに頼らず、機能・規制・運用の3軸で評価する「選定基準」の考え方や、トライアル環境を用いた「業務シナリオ評価」の進め方、さらにはリスク視点での評価方法を解説します。また、ベンダー見積ではうっかり見落としがちな「総保有コスト（TCO）」の罠や、査察に耐えうる「評価選定報告書」の作成、そして経営層にシステム導入の必要性を説明するロジックまで、構想フェーズを完璧に締めくくり、導入プロジェクトへと確実にバトンを繋ぐための意思決定プロセスを余すところなくお届けします。どうぞご期待ください。

著者紹介

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

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