テックメモ

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

多品種少量・受注生産の中小製造業では、業務プロセスそのものが常に変わる。顧客が変わり、製品が変わり、工程が変わる。以前の記事で「変化への追従速度」を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を検討する、という順番で十分だと思っている。「とりあえずクラウド」という判断は、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を検討する前に、自社が困っている課題を二つに切り分けることを勧めたい。

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導入、ベンダーによるフルスクラッチ開発、小規模ベンダーへの開発委託、内製エンジニアによるプログラミング、ローコード開発、業務委託の活用。どれがいいのかという問いに対して、一般的には「まずパッケージを検討し、合わなければスクラッチ」という順序が語られることが多い。

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

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

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

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

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

各手段の向き不向き

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

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

→ 中小製造業の内製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の正しい順番

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

一緒くたに語られがちな内製DX

内製DXという言葉で括られるソフトウェアには、実は目的が異なる二つの型がある。「管理精度を上げるソフト」と「工数を削減するソフト」。この二つは設計の方針も導入のアプローチも違うのに、あまり区別されないまま語られることが多い。

自分が内製で業務ソフトを作ってきた経験では、この区別を意識するかどうかで、定着するかしないかが大きく変わると感じている。

管理精度型と工数削減型の違い

管理精度型は、今まで見えなかったものを見えるようにするソフト。在庫の正確な把握、勤怠の記録、プロジェクト進捗の可視化など。導入後、数値化や構造化によって経営判断の質が上がるのが狙いになる。

工数削減型は、今までやっていた作業を減らす・なくすソフト。手作業の自動化、帳票生成、データ連携など。導入前後で時間が測りやすく、効果が目に見える。

この二つを混同すると問題が起きる。管理精度型を「工数削減」で評価すると、現場から「仕事が増えただけ」と反発される。工数削減型に「管理が良くなったか？」と問うても、そもそもそこは変わっていない。経営層への説明が曖昧になり、どちらも中途半端な投資判断になる。

両方を兼ねるソフトは成功しやすい

ただし、二つの型がきれいに分かれるとは限らない。ペーパーレス化はその典型で、紙を探す手間が減り（工数削減）、同時にデータが構造化されて管理精度も上がる。

こういう両立型は、導入してもまず成功する。当たり前の話だが、使う本人が楽になり、かつ管理も良くなるなら、反対する理由がない。

逆に言えば、成功しやすい内製DXには共通点がある。使う人自身にメリットがあるかどうか。ここが分かれ目になる。

分類するのは「ツール」ではなく「体験」

ここまで読んで、「そんなに簡単に二つに分けられるのか？」と思った方もいるだろう。CRMはどっちだ、工数入力はどっちだ、と。

結論から言うと、ツール単位で分類しようとするとうまくいかない。分類すべきなのは、ツールではなく使う人の体験の方になる。

CRMを例にすると、営業担当にとって商談内容を毎回入力するのは負担が増える体験（管理精度型）だが、過去の対応履歴をすぐ引き出せたり、フォロー漏れを通知してくれたりする部分は楽になる体験（工数削減型）になる。一つのツールの中に、両方の体験が混在している。

工数入力も同じ構造で、毎日作業時間を記録する部分は純粋に負担が増える。しかし、そのデータから自分の稼働状況が可視化されて、無理な仕事を断る根拠にできるなら、入力者本人にもメリットがある。

つまり、二つの型は「このソフトは管理精度型」「あのソフトは工数削減型」とラベルを貼るためのものではない。一つのソフトの中で、どの機能が誰にとってどちらの体験になっているかを見るための視点になる。

そして設計で考えるべきは、管理精度型の体験（負担が増える部分）をどれだけ小さくして、工数削減型の体験（楽になる部分）をどれだけ大きくできるかというバランス。そのバランスが「楽になる」側に傾いていれば自然に定着するし、「負担が増える」側に傾いているなら、次に述べるような設計上の工夫と導入戦略が必要になる。

管理精度だけを目的にしたソフトが定着しにくい理由

管理精度型の構造的な問題は、入力する人と恩恵を受ける人が違うことにある。

現場の担当者が毎日データを入力する。その数字を見て判断に使うのは管理者や経営層。担当者にとっては純粋に作業が増えただけで、自分の仕事が楽になるわけではない。

だから「入力が面倒」「Excelでいいじゃん」となって、次第に使われなくなる。管理精度型のソフトが形骸化するパターンは、だいたいこの構造で説明がつく。

管理精度型を成功させる設計のコツ

自分が管理精度を目的としたソフトを作るときに意識しているのは、作業者の負担をギリギリ変わらないラインに抑えること。

• 工数が減る → 現場が喜んで使う
• 工数が変わらない → まあ使ってくれる
• 工数が少しでも増える → 抵抗が始まる

この閾値はかなりシビアで、紙に手書きしていたものをフォームに入力するだけでも「前のほうが早かった」と言われることがある。

だから設計では、今の作業フローをそのまま置き換える形にする。入力項目は最小限にする。選択式やデフォルト値で手間を減らす。管理側としては「せっかく作るならあの項目もこの項目も」と欲張りたくなるが、それをやった瞬間に現場の負担が増えて失敗ルートに入る。

管理精度型のソフト設計は、言い換えれば管理側の欲を削る作業でもある。内製だからこそ、このさじ加減ができるのは強みだと思う。

導入アプローチも型によって変える

設計だけでなく、導入の仕方も二つの型で変えている。

管理精度型はトップダウン寄りで進める。上長に話を通して、「会社の仕組みとして必要」というお墨付きをもらう。現場にとって自発的に使う動機がないソフトは、組織としての後押しがないと定着しない。負担がプラマイゼロに抑えられていれば、「会社で決まったことなら」と使ってくれる。

工数削減型はボトムアップ寄りで進める。上長には「こういうの作りました、使ってOKですか」と許可だけ取る。あとは現場に自由に使ってもらえば、楽になるのだから勝手に広まる。むしろ上から押し付けると「やらされ感」が出て逆効果になりかねない。

このアプローチを逆にすると失敗しやすい。工数削減ツールをトップダウンで強制すると、自分のやり方がある人ほど反発する。管理精度ツールをボトムアップで放置すると、誰も自発的に使わないまま消えていく。

まとめ：型を見極めてから設計と導入を決める

内製DXに取り組むとき、最初にやるべきは「これは管理精度型か、工数削減型か、その両方か」を見極めること。

型が違えば、設計の方針も導入の戦略も変わる。ここを一緒くたにしたまま「内製DXで業務改善」と進めると、打ち手がぼやける。自分の実感としては、この型の見極めが内製DXの最初の仕事だと思っている。

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

• 中小製造業の内製DX ──「作る」前に「やめる」を考える
• 中小製造業のDX、どの手段が正解か ── 再現性のある内製化のレベル感
• 管理精度の天井は、経営者の判断力で決まる ── 「コスト削減」では説明できないDXの話

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

「ちゃんとした仕入管理」を目指すと行き詰まる

「仕入管理をちゃんとしたい」という話になったとき、パッケージの仕入管理モジュールを検討したり、ERPの導入を考えたりすることがある。

ただ受注生産・多品種少量の中小製造業に必要な仕入管理は、そこまでの仕組みを必要としないことが多い。仕入管理に求められるのは2つだけになる。「どの案件にいくら材料費がかかったか（個別原価の材料費部分）」と「誰にいくら払うか（支払管理）」——この2つが把握できれば、仕入管理として十分機能する。

そしてこの2つは、受注番号を軸にした紐づけと、直接材と間接材の区分で対応できる。

軸は受注番号による紐づけ

仕入台帳の基本設計は「発注1件 = 1行」で、必ず受注番号を入れることになる。

受注番号があれば後から案件別に集計できる。どの案件に材料費がいくらかかったかが出る。これに加工費としてのアワーレートを乗せると、個別原価になる。

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

受注番号での集計と、仕入先ごとの集計は同じ台帳から出せる。案件別は月次原価の元データ、仕入先別は買掛・支払管理の元データになる。1つの台帳が2つの目的を兼ねる。

直接材と間接材を分ける

受注生産の仕入には大きく2種類ある。

直接材は、特定の案件のために購入するもの。鋼材、特殊部品、外注先への支給材料。受注番号で紐づけて追跡する対象になる。

間接材は、複数の案件に共通して使う消耗品。ボルト、ナット、塗料、研磨材。発注点方式で管理していることが多く、特定の案件に紐づけない方がシンプルに回る。原価には含めないか、固定配賦で処理する。

この2つを分けておくだけで、台帳の使い方が明確になる。直接材の行が個別原価の集計元で、間接材の行は集計対象外——この区分が設計の核になる。台帳に「直/間」の列を1つ加えるだけでいい。

粒度は割り切っていい

直接材でも、粒度を完全に合わせようとすると行き詰まる。

たとえば鋼材を定尺で購入して、必要な分を切り出す。余った端材は別の案件でも使えるかもしれない。この端材をどう按分するか——ここを厳密に追おうとすると手間が増える割に、精度はそれほど上がらない。

現実的な落とし所は、材料を購入した時点で受注番号に全額紐づけること。端材が出たら次の案件で使う。端材の在庫管理は別の話として扱う。

この割り切りで個別原価の精度は多少下がるが、ベテランの見積もり精度と大きくズレることは少ない。「思ったより利益が出た・出なかった」という肌感覚とデータが乖離したときだけ、原因を追えばいい。70〜80点の精度で十分という考え方は原価計算だけでなく、仕入管理の粒度にも当てはまる。

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

この台帳で何が見えるようになるか

受注番号・直間区分・仕入先の3軸を持つ台帳ができると、以下が出せるようになる。

• 案件別材料費：受注番号で集計するだけ。アワーレートと合わせると個別原価が出る
• 仕入先別支払：仕入先で集計して月次合算。買掛管理に連携できる
• 発注残：入荷フラグがついていない行が発注残。どの案件の何が届いていないかが見える

逆に、この台帳では追いきれないものもある。端材の実在庫、間接材の在庫水準——これらは仕入台帳ではなく在庫管理の問題になる。受注生産の在庫をフロー在庫とストック在庫に分けて考える視点は、別の記事で書いた。

→ 受注生産の在庫管理は「数える」より「分ける」が先 ── フロー在庫とストック在庫

Excelで十分回る

この仕組みはExcelで十分機能する。

仕入台帳を1ファイルにまとめ、受注番号・直間区分・仕入先・入荷フラグの列を持たせる。月次で案件別に集計すれば材料費が出る。仕入先別に合算すれば買掛が出る。これで個別原価と支払管理の2つに答えられる台帳が完成する。

問題になるのは、複数人が同時に編集するようになったときや、件数が増えてファイルが重くなってきたとき。その段階になったら、バックエンドにデータベースを置くか、入力フォームを別途作るかを考えればいい。ただ数十人規模の工場であれば、件数的にもユーザー数的にも、Excelで回る期間の方がずっと長い。

仕組みを変えるタイミング

大掛かりなシステムへの移行が効くのは、外的な要因で現状維持が難しくなったときになる。人員が減って属人的な運用が維持できなくなった。案件数が増えてExcelの限界を超えた。月次原価の仕組み自体を見直す必要が出た——こうした場面になって初めて、システム化のコストが見合うかを検討する。

「ちゃんとしたシステムを入れれば仕入管理が解決する」という発想で動き始めると、現場の運用を把握しないままパッケージを入れ、結果的にExcelに戻ってくることがある。受注番号による紐づけ、直接材と間接材の区分、粒度の割り切り——この3つの構造が機能していれば、器がExcelでもシステムでも仕入管理は回る。逆にこの構造を持たないままシステムを変えても、管理の質は変わらない。

仕入管理は仕組みの複雑さで精度が上がるわけではない。軸は受注番号、区分は直接材と間接材、記録単位は発注1件1行——これだけ決めれば、受注生産の中小製造業の仕入管理として十分機能する。

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

• 中小製造業の多品種少量生産における原価計算の「落とし所」
• データは単体では意味がない ── 在庫と原価を「つなげて見る」という内製DXの基本
• Excelのデータは「いつでもDBに移せる形」で持つ ── データの文法という考え方
• 受注生産の在庫管理は「数える」より「分ける」が先 ── フロー在庫とストック在庫

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