中小製造業の内製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の成功率は大きく変わる。


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

シリーズ記事一覧はこちら →

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

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

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

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

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

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

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

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

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

飲みに行く話ではない

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

話すことで得られるもの

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

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

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

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

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

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

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

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

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


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

シリーズ記事一覧はこちら →

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

シリーズ記事一覧はこちら →

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

システム化の依頼が来たら、まず疑うこと

内製DXを進めていると、社内からシステム化の依頼が出てくる。「この週報をExcelじゃなくてシステムで入力できるようにしてほしい」「この集計作業を自動化してほしい」。

依頼が来たら作る。それが内製DX担当者の仕事に見える。しかし、ここで一つ立ち止まって考えるべきことがある。

その業務は、そもそも必要なのか。

以前の記事で、内製DXには「管理精度型」と「工数削減型」の2つがあると書いた。管理精度型は見えないものを見える化する。工数削減型は手間を減らす。どちらも「業務が存在する」ことを前提にした改善になる。

しかし実際の現場には、存在自体が疑わしい業務がある。ここに手を入れるのが第三の選択肢、「廃止型」 になる。

誰も見ていない資料が作られ続ける構造

中小製造業の現場で、こういう光景は珍しくない。

  • 毎週作成される週報。上司は読んでいない
  • 月次で集計される実績表。会議資料に載るが、その数字について議論されたことがない
  • 日報を全員に書かせているが、集計も分析もされずフォルダに溜まっていく
  • 「前任者がやっていたから」という理由だけで続いている帳票

これらは、始まった当初には目的があったはず。しかし目的が形骸化しても、作業だけが慣性で残る。やめるきっかけがないから続いている。誰かが「これ要りますか?」と聞かない限り、止まらない。

そしてここに「この資料の作成をシステム化してほしい」という依頼が来る。システム化すれば作成の手間は減る。しかし、誰も見ていない資料の作成が楽になっただけで、無駄がデジタルに移っただけになる。

プロセス改善がいちばん効く場合がある

ツールを作って業務を効率化するのが内製DXの仕事だと思いがちだが、業務プロセスそのものを見直すほうが効果が大きいケースは多い

たとえば、ある帳票の作成に毎週2時間かかっているとする。これをシステム化して30分に短縮すれば、週1.5時間の削減になる。しかし、その帳票が実は不要だったとわかれば、削減効果は週2時間。しかもシステムを作る工数がゼロになる。

作るより、やめるほうが速い。

もちろん、すべての業務を疑い始めたら何も進まない。しかし少なくとも「システム化してほしい」という依頼が来たとき、作り始める前にその業務の目的と利用実態を確認する工程を挟むだけで、無駄なシステムを作るリスクを大幅に減らせる。

ただし、DX担当者1人では「やめる」は決められない

ここが現実の壁になる。

「この資料、誰が見ていますか?」は正論だが、依頼してきた上司や他部門に対して、DX担当者の立場からは聞きにくい。特に中小企業では、DX担当者が若手だったり兼任だったりして、業務の要否を問える位置にいないことが多い。

「やめましょう」と提案するのは、その業務を続けてきた人の仕事を否定するように聞こえかねない。正しいことを言っていても、組織の中では通らないことがある。

だから廃止型のDXは、DX担当者単独ではできない。経営者の協力が必要になる。

経営者の役割は「やめていい」と言うこと

内製DXにおける経営者の役割は、予算を出すことだけではない。管理精度型であれば「何を見たいか」を決める。工数削減型であれば「何を優先するか」を決める。

廃止型では、経営者の役割は 「やめていい」と言うこと になる。

DX担当者が「この帳票、システム化の前に利用状況を確認したいのですが」と聞ける空気を作る。確認した結果「実は誰も使っていない」とわかったとき、「じゃあやめよう」と判断を下す。この判断はDX担当者にはできない。業務を廃止する権限を持っているのは経営者だけになる。

逆に言えば、経営者が「やめていい」と言えない組織では、廃止型のDXは機能しない。不要な業務がシステム化され、無駄が効率よく回り続ける。

そしてもう一つ、経営者自身が気をつけるべきことがある。以前の記事で、管理精度の向上は経営者の判断力を引き上げる「武器」だと書いた。これは正しいが、武器は多ければ多いほどいい、とはならない。

経営者が「あれも見たい、これも把握したい」と求めると、その分だけ現場の入力負荷が増え、DX担当者の開発負荷が増え、管理帳票が増える。武器を増やしすぎた結果、どの数字も中途半端にしか見ない状態になれば、武器を持っていないのと同じになる。

廃止型DXの対象は、現場が惰性で続けている業務だけではない。経営者自身が過去に「見たい」と言って作らせた管理帳票も含まれる。かつて必要だと思って作らせたが、今は見ていない。しかし自分が頼んだ手前、やめようとは言い出しにくい。こうして経営者側からも不要な業務が生まれ続ける。

本当に使う武器だけを手元に残す。それは現場に「やめていい」と言うのと同じかそれ以上に、勇気が要ることかもしれない。

「やめていいか」を確認する方法

とはいえ、経営者もすべての業務の利用実態を把握しているわけではない。DX担当者側から判断材料を出す必要がある。ここは角の立たない形で確認する方法がある。

要件定義として聞く:

システム化の依頼が来たとき、作り始める前に確認するのは当たり前のことになる。「この資料は誰がいつ、どういう判断に使っていますか?」は、要件定義として自然な質問であり、業務の要否を問うているようには聞こえない。

この質問に明確な答えが返ってこない場合、その業務は形骸化している可能性が高い。

データで確認する:

ファイルサーバーに置かれている資料であれば、最終アクセス日時を確認できる。半年間誰も開いていないファイルがあれば、それは事実として示せる。人に「見ていますか?」と聞くと角が立つが、データが示す事実に対しては反論しにくい。

どちらの方法も、DX担当者が「この業務は不要です」と言っているのではなく、事実を集めて経営者に判断材料を渡しているだけになる。判断するのは経営者。DX担当者の仕事は、判断できる材料を揃えることになる。

DXは1人では回らない

このシリーズでは、内製エンジニアがAIを活用して社内ツールを高速開発するアプローチを繰り返し勧めてきた。しかし内製DXは、技術だけで完結する話ではない。

管理精度型のDXでは、経営者が「何を見たいか」を決めなければ設計できない。廃止型のDXでは、経営者が「やめていい」と判断しなければ動けない。工数削減型ですら、現場の協力がなければ定着しない。

DX担当者は道具を作れる。しかし、何を作るか、何をやめるかの判断は、経営者と一緒にやるしかない。内製DXの成否を分けるのは、技術力よりも、経営者とDX担当者が同じ目線で業務を見られる関係があるかどうかになる。

新しいツールを作る前に、まず今ある業務を一緒に眺めてみる。「これは何のためにやっているんだっけ?」と問い直す。その結果やめられる業務が見つかれば、それはシステムを1本作るより大きな成果になることがある。作ることだけがDXではない。やめることもDXになる。


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

シリーズ記事一覧はこちら →

AIの具体的な未来予測はどうでもいい ── それでも中小製造業が今から触るべき理由

「AIで○○が自動化される」は、当たるかどうかわからない

AIに関する予測は毎月のように出てくる。プログラミングは自動化される、設計はAIがやる、営業メールは全部AIが書く、工場の検査は画像認識に置き換わる。

こうした具体的な予測が当たるかどうかは、正直わからない。5年前に「RAGで社内ナレッジが自在に引き出せる」と言われていたが、以前の記事で書いた通り、現時点でそれが中小企業の現場で安定して動いているケースは少ない。一方で、コード生成のように予想以上に早く実用化した領域もある。

個別の予測は外れることも多い。「来年にはこれが自動化される」という話に一喜一憂しても仕方がない。

ただし、大局は決まっている

個別の予測は当てにならないが、大きな方向は決まっている。AIは今後、電気やインターネットと同じレベルのインフラになる。 これはもう予測ではなく、既定路線と言っていい。

PCが普及した1990年代を思い出すとわかりやすい。当時「PCで何ができるか」の具体的な予測は玉石混交だった。「紙はなくなる」と言われたが紙はまだある。「全員がプログラマーになる」とも言われたがそうはなっていない。しかし「PCが業務インフラになる」という大局だけは完全に当たった。今、PCが使えない会社は存在できない。

インターネットも同じだった。「ネットで何が変わるか」の個別予測は外れだらけだったが、「ネットが前提になる」という大局は不可逆だった。

AIも同じ構造をたどっている。「AIで具体的に何が自動化されるか」の予測に振り回される必要はない。しかし「AIがインフラになる」という大局に対して準備しない、という選択肢はない。

「成果が出てから始める」では遅い

中小企業の経営者が慎重になるのは理解できる。限られた予算と人手の中で、成果が見えないものに投資するのはリスクに感じる。「もう少し事例が出てから考える」というのは、一見合理的な判断に見える。

しかしインフラの転換期において、この判断は裏目に出ることが多い。

PCの導入も、早い段階で触り始めた会社と、「ウチにはまだ早い」と様子を見ていた会社で、数年後に大きな差がついた。差がついたのは、PC自体の性能ではなく、組織がPCを使いこなすまでの学習時間があったかどうかだった。

AIも同じことが起きる。ツールの性能は日進月歩で上がっていくが、組織がAIを使いこなすための学習は一朝一夕にはいかない。「何を聞けばいいかわからない」「どの業務に使えるかピンとこない」——これは触って試して失敗して、初めて超えられる壁になる。成果が出てから始めようとしても、その時点では学習期間を経た他社との差がすでに開いている。

全社員に配っても使われない問題

以前の記事で、「全社員にAIツールを配る」アプローチはPCスキルのばらつきや「何を聞けばいいかわからない」という壁があると書いた。この状況は現時点でも大きくは変わっていない。

実際、ChatGPT EnterpriseやMicrosoft Copilotを全社展開した企業でも、継続的に使い込んでいるのは全体の1〜2割で、残りは数週間で使わなくなるという話はよく聞く。短期のROIで測れば、全社員分のライセンス費用に見合っていないと評価されてもおかしくない。

しかし、これを「失敗」と見るかどうかは、何を期待していたかによる。

全社員が即座にAIを使いこなして生産性が上がる——そう期待していたなら確かに失敗になる。しかし、組織としてAIに触れ始める最初の一歩——そう位置づけるなら、使わなくなった8割も含めて「AIというものが存在する」という認識が社内に共有されたこと自体に意味がある。

挑戦自体が資産になる

中小製造業がAIに取り組む価値は、今すぐの成果ではなく挑戦の過程で組織に蓄積されるものにある。

  • AIに何を聞けば使えるのか、何を聞いても無駄なのかの肌感覚
  • 自社の業務のうち、どこにAIが効きそうで、どこには効かないかの見極め
  • 「AIを使う」という行為への心理的なハードルの低下

これらは導入事例を読んだだけでは得られない。自分たちで触って、うまくいかない経験も含めて初めて身につく。

以前の記事で、内製DXは内製エンジニアがAIを活用して社内システムを高速開発するアプローチが最も効果的だと書いた。この考えは変わっていない。ただし、内製エンジニア以外の社員がAIに触れること自体を否定しているわけではない。全社員の生産性が即座に上がることを期待するのではなく、組織全体がAIに慣れるプロセスに投資していると捉えれば、短期の利用率の低さは問題にならない。

AIは「改善」ではなく「変化」、ただし土台がなければ乗れない

業務改善には2種類ある。今あるやり方をより良くする「改善」(1→2)と、やり方そのものが変わる「変化」(1→A)になる。

このシリーズでやってきたのは、ほとんどが「改善」にあたる。Excelのデータの持ち方を正す、紐づけのキーを入れる、見積番号と受注番号をつなげる。どれも今の業務の延長線上で、やり方の根本は変わっていない。

一方、AIの登場は「変化」の側にある。同じ作業を速くやるだけではなく、誰が何をできるかのルール自体が変わる。コードを書ける人の裾野が変わる。今まで人手でやるしかなかった判断の一部が委譲できるようになる。これは改善の延長にはない、ルールの変更になる。

しかし、変化に乗るには土台が要る。

AIにデータを読ませたくても、データが整っていなければ読ませるものがない。AIで業務を自動化したくても、業務プロセスが整理されていなければ何を自動化すべきかわからない。AIを活用できる内製エンジニアがいても、現場との信頼関係がなければツールは使われない。

このシリーズで書いてきたデータの文法、紐づけの設計、プロセスの見直し、現場とのコミュニケーション——これらは地味な改善の話だが、同時にAIという変化に乗るための土台づくりでもある。改善を飛ばして変化には行けない。 逆に、改善だけやっていて変化を見ないと、気づいたときにはルールが変わった世界に取り残される。

両方が要る。地味な改善で足元を固めながら、AIという変化の方向を見ておく。どちらか片方では足りない。

具体的な予測ではなく、構えを取る

「AIで何ができるようになるか」の具体的な予測を追いかけるのは、情報収集としては面白いが、経営判断の根拠にはしにくい。予測が当たるかどうかに賭けるのはギャンブルになる。

代わりに取るべきは、AIがインフラ化したときに対応できる組織の構えを今から作っておくことになる。

具体的には、このシリーズで繰り返し書いてきたことと変わらない。

  • データの持ち方を正しくしておく(AIが活用できるデータの土台)
  • 内製エンジニアを育て、AIを開発の加速に使う(最も確実にROIが出る領域)
  • 社員がAIに触れる機会を作る(学習コストは早く払うほど安い)

AIの進化は速いが、だからといって「最新のAIが出てから考える」のでは永遠に始められない。今の時点で完璧なAI活用戦略を立てる必要はない。むしろ、完璧な戦略が立てられないからこそ、小さく始めて試行錯誤する。その試行錯誤の蓄積こそが、数年後にインフラ化したAIを使いこなすための土台になる。

予測に乗るのではなく、構えを取る。それが、中小製造業にとって最も現実的なAIとの付き合い方になる。


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

シリーズ記事一覧はこちら →

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

数字を単体で見せることの危うさ

内製DXで社内のデータを可視化する場面が増えてくると、「この数字を見えるようにしてほしい」という依頼が出てくる。売上推移、原価率、在庫金額、不良件数。それぞれの数字を出すこと自体は難しくない。

しかし、数字を単体で見せると判断を誤ることがある。

原価率が下がっていれば「改善した」と見える。在庫金額が増えていれば「資産が増えた」と見える。どちらも単体では正しい読み方に見えるが、この2つを並べると、まったく違う景色が見えてくることがある。

内製DXの担当者は、データを経営者に渡す立場にいる。会計の専門家である必要はないが、渡す数字が単体で見ると誤解を招く構造になっていないかは知っておく必要がある。今回は在庫と原価という、中小製造業で最も身近で、かつ最もつなげて見るべき数字の組み合わせを取り上げる。

在庫が増えると、原価率が良くなる仕組み

会計上、売上原価は次のように計算される:

売上原価 = 期首在庫 + 当期製造コスト − 期末在庫

この式の意味するところは単純で、期末の在庫が多ければ売上原価は小さくなり、利益は大きくなる。在庫が増えただけで、売上が同じでも利益の数字が変わる。

たとえば、ある月の状況がこうだったとする:

通常月 在庫増加月
売上 1,000万円 1,000万円
期首在庫 200万円 200万円
当月製造コスト 800万円 900万円
期末在庫 200万円 350万円
売上原価 800万円 750万円
原価率 80% 75%

在庫増加月は通常月より100万円多く作っている。しかし売上は同じ。売れなかった分が在庫として150万円積み上がっている。

会計上の売上原価は「200+900-350=750万円」となり、原価率は75%。通常月より良い数字が出る。製造コストは増えているのに、原価率は改善している。

これは会計の仕組み上そうなるだけであって、実態として効率が良くなったわけではない。

DX担当者がこの構造を知っておくべき理由

この話は経理の人間なら知っている。しかしDX担当者がデータを可視化する立場になったとき、この構造を知らないまま数字を出すと危険なことが起きる。

たとえば、月次の管理レポートを作ってくれと頼まれたとする。会計ソフトから原価率を引っ張って、推移グラフを作る。3ヶ月連続で原価率が下がっている。「改善傾向です」と報告する。

しかし同じ期間に在庫が膨らんでいたら、それは改善ではなく在庫の積み増しで原価率が良く見えているだけかもしれない。このレポートを受け取った経営者が「原価は順調だ」と判断してしまえば、在庫の問題に気づくのが遅れる。

数字を出す人間が構造を知らなければ、正確な数字で経営者をミスリードすることになる。 データが間違っているのではなく、見せ方が足りない。

ちゃんとした原価計算でも起きる

全部原価計算で個別原価を管理している会社でも、同じ構造の問題が起きる。

全部原価計算では、固定費(設備の減価償却費、工場の賃料など)を生産量で割って製品に配賦する。生産量が増えれば1個あたりの固定費負担が下がるので、製品の単位原価が下がる。

  • 月産100個なら、固定費500万円 ÷ 100個 = 1個あたり5万円
  • 月産150個なら、固定費500万円 ÷ 150個 = 1個あたり約3.3万円

原価が下がった。改善が進んだ。——しかし増産した50個が売れずに在庫になっていたら、それは改善ではなく、固定費を在庫に押し込んだだけになる。

以前の記事でアワーレート方式による個別原価管理を書いた。アワーレート自体は正しい管理手法だが、生産量が増えたときに単位原価が下がる構造は同じになる。原価データだけを見ていると改善に見えるものが、在庫データと並べると実態が違うことがわかる。

一方で、個別原価計算をやっていない会社でも同じ罠にはまる。会計ソフトから出てくる月次の原価率だけ見ていて、「今月は原価率が下がった、いい傾向だ」と思っている。在庫と並べていないから気づかない。ある日、倉庫を見て「なんでこんなに在庫があるんだ?」となる。

ちゃんと原価を見ている会社も、なんとなく見ている会社も、在庫が増えると利益が良く見えるという同じ罠にハマる。ハマる経路が違うだけになる。

ゴールドラットが指摘した構造

この問題を最も鋭く指摘したのが、エリヤフ・ゴールドラットの『ザ・ゴール』になる。

工場の「効率」を上げろと言われる。機械を止めるな、稼働率を上げろ。稼働率を上げるためには作れるだけ作る。作った分は在庫になる。原価計算上は単位コストが下がる。帳簿上は利益が出ている。しかしキャッシュは在庫に寝ていて、実際には金が回っていない。

ゴールドラットはこの構造を「原価計算が工場の判断を狂わせる」と表現した。原価を下げるための合理的な行動(稼働率を上げる、大ロットで作る)が、在庫の山を生み、キャッシュフローを悪化させる。

「たくさん作ったほうが1個あたりのコストが安い」という感覚は、規模を問わず現場に染みついている。その感覚が正しい場面もあるが、売れる見込みのない製品を在庫として積み上げる根拠にしてはいけない。在庫は帳簿上は資産だが、実質的には回収できていないキャッシュになる。

部門ごとのKPIが全部「良好」なのに、会社全体がおかしくなる

この問題がさらに厄介なのは、各部門がそれぞれの評価指標で見ると全員「良い仕事をしている」ように見えることにある。

  • 製造部門は稼働率で評価される。機械を止めず、たくさん作っている。KPIは良好
  • 経理は原価率を見ている。生産量が増えて単位原価が下がっている。KPIは良好
  • 営業は売上で評価される。在庫の問題には関心がない。売上が立っていればKPIは良好

各部門のKPIがすべて「順調」を示しているのに、会社全体では在庫が膨らみ、キャッシュが倉庫に寝ている。部門単位の数字をいくら集めても、全体の矛盾は見えない。

これは在庫と原価に限った話ではなく、部門ごとに評価指標が分かれている組織で構造的に起きる問題になる。各部門が自分のKPIを最適化する合理的な行動を取った結果、全体では非合理な状態が生まれる。

DX担当者がデータを可視化するとき、部門ごとのレポートをそれぞれ作るだけでは、この矛盾には気づけない。部門をまたいで数字をつなげて初めて、「各部門は順調なはずなのに、なぜ全体がおかしいのか」が見える。

「つなげて見せる」のがDX担当者の仕事

ここまでの話を踏まえて、DX担当者として最低限やるべきことを整理する。

原価率も在庫金額も、会計ソフトの中にすでに存在しているデータになる。問題はこの2つが別々の帳票・画面に出てくるため、並べて見る習慣がないことにある。

月次で2つの数字を並べるだけで、見え方が変わる:

原価率 期末在庫金額
1月 78% 320万円
2月 75% 380万円
3月 73% 450万円
4月 76% 420万円

原価率が下がっているのに在庫金額が増えていたら、効率改善ではなく在庫の積み増しを疑うサインになる。逆に、原価率が上がっていても在庫が減っていれば、滞留在庫を吐き出している健全な状態かもしれない。

新しいデータを取る必要はない。すでに会計ソフトにある数字を、並べて見える形にするだけ。しかしこの「並べる」という行為こそが、データを情報に変える最小単位の仕事になる。

もう一歩踏み込むなら、在庫を品目別または製品グループ別に見て、どこに滞留があるかを把握する。ただしこれは棚卸のデータがその粒度で残っていることが前提になる。以前の記事でデータの文法について書いたが、棚卸データも「あとから分析できる形」で残していなければ、数えた事実だけがあってデータとして使えないことになる。

データを「つなげる」視点は、在庫と原価に限らない

今回は在庫と原価の組み合わせを取り上げたが、単体では正しくても組み合わせないと意味が変わる数字は他にもある。

  • 売上が伸びているのに、入金サイトが延びていたらキャッシュは増えていない
  • 生産量が増えているのに、不良率も上がっていたら実質的な生産性は変わっていない
  • 受注件数が増えているのに、1件あたりの粗利が下がっていたら忙しくなっただけ

これらに共通するのは、1つの数字だけ見せると「良くなっている」ように見えるが、別の数字と並べると実態が違うという構造になる。

内製DXの担当者がデータを可視化するとき、「この数字は単体で見せていいか、何かと並べるべきか」を考える癖をつけておく。それが、データを出す人間としての最低限のリテラシーになる。以前の記事で管理精度の天井は経営者の判断力で決まると書いたが、その判断の手前で、データの出し方が判断の質を左右する。正しい数字を、誤解を招かない形で渡すこと。そこにDX担当者の役割がある。


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

シリーズ記事一覧はこちら →

品質管理の正体はデータ管理 ── 中小製造業のトレーサビリティと統計管理を阻むもの

品質管理の「手法」は足りている

品質管理の教科書は山ほどある。QC7つ道具、なぜなぜ分析、FMEA、SPC(統計的工程管理)。手法そのものは体系化されていて、学ぼうと思えばいくらでも学べる。

しかし中小製造業の現場で品質管理が回っていないとき、原因は手法を知らないことではない場合が多い。管理図を描きたくてもデータがない。不良の傾向を分析したくても記録が残っていない。トレーサビリティを求められても、どのロットがどの材料でいつ誰が作ったのか追えない。

品質管理の問題に見えて、実はデータ管理の問題であるケースが非常に多い。

トレーサビリティは「紐づけ」の問題

トレーサビリティとは、製品がどの材料から、どの工程を経て、いつ、誰の手で作られたかを追跡できる状態を指す。顧客からのクレーム対応、リコール時の影響範囲の特定、工程改善のための原因分析——いずれもトレーサビリティがなければ始まらない。

ここで必要なのは高度なシステムではなく、データ同士の紐づけになる。

受注番号、ロット番号、仕入先、材料ロット、工程、作業日、作業者。これらの情報がバラバラに存在していても、紐づけのキーがあれば追跡できる。逆に、どれだけ丁寧に検査記録を書いていても、紐づけのキーがなければ追跡できない。

受注番号と製品の紐づきは、規模の小さい工場でも大抵できている。受注を受けて製品を作る以上、どの注文に対して何を作ったかは自然と追える。

切れがちなのは、その先——仕入の情報との紐づけになる。どの受注の製品に、どの仕入先から、いつ届いた、どのロットの材料を使ったか。ここが結びついていないケースが非常に多い。検査成績書には「合格」と書いてあるが、使った材料のロットまでは追えない。これではクレームが入ったとき、同じ材料ロットで作った他の製品を特定できない。材料起因の不良なのか工程起因なのかの切り分けもできない。

もう一つ切れやすいポイントがある。以前の記事で、生産管理ではバッファ在庫を置いて前後工程を分断する「ポイントスケジューリング」が有効だと書いた。管理の負荷を下げるには良い考え方だが、品質の追跡という観点では、このバッファ在庫が情報の断絶点になりやすい。前工程で加工された部品がバッファに入った時点で、どのロットの材料をいつ加工したものかという情報が消え、後工程ではただ「棚にある部品」として使われる。生産効率のための分断が、トレーサビリティの分断にもなってしまう。

ここは割り切りが要る。全部品にロット番号を貼って追跡するのは中小の体力では現実的でないことが多い。ただし、少なくともバッファ在庫に入れるタイミングで「いつの加工分か」がわかる程度の単位管理——たとえば加工日や加工週で棚を分ける、現品票に加工日を書く——をしておくだけで、問題発生時の追跡範囲は大幅に絞れる。完璧な個体追跡でなくても、「3月第2週の加工分」まで絞れれば、全数回収よりはるかにましになる。

以前の記事で、受注生産の仕入管理は受注番号を軸にした紐づけで成り立っていると書いた。品質管理のトレーサビリティもまったく同じ構造になる。受注番号を一本の串として、仕入・工程・検査・出荷のデータを通す。特別な仕組みは要らない。串になるキーが存在し、各記録にそのキーが入っていること。それだけで追跡は可能になる。

紙の記録が悪いのではない

誤解のないように書いておくと、紙の検査記録が悪いわけではない。中小製造業の現場で、検査のたびにPCを開いて入力するのが現実的でない場面は多い。

問題は紙かデジタルかではなく、その記録に紐づけのキーが入っているかどうかになる。

検査記録の用紙に受注番号(またはロット番号)の記入欄があり、それが確実に書かれていれば、紙の記録でもトレーサビリティは成立する。後からデジタル化したくなったときも、キーさえあれば紐づけられる。

逆に、キーのない記録を何年分積み上げても、それは「記録した」という事実があるだけで、追跡可能な品質データにはなっていない。

検査データは「社外への証明」になる

このシリーズでは、原価や負荷、仕入といった社内向けのデータ管理を中心に書いてきた。これらは自社の判断のために使うデータであり、保管方法はExcelファイルで十分だった。

しかし検査データは性質が異なる。検査成績書は顧客への品質保証の証拠であり、クレーム対応時の根拠資料であり、業種によっては法令や規格(ISO 9001など)で保管期間が定められている。社内の管理データとは違い、「あとから出せること」が要件になる

ここで問題になるのが、紙の検査記録のまま何年分もファイルキャビネットに積み上がっている状態になる。記録は存在するが、3年前の特定の受注番号の検査成績書を探そうとすると、棚を端から探すことになる。顧客から急ぎで求められたとき、見つからないのは「記録がない」のと実質同じになる。

紙で記録すること自体は問題ないと先に書いた。ただし保管については、検索できる状態を維持する必要がある。現実的な方法としては、紙の記録をスキャンしてPDFにし、ファイル名に受注番号と日付を入れて保存するだけでも十分に機能する。検索キーがファイル名に入っていれば、フォルダの中から探せる。

以前の記事で、管理精度の向上は経営者の判断力を引き上げる「武器」だと書いた。原価の見える化や負荷の可視化は、経営者が攻めの判断をするためのデータになる。

一方、品質保証のデータは 「防具」 になる。経営者が日常的に見るものではない。しかしクレームが入ったとき、取引先の監査が来たとき、万が一リコールが必要になったとき、このデータがあるかないかで会社が受けるダメージがまったく変わる。武器と違って、防具は使わずに済むに越したことはない。しかし持っていなければ、一撃が致命傷になりかねない。

紐づけのキーと、検索可能な保管。この二つが揃っていれば、紙ベースの運用でも防具としての機能は果たせる。

統計的品質管理はデータの「形」が前提

統計的工程管理(SPC)は品質管理の中でも特にデータへの依存度が高い領域になる。Xbar-R管理図を描くには、同じ測定項目の数値データが時系列で蓄積されている必要がある。工程能力指数(Cp、Cpk)を算出するにも、十分な件数の測定値が規則的に記録されていなければならない。

ここで壁になるのが、データの「形」の問題になる。

以前の記事で、Excelのデータには「文法」があると書いた。1セル1値、型の統一、1行1件。品質データにもこの文法がそのまま当てはまる。

測定データが使えない形で残っている例:

日付 検査結果
3/5 外径 φ10.02、内径 φ5.01、OK
3/5 外径 φ10.05(※上限ギリギリ)、内径 φ4.98
3/6 OK

人間が読めば内容はわかる。しかしこのデータから管理図は描けない。数値と判定とコメントが1つのセルに混在し、測定項目が行ごとに違う形で書かれている。

使える形:

日付 受注番号 測定項目 測定値 規格下限 規格上限 判定 備考
2025-03-05 J-2501 外径 10.02 9.95 10.05 OK
2025-03-05 J-2501 内径 5.01 4.95 5.05 OK
2025-03-05 J-2502 外径 10.05 9.95 10.05 OK 上限ギリギリ
2025-03-05 J-2502 内径 4.98 4.95 5.05 OK
2025-03-06 J-2503 外径 10.01 9.95 10.05 OK
2025-03-06 J-2503 内径 5.02 4.95 5.05 OK

この形であれば、外径だけをフィルタして時系列に並べれば管理図が描ける。受注番号でフィルタすれば特定案件の検査結果が一覧できる。工程能力指数も計算できる。そして受注番号というキーを通じて、仕入データや工程データとも紐づく。

今すぐSPCをやるかどうかは関係ない。データの持ち方さえ正しければ、やりたくなったときにすぐできる。持ち方が間違っていれば、まずデータの整形から始めることになり、過去のデータは使えない。

「全数記録」で破綻するパターン

品質データの管理を始めようとすると、「全工程・全項目を記録しよう」という話になりがちになる。しかし中小製造業の現場で全数記録を徹底しようとすると、記録作業の負荷が高すぎて破綻するケースが多い。

以前の記事で、生産管理において全工程スケジューリングではなくポイントスケジューリングが有効だと書いた。品質管理でも同じ発想が使える。

押さえるべきポイントは3つ:

  1. 受入検査 ── 材料・部品が入ってきた段階。ここで記録を残せば、不良発生時に材料起因かどうかを切り分けられる
  2. 最終検査 ── 出荷前の段階。製品品質の最後の砦であり、顧客に対する品質保証の根拠になる
  3. クレーム・不良記録 ── 発生した問題の記録。これがなければ改善のサイクルが回らない

この3点だけ押さえれば、品質の追跡は8割方カバーできる。中間工程の記録は、特定の工程で不良が頻発しているなど、必要性が見えてから追加すればいい。最初から全部やろうとして、結局どれも中途半端になるよりも、3つを確実に残す方がはるかに実効性がある。

不良データは「件数」ではなく「分類」で持つ

不良の記録で最もよく見るのが、月次で不良件数だけを集計しているケース。「今月の不良は12件」という数字はあるが、どの工程で、どんな種類の不良が、どの程度の頻度で起きているかがわからない。

パレート図を描いて不良の優先順位をつけるには、不良の分類データが必要になる。分類といっても、最初から細かく定義する必要はない。

日付 受注番号 工程 不良区分 内容 数量
2025-03-05 J-2501 機械加工 寸法不良 外径公差外れ 2
2025-03-06 J-2503 溶接 外観不良 ビード不整 1
2025-03-07 J-2505 組立 欠品 ボルト不足 1

不良区分を5〜10種類程度に絞り、ドロップダウンリストで選択式にしておく。自由記述にすると「寸法不良」「寸法NG」「寸法はずれ」のように表記がゆれて集計できなくなる。これもデータの文法の記事で書いた、名称の統一と選択式の原則がそのまま効く話になる。

この形でデータが蓄積されれば、月次でパレート図を作って「先月は寸法不良が6割を占めている。機械加工の外径加工を重点的に見直す」という判断ができる。件数だけでは見えなかった改善の優先順位が、分類データによって見えるようになる。

品質管理のDXは検査装置の導入ではない

品質管理のDXというと、三次元測定機や画像検査装置の導入を思い浮かべるかもしれない。確かにこれらの装置は測定の精度と速度を上げてくれる。しかし、装置が吐き出すデータの受け皿が整っていなければ、高精度な測定値が紙に印刷されて棚にファイルされるだけで終わる。

品質管理のDXの本質は、検査装置の導入ではなくデータの設計にある。

  • どの情報を、どのタイミングで、どの形式で記録するか
  • データ同士をどのキーで紐づけるか
  • 蓄積したデータをどう集計・分析できる形にしておくか

これはExcelの使い方の範囲内でできることであり、新しいシステムも高価な装置も必要ない。紙の検査記録であっても、紐づけのキーと記録項目の設計が正しければ、品質データとして機能する。

このシリーズで繰り返し書いてきたことだが、中小製造業のDXは、ツールの導入ではなくデータの持ち方から始まる。品質管理も例外ではない。管理図やパレート図を描くための特別なソフトは不要で、Excelで十分にできる。ただし、そのExcelに入っているデータが、分析できる形で蓄積されていることが前提になる。

手法は教科書から学べる。装置は必要になれば買える。しかしデータは、正しい形で蓄積し始めなければ、後から取り返すことができない。品質管理の最初の一歩は、検査の厳格化でも装置の導入でもなく、記録の設計を見直すことにある。


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

シリーズ記事一覧はこちら →

中小製造業の社内連絡は、メールでも電話でもなくチャットがちょうどいい

全員が同じ部屋にいるなら、この話は要らない

事務所に全員が座っていて、声をかければ伝わる会社なら、コミュニケーションツールの話はほとんど意味がない。振り向いて話せばいい。

しかし現実には、事務所と工場が離れている、支店がある、業務委託の外注先とやりとりがある、営業が外に出ている——こうした「同じ場所にいない人との日常的な連絡」が発生する会社は多い。そしてこの連絡手段が、たいていの場合メールか電話に偏っている。

どちらも長く使われてきた道具だが、中小製造業の日常のやりとりには、実はどちらも微妙に合っていない。

電話の問題:相手の都合を無視する

電話は即座に伝わる。それが強みだが、同時に最大の弱点でもある。

電話をかけるということは、相手が今何をしていようと中断させるということになる。工場で作業中の人が事務所からの電話で手を止める。集中して見積もりを作っている人が電話で思考を切られる。電話はかける側の都合で成立するが、受ける側の都合は考慮されない。

もう一つの問題は、電話では考える時間がないということ。何かを判断しなければならない場面で、電話口で即答を求められる。「ちょっと確認して折り返します」と言えればいいが、そのまま口頭でやりとりが進んでしまうことも多い。結果として、十分に考えないまま判断が行われる。

そして電話には記録が残らない。「電話で言った・言わない」のトラブルは、どの会社でも経験があるのではないかと思う。

メールの問題:遅い、埋もれる、確認頻度が低い

メールは記録が残る。これは電話にない利点。しかし別の問題がある。

まず、広告メールやメルマガが多すぎる。業務メールが営業メールの山に埋もれて、重要な連絡を見落とすことがある。受信トレイの整理自体が仕事になっている人もいる。

次に、確認頻度が低い。メールを一日に2〜3回しか開かない人は珍しくない。朝と昼と終業前に確認する、というペースだと、急ぎではないが当日中に返事がほしい連絡が翌日に回ることがある。

さらに、メールは構造的に1対1のやりとりに偏る。CCで複数人に共有はできるが、関係者全員がスレッドを追えているかどうかは確認しようがない。結果として、情報が特定の人の間だけに閉じてしまう。

チャットは「ちょうどいい」位置にある

チャットツールは電話とメールの間を埋める存在になる。

電話ほどリアルタイムではない。 相手が手を止められるタイミングで読めばいい。作業中に通知が来ても、区切りがいいところで確認すれば済む。相手の集中を奪わない。

メールほど遅くない。 チャットは通知の仕組みが軽いので、メールよりも確認頻度が上がる。「見たらさっと返す」という習慣がつきやすく、数分〜数十分で返事がやりとりされることが多い。

考える余裕がある。 電話のように即答を求められない。メッセージを読んで、少し考えてから返信できる。判断を伴うやりとりでは、この「考える間」が地味に重要になる。

記録が残り、共有しやすい。 チャンネル(部屋)に関係者を入れておけば、やりとりが自然と共有される。「AさんとBさんの間で決まったことを、Cさんが知らなかった」という問題が起きにくい。

導入のハードルは低い

チャットツールの導入は、DXの中でも最もハードルが低い部類に入る。

データの移行も、業務フローの設計も要らない。アカウントを作って、部署やプロジェクトごとにチャンネルを作って、使い始めるだけ。合わなければやめればいい。

選択肢はいくつかある。

  • Slack: 最も知名度が高い。無料プランでも基本的な機能は使える。ただし無料プランではメッセージの履歴に制限がある
  • Microsoft Teams: Microsoft 365を契約しているなら追加コストなし。ただしメール・カレンダー・ファイル共有と一体化しているため、以前の記事で書いたロックインのリスクは意識しておく必要がある
  • Mattermost: OSSのチャットツール。自社サーバーで運用するため、やりとりのデータは完全に手元に残る。以前の記事でIT環境の「入れ替え可能な部品」として紹介した

どれを選ぶかは、会社の状況とIT環境への考え方で決めればいい。重要なのはツールの選定ではなく、電話とメールの間を埋める連絡手段を持つということになる。

LINEを業務で使う問題

チャットツールの話をすると、「うちはLINEで連絡している」という会社に出会うことがある。

LINEは個人のコミュニケーションツールとしては優れている。しかし業務で使うには問題がある。

個人アカウントと業務が混在する。 休日に業務連絡が個人のLINEに飛んでくる。プライベートと仕事の境界が曖昧になる。

退職時にデータが消える。 社員が辞めると、その人のLINEアカウントとともにやりとりの履歴が消える。業務上の判断経緯や連絡事項が失われる。

検索や整理ができない。 グループLINEは時系列で流れていくだけで、話題ごとに整理できない。過去のやりとりから情報を探すのが困難になる。

LINE WORKSという法人向けサービスもあるが、いずれにしても「個人のLINEで業務連絡」は早めに脱却したほうがいい。

チャットツールで変わること

チャットツールを入れたからといって、業務が劇的に変わるわけではない。しかし、いくつかの地味な変化が積み重なる。

「ちょっと確認したい」のハードルが下がる。 電話するほどではないが、メールを書くほどでもない——この中間の連絡が、チャットだと気軽にできる。その結果、確認不足による手戻りが減る。

情報が属人化しにくくなる。 チャンネルに関係者がいれば、やりとりは自然と共有される。「あの件、どうなった?」と聞かなくてもチャンネルを見ればわかる。

非同期で仕事が進む。 相手の返事を待つ間に別の仕事ができる。電話のように相手を拘束しないので、お互いの時間を効率よく使える。

どれも小さな改善だが、拠点が分かれている会社やリモートの関係者がいる会社では、この小さな改善の積み重ねが効いてくる。

テキストの限界と、電話への入口

一方で、テキストベースのやりとりにも限界がある。

「Aの場合はBで、ただしCが未確定ならDに切り替えて、その場合の納期はEで……」のように、条件が複数重なる話をチャットで書こうとすると、メッセージの情報量が膨れ上がる。書くほうも大変だし、読むほうも正確に解釈するのが難しくなる。

こういう場面では、テキストに固執する必要はない。チャットで「この件、ちょっと今から電話(Web会議)いいですか?」と一言送って、口頭に切り替えればいい。

実はここにチャットツールのもう一つの価値がある。チャットは電話への入口にもなる。いきなり電話をかけると相手の都合を無視することになるが、チャットで「今いいですか?」と聞いてからなら、相手が受けられるタイミングで通話に移れる。テキストで済む話はテキストで、込み入った話は口頭で。この切り替えがチャット上で自然にできることが、電話やメールだけの環境にはなかった柔軟さになる。

テキストは冷たく見える

もう一つ、テキストベースのコミュニケーションで気をつけたいことがある。文字だけのやりとりは、思った以上に冷淡に映る

「了解です」「確認します」「対応お願いします」——書いた側にはそのつもりがなくても、受け取る側は素っ気なく感じることがある。対面なら表情や声のトーンで補えるニュアンスが、テキストではすべて削ぎ落とされる。

自分の経験でも、チャットでのやりとりが事務的になりすぎて、チーム内の雰囲気が硬くなったことがある。対策として意識しているのは二つ。

一つは、絵文字やリアクションを意識的に使うこと。「了解です」より「了解です👍」のほうが柔らかくなる。チャットツールにはメッセージへのリアクション機能があるので、「いいね」や「ありがとう」をワンクリックで返せる。小さなことだが、やりとりの温度を保つのに効く。

もう一つは、ときどき口頭のコミュニケーションを意識的に混ぜること。チャットの効率が良いからといって、すべてのやりとりをテキストに寄せすぎると、人間関係の部分が削れていく。週に一度の短い通話や、たまの対面でのやりとりが、チャットでは伝わらない信頼関係を補ってくれる。

チャットツールは便利だが、万能ではない。効率と人間関係のバランスを取ることも、運用の一部になる。

まず「電話とメール以外の手段を持つ」こと

高度なDXの話ではない。チャットツールの導入は、社内の連絡手段を一つ増やすだけの話になる。

ただ、この「一つ増やす」が、電話とメールしかなかった会社にとっては意外と大きい。電話の即時性が必要な場面では電話を使えばいいし、正式な記録が必要な場面ではメールを使えばいい。その間にある日常的なやりとりに、ちょうどいい手段が加わる。

事務所と工場が離れている会社、支店とのやりとりが頻繁な会社、外部の協力先と日常的に連絡を取る会社——こうした環境であれば、チャットツールは検討する価値がある。導入コストも運用の手間も小さいので、試してみて合わなければやめればいい。


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

シリーズ記事一覧はこちら →

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

Excelのままでいい、ただし持ち方は変える

以前の記事で、中小製造業のデータ加工業務はExcelでも十分に回せると書いた。その考えは変わっていない。今すぐデータベースを導入する必要はないし、Excelで業務が回っているならそれでいい。

ただし一つだけ条件がある。Excelに入っているデータが、いつでもデータベースに移せる状態になっていること

今はExcelで運用するとしても、事業が成長して件数が増えたり、内製ツールを作る段階に進んだりすれば、データベースへの移行が必要になる場面は来る。そのとき、Excelのデータがきれいに整っていれば移行は簡単にできる。しかしぐちゃぐちゃな状態で蓄積されていたら、まずデータの整理から始めることになる。数年分のデータを手作業で直す作業は、想像以上に重い。

だから今のうちに、データの持ち方だけは整えておく。これはシステム導入の話ではなく、Excelの使い方の話になる。

そしてこの「持ち方」は、データベースへの移行だけでなく、Excel VBAでデータを操作する場面でもそのまま効いてくる。以前の記事でExcel VBAによる業務改善について書いたが、VBAでデータを読み込んで集計したり、帳票を自動生成したりするには、データが規則的に並んでいることが前提になる。データの持ち方が整っていれば、VBAでの自動化もすぐに始められる。持ち方が崩れていれば、VBAを書く前にデータの整形処理が必要になり、コードが複雑になって保守できなくなる。

データの「文法」がある

日本語を話すのに文法を意識しなくても通じる。しかし文章として書き残すなら、文法が要る。主語と述語がなければ読み返したときに意味がわからなくなる。

データも同じで、その場で見て理解できればいいだけなら、どんな書き方でも構わない。しかしデータとして蓄積し、後から集計したり、別のツールで読み込んだり、データベースに移したりするなら、守るべきルールがある。

ここではそれを「データの文法」と呼ぶことにする。IT経験者にとっては当たり前のことばかりだが、ITの経験がない人がExcelで業務データを管理している現場では、これらが守られていないケースが非常に多い。

ルール1:1つのセルに値は1つだけ

悪い例:

数量
3個(うち1個は予備)
5個 ※納品済み

良い例:

数量 備考
3 うち1個は予備
5 納品済み

1つのセルに複数の情報を詰め込むと、集計ができなくなる。「数量の合計を出したい」と思っても、「3個(うち1個は予備)」というセルは数値として計算できない。

値と補足情報は別のセルに分ける。これだけで、データとしての使い道がまったく変わる。

ルール2:数字のセルには数字だけ、日付のセルには日付だけ

悪い例:

納期 単価
3月中旬 約1,200円
未定 応相談

良い例:

納期 納期備考 単価 単価備考
2025-03-15 中旬目安 1200
未定 応相談

数字の列に「未定」や「約」が入ると、その列全体が文字列になる。日付の列に「3月中旬」と書くと、並べ替えも期間の計算もできなくなる。

確定していない情報は備考列に逃がして、データの列は型を統一する。データベースでは「この列は数値」「この列は日付」と型が決まっている。Excelでも同じ考え方で運用しておけば、将来の移行がそのままできる。

ルール3:名称は表記を統一し、選択式にする

悪い例:

得意先
株式会社山田製作所
(株)山田製作所
山田製作所
ヤマダ製作所

これは人間が見れば全部同じ会社だとわかる。しかしデータとしては4つの別々の得意先になる。「山田製作所の受注合計」を出そうとしても、表記が揺れているせいで正しい数字が出ない。

対策は二つ。

  • 得意先マスタを別シートに作り、入力はドロップダウンリストで選択式にする。 手入力をさせない
  • コードを振る。 得意先コード「Y001」のように、名称とは別に一意のコードを持たせる。名称が変わってもコードで紐づけられる

わずかな表記ゆれでも、データとしては致命的になる。自由入力をやめて選択式にするだけで、この問題はほぼ消える。

ルール4:データは上から下に、1行1件で登録する

悪い例:

1月 2月 3月
A製品 10 15 12
B製品 8 20 5

人間が見る分にはわかりやすい。しかしこの形式は、月が増えるたびに列が増えていく。1年で12列、3年で36列。集計も面倒になるし、データベースにはこの形では入らない。

良い例:

製品 年月 数量
A製品 2025-01 10
A製品 2025-02 15
A製品 2025-03 12
B製品 2025-01 8
B製品 2025-02 20
B製品 2025-03 5

1行に1件のデータを、上から下に積んでいく。行が増えるだけで列は増えない。この形式なら、フィルタで特定の製品や期間を絞り込めるし、ピボットテーブルで自由に集計できる。データベースに移すときもそのまま入る。

見た目は冗長に感じるかもしれないが、データとしての使い勝手はこちらのほうが圧倒的に高い。見やすさが必要なら、このデータを元にピボットテーブルや別シートで見やすい表を作ればいい。データの持ち方と見せ方は分ける

ルール5:色や罫線で状態を管理しない

悪い例:

赤く塗ったセルは「未完了」、黄色は「保留」、緑は「完了」——現場でよく見るパターンだが、これは人間にしか読めない。プログラムやデータベースは色を判定できない。

良い例:

案件名 ステータス
A案件 未完了
B案件 保留
C案件 完了

状態は文字データとして列に持つ。こうすれば「未完了の件数」をCOUNTIF関数で出せるし、フィルタで絞り込める。色で管理していると、目で数えるしかない。

色をまったく使うなという話ではない。ステータス列の値に応じて条件付き書式で色をつければ、見た目のわかりやすさとデータとしての正しさを両立できる。色は「表示」であって「データ」ではない。この区別が重要になる。

ルール6:同じ構造のシートやブックは、行と列を必ず揃える

同じフォーマットのExcelファイルを月ごとや拠点ごとに作ることがある。月次の実績表、拠点別の在庫表、案件ごとの見積書など。

このとき、行と列の構造が完全に同じであることが絶対条件になる。

たとえばA拠点の在庫表は「A列が品名、B列が数量」なのに、B拠点では「A列が品番、B列が品名、C列が数量」になっている——こうなると、VBAで複数ファイルをまとめて処理することができなくなる。人間はレイアウトの違いを見て判断できるが、プログラムは「B列の数字を合計する」としか書けない。列がずれていれば、間違った数字を集計するか、エラーで止まる。

同じ構造のファイルを複数作る場合は、テンプレートを一つ決めて、必ずそこから複製する。列の追加や順序の変更は、全ファイルに対して同時に行う。1つでも構造が違うファイルが混ざると、自動処理の前提が崩れる

なぜこのルールが必要なのか

これらのルールは、一言でまとめるとデータベースに入る形でデータを持つということになる。

データベースのテーブルは、列ごとに型が決まっていて、1行が1件のレコードで、表記は統一されている。Excelをこの形式に合わせておけば、将来データベースに移行するときにほぼそのまま移せる。

逆に、このルールを守っていないExcelは、見た目はきれいでも「人間が読むためだけの書類」であり、データとしては再利用できない。集計するたびに手作業が必要になり、別のツールに取り込もうとすると整形作業が発生する。

以前の記事で見積データの再利用について書いたが、再利用できるかどうかは、データの持ち方で決まる。持ち方が正しければ、Excelのままでも十分に再利用できるし、必要になればデータベースにも移せる。持ち方が間違っていれば、Excelの中でさえ再利用できない。

崩れたデータは、現実的には直せない

「後からデータクレンジングすればいい」という話を聞くことがある。しかし実際にやってみると、これは相当に厳しい作業になる。

自分の経験でも、表記ゆれの修正を正規表現で一括処理しようとしたことがある。「株式会社」「(株)」「㈱」を統一する程度なら対応できる。しかし現実のデータはそう単純ではない。略称、旧社名、担当者が独自に使っていた通称——こうしたものが混在していると、プログラムでは判定しきれない。結局、目視で一件ずつ確認することになるが、数千件のデータを目で見て判断すれば、そこでもまた判断がゆれる。直したはずのデータが、別の形でまた不整合を起こす。

数年分のデータが崩れた状態で蓄積されてしまうと、現実的には再利用不可能になる。データクレンジングにかかる工数が、新しくデータを取り直す工数を超えてしまう。

だからこそ、最初の段階でデータの持ち方を正しくしておくことが決定的に重要になる。後から直すコストは、最初に正しく入れるコストとは比較にならない。

データの文法は、DXの土台になる

このシリーズでは、個別原価の可視化、負荷の見える化、納期回答の仕組み化といった管理精度の向上を繰り返し取り上げてきた。これらはすべて、元になるデータがきれいに整っていることが前提になっている。

管理精度を上げるための高度なツールを導入する前に、まずExcelのデータの持ち方を見直す。1セル1値、型の統一、名称の統一と選択式、上から下に1行1件、色ではなく文字で状態を持つ、同じ構造のファイルは行列を揃える。

どれもExcelの機能の範囲内でできることであり、新しいツールもシステムも要らない。しかしこれらを守るだけで、Excelのデータは「書類」から「資産」に変わる。VBAで自動化する土台にもなるし、将来どんなツールやデータベースを導入することになっても、このデータはそのまま使える。

今すぐデータベースに移す必要はない。ただ、いつでも移せる状態にしておく。それが、中小製造業のDXにおける最も地味で、最も確実な一歩になる。


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

シリーズ記事一覧はこちら →