Excelと紙だらけの工場を変えたい——中小製造業の総務が始めたDXの第一歩
「ある業務で、データの照合が正しくできていないことがあるんだけど、なんとかならないかな」
ある日、上司からそう声をかけられたのが、すべての始まりでした。
当時の私は、今とは別の部署にいました。「なんで現場の改善を?」と思いますよね。これ、中小企業あるあるなんですが、部署を超えて応援に入ったり、人手が足りなくて担当範囲が広がったり、そういうことが日常的にある環境だったんです。なぜ私にこの話が来たのか、という経緯はまた別の記事で書きますが、とにかくこの課題に取り組んだ瞬間が、私の「DXの第一歩」でした。
どんな課題だったか
具体的な業務内容はぼかしますが、ざっくり言うとこういう話です。
製品を出荷するとき、製品に貼ってあるラベル(製品情報が載ったもの)と、その日の出荷予定のリストが一致しているかを確認したい。コンビニの商品にバーコードが貼ってありますよね。あんなイメージで、うちの製品にもコード付きのラベルがついていました。
つまり、ラベルのコードを読み取って、出荷リストと機械的に1対1で照合すればいい。最初はそう考えていました。シンプルな話だと思ったんです。
ところが、現実はそう簡単ではありませんでした。
照合したい相手が「手書き」だった
照合するもう片方——出荷リストを見せてもらって、唖然としました。
手書きだったんです。
しかも、ちゃんとした出荷予定リストがあるわけではありませんでした。別の業務記録(これも手書き)をコピーして、「ここからここまでが今日の分」とマーカーで線を引いてあるだけ。
当時はそれが当たり前のやり方でしたし、長年それで回っていた実績もありました。でも、データの照合をしようと思ったとき、照合する相手がデジタルで存在していないという現実に直面しました。
まず現場に話を聞きにいった
まずはその手書きのリストが普段どう作られているのか、現場の担当者に話を聞きに行きました。
この時の私は、正直なところ少し思い上がっていたのかもしれません。システムを考えることは好きだったし、自分にはできると思っていました。
「手書きの部分を電子化して、業務を楽にしたい。普段の作り方や使い方を教えてほしい」と伝えました。
ところが、現場からは慎重な声がありました。
「一部の業務が楽になっても、自分たちの作業が増えるなら意味がない。」
私の中では、トータルで考えたら効率は上がるし、手書き作業も減るし、ミスも防げる。この改善に疑問を持つことはありませんでした。だから正直、その反応を受けたとき、戸惑いました。
でも今振り返ると、現場の人たちの気持ちも当然だったと思います。長年のやり方を変えるのは、誰だって不安です。
なんとか普段の業務の流れを教えてもらうことには成功しました。
「絶対に良いものを作ってやる」
現場の慎重な反応を受けて、逆に火がつきました。
だったら、使ってもらったときに「これは良かった」と思ってもらえるものを作ってやる。そう心に決めて、Excelでの自動化について猛勉強を始めました。
当時はまだAIもない時代。本とネットだけが頼りでした。VBA(Excelのプログラミング言語)について独学で学び、ボタンひとつでデータの記録や登録、印刷ができるように。使う人が「手間だ」と感じないような流れを、とにかくいっぱい考えました。
この時の勉強が、今の自分の力になっていることをすごく実感します。データベースの基礎的な考え方と、コードを組んでシステムを自動化することの楽しさ。この二つに気づけたのは、この経験があったからです。
照合に使うコードやスキャナーについても、本当にたくさん勉強しました。コードの形式や種類、書き込むデータの設計。この世界は思った以上に奥が深く、これもまたすごく勉強になりました。
そして約1ヶ月。ボタンひとつでその日のリストを作成し、照合用の資料を印刷するところまで——ようやく完成しました。
また、衝撃を受けた
自分の手元ではテスト用のデータで動作確認もできていたので、自信を持って現場に持っていきました。
そこで、また衝撃を受けました。
聞き取りをしたときの話と、実際の使い方に違いがある部分があったんです。聞いた通りに作ったはずなのに、実際の作業の流れに合っていない。逆に手間がかかる作りになってしまっていました。
結局、作り直しです。
今度は実際の作業に沿った流れで動くように修正しました。他にも細かい修正はいくつもありましたが、ひとつひとつ直していって、ようやく——本当にようやく、現場で使ってもらえるものが出来上がりました。
自分が作ったものが、現場で動いた
この業務には、リストを作る工程とは別に、すべての製品を目視で確認する工程がありました。この確認作業の実態にも驚きました。毎朝確認を始めて、出荷ギリギリの時間までかかっていたんです。丸一日がかりの作業でした。
改善後、その確認作業がおよそ半日で終わるようになりました。
現場から「すごく楽になった」と感謝の言葉をもらったとき、感動したのはむしろ私の方でした。自分で考えて、自分で勉強して、自分で作ったものが、目の前で誰かの仕事を楽にしている。あの瞬間の気持ちは、今でもはっきり覚えています。
「これ、ボタンひとつで印刷と保存の両方やってくれるんですか!?」と驚いてもらえたこともありました。最初に慎重だった現場の空気が、少しずつ変わっていくのを感じました。使って初めてわかってもらえた。それが、嬉しかった。
この改善をきっかけに、「こんな改善もできない?」と声をかけてもらえることが増えました。あの一つの経験が、その後のさまざまな改善に取り組んでいく入口になったと感じています。
「聞いたつもり」では足りなかった
この一連の経験を通じて、ひとつ大きな学びがありました。
現場の話を「聞いた」だけでは、本当の業務はわからない。
私は確かに担当者に話を聞きに行きました。作り方を教えてもらい、それを元にシステムを作りました。でも、出来上がったものは実際の作業に合っていなかった。聞き取りが足りなかったんです。
人は自分の仕事を説明するとき、無意識にやっていることや、例外的な対応を省略してしまうことがあります。聞く側も、「なるほど、わかりました」と理解したつもりになってしまう。でも「聞いたつもり」と「本当に理解した」の間には、大きな溝がありました。
この経験から、私は現場の話を聞くだけでなく、実際の作業を自分の目で見ること、そして作ったものを早い段階で使ってもらってフィードバックをもらうことを大事にするようになりました。
改善の出発点は、システムではなく、現場を知ることから。今でも私が一番大切にしている考え方です。
---
実は、時系列としてはこの話より前に、本当に自分でゼロから作り上げた改善がありました。ある意味、こっちが「本当の第一歩」かもしれません。その話は、また別の記事で書きたいと思います。
※ この記事は「非エンジニアの私が、中小製造業の現場でDXに奮闘している話」シリーズの第2回です。
前回の記事:非エンジニアの私が、中小製造業の現場でDXに奮闘している話
いいなと思ったら応援しよう!
気が向いたらコーヒー奢ってください。泣きながら喜びます。また奢ってくれた人いたら感謝しながら拝み奉ります。