中小製造業の見える化は「基準と実績の突合」── 数字は比較して初めて意味を持つ

「見える化」の中身が曖昧なまま進んでいないか

内製DXの文脈で「見える化」という言葉はよく出てくる。原価を見える化する、納期を見える化する、在庫を見える化する。方向としては正しい。しかし「見える化」の中身が曖昧なまま進むと、数字は出たが使われない、という結果になりやすい。

売上が3,000万円。原価率が78%。在庫金額が450万円。これらの数字を出すこと自体は、会計ソフトやExcelがあればできる。しかし、この数字を見て「だから何をすべきか」がわかるかというと、わからないことが多い。

以前の記事で「データは単体では意味がない」と書いた。あの記事では在庫と原価の組み合わせを取り上げたが、今回はもう少し根本的な話をする。見える化の本質は、数字を出すことではなく、比較できる状態を作ることになる。

データは単体では意味がない ── 在庫と原価を「つなげて見る」という内製DXの基本

数字は1つでは改善につながらない

原価率が78%。この数字だけを見て、改善すべきかどうか判断できるだろうか。

見積もりのとき想定していた原価率が75%だったとわかれば、「3%のズレがある、なぜか」という問いが生まれる。材料費が想定より高かったのか、工数がかかりすぎたのか、不良が多かったのか。ズレの原因を調べる過程で、改善ポイントが見えてくる。

あるいは、予定納期が3月15日だった案件が、実際には3月22日に出荷されていた。7日のズレがある。どの工程で遅れたのか。なぜ遅れたのか。この問いは、予定と実績の両方がデータとして残っていて初めて成り立つ。

つまり、改善とは「ズレを見つけて直すこと」 になる。ズレを見つけるには、比較する2つの数字が必要になる。基準と実績。想定と実態。この2つが揃って初めて、「見える化」が改善につながる。

基準はすでに業務の中にある

では「基準」は誰がどうやって作るのか。ここで多くの会社がつまずく。KPIを設定しなければ、目標を定義しなければ、と考え始めると、それだけで手が止まる。

しかし、実は基準はすでに業務の中に存在していることが多い。

  • 見積もり → 原価の基準。見積もりとは「この仕事はこれくらいのコストでできるはず」という想定そのもの
  • 納期回答 → 納期の基準。「いつまでに届けます」と約束した日付がそのまま基準になる
  • 発注数 → 入荷の基準。「100個発注した」なら「100個届くはず」が基準
  • 図面の指示値 → 品質の基準。「公差±0.1mm」がそのまま合否の基準

これらは経営者が新たに設定したKPIではない。日々の業務の中で自然に生まれている数字になる。見積もりは営業や生産管理が作っている。納期は顧客と約束している。発注は購買が出している。基準は最初から存在している。

問題は、この基準がデータとして残っていないことにある。

基準と実績がつながっていない

見積もりはExcelで作っているが、実績原価は会計ソフトにある。この2つを突合しようとしても、見積番号と会計データがつながっていない。手作業で1件ずつ照合するしかない。現実にはそんな手間はかけられないから、突合されないまま放置される。

納期回答は営業が口頭やメールで伝えているが、出荷日は別のシートに記録されている。予定と実績を並べて見る仕組みがない。「最近、納期遅れが多い気がする」という感覚はあっても、どれくらい遅れているのか、どの工程で遅れているのかは見えない。

発注は仕入先にFAXやメールで出しているが、入荷の記録は紙の受入伝票に書いている。発注と入荷を突合して「未入荷リスト」を出す仕組みがない。入荷漏れに気づくのは、現場から「材料がない」と言われたとき。

どのケースでも、基準のデータと実績のデータは社内のどこかに存在している。しかし、それぞれ別の場所に、別の形式で、別の人が管理している。突合できる形でつながっていない。 これが中小製造業の「見えていない」状態の正体になる。

内製DXの仕事は「測れるようにすること」

ここまでの話を整理すると、内製DXの担当者がやるべきことが見えてくる。

基準を作ることではない。基準と実績を突合できる仕組みを作ること。

基準——見積もりの想定原価、約束した納期、発注した数量——は、経営者や現場が業務の中で決めている。内製DXの担当者の仕事は、その基準と実績を同じキーでつなげて、ズレが見える状態にすること。

以前の記事で「受注生産のデータは見積番号から始める」と書いた。見積番号を起点にすれば、見積もり→受注→発注→製造→出荷→請求まで、一連のデータを1本の線でつなげられる。このつなげ方の設計が、内製DXの核になる。

受注生産のデータは見積番号から始める ── 受注起点では見えないフィードバックループ

あるいは、以前の記事で「ExcelのデータはいつでもDBに移せる形で持つ」と書いた。あの「データの文法」も、突合のための下準備になる。同じ品番で引けるようにする、日付の書式を揃える、1行1レコードにする。これらは基準と実績を突合するための前提条件になる。

Excelのデータは「いつでもDBに移せる形」で持つ ── データの文法という考え方

自分のプロフィールで「今ある商売の中からデータを見えるようにし、課題を見つけて改善する」と書いた。この「見えるようにする」の具体的な中身が、基準と実績の突合になる。

ズレが見えれば改善は自然に動く

基準と実績のズレが見えるようになると、改善は意外と自然に動き始める。

「見積もりより実績が20%高い案件が、先月5件あった」——この事実が見えれば、経営者は「なぜか」を知りたくなる。5件に共通するパターンがあるかもしれない。特定の工程で想定以上に時間がかかっているかもしれない。材料の歩留まりが悪いのかもしれない。

ズレの原因を調べる過程で、改善すべきポイントが具体的に見えてくる。「コストを下げろ」という漠然とした指示ではなく、「この工程の想定時間と実績のズレを縮めるにはどうするか」という具体的な問いになる。

以前の記事で紹介した、コスト低減も納期短縮も、具体的にやることはこの「ズレの可視化と是正」に帰着する。コストを下げるとは、見積もりと実績のズレを縮めること。納期を短縮するとは、予定と実績のズレをなくすこと。抽象的な目標が、ズレという形で具体化される。

まず1つの突合から始める

基準と実績の突合が大事だとして、どこから始めればいいか。

全部を一度にやろうとする必要はない。まずは1つ、最も身近で効果が出やすいところから始める。

多くの中小製造業にとって、最も始めやすいのは 見積もりと実績原価の突合 だと思っている。理由は2つ。まず、見積もりは必ず作っているので基準側のデータが存在する。次に、原価のズレは利益に直結するので経営者の関心が高い。

以前の記事で「管理精度の天井は経営者の判断力で決まる」と書いた。経営者が「知りたい」と思う情報から始めるのが定着の近道になる。見積もりと実績のズレは、ほぼすべての経営者が知りたい情報だろう。

管理精度の天井は、経営者の判断力で決まる

完璧な精度は要らない。70点でいい。大まかにでも「この案件は見積もりより高くついた」「この案件は想定内で収まった」がわかれば、改善の起点としては十分になる。

突合のために実績データを集める方法——何を・いつ・どこで・どう集めるかの設計——については、別の記事で書いている。

中小製造業の実績データ収集は「何と比較するか」から逆算する


このシリーズの他の記事:

シリーズ記事一覧・著者への相談はこちら →

内製DXの弱点を正直に書く ── 小さなツールの組み合わせで起きること

このシリーズで推してきたアプローチ

このシリーズでは一貫して、中小製造業の内製DXは「小さなツールの組み合わせ」で進めるべきだと書いてきた。Excel VBAで十分な領域はVBAで作る。必要なところだけデータベースや専用言語を使う。大きなパッケージを一括導入するのではなく、業務に合わせて小さな仕組みを少しずつ積み上げる。

この考え方は変わっていないし、中小製造業の体力や現場のリアルを考えれば、今でも最も現実的なアプローチだと思っている。

ただ、このやり方には弱点がある。そこを書かずにいるのはフェアではないので、正直に書いておく。

弱点:ツールとツールの「つなぎ目」で漏れる

小さなツールを組み合わせるということは、ツール間のデータの受け渡しが人の手で行われるということ。

たとえば、Excelの見積データから受注情報を別のシートに転記する。発注データを仕入管理のファイルに手で移す。検査結果をまた別のところに入力する。一つひとつのツールは業務にフィットしていても、ツール間の橋渡しは手作業になる。

この「つなぎ目」で何が起きるか。

転記漏れ。 あるツールに入力したデータを、次のツールに移し忘れる。受注したのに発注していない、発注したのに入荷を登録していない——こうした漏れは、つなぎ目が手作業である限り必ず発生する。

入力ミス。 数値の桁間違い、品番の打ち間違い。コピー&ペーストでも貼り先を間違えることがある。

タイミングのずれ。 あるツールではデータが更新されているが、別のツールにはまだ反映されていない。どちらが最新かわからなくなる。

もちろん、対策はある程度できる。コピー&ペーストで転記の手間を減らす、入力をマスタからの選択式にする、数値の範囲チェックを入れる。こうした工夫で頻度は下がる。しかし、つなぎ目が手作業である以上、ゼロにはならない。対策はできるが、構造的な弱点は残る。

統合システムならこの問題は起きにくい

ここは正直に認めるべきところで、統合された生産管理システムやERPには、この弱点がない。

統合システムでは、受注データを一度登録すれば、そこから発注、製造指示、出荷、請求まで一つのシステムの中でデータが流れる。ツール間の橋渡しが存在しないから、転記漏れも入力ミスも構造的に起きにくい。「受注したのに発注していない」はシステムがアラートで教えてくれる。

さらに、データが一箇所にあるから、工程の進捗も在庫も原価もリアルタイムで見える。小さなツールの組み合わせでは「あのファイルを開いて、あのシートを見て」となるところが、統合システムなら画面一つで済む。

それでも統合システムを勧めない理由

統合システムの利点は認めた上で、中小製造業に統合システムを勧めない理由は以前の記事で書いた通り。

「ERP」という言葉の解像度が低すぎる ── 中小製造業が本当に必要な仕組みを考える

業務がシステムの型に合わない。 受注生産・多品種少量の業務は標準化しにくい。パッケージの想定する業務フローと実際のフローが合わず、カスタマイズが膨らむか、業務をシステムに合わせることになる。

導入・維持コストが体力に合わない。 数十人規模の会社で数千万円の投資は現実的ではない。仮に導入できても、保守費用やバージョンアップのコストが続く。

変更に弱い。 業務が変わったときにシステムを改修するのに時間とコストがかかる。小さなツールなら翌日には直せる変更が、統合システムでは数週間〜数ヶ月かかることがある。

つまり、統合システムは「つなぎ目の問題」を解決する代わりに、「柔軟性の問題」を抱えている。どちらも弱点がある。どちらの弱点のほうが致命的かは、会社の規模と業務の性質で決まる。

ケアレスミスはシステムでは防ぎきれない

もう一つ、さらに根本的な話がある。

入力し忘れる、数字を見間違える、コピー先を間違える——こうしたケアレスミスは、どんなシステムを使っても完全にはなくならない。統合システムでも、最初のデータ入力が間違っていれば、そこから先は全部間違ったまま流れる。

小さなツールの組み合わせでは、つなぎ目が多い分だけケアレスミスの機会が増える。これは事実。しかし、統合システムでもミスは起きる。システムが変わっても人は変わらない。

現実的な対策は、ミスを防ぐ仕組みよりも、ミスに気づく仕組みを作ることになる。

  • 入力されていないデータを定期的に洗い出す(未発注リスト、未入荷リストなど)
  • 異常値を検出する(通常の発注量と大きく異なる、単価がゼロなど)
  • 工程の節目でデータの突合を行う

これは統合システムだろうと小さなツールだろうと、同じように必要な仕組みになる。以前の記事で「セキュリティは守り方より戻し方」と書いたが、データ品質も同じで、入力ミスは起きる前提で、早く検知して直す仕組みのほうが効果的

中小製造業のセキュリティは「守り方」より「戻し方」

弱点を知った上で選ぶ

このシリーズで推してきた「小さなツールの組み合わせ」は、つなぎ目で漏れるという構造的な弱点を持っている。統合システムにはこの弱点がない代わりに、柔軟性とコストの問題がある。

どちらを選ぶかは、弱点を知った上で判断すべき話になる。中小製造業——特に数十人規模の受注生産の現場——にとっては、つなぎ目の漏れを運用でカバーするほうが、統合システムの硬直性に苦しむよりも現実的だと、自分は考えている。

ただし、「小さなツールなら何も問題ない」とは言わない。つなぎ目が増えれば漏れも増える。だからこそ、以前の記事で「作る前にやめるを考える」と書いた。ツールの数が増えるほどつなぎ目が増える。不要なツールを減らすことは、つなぎ目の漏れを減らすことでもある。

中小製造業の内製DX ──「作る」前に「やめる」を考える

弱点のないアプローチは存在しない。弱点を知って、それをカバーする運用を組みながら進める。これが内製DXの現実的なやり方になる。


このシリーズの他の記事:

シリーズ記事一覧・著者への相談はこちら →

中小製造業の現場にタブレットを配っても定着しない ── 入力は「いつ・どこで」を設計する

「現場のデジタル化=タブレット」という思い込み

製造現場のデジタル化と聞くと、まず思い浮かぶのがタブレットの導入。作業者にタブレットを持たせて、作業実績や検査結果をその場で入力する。紙の帳票をなくしてペーパーレスにする。展示会やセミナーでよく見るデモは、だいたいこの形になっている。

自社でも検討し、テスト的にタブレットを現場に持ち込んだことがある。結論から言うと、定着しなかった。最終的に紙に戻した。

なぜタブレットが定着しなかったか

理由は一つではなく、複数の問題が重なった。

手が汚れる。 切削油、グリス、粉塵。製造現場では手が汚れた状態で作業することが多い。タッチパネルは汚れた手では反応しにくいし、画面が見えなくなる。毎回手を拭くのは現実的ではない。

壊れる・壊す。 工場の床はコンクリート。落としたら割れる。ケースを付けても衝撃に限界がある。工具や材料が飛んでくることもある。1台数万円のタブレットを現場に置いておくのは、コストとしても精神的にも気を遣う。

作業の手が止まる。 紙にペンでチェックを入れるのは一瞬。タブレットだと画面を開いて、該当の項目を探して、タップして——この数秒の差が、作業中のリズムを崩す。作業者にとっては「面倒」の一言になる。

手袋が使えない。 安全上の理由で手袋をしている作業が多い。静電容量式のタッチパネルは手袋では反応しない。対応手袋もあるが、現場で使っている手袋を変えるのは別のコストになる。

騒音で通知が聞こえない。 工場の中は機械の音で会話も難しい場所がある。タブレットからの通知音やアラートは聞こえない。

これらは「慣れの問題」「運用でカバー」と言われがちだが、実際に試してみると、慣れで解決する範囲を超えている。現場の作業者に無理を強いて定着させても、入力データの質が下がれば意味がない。

タブレットを否定しているわけではない

誤解のないように書いておくと、タブレットが現場に合う業種・環境はある。

クリーンルームのような清潔な環境なら、手の汚れや粉塵の問題はない。検査業務で写真を撮ってそのまま記録に残すような用途なら、タブレットのカメラは便利。組立工程で図面や手順書を表示する「閲覧用」としてなら、入力の問題も少ない。

問題は、自社の現場環境を見ずに「タブレット=正解」と決め打ちすること。切削、溶接、鋳造、プレス——油や粉塵が飛ぶ環境では、タブレットは向いていないことが多い。業種や工程によって判断が変わるのが当然で、「製造業ならタブレット」という一括りは乱暴になる。

紙のほうが優れている場面

製造現場で紙が使われ続けているのは、惰性だけが理由ではない。

速い。 ペンでチェックを入れる、数字を書く。デバイスの起動もログインも要らない。

壊れない。 油で汚れても読める。落としても踏んでも平気。水に濡れても乾けば読める。

コストがゼロに近い。 紙とペンは原価がほぼない。紛失しても損害がない。

教育が要らない。 誰でも使える。ITリテラシーに依存しない。

紙の弱点は、記録がそのまま残ること——つまりデジタルデータにならないこと。検索できない、集計できない、他のデータとつなげられない。この弱点が許容できる業務なら、紙のままでいい。

「紙のまま」で困る場面だけデジタル化する

逆に、データとして蓄積・集計・検索する必要がある業務は、どこかでデジタル化しなければならない。問題は「どこで」デジタルにするかになる。

多くの導入提案は「発生源入力」——データが生まれる現場でそのまま入力するのが効率的、という考え方に基づいている。理論的にはその通りだが、現場環境がそれを許さない場合がある。

自社で取った方法はこうだった。

現場の複数箇所に固定のPCを置いた。 タブレットではなく、据え置きのPC。キーボードとマウスで入力する。画面は大きいから見やすいし、汚れた手で触る必要がない(手を拭いてから触る場所、という位置づけができる)。

入力のタイミングを「作業の切れ目」にした。 作業中に入力させるのではなく、休憩に行くタイミングや作業の区切りで入力してもらう。リアルタイム性は多少落ちるが、作業のリズムを崩さない。

入力する項目を最小限にした。 以前の記事で「データの文法」について書いたが、現場で入力してもらうのは必要最小限のデータだけ。品番、数量、完了時刻。それ以外は事務所側で補完する。

Excelのデータは「いつでもDBに移せる形」で持つ ── データの文法という考え方

入力手段とデータ管理を分けて考える

ここでのポイントは、「現場でどう入力するか」と「データをどう管理するか」は別の問題だということ。

データ管理はデジタルのほうが圧倒的に優れている。検索、集計、紐づけ、トレーサビリティ——これは紙では無理。しかし、入力手段までデジタルにする必要があるかは、環境による。

現場の手元は紙で十分な場合がある。紙で記録したものを、作業の切れ目に固定PCで入力する。あるいは、紙の帳票を事務所で入力する。入力の手間は増えるが、現場の作業効率を落とさずにデータを残せる。

以前の記事で「手作業でできることしかシステムにできない」と書いた。入力手段も同じで、現場の作業者が無理なくできる方法でなければ、データの質は保てない。理論上の最適解より、現場が自然に続けられる方法のほうがデータは正確に残る。

手作業でできることしかシステムにできない ── 中小製造業の内製DXの正しい順番

「全部デジタル」も「全部紙」も極端

製造現場のデジタル化は、全か無かの話ではない。

  • 紙で十分な業務は紙のまま残す
  • デジタルで管理したいデータは、入力のタイミングと場所を設計する
  • タブレットは環境に合えば使う、合わなければ無理に導入しない

DXの目的は紙をなくすことではなく、必要なデータが必要なときに見える状態を作ること。入力が紙でも、最終的にデータが整理された形で残っていれば、目的は達成できる。手段にこだわって現場に負荷をかけるより、「データが残る仕組み」をどこに置くかを考えるほうが現実的になる。


このシリーズの他の記事:

シリーズ記事一覧・著者への相談はこちら →

中小製造業の業務プロセスは、ワークフローで「型」にして定着させる

マニュアルを作っても守られない

業務プロセスを整理したとき、多くの会社がやるのはマニュアルの作成。手順書を作って共有フォルダに置き、「これに従って作業してください」と通達する。

しかし現実には、マニュアルは作った直後しか読まれない。半年もすれば存在自体が忘れられ、以前の自己流に戻る。更新も止まり、実態とずれたまま残り続ける。ISOの審査前に慌てて直す——という光景は珍しくない。

以前の記事で「手作業でできることしかシステムにできない」と書いた。手作業でプロセスを検証し、ロジックを明確にする。ここまでは正しい。しかしその次のステップ——整理したプロセスをどうやって組織に定着させるか——については十分に書いていなかった。

手作業でできることしかシステムにできない ── 中小製造業の内製DXの正しい順番

マニュアルは「読めばわかる」が前提で、読むかどうかは本人任せ。だから守られない。プロセスを定着させるには、本人任せにしない仕組みが要る。

ワークフローは「型」になる

マニュアルは「読んで従う」が前提の受動的な道具。必要なのは、業務の流れそのものがシステムに組み込まれていて、次にやるべきことをシステムが案内する仕組みになる。ワークフローソフトがそれにあたる。

ワークフローソフトは、業務の流れをステップとして定義し、各ステップの担当者への通知、完了の記録、次のステップへの引き継ぎを自動で管理する。ステップを飛ばせない——これがマニュアルとの決定的な違いになる。

たとえば、顧客からのクレーム対応。「受付→原因調査→対策立案→対策実施→報告」という流れがあるとして、マニュアルに書いてあるだけなら「原因調査」を飛ばしていきなり「とりあえず交換します」で済ませる人が出てくる。ワークフローに載せれば、原因調査のステップを完了しない限り次に進めない。

これがワークフローの本質的な価値で、承認ルーティングではなく 「プロセスの型を強制する道具」 として機能する。

承認申請だけがワークフローではない

ワークフローと聞くと、有給休暇の申請や稟議書の承認を思い浮かべる人が多い。確かにそれもワークフローだが、本来の適用範囲はもっと広い。

たとえば図面の承認フロー。設計→チェック→承認というプロセスをワークフローに載せれば、未チェックの図面が現場に流れることを防げる。注文の承認も同じで、金額や取引先の条件に応じて承認ルートを分岐させれば、権限を超えた発注を防止できる。

入社時の手続きにも使える。「PCの手配→アカウント発行→安全教育→OJT担当の割り当て」といった一連のタスクをワークフローに載せれば、「あの手続きが漏れていた」という事故が減る。人の入れ替わりが多い職場ほど効果が大きい。

ポイントは、ワークフローを「申請と承認の道具」ではなく 「業務プロセスを型にする道具」 として見ること。有給申請のような総務系の定型処理だけでなく、製造業の本業——図面管理、受発注、品質管理——の業務フローに組み込んで初めて、本来の力を発揮する。

なぜ中小製造業でも必要になってきたか

「うちは少人数だから、口頭で十分」——そう思っている会社は多い。実際、社員20〜30人の会社では、顔が見える距離で仕事をしているから、なあなあでも回ってきた。

しかし最近、外部から型を求められる場面が増えている。

顧客の要求水準が上がっている。 大手の取引先からISO認証を求められたり、品質管理体制の監査を受けたりする場面が増えた。「やっています」だけでは通らず、プロセスが文書化され、記録が残り、逸脱があれば検知できることを示す必要がある。

属人化のリスクが顕在化している。 ベテランの退職や急な欠勤で、「あの人しかやり方を知らない」業務が止まる。以前の記事で属人化のトリアージについて書いたが、トリアージの結果「これは標準化すべき」と判断した業務を、どうやって標準化するかの手段が要る。

中小製造業は「脱属人化」ではなく「属人化のトリアージ」

人の入れ替わりが増えている。 中小製造業でも中途採用や派遣スタッフが増えた。新しい人にプロセスを教えるとき、マニュアルを渡して「読んでおいて」では不安が残る。ワークフローがあれば、システムが次のステップを案内してくれる。

全部載せる必要はない

ここで「では全業務をワークフロー化しましょう」となるのは危険。以前の記事で「作る前にやめるを考える」と書いたが、ワークフロー化にも同じ原則が当てはまる。

中小製造業の内製DX ──「作る」前に「やめる」を考える

ワークフローに載せるべき業務:

  • 記録が求められる業務。 ISO、顧客監査、法規制で「誰が、いつ、何を判断したか」を残す必要があるもの。クレーム対応、品質逸脱、設計変更など
  • ステップの飛ばしがリスクになる業務。 検査工程を飛ばして出荷する、承認なしに発注する——飛ばすと損害が出るプロセス
  • 人の入れ替わりが多い業務。 手順を教える側の負荷が高いもの

ワークフローに載せなくていい業務:

  • 判断が速いほうが価値がある業務。 現場での即時判断、日常的な報告、軽微な手配。ワークフローに載せるとステップが増えて遅くなる
  • 頻度が低い業務。 年に数回しか発生しないものにワークフローを組むのは、設定コストに見合わない
  • 内容が毎回違う業務。 定型化できないものはワークフローの「型」に収まらない

手作業 → ワークフロー → 内製ツールの三段階

以前の記事で整理した「内製DXの正しい順番」にワークフローを位置づけると、こうなる。

手作業でできることしかシステムにできない ── 中小製造業の内製DXの正しい順番

第一段階:手作業でプロセスを回す。 ロジックを検証し、不要な手順を見つけて廃止する。ここでプロセスの骨格が固まる。

第二段階:ワークフローでプロセスを型にする。 手作業で回せるようになったプロセスをワークフローソフトに載せる。ステップの飛ばしを防ぎ、記録を自動で残す。プロセスが「個人の習慣」から「組織の仕組み」に変わる。

第三段階:必要に応じて内製ツールで自動化する。 ワークフローで回してみると、「このステップはデータを転記しているだけ」「この判断は数値の閾値で自動化できる」という部分が見えてくる。そこだけをVBAや専用言語で自動化する。

多くの会社は第一段階を飛ばして第三段階に行こうとして失敗する(前回の記事で書いた通り)。しかし第二段階を飛ばして第三段階に行こうとするケースも同じくらい多い。プロセスが定着していない状態で自動化しても、自動化されたプロセスが使われない。

手作業でできることしかシステムにできない ── 中小製造業の内製DXの正しい順番

ワークフローソフトの選び方

中小製造業で使うなら、大げさなBPMツールは要らない。選ぶ基準はシンプル。

フローの変更が自分たちでできること。 業務プロセスは変わる。変更のたびに業者に依頼するのでは、変化への追従が遅れる。ノーコードでフローを組み替えられるものを選ぶ。

データのエクスポートができること。 以前の記事で書いた原則と同じで、ワークフローに蓄積された記録データを外部に取り出せることが重要。ワークフローソフトを変えるときに、過去の記録が人質にならないようにする。

中小製造業のIT環境は「入れ替えられる設計」で組む ── OSSとSaaSの使い分け

過剰な機能を求めないこと。 承認ルート、ステップ管理、記録の保持。中小製造業のワークフローに必要な機能はこの程度。AI連携やBI機能は、あっても使わない。

プロセスを変えたいなら、型を変える

ワークフローの最も実用的なメリットは、プロセスを変更したいときに、ワークフローの定義を変えれば全社に即座に反映されること。

マニュアルだと、文書を更新して配布して「変わりました」と周知して——それでも古いやり方で続ける人がいる。ワークフローなら、フローの定義を変えた瞬間から、全員が新しいプロセスで動くことになる。古いやり方では先に進めないから。

業務プロセスの改善は、変えることよりも定着させることのほうが難しい。マニュアルは定着の道具としては弱い。ワークフローは型として強制力がある。中小製造業でも、記録を求められる業務やステップの飛ばしがリスクになる業務から、ワークフローで型を作っていく価値はある。


このシリーズの他の記事:

シリーズ記事一覧・著者への相談はこちら →

中小製造業のExcelデータ、帳票型でも「行列が揃っていれば」救える

帳票型のデータは、どこにでもある

以前の記事で、Excelのデータは「いつでもDBに移せる形」で持つべきだと書いた。1行1件で上から下に積んでいく、いわゆる縦持ちの形式。データベースに入る形で持っておけば、集計もVBAでの自動化もスムーズにできる。

Excelのデータは「いつでもDBに移せる形」で持つ ── データの文法という考え方

この考え方自体は変わっていない。しかし現実の中小製造業を見ると、この形式でデータを持っている会社はほとんどない。

圧倒的に多いのは、帳票型のデータ。月別にシートが分かれている実績表、日付ごとの日報シート、案件別のブック。横軸に日付や月が並び、縦軸に品目や工程が並ぶクロス集計のレイアウト。Excelが存在する限り、この形式はなくならないだろう。

帳票型が選ばれる理由

帳票型がこれほど広く使われているのには理由がある。

一覧性が高い。 月の実績を一枚のシートで見渡せる。どの品目がどの日に何個出たのかが、目で追える。縦持ちのデータベース形式だと、同じ情報を見るためにフィルタやピボットテーブルを使う必要がある。

そのまま印刷できる。 現場に紙で貼り出す文化がある製造業では、これは大きい。縦持ちのデータを印刷しても、そのままでは使い物にならない。

入力がしやすい。 今日の実績を今日のセルに入れるだけ。行を追加する必要もないし、日付を毎回入力する必要もない。

つまり帳票型は、人間が日常的にデータを入力し、確認し、共有するための形式としては合理的。以前の記事で否定したかったのはこの形式そのものではなく、これを「データの唯一の保管場所」にしてしまうことだった。

Excelのデータは「いつでもDBに移せる形」で持つ ── データの文法という考え方

救えるかどうかの分かれ目は「行列の固定」

帳票型のデータが社内に何年分も蓄積されている。この現実に対して、自分の考えはこうなる。

行と列のレイアウトが固定されていれば、データは救える。

たとえば月次の生産実績表。毎月同じフォーマットで、A列が品目名、B列以降が日付ごとの数量。この形式が12ヶ月×数年分あったとしても、VBAやスクリプトで一括して縦持ちに変換できる。セルの位置が決まっているなら、プログラムは確実にデータを拾える。

レイアウトが固定されているなら、帳票型から縦持ちへの変換は技術的には難しくない。1シートから読み取るロジックを一度書けば、あとは全シートに同じ処理を回すだけになる。

一方、自由配置のシートは救えない。

セル結合が多用され、データの位置がシートごとに違い、余白や注釈が任意の場所に入っている。こうなるとプログラムで読み取る前提が成り立たない。人間が目で見れば情報はわかるが、機械的にデータを拾うことは不可能に近い。

この線引きは明確で、レイアウトが固定されているか、されていないか。これだけで、過去データが資産になるか、ただのアーカイブで終わるかが決まる。

今すぐやるべきことは一つ

過去のデータを今すぐ全部変換する必要はない。以前の記事でも書いたが、崩れたデータを遡って直す作業は現実的ではないことが多い。

Excelのデータは「いつでもDBに移せる形」で持つ ── データの文法という考え方

しかし、これだけは今すぐやったほうがいい。

帳票型シートのレイアウトを固定する。

具体的には:

  • 行と列の構造を統一する。 今月のシートと来月のシートで、列の並びや行の数が変わらないようにする
  • セル結合を使わない。 結合セルはプログラムから見ると位置がずれる原因になる。見た目を揃えたいなら「選択範囲内で中央」を使う
  • データ領域と見た目の装飾を分ける。 タイトルや罫線、色は好きにしていい。ただしデータが入るセルの位置は動かさない
  • テンプレートから複製する。 新しいシートやブックを作るとき、毎回ゼロから作らず、テンプレートをコピーする

帳票型をやめる必要はない。帳票型のまま、レイアウトだけ揃える。これだけで、将来データを吸い出したくなったときの難易度が劇的に下がる。

変換は後からでいい

レイアウトが固定された帳票型データがあれば、必要になったタイミングで縦持ちに変換できる。

たとえば「過去2年分の生産実績を製品別に集計したい」となったとき、24枚の月次シートから品目と数量をVBAで読み取って、1行1件のデータシートに出力する。レイアウトが固定されていれば、この変換処理は数十行のコードで書ける。

全部を一度に変換する必要もない。使うデータだけ、使うタイミングで変換すればいい。レイアウトさえ揃っていれば、「いつでも変換できる」という状態を維持できる。これは以前の記事で書いた「いつでもDBに移せる形で持つ」のもう一つの形と言える。理想的な縦持ちではないが、変換可能な状態を保っているという点で、データの再利用性は確保されている。

Excelのデータは「いつでもDBに移せる形」で持つ ── データの文法という考え方

自由配置のデータにも手段はゼロではない

レイアウトが崩れたデータは救えないと書いたが、最近はAIによるOCR・データ抽出の精度が上がっている。ExcelやPDFの帳票をAIに読ませて、テーブル形式に変換するといった手段は選択肢として存在する。

ただし、VBAで固定レイアウトを読み取る方法と比べると、確実性が違う。VBAはセルの位置を指定して読むだけだから、100回やれば100回同じ結果が返る。AIによる抽出は精度が高くなってきているとはいえ、読み取りミスや解釈の揺れが起きる可能性がある。件数が多いほど、目視での確認コストが積み上がる。

「どうしても過去データを救いたいが、レイアウトが揃っていない」という場面では検討する価値はある。しかし、これから作るデータのレイアウトを揃えるほうが、はるかに確実でコストも低い。AIは最後の手段であって、最初の戦略にはならない。

帳票型を否定しない、自由配置を否定する

帳票型のExcelは、現場の運用としては合理的な選択肢。そのまま使い続けて構わない。

問題は帳票型かどうかではなく、データの位置が決まっているかどうか。行列が固定されていれば、いつでもプログラムでデータを拾える。自由配置になっていると、そのデータは人間が目で見ることしかできない。

今すぐデータの持ち方を変える必要はない。ただ、レイアウトだけは揃えておく。帳票型のシートをテンプレートから複製するだけでいい。この小さな習慣が、将来データを活用したくなったときに、選択肢を残してくれる。


このシリーズの他の記事:

シリーズ記事一覧・著者への相談はこちら →

ローコード・ノーコードは中小製造業に合うのか ── 市民開発とExcel VBAの境界線

ローコード・ノーコードの広がり

ここ数年、ローコード・ノーコードという言葉を聞く機会が増えた。Power Apps、kintone、Appsheet。プログラミングなしで業務アプリが作れるという触れ込みで、大手企業を中心に導入が進んでいる。

背景にあるのは「市民開発」という考え方で、IT部門ではなく現場の担当者が自分で業務ツールを作る。これ自体は理にかなっている。業務を一番よく知っている人が、自分の手で仕組みを作れるなら、それが最も速い。

ただ、この流れを見ていて一つ面白い矛盾がある。

属人化の扱いが揺れている

DXの文脈では「属人化を解消しましょう」がほぼ定番の提言になっている。特定の人しかできない業務はリスクだから、標準化・マニュアル化しましょう、と。

一方で、市民開発は「現場の個人がツールを作る」ことを推奨している。作った人がいなくなったらどうするのか、という問いに対する答えは、正直あまり見かけない。

これは別に業者の言っていることが間違っているわけではない。属人化の解消と市民開発は、対象としているレイヤーが違う。業務プロセスの属人化は確かにリスクだが、ツールを作る能力が特定の人に集中すること自体は、中小企業では避けようがない現実でもある。以前の記事で「属人化のトリアージ」として整理したが、何を標準化して何を属人のまま許容するかは、一律に決められる話ではない。

中小製造業は「脱属人化」ではなく「属人化のトリアージ」

ローコードが選ばれる合理的な理由

ローコード・ノーコードが大手企業で支持されている理由は、技術的なハードルの低さだけではない。もっと実務的な理由がある。

配布と改修の管理ができる。 ここがExcelとの最大の違いだと思っている。Excelで作った業務ツールは、ファイルをコピーすれば誰でも使える。しかし裏を返せば、配布したファイルを誰かが勝手に改修しても止められない。数式を壊す、マクロを無効にする、構造を変える。こういったことが日常的に起きる。

ローコード・ノーコードのプラットフォームでは、アプリはサーバー上で一元管理される。利用者はアプリを「使う」だけで、中身を触ることはできない。改修できるのは作成者だけ。この構造は、数十人〜数百人規模の組織でツールを展開するときに大きな意味を持つ。

誰が何を使っているかが見える。 IT部門の立場からすると、社内にどんなツールがあり、誰が使っているかを把握できることは重要になる。Excelファイルが各自のPCに散らばっている状態では、この把握がほぼ不可能。ローコード・ノーコードのプラットフォームなら、管理画面からアプリの一覧、利用状況、作成者が確認できる。

権限管理が標準装備されている。 閲覧だけの人、編集できる人、管理者。こうした権限の切り分けがプラットフォーム側で用意されている。Excelファイルに対して同じことをやろうとすると、フォルダのアクセス権やSharePointの設定など、別のレイヤーで対応する必要がある。

こうした特徴は、組織としてのIT統制を求められる環境では合理的な選択になる。大手企業がローコード・ノーコードを採用する背景には、こうした管理面のメリットが大きい。

データの持ち方という視点

ローコードのプラットフォームにデータを預けるということは、そのプラットフォームに依存するということでもある。以前の記事で「データが特定のツールに閉じ込められない状態を維持する」と書いたが、この原則はローコードにも当てはまる。

中小製造業のIT環境は「入れ替えられる設計」で組む ── OSSとSaaSの使い分け

ただ、これはローコードの欠点というより、トレードオフとして理解したほうがいい。Excelファイルが各自のPCに散らばっている状態は、確かにデータは手元にあるが、統制が取れていない。ローコードのプラットフォームにデータを集約すれば統制は取れるが、プラットフォームへの依存が生まれる。

大手企業がこのトレードオフでプラットフォーム側を選ぶのは、組織規模を考えれば自然なことだと思う。数百人の社員が使うツールのデータが個人のPCに散らばっていたら、それこそ管理不能になる。

中小製造業ではどうか

では中小製造業、特に多品種少量の受注生産をやっている会社ではどうか。

自分の結論としては、ローコード・ノーコードが最適な選択肢になるケースはかなり限られると考えている。

組織の規模が違う。 ローコードの管理面のメリットは、ある程度の人数がいて初めて効いてくる。社員数十人の会社で、ツールを使う人が5〜10人程度なら、Excelファイルの管理で困る場面はそこまで多くない。誰が何を使っているかも、声をかければわかる距離感にある。

業務の変化速度に対する柔軟性。 多品種少量の受注生産では、業務プロセスが頻繁に変わる。ローコード・ノーコードは「用意された部品の組み合わせ」で作るため、プラットフォームが想定していない要件に当たると途端に行き詰まる。Excelなら力技でも何とかなる場面が、ローコードだと「できない」で終わることがある。

コストの問題。 ローコード・ノーコードはユーザー数に応じたライセンス費用がかかる。月額数百円のプランもあるが、業務で本格的に使おうとすると一人あたり数千円は必要になる。中小企業にとってこの固定費は軽くない。Excelは既にライセンスがあるケースがほとんどで、追加コストがかからない。

データの主権。 これは規模に関係なく重要な話で、ローコードのプラットフォームに業務データを預けるということは、そのプラットフォームが値上げしたり、サービスを終了したりしたときに、自社のデータと業務ロジックが人質になるリスクを抱えるということ。中小企業にとって、このリスクは大手以上に重い。代替手段を検討する体力が限られているからこそ、データは自分の手元に置いておきたい。

「管理のしやすさ」と「自由度」のバランス

結局のところ、ローコード・ノーコードとExcel VBAの選択は、組織として何を優先するかの問題になる。

管理のしやすさを優先するなら、ローコード・ノーコード。 配布管理、権限管理、利用状況の把握。組織としてのIT統制が求められる環境では、これらの機能が標準で備わっていることの価値は大きい。

自由度とデータの主権を優先するなら、Excel VBAや内製プログラミング。 業務の変化に柔軟に対応でき、データは自分の手元にある。ただし管理は自分たちでやる必要がある。

中小製造業の場合、組織の規模と業務の特性を考えると、後者のほうが合っていることが多い。Excelの「誰でも触れてしまう」という特性は、裏を返せば「誰でも直せる」「誰でも改善できる」ということでもある。この柔軟さは、多品種少量の受注生産で日々変化する業務に対応するうえで、むしろ強みになる。

管理面の不安があるなら、以前の記事で書いたようにExcelのシート構造を整理し、データシートとUIシートを分離するだけでも、かなりの部分は解消できる。ツールが大きくなって管理が追いつかなくなったら、そのときはローコードではなく、C#やPythonなどの専用言語にステップアップするほうが、長期的にはデータの主権を保ったまま保守性を確保できる。

中小製造業に「脱Excel」は必要か


このシリーズの他の記事:

シリーズ記事一覧・著者への相談はこちら →

中小製造業の内製DXと外注の線引き ──「自社固有」か「汎用」かで決める

小回りのきく業者は中小製造業の味方

中小製造業にとって、大手SIerは現実的な選択肢になりにくい。予算規模が合わない上に、パッケージ化された提案は受注生産・多品種少量の現場にそのまま当てはまらないことが多い。

自分の経験でも、中小の現場でうまくいっているのは、小規模で小回りのきく業者との付き合いだった。いわゆる「御用聞き」タイプの業者で、こちらの事情を理解した上で、必要なときに必要なだけ対応してくれる。電話一本で動いてくれるスピード感は、中小にとって大きな価値がある。

ただし、この「何でもやってくれる便利さ」には落とし穴がある。

線引きの基準は「自社固有かどうか」

業者に頼むとき、こちらが内容を理解した上で任せているのと、よくわからないから全部お願いしているのとでは、まったく意味が違う。前者は対等なパートナーとして付き合える。後者は、提案の良し悪しも判断できないまま、言い値で進むことになる。

では、丸投げにならないために全部を理解すべきかというと、そうではない。

たとえばネットワークやサーバーのインフラ。自分のところでもインフラは業者に完全に任せている。インフラの知識は汎用的なもので、製造業だろうとサービス業だろうと基本は同じ。ここはプロに任せた方が効率がいい。

一方、自社の見積もりの構造、工程の流れ、原価の考え方、データの持ち方。これらは自社固有の知識で、外の人間がどれだけ優秀でも、本質的には社内の人間にしかわからない。

汎用的な領域は業者に任せていい。自社固有の領域は、自分たちで理解していなければならない。

理解がないと「値段」でしか選べない

自社固有の領域を理解していないとき、外注先をどう選ぶか。中身がわからなければ、比較できるのは値段だけになる。

ある会社から相談を受けた話。以前、別の外注にExcel VBAと専用ソフトの組み合わせで作ってもらった仕組みがあり、それをExcel VBAだけで作り直してほしいという依頼だった。前の外注はかなり安価でやっていたらしい。今回は「専用ソフトの部分が要らないぶん、もっと安くできるだろう」という前提での相談だった。

その会社の業務にとって重要なロジックが入っている仕組みだった。にもかかわらず、「やりたいことは説明できるから、実装だけしてもらえればいい」という感覚で話が進んでいた。

手作業でできることしかシステムにできない ── 中小製造業の内製DXの正しい順番

この話に限らず、自分が何を頼んでいるかの解像度が低いと、値段の比較しかできなくなる。 「安い方がいい」は、中身を評価する基準がないときに出てくる判断軸。 そして安さで選ぶと、相手もそれなりの対応になる。結果として、必要な情報がこちらに残らないまま納品だけが行われ、次もまた別の業者に値段で発注する——というループに入る。

これは別の記事で書いた「値決めできない」問題の裏面でもある。自社の製品に値段をつけられないのと、他人の仕事を値段でしか評価できないのは、同じ構造の問題。 理解がなければ、売る側も買う側も値段でしか判断できなくなる。

中小製造業の「値決めできない」問題に、内製DXはどこまで効くか

知識のロックインが一番深い

自社固有の領域を理解しないまま外注を続けると、「業者が作ったシステムを、業者にしか直せない」という依存関係が生まれる。技術的なロックインよりも、 知識のロックインの方が根が深い。 技術は乗り換えられるが、自社業務の理解を外に持っていかれると、取り戻すのが難しくなる。

見落としがちなのが、業者との関係が特定の担当者に依存しているケース。自分が見た例では、こちらの担当者が異動で変わったことで、業者との暗黙の前提がすべて崩れた。やり取りの経緯や判断の背景が担当者の頭の中だけにあると、人が変わった瞬間にすべてが失われる。

中小製造業の仕入先との関係は、担当者の頭の中にしかない

逆に、自社固有の領域を自分たちで扱えるようになると、業者との付き合い方が変わる。「何をやってほしいか」を明確に伝えられるので、業者は本来の強みである技術力とスピードを発揮しやすくなる。依存が協業に変わる。

ポイントは、業者の規模ではなく 知識がどこにあるか になる。大手がドキュメントを残してくれても、読んで理解できる人が社内にいなければ紙の束でしかない。小規模の業者に丸投げして納品物だけ受け取るのも、ベンダーロックインの小規模版になるだけ。

100%内製ではなく「8割内製、2割外部」

内製とは、全部を自分でやることではなく、自社固有の部分を自分で理解・管理できる状態のこと。

100%内製を目指すから非現実的に見える。コモディティ業務はパッケージで割り切り、インフラは業者に任せる。自社の見積もり構造、工程の流れ、原価の考え方といった固有の領域は、内製を軸にする。

自社に必要な8割は内製でカバーし、残り2割は外部の力を借りる。そしてその2割の相手が、丸投げ先ではなく、こちらの事情を理解して一緒に作れる人間であれば、知識も社内に残る。この組み合わせが、中小製造業の体力に合った現実解だと考えている。

中小製造業のDX、どの手段が正解か ── 再現性のある内製化のレベル感


このシリーズの他の記事:

シリーズ記事一覧・著者への相談はこちら →

手作業でできることしかシステムにできない ── 中小製造業の内製DXの正しい順番

システム化から始めたがる問題

内製DXの相談で多いのが、「この業務をシステム化したい」という話から始まるケースになる。気持ちはわかるが、ここにはよくある落とし穴がある。

「システム化したい」が先に来ると、ツール選定や技術検討から始まってしまう。どの言語で作るか、Excelで済むかデータベースが要るか、クラウドか社内サーバーか。しかし、その業務のロジックがそもそも明確でなければ、どんな道具を選んでも作れない。

システムとは、人間がやっていることを機械に置き換えるものになる。置き換えるためには、何をどういう順番で、どういう条件で判断しているかが明確でなければならない。つまり手作業でできていないことは、システムにもできない

手作業でできない=ロジックがわかっていない

「手作業ではやっているが、大変だからシステム化したい」——これは正しい。手作業で回せている業務のシステム化は、ロジックが明確になっているから設計できる。

問題は、「手作業ではうまく回っていないが、システムを入れれば解決するはず」というケースになる。これは高い確率で失敗する。

手作業でうまく回っていないということは、以下のどれかが起きている。

  • 業務の手順が定まっていない。 人によってやり方が違い、統一されたルールがない
  • 判断基準が曖昧。 「ベテランの勘」で処理されていて、条件分岐を言語化できない
  • そもそもその業務の目的が不明確。 何を達成するための業務なのかが曖昧

こうした状態でシステムを作ろうとすると、要件定義の段階で行き詰まる。「この場合はどうしますか?」という質問に誰も答えられない。仕様が固まらないまま作り始めると、出来上がったものは「誰の業務にも合わない」ツールになる。

なお「ベテランの勘」で動いている業務は、言語化できなくても安定して機能しているなら、無理にシステム化しない判断もある。どの業務を仕組み化すべきかのトリアージについては以前の記事で書いた。

中小製造業は「脱属人化」ではなく「属人化のトリアージ」

手作業で回すことはロジックの検証になる

システム化の前に手作業で回すことを勧めると、「それでは効率が悪い」と言われることがある。しかし、手作業で回すことの目的は効率化ではなく、ロジックの検証になる。

手作業で業務を1回通してみると、以下のことがわかる。

  • 実際に必要なデータは何か。 想定していたデータの半分は使わず、想定していなかったデータが必要になることは珍しくない
  • 判断の分岐点はどこか。 「Aの場合はこう、Bの場合はこう」というロジックが、手を動かして初めて明確になる
  • 例外処理は何か。 正常系だけなら簡単だが、現実には例外が山ほどある。手作業で回すと例外パターンが見えてくる

これらはヒアリングだけでは見えにくい。以前の記事で現場と話す時間の重要性を書いたが、話を聞くだけでは「普段どうやっていますか」の回答は正常系に偏りがちになる。自分で手を動かすか、現場に隣で見させてもらうかして、実際の業務を一通り体験すると、聞いていた話と実態の差に気づくことが多い。

中小製造業の内製DX ── 成否は「話す時間」があるかどうかで決まる

手作業で回すと「やめるべき業務」も見える

手作業で業務を通してみると、ロジックの検証だけでなく、そもそも不要な手順が見えてくることがある。

以前の記事で、システム化の前に「やめる」を考える廃止型のDXについて書いた。しかし、やめるべき業務を見つけるのは簡単ではない。依頼として「これは不要です」とは上がってこないし、長年続いている業務は存在自体が当たり前になっている。

中小製造業の内製DX ──「作る」前に「やめる」を考える

手作業で一通り回してみると、「この手順、何のためにやっているんだろう」という疑問が自然に出てくる。頭で考えているだけでは気づかなかった無駄が、手を動かすと見える。

あるいは、手作業で回した結果「これは手作業のままで十分に回る」とわかることもある。月に数回しか発生しない業務をシステム化するより、手作業のままにしておくほうが合理的な場合は少なくない。システム化の判断自体が、手作業で回してみて初めて正確にできる。

内製DXの正しい順番

ここまでの話を整理すると、内製DXには正しい順番がある。

多くの会社がやりがちな順番:

  1. 「この業務をシステム化したい」と決める
  2. ツールや技術を選ぶ
  3. 作り始める
  4. 要件が固まらず迷走する、または作ったが使われない

うまくいく順番:

  1. まず手作業で業務を回してみる(ロジックの検証)
  2. 不要な手順があれば廃止する(廃止型DX)
  3. 残った手順を整理して、使う人と話しながら設計する
  4. 手作業で検証済みのロジックをシステムに落とし込む

1が抜けると、ロジックが不明確なまま設計に入ることになる。2が抜けると、不要な業務をシステム化してしまう。3が抜けると、使われないツールができる。

このシリーズで書いてきたことは、すべてこの順番の中に位置づけられる。データの持ち方を正す(1の中で見えてくる)、やめる業務を見つける(2)、現場と話す(3)、ツールを作る(4)。どれも順番を飛ばすと効果が出ない。

この順番は、内製DXの着手順序全体とも重なる。以前の記事でDXの地固め——コミュニケーション基盤の確立、現状把握、保全——について書いたが、そこで言う「現状把握」は手作業での業務検証と直接つながっている。

中小製造業の内製DXは「改善」の前に「地固め」から始める

手作業を「遠回り」と思わないこと

手作業で回す時間を「無駄」や「遠回り」と感じる気持ちはわかる。DX担当者としては早くツールを作りたいし、経営者からも「いつできるのか」と聞かれる。

しかし、ロジックが検証されていない状態で作り始めると、手戻りのコストのほうがはるかに大きくなる。作り直し、仕様変更、使われないまま放置——これらの時間とコストに比べれば、手作業で1〜2週間回してみることは安い投資になる。仕入管理の仕組み化を何度か手がける中で、要件定義を急いで進めた場合の手戻りは、手作業で検証してから設計した場合の数倍かかることが多かった。

手作業でできることしかシステムにできない。逆に言えば、手作業でできるようになったものは、確実にシステム化できる。この順番を守るだけで、内製DXの成功率は大きく変わる。


このシリーズの他の記事:

シリーズ記事一覧・著者への相談はこちら →

中小製造業の内製DX ── 成否は「話す時間」があるかどうかで決まる

工数削減型は普及しやすい、それでも定着しない場合がある

以前の記事で、内製DXには「管理精度型」と「工数削減型」があり、工数削減型は使う人自身にメリットがあるため自然に広まりやすいと書いた。この考えは変わっていない。作業が楽になるツールは、押し付けなくても使ってもらえることが多い。

中小製造業の内製DXには「管理精度型」と「工数削減型」がある

しかし経験上、工数削減型であっても定着しないケースはある。機能は揃っている。操作も難しくない。使えば確かに楽になる。それでも現場に渡しても使われない。

この原因を「現場のITリテラシーが低い」「変化を嫌う体質」と片付けてしまうケースは多い。しかし自分の経験では、使われない原因のほとんどは、ツールの問題でも現場の問題でもなく、DX担当者と現場の間で十分に話す時間がなかったことにある。

当事者意識は説明会では生まれない

ツールを作り終えてから説明会を開く。操作方法を教えて、マニュアルを配る。「来月からこれを使ってください」と伝える。

このやり方で定着することもあるが、うまくいかないことのほうが多い。理由は単純で、現場の人にとってそのツールは「他人ごと」だからになる。自分が頼んだわけでもない、自分の困りごとから出発したわけでもないツールに対して、当事者意識を持てというほうが無理がある。

当事者意識は、操作説明では生まれない。作る前から話していて、自分の声が反映されていると感じたときに生まれる。

飲みに行く話ではない

コミュニケーションが大事だと言うと、「飲み会を増やせ」「雑談の機会を作れ」という話に聞こえるかもしれない。否定はしないが、ここで言いたいのはそういう話ではない。

必要なのは、業務時間の中に、使う人と話す時間が確保されていること。これだけになる。

「今の作業で一番面倒なのはどこですか」「この帳票はどういう流れで使っていますか」「こういう画面にしようと思っているんですが、どう思いますか」。こうした会話が、ツールを作り始める前と、作っている途中に、十分な回数行われているかどうか。

特別な仕掛けは何も要らない。話す。聞く。見せる。また話す。この繰り返しだけで、ツールの精度も定着率も大きく変わる。

DX担当者は「開発者」ではなく「通訳」

内製DX担当者の仕事は、コードを書くことだと思われがちになる。実際、経営者から見ても「ツールを作る人」として認識されていることが多い。

しかし現実には、DX担当者の仕事の中で最も時間をかけるべきなのは、現場の業務を理解するために人と話すことになる。

現場の人は自分の業務の困りごとを言語化できないことが多い。「なんとなく面倒」「昔からこうやっている」「Excelが重い気がする」。こうした曖昧な不満の裏に、本当の課題が隠れている。

DX担当者の仕事は、この曖昧な不満を聞き取って、システムで解決できる形に翻訳すること。つまり現場の言葉と技術の言葉の通訳になる。通訳するためには、まず現場の言葉を聞く時間が要る。

話す時間がなぜ確保されないか

これだけ単純なことが、実際にはできていない会社が多い。理由はいくつかある。

DX担当者が兼任で忙しい。 中小企業のDX担当者は情シスや総務との兼任であることが多い。日常の問い合わせ対応やPC管理に追われて、現場に出向いて話す時間がそもそも取れない。

「話している時間」が仕事に見えない。 コードを書いていれば成果物が見える。しかし現場で話を聞いている時間は、外から見ると仕事をしていないように見える。経営者がこの時間の価値を理解していないと、「早く作ってくれ」というプレッシャーになる。

現場も忙しい。 話を聞きに行きたくても、製造の現場は手が止められない。まとまった時間を取ってもらうのが難しい。

これらは構造的な問題であり、DX担当者の努力だけでは解決しにくい。以前の記事で、DXは1人では回らず経営者の協力が必要だと書いた。ここでも同じことが言える。経営者が「現場と話す時間」をDX担当者の仕事として認め、その時間を確保する環境を作る必要がある。

中小製造業の内製DXには「管理精度型」と「工数削減型」がある

話すことで得られるもの

DX担当者が現場と話す時間を確保できると、ツールの定着率が上がるだけでなく、それ以上の効果が出てくる。

作るべきものが見える。 依頼ベースで動いていると「これをシステム化して」という要望に応えるだけになる。しかし現場と日常的に話していると、依頼にはならないが実は大きな非効率が見えてくる。以前の記事で「やめるべき業務を見つける」話を書いたが、やめるべき業務は依頼としては上がってこない。現場の日常を知っている人間だけが気づける。

中小製造業の内製DX ──「作る」前に「やめる」を考える

信頼関係ができる。 新しいツールへの抵抗感は、変化への不安からくる。しかし「あの人が作るなら」「前にちゃんと話を聞いてくれた人だから」という信頼があると、ハードルは下がる。これは飲み会で得る信頼ではなく、仕事の中で「この人は自分たちの業務を理解している」と感じてもらえるかどうかの話になる。

手戻りが減る。 作り終えてから「思っていたのと違う」と言われるのが最も痛い。途中で見せて話していれば、方向修正は小さくて済む。開発効率の観点からも、話す時間への投資は回収できる。

技術力に加えて、もう一つ

内製DXの担当者に求められるスキルは何かと聞かれたら、プログラミングだと答える人が多いだろう。確かにコードが書けなければツールは作れないし、技術力は内製DXの土台になる。

このシリーズでは、内製エンジニアがAIを活用して社内ツールを高速開発するアプローチを勧めてきた。AIのおかげでコードを書く能力のハードルは大幅に下がっている。技術面の環境は確実に良くなっている。

ただし、技術力があればうまくいくかというと、それだけでは足りないことがある。現場に出向いて話を聞く時間を持っているかどうか。地味で泥臭い話だが、これが技術力と同じくらい成果に効いてくる。

AIがコードを書く力を補ってくれる時代だからこそ、AIには補えない部分——現場に行って、話を聞いて、業務を理解すること——の価値が相対的に上がっている。技術力を磨くことと、話す時間を確保すること。この両方が揃ったとき、内製DXは最も確実に成果を出せる。


このシリーズの他の記事:

シリーズ記事一覧・著者への相談はこちら →

受注生産のデータは見積番号から始める ── 受注起点では見えないフィードバックループ

受注番号からデータが始まる会社が多い

中小製造業のデータ管理で、最も一般的な起点は受注番号になる。受注が確定した時点で番号を振り、その番号で製造指示、仕入、工程管理、出荷、請求と紐づけていく。

このシリーズでも、受注番号を軸にしたデータの紐づけを繰り返し勧めてきた。仕入管理、品質管理、納期回答——いずれも受注番号を一本の串にして情報を通す考え方になる。

受注番号を起点にすること自体は間違っていない。しかし、ここで一つ見落とされがちな問題がある。受注の前には見積もりがある。 そして多くの会社で、見積もりと受注のデータがつながっていない。

見積もりは「使い捨て」にされている

受注生産の中小製造業であれば、ほぼ確実に見積もりをしている。顧客から引き合いが来て、材料費・加工時間・外注費を積算し、見積書を出す。

このとき見積もりの中には、その案件の原価構造がすでに入っている。どの工程にどれだけ時間がかかるか、材料費はいくらか、外注はどこに出すか。受注前の段階で、これだけの情報が一度は整理されている。

しかし受注が決まると、多くの会社ではここで断絶が起きる。受注番号が新しく採番され、製造は受注番号で動き始める。見積書はファイルに綴じられるか、フォルダに保存されて、二度と参照されない。

見積もりの時点で積み上げた情報と、受注後の実際の業務が、番号で結びついていない。見積もりが使い捨てになっている。

見積番号と受注番号を紐づけるだけで変わること

やるべきことは単純で、見積番号と受注番号を紐づけるだけになる。見積台帳に受注番号の列を追加する、あるいは受注台帳に見積番号の列を追加する。どちらでもいい。

この紐づけが存在するだけで、以下のことが可能になる。

1. 積算と実績の比較ができる

見積もりの段階で「溶接3時間、材料費5万円」と積算したものに対して、実際にかかったコストを突き合わせられる。見積もり時の想定と実績がどれだけ乖離しているかがわかる。

以前の記事でアワーレート方式による個別原価管理を書いたが、原価の「実績」だけ見ていても、それが高いのか安いのか判断しにくい。見積もりの「積算」という比較対象があって初めて、乖離の大きさと方向がわかる。

中小製造業の多品種少量生産における原価計算の「落とし所」

2. 見積もりの精度を改善できる

積算と実績の差が蓄積されれば、見積もりのどこにズレがあるかが見えてくる。「溶接工程はいつも1.5倍かかっている」「材料費は見積もりより低く収まる傾向がある」。このフィードバックがあれば、次の見積もりでは最初から補正できる。

以前の記事で、見積もりデータを生産計画の簡易マスタに流用する方法を書いた。見積もりを計画に使う——これは前方向への流れになる。今回の話はその逆で、実績を見積もりに返す——後方向への流れになる。前方向と後方向の両方が回って、初めてサイクルが成立する。

中小製造業の生産計画は、見積もりデータの再利用から始められる

3. 見積もりデータがそのまま実用マスタになる

見積もりと受注が紐づいて、さらに実績でフィードバックが返ってくると、見積もりデータの精度が時間とともに上がっていく。こうなると、過去の見積もりデータは「正確さが検証された積算情報」の集まりになる。

以前の記事で、中小製造業ではBOMや標準時間の整備が進まないと書いた。完璧なマスタを一から作るのは工数が重すぎる。しかし、見積もりデータを起点に、実績で補正しながら育てていけば、日常の業務の中で自然にマスタが育つ。整備のための特別な作業は要らない。

中小製造業の生産計画は、見積もりデータの再利用から始められる

受注にならなかった見積もりにも価値がある

見積番号で管理するもう一つの利点は、受注にならなかった案件のデータも残ることにある。

受注番号を起点にすると、受注になった案件しかデータに残らない。しかし実際には、見積もりを出したうち受注になるのは一部であり、受注にならなかった案件の情報は消えてしまう。

受注にならなかった見積もりには、価格面で折り合わなかった、納期が合わなかった、仕様が合わなかったなど、何らかの理由がある。この情報が蓄積されれば、受注率の傾向が見えてくる。「この価格帯だと失注する」「このリードタイムでは取れない」といった営業判断の材料になる。

見積番号を起点にしたデータ管理は、受注以降の業務だけでなく、受注の手前にある営業活動の可視化にもつながる。

紐づけの粒度は「見積番号=受注番号」でなくていい

実務上、見積もりと受注が1対1に対応しない場合も多い。1つの見積もりから複数の受注に分かれることもあるし、見積もりを何度か改定してから受注が決まることもある。

ここで完璧な対応関係を作ろうとすると、仕組みが複雑になりすぎる。現実的な落とし所としては、受注データに「元の見積番号」を1つ持たせるだけで十分に機能する。改定がある場合は最終版の見積番号を入れておけば、積算との比較は成立する。

以前の記事で繰り返し書いてきたが、完璧を目指して始められないより、70点で回し始めるほうがはるかに価値がある。見積番号と受注番号の紐づけも同じで、厳密な対応関係がなくても、つながっているだけで見える景色が変わる。

中小製造業の多品種少量生産における原価計算の「落とし所」

見積もりを起点にすると、データの流れが一本になる

ここまでの話を整理する。

受注番号を起点にしたデータの流れ:

受注 → 製造 → 仕入 → 検査 → 出荷 → 請求

これに見積番号を加えると:

見積 → 受注 → 製造 → 仕入 → 検査 → 出荷 → 請求 → 実績を見積にフィードバック

起点が一つ前に伸びて、終点からフィードバックが返る。直線がループになる。

このシリーズで繰り返し書いてきた「受注番号を串にする」という考え方は変わらない。ただし、その串の先頭に見積番号をつなげるだけで、データの活用範囲が大きく広がる。新しいシステムは要らない。見積台帳と受注台帳に、お互いの番号を1列追加するだけでいい。

見積もりは使い捨てにするには惜しいデータになる。中小製造業が日常的に作っている見積もりの中に、原価管理の基準、生産計画の簡易マスタ、営業分析の材料がすでに入っている。それを活かすために必要なのは、番号を一つつなげることだけになる。


このシリーズの他の記事:

シリーズ記事一覧・著者への相談はこちら →