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