製造業の品質管理（GMP）をITに持ち込むと、何が変わるのか
品質管理（GMP）をITに持ち込むと、何が変わるのか？ 記録が全部残るシステムを一人で作り込んで取り違えた前職の経験から、機能の数ではなく変更・承認・記録の三つで測る設計にたどり着いた話を書きます。
「記録が残る」を作れば、うまくいくと思っていました
品質管理をITに持ち込むことは、立派な機能を載せることではありません。記録が全部残るシステムを一人で作り込み、その取り違えをした側だからです。製造業のDXの話は、たいてい「どの機能を載せるか」から始まります。私たちは、そこでつまずいた側です。
前職の化粧品工場で、品質管理のシステムを一人で書きました。製品標準書の変更履歴、原料データベース、配合比、抜き取り検査、受入検査、不良記録、生産指図から出荷まで。化粧品GMPに対応した記録が、すべて残る。薬事の三者承認フローまで組み込みました。我ながら、よくできたと思っていました。
システムを書いていたころ、私が信じていたのは、たった一つです。GMPに対応して、記録がきっちり残るシステムさえ付ければ、すべてうまくいく。品質管理をITに持ち込むとは、そういうことだと思っていました。
いま振り返ると、これがいちばんの取り違えでした。品質管理をITに持ち込む意味を、私は「機能を載せること」だと勘違いしていたのです。
GMPが本当に管理しているのは、機能ではなく「人の弱さ」
GMPが厳しく守ろうとするのは、優秀さや注意深さではなく、人の弱さを前提にした品質のほうです。疲れていても慣れていても品質が落ちない——その考え方を、私たちはITの現場に持ち込みたいと考えてきました。GMPを学んで、面白いと思いました。ただ、その面白さの正体に気づくのには時間がかかりました。
GMPが厳しく求めるのは、立派な設備でも、高度な検査機でもありません。「誰が、いつ、何を、どの手順で行い、誰が承認したか」を残すことです。変更があれば、変更前と変更後を記録し、承認を通す。逸脱が出れば、隠さず記録し、原因をたどれるようにする。トレーサビリティとは、そのための仕組みです。
GMPは、人の構造的な弱さを最初から織り込んでいます。
なぜ、そこまでするのか。前提が違うからです。GMPは、人を信じていません。正確には、人の構造的な弱さ——忘れる、慣れる、驕る、つい省く——を最初から織り込んでいます。優秀な人が注意深くやるから品質が保たれる、とは考えない。誰がやっても、疲れていても、記録と承認と手順で担保される。だから品質が落ちない。
記録と承認と手順で担保するやり方が、製造業の当たり前です。品質は、人の頑張りではなく、仕組みで守るもの。私たちがITに持ち込みたかったのは、本当はこの発想でした。
ITに持ち込むと、品質の「測り方」が変わる
品質の良し悪しは、機能の数ではなく、変更に耐え、承認と記録がたどれるかで決まります。この発想を業務システムに当てると、何が変わるのか。品質の測り方が、まったく違います。
多くのシステム導入は、機能の数と豪華さで良し悪しを測ります。あの機能もある、この画面もある、と。GMPの発想で測ると、見るところが変わります。仕様が変わったとき、変更前の状態が残るか。誰がいつ承認したかがたどれるか。イレギュラーな操作を、なかったことにせず記録するか。担当者が代わっても、同じ記録が同じように残り続けるか。
派手な機能は、導入した日がいちばん立派です。そこから現場が使い込み、例外が起き、人が入れ替わる。そのとき効いてくるのは、機能の数ではありません。変更に耐えられるか。おかしなことが起きたとき、あとから原因をたどれるか。人が代わっても品質が落ちない設計になっているか。製造業では、図面の上で完璧でも、ラインで例外に耐えられなければ不良品と同じです。その基準を、私たちはシステムにそのまま当てています。
私も、品質管理を「機能の話」だと誤解していました
偉そうに書いていますが、私自身がこの罠にはまっていました。
一人で書いたあのシステムは、記録は残せても、残せる仕組みにはなっていませんでした。一人で書いたコードは、一人でしか直せない。仕様が変われば、また私が書き直すしかない。私が抜けたら、誰も手を入れられない。人の弱さを仕組みで担保するどころか、私という一人の人間に、すべてを依存させていました。GMPを学んだ人間が、GMPの逆をやっていたわけです。
残すことと、残し続けられる設計は別物です。
記録が残るシステムを載せれば品質が守られる、と思い込んでいたあいだ、私は品質管理をずっと機能の問題として見ていました。本当は、人の弱さを前提に、変更と承認と記録で担保しつづける「運用の設計」の問題だったのに、です。作ったから使われる、載せたから守られる。この思い込みを、私は身をもって外すことになりました。
だから私たちは、変更・承認・記録で測ります
では、どうするか。私たちは、業務システムを機能の数では評価しません。変更に耐えるか、承認と記録が残るか、人が代わっても回るか。この三つで測ります。
製造業の品質管理が長年磨いてきた当たり前を、ITの現場に持ち込みます。
具体的には、開発の最初に機能一覧を広げません。まず、その現場でどんな変更が起きるか、どんな例外が出るか、誰が何を承認しているかを見ます。今日の業務を写し取るだけなら、変更が来た瞬間に壊れます。壊れないシステムは、変更が来ることを前提に設計されています。これは製造業の品質管理そのものの発想です。
そしてもう一つ。人の弱さを仕組みで担保するという発想は、担当者を縛るためではありません。逆です。誰がやっても品質が保たれるなら、特定の一人に負荷が集中しません。属人化がほどけ、担当者は安心して休めるようになります。記録は、その人のやり方を型にはめることではなく、その人の判断と貢献を残すことでもあります。私たちが「品質管理をITに持ち込む」と言うとき、目指しているのは監視ではなく、この安心のほうです。
経験でつまずいた私たちだから、向き合えること
製造業DXがうまくいかないとき、原因はたいてい技術ではありません。品質管理を、機能を載せることだと取り違えることです。私たちは、記録が残るシステムを一人で作り込み、まさにその取り違えで一度つまずきました。
派手な機能より、
変更に耐え、記録が残り、人が代わっても回ること。
一度失敗したからこそ、見えるものがあります。
だからいま、お客様の現場では、機能の数を競いません。変更が来ても壊れないか。何かあったとき、原因をたどれるか。作った人がいなくなっても、直しつづけられるか。製造業が長い時間をかけて磨いた品質管理の当たり前を、私たちはITの現場に持ち込みます。そこで一度失敗したことが、私たちのいちばんの強みだと考えています。
よくあるご質問
- 変更や承認の履歴が残る仕組みを入れるのに、どれくらいの期間と費用がかかりますか。
- 私たちはまず、その現場でどんな変更や例外が起きるのかを聞き取る期間を、二週間から一か月ほどいただきます。何を記録し、誰が承認するのかが見えてから、費用を提示します。最初に一律の金額を出さないのは、記録すべき変更の種類や承認の段数によって手間が大きく変わるからです。一つの業務から始めて、回ることを確かめてから広げる進め方もお勧めしています。
- うちは化粧品や医薬品のような規制のある業種ではありません。それでも変更・承認・記録の設計は必要ですか。
- 規制の有無にかかわらず、人が入れ替わり仕様が変わる現場であれば効いてきます。私たちがGMPから持ち込んでいるのは薬事の書式ではなく、人を過信せずに品質を保つという考え方のほうです。ですから、法令で記録が義務づけられていない業種でも、どこまで履歴を残すかはその現場の実態に合わせて加減します。要らない記録を増やして現場を重くするのは、私たちも避けたいところです。
- 社内に品質管理の担当者がいなくても、こうした仕組みは入れられますか。
- 入れられます。どんな変更や例外が起きているかを一緒に洗い出すところから、私たちが引き受けます。品質管理の専門家を先に採用してから、という順番でなくても始められます。むしろ担当者が一人もいない現場ほど、記録と承認の仕組みで品質を支える意味は大きいと考えています。
- すでに使っている業務システムに、後から変更履歴や承認の記録を足すことはできますか。
- できる場合が多いです。まず、いまのシステムでどの操作が記録されず、どこで承認が抜けているかを私たちが見せていただきます。全部を作り直すのではなく、変更が起きる箇所と承認が要る箇所を絞って、そこから履歴が残るように直していきます。一度に完璧を目指すより、後から原因をたどれる状態に少しずつ近づけるほうが、現場は止まりません。
技術は真似できる
定着させるノウハウが、弊社の強みです。
まずは相談してみる
現状を整理してみる、くらいの気持ちで大丈夫です。
見せていただいた作業を、動く画面にしてお返しします。