テックメモ

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

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

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

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

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

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

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

→ 中小製造業の内製DX ── Excel 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つでも構造が違うファイルが混ざると、自動処理の前提が崩れる。

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

これらのルールは、一言でまとめるとデータベースに入る形でデータを持つということになる。このルールを守っていないExcelは、見た目はきれいでも「人間が読むためだけの書類」であり、データとしては再利用できない。以前の記事で見積データの再利用について書いたが、再利用できるかどうかは持ち方で決まる。

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

「後からデータクレンジングすればいい」という話を聞くことがあるが、実際にやると相当に厳しい。自分の経験でも、表記ゆれの修正を正規表現で一括処理しようとしたことがある。「株式会社」「（株）」「㈱」を統一する程度なら対応できる。しかし略称、旧社名、担当者が独自に使っていた通称が混在していると、プログラムでは判定しきれない。数年分のデータが崩れた状態で蓄積されてしまうと、現実的には再利用不可能になる。後から直すコストは、最初に正しく入れるコストとは比較にならない。

どのルールもExcelの機能の範囲内でできることであり、新しいツールもシステムも要らない。しかしこれらを守るだけで、Excelのデータは「書類」から「資産」に変わる。今すぐデータベースに移す必要はない。ただ、いつでも移せる状態にしておく。それが、中小製造業のDXにおける最も地味で、最も確実な一歩になる。

---

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

• 中小製造業に「脱Excel」は必要か ── データ加工業務はExcelの使い方を変えるだけで回せる
• 受注生産の中小製造業における仕入管理は「今のやり方」から始めればいい
• データは単体では意味がない ── 在庫と原価を「つなげて見る」という内製DXの基本

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

管理精度型のDXは、何のためにやるのか

以前の記事で、内製DXには「管理精度型」と「工数削減型」の二つがあると書いた。工数削減型はわかりやすい。手作業を自動化して、浮いた時間を他に使う。効果は時間で測れるし、コストに換算できる。

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

一方、管理精度型は説明が難しい。個別原価の可視化、負荷の見える化、納期回答の仕組み化——こうした取り組みの効果を「いくら削減できるか」で聞かれると、答えに詰まる。コストカットが目的ではないものを、コストで説明しようとするから無理が生じる。

では管理精度型のDXは何のためにやるのか。自分の答えはシンプルで、経営判断の精度を高めるためになる。

正しい情報がなければ、正しい判断はできない

当たり前のことだが、意外と見落とされている。

受注を受けるかどうか。値引きに応じるかどうか。設備投資をするかどうか。人を増やすかどうか。こうした判断を、経営者は日常的に求められる。

このとき、判断の材料になる情報の精度が低ければ、判断の精度も低くなる。個別原価がわからなければ、その仕事が利益を出しているのかどうかもわからない。負荷の実態が見えなければ、納期を短縮できるかどうかもわからない。

勘と経験でなんとかなっている会社もある。しかしそれは、経営者の判断力が情報の不足を補っている状態であって、情報が不要だということではない。見えていないリスクをたまたま回避しているだけかもしれない。

管理精度型のDXは、この判断の材料を整えるための取り組みになる。

以前の記事で「見える化の本質は基準と実績の突合」だと書いた。管理精度を高めるとは、比較できる基準を持ち、実績と突き合わせられる状態にすること——同じことを別の角度から言い換えている。

→ 中小製造業の「見える化」は数字を出すことではない ── 基準と実績の突合という考え方

だから「投資対効果」という問い自体がずれている

管理精度型のDXに対して「投資対効果は？」と問うのは、「経営者が正確な情報を持つことの金銭的価値はいくらか」と問うのと同じになる。

答えられるわけがない。正確な情報があったから避けられた赤字案件、正確な情報があったから取れた値上げ交渉——こうした「起きなかった損失」や「実現した機会」は、事後的にも定量化が難しい。

工数削減型なら「月に○時間の作業がなくなった」と言える。管理精度型にはその言い方が使えない。だからといって価値がないわけではなく、価値の性質が違う。

コスト削減は「同じことをより安くやる」ための投資。管理精度の向上は「より良い判断をするため」の投資。測り方が違って当然であり、前者の物差しで後者を測ろうとすること自体が、判断を誤らせる。

管理精度の天井は経営者が決める

ここからが、自分がこのテーマで一番伝えたいことになる。

管理精度は、高ければ高いほどいいわけではない。経営者が求める水準で止まる。というより、経営者が使いこなせる水準を超えても意味がない。

たとえば個別原価を小数点以下まで精緻に出したとして、経営者がその数字を見て判断を変えないなら、その精度は不要になる。「この製品は粗利が30%前後」とわかれば十分な経営者に、「粗利は28.7%です」と出しても判断は変わらない。

以前の記事で「70点精度の個別原価管理で十分」と書いた。あの70点には根拠がある。経営判断に必要な粒度がそこだからだ。100点を目指すのは手を抜いていないからではなく、100点の情報を使いこなせる判断の仕組みが社内にないなら、100点にする意味がない。

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

逆に言えば、経営者の判断力が高ければ、もっと精度の高い情報を求めるようになる。数字を見て仮説を立て、検証し、次の手を打つ——このサイクルを回せる経営者は、自然とデータの粒度に注文をつけてくる。「この数字、もう少し工程別に見たい」「月次じゃなくて週次でほしい」。こうなったとき、管理精度を引き上げる意味が出てくる。

つまり、管理精度の天井は技術やツールの制約ではなく、経営者の判断力で決まる。

経営者の武器を磨くということ

この見方に立つと、管理精度型のDXは単なるシステム導入の話ではなくなる。

経営者の判断の武器を磨く取り組みになる。

いままで勘と経験で判断していたことに、裏付けとなるデータがつく。データがあることで、判断の確度が上がる。確度が上がると、より踏み込んだ判断ができる。踏み込んだ判断ができると、より細かいデータがほしくなる。このサイクルが回り始めると、管理精度は経営者の成長とともに自然と上がっていく。

逆に、経営者がデータに関心を持たなければ、このサイクルは始まらない。どれだけ精緻な仕組みを作っても、見なければ存在しないのと同じになる。

管理精度型のDXの成否は、ツールの出来ではなく、経営者がそのデータを使って判断を変える意思があるかどうかにかかっている。

工数削減型と管理精度型は、問いが違う

整理すると、こうなる。

	工数削減型	管理精度型
目的	同じことをより少ない手間で	より良い判断をより確かな根拠で
効果の測り方	削減された時間・コスト	判断の質の変化（定量化しにくい）
投資判断の問い	「いくら浮くか」	「経営者がこの情報を使うか」
精度の天井	業務要件で決まる	経営者の判断力で決まる

工数削減型に対して「いくら浮くか」と聞くのは正しい。コスト削減が目的だから、コストで答えるのが筋になる。

管理精度型に対して同じ問いを向けるのは筋が違う。聞くべきは「この情報があれば、経営者の判断は変わるか」になる。答えがイエスなら、それが投資の根拠になる。

まず経営者が「知りたい」と思うこと

管理精度型のDXをどこから始めるかについても、この視点は指針を与えてくれる。

高度なBIダッシュボードや精緻な原価計算から始める必要はない。経営者が日常の判断で「ここがわからなくて困っている」と感じていることから始める。

「この案件、利益が出ているのかわからない」なら個別原価の可視化。「来月の負荷がどうなるか見えない」なら負荷の見える化。負荷の見える化は、受注データへの1項目追加で始められると以前の記事で書いた。

→ 中小製造業の納期回答は、受注データと1項目で仕組み化できる

経営者自身が「知りたい」と思っている情報から手をつければ、作った瞬間から使われる。使われれば改善の要望が出る。要望に応えれば精度が上がる。

経営者が求めていない精度を先回りして作っても、使われない。経営者が求めている精度を、求められたタイミングで提供する。この順序を間違えないことが、管理精度型のDXを定着させる最も確実な方法だと思っている。

---

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

• 中小製造業の内製DXには「管理精度型」と「工数削減型」がある
• 中小製造業の多品種少量生産における原価計算の「落とし所」
• 中小製造業の「見える化」は数字を出すことではない ── 基準と実績の突合という考え方
• 受注生産の値決めと内製DX ── 「受注が選べる状態」を作ることの意味

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

防御を固めても、すり抜けはゼロにならない

セキュリティソフト、UTM（統合脅威管理）、WindowsやOfficeのアップデート、管理者権限の制限。こうした基本的な対策は当然やるべきで、やっていなければまずやる。

ただ、これらは脅威を「減らす」ための仕組みであって「なくす」ための仕組みではない。

たとえばランサムウェア。社内のファイルを暗号化して使えなくし、復号と引き換えに身代金を要求する攻撃になる。UTMがブロックする。セキュリティソフトが検知する。それで大半は防げる。しかし新種の攻撃や、社員が不審なメールを開いてしまうケースまで、すべてを防ぐことは構造的に不可能になる。

どれだけ防御を固めても、すり抜ける可能性はゼロにならない。この前提に立つと、セキュリティの本丸は防御ではなく、すり抜けたあとにどう戻すかになる。

バックアップが唯一の確実な復旧手段

ランサムウェアに感染した場合、現実的な復旧手段はバックアップからの復元しかない。

身代金を払っても復号キーが送られてくる保証はない。セキュリティベンダーが復号ツールを出すこともあるが、対応できるのは既知の型だけで、タイミングも読めない。

結局、自分のデータを自分で持っている状態——つまりバックアップ——が、唯一コントロール可能な復旧手段になる。これは以前の記事でデータの主権について書いたことと同じ構造で、自分で持っていないものは、自分では取り戻せない。

→ 中小製造業に Google Workspace は必要か

ただし「バックアップがある」だけでは足りない

ここで重要なのは、バックアップの「ある・なし」ではなく、どこにあるかになる。

ランサムウェアはネットワーク上のドライブを片っ端から暗号化する。社内のNASに毎日バックアップを取っていても、そのNASがネットワークに繋がっていれば、本体と一緒に暗号化される。バックアップがあるのに復元できない、という最悪のケースが起きる。

バックアップが有効であるためには、ランサムウェアの影響が及ばない、切り離された環境に保管する必要がある。

具体的には：

• 外付けHDDに取って、物理的に外しておく。 最もシンプルで確実。バックアップ時だけ接続し、終わったら外す
• クラウドストレージに世代管理付きで保管する。 暗号化されたファイルが同期されても、過去の世代に戻せる
• テープバックアップ。 大げさに聞こえるが、オフラインメディアとしては今でも有効

方法は会社の規模やデータ量に合わせて選べばいい。原則は一つ。バックアップの保管先が、本番環境と同じネットワーク上にないこと。

「業者に任せてあるから大丈夫」が一番危ない

以前、あるソフトウェアの導入にあたって、サーバーのハードウェア選定から環境構築、バックアップ設定までを一括で業者に依頼したことがある。専門業者だから安心だろうと思っていた。

しかし、そのサーバーが壊れたとき、バックアップイメージからの復旧がうまくいかなかった。どうやらイメージの作り方に問題があったようで、結果として復旧に数週間かかった。中小製造業にとって、サーバーが数週間止まるというのは業務が止まるということになる。

この経験で痛感したのは、専門業者に任せたからといって、バックアップが正しく機能するとは限らないということ。業者の技術力にもばらつきはあるし、構築時の設定の問題は納品時点では表面化しない。問題がわかるのは実際に壊れたとき——つまり検証していなければ、何年も気づかないまま「使えないバックアップ」を取り続けることになる。

復旧手順を自分たちで理解しておく

この問題の根っこは、バックアップの技術的な話ではなく、復旧の知識が社内になかったことにある。

以前の記事で、DXにおいて「知識がベンダー側に偏る」ことの危険性を書いた。セキュリティのバックアップと復旧でも、まったく同じ構造が起きる。

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

• バックアップの設計を業者に任せる
• バックアップが毎日動いているのを確認して安心する
• いざ壊れたときに「業者に連絡して復旧してもらおう」と思う
• 業者がすぐ来るとは限らない。来ても、数年前に構築した環境の詳細を業者側が覚えているとも限らない

以前の記事でDXの丸投げについて書いたが、構造としては同じことが起きている。

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

最低限、以下は社内で把握しておいたほうがいいと思っている。

• 何のバックアップが、どこに、どの頻度で取られているか
• バックアップからの復元手順。 実際に復元テストをやったことがあるか
• 復旧にどのくらいの時間がかかるかの見積もり
• 業者に連絡がつかない場合、自分たちだけでどこまで復旧できるか

完璧に理解する必要はない。しかし「バックアップは業者に任せてあるので大丈夫です」という状態は、「システムはベンダーに任せてあるので大丈夫です」と同じレベルの危うさがある。

見落とされがちな個人PCのバックアップ

ここまでサーバーやNASの話を書いてきたが、中小製造業で意外と盲点になるのが個人PCになる。

見積データをExcelで管理している。過去の図面修正履歴がローカルに残っている。取引先とのメールのやり取りが業務の証跡になっている。こうしたデータが個人PCにしか存在しないケースは珍しくない。そしてそのPCのバックアップを取っている人は、ほとんどいない。

PCが壊れたとき、OSの再インストールやソフトの設定は時間さえかければ戻せる。しかしデータは戻せない。ハードディスクの物理故障であれば、復旧業者に出しても取り戻せないことがある。

対策はシンプルで、BunBackupのようなフリーソフトで十分。指定したフォルダを外付けHDDやNASに定期コピーするだけのソフトで、設定も10分もかからない。毎日自動で差分バックアップを取る設定にしておけば、意識しなくてもデータが残る。

理想を言えば、業務データはサーバーに集約すべきだろう。しかし現実には個人PCにしかないデータが必ず存在する。その現実を前提にして、まず「今あるデータを失わない仕組み」を入れておく。サーバーへの集約はその後でいい。

セキュリティも「自分で持つ」

このシリーズを通じて、データの主権、ツールの選択権、知識の所在——「自分で持つ」ことの重要性を繰り返し書いてきた。セキュリティも同じだと思っている。

セキュリティ製品を導入することと、セキュリティを「持っている」ことは同じではない。UTMを置いてセキュリティソフトを入れることは大事だが、それは防御の道具を揃えた段階であって、いざというときに事業を継続できる力があるかどうかは、また別の話になる。

防御は製品に任せていい。ただ、復旧については自分たちでも動ける状態にしておく。バックアップを切り離された場所に持ち、復旧手順を理解し、定期的に検証する。地味で面倒な作業だが、これが中小製造業にとって最も現実的で、最も確実なセキュリティになる。

高価な製品を積み上げるよりも、「壊れても月曜日には出荷できる」状態を作ること。それがこの規模の会社にとってのセキュリティの本質だと考えている。

---

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

• 中小製造業のIT環境は「入れ替えられる設計」で組む ── OSSとSaaSの使い分け
• 中小製造業に Google Workspace は必要か ── 「全部クラウド」の前に考えるデータの主権

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

受注生産の現場は、変化が常態

多品種少量・受注生産の中小製造業では、業務プロセスそのものが常に変わる。顧客が変わり、製品が変わり、工程が変わる。以前の記事で「変化への追従速度」をDX手段の評価軸として挙げたが、この話はアプリケーション層だけの問題ではない。

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

アプリケーションをいくら素早く作り変えられても、その土台となるIT環境が固定的では、結局どこかで詰まる。メールはこのサービス、ファイル共有はこのサービス、データベースはこのベンダー——それぞれが長期契約やベンダー固有の仕様で固まっていると、業務の変化に合わせてIT環境を組み替えることができない。

変化への追従は、アプリケーションだけでなく、その下のIT基盤層でも求められる。

IT環境が固定化すると何が起きるか

IT環境の固定化がもたらす問題は、使い勝手の悪さではない。変化のたびにコストが発生する構造になることにある。

たとえば、あるSaaSに業務データを蓄積していて、別のツールに切り替えたくなったとする。データのエクスポート機能が貧弱であれば、移行に多大な手間がかかる。業務ロジックをそのSaaSの上に組んでいれば、ロジックの移植も必要になる。結果として「合わないとわかっているが、変えるコストが高すぎて変えられない」という状態に陥る。

以前の記事でGoogle Workspaceについて「GASで業務ロジックを組むとロックインが完成する」と書いたが、同じ構造はどのサービスでも起きうる。問題はサービスの良し悪しではなく、環境が入れ替えられない設計になっていることにある。

→ 中小製造業に Google Workspace は必要か

設計原則は「データの再利用性」

では、入れ替えられる環境をどう設計するか。原則は一つ。データが特定のツールに閉じ込められない状態を維持すること。

具体的には：

• データは標準的な形式で手元に持つ。 CSV、JSON、あるいはPostgreSQLのようなオープンなデータベース。特定のサービスでしか読めない形式に依存しない
• 業務ロジックはデータと分離する。 ロジックをSaaSの上に組むのではなく、データを手元に持った上で、処理は自分の環境で行う
• ツールは「部品」として使う。 一つのサービスに全機能を求めるのではなく、機能ごとに最適な部品を選び、組み合わせる

この原則を守っていれば、ツールが合わなくなったときに、そのツールだけを差し替えられる。データは手元にあるから、新しいツールに繋ぎ直すだけで済む。

OSSが「部品」として優れている理由

この「入れ替えられる設計」において、OSSには構造的な強みがある。

データが手元にある。 OSSは自社のサーバーやPCで動くから、データは最初から手元にある。サービス終了やアカウント停止でデータにアクセスできなくなるリスクがない。

判断の手綱が自分にある。 商用サービスを導入するとなると、少額でも稟議が要る。展開するなら説明責任が発生する。活用されるかどうかわからない段階で会社にお金を出してもらうと、「使われなかったらどうするのか」という話になる。OSSなら、まず数人で試してみて、合わなければ静かにやめればいい。この「試して、だめなら引く」という判断を自分の裁量でできることが、結果的に導入のスピードを上げる。

浸透に時間をかけられる。 商用サービスは「契約しているのに使われていない」という組織内のプレッシャーがかかる。OSSにはそれがない。一部署で半年試して、手応えがあれば広げる。なければ静かにやめる。この「急がなくていい」という性質は、ITリテラシーにばらつきがある中小製造業の現場において、地味に大きい。

標準的な技術の上に成り立っている。 OSSの多くは、オープンな標準技術をベースにしている。PostgreSQLのデータは他のツールからも読めるし、Mattermostのデータは標準的なデータベースに格納される。特定のベンダーに閉じた仕様ではないから、ツール間の接続や将来の入れ替えがしやすい。

SaaSが合う領域もある

一方で、何もかもOSSにすればいいとは思っていない。SaaSには中小製造業にとって明確な利点がある。

構築と運用の手間がゼロに近い。 OSSは自分で構築し、自分で運用する必要がある。アップデート、バックアップ、障害対応、すべて自分持ち。情シス不在の中小企業にとって、この運用負荷は軽くない。SaaSならそれを丸ごとサービス側に任せられる。

すぐに使い始められる。 契約すれば翌日から全社で使える。OSSは構築だけで数日かかることもある。

SaaSを使う際のポイントは、データのエクスポートとAPI連携がしっかりしているサービスを選ぶこと。データをCSVやAPIで取り出せるなら、そのSaaSが合わなくなったときに別の手段に移行できる。逆に、データの取り出しが難しいサービスは、いくら便利でも長期的にはリスクになる。

つまりSaaSを使う判断基準は「便利かどうか」ではなく「データを人質に取られないかどうか」になる。

基幹業務そのものはOSSでは回らない

正直に言うと、生産管理や原価管理をそのままカバーできるOSSはほぼない。ERPNextのようなOSS ERPは存在するが、多品種少量の受注生産には合わないことが多い。

OSSが効くのは基幹業務そのものではなく、基幹業務の周辺を支えるIT環境の部分になる。情報の流れ、データの可視化、ファイルの共有、業務間のデータ連携。こうした「つなぎ」の部分をOSSで固めて、基幹業務は内製ツールや既存のやり方で回す。以前の記事で整理した三層構造でいえば、OSSは第一層（コモディティ）と第二層（小さな改善）の間を埋める「インフラ部品」として位置づけるのが現実的になる。

→ 中小製造業の内製DX ── Excel VBAで済む領域と、専用言語で作るべき領域

ハードウェアも同じ原則で選ぶ

ソフトウェアの話が中心になったが、PCやサーバーといったハードウェアの調達も同じ考え方が使える。

ハードウェアは完全にコモディティで、どこで買っても同じものが届く。違いが出るのは、購入後の面倒を誰が見るかという点だけになる。

PCであれば、メーカー直販で買って社内でキッティングするのが最もコストが低い。OSのセットアップやソフトのインストールは、ITに詳しくない社員でもマニュアルがあれば対応できる範囲のことが多い。台数が少ない中小企業では、リースの管理メリットも薄く、総コストで購入に負ける。

一方、サーバーやネットワーク機器は話が変わってくる。障害が起きたとき自力で復旧できるかどうかが判断基準になる。自力で対応できないものについては、地場のIT業者に調達と保守をセットで頼むのは合理的な選択になる。業者に払っているのはハード代ではなく、何かあったときの対応力に対する保険になる。

つまりハードの調達も、ソフトウェアと同じく 「自分たちで面倒を見られるかどうか」 で線を引けばいい。

OSSをどこで動かすか ── オンプレ・VPS・クラウドの選び方

ここまでOSSの「何を使うか」を書いてきたが、「どこで動かすか」も重要な判断になる。選択肢は大きく3つ。社内のサーバー（オンプレ）、VPS、クラウド（AWS・Azure・GCP等）になる。

結論から言えば、社内からしかアクセスしないなら、オンプレが最もシンプルで安全になる。サーバーがインターネットに出ていなければ、外部からの攻撃リスク自体が発生しない。データの主権という観点でも、物理的に手元にあるのが最も確実な形になる。社内のPCやNASの延長として、MattermostやMetabaseを動かすだけなら、これで十分機能する。

問題になるのは、外からもアクセスしたいケースになる。リモートワーク対応、拠点間の情報共有、外出先からのデータ確認。こうした要件が出てきたとき、選択肢に入るのがVPSとクラウドになる。

「クラウド」というと最先端で正しい選択に聞こえるが、AWS・Azure・GCPのようなクラウドサービスは、中小製造業には過剰なことが多い。IAM（権限管理）、VPC（仮想ネットワーク）、セキュリティグループ、従量課金の見積もり——学習コストが高く、設定を間違えるとセキュリティホールになる。そもそもこれらは大規模なシステムを柔軟にスケールさせるための仕組みで、数十人規模の会社がMattermostを1台動かすには大げさすぎる。

VPSはもっと単純で、月額固定で1台のLinuxサーバーを借りるだけの話になる。SSHで入って、ソフトを入れて、設定する。クラウドのような複雑な概念は出てこない。月額1,000〜3,000円程度で、コストも読みやすい。

ただし、VPSはインターネット上にサーバーを置くことになるので、セキュリティは自己責任になる。ファイアウォールの設定、SSH鍵の管理、OSやソフトウェアの定期的なアップデート。これを怠ると、外部から侵入される可能性がある。

整理すると、判断基準はシンプルになる：

条件	選択肢	理由
社内からのアクセスだけで済む	オンプレ	最もシンプルで安全。外部リスクがゼロ
外からもアクセスしたい	VPS	安価で構成がシンプル。セキュリティは自己管理
大規模・高可用性・複数拠点統合	クラウド	中小製造業ではほぼ不要

多くの中小製造業では、まずオンプレで始めて、外部アクセスの必要が出てきたらVPSを検討する、という順番で十分だと思っている。「とりあえずクラウド」という判断は、ERPと同じで解像度が低い。何のために、どこからアクセスする必要があるのかを先に整理すれば、おのずと答えは決まる。

内製力がなければ始まらない

ここまで読んで気づいた方もいると思うが、OSSの導入には内製力が前提になる。構築、設定、運用、トラブル対応——SaaSならサービス側がやってくれることを、自分でやる必要がある。

以前の記事で整理した内製力のレベル感でいえば、OSSの導入・運用にはレベル2（設定変更・軽微な修正ができる）以上が必要になる。レベル0の会社がいきなりOSSを導入しようとしても、構築の段階で止まる。

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

逆に言えば、OSSの導入は内製力を伸ばす実践の場にもなる。Mattermostを立てるだけでも、Linuxの基礎、ネットワークの設定、データベースの概念に触れることになる。そしてこの経験は、その後の内製DXの土台になる。

「止められる」から始められる

IT環境は一度作って終わりではない。業務の変化に合わせて、環境自体を組み替え続ける必要がある。商用サービスは導入にも撤退にも組織的な判断が伴うが、OSSにはそれがない。このサイクルを自分の裁量で回せることが、変化の多い受注生産の現場において、環境を最適な状態に保ち続ける力になる。

入れ替えられる部品で環境を組んでおくことが、長期的に見て最も堅実な設計になる。OSSはその「入れ替え可能な部品」として、中小製造業のIT環境に組み込む価値がある。

---

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

• 中小製造業に Google Workspace は必要か ── 「全部クラウド」の前に考えるデータの主権
• 中小製造業の内製DX ── Excel VBAで済む領域と、専用言語で作るべき領域
• 中小製造業のセキュリティは「守り方」より「戻し方」 ── バックアップを自分で握る

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

DXの入口として勧められるGoogle Workspace

中小製造業のDXを検討していると、「まずはGoogle Workspaceを導入しましょう」という提案に出会うことが多い。メール、カレンダー、ファイル共有、表計算がすべて一つのサービスで揃い、月額数百円から始められる。確かに入口としてはわかりやすい。

自分は「機能だけ借りて、データは手元に持つ」という使い方をしてきた。ただ、検討した上でGWSに全面的に乗るのも一つの選択肢になりうる。この記事では、どちらを選ぶにしても知っておきたい判断材料を整理したい。

全部入りの手軽さは本物

Google Workspaceは「全部入り」のサービスだが、中小製造業の現場で日常的に使われるのは、だいたい次の五つに絞られる。

• Gmail： メールの送受信と、迷惑メールフィルタ
• Googleカレンダー： スケジュール共有
• Googleドライブ： ファイルの保管と共有
• Google Meet： リモート会議、拠点間の打ち合わせ
• Google Chat： 社内のチャット連絡

全部の機能を使いこなしている会社は少ないだろう。ただし、使わない機能があるから無駄かというと、そうでもない。メールはレンタルサーバー、カレンダーはサイボウズ、ファイル共有はNAS——と個別に手当てすれば、それぞれに契約・管理・保守の手間がかかる。GWSなら1つのアカウントでメール・カレンダー・ファイル共有が揃い、管理も一元化される。月額数百円でこれが全部入りなら、バンドルとしてのコスパは悪くない。

ただし、この「手軽に全部揃う」便利さが、後述するロックインの入口にもなる。

見落とされる長期コスト

Google Workspace Business Starterは1ユーザー月額680円。安く感じるが、これは積み上がる。

社員20人の会社なら、680円 × 20人 × 12ヶ月 = 年間163,200円。5年で約80万円、10年で160万円を超える。これは「全員がメールとカレンダーを使っているだけ」の費用になる。

コスト差が決定的というわけではないが、「クラウドの月額課金は永遠に続く」という点は意識しておく必要がある。

本当のリスクはコストではない

コストよりも深刻なのは、データの主権の問題になる。

Google Workspaceにデータを蓄積するということは、自社の業務データをGoogleに預けるということ。「預ける」という表現は上品すぎるかもしれない。実態としては、Googleの規約とインフラの上にデータが存在し、Googleのさじ加減一つでアクセスできなくなるリスクを負うということになる。

実際に起きている事象として：

• アカウント停止のリスク。 Googleの規約違反と判定されると、アカウントが停止される。法人アカウントでも例外ではない。停止されると、メール、ドライブ、カレンダーのすべてに一切アクセスできなくなる
• 復旧の困難さ。 問い合わせ窓口はbot対応が中心で、人間の担当者に辿り着くまで時間がかかる。中小企業には専任の法務もいない。停止期間中、業務は止まる
• 料金改定の一方的な通告。 Googleは過去に何度も料金を引き上げている。ストレージの無料枠の縮小やAPIの仕様変更も、利用者への事前相談なく行われる

ローカルにデータがあれば、HDDが壊れてもRAIDやNASのバックアップから自分の意思で復旧できる。しかしクラウドのアカウントが停止された場合、自分では何もできない。この非対称性が最大のリスクになる。

ただし、ローカルなら安全かといえば、そう単純でもない。ランサムウェアに感染すれば、ローカルのデータもネットワーク上のNASも丸ごと暗号化される。バックアップを取っているつもりで、実際には復元できる状態になっていない会社も少なくない。ローカル環境を維持するには、バックアップの運用と検証を継続的にやる必要があり、その手間は決して軽くない。

→ 中小製造業のセキュリティは「守り方」より「戻し方」
→ 中小製造業のDXとランサムウェア ── 便利にした分だけ攻撃面が増える

クラウドにもローカルにも、それぞれ違う性質のリスクがある。大事なのは「どちらが安全か」ではなく、リスクの中身を理解した上で使い分けることになる。

段階的にロックインされる構造

意識しておくべきなのは、便利に使えば使うほど抜け出しにくくなる構造があること。これはGWSに限らず、クラウドサービス全般に共通する話になる。

最初はメールとカレンダーだけ使う。この段階なら乗り換えは簡単。次にGoogleドライブにファイルを蓄積し始める。これもまだ頑張ればデータを移行できる。

問題はその次。Googleスプレッドシートに業務ロジックを載せ始めると、状況が変わる。関数やGoogle Apps Script（GAS）で集計処理を組み、Google Formsで入力を受け付け、GASで通知を飛ばす——こうなると、業務フロー全体がGoogle前提で構築される。

この段階で「やっぱりローカルに戻そう」と思っても、データはエクスポートできるが、業務ロジックはエクスポートできない。GASで書いた処理はGoogle環境でしか動かない。業務フローを一から組み直す必要がある。つまり、移行コストが残留コストを上回り、事実上のロックインが完了する。

GASやスプレッドシートの機能自体が悪いわけではない。開発プラットフォームとしてのExcel VBAとの得意・不得意の違いは、別の記事で詳しく書いた。

→ スプレッドシート＋GASという選択肢 ── Excel VBAとは得意・不得意が逆になる

併用という現実解

自分がやってきたのは、機能だけ借りてデータは手元に持つ併用になる。GWSに全面的に乗る選択を否定はしないが、機能とデータは分けられるという点は知っておいて損はない。

たとえばGASのトリガーが便利だからといって、処理するデータ本体までスプレッドシートに置く必要はない。トリガーで起動してローカルのデータを処理する、あるいはトリガーで通知だけ飛ばしてデータ処理はローカルで行う、といった分離は十分に可能になる。

データの置き場所を意識的に決める

結局のところ、重要なのは何をどこに置くかを意識的に決めることだと思っている。

外に預けていいもの： メールのやりとり、スケジュール、一般的な社内連絡。これらは最悪失っても業務が止まるわけではない。

手元に持つべきもの： 見積データ、受注履歴、原価情報、顧客情報、図面。これらは自社の業務の根幹であり、消失したら事業が止まる。アカウント停止や規約変更で突然アクセスできなくなるリスクに晒すべきではない。

この線引きができるかどうかが、Google Workspaceを「道具として使う」か「依存する」かの分かれ目になる。

道具は「借り物」か「持ち物」か

クラウドサービスは本質的に「借り物」になる。便利だが、貸主の都合で条件が変わる。料金が上がる、仕様が変わる、最悪の場合はアクセスを止められる。

ローカルの環境は「持ち物」になる。メンテナンスは自分でやる必要があるが、誰かの都合で突然使えなくなることはない。

自分は「機能だけ借りてデータは手元に持つ」というやり方をしてきた。ただ、GWSの手軽さや管理の一元化を重視して全面的に乗る選択も、トレードオフを理解した上でなら間違いではない。

大事なのは、何も考えずに流されることではなく、自社のデータがどこにあり、何に依存しているかを把握した上で選ぶこと。その判断ができていれば、GWSに全面的に乗っても、部分的に借りても、リスクは管理できる。

---

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

• スプレッドシート＋GASという選択肢 ── Excel VBAとは得意・不得意が逆になる
• 中小製造業のIT環境は「入れ替えられる設計」で組む ── OSSとSaaSの使い分け
• 中小製造業のセキュリティは「守り方」より「戻し方」 ── バックアップを自分で握る
• 中小製造業のDXとランサムウェア ── 便利にした分だけ攻撃面が増える

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

全部Excel VBAでいいのか

内製DXの話をすると、「結局どの道具で作ればいいのか」という問いにぶつかる。

自分の結論から言えば、中小製造業のデータ加工業務の大半はExcel VBAで回せる。以前の記事でも書いたが、シートの役割を分離してデータシートとUIシートを分け、VBAで制御すれば、受注管理や進捗管理、負荷の可視化まで十分に対応できる。

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

しかし、全部Excel VBAでいいかと聞かれたら、それは違うと思っている。自分自身、業務の中核になるツールはC#などで作っている。Excelでも同じことはできるが、あえて別の手段を選んでいる理由がある。

ツールの規模と「育て続ける必要性」

Excel VBAと専用の開発言語の差は、小さなツールではほとんど見えない。

たとえば、受注一覧から納期別に件数を集計するツール。こういう一瞬で全体を理解できる規模のものなら、Excel VBAで何の問題もない。壊れたら作り直せるし、引き継いだ人もコードを見ればすぐわかる。

差が出てくるのは、ツールが育ってきたとき。業務に合わせて機能を追加し、ロジックが増え、複数の業務をまたぐようになったとき、Excel VBAには構造的なしんどさが出てくる。

Excel VBAで大きくなると何が起きるか

開発者の好みの問題ではなく、構造的な制約がある。

コードが本番環境と一体化している。 VBAのコードはExcelファイルの中に埋まっている。コードを変更するということは、本番で使っているファイルを直接いじるということ。壊したら本番が止まる。だから怖くて触れなくなり、ツールが凍結する。

変更履歴が残らない。 いつ、誰が、何を変えたかを追跡する手段がない。「先週まで動いていたのに」となったとき、戻す方法がない。

構造化に限界がある。 モジュール分割はできるが、大きなロジックを整理するための仕組みが乏しい。コードの見通しが悪くなり、一部を変えたら別の場所が壊れる。

これらは小さなツールでは問題にならない。しかしツールが育って複雑になると、内製DXの最大の強みであるはずの「変化への追従速度」が、VBAの制約によって失われていく。改善したいのに改善できない、というのは本末転倒になる。

専用言語が解決すること

C#やPythonのような専用の開発言語を使うと、この問題が構造的に解消される。

開発環境と本番が分離している。 コードを変更して、テストして、問題なければ差し替える。本番を直接いじる必要がない。

変更履歴が残る。 Gitのようなバージョン管理ツールが使える。いつでも前の状態に戻せる。

保守性が高い。 コードの構造化、テスト、デバッグのための道具が揃っている。引き継いだ人がコードを読みやすい。

要するに、専用言語を使う理由は高度なことがしたいからではなく、ツールを継続的に育て続けられる環境を確保するためになる。

判断基準は「業務の戦略的重要度」

では、どこにExcel VBAを使い、どこに専用言語を使うか。その判断基準は、開発の規模だけではなく、その業務が自社にとってどれだけ重要かで決めるのがいいと思っている。

ここで、内製DXにおける道具選びを三つの層に整理してみる。

第一層：コモディティ業務 → 専用ソフト

会計、給与、勤怠、販売管理など。業種を問わず共通する業務には、安価で安定した専用ソフトがある。ここは自分で作る必要がない。

第二層：小さな改善・業務効率化 → Excel VBA

帳票の自動生成、データの集計、ちょっとした入力支援など。一瞬で理解できる規模のツールなら、Excel VBAで十分。作り直しも簡単だし、社内の「Excelに強い人」が対応できる。中小製造業の内製DXで作るツールの大半は、この層に収まる。

第三層：差別化の源泉となる中核業務 → 専用言語

自社の競争力に直結する業務プロセス。受注から出荷までのデータの流れ、独自の原価管理、顧客ごとの仕様管理など。ここは業務の変化に合わせて継続的に改善し続ける必要がある。育て続けるツールだからこそ、保守性と改善のしやすさが求められる。

「育てるかどうか」で線を引く

三つの層を分けるもう一つの見方として、そのツールを育て続ける必要があるかどうかという基準がある。

作って終わりのツールなら、Excel VBAで十分。動いているならそれでいい。壊れたら作り直すか、そのとき改めて考えればいい。

一方、業務の変化に合わせて改善し続けるツールなら、改善しやすい環境で作る必要がある。コードを安全に変更でき、履歴が残り、壊しても戻せる環境。これは道具の好みではなく、継続的な改善を可能にするための条件になる。

そして「育て続ける必要があるかどうか」は、その業務が自社の差別化にどれだけ関わっているかで判断できる。差別化の源泉である業務は、市場や顧客の変化に合わせて常にプロセスが変わる。だからツールも変わり続ける必要がある。

大半はExcelでいい、だから迷わなくていい

この三層の整理で伝えたいのは、中小製造業の内製DXは大半が第二層で回るということ。

「Excelでいいのか、もっとちゃんとしたものを作るべきか」と迷う場面は多いと思うが、迷うくらいならExcelで始めていい。一瞬で理解できる規模のツールを、必要なところから小さく作っていく。それで十分に効果は出る。

専用言語の出番は、ツールが育ってきて「これはもう簡単には作り直せない」「変更するのが怖い」と感じたとき。そのときが、第二層から第三層への移行を考えるタイミングになる。

最初から第三層を目指す必要はない。Excelで始めて、必要に応じてステップアップすればいい。その段階的なアプローチこそが、中小製造業の内製DXに最も合ったやり方だと思っている。

---

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

• 中小製造業に「脱Excel」は必要か ── データ加工業務はExcelの使い方を変えるだけで回せる
• 中小製造業のDX、どの手段が正解か ── 再現性のある内製化のレベル感
• 中小製造業のIT環境は「入れ替えられる設計」で組む ── OSSとSaaSの使い分け

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

納期回答は誰がやっているか

多品種少量・受注生産の中小製造業では、納期回答はだいたい工場長かベテランのリーダーが担っている。顧客から「いつできる？」と聞かれたら、頭の中で今の仕掛りと先の受注を思い浮かべて、「3週間くらいですかね」と答える。

継続取引の顧客なら「○月○日までに欲しい」と納期指定で注文が来ることもあるが、その場合でも「受けられるかどうか」の判断は同じ人の頭の中で行われている。

この判断が間違っていても、すぐにはわからない。保守的すぎる回答で受注を逃しても、それは見えない機会損失になる。楽観的すぎる回答で受けてしまえば、現場が残業や外注で帳尻を合わせることになり、利益が飛ぶ。

経営インパクトが大きいのに、仕組み化されていない

考えてみると、納期回答は中小製造業における最も経営インパクトの大きい判断の一つになる。

受注するかしないか、いつ届けると約束するか。この判断が売上と利益率の両方を左右している。受けすぎれば現場が破綻し、断りすぎれば売上が立たない。

にもかかわらず、この判断を支える仕組みを持っている中小製造業はほとんど見たことがない。根拠は特定の人の記憶と経験。その人が休んだり辞めたりしたら、誰も精度の高い納期回答ができなくなる。属人化のすべてが悪いわけではないが、経営判断に直結する部分は仕組みで支える必要がある。

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

原因は「負荷が見えていない」こと

なぜ仕組み化されていないかというと、工場の負荷状態が可視化されていないからになる。

受注データは何かしらの形で記録されている。Excelでも、販売管理ソフトでも、受注伝票でも、品名・数量・納期は残っているはず。ただ、受注データの起点をどこに置くかで使い勝手が変わる。以前の記事で書いたが、見積番号を起点にしておくと、受注後のデータ活用の幅が広がる。

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

しかしそのデータから「来月の第2週、うちの工場はどのくらい埋まっているか」が見えるかというと、見えていない会社がほとんどだと思う。

データはあるのに、判断に使える形になっていない。これが問題の正体になる。

負荷の見える化は、簡単なExcelで始められる

大掛かりな仕組みは要らない。受注データを一覧にして、納期から逆算して週単位で並べるだけで、負荷の濃淡は見えてくる。

たとえば、受注一覧に納期が入っていれば、「納期が来月第2週の受注がこれだけある」という集計はExcelで簡単にできる。それだけで、今まで頭の中にしかなかった情報が目に見える形になる。

精度はざっくりでいい。今の比較対象がゼロ——つまりベテランの記憶だけ——なのだから、多少粗くても可視化されているだけで判断の質は大きく変わる。70〜80点の精度で十分という話は原価計算でも同じで、完璧を目指して動けなくなるより、ざっくりでも回し始める方が現場は前に進む。

→ 受注生産の原価計算は、これぐらいの精度で十分 ── 中小製造業のアワーレート計算

「来月の第2週、すでに5件入っている」という情報があるだけで、新しい引合いに対して「この週は厳しいので翌週でどうですか」と根拠を持って答えられる。

追加で必要な入力は、最大でも1項目

ここまでは受注データの納期を並べるだけだが、もう一歩進めて負荷の「量」を積みたくなる。件数だけではなく、どのくらいの生産ボリュームがあるかを知りたい。

ここで生産スケジューラーを入れようとすると、製品別の標準時間マスタ、工順マスタ、工程別のキャパシティ設定……と、使い始める前に膨大なマスタ整備が必要になる。多品種少量の製品ごとにこれを整備するのは、現実的ではないことが多い。

しかし負荷のざっくりした可視化が目的なら、そこまでの精度は要らない。

受注金額が使えるケース。 受注金額と生産負荷がある程度相関する場合は、金額をそのまま負荷の代理指標にできる。受注データには金額が必ずあるから、追加入力はゼロ。今あるデータだけで、週ごとの負荷を金額ベースで山積みできる。

金額と負荷が相関しないケース。 材料費の比率が高い製品と加工費の比率が高い製品が混在するような場合、金額だけでは生産負荷を反映できない。この場合は、受注時に「工数ランク」のようなものを一つだけ登録してもらう。たとえばS・M・Lの3段階でもいい。精密な工数見積もりではなく、「この案件は重い・普通・軽い」という粒度で十分になる。

どちらのケースでも、追加で必要な入力は最大1項目。それだけで負荷の山積みと溢れの検知ができるようになる。

作り込む価値がある仕組み

ざっくりExcelで始められると書いたが、だからといってずっとざっくりのままでいいわけではない。納期回答は経営インパクトが大きい判断だからこそ、ある程度作り込む価値がある。

作り込むといっても、生産スケジューラーのような大掛かりなシステムを指しているわけではない。Excelの上で、受注データから負荷を自動計算し、キャパシティの上限を超えている週を警告するような仕組みを作る。受注が追加されるたびに負荷の山が更新され、溢れが一目でわかる状態にする。

過去の実績が溜まってくれば、製品の種類ごとに実績工数の傾向が見えてくる。最初はS・M・Lの3段階だったものが、もう少し精度の高い数字に置き換わっていく。仕組みを使いながら精度を上げていけるのは、内製ならではの強みになる。

生産スケジューラーとの違い

生産スケジューラーは、工程単位で詳細な計画を立てるツール。どの機械にいつどの作業を割り当てるかを最適化するのが目的になる。

ここで提案しているのは、それとはまったく違うレイヤーの話。受注データから週単位の負荷の塊を積み上げて、溢れているかどうかを見るだけ。工程の詳細な割り当ては扱わない。

これは以前の記事で書いたポイントスケジューリングの考え方と同じで、全工程を管理しようとするのではなく、経営判断に必要なポイントだけを押さえる。納期回答に必要なのは「この週は空いているか埋まっているか」であって、「火曜日の午後にA旋盤が空いているか」ではない。

→ 多品種少量・受注生産の中小製造業に、全工程スケジューリングは必ずしも要らない

生産スケジューラーも、ERPの生産管理モジュールも要らない。受注データと1項目あれば、納期回答を特定の人の記憶から解放できる。

最初はざっくりでいい。ざっくりでも、ゼロよりはるかにましだから。そこから使いながら育てていくのが、中小製造業の内製DXらしいやり方だと思っている。

---

関連記事：

• 多品種少量・受注生産の中小製造業に、全工程スケジューリングは必ずしも要らない
• 中小製造業の生産計画は、見積もりデータの再利用から始められる
• 中小製造業に「脱Excel」は必要か ── データ加工業務はExcelの使い方を変えるだけで回せる

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

ERPと聞いて何を思い浮かべるか

「そろそろERPを入れたほうがいいですよ」。中小製造業の経営者なら、ベンダーやコンサルからこう言われた経験があるかもしれない。

ERPと聞くと、受注から生産、出荷、会計まで、すべてが一つのシステムでつながる姿を想像する。バラバラだったExcelや紙の業務が統合されて、経営の見える化が実現する——そういうイメージだろう。

しかし、実際にERPを導入した中小製造業で、そのイメージ通りに運用できている会社がどれだけあるか。自分が見てきた現場では、かなり少ない。

ERPの「主戦場」はどこか

ERPという言葉は守備範囲が広すぎて、何を指しているのかが曖昧になりがちになる。機能を分解してみると、ERPの主戦場は明確にある。

• 販売管理： 受注・売上・請求
• 購買管理： 発注・仕入
• 在庫管理： 入出庫・棚卸
• 会計連携： 上記のデータを会計に流す

これらがERPの中核機能であり、最も成熟している部分になる。ERPが「基幹システム」と呼ばれる理由は、この商流と金流のデータを一元管理できるところにある。

生産管理モジュールを持つERPもあるが、ここが多品種少量・受注生産の中小製造業にとっては落とし穴になりやすい。

生産管理はERPの得意領域ではない

ERPの生産管理モジュールは、基本的に標準的なBOM（部品表）と工順を前提としている。同じ製品を繰り返し作る量産型の製造業には合う。

しかし多品種少量・受注生産の現場では、製品ごとにBOMが違い、工程の順序も変わり、段取りの判断も毎回異なる。標準化しきれない部分が多すぎて、ERPの生産管理モジュールに業務を合わせようとすると、カスタマイズ費用が膨らむか、現場が入力負荷に耐えられなくなるか、どちらかになりやすい。

結果として、よく見る光景はこうなる。

ERPの受発注・在庫モジュールは使っているが、生産管理は結局Excelで回している。

これはERPが悪いわけではない。ERPの得意領域と、自社が本当に困っている領域がずれているだけになる。

「ERP」で一括りにするから判断を間違える

問題の根っこは、「ERP」という一語の解像度が低すぎることにあると思っている。

経営者が「うちもERPを入れるべきか」と考えるとき、頭の中では「業務全体が一つのシステムでつながる」というイメージが先行する。しかし実態としてERPが確実にカバーするのは受発注・在庫・会計の統合であって、多品種少量の生産管理はそもそも守備範囲の外にあることが多い。

この解像度のまま導入を決めると、こうなる。

• ERPの価格で、実質的には販売管理ソフトを買っている
• 本当に困っていた生産の流れは何も変わっていない
• 「思っていたのと違う」が、導入後に初めてわかる

ベンダーが嘘をついているわけではない。ERPには生産管理モジュールもあるし、カスタマイズすれば対応できると言われればその通り。ただ、その「カスタマイズ」のコストと、自社の業務に本当に合うかどうかは、別の話になる。

まず課題を切り分ける

ERPを検討する前に、自社が困っている課題を二つに切り分けることを勧めたい。

1. 商流・金流のデータ管理（受発注・在庫・会計）

ここは定型的な業務で、業種を問わず共通する部分が大きい。いわゆるコモディティ業務になる。

2. 製造プロセスのデータの流れ（見積→手配→工程→進捗→出荷→原価）

ここは自社の業務プロセスに強く依存する部分で、製品も工程も会社ごとに違う。

この二つは性質が違うのに、「ERP」という一語で両方を解決しようとするから噛み合わなくなる。

コモディティ業務は専用ソフトで十分

受発注・在庫・会計の管理は、中小製造業向けの安価な専用ソフトで十分に回せる。販売管理ソフトと会計ソフトを連携させれば、ERPの中核機能と同等のことが、はるかに低いコストで実現できる。

この領域にERPの価格を払う必要があるかは、冷静に考えてみる価値がある。

製造プロセスは内製の小さなツール群で回す

では、本当に困っている製造プロセスのデータの流れはどうするか。ここは自社の業務に合わせた仕組みを、小さく内製するのが現実的だと考えている。

狙うのは、データが一回の入力で下流に流れる構造。

受注の段階でデータを確定させ、そこから手配・工程・進捗・出荷へとデータが流れていく。人間がやるのは確認と修正だけ。二重入力をなくすことが、最も効果の大きい改善になる。

大掛かりなシステムは要らない。Excelをベースに、シートの役割を分離し、VBAで制御するだけでも、この流れは作れる。以前の記事で書いた「データシートをDBのように扱い、UIシートと分離する」設計がそのまま使える。

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

ポイントは、最初から全工程を一気に作ろうとしないこと。まずは最もデータの二重入力が多い部分、たとえば受注と手配の間をつなぐところから始めて、うまくいったら次の工程へ広げていく。

ERPが合う会社、合わない会社

ERPを否定したいわけではない。ERPが合う会社は確実にある。

• 拠点が複数あり、リアルタイムでデータを共有する必要がある
• 製品の種類が比較的限定されていて、BOMや工順が標準化できる
• 管理部門に、システムを運用・活用できる人材がいる

こうした条件が揃っていれば、ERPの統合力は大きな武器になる。

一方、多品種少量・受注生産で、拠点も一つか二つ、製品ごとに工程が変わるような中小製造業であれば、ERPの恩恵を受けにくい構造にある。その場合は、コモディティ業務を安価な専用ソフトに任せ、製造プロセスの部分は自社に合った小さなツールを内製で作るほうが、コストも導入の速さも、変化への対応力も上回ることが多い。

「ERP」の解像度を上げることから始める

「うちもERPを入れるべきか」という問いに対して、自分の答えは「その前に、ERPという言葉の解像度を上げましょう」になる。

自社が本当に困っているのは、受発注・在庫の管理なのか、製造プロセスのデータの流れなのか。前者ならERPでなくても安い専用ソフトで解決できる。後者ならERPでも解決しにくいことが多く、内製のほうが合う可能性がある。

ERPという一語に惑わされず、課題を分解して、それぞれに合った手段を選ぶ。地味だが、これが中小製造業のシステム投資で最も失敗しにくいアプローチだと思っている。

---

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

• 中小製造業の内製DXには「管理精度型」と「工数削減型」がある
• 中小製造業のIT環境は「入れ替えられる設計」で組む ── OSSとSaaSの使い分け

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

誤解される前に言っておきたいこと

「Excelで十分」と言うと、思考停止に聞こえるかもしれない。DXの文脈では「脱Excel」が合言葉のようになっていて、Excelを肯定する発言は時代遅れに映る。

自分は中小製造業で内製DXを推進してきた立場で、業務に合わせてWebアプリやデータベースを使ったシステムも作ってきた。その経験を踏まえて思うのは、多品種少量・受注生産の中小製造業において、データを加工する業務プロセスはExcelでも十分に回せるということ。ただし、使い方を変える必要がある。

対象を絞る

まず前提として、すべてをExcelでやれと言っているわけではない。

• 会計・給与・勤怠などのコモディティ業務 → 安価で安定した専用ソフトがある。それを使えばいい
• CAD/CAM・ロボット制御など → 専門ソフトの領域。Excelの出番ではない

Excelでも回せると言っているのは、それ以外のデータを加工する業務プロセス。受注管理、見積、工程の進捗把握、原価集計、在庫管理——こうした、自社の業務プロセスにフィットさせる必要がある領域の話になる。

そしてこの領域こそが、外注やパッケージでは対応しきれず、かといって本格的なシステム開発に踏み切るほどでもない、中小製造業が最も悩むゾーンだと思う。「ERP」という一語で片づけるには解像度が低すぎる、という話は以前の記事で書いた。

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

「壊れるExcel」と「回るExcel」は別物

世の中で問題視されているExcel運用は、だいたいこういう状態だろう。

• 一つのシートに何でも詰め込んでいる
• 誰かが数式を壊すと全体が崩れる
• ファイルがコピーされて、どれが最新かわからない
• 作った人にしか構造がわからない

これは確かに問題だが、Excelという道具の問題ではなく、使い方の問題になる。

「脱Excel」論の多くは、この壊れた状態のExcelを前提にしている。壊れた使い方を直せばいいのに、道具ごと捨てて新しいシステムを入れようとする。そして新しいシステムが現場に合わず、結局Excelに戻る——という話は、製造業では珍しくない。

使い方を変える：シートの役割を分ける

自分がExcelで業務の仕組みを作るとき、最も意識しているのはシートの役割を分離することになる。

• データシート： マスタや実績データを格納する。直接手で編集しない前提で運用する
• UIシート： ユーザーが入力・操作する画面
• 出力シート： 帳票や集計結果を表示する

データシートはデータベースのテーブルと同じ扱い。ここにデータが蓄積され、VBAを通じて読み書きする。ユーザーはUIシートだけを触り、データシートには直接触れない。

これだけで、先ほどの「壊れるExcel」の問題はほぼ消える。データと画面が分かれているから、誰かが数式を壊してデータが飛ぶことがない。どのシートが何の役割かが明確だから、構造もわかりやすくなる。

データシートのデータは「いつでもDBに移せる形」で持っておくと、将来的にデータベースへ移行する余地も残せる。

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

なぜWebアプリではなくExcelなのか

Webアプリを作ればいいじゃないかという意見もあるだろう。自分もケースによってはそちらを選ぶこともある。それでも多くの場面でExcelを選んできた理由がある。

UIを作るコストがゼロ。 Webアプリを作ると、画面設計・レイアウト調整・レスポンシブ対応と、UI周りだけで相当な工数がかかる。Excelなら、セルの配置がそのままUIになる。

教育コストがゼロ。 全員がすでに使い方を知っている。新しいシステムを導入すると必ず発生する「操作方法の説明会」が要らない。

出力がそのまま帳票になる。 製造業では紙の帳票がまだ必要な場面が多い。Webアプリだと印刷用のレイアウトを別途作る必要があるが、Excelならそのまま印刷できる。

現場が自分で微調整できる。 「この列をもう少し広くしたい」「ここに項目を追加したい」という要望に、現場が自力で対応できる部分がある。開発者に頼まなくていい。

つまりExcelを選ぶ理由は、技術的な優位性ではなく導入と定着のしやすさにある。中小製造業のDXで最も難しいのは、作ることではなく使ってもらうこと。その壁が低い選択肢として、Excelはもっと見直されていいと思う。

よくある批判に答える

「データ量が増えたら重くなるのでは？」

今のPCスペックなら、中小製造業のデータ量で重くなることはほぼない。数万件のデータシートを頻繁に参照する場合は工夫が必要で、Range データを配列に読み込んでオンメモリで検索するといった対処をすれば十分に速く動く。

「作った人しかメンテできないのでは？」

これはExcel固有の問題ではない。Pythonで作ろうがWebアプリで作ろうが、作った人が辞めたらメンテできなくなるリスクは同じ。なのにExcelだけが「属人化するからダメ」と批判されるのは公平ではない。属人化は道具の問題ではなく、組織の問題になる。属人化そのものとどう向き合うかは、以前の記事で書いた。

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

「複数人で同時に使えないのでは？」

常時複数人が同時に書き込む必要がある場合は、外部データベースをバックエンドに置くべきだと思う。ただしその場合でも、UIとしてのExcelは読み取り専用で残せる。Excelを捨てる必要はなく、裏側を強化すればいい。

「脱Excel」の前に、Excelの使い方を見直す選択肢

「脱Excel」が必要な場面はもちろんある。ただ、中小製造業のデータ加工業務という文脈では、Excelの使い方を変えるだけで解決できることも多い。

変化への追従速度が速い。導入の壁が低い。教育が要らない。帳票がそのまま出る。そして何より、すでに手元にある。

100点のシステムを時間とコストをかけて導入するのも一つの道だが、今あるExcelの使い方を変えて80点の仕組みを来週から回し始めるという選択肢も、中小製造業のDXとしてはもっと検討されていいと思っている。

---

関連記事：

• 中小製造業の内製DX ── Excel VBAで済む領域と、専用言語で作るべき領域
• 中小製造業のExcelデータ、帳票型でも「行列が揃っていれば」救える
• 中小製造業の内製DXは「改善」の前に「地固め」から始める

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

手段の選択肢は多いが、評価軸がぼやけている

DXを進めるにあたって、手段の選択肢は意外と多い。パッケージ導入、OSS導入、ベンダーによるフルスクラッチ開発、小規模ベンダーへの開発委託、内製エンジニアによるプログラミング、ローコード開発、業務委託の活用。どれがいいのかという問いに対して、一般的には「まずパッケージを検討し、合わなければスクラッチ」という順序が語られることが多い。

しかし多品種少量・受注生産の中小製造業という文脈に絞ると、この一般論はむしろ逆に作用すると感じている。

評価軸は「変化への追従速度」

この業態の最大の特徴は、業務プロセス自体が常に変動することにある。量産型とは決定的に違う点で、「一度作って終わり」のシステムでは対応できない。

パッケージもベンダー開発も、変更に対するリードタイムが長い。受注生産の現場は「来月からこのやり方に変えたい」が日常なのに、要件定義→見積→開発→テスト→リリースで数ヶ月かかるのでは、現場が先に進んでしまう。

どの手段が正解かを考えるとき、最も重要な評価軸は変化への追従速度になる。この軸で測ると、業務を最も深く理解している社内の人間が直接手を動かせる状態が、結果的に最も速い。

各手段の向き不向き

手段	向いている領域	落とし穴
パッケージ導入	会計・給与・勤怠などコモディティ業務	生産管理系は多品種少量に合わないことが多い。カスタマイズ費が膨らみがち
OSS導入	特定機能の部品として（DB、BIツール等）	運用・保守できる人が社内にいることが前提
ベンダーフルスクラッチ	大規模・長期安定の基幹系	コストが大きく、知識がベンダー側に偏る
小規模ベンダー開発	特定業務のツール化	柔軟だがドキュメントが手薄になりやすく、知識が社内に残りにくい
内製（プログラミング）	業務の中核、差別化に直結する領域	人材の採用・育成が最大の壁
内製（ローコード）	現場主導の小さな改善、入口として	複雑になると限界にぶつかる
業務委託	内製の立ち上げ期、技術的なギャップ埋め	知識が退場とともに流出するリスク

どの手段にもメリットはあるし、うまくいっている会社もある。ただ、多品種少量の受注生産で「現場の変化に追いつける仕組み」を作ろうとすると、内製の優位性が際立ってくるというのが、現場を見てきた実感になる。

なお、内製と外注をどう使い分けるかの線引きについては、別の記事で書いている。

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

ここからは、内製に軸足を置くとして「どう始めるか」の話に進む。

内製化の最大のハードルは人材

ここまで聞くと「内製化最高」となりがちだが、最大の問題はハードルの高さにある。中小製造業で事務作業をしている人に「プログラミングを覚えろ」と社内命令を出すのは現実的ではない。大企業のように潤沢な人材がいるわけでもない。

プログラミングは意欲の問題ではなく適性の問題で、業務で使えるレベルまで自走できるかどうかは「好きかどうか」にかなり依存する。中小製造業に入社する人の動機は「ものづくり」であって「プログラミングがしたい」ではない。ゴリゴリのプログラマーが社内にいること自体が例外的で、それを戦略の前提にはできない。

内製化にはレベルがある

「内製化＝社員全員がプログラマーになること」ではない。自分が考える内製力のレベル感はこうなる。

• レベル0： 完全外注。中身は誰もわからない
• レベル1： 仕組みを「理解できる」人がいる
• レベル2： 設定変更・軽微な修正ができる人がいる
• レベル3： ローコード等で業務ツールを作れる人がいる
• レベル4： プログラミングで自由に作れる人がいる

多くの会社はレベル0で、いきなりレベル4を目指すから「無理だ」となる。しかしレベル1〜2に引き上げるだけでも状況は劇的に変わる。ベンダーと対等に会話できるようになるし、「この変更は自分たちでできる」という判断ができるようになる。

「育成」ではなく「発掘」

全員に求めるのではなく、1人見つけるのが出発点になる。現場や事務の中に、Excelマクロを自発的に作っているような人がいることがある。あるいは趣味でPCを触るのが好きな人。そういう人に業務時間の一部を使って取り組んでもらう。

「社内命令でプログラミングを覚えろ」ではなく、すでに素養がある人を見つけて環境と時間を与える。命令ではなく発掘。これなら再現性がある。

AI支援がレベル間の壁を下げている

レベル4の人材を社内で見つけるのはほぼ運だと述べたが、ここに今、大きな変化が起きている。AIコーディング支援によって、レベル3の人がレベル4に近いアウトプットを出せる場面が増えている。

完全なレベル4にはならない。しかし中小製造業のDXに必要なのは、最先端のWebサービスを作ることではなく、自社の業務に合った実用的なツールを作って回すことだ。それなら、レベル3にAI支援を組み合わせた「レベル3.7」程度で十分回るケースが多い。

まず自社のレベルを知るところから

内製化で大事なのは、レベル4を目指すことではなく、今の自分たちがどのレベルにいるかを正確に把握すること。レベル0ならまずレベル1を目指す。レベル2にいるなら、AI支援を活用してレベル3の先を狙う。

どの手段が正解かという問いに対する答えは、「自社の内製化レベルに合った手段を選ぶ」になる。レベル0の状態でパッケージを入れても中身がブラックボックスになるだけだし、レベル2の会社がフルスクラッチに挑む必要もない。ゴリゴリのプログラマーを社内で育てようとしなくていい。ツールやExcelに強い人を1人見つけて、ローコードやAI支援を使える環境を整える。そこから始めるのが、中小製造業のDXにおいて最も再現性のある形だと考えている。

---

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

• 中小製造業の内製DXには「管理精度型」と「工数削減型」がある
• 中小製造業の内製DX ── Excel VBAで済む領域と、専用言語で作るべき領域
• 手作業でできることしかシステムにできない ── 中小製造業の内製DXの正しい順番

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