投稿日:

中小製造業のファイル管理は、フォルダ構造をデータベース代わりにする

案件のファイルをもっと早く開きたい

共有フォルダに年度別や部署別でフォルダを分けて、ファイルを管理している会社は多い。普通に運用できている会社がほとんどだと思う。

ただ、受注生産で案件数が多くなってくると、「あの案件の図面どこだっけ」と探す場面が増えてくる。年度フォルダの中を開いて、顧客名で探して、その中のファイルを確認して——という手順を毎回やるのは地味に手間がかかる。

自分が現場で試して効果があったのが、製造番号（受注番号）をキーにしたフォルダ構成になる。これは既存のフォルダ管理を置き換えるというより、案件単位でファイルをまとめる仕組みを一つ加えるという話。

製造番号でフォルダを切る

受注生産の中小製造業なら、最もシンプルで効果的な方法がある。製造番号（または受注番号）でフォルダを作ること。

製造番号がわかれば、その案件に関するファイルはすべて一つのフォルダに入っている。図面も見積書も検査記録も発注書も、案件単位でまとまっている。

「あの案件の図面どこ？」→ 製造番号で開く → ある。これだけで、ファイルを探す時間の大半がなくなる。

フォルダ構造がデータベースの役割を果たす

この方法が効くのは、フォルダ構造自体が案件をキーにしたデータベースになっているからになる。

以前の記事で「受注生産のデータは見積番号から始める」と書いた。データベースでいえば、見積番号や製造番号が主キーで、それに紐づくデータ（図面、見積、検査記録）がぶら下がっている。フォルダ構造でも同じことができる。製造番号がフォルダ名、その中のファイルが紐づくデータ。

普通のデータベースと違うのは、誰でもエクスプローラーで開けるということ。特別なソフトがなくても、フォルダをたどれば必要なファイルにたどり着ける。

ソフトからも一発で開ける

ここからが実用的な話になる。フォルダを製造番号で切っておくと、業務ソフトとの連携が簡単にできる。

自分が実際にやった方法はこうなる。業務管理のソフトに「フォルダを開く」ボタンを付ける。ボタンを押すと、今見ている案件の製造番号に対応するフォルダが自動で開く。ソフトの中にはファイルを保存しない。あくまで普通のフォルダにあるファイルへの入口を提供するだけ。

Excel VBAでも同じことができる。セルに製造番号が入っていれば、VBAでパスを組み立ててエクスプローラーで開く。数行のコードで済む。

この設計のポイントは、ソフトはファイルへの便利な入口であって、ファイルの保管場所ではないということ。ソフトが壊れても、ファイルはフォルダにそのまま残っている。ソフトを入れ替えても、ファイルは影響を受けない。

ファイルをソフトに閉じ込めない

生産管理システムや文書管理システムの中には、ファイルをシステム内部に格納するものがある。登録したファイルはシステムからしかアクセスできない。

管理の観点からは正しい。勝手にファイルを移動されたり消されたりしない。バージョン管理もシステムが担う。大企業ならこの方が安全だろう。

しかし中小製造業では、これがリスクになることがある。

  • システムが止まるとファイルにアクセスできない。 サーバーが故障したら図面が見られない。業務が止まる
  • システムを入れ替えるとき、ファイルの移行が大変。 データのエクスポート機能がなければ、ファイルを取り出すだけで一仕事になる
  • 業者に依存する。 ファイルの取り出しに業者の協力が必要になると、以前の記事で書いた「知識のロックイン」と同じ構造が生まれる

以前の記事で「入れ替えられる設計」の重要性を書いた。ファイル管理でも同じ原則が当てはまる。ファイルは普通のフォルダに、普通のファイルとして置いておく。 ソフトはそこへの便利な入口を提供するだけ。こうしておけば、ソフトが変わってもファイルは残る。

バックアップも楽になる

ファイルが普通のフォルダにあるということは、バックアップも単純になる。フォルダごとコピーすればいい。

以前の記事でバックアップの重要性を書いた。ファイルがシステム内部に格納されていると、バックアップにはシステムのエクスポート機能やデータベースのバックアップが必要になる。フォルダにあるなら、フォルダごと外付けHDDにコピーするだけで済む。

個人フォルダは残していい

共有フォルダの中に個人名のフォルダがある会社は多い。「田中」「鈴木」のようなフォルダに、それぞれが自分のファイルを入れている。

これを「属人化だからやめるべき」と言う人もいるが、個人フォルダは使いやすい。自分のファイルの置き場所がはっきりしているし、作業中のファイルを他の人に触られる心配もない。無理になくす必要はないと思っている。

ただし、案件の成果物が個人フォルダにしかない状態は避けたい。図面の最終版、提出した見積書、検査成績書。これらは案件に紐づく共有のファイルであって、個人のものではない。担当者が異動や退職したときに、案件のファイルが見つからないという事態になる。

以前の記事で「属人化のトリアージ」について書いた。ファイル管理でも同じ考え方が使える。個人の作業ファイルは個人フォルダに、案件の成果物は製造番号フォルダに。この使い分けだけ守れば、個人フォルダはそのまま残していい。

フォルダ整理のルールは最小限でいい

製造番号でフォルダを切る。案件に関するファイルはそのフォルダに入れる。この2つだけ守れば、細かい命名規則やサブフォルダのルールは最小限でいい。

現場のルールは少ないほど守られる。「製造番号のフォルダに入れてくれ」は守れる。「ファイル名は日付＋版数＋担当者名で、サブフォルダは種類別に分けて、命名はキャメルケースで」は守られない。

運用で大事なのは、新しい案件が発生したときにフォルダを自動で作る仕組みを入れておくこと。手動で作ると忘れるし、名前の揺れが出る。受注登録のタイミングでフォルダを自動生成するだけで、構造の一貫性が保てる。

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

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

投稿日:

中小製造業のExcel業務が「1シート」で止まる理由 ── 関数の限界と次の一歩

1つのシートならなんとかなる

中小製造業で「Excelでちゃんと管理してくれ」と言われたとき、まず作るのはだいたい1つのシートにまとめた一覧表になる。

在庫一覧、受注一覧、発注一覧。品番、数量、日付を並べて、フィルターで絞り込んで、SUMで合計を出す。これは特別なスキルがなくてもできるし、実際これだけで回る業務も多い。

問題はここから先。

「2つのデータをつなげる」瞬間に壁が来る

業務が進むと、1つのシートでは収まらない場面が出てくる。

  • 発注したものが届いたかどうか確認したい → 発注データと入荷データを突合する必要がある
  • 在庫から出荷した分を引きたい → 在庫データと出荷データをつなげる必要がある
  • 見積もりと実際の原価を比べたい → 見積データと実績データを並べる必要がある

どれも「2つのデータを共通のキー（品番や注文番号）でつなげて、比較する」という同じ構造の問題になる。

ここでVLOOKUPやSUMIFSを使ってみる。品番をキーにして別シートから数字を引っ張ってくる。「入庫合計 − 出庫合計 = 現在の在庫数」をSUMIFSで出す。ここまではなんとかなる。

しかし、実際の業務ではこれだけでは足りなくなる。

関数でできるのは「今の状態を見る」こと

SUMIFSで「品番Aの入庫合計は300、出庫合計は200、だから在庫は100」と計算できる。これはある時点のスナップショットを見ているだけになる。

しかし、業務で必要なのはこういうことになる：

発注と入荷の消し込み。 発注番号PO-001で100個発注した。3月1日に60個届いた。残り40個がまだ届いていない。この「残り40個を追いかける」という作業は、発注レコードと入荷レコードを1件ずつ紐づけて、状態を管理する必要がある。SUMIFSで発注合計と入荷合計の差を出すことはできる。しかし「どの発注の、どの分が未入荷なのか」までは追えない。

在庫の引当。 在庫が200個ある。注文Aで80個、注文Bで150個の引き合いが来ている。合計230個で在庫が足りない。どちらを優先するか判断して、引き当てた分を在庫から確保する。これは「計算」ではなく「判断して状態を変える」作業になる。

出荷済みの消し込み。 受注リストから出荷が完了した案件を消し込む。出荷データと突合して、ステータスを「出荷済み」に変える。関数で「出荷データに存在する＝出荷済み」と判定することはできるが、それを受注リストに反映して管理し続ける仕組みは関数だけでは作りにくい。

「見る」と「処理する」の境界

ここまでの例に共通しているのは、関数でできるのは 「見る」 ことであって、 「処理する」 ことではないという点になる。

  • 見る： 今の在庫数を計算する、合計と合計の差を出す、条件に合うデータを探す
  • 処理する： 発注に対して入荷を紐づける、在庫を引き当てる、ステータスを変更する

1つのシートで完結する業務は「見る」だけで回る。品番ごとの合計を出す、一覧を並べ替える、条件に合うものを抽出する。これは全部「見る」の範囲になる。

2つのデータをつなげる業務には「処理する」が入ってくる。AのデータとBのデータを照合して、結果に応じて状態を変える。この「状態を変える」部分が、関数にはできない。関数は与えられたデータから答えを計算するだけで、データそのものを書き換えることはしない。

1シートで止まるのは、能力の問題ではなく、関数という道具の限界になる。

この壁を超えるには

「処理する」をExcelの中でやろうとすると、VBA（マクロ）が必要になる。VBAなら、データを読んで、条件を判断して、別のシートに書き込む、という一連の処理を自動化できる。

以前の記事で、Excelでも業務の仕組みは作れると書いた。あの記事で言う「シートの役割を分離して、VBAで制御する」というやり方は、まさにこの「処理する」壁を超えるための方法になる。

ただし、VBAを書く前にやるべきことがある。データの持ち方を整えることになる。

発注データと入荷データを突合するには、両方に共通のキー（発注番号など）が入っている必要がある。在庫の入出庫を追いかけるには、入庫と出庫が同じ品番コードで記録されている必要がある。VBAで処理を書く以前に、つなげるためのデータの形が揃っていなければ、何も始まらない。

以前の記事で「Excelのデータはいつでもデータベースに移せる形で持つ」と書いた。あの「データの文法」の話は、実はこの壁を超えるための準備でもある。1行1レコード、列は固定、共通キーを持つ。この形になっていれば、VBAでもデータベースでも、次のステップに進める。

まず「何と何をつなげたいか」を整理する

VBAが書けなくても、今すぐできることがある。

「何と何をつなげたいか」を書き出すこと。

  • 発注データと入荷データをつなげて、未入荷を把握したい
  • 見積もりと実績原価をつなげて、ズレを見たい
  • 受注データと出荷データをつなげて、未出荷を管理したい

つなげたいデータの組み合わせと、それぞれの共通キー（発注番号、見積番号、受注番号）を整理する。これだけで、今の業務のどこに「処理する」壁があるかが明確になる。

その上で、VBAを自分で覚えるか、できる人に相談するか、業者に頼むか。選択肢はいくつかあるが、何をつなげたいかが整理できていれば、どの選択肢を取っても話が早い。 逆に、ここが整理できていないまま「なんとかしてほしい」と頼むと、業者に頼んでもうまくいかない。以前の記事で「自分たちで理解できていないことは、正しく外注もできない」と書いた通りになる。

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

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

投稿日:

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

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

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

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

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

数字は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レコードにする。これらは基準と実績を突合するための前提条件になる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

投稿日:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

弱点を知った上で選ぶ

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

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

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

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

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

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

投稿日:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

投稿日:

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

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

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

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

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

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

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

ワークフローソフトにプロセスを載せると、ステップを飛ばせなくなる。

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

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

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

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

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

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

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

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

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

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

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

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

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

全部載せる必要はない

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

投稿日:

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

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

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

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

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

帳票型が選ばれる理由

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

具体的には：

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

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

変換は後からでいい

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

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

全部を一度に変換する必要もない。使うデータだけ、使うタイミングで変換すればいい。レイアウトさえ揃っていれば、「いつでも変換できる」という状態を維持できる。これは以前の記事で書いた「いつでも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統制を求められる環境では合理的な選択になる。大手企業がローコード・ノーコードを採用する背景には、こうした管理面のメリットが大きい。

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

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

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

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

中小製造業ではどうか

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

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

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

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

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

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

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

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

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

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

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

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

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

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

投稿日:

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

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

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

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

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

任せることと、丸投げすることは違う

同じ「業者に頼む」でも、中身が大きく異なる2つのパターンがある。

一つは、自分たちで内容を理解した上で任せているケース。何が必要で、何をやってもらっていて、結果がどうなるべきかを把握している。もう一つは、よくわからないから全部お願いしているケース。何をやっているか、なぜそうしているかが見えていない。

外から見ると同じ「外注」だが、業者との力関係がまったく違う。前者は対等なパートナーとして付き合える。後者は、言い値になりやすく、提案の良し悪しも判断できない。業者が悪いわけではなく、こちらに判断基準がないことが問題になる。

全部を理解する必要はない

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

たとえばネットワークやサーバーのインフラ。自分のところでもインフラは業者に完全に任せている。ネットワーク構成を深く理解しても、それが自社の競争力に直結するわけではない。インフラの知識は汎用的なもので、製造業だろうとサービス業だろうと基本は同じ。ここはプロに任せた方が効率がいい。

PCなどの機器も同じ考え方で整理できる。社内にトラブル対応できる人がいれば、購入して自分たちで管理する方がトータルコストは安い。対応力がなければ、リースやレンタルでサポート込みの契約にした方が安全になる。汎用品の調達方法は、社内の対応力に合わせて選べばいい。

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

線引きの基準は「自社固有かどうか」になる。 汎用的な領域は業者に任せていい。自社固有の領域は、自分たちで理解していなければならない。

自社固有の領域を外注するとき何が起きるか

問題が起きるのは、自社固有の領域をよく理解しないまま外注するケースになる。

よくあるのが、業務システムの開発を業者に丸投げするパターン。「うちの業務に合ったシステムを作ってほしい」と依頼するが、「うちの業務」を仕様として言語化できていない。業者は聞き取りをして要件をまとめてくれるが、業務の本質的な部分はこちらにしかわからない以上、ズレが生じやすい。

以前の記事で「手作業でできることしかシステムにできない」と書いた。同じ構造がここにもある。自分たちで理解できていないことは、正しく外注もできない。 業者に説明できないということは、要件が固まっていないということであり、出来上がったものが期待と違っても、どこがズレているのかすら指摘しにくい。

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

関係は人につく──担当者が変わるリスク

もう一つ、見落としがちなリスクがある。業者との関係が特定の担当者に依存しているケースになる。

自分が見た例では、ある業者がまるで社員のように社内の事情を把握してくれていた。システムの経緯も、現場の癖も、過去のトラブルも全部わかっている。非常にうまく回っていた。しかし、こちらの担当者が異動で変わったことで、この関係が崩れてしまった。新しい担当者は業者との経緯を把握しておらず、業者側も「前の担当者とはこうやっていた」という暗黙の前提が通じなくなった。結果、どちらもどうしていいかわからない状態に陥った。

これは業者の問題ではなく、関係性が特定の人と人の間にしか存在していなかったことが原因になる。業者とのやり取りの内容、判断の経緯、依頼の背景。これらが担当者の頭の中だけにあると、人が変わった瞬間にすべてが失われる。

このシリーズで繰り返し書いてきた「暗黙知をデータにする」という話は、社内の業務だけでなく、業者との関係にも当てはまる。何を頼んでいるか、なぜそうしているか、過去にどんな判断をしたか。最低限の記録があるだけで、担当者が変わっても関係を引き継げる。

内製DXが業者との関係を変える

このシリーズで書いてきた内製DXは、自社固有の領域を自分たちで扱えるようにするという話でもある。

データの持ち方を自分たちで設計する。業務フローを自分たちで整理する。見積もりから受注、製造、実績までのデータの流れを自分たちで構築する。これらは自社固有の知識であり、外注しにくい部分だからこそ、内製する意味がある。

逆に、内製DXが進むと業者との付き合い方が変わってくる。「何をやってほしいか」を明確に伝えられるようになるので、業者は本来の強みである技術力とスピードを発揮しやすくなる。こちらも「何をいくらで頼んでいるか」が見えるので、コスト感覚が持てる。

つまり、内製力が上がるほど、業者との関係が依存から協業に変わる。内製とは、全部を自分でやることではなく、自社固有の部分を自分で理解・管理できる状態のこと。 その上で、汎用的な領域や専門的な技術は業者に任せる。この使い分けが中小製造業にとって現実的な形になる。

まとめ：理解の有無が外注の質を決める

業者との付き合いで大事なのは、良い業者を見つけること以上に、自分たちが何を理解していて、何を理解していないかを把握することになる。

  • 汎用領域（インフラ、ネットワーク、ハードウェア）→ 信頼できる業者に任せる。ここは御用聞きタイプの業者が力を発揮する
  • 自社固有領域（業務ロジック、データ設計、業務フロー）→ 自分たちで理解を持つ。ここを外に出すなら、少なくとも仕様を自分たちで書ける状態にする

小回りのきく業者は中小製造業にとって貴重なパートナーになる。ただし、そのパートナーシップが機能するのは、こちらが自社の業務を理解している場合に限る。理解がなければ、パートナーではなく依存先になってしまう。

内製DXで自社固有の領域を固めつつ、汎用的な部分は信頼できる業者と組む。この組み合わせが、中小製造業の体力に合った現実的なやり方だと考えている。

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

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

投稿日:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

内製DXの正しい順番

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

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

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

うまくいく順番：

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

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

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

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

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

しかし、ロジックが検証されていない状態で作り始めると、手戻りのコストのほうがはるかに大きくなる。作り直し、仕様変更、使われないまま放置——これらの時間とコストに比べれば、手作業で1〜2週間回してみることは安い投資になる。

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

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

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