── 月曜の生産会議が終わったあと、事務所で
Y社長：「同じ品物の受注残が、営業の表では480個、Uさんの表では360個。どっちが正しいんですか」
Uさん（生産管理）：「基幹システムの画面を見れば分かるはずなんですが、写した日が違うので……」
Y社長：「会議の半分が、数字の確認で終わってしまいますね」
正しい数字は、会社の中にある。誰も、それを直接見ていない。
会社の中心には、基幹システム（受注・在庫・出荷をまとめて管理しているシステム）がある。ところが、日々の仕事で見られているのは、部署ごとに育った手元の表のほうだ。
手元の表は、基幹システムの画面や帳票を見ながら、人が打ち直して作っている。写した日が違えば、同じ品物の数字も違ってくる。
表が悪いのではない。どの表も、会社の中心の数字から、少しずつ離れたところで動いているのだ。
会議のたびに、同じ品物の数字が三つ出てくる
ある樹脂成形の製造業（従業員約65名）では、10年以上前から同じ基幹システムを使っていた。受注も在庫も出荷も、正しい数字はこの中にある。
ただ、基幹システムから取り出せるのは、導入のときに決めた帳票（決まった形で印刷や表示をする一覧）だけだった。部署が見たい形の一覧は、そこにはなかった。
そこで、部署ごとに手元の表が育っていった。
- 営業：Excelの受注残の表。週に1回、帳票を見ながら約2時間かけて打ち直す
- 生産管理：UさんがMicrosoft Access（小さなデータベースを自分で作れる道具）で作った生産計画の表。毎朝、基幹システムの画面から約40分かけて写す
- 成形課：班長のVさんが使うGoogleスプレッドシートの材料在庫の表。週に2回、約1時間ずつ写す
合わせると、打ち直しに週7時間ほどかかっていた。そして写すタイミングがばらばらなので、月曜の生産会議では、同じ品物の数字が表の数だけ出てくる。60分の会議のうち、20〜30分は「どの数字が正しいか」の確認に使われていた。
手元の表には、それぞれに育った理由があった
Y社長は最初、二つの案を考えていた。手元の表をやめて、全員が基幹システムの画面を見るようにするか。基幹システムの提供元に、部署ごとの帳票を追加で作ってもらうか。
しかし、どちらも簡単ではなかった。
Uさんの表には、基幹システムにはない「金型を付け替える順番」が入っている。営業の表には、まだ注文になっていない内示（お客さまからの事前の見込み）の数が並んでいる。Vさんの表は、成形機の横でタブレットから見られる形になっている。どの表も、基幹システムの画面ではできないことを補うために作られていた。
一方で、帳票を部署ごとに追加するには、見積もりを取ってから作ってもらうまでに時間も費用もかかる。部署の見たい形が変わるたびに、また頼むことになる。
誰かが勝手に表を作ったわけではない。基幹システムが見せてくれる形と、現場が必要な形が違っていた。そのあいだを、人の打ち直しが埋めていた。
手元の表が悪いのではない。どの表も、会社の中心の数字から、手作業の分だけ離れたところで育っていた。
基幹システムの裏にある「倉庫」から、表へ直接数字を渡した
基幹システムの画面や帳票は、いわば窓だ。窓の奥には、データをためておく倉庫、データベースがある。この会社の基幹システムでは、その倉庫にOracle（データベースの製品）が使われていた。
私が手がけたのは、窓の形を増やす代わりに、倉庫から直接、手元の表へ数字を渡す道を作ることだった。営業のExcel、UさんのAccess、VさんのGoogleスプレッドシートが、それぞれ基幹システムの裏のデータベースから、受注残や在庫の数字を受け取れるようにした。
手元の表の形は、ほとんど変えていない。変わったのは、数字の出どころだけだ。人が画面から写していた数字が、倉庫から届くようになった。
あわせてY社長は、社内に一つ決まりを置いた。「受注残・在庫・出荷の数字は、基幹システムのものを正本にする。手元の表では打ち直さない」
並べて見比べた2週間で、Uさんの「ひと手間」が出てきた
切り替えの前の2週間、各部署はこれまでどおり打ち直した表と、倉庫から数字が届く表を並べて見比べた。
営業とVさんの表は、打ち間違いを除けばほぼ一致した。ところが、Uさんの生産計画の表だけは、いくつかの品物で数字がそろわなかった。
Uさんが理由を話してくれた。「不良が出やすい品物は、写すときに少し多めにしていたんです。そのまま作ると、足りなくなるので」
打ち直しの中に、Uさんの判断が溶け込んでいた。本人にとっては当たり前のひと手間で、表を見るほかの人には見えていなかった。
そこでUさんは、倉庫から届く受注残の横に「上乗せ」の列を別に作ることにした。正本の数字と、Uさんが足す数字を分けて並べる。営業も、内示の数を同じように「付け足し」の列として分けた。
2ヶ月後、会議で数字の確認をしなくなった
切り替えから2ヶ月後、週7時間ほどあった打ち直しは、付け足しの列を入れる分の週1時間ほどになった。
月曜の生産会議では、数字の確認に使っていた20〜30分が、ほとんどなくなった。どの表の受注残も、同じ倉庫から届いている。確かめる必要がなくなったのだ。部署ごとの帳票を追加で作ってもらう話も、見送りになった。
ただ、会議で数字が食い違うことが、まったくなくなったわけではない。
内示の数や上乗せの数は、今も人が入れている。その付け足しの数字をめぐって、営業と生産管理の見方が分かれることはある。違うのは、議論がどこから始まるかだ。
Y社長はこう言った。「前は、どれが正しい数字かで揉めていた。今は、正しい数字の上に何を足すかで話している。同じ時間でも、話の中身が違いますね」
正本が一つに決まると、手元の表は「写し」ではなく、中心の数字をのぞく「窓」になる。
骨格調整でやること：3つのアクション
1. 手元の表をやめさせる前に、その表が何のために育ったかを見る
部署ごとの表は、基幹システムでは足りないものを補うために生まれていることが多い。表をやめさせると、その補っていた役割まで消えてしまう。まず、その表にしか入っていない情報は何かを確かめる。
2. 正本を一つ決め、「写した数字」と「付け足した数字」を分ける
基幹システムにある数字は、基幹システムを正本にする。手元の表で人が足す数字（内示、上乗せ、見込み）は、正本とは別の列に置く。混ざっていると、どこからが人の判断なのかが見えなくなる。
3. 帳票を増やす前に、裏のデータベースから渡せないかを確かめる
見たい形が増えるたびに帳票を足していくと、費用も時間もかさむ。基幹システムの裏にあるデータベースから、手元の表へ直接数字を渡せれば、表の形は部署で決められる。
このモデルケースについて
この物語は、中小製造業の支援でよく出会う流れを再構成したモデルケースです。特定の実在企業の話ではなく、登場する会社・人物・数字は、典型的なパターンを示すために組み立てたものです。
部署ごとに表や道具を工夫していくと、やがて「会社の中心の仕組みと、手元の表が別々に動いている」という形で課題が現れることがあります。この話は、その段階の一場面です。
HABAねっとは、北陸を拠点に中小企業・個人事業主のDX伴走支援を行っています。「部署ごとの表の数字が合わない」「結局、誰かが基幹システムから打ち直している」という状態から、会社の中心の数字と手元の表をつなぎ直すところまで一緒に整理します。
この話のような取り組みは、HABAねっとでは「第3段階 骨格調整」としてお手伝いしています。
素早く、手早く、滑らかに。
📖 事例レポート版（数値・Before/After形式）は → こちら