── トラックが着く30分前、出荷場で
Wさん（出荷担当）：「3時の便、製番0187の分は何箱ですか？」
Fさん（出荷担当）：「7箱です。朝、入荷の場所を空けるのに奥へ寄せたはずなんですけど、6箱しか見当たらなくて」
Wさん：「残りの1箱は、どこに行ったんでしょう」
箱には製番が書いてあった。分からなかったのは、その箱がいまどこにあるかだった。
出荷のミスと聞くと、多くの人は「積む人の確認不足」を思い浮かべる。
しかし、出荷場に立ってみると、箱は一つの場所にとどまっていないことが多い。限られた場所に、梱包を終えた段ボールが次々に運び込まれ、出荷の順番や入荷に合わせて寄せ直される。
箱に番号が書いてあっても、その箱がいまどこにあるのか、どこへ出すのかまでは教えてくれない。
出荷前の置き場で、箱は毎日動いていた
ある産業機械部品のメーカー（従業員約50名）は、注文ごとに設計して作る個別受注の会社だった。注文が入ると「製番」（製造番号。注文ごとに一つ振る番号）が決まり、図面も作業指示書も、その製番で動いていく。
一つの製番で作る部品は、数点のこともあれば、数十点に及ぶこともある。梱包を終えると、段ボールで2箱から10箱ほどになる。箱は製番ごとに一つの群にまとめて、出荷の日まで出荷場の一角に置いておく。出荷は1日に6〜8製番ほどで、多い日には置き場に60箱近くが並んだ。
ところが、出荷場のスペースは限られていた。入荷の荷物を受け入れるため、翌朝の便を手前に出すため、製番の群は日に何度か寄せ直された。昨日あった場所に、今日も同じ群があるとは限らない。
箱には、梱包した人が油性ペンで製番と「1/7」のような箱の番号を書いていた。箱を手に取れば、どの注文のものかまでは分かる。
製番の群がどこにあるかは、Fさんの記憶だった
出荷担当のFさんは、置き場の動きをよく見ていた。「0187の群は、朝、奥の壁ぎわに寄せた」「0192は入口の横」。どの製番の群がいまどのあたりにあるかを、Fさんは覚えていた。
それでも、出荷の前には毎回、置き場を見て回る時間がかかった。出荷予定の紙を片手に群を探し、箱の製番を読んで紙と見比べ、数を数える。1日に合わせて1時間ほどが、この確認に使われていた。
困りごとは、もう一つ重なっていた。製番を見ても、出荷に要ることは分からない。製番は、もともと注文を受けたときに振る番号だからだ。納期はいつか、どの顧客の、どこの出荷先へ送るのか。そうした物流の情報は、事務所で印刷した出荷予定の紙や、別の台帳に載っていた。
Fさんが休みの日は、もっとかかった。代わりの人はどの群がどこにあるか分からず、置き場を端から見て回ることになり、確認の時間はおよそ倍になった。
しかも、見て回っても間違いはゼロにならなかった。過去1年で、出荷の誤りが2件あった。1件は、寄せ直しのときに隣の群に紛れた別の製番の箱が、1つ混ざって出ていった。もう1件は、7箱のうち1箱だけが離れた場所に置かれたままで、積み残した。
箱の居場所を知っていたのは、箱ではなく、人だった。
誰かが手を抜いていたわけではない。箱には製番という名前があった。足りなかったのは、いまどこにあるかと、どこへ出すかだった。その二つを、人の記憶と紙が埋めていた。
出荷予定と箱を、製番でひもづけた
探し物の多くは、名前と中身が別々の場所に置かれているところから生まれる、と私は考えている。この工場では、製番は箱の上に、出荷の情報は事務所の紙と台帳に、群の居場所はFさんの頭の中にあった。
製番は、注文ごとに一つだけ振られる。作業指示書にも、梱包の指示にも、箱にも載っている。新しい番号を作る必要はなかった。足りないのは、製番から「どこへ出すか」と「いまどこにあるか」をたどる道だった。
そこで私は、出荷予定の情報と、出荷前の置き場にある梱包済みの箱とを、製番をキーにしてひもづけられるようにした。
「どこへ出すか」にあたる納期や顧客名、出荷先は、もともと基幹システム（受注や生産、出荷を管理する会社の中心のシステム）のデータベースに入っていた。そこで、そのデータベース（Oracle）から出したデータをCSV（表の形の文字データ）にしてGoogle側へ送り、Google Apps Script（Google Workspaceの中で動く小さなプログラム）で、AppSheetが読める形のスプレッドシートに毎日自動で変換して取り込むようにした。途中にいくつか経由がある、込み入った道だった。データの出し方は、何のために使うのかを私が基幹システムの業者に説明し、CSVで受け渡す形で双方が納得した。これで、製番から納期・顧客名・出荷先などを引けるようになった。AppSheetは、表やデータベースのデータをもとに、スマートフォンやタブレットで使える業務アプリを作れる道具である。
アプリは、出荷管理のアプリとして自作した。受注の内容を確かめるところから、ピッキング（棚から部品を取り出す作業）、パッキング（梱包）、梱包した箱を置き場に収めるところまでを、現場の端末だけで済ませられる形にした。
QRコードで、群を置いた場所を残した
「いまどこにあるか」は、日々変わる。変わるたびに人が書き留めるのでは続かない。製番は桁が多く、似た番号も並ぶ。手で打てば、打ち間違いがそのままひもづけの誤りになる。
だから、QRコードを使った。狙いは、素早く、正確に、滑らかにひもづけられることだった。
梱包が終わった箱には、製番と箱の番号を入れたQRコードのラベルを貼る。置き場に収めるときに、タブレットでラベルを読み取り、群を置いた場所と結びつける。寄せ直したときは、置き直した場所で読み直す。入力は、読み取りと数回のタップで済むようにした。
出荷予定の一覧を開けば、製番ごとに、納期や出荷先と並んで、箱の数といまの置き場所が分かる。
読み取りに使うタブレットは、インフラ整備の一環として4台を配備した。梱包する場所でも、出荷場でも、手元で読み取れる台数である。
最初の2週間、ラベルのない箱が残った
使いはじめてすぐに、つまずきが出た。
最初の2週間で、ラベルが貼られないまま置き場に並んだ箱が十数個あった。梱包の手順の中に、ラベルを貼るタイミングがはっきり決まっていなかったのだ。ラベルのない箱の居場所は、これまでどおりFさんの記憶に頼るしかなかった。
これを受けて、梱包の担当者たちが自分たちで決まりを一つ作った。「テープで封をしたら、その場でラベルを貼る。置き場には、読み取ってから収める」。
決まりは短く、守りやすかった。3週目からは、ラベルのない箱はほとんど出なくなった。
仕組みは、道具だけでは回らない。手順のどこに差し込むかを決めたのは、毎日箱を詰めている人たちだった。
私は設計と実装を担い、こうした現場の人たちと一緒に、運用が定着するところまで進めた。
Fさん以外の人でも、出荷物を見つけて取り出せるようになった
使いはじめて3ヶ月ほどたったころには、出荷物を探して取り出す仕事は、Fさんだけのものではなくなっていた。
Fさんが休んだ日に出荷を担当したのは、入社して1年ほどの若手だった。タブレットで出荷予定の一覧を開き、製番ごとに出荷先と箱の数、いまの置き場所を確かめて群を見つけ、ラベルを見て取り出していく。置き場を端から探し回ることはなかった。
Fさんがいる日も同じである。ほかの人が出荷物を取りに行くときは、アプリで群の場所と出荷の情報を確かめれば、自分で見つけて取り出せる。群の居場所を聞くために、Fさんを探す必要はなくなった。
出荷前の探す時間と確かめる時間は、1日に合わせて約1時間から15分ほどになった。使いはじめてからの半年、別の製番の箱が混ざったり、箱を積み残したりしての出荷は起きていない。
その後、同じタブレットは、アルコールやシンナー類といった危険物の出庫の管理にも使われるようになった。一度そろえた道具は、次の困りごとにも手が届く。
Fさんは、少し拍子抜けしたように言った。
「どの群をどこに寄せたか、覚えておかなくていいのが、こんなに楽だとは思いませんでした」
体質改善でやること：3つのアクション
探す時間を減らすことは、探すのが上手な人を増やすことではない。探さなくても分かる形に、ものと情報をそろえることだ。
1. すでにある番号から、出荷の情報までたどれるようにする
箱に番号が書いてあっても、その番号から要る情報にたどれなければ、結び目は人の記憶に残る。社内ですでに使っている番号の中から、注文ごとに一つだけ振られるものを選び、そこから納期や出荷先まで引けるようにする。
個別受注の製造業なら、多くは製番がその役を担える。新しい番号を作ると、覚えるものが一つ増えるだけになりやすい。
2. 番号は打たせず、読み取らせる
現場での入力が手間なら、どれほど良い仕組みでも続かない。桁の多い番号を手で打てば、打ち間違いも起きる。
QRコードのように読み取るだけで入る形にして、入力は読み取りと数回のタップにとどめる。入力が簡単であることは、正確であることにもつながる。
3. 動く箱は、置いた場所を読み取りで残す
箱がどの製番のものか分かっても、どこにあるかが分からなければ、また探すことになる。限られた場所では、置き場は日々動く。置くたびに読み取り、いまの場所を一覧に残す。
いつ読み取るかは、現場の手順の中に決める。このケースでは、梱包の担当者たちが「封をしたら貼り、読み取ってから収める」と決めた。
箱の名前から、いまの場所と行き先が引ければ、人は覚えておかなくていい。覚えておく力は、別の仕事に回せる。
Fさんの記憶は、長い年月をかけて身についた、この会社の大切な力だった。その力を群の居場所を覚えることに使い続けるのではなく、箱の名前（製番）から、いまどこにあるかと、どこへ出すかを引けるようにする。それが、この工場の体質改善だった。
このモデルケースについて
この話は、HABAねっとが支援の中で出会ってきた課題をもとに、解決までの流れを再構成したモデルケースです。特定の実在企業の事例ではなく、登場する企業・人物・数値は典型的なパターンを示すために構成しています。
同じ第2段階のモデルケースとして、業務の流れを書き出して二重作業を見つけた「業務の見える化」、スプレッドシート1枚から始めた「スモールスタート」もあわせてどうぞ。
HABAねっとは、北陸を拠点に中小企業・個人事業主のDX伴走支援を行っています。人の記憶に頼っている「見分ける」「探す」仕事を、社内にすでにある番号を軸に、現場で無理なく続けられる形へ一緒に整えます。
この話のような取り組みは、HABAねっとでは「第2段階 体質改善」としてお手伝いしています。
素早く、手早く、滑らかに。
📖 事例レポート版（数値・Before/After形式）は → こちら