第1回：業務の理想像を描く「発散」と、GxP前提の理解

株式会社シーエーシーにてCSV支援サービスを担当しております。昨年のCSVをテーマとしたコラムに引き続き、今年もアガサ様とのコラボでコラム連載を開始いたします。全3回で「構想フェーズ」に焦点を当てた内容とする予定です。GAMP5のようなCSVガイドラインでも、導入プロジェクトの前段階に構想フェーズを置くことを推奨されていながら、その内容やベストプラクティスにまでは踏み込まれていませんが、このコラムでは私たちがお客様のシステム選定をご支援した経験も踏まえ、何をするべきなのかをご理解いただける内容を目指してまいります。どうぞご期待ください。

本コラムは、医薬品のGxP領域におけるシステム選定を初めて任された担当者様に向けて、具体的な進め方を解説する実践的なガイドです。CSV（コンピュータ化システムバリデーション）を含む導入プロジェクトを成功に導くには、システムを選ぶ前段階である「構想フェーズ」での準備が極めて重要です。本連載では、業務の理想を描く段階から、規制要件やデータインテグリティを踏まえて最終的な評価選定に至るまで、行うべきタスクの指針となるよう解説するものです。

第1回となる今回は、構想フェーズをどのような形で始めるのか、業務とシステムに求める理想と押さえるべき現実の規制要件をどう踏まえるのかについて解説していきます。
 

━━━━

システム導入の成否は、実はシステムを選ぶ前の「準備」で決まります。なぜ多くのプロジェクトが後々CSVの対応に追われ、予算やスケジュールをオーバーしてしまうのか。その根本原因を探りながら、最初期に行うべき「期待の言語化」の重要性を紐解きます。 

医薬品の製造業や製造販売業において、業務のデジタル化やシステム刷新は避けて通れないテーマです。生産管理（ERP/MES）、試験室情報管理（LIMS）、文書管理（DMS）、品質イベント管理（QMS）など、検討すべきシステムは多岐にわたります。

しかし、こうしたシステム選定プロジェクトのリードを任されるのは、必ずしもITの専門家ではありません。多くの場合、製造、品質管理、品質保証といった、日々の実務を担う現場のキーパーソンが突然担当者に指名されます。

「システムのことはよくわからないのに、どう選べばいいのか」 「GxPやCSVという言葉は知っているが、選定段階で何をすべきか見当もつかない」

このような不安を抱えるのは当然です。多くのシステムを有し、豊富にノウハウが蓄積されているグローバル大手ならともかく、多くの製薬企業においてGxPシステムの選定は「数年に一度」のイベントであり、社内に経験豊富な有識者がおらず、最新のノウハウが蓄積されていないのが一般的です。本コラムは、こうした「初めてシステム選定を任され、何から手をつければよいか戸惑っている担当者」が、自信を持ってプロジェクトを進めていただけるようにするための実践的なガイドです。

GxP領域のシステム導入で避けて通れないのが「CSV（コンピュータ化システムバリデーション）」です。多くのプロジェクトにおいて、CSVは「システム構築後に、膨大な文書を作成する負担の大きい作業」と捉えられがちです。

「検証の最終段階で、QA（品質保証部門）から『要件の根拠は何か』『なぜこのテストが必要なのか』と問われ、辻褄合わせの文書作成に追われた」 「稼働直前になって規制要件を満たしていない致命的な欠陥が見つかり、追加開発が発生して予算もスケジュールもオーバーした」

こうした事態が起こる根本原因は、CSVそのものの難しさではなく、システムを「選ぶ前」の段階、すなわち「構想フェーズ」における準備不足にあるとも言えます。

CSVの本質は、システムが「意図した用途（Intended Use）に適合していること」を検証し、文書化することです。「意図した用途」が明確に定義されていなければ、何を検証すべきかも決まりません。構想フェーズで業務ニーズと規制要件（GxP）が整理されないままシステムを選定してしまうと、後続のバリデーションで迷路に迷い込む可能性があります。CSVをコントロールできるかどうかは、この構想フェーズの成否にかかっているのです。

システム選定が始まると、多くのチームがすぐに「ベンダーへの見積依頼」や「製品カタログの比較」に走ってしまいます。特にコスト削減の圧力が強い環境では、金額面での比較が先行しがちです。

しかし、これは後々の手戻りを生みやすいアプローチです。自社が「そのシステムを使って、どのような業務を実現したいのか」が言語化されていない状態でもらう見積もりは、要件のズレによって後から金額が大きく変動する可能性があり、正確な比較が難しくなるからです。

金額の比較を始める前に、まずは業界向けシステムの情報収集も交えながら、「業務の棚卸し」と「期待の言語化」を進めることが重要です。

• 現在の業務フローはどうなっているのか（As-Isの把握）
   
• どのような課題（無駄、ミス、遅延など）が発生しているのか
   
• システムを導入することで、業務はどう変わるべきなのか（To-Beの描き出し）

これらを徹底的に洗い出し、関係者間で合意を形成することが先決です。この「期待の言語化」が不十分なままシステムを選定すると、ベンダーの華やかなデモや「業界シェアNo.1」といった言葉に惑わされ、自社の業務プロセスに全く適合しないシステムを導入してしまうことにもなりかねません。金額の比較は、自社としての要求事項を定義し、候補システムがそれを満たしていることを確認した「後」に進めるべきステップです。
 

━━━━

医薬品の品質や安全性に直結するシステムを導入する際、一般的なITシステムと同じ感覚で選定を進めることはできません。GxP領域において信頼性の根幹をなす「データインテグリティ（DI）」の基本原則と、各種のCSVガイドラインが求める「意図した用途への適合」について、その本質を整理します。

一般的な企業のITシステムの導入では、「業務効率化」「コスト削減」「使いやすさ」が重視されます。もちろん一般的なITシステムでも不具合は避けるべきですが、GxP適用システムと比較した場合、その影響の性質が異なります。一般システムでは業務の継続性やコスト対効果が主な評価軸となりますが、GxP領域では「製品の品質」や「患者の安全性」に直結するため、不具合に対する許容度が極めて厳しく制限されます。

したがって、GxP適用システムでは、効率性や利便性よりも先に、「製品の品質（Quality）」「患者の安全性（Safety）」とそれを支える「データの信頼性（Data Integrity）」に対するリスクが最小化されていることが最優先で求められます。

一般のシステムであれば「使いにくいから運用でカバーしよう」で済む問題も、GxP領域では「その運用でのカバーによって、データ改ざんや誤入力のリスクが高まらないか」という評価が必要になります。この「規制遵守（コンプライアンス）」という厳格なフィルターが存在することこそが、GxPシステム選定の特殊性です。

近年のGxP査察において、主要な着眼点の一つとなっているのが「データインテグリティ（DI：データの信頼性・完全性）」です。医薬品が承認された規格通りに正しく製造・試験されているかを証明する客観的な証拠となるのが「記録（データ）」だからです。

データインテグリティの基本原則として、よく知られているのが「ALCOA+（アルコアプラス）」です。

• Attributable（帰属性）：誰が作成・変更したデータか明確であること
   
• Legible（判読性）：記録が恒久的に読める状態であること
   
• Contemporaneous（同時性）：行為と同時に記録されること
   
• Original（原本性）：コピーではなく、最初の記録（生データ）であること
   
• Accurate（正確性）：エラーや改ざんがなく、正確であること
   
• Complete（完全性）：すべてのデータ（メタデータや監査証跡を含む）が揃っていること
   
• Consistent（一貫性）：時系列やプロセスに矛盾がないこと
   
• Enduring（恒久性）：規定された保存期間中、劣化せずに保存されること
   
• Available（利用可能性）：必要な時にいつでも閲覧・取り出せること 

GxP領域に使用するシステムを選定する際、ALCOA+の要件をどのように満たすかの評価は必須です。ここで重要なのは、ALCOA+はシステムの機能（技術的対策）だけで満たされるものではなく、それを正しく使うための運用や管理方法（手順書の整備、教育訓練などの運用的対策）と組み合わさることで、初めて確保される原則であるという点です。

しかし、システム側に必要な機能が欠けていると、いくら運用ルールを厳しくしてもデータインテグリティを担保しきれません。例えば、「アカウント権限のReadとWriteを分けられないシステム」は、運用だけでアクセス制限をかけようとしても限界があり、誰でもデータが書き込めてしまうため、正確性や一貫性を満たせず、GxP領域で採用するには大きなリスクが伴います。また、「監査証跡やデータの修正履歴が自動で残らないシステム」も、人の運用管理だけで正確性や完全性を担保することは極めてハードルが高いため、避けるべきです。

どんなに機能が豊富で使いやすく、なおかつ安価なシステムであっても、システム機能と運用の両面からデータインテグリティを担保できる見通しが立たなければ、GxP領域への適用は困難です。システム選定の初期段階から、こういった視点を持っておくことは、後々の手戻りを防ぐために極めて重要です。

製薬企業は、薬機法に基づく各種省令（GMP、GQP、GVP省令など）を遵守する義務があります。そして、これらの省令の下には、コンピュータシステムに特化したガイドラインが存在します。日本においては、厚生労働省の「医薬品・医薬部外品製造販売業者等におけるコンピュータ化システム適正管理ガイドライン」がこれに該当します。また、グローバルなデファクトスタンダードとしては、ISPE（国際製薬技術協会）が発行している「GAMP 5」があります。

これらのガイドラインが共通して求めているのは、システムが「意図した用途（Intended Use）に適合していること」です。

これは、自社の特定の業務プロセスにおいて、そのシステムがどのように使われ、どのようにリスクをコントロールするのかが明確であり、その目的に対してシステムが正しく機能することを検証（バリデート）しなさい、ということです。「高機能で高価なシステムを買えば安心」ということにはなりません。

したがって、システム選定のスタートラインは、「CSVの対応実績があるとベンダーが主張するシステムを探すこと」ではなく、「自社の『意図した用途』とは何かを定義すること」でなければなりません。
 

━━━━

構想フェーズのスタートにおいて、最初から予算や規制の制約に縛られる必要はありません。まずは現場の「やりたいこと」を自由に膨らませ、理想の業務像を描くことから始めます。現場の課題を視覚化し、市場にあるシステム候補を広く洗い出すプロセスを解説します。

ここまで述べたように、GxPシステムならではの様々な前提や制約はありますが、構想フェーズの初期段階において、最も重要なのは「発散（アイデア出し）」です。この段階では、GxPの規制要件や予算の制約、あるいは「今のシステムではできないから」といった既存の枠組みを一度すべて取り払い、自由な発想で「理想の業務像」を描くことが求められます。

最初から「GxPに適合しなければならない」「予算はこれだけしかない」といった制約を意識しすぎると、現場から出てくる意見は「今のシステムのここを少し改善したい」といった、極めて視野の狭いマイナーチェンジに留まってしまいます。これでは、せっかく多額の投資をしてシステムを刷新する意味がありません。

「もし、何の制約もないとしたら、どんな業務の進め方が理想か」 「毎日行っているあの二重チェックや、紙からの転記作業がすべて自動化されたら、どれだけ楽になるか」 「試験結果がリアルタイムで承認者に届き、その場で承認できたら、リードタイムはどれだけ短縮できるか」

実現の可否はさておき、業務面から「何ができるようになりたいか」をポジティブに膨らませていくことが、プロジェクトに活気を与え、真に価値のあるシステム導入へと繋がります。

「発散」を単なる絵に描いた餅に終わらせないためには、現場の「困りごと（ペインポイント）」を具体的に洗い出し、それを解決した「理想のワークフロー」を視覚化することをお勧めします。

この作業を進める際に有効なのが、「業務フロー図（スイムレーン図）」の作成です。縦軸に「担当者」や「システム」、横軸に時系列で業務の流れを書き出していきます。

• 現状（As-Is）の視覚化：現在の業務フローを書き出し、「どこで紙が発生しているか」「どこでデータの二重入力が発生しているか」等を記入し、現場が抱える「真の困りごと」を浮き彫りにします。
   
• 理想（To-Be）の視覚化：次に、システム導入によってそれらの課題が解決された「理想の業務フロー」を描きます。「このプロセスはシステムが自動で処理する」「この承認はモバイル端末から行えるようにする」といった具合に、システムに期待する役割を明確にしていきます。 

このように視覚化することで、プロジェクトメンバー間だけでなく、後にベンダーへ要件を説明する際にも、極めて強力なコミュニケーションツールとなります。 

自社の「理想の業務像」が見えてきたら、次はその理想を実現してくれそうな「世の中のシステム候補」を広く浅く洗い出す情報収集フェーズに入ります。

この段階では、特定のベンダーに絞り込む必要はありません。インターネット、業界誌、展示会への参加、あるいは他社での導入事例などを参考に、自社の対象業務に対応するシステム（例：LIMS、DMS、MESなど）をリストアップしていきます。

情報収集のポイントは、「自社の理想（To-Be）と、各システムのコンセプトが合致しているか」を大まかにつかむことです。

• そのシステムは、自社と同じ「医薬品業界」での導入実績が豊富か（業界特有の規制をベンダーが理解しているか）
   
• クラウド型（SaaS）が主流なのか、オンプレミス型（自社サーバー設置）なのか
   
• 自社が望む「自動化」や「測定器との連携」の機能を標準で持っていそうか

この段階では、詳細な機能比較や見積もりの取得は不要です。まずは「どのような選択肢が市場に存在するのか」の全体像（ロングリスト）を把握し、次のステップである「絞り込み」のための材料を揃えることが目的となります。
 

━━━━

広く集めたアイデアやシステム候補を前に、プロジェクトを現実的な形へと進めるための「初期評価」を行います。膨らんだ理想に境界線を引くスコープの整理から、他システムとの接続性、そしてプロジェクト化（予算化）へ進むための最終判断基準まで、最初の関門となる実務ステップを解説します。

3章で現場の「やりたいこと」を自由に膨らませ、市場のシステム候補を広く洗い出した後、最初に行うべきは「理想と現実の境界線」を引き始める作業、すなわち「システム化範囲（スコープ）の整理」です。

現場から出たアイデアをすべて一度に実現しようとすると、プロジェクトの規模が膨れ上がり、コストやスケジュールの面で破綻を招きます。特にGxP領域では、システム化の範囲が広がるほど、バリデーション（CSV）の検証範囲も指数関数的に増大するため注意が必要です。

そのため、この段階で「今回のプロジェクトで絶対に実現すべき範囲（フェーズ1）」と「将来的に対応を検討する範囲（フェーズ2以降）」を区別します。例えば、コアとなるデータ管理機能と他システムとの自動連携は初期導入を必須とし、高度な分析機能は次期フェーズに回す、といった判断です。これは次段階で行う要求仕様にも反映されていくものです。

このスコープ整理により、プロジェクトの現実的なゴールが定義され、後続の接続性評価や予算化の判断を、地に足のついた形で進めることが可能になります。

システムを単体で導入することは稀であり、多くの場合、既存の他システム（基幹ERPやActive Directoryなど）や、試験室の測定機器（天秤、HPLCなど）との接続、データ連携が発生します。

構想フェーズにおいて、この「接続性（インターフェース要件）」の評価は極めて重要です。なぜなら、システム間のデータ連携部分は、データインテグリティ上の最大の弱点になりやすいためです。

また、ここで強く意識すべきは、「サービスや製品の標準機能の活用を基本とし、個別カスタマイズについてはその必要性とリスクを踏まえて慎重に評価・判断する」という姿勢です。 個社ごとの既存の業務プロセスや利用機器にシステムを完全に合わせようとすると、ソースコードレベルでのプログラム修正を要する（GAMPカテゴリ5に該当する）「アドオン（追加開発）」や「カスタマイズ」での対応が多くなりがちです。ただし、GxP領域におけるカスタマイズは、開発コストや保守コストを跳ね上げるだけでなく、そのカスタマイズ部分は「自社特有の要件に対して責任を持ってバリデーションを行わなければならない」という、相応の負担を伴います。

したがって、まずは標準機能でどこまで業務が回せるかを検討し、どうしても必要な部分に絞って個別対応を検討する、あるいは運用でカバーするといった、メリハリのある判断が求められます。システムベンダーがどのようなアプローチで個社ごとの要件の違いを吸収する方針なのか（設定変更で対応できるのか、個別開発になるのかなど）を評価しつつ、「現行業務をどこまで維持し、どの部分をシステムに合わせて変更するか」をこの構想段階から整理し、最適な運用プロセスを検討しておくことが、プロジェクトの成否を分ける鍵となります。 

構想フェーズの締めくくりとして、集まった情報と初期アセスメントの結果をもとに、あらためて「このプロジェクトを本格的に推進（予算化・プロジェクト化）すべきか」の意思決定を行います。導入に向けて評価選定を進める旨は、この時点で経営層と合意できているべきです。

この判断基準は、単に「システムが良さそうだから」という曖昧なものではありません。以下の3つの軸で、プロジェクトの実現可能性（フィージビリティ）を客観的に評価します。

• 業務的価値（ベネフィット）： システム導入によって、現場のどのような課題が解決され、どのような定量的・定性的効果（ミスの削減、リードタイム短縮、ペーパーレス化による省力化など）が得られるか。
   
• 規制適合性（コンプライアンス）： 現状の「紙と手作業」によるデータインテグリティ上のリスクが、システム導入によってどのように低減されるか。（規制当局に対する説明性・適合性をどれだけ向上できるか）
   
• リソースと実現性（フィージビリティ）： 自社にプロジェクトを推進する体制（業務部門、IT部門、QA）が整っているか。また、想定されるバリデーション工数に対して、現実的なスケジュールが組めるか。
   

特にGxP領域においては、「コンプライアンス上のリスク低減」が、投資の最大の動機（ドライバー）になることが多々あります。「現状の運用におけるデータインテグリティ上のリスクを低減し、コンプライアンスをより確実なものにする。そのためにシステム化が必要である」というロジックは、経営層に対して予算獲得を働きかける際、非常に説得力のある根拠となります。

これらの評価を行い、会社全体として「進むべき」という確証が得られて初めて、プロジェクトは次の「要求仕様の作成着手」および「ベンダーの評価選定」という具体的な実行フェーズへと進むことができるのです。
 

━━━━

システム導入の「構想フェーズ」は、一見すると地味で、時間ばかりがかかるプロセスに見えるかもしれません。しかし、この段階で「自社が何を実現したいのか（業務要件の発散）」を明確にし、同時に「GxP領域として何を守らなければならないのか（前提条件の理解）」を整理しておくことは、プロジェクト全体の運命を決定づけます。

急がば回れ。金額の比較やベンダーとの交渉に飛びつく前に、まずは自社の足元を見つめ直し、理想の姿を描くことから始めてみましょう。
 

次回（第2回）は、今回「発散」させた現場の希望を、規制適合のフィルターにかけながら、ベンダーに伝わる具体的な「ユーザー要求仕様書（URS）」へと「収束」させていくプロセスを詳しく解説します。データインテグリティを担保するための必須機能や、検証ボリュームを左右する「GAMPカテゴリ」の考え方など、より実務に踏み込んだ内容をお届けします。

著者紹介

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

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