製薬会社で働いていると、「DX」という言葉を聞く機会がかなり増えた。
DX推進、スマートファクトリー、データ活用、AI活用、ペーパーレス化など、さまざまな取り組みが進んでいる。
一方で、
「DX担当って実際に何をしているのか」
「従来の改善活動と何が違うのか」
「製薬会社でDX人材になるには何が必要なのか」
と疑問に思う人も多いと思う。
実際、製薬会社のDXはかなり幅が広い。
大規模なシステム導入もあれば、Excel業務の自動化、データ解析、設備の自動化なども含まれる。
私は、製薬会社のDXを考えるうえで重要なのは、新しいデジタル技術を使うこと自体ではなく、仕事の進め方や仕組みを変えることだと考えている。
この記事では、製薬会社のDX担当がどのような仕事をするのか、現場改善との違い、そしてGMPを理解したDX人材がなぜ重要なのかを実務目線で紹介する。
そもそもDXとは何なのか
DXは「Digital Transformation」の略である。
直訳すると「デジタルによる変革」という意味になる。
ここで重要なのは、単なるデジタル化とDXは少し違うということだ。
例えば、紙で管理していた帳票をPDFに変えたとする。
これはデジタル化ではある。
しかし、紙をPDFに変えただけで、承認方法や作業の流れがほとんど変わっていなければ、業務そのものは大きく変わっていない。
一方で、
紙に記録する
↓
Excelへ転記する
↓
別のシステムへ再入力する
↓
人が集計する
という業務を、
設備から自動でデータを取得する
↓
データベースへ保存する
↓
自動でグラフ化する
↓
必要な人がリアルタイムで確認する
という形に変えたとする。
この場合は、単なるデジタル化より一歩進んでいる。
仕事の流れそのものが変わっているからである。
DXという言葉は曖昧に使われることも多いが、「デジタル技術を使って業務の仕組みを変えること」と考えると分かりやすい。
製薬会社のDX担当は何をするのか
製薬会社のDX担当といっても、仕事内容は会社や部署によって大きく異なる。
例えば製造部門では、
- 製造データの自動収集
- 電子製造記録の導入
- Excel業務の自動化
- RPAによる定型作業の削減
- AIを使った文書作成支援
- 工程データの解析
- 設備状態の可視化
- センサー導入
- PLCや制御システムとの連携
- ペーパーレス化
- ラボオートメーション
- スマートファクトリー化
などが考えられる。
研究部門であれば、電子実験ノート、実験データの自動取得、画像解析、ロボットによる実験自動化などもDXの対象になる。
品質部門であれば、文書管理、レビュー支援、試験データ管理、データインテグリティなどが関係する。
そのため、DX担当＝プログラマーというわけではない。
システムを作る人もいる。
データを分析する人もいる。
設備を自動化する人もいる。
そして、現場の課題を見つけ、IT部門や設備メーカーとつなぐ人もいる。
現場改善とDXの違いは意外と曖昧
製造業では、DXという言葉が広まる前から改善活動が行われてきた。
例えば、
- 作業動線を短くする
- 手順を変更する
- 治具を作る
- Excelを使いやすくする
- チェック方法を見直す
といった活動である。
では、これらの改善とDXには何が違うのだろうか。
個人的には、明確な境界線を引く必要はないと思っている。
例えば、毎日1時間かかっているExcel作業をVBAで5分にしたとする。
これを「業務改善」と呼んでもいいし、「DXの一部」と呼んでもいい。
重要なのは呼び方ではない。
現場の問題が実際に解決されているかどうかである。
DXという言葉を使うと、大規模なシステム導入やAI活用を想像しやすい。
しかし現場では、数千万円のシステムよりも、毎日30分かかっている作業をなくす方が喜ばれることもある。
小さな改善でも、複数部署へ横展開されれば大きな効果になる。
現場を知らないDXはうまくいかないことがある
製造現場のDXで難しいのは、IT技術だけでは解決できないことだ。
製薬工場には、
- GMP
- 品質保証
- バリデーション
- データインテグリティ
- 安全
- 設備管理
- 製造手順
- 変更管理
など、さまざまなルールがある。
IT的には簡単に変更できそうな仕組みでも、GMP環境では簡単には変えられない場合がある。
例えば、
「このExcelをWebアプリにすれば便利そうだ」
と思ったとしても、そのデータがGMP記録として扱われるのであれば、アクセス権限、変更履歴、バックアップ、電子記録の信頼性などを考える必要が出てくる。
逆にIT部門から見れば、
「なぜこの作業はこんなに複雑なのか」
と思う場合もある。
しかし現場側には、品質や安全上そうせざるを得ない理由が存在することもある。
ここで重要になるのが、現場とデジタルの両方をある程度理解する人である。
DX担当で重要なのは「課題を見つける力」
DX担当というと、プログラミングが得意な人を想像するかもしれない。
もちろん、VBAやPython、SQLなどを使えることは強みになる。
しかし私は、それ以上に重要なのが、
何を改善すれば価値が出るのかを見つける力
だと思っている。
高度なプログラムを書けても、現場が困っていないものを作ってしまえば使われない。
逆にプログラミング能力がそこまで高くなくても、
「この転記作業はなくせるのではないか」
「このデータは自動取得できるのではないか」
「ここで毎回同じミスが起きている」
と気付ける人はDXと相性がよい。
製造現場では、本人たちが「これが普通」と思っている作業の中に改善ポイントが隠れている。
例えば、
毎朝同じデータを複数ファイルから集める。
同じ情報を複数システムへ入力する。
紙に記録した数字をあとでExcelへ転記する。
文書を作るたびに似た文章をコピーする。
こうした作業に対して、
「そもそも、なぜこの作業をしているのか」
と疑問を持つところからDXは始まる。
化学系人材がDXに向いている理由
化学系や薬学系の人材がDXを学ぶ意味はかなり大きいと思っている。
なぜなら、理系の仕事ではもともと、
「現象を観察する」
「原因を考える」
「条件を変える」
「結果を比較する」
という考え方を使うからである。
これは業務改善にも非常に近い。
例えば、化学反応の収率が低下した場合、
原料なのか。
温度なのか。
撹拌なのか。
反応時間なのか。
設備なのか。
さまざまな原因を考える。
そしてデータを集め、仮説を立て、検証する。
DXでも同じである。
「なぜこの仕事に時間がかかるのか」
「どこでミスが発生しているのか」
「どのデータを取れば原因が分かるのか」
を考える。
そこにプログラミングやデータ解析という道具が加われば、改善できる範囲は大きく広がる。
GMPを理解したDX人材は製薬業界で需要がある
製薬会社のDXでは、ITやプログラミングの知識だけでは対応しにくい場面が多い。
なぜなら、製薬業界ではGMPを前提として業務を設計する必要があるからだ。
例えば、ある業務を自動化するとしても、
- そのデータはGMP記録に該当するのか
- 誰が入力・修正できるようにするのか
- 変更履歴は残るのか
- システムの信頼性をどう担保するのか
- 導入時にバリデーションが必要なのか
- 自動化してよい部分と、人が確認すべき部分はどこか
といった点まで考える必要がある。
ITの知識があれば、「技術的に実現できるか」は判断できる。
しかし製薬会社ではそれだけでは不十分である。
「GMP上、この仕組みを実際に運用できるか」まで考えられることが重要になる。
逆に、GMPには詳しくてもデジタル技術を知らなければ、今の業務をどこまで自動化できるのか、どのような選択肢があるのかをイメージしにくい。
そのため、製造や品質の業務を理解しながら、VBA、Python、AI、データ解析、設備自動化などの知識も持つ人材は、両者をつなぐ役割を担うことができる。
例えば、
「この転記作業は自動化できる」
「ここは品質判断なので人が確認する必要がある」
「このデータは重要なので、単純なExcel管理ではなくシステム側の管理も検討した方がよい」
といった判断ができる。
これは、単にプログラムを書けることとは少し違う。
製薬現場を理解したうえで、デジタル技術をどう使うか考えられること自体が専門性になる。
今後、電子化、AI活用、ラボオートメーション、スマートファクトリーなどが進めば、製造・品質・ITの間をつなぐ人材はさらに重要になると考えている。
製薬業界でDXを目指すのであれば、プログラミングの専門家と同じ土俵で競争する必要はない。
むしろ、
GMPの知識 × 現場経験 × デジタル技術
という組み合わせを作ることが一つの強みになる。
製薬業界で働いてきた経験は、DXへ進むうえで遠回りではない。
むしろ、その業界知識があるからこそ、実際の現場で使えるDXを考えられるのである。
現場側にプログラミングができる人がいるメリット
製造現場でプログラミングができる人がいると、改善のスピードが速くなることがある。
例えばExcel作業で困っている場合、
現場で課題を整理する
↓
上司へ相談する
↓
IT部門へ依頼する
↓
仕様を説明する
↓
開発してもらう
↓
修正依頼する
という流れになることがある。
小さな改善では、依頼するだけで時間がかかってしまう。
しかし現場側でVBAやPythonを使える人がいれば、簡単な試作品をその場で作ることができる。
「こういうものが欲しい」
という説明だけではなく、
「とりあえずこんな感じで作ってみた」
という状態から議論できる。
これだけでも改善スピードはかなり変わる。
もちろん、本番システムとして運用する場合はIT部門や品質部門との連携が必要になる。
それでも、最初のアイデアを形にできる人が現場にいる価値は大きい。
DXは「大きなプロジェクト」だけではない
DXという言葉が難しく感じる理由の一つは、最初から大きなことを想像してしまうからだと思う。
AI導入。
スマートファクトリー。
デジタルツイン。
IoT。
こうした技術は確かに魅力的である。
しかし、いきなりそこを目指す必要はない。
例えば、
毎月2時間かかっている集計を自動化する。
製造データをボタン一つでグラフ化する。
大量のファイル名を自動変更する。
文書の入力漏れを自動チェックする。
こうした改善も立派な第一歩である。
小さな改善を繰り返していると、
「このデータも自動で取れないか」
「この設備とつなげられないか」
「この処理をPythonでできないか」
と次のアイデアが出てくる。
その延長線上に設備自動化やスマートファクトリーがある。
DX担当は「現場とITの通訳」でもある
製薬会社のDXで面白いのは、必ずしも一つの専門性だけで勝負する仕事ではないという点である。
例えば、
化学は詳しいがITも少し分かる。
GMPは詳しいがプログラミングも少しできる。
設備は分かるがデータ解析もできる。
こうした複数領域の組み合わせが役に立つ。
現場の人が話している課題を理解し、それをIT的な要件に変える。
逆に、システム側の制約を理解し、現場へ分かりやすく説明する。
私はDX担当には、この通訳のような役割もあると思っている。
高度な専門家同士をつなぎ、実際に使える仕組みへ落とし込む。
これは製薬会社のように、品質、製造、設備、ITなど多くの部門が関わる環境では特に重要である。
DXをやりたいならまず身近な改善から始める
これから製薬会社でDXに関わりたい人は、いきなり専門部署へ異動する必要はない。
まずは自分の仕事を見直してみるとよい。
例えば、
- 毎週繰り返している作業
- コピー＆ペーストが多い仕事
- 転記が多い仕事
- 人によってやり方が違う仕事
- ミスが起きやすい作業
- データがあるのに活用されていない仕事
を探してみる。
そして、一つだけ改善する。
Excel関数でもよい。
Power Queryでもよい。
VBAでもよい。
Pythonでもよい。
大切なのは、技術を勉強することを目的にするのではなく、
実際の仕事を改善するために技術を使うこと
である。
この経験を積み重ねると、単なるプログラミング経験ではなく、「DXの実績」になっていく。
まとめ
製薬会社のDX担当の仕事は、会社や部署によってさまざまである。
システム導入、データ解析、AI活用、文書自動化、設備自動化、ラボオートメーションなど、対象は非常に広い。
一方で、DXの本質は必ずしも最新技術を使うことではない。
デジタル技術によって、仕事の仕組みをより良く変えることである。
その意味では、昔から行われてきた現場改善とDXには共通する部分が多い。
違いがあるとすれば、データ、ソフトウェア、設備制御などのデジタル技術を使うことで、改善できる範囲が大きく広がったことだと思う。
そして製薬会社では、ITだけ分かる人でも、現場だけ分かる人でも解決しにくい課題がある。
だからこそ、
GMPの知識 × 現場経験 × デジタル技術
という組み合わせには価値がある。
製造や品質を理解しながらデジタル技術も使える人は、現場とITをつなぎ、実際に運用できる仕組みを考えることができる。
DXに興味があるなら、まずは目の前にある「面倒な仕事」を一つなくすところから始めてみるのがおすすめである。
その小さな改善が、製薬会社でDXに関わる最初の一歩になるかもしれない。
