一斗缶（塗料や食品を入れる缶）を製造する鉄工所での話である。半年かけて生産管理システムを作った。業務フローも確認し、画面遷移も紙の上で作り、現場の人たちとも何度も確認した。
ハンドヘルドターミナルを使って作業実績を入力し、現品票を印刷し、そのデータをPCへ送る。仕組みとしては、きちんと動いていた。それでも、実際の運用が始まると、設計していたときには想像していなかったことが出てくる。その一つが、ハンドヘルドターミナルの電池だった。
システムが動くことと、現場で毎日無理なく運用できることは、少し違う。
今回は、少品種多量生産の工場で生産管理システムを作り、本番稼働後の二週間を現場と一緒に調整していったときの話である。
少品種多量と多品種少量では、作り方がまるで違った
以前、多品種少量生産の鉄工所の話を書いた。歯車や工作機械の組立加工など、注文ごとに中身がまったく違う仕事を、現場を巻き込みながらボトムアップで整理していった話である。
今回は、同じ「鉄工所」でも、まったく違うタイプの現場だった。商品は一斗缶。塗料を入れるものもあれば、食品を入れるものもある。作るものの種類は少ないが、量は多い。少品種多量生産という、前回とは対極の生産形態だった。
同じ生産管理でも、生産形態が違えば、システムの作り方そのものを変える必要がある。
トップダウンで全体を組み立てる
前回の現場では、ボトムアップで一つひとつ現場の知恵を拾い上げていくやり方をとった。今回はその逆で、トップダウンで全体を組み立てていった。
ただし、トップダウンだからといって、机の上だけで作ったわけではない。今回も半年、現場に通った。工程が比較的シンプルだったからこそ、業務フローを作り、現場にも入り、営業事務の人たちとも何度も会話を重ねた。
画面遷移も、実際に作る前に紙の上で確認した。紙芝居のように画面の流れを並べ、これで現場が迷わず使えるかを見ていった。
今回トップダウンで進めることができたのは、工程そのものが比較的シンプルだったことに加え、トップ自身が工程をよく理解していたからである。トップダウンといっても、現場を知らずに上から決めるのとは違う。全体の方向はトップが決め、その中身は現場と確認しながら固めていく。そんな進め方だった。
パッケージは使えるところだけ使う
生産管理の骨格は、工程を部品表化して工程計画を立てるという考え方だった。MRP（資材所要量計画）の部品展開を使い、受注管理から工程管理、日報、出荷、仕入、販売、在庫管理までを一連の流れとして組み立てていった。
MRPの部品展開については、「TPICS」というソフトを用いた。マスタはDBマジックで構築し、
部品展開は別ソフトに任せる方式である。その後、またメインシステムに戻す。
「TPICS」は、今もバリバリに使われているシステムである。
ゼロからすべて作る必要はない。すでにある仕組みに乗る方が理にかなっているところは、そこに乗ればいい。一方で、受注管理、工程管理、日報、出荷、仕入、販売、在庫管理については、現場に合わせてオリジナルで作った。
使えるところは使い、合わないところは作る。
パッケージを全部使うか、全部捨てるかではなく、自社の仕事に合わせて切り分けることが大切だった。
ロット管理を現場に落とし込む
作業実績の収集と、仕掛品・製品の在庫管理のために、ロット管理を導入した。ハンドヘルドターミナルでロット番号のバーコードを読み取り、工数と完成数を入力する。そのうえで、ロット番号と完成数を印字した現品票を出し、現品に貼り付ける。入力した実績データは、そのままPCへ送信される仕組みにした。
棚卸の入力にも、同じハンドヘルドターミナルを使った。一つの道具を、日々の実績収集にも棚卸にも使えるようにして、現場の手順をできるだけ増やさないようにした。
この仕組み自体は、きちんと動いた。ただ、本番運用に入ると、それまで見えていなかったことが出てきた。
本番運用で出てきた、想定外の問題
その一つが、ハンドヘルドターミナルの電池だった。
当時の電池は、今の機器のように、使ったら充電しておけばよいというものではなかった。まとめて充電しないとすぐ放電してしまい、いつ充電するのか、どのくらいの間隔で回すのかを考える必要があった。
システムとしては正常に動いている。それでも、使いたいときにハンドヘルドターミナルが使えなければ、現場の仕事は止まる。最後は工場長の案で、充電の運用を決め、なんとか安定して使えるようになった。
今なら、同じような問題は別の形で出るのだと思う。タブレットを誰が充電するのか。マスタを誰が更新するのか。バーコードが読めないときはどうするのか。入力を忘れたときはどうするのか。
設計段階では小さく見えることが、運用に入ると大きな問題になることがある。
電池の問題は、そのことを分かりやすく教えてくれた一例だった。
稼働後の二週間で仕組みを調整する
稼働してからの二週間は、かなり大変だった。マスタの入力と、実際に動かしてみて出てくる不具合の修正を並行して行った。それだけではなく、実際の使い方を見ながら、運用上の細かな調整も重ねていった。
工程がシンプルだからといって、本番稼働がすんなり進むわけではない。現場で実際に使ってみて初めて分かることが、次々に出てくる。
この二週間は、システムを作り直す期間というより、作ったシステムを現場の仕事になじませる期間だったのだと思う。システムは稼働日で完成するのではなく、実際に使いながら調整して、初めて運用として落ち着いていく。
在庫管理を支えた一枚の現品票
最終的には、現品票をキーにして在庫管理を回す仕組みが定着した。ロット番号と完成数が印字された現品票が、そのまま現品と情報をひも付ける役割を果たす。現物とデータが同じキーでつながることで、在庫管理の精度も上がった。
在庫管理というと、どうしてもシステムの機能や入力画面に目が行く。しかし、本当に大切なのは、現物とデータをどう結び付けるかである。この工場では、その役割を一枚の現品票が担っていた。
トップダウンを支えた人たち
今回、トップダウンで進めることができた背景には、何人かのキーマンがいた。
一人は常務である。冷静で理論的な考え方をする人で、今でも覚えている言葉がある。
「たいていのことは、相手の立場になって考えれば解決できる」
システムの話も、結局は人と人との調整である。現場からどう見えるか。使う人はどう感じるか。相手の立場で考えることは、今の仕事にもずっと生きている。
もう一人は社長だった。まだ若い方だったが、工程の細部までよく理解していた。だからこそ、トップダウンという進め方が機能したのだと思う。そして、本番稼働後の電池問題では、工場長の現場の知恵に助けられた。
トップが方向を決め、現場が運用を支える。その両方があって、初めて仕組みが定着した。
WITSで振り返る ― 設計と運用の間にあるもの
この仕事を今、WITS整理法で振り返ると、システム導入には設計だけではなく、運用まで考える必要があることがよく分かる。
W ― Will：何を実現したいのか
今回は、少品種多量生産の流れを整理し、生産から在庫までを一連の仕組みにすることが目的だった。まず「何のために変えるのか」を決める。ここが出発点である。
I ― Intelligence：誰が現場を知っているのか
全体はトップダウンで進めたが、最後の運用では工場長の知恵に助けられた。設計するときに必要な知恵と、実際に運用するときに必要な知恵は、必ずしも同じ人が持っているとは限らない。
T ― Tools：何を使い、何を作るのか
MRPの部品展開は既存の仕組みを使い、それ以外はオリジナルで作った。道具は目的ではない。現場に合うように組み合わせることが大切である。
S ― Story：どうすれば現場で迷わず使えるのか
業務フローを作り、画面遷移を紙の上で確認し、現品票で現物とデータを結び付けた。それでも、実際に使って初めて分かることがあった。
だからこそ、仕組みを作って終わりではなく、現場でどう使うのかまで共有していく必要がある。
WITSの四つを自社に置き換えるなら、何を実現したいのか。誰が現場を知っているのか。何を道具として使うのか。そして実際の運用をどう回すのか。
ここまで整理して初めて、システムが仕事の仕組みになる。
半年かけて作った生産管理システムは、きちんと動いた。しかし、本番運用が始まると、電池のような想定外の問題も出てくる。
システム構築では、設計どおり動くことがゴールではない。現場で使いながら出てくる問題を一つずつ調整し、無理なく続けられる形にしていくことが大切なのだと思う。
