製薬業界におけるデジタルトランスフォーメーションは、多くの場合、小さなことから始まります。例えば、記録帳の置き換え、手作業による入力の削減、データの可視性の向上などです。しかし、技術の柔軟性が高ければ高いほど、成功は新たな課題を生み出します。当初は限定的なプロジェクトとして始まったものが、あっという間にはるかに大規模なものへと拡大してしまうのです。
「Operations Calling」では、Jazz Pharmaceuticalsのジェイソン・ギレスピー氏が、ログブックのデジタル化プロジェクトが、どのようにしてエンドツーエンドの生産実行プログラムへと発展していったかについて語りました。チームが実現の可能性を実感するにつれ、対象範囲は拡大し、アプリやプロセスの数が増え、目標もより高いものへと広がっていきました。
このブログでは、彼らがその拡張を管理するために用いた手法について詳しく解説します。具体的には、作業範囲をどのように定義し、プラットフォームの検証とプロセスのガバナンスを分離し、早期にQAを連携させ、柔軟性を活かして、制御不能なスコープの拡大ではなく、構造化されたスケーラブルな変革を実現したかについてお話しします。
GxP において、柔軟性は諸刃の剣です
柔軟性の高いプラットフォームを使えば、開発が容易になり、チームがその可能性を実感すれば、勢いは急速に高まります。
Jazzでは、当初の目標は単純なものでした。それは、航海日誌をデジタル化することです。しかし、各チームが実際にシステムを体験してみると、その意欲は高まりました。新たな活用事例が次々と生まれ、対象となる業務プロセスも拡大していきました。
「当初は10個のアプリを導入するだけだと思っていました……ところが、その数は倍になりました。その過程で、183件の改善案が浮上しました。」 — ジェイソン・ギレスピー、ジャズ・ファーマシューティカルズ、デジタル・エンタープライズ・ケイパビリティーズ・ビジネス・パートナー。
これは失敗の兆候ではありませんでした。そのアプローチが功を奏している証拠だったのです。
課題は、拡大を制限することではありませんでした。それは、拡大の仕組みを整えることでした。
GxP においては、新しいワークフローが導入されるたびに、バリデーションやガバナンスに関する検討が必要となります。Jazzは、バリデーション、所有権、およびリリースに対する管理を維持しつつ、プラットフォームの価値を最大化しながら、その需要を意図的に拡大する方法に焦点を当てていました。
柔軟性はリスクを生み出したわけではありません。それはチャンスを生み出したのです。重要なのは、そのチャンスを、計画的で管理された拡大へと確実に結びつけることでした。
柔軟性の高いプラットフォームなら、構築も簡単です。拡張も容易になります。チームが可能性を実感すれば、アプリの増加、プロセスの拡充、そしてさらなる野心とともに、その規模も拡大していきます。
ステップ1：技術の範囲を定める前に、問題の範囲を明確にしましょう
技術の詳細やその可能性に目を奪われてしまいがちです。チームが一歩引いて、最も差し迫った課題を理解すれば、その業務範囲において大きな効果をもたらす解決策を計画しやすくなります。
プロジェクトのロードマップを承認する前に、その取り組みによって何を改善するつもりなのかを明確にし、その基準を明示してください。
拡張については、運用への影響を踏まえて評価すべきです：
手作業をなくし、時間を節約しましょう
品質レビューの所要時間を短縮する
ばらつきを減らす
実用的なデジタルデータを活用できるようにする
これらの優先事項が判断基準となります。新しいユースケースは、以下の点について厳しく検証されなければなりません。これは私たちにどのような効果をもたらすのでしょうか？プロセスをどのように変革するのでしょうか？どのようなメリットがあるのでしょうか？答えが明確でない場合は、進めるべきではありません。
規制の厳しい環境では、ワークフローが追加されるたびに、検証とガバナンスの責任が増大します。成長は当然のこととして想定するのではなく、その正当性を立証する必要があります。まずは目的の範囲を明確に定義し、実証された価値に応じてシステムの導入範囲を拡大していくべきです。
ステップ2：業務を「プラットフォーム」「プロセス」「ガバナンス」に分類する
製薬製造におけるデジタルトランスフォーメーションが進むにつれ、複雑さはアプリそのものから生じるのではなく、責任の所在が不明確であることに起因しています。
ライフサイクルの管理は誰が担当しますか？
誰が何を検証しますか？
リリースの承認は誰が行いますか？
検査の際、誰が責任を負いますか？
早い段階でそれらの答えが明確でなければ、事業拡大のペースが鈍化したり、さらに悪い場合には、自信が失われてしまいます。
拡張性の高いモデルでは、作業を3つの明確なコンテナに分割します。
Platform
アーキテクチャを一度だけ定義します。アプリケーションの構造、バージョン管理、移行、および環境間の管理方法を定義します。導入当初から拡張性を考慮した構築を行います。
メリット：新しいワークフローが追加されるたびに、アーキテクチャの再検証を行う必要がなくなります。
プロセス
ワークフローをデジタル化する前に、その有効性を検証し、再設計してください。紙ベースの非効率性をソフトウェアにそのまま持ち込まないようにしましょう。デジタル化を機に、手順を簡素化し、冗長なチェックを排除し、業務の進め方を標準化してください。
メリット： 手戻りを減らし 、検証の過程で隠れたエッジケースが表面化するのを防ぎます。
ガバナンス
プラットフォームのガバナンスとプロセスの検証を分離します。デジタルQAはプラットフォームを検証し、ライフサイクル管理を定義します。サイトQAはプロセスの文脈においてアプリケーションを検証し、最終リリースを管理します。
メリット：QAが権限を維持し、検査対応態勢が維持され、範囲が拡大しても責任の所在が明確になります。
これらの流れは並行して進むことができます。ただ、一つに統合されてはいけません。その結果は理論的なものではありません。実用的なものです：
アプリの展開を迅速化
検証の負担を軽減する
検査報告書の概要
制御された拡張
構造こそが、混乱を招くことなく柔軟に拡張することを可能にするものです。
ステップ3：デジタル化を業務プロセスの再設計と捉える
デジタル化は、設定から始めるべきではありません。疑問を投げかけることから始めるべきです。
製薬製造におけるデジタルトランスフォーメーションで最もよくある間違いの一つは、既存のSOPをそのままソフトウェアに反映させてしまうことです。一見、効率的であり、慣れ親しんだ手順を維持できるように思えます。しかし、それによって非効率性や冗長性、さらには文書化されていない回避策までもがそのまま残されてしまうのです。
アプリケーションを構築する前に、そのプロセス自体を検討する必要があります：
紙の制約によって必要となる手順にはどのようなものがありますか？
視界不良を補うための二次確認はどこで行われていますか？
データが連携されていないという理由だけで、どのような照合作業が手作業で行われているのでしょうか？
現場の慣習は、SOPに書かれている内容に優先するのでしょうか？
この発見の段階は、課題への挑戦です。
このステップを省略したチームは、検証や本番稼働の段階で、しばしばエッジケースに気づくことになります。その結果、手戻りや追加のテストサイクルが発生し、プロジェクトの途中でスコープの調整を余儀なくされることになります。
ここで時間を割くチームは、その後のプロセスの摩擦を軽減できます。
「これは、どちらかといえば人材の変革、文化の変革、プロセスの変革といったものであり……テクノロジーはあくまで最後の仕上げに過ぎません」— ジェイソン・ギレスピー、ジャズ・ファーマシューティカルズ、デジタル・エンタープライズ・ケイパビリティーズ・ビジネスパートナー
デジタル化は、変革を促す原動力となります。それは曖昧さを浮き彫りにし、不整合を表面化させ、プロセスが十分に標準化されていなかった箇所を明らかにします。その瞬間を、単なる再現ではなく、再設計の機会として捉えてください。
なぜなら、一度アプリケーションに非効率性が組み込まれてしまうと、それを取り除くのははるかに難しくなるからです。
ステップ4：体系的な検証を通じて、早期にQA部門の信頼を獲得する
GxP において、品質保証部門がシステムに確信を持てなければ、デジタルトランスフォーメーションは拡大しません。
柔軟なプラットフォームについては、すぐに次のような疑問が生じることがあります：
これはどのように検証すべきでしょうか？
リスク分類はどのようになっていますか？
これはインフラストラクチャ、アプリケーション、あるいはその両方でしょうか？
効果的な戦略の一つは、初期段階で保守的に検証を行うことです。
それは、ユニットテストとエンドツーエンドのプロセステストを組み合わせることを意味するかもしれません。実行したセッションを記録して確認することを意味するかもしれません。あるいは、長期的には最終的に必要とされるよりもはるかに多くのテスト手順を文書化することを意味するかもしれません。
目的は書類作業を増やすことではありません。曖昧さをなくすことです。
体系的なアプローチでは、多くの場合、責任の分担が含まれます：
プラットフォームレベルのガバナンスとライフサイクル管理は、一元的に管理されています
Application検証は、サイトの品質保証（QA）チームが担当しています
品質部門に明確な承認権限が委ねられています
この区分により、責任の所在に関する混乱を防ぎ、検査報告書を明確な内容に保つことができます。
時間の経過とともに、プラットフォームの挙動が理解され、ライフサイクル管理の有効性が実証されれば、検証作業はよりリスクベースのモデルへと移行させることができます。
しかし、効率性は信頼に続いてこそ生まれるものです。規制の厳しい環境においては、加速は自信から生まれます。そして、その自信は、体系化され、可視化された検証プロセスを通じて築かれるのです。
ステップ5：スプリントとメトリックゲートによるスコープの管理
勢いは、柔軟性だけから生まれるものではありません。勢いは、何が可能かを目の当たりにし、チームがプロセスのデジタル化、ワークフローの簡素化、あるいは手作業の排除がいかに迅速に行えるかを理解したときに生まれます。その勢いが一度高まると、そこには枠組みが必要となります。
拡張が加速するにつれ、2つのリスクが浮上します。それは、一度に追加しすぎてしまうことと、構築の途中でエッジケースに対処することです。
懸念されるのは、制御の問題です。ドリフトを防ぐ仕組みは、アイデアを制限してしまうのです。
まず、作業は、あらかじめ成果が定められた2週間のスプリントのような、短く明確なサイクルに分割すべきです。各セッションには時間制限を設ける必要があります。フィードバックループを組み込むべきです。開発は、大規模なリリースではなく、段階的に進めるべきです。
第二に、拡張は指標に基づいて判断すべきです。新しいユースケースは、当初に定義されたのと同じ運用基準を満たす必要があります。労力、監視体制、または逸脱リスクを大幅に改善できない場合は、拡張を待つべきです。
スプリントはペースを管理し、メトリック・ゲートは優先順位を管理します。これらを組み合わせることで、柔軟性が無秩序な拡大へとつながるのを防ぐことができます。
GxP において、スコープ管理とは適切な順序付けを行うことであり、それによって変換が事後対応ではなく、計画的に行われるようになります。
ログブックからエンドツーエンドの実行まで
範囲が適切に管理され、検証によって信頼性が確保されれば、事業拡大は持続可能になります。
単一のワークフローとして始まったものが、これまで孤立していたプロセスを連携させることで、スケジューリング、ラインの空き確認、実行手順、清掃、そして梱包にまで広がっていくことがあります。
ワークフローに直接組み込まれた検証手順により、オペレーターが各ステップを正しく完了し、記録することが保証されます。これにより、手動による第三者による確認への依存度が低減され、バッチレビューが簡素化されます。
実行があってこそ可視化が実現します。ワークフローがデジタル化されれば、パフォーマンスに関する洞察は自然と得られるようになります。
エンドツーエンドの実行には、モノリシックなデプロイメントは必要ありません。
体系的で検証済みの段階的なプロセスを通じて進化させることができます。
Tulip 製薬製造業界において、体系的で拡張性の高いデジタルトランスフォーメーションTulip する方法
Tulip 、プラットフォームのガバナンスとプロセスの実行を分離することで、この体系的なアプローチTulip 。
チームはまず、プラットフォームレベルでアーキテクチャ、ライフサイクル管理、および検証戦略を確立します。その後、定義された範囲内で、プロセス固有のアプリケーションを段階的に構築していきます。
Tulipプラットフォームを利用すれば、製薬チームの皆様は、ログブック、スケジューリング、清掃、実行手順といった各工程を段階的に拡張することができ、かつ、モノリシックな導入を強要されることはありません。チームは管理されたバージョン管理を通じてアプリを進化させることができ、QA部門はリリース権限を維持しつつ、変更内容に対する可視性を確保できます。
ガードレールをワークフローに直接組み込むことで、コンプライアンス管理を維持しつつ、手動による再確認への依存を減らすことができます。
これにより、製薬製造におけるデジタルトランスフォーメーションを計画的に拡大することが可能になります。まず限定的なユースケースから始め、厳格に検証を行い、明確なガバナンスを適用し、リスクを増大させることなく、確信を深めながら生産全体へと展開していくのです。
Tulipで現場のデジタル変革を実現
アプリで構成したシステムが、業務の連携とアジャイルな運用を実現する仕組みをご覧ください。