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