テックメモ

AIがあれば基幹システムは作れてしまう

別の記事で「ERPの主戦場は受発注・在庫・会計の統合であり、製造プロセスの部分は自社に合った小さなツールを内製で作るほうが合う」と書いた。Excelベースの業務ツール、VBAのマクロ、ちょっとしたデータベース——内製DXの「小さなツール」は、そのあたりの規模感を想定している。

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

しかしAIコーディングツールの普及で、内製で作れるものの範囲は広がりつつある。

受注管理、発注管理、在庫管理、原価計算、納期管理。ロジック自体はそこまで複雑ではない。複雑なのは業務の例外処理と運用の細かいルール——つまりドメイン知識の部分になる。そのドメイン知識を持っている人間がAIに指示を出せば、従来は数百万から数千万円かかっていた規模のシステムを、数ヶ月で内製できてしまう。

否定的な意見はまだ多いだろう。「AIが書いたコードで基幹業務を回すなんて危険だ」「品質が担保できない」。気持ちはわかる。しかし別の記事でも書いた通り、AIがインフラになる方向性は確定している。AIの実装力は上がり続ける。できるかどうかの議論は、遅かれ早かれ決着がつく。

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

問題は「作れるか」ではなく、 「作ったものを1人のSEに任せていいのか」 という別の次元にある。

最初はコスパが圧倒的に見える

1人の社内SE、あるいは外部のDXエンジニアが、AIを使って基幹システムを内製する。パッケージを買えば数百万、カスタマイズを入れれば数千万。それを人件費の一部で実現できるなら、経営者にとっては魅力的に見える。

実際、最初は機能する。業務をわかっている人間がAIを使って作るから、現場に合ったものができる。パッケージにありがちな「導入したけど使われない機能」がなく、必要なものだけが揃っている。業務をシステムに合わせる必要もないし、修正も即座にできる。

コスト、フィット感、柔軟性。どれを取っても、パッケージ導入より内製のほうが良く見える。少なくとも最初の数年は。

3年後に何が起きるか

問題は、そのSEがいなくなったときに起きる。

退職、異動、病気、家庭の事情。理由は何でもいい。基幹システムを作った人間が、ある日いなくなる。残されたのは、その人が作って、その人が保守していたシステム。他に触れる人がいない。

AIのおかげで1人のSEが作れる範囲が広がった分、その人に依存するリスクも広がっている。受注も発注も在庫も原価も、すべてが1人のSEが作ったシステムに乗っている。 会社全体の業務が、1人の人間に依存する構造 になる。

しかもAIで作ったシステムには、従来にはなかった厄介な性質がある。

AI時代の属人化はさらに深い

これまでの属人化は「その人の頭の中にある」だった。少なくとも本人は理解している。聞けば説明してくれる。引き継ぎの時間があれば、ある程度の知識移転はできる。

AIで作ったシステムの場合、 作った本人ですらコードの全体を完全には把握していない 可能性がある。AIに指示を出して、出てきたコードを検証して、動いたから採用する。部分ごとには理解しているが、全体がどう組み合わさっているかは、AIとの対話の中でしか存在していない。

別の記事で「全部読んで確認する方法はどこかで限界が来る」と書いた。基幹システムの規模になれば、まさにその限界に直面する。

→ AI時代の内製DXエンジニア ── 実装の先にある仕事が本業になる

このシステムを引き継ぐ人間は、元のSEが持っていたドメイン知識、AIとの対話で生まれた設計判断、動作検証のノウハウ——これらをすべて再構築しなければならない。引き継ぎのハードルは、人間が書いたシステムよりもはるかに高くなる。

任せていい——ただし「替えがきく」前提で

ここまでの話を整理すると、問いは2つに分かれる。

AIで基幹システムを作れるか。 → 作れる。ロジックは複雑ではなく、ドメイン知識があれば十分に可能。

それを1人のSEに任せていいか。 → 任せていい。ただし条件がある。

従来の基幹システムは、一度作ったら何年も使い続けるものだった。だからこそ、作った人間がいなくなることが致命的なリスクになった。

しかしAI時代は前提が変わる。 基幹システムそのものが「替えのきくもの」になる。 1人のSEがAIを使って数ヶ月で作れたなら、別のSEがAIを使って数ヶ月で作り直せる。システムを守り続ける必要はない。必要なら作り直せばいい。

ただし、作り直せるためには条件がある。 システムは替えがきいても、データは替えがきかない。

守るべきはシステムではなく、データと、そのデータがどういう意味を持っているかの記録になる。

データの持ち方を標準化する。 別の記事で「データの文法」について書いている。基幹システムであれ小さなツールであれ、データが標準的な形で保持されていれば、システムを作り直してもデータはそのまま引き継げる。

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

業務の構造を記録する。 何がどうつながっているか、どのテーブルにどんなデータがあるか。コードの詳細は後からAIに読ませれば再構築できるが、業務の構造と設計の意図は記録しないと消える。

入れ替えられる設計にしておく。 内製の基幹システムであっても、いつか別のものに置き換える日が来る前提で設計する。データが特定のシステムに閉じ込められない状態を維持する。

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

守るものが変わる

AIで基幹システムが作れる時代になると、守るべきものが変わる。

従来は システムを守る 発想だった。作ったものを壊さないように保守し、動かし続ける。だから作った人間がいなくなると困る。

AI時代は データと業務知識を守る 発想に変わる。システムはいつでも作り直せる。しかしデータが壊れたら、どんなに優秀なSEがいても復元できない。業務の構造が誰の頭にも残っていなければ、AIに指示を出すこともできない。

別の記事で「8割内製、2割外部」と書いた。基幹システムであっても、業務の構造を言語化して外部と共有しておくことで、知識が1人に閉じるリスクを減らせる。

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

1人のSEに任せること自体は問題ではない。 そのSEがいなくなったときに、別の人間がAIを使って作り直せる状態を維持しておくこと。 それがAI時代の基幹システムとの付き合い方になる。

AIがコードを書く時代のセキュリティ問題

別の記事で「AIが実装を肩代わりする時代に、内製DXエンジニアの仕事はどう変わるか」を書いた。

→ AI時代の内製DXエンジニア ── 実装の先にある仕事が本業になる

AIコーディングツールの普及で、コードを書くスピードは劇的に上がった。しかし、速く書けるようになった分だけ、新しい問題が出てきている。 AIが書いたコードのセキュリティを、誰がどうレビューするのか。

IT業界全体で見ると、これは深刻な問題になりつつある。コードを書くスピードが上がった分、レビューが追いつかなくなっている。Webサービスを開発している会社にとっては、セキュリティレビューの体制をどう整えるかが経営課題になりつつある。

セキュリティは「悪魔の証明」

なぜセキュリティレビューが追いつかないのか。根本的な理由は、セキュリティの検証がコーディングとは性質が違うことにある。

コーディングには達成すべき目的がある。「この入力に対してこの出力を返す」というゴールが明確で、テストで検証できる。別の記事で書いた「テストで検証する」アプローチは、機能面には有効に働く。

→ AI時代の内製DXエンジニア ── 実装の先にある仕事が本業になる

しかしセキュリティは 「穴がないこと」を証明する作業 になる。既知の脆弱性パターンはチェックできるが、まだ知られていない攻撃手法には対応できない。攻撃する側は1つの穴を見つければ勝ち。守る側はすべてを塞がないと負け。この非対称性は、AIを使ってもなかなか解消できない。

いずれAIがセキュリティの問題を解決する日は来ると思う。しかし「穴がありません」とAIが保証する形がどうなるかは、まだ見えていない。しばらくは人間の判断が必要な領域として残るだろう。

内製DXは「閉じている」から影響が小さい

ただし、この問題が中小製造業の内製DXにとって緊急かと言えば、 そこまでではない。

理由は単純で、内製DXのツールはほとんどが社内ネットワークに閉じているから。ユーザーは社員数十人。外部からのアクセスはない。攻撃者から見て、社内の業務ツールに直接到達するのは非常に難しい。

AIが書いたコードに問題があったとしても、そのコードが社内ネットワークの中でしか動いていなければ、外部から突かれることはない。内製DXの世界では、AIのコードをそのまま使うことのリスクは、外部公開サービスとは比較にならないほど小さい。

だから、内製DXにおけるAI活用は 使う方向で問題ない。 コーディングの難易度もそれほど高くなく、環境が閉じているから、AIとの相性は良い。別の記事でVBAとAIの組み合わせについて書いているが、内製DXの開発にAIを取り入れることへの障壁は低い。

→ 内製DXの開発にAIを使う ── VBAでも「AIに書かせる設計」はできる

外に出すなら話が変わる

問題になるのは、AIが書いたものを 外部に公開する 場面になる。

たとえば、自社のWebサイトに問い合わせフォームを設置する。社外向けの受発注ポータルを作る。取引先とのファイル共有の仕組みを構築する。こうした「外に開けた」システムをAIに書かせて、セキュリティレビューなしにそのまま公開するのは危ない。

「得意なプラットフォーム」を1つ持っておく

では、外に開けた環境でAIを使いたいならどうするか。答えは 自分がある程度理解しているプラットフォームを1つ決めて、そこで動かす ことになる。

VPSなら基本的なセキュリティの設定ができる、という人はVPSでやればいい。クラウド（AWSやGCP）のセキュリティグループの設定がわかるなら、そこでやればいい。FileMakerやkintoneのようなノーコード系のプラットフォームで外部公開の仕組みを作る手もある。セキュリティの基本的な部分はプラットフォーム側が担保してくれるので、自分でインフラを管理するよりハードルは低い。何のプラットフォームでもいいが、大事なのは 自分が仕組みを理解している「箱」の上で動かすこと になる。

別の記事で「自社固有の領域は自分で理解すべき」と書いた。これと同じ構造になる。AIがコードを書いてくれても、そのコードが動く環境の安全性は自分が担保する。コードの中身はAIに任せても、インフラの理解は手放さない。

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

逆に言えば、 AIが書いたコードをコピペして、よくわからないプラットフォームに載せて外に出す のが一番危ないパターンになる。コードもわからない、環境もわからない。何かあったときに、何が起きているかも判断できない。

閉じた環境から始めて、得意な場所に広げる

中小製造業の内製DXとしての現実的なステップは明確になる。

まずは社内に閉じた環境でAIを使って開発する。 ここはリスクが低いので、積極的に活用していい。コーディングの速度が上がり、これまで手が回らなかった改善にも着手できるようになる。

外部に公開する必要が出てきたら、得意なプラットフォームを1つ決める。 そのプラットフォームの基本的なセキュリティ——ファイアウォールの設定、アクセス制御、SSL証明書の管理——を自分で理解して設定できる状態にしておく。

わからなければ、その部分は業者に頼む。 セキュリティは汎用領域なので外注が自然。ただし、何を守りたいかは自分で把握しておく。

→ 中小製造業のDXとランサムウェア ── 便利にした分だけ攻撃面が増える

資金繰り予定表の「変動費」はどうやって埋めているか

受注生産の中小製造業なら、資金繰り予定表は作っているだろう。入金予定と出金予定を並べて、向こう数ヶ月の資金の過不足を見る。経営の基本になる。

入金側は比較的見通しが立てやすい。販売管理ソフトに受注を登録していれば、納期と顧客ごとの回収サイト（締日・支払日）から入金予定が組める。すでに出荷・請求済みの売掛金は会計ソフトにも入っている。

出金側のうち固定費——家賃、リース料、給与、社会保険料——も毎月ほぼ一定で、過去のデータから予測できる。すでに発注済みの材料費や外注費は、販売管理に買掛として入っているから出金予定は見える。

では、受注は決まっているが、まだ材料を手配していない案件の変動費 はどうやって予定表に載せているか。

ここが資金繰り予定表の最も作りにくい部分になる。受注残が多い会社ほど、この「受注済み・未発注」の層が厚い。

しかもこの変動費の根拠データは、経理からは入手しづらい構造になっている。材料費や外注費の内訳を持っているのは設計部門で、積算資料（見積もりの原価明細）の中にある。資金繰り予定表を作る経理と、変動費の根拠を持つ設計が別の部門にいるから、案件ごとの積算が予定表に反映されにくい。結果として、経理は経験則や過去の傾向で埋めることになるが、受注の内容によって変動費は大きく変わるから、精度に限界がある。

受注が増えれば運転資金も比例して増える。その見通しの精度を左右するのが、この未発注分の変動費をどれだけ正確に予定表に載せられるか、という部分になる。

設計の積算データを経理につなげる

ここで内製DXの出番がある。

受注生産では、すべての受注に見積もりがある。設計部門が作る積算資料の中に、材料費と外注費の内訳がすでに入っている。つまり受注残の全案件について、変動費の根拠データは社内に存在している。問題は、そのデータが資金繰り予定表に活用できる仕組みになっていないことにある。

以前の記事で「見積もりは使い捨てにするには惜しいデータ」と書いたが、資金繰りの文脈でも同じことが言える。

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

やることは、受注データに以下の情報を紐づけるだけになる。

• 入金側： 納期 → 請求 → 回収サイト → 入金予定日
• 出金側： 見積の材料費・外注費 → 仕入先の支払条件 → 出金予定日

これを受注案件ごとに並べれば、「この案件は出金が入金より2ヶ月先行する。その額は約○万円」という見通しが立つ。受注残の全案件を積み上げれば、資金繰り予定表の変動費の部分が、経理の経験則ではなく設計の積算データに基づいた数字で埋まる。

内製DXの仕事は、設計部門が持っている積算データを、経理が資金繰り予定表に使える形で引き出すこと。新しいデータを作る話ではなく、すでに社内にあるデータを部門をまたいでつなげる話になる。

来月の案件も3ヶ月先の案件も、見積もりを出している以上、予測の精度は同じになる。受注生産の強みは、受注残の範囲内であれば時間軸に関係なく同じ精度で出金を予測できることにある。見えないのは受注残の外——まだ受注していない仕事だけになる。

もちろん、資金繰りの実態は会社によってまったく違う。数ヶ月かけて大型設備を1台作る会社なら、1案件の出金インパクトが大きく、その1件の入金タイミングで資金繰りが左右される。数日で小物部品を数百個作る会社なら、1案件ごとの影響は小さいが、件数が多い分だけ全体の積み上げが要る。どちらにしても、見積データを資金繰り予定表につなげる原理は同じになる。

精度は見積の精度で決まる、でもそれで十分

予測の精度は見積もりの精度に依存する。見積ベースの材料費と実際の仕入額は一致しない。ただし、ここで必要なのは1円単位の正確さではなく、 「資金がショートしそうかどうか」の判断材料 になる。以前の記事で原価管理の精度について「70点で十分」と書いたが、資金繰りの予測も同じ。見積もりの読みが大きく外れていなければ、見通しとしては十分に使える。

→ 受注生産・多品種少量の中小製造業における原価管理の「落とし所」

もちろん、DXで改善できるのは予定表の精度まで。支払条件の交渉、大口案件の前受金、金融機関との資金調達——こうした資金繰りそのものの改善は経営判断の領域であり、データの問題ではない。

ただ、3ヶ月先に資金が足りなくなりそうだとわかっていれば、手の打ちようはいくらでもある。来週の支払いに足りないとわかったときには、選択肢はほとんどない。予定表の変動費が経験則ではなくデータで裏付けられていれば、経営者はより早く、より正確に手を打てる。

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

受注が増えて会社が成長するとき、運転資金の負担は必ず大きくなる。設計の積算データを資金繰り予定表につなげておくこと。経理の仕事を代替するのではなく、設計部門が持っている原価情報を、経理が使える形で届けること。部門をまたぐデータの橋渡し——それが資金繰りにおける内製DXの役割になる。

---

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

• 受注生産のデータは見積番号から始める ── 受注起点では見えないフィードバックループ
• 受注生産・多品種少量の中小製造業における原価管理の「落とし所」
• データは単体では意味がない ── 在庫と原価を「つなげて見る」という内製DXの基本
• 中小製造業の「値決めできない」問題に、内製DXはどこまで効くか

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

仕入先にも種類がある

中小製造業の「仕入先」と一口に言っても、中身はかなり違う。

製品の材料を買う鋼材商社。ボルトやナットを買う部品商社。自社の製品の一部を加工してもらう外注先。自社ではできない条件があるときに頼む同業の協力会社。ネットワークやサーバーを面倒見てくれるIT業者。

材料を買うだけの取引なら、発注・納品・請求というデータの「点」で関係が完結する。価格と納期と品質が合えばそれでいい。

しかし、加工外注や協力会社になると話が変わってくる。「この形状ならあそこに頼めばうまくやってくれる」「急ぎのときは無理を聞いてくれる」「図面に書いていないニュアンスを汲んでくれる」——こういう関係は、発注データには載らない。データとしての接点は「点」でも、実際の関係はもっと深いところで動いている。

別会社という壁

当たり前だが、仕入先は別会社になる。相手のシステムに入り込むことはできないし、相手の工程や負荷状況を直接見ることもできない。

やりとりの手段は、メール、電話、チャットに参加してもらう、あるいは社員が検査や打ち合わせで訪問する——この程度が現実的な接点になる。以前の記事で外注先をチャットに入れる運用を紹介したが、あれにしても日常のやりとりがスムーズになるだけで、相手の内部が見えるようになるわけではない。

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

お互い懐を見せられない、という事情もある。こちらの原価構造を相手に見せたくないのと同じように、相手も自社の情報は出したくない。中小同士の取引では、このあたりの距離感は特に繊細だと思う。

担当者の関係で成り立っている

結局のところ、中小製造業の仕入先との関係は、担当者同士の人間関係で成り立っている部分が大きい。

関係の始まり方も様々で、実務者レベルで完結しているケースもある。飛び込み営業がきっかけで付き合いが始まり、そのまま現場の担当者同士でやりとりが続いている。この場合、経営者はその仕入先と具体的にどういう関係にあるのか、詳しくは把握していないことも多い。

一方で、経営者同士が知り合いというパターンもある。もともと社員だった人が独立して作った会社、業界の集まりで知り合った同業者——こうした関係は、経営者の個人的なつながりに依存している。

どちらのパターンでも、関係の実態は特定の誰かの頭の中にある。自社にとってどれだけ重要な仕入先であっても、その関係の経緯や背景、相手の特徴や注意点は、担当者が抱えたまま共有されていないことが多い。

担当者が変わると関係が切れる

以前の記事で、IT業者との関係が担当者の異動で崩壊した例を書いた。仕入先との関係でも同じことが起きる。

→ 中小製造業の内製DXと外注の線引き

担当者が退職する、異動する、あるいは相手側の担当者が変わる。それだけで、長年かけて築いた関係がリセットされる。やりとりの経緯、暗黙の了解、「前にこういうことがあったから今はこうしている」という判断の背景——こうした情報が一人の頭の中にしかなければ、その人がいなくなった時点ですべて失われる。

大企業なら組織として関係を管理する仕組みがある。引き継ぎの手順があり、複数人で対応する体制がある。しかし中小製造業では、仕入先との関係が文字通り一人の担当者に紐づいていることが珍しくない。自社の製造能力に直接影響するような重要な協力会社との関係ですら、そうなっていることがある。

DXの限界を認める

正直に書くと、この問題にDXが直接効く場面は限られている。

仕入先との関係の本質は、信頼と暗黙知で成り立っている。「あそこは急ぎでも嫌な顔をしない」「この手の加工はあそこが一番うまい」「あの担当者にはこう言えば通る」——こうした情報はシステムに載せにくい。載せたところで、信頼関係そのものが移るわけではない。

以前の記事で内製DXの弱点を正直に書いた。今回も同じスタンスで、できないことはできないと認めた上で、それでもやれることを考えたい。

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

接点を一人にしない

これはDXの話ではなく組織の話になるが、最も効果があるのは 仕入先との接点を担当者一人に閉じないこと だと思う。

打ち合わせに複数人で参加する。訪問するときに別の社員も連れていく。チャットのチャンネルに担当者以外も入れておく。こうした小さな積み重ねで、関係が一本の線ではなく複数の線で結ばれた状態になる。

一人が抜けても、別の誰かが関係の文脈を持っている。完全な引き継ぎは難しくても、ゼロからの再スタートにはならない。

仕入先マスタにナレッジを足す

もう一つ、これはDXの領域になる。仕入先に関する情報を、担当者の頭の中から取り出して残すこと。

営業先の管理にはCRMという考え方がある。担当者名、商談の履歴、関係の経緯——顧客との関係を組織として蓄積する仕組み。同じことが、仕入先に対しても必要ではないかと思っている。売る側には仕組みがあるのに、買う側には何もない——これは中小製造業に限らず、多くの会社で見落とされている部分だろう。

ただし、ゼロから仕入先データベースを作る必要はない。仕入先とお金のやりとりをしている以上、会計ソフトなり業務システムなりに仕入先マスタはすでにある。会社名、支払い条件、振込先——取引に必要な情報は登録されている。箱はすでにあるので、そこにナレッジを足すほうが自然だと思う。

→ 受注生産の中小製造業における仕入管理は「今のやり方」から始めればいい

足すべき情報は、たとえばこういうものになる。

• 相手側の担当者名、連絡先
• 得意な加工、対応できる条件、設備の特徴
• 過去のトラブルや注意点
• 関係の経緯（どういう縁で付き合いが始まったか）
• 価格感の目安、納期の傾向

どれも担当者に聞けばすぐ出てくる情報だが、聞かなければどこにも残らない。以前の記事でナレッジ管理の話を書いたとき、対象は社内業務のノウハウだった。しかし同じ方法論——聞き取り役が翻訳して残す——は、仕入先の情報にも使える。

→ 中小製造業のナレッジ管理が進まない本当の理由

担当者が辞めたときに、次の人が「この会社とはこういう付き合いをしてきた」とわかる程度の情報があるだけで、ダメージは大きく変わる。7516で書いた「30点からスタートできる状態」と同じ考え方になる。

関係の見える化は、仕入先の棚卸しでもある

仕入先の情報を整理してみると、副次的に見えてくることがある。

特定の仕入先に依存しすぎていないか。代替先はあるか。関係が一人の担当者に集中していないか。以前の記事で「依存先は常に分散させる」と書いたが、仕入先との関係にも同じことが言える。

→ 中小製造業の内製DX ── 判断に迷ったときの基準を持っておく

仕入先の情報を残す作業は、単なる記録ではなく、自社の外部依存の構造を可視化する作業でもある。見えていなかったリスクが見えるようになるという意味では、これも一つの「見える化」だと思っている。

---

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

• 中小製造業の内製DXと外注の線引き
• 中小製造業のナレッジ管理が進まない本当の理由
• 中小製造業の社内連絡は、メールでも電話でもなくチャットがちょうどいい
• 受注生産の中小製造業における仕入管理は「今のやり方」から始めればいい

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

「人材不足」とは誰の話か

中小製造業で「人材不足」という言葉はよく聞く。しかし、この言葉はかなり雑に使われている気がしている。

事務職が足りないという話はほとんど聞かない。経理、総務、購買事務——こうしたポジションは、募集すればそれなりに応募が来る。

足りないのは現場作業者のほうだろう。製造ラインに入る人、溶接や機械加工のオペレーター、検査員——ものを作る現場で手を動かす人が来ない。これが中小製造業の「人材不足」の正体ではないかと思っている。

集まりにくい構造がある

理由を突き詰めると、きつい仕事のわりに給与が高くないという話に行き着く。

立ち仕事、重いものを扱う、暑い・寒い・油がつく——製造現場の仕事は身体的な負荷が高い。それに対して、同じ地域のサービス業や事務職と比べて給与が突出して高いかというと、そうでもないことが多い。特に数十人規模の中小製造業は、大手メーカーの賃金テーブルとは差がある。

同じ給与なら、身体への負担が少ない仕事のほうに人が流れるのは自然なことだと思う。「人材不足」と言い続けることで、賃金や労働条件の問題に向き合う機会を逃している面もある気がしている。

DXだけでは解決しない

この問題に対して「DXで解決しましょう」と言うのは無責任だろう。

現場作業者が足りない本質は、賃金と労働条件の問題にある。業務効率化で多少の負荷を減らせたとしても、それだけで応募が急に増えるわけではない。以前の記事で「受注が足りないときは内製DXでは解決しない」と書いたが、人材不足にも似た構造がある。打てる手の限界を認識した上で、それでもDXにできることを考えたほうが誠実だと思う。

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

「その他が同じ条件なら」で差がつく

ただ、一つ気づいていることがある。

同じ業種、同じ地域、同じくらいの給与水準でも、人が集まっている会社とそうでない会社がある。その差がどこにあるかというと、社内環境の印象ではないかと感じている。

求職者の立場で考えてみる。どちらも同じような製造業の求人で、給与も大差ない。片方はホームページに工場の写真が載っていて、社内の雰囲気が見える。もう片方はホームページすらない。どちらに応募したくなるかと言えば、やはり前者だろう。

これは見た目の話だけではない。入社後の環境にも差が出てくる。情報が整備されていて、教育体制がある会社と、「とりあえず見て覚えて」の会社。社内の連絡がチャットで整理されている会社と、口頭と紙のメモだけの会社。現場にタブレットや端末があって図面や手順書がすぐ見られる会社と、事務所まで取りに行かないと確認できない会社。

きつい仕事であること自体は変わらない。しかし、 その他の条件で「ここはちゃんとしている」と感じてもらえるかどうか が、応募の分岐点になっている気がする。

具体的に何が効くか

社内環境の整備が、結果として採用力につながる場面がある。いくつか挙げてみる。

ホームページで社内環境をオープンにする。 受注を取るためのHPではなく、採用のためのHPという発想になる。工場の写真、設備の紹介、社員の働いている様子——検索で求人にたどり着いた人が「ここで働くイメージ」を持てるかどうかは意外と大きい。以前の記事でHPだけで受注は来ないと書いたが、採用における役割はまた別の話になる。

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

社内の情報に携帯からアクセスできる。 勤怠、給与明細、社内連絡——こうした情報に自分のスマホからアクセスできる環境は、今の求職者にとっては当たり前に近くなっている。逆にこれがないと、それだけで「古い会社」という印象を持たれやすい。

現場に端末がある。 図面を確認する、作業手順を見る、不良の記録を入力する——紙ではなくデジタルで完結する現場は、見た目にも整った印象を与える。以前の記事でタブレットを入れて最終的に固定PCに落ち着いた経験を書いたが、タブレットでも固定PCでも、現場で必要な情報にすぐアクセスできる状態を作ることが大事になる。

→ 中小製造業のデータ入力は、タブレットでは定着しない

入社時に情報が整備されている。 業務マニュアル、作業手順書、安全規定——入社初日に「これを読んでおいて」と渡せるものがあるかどうか。ナレッジが整備されている会社は、教育の負担が減るだけでなく、「受け入れ体制がちゃんとある」という安心感にもつながる。

→ 中小製造業のナレッジ管理が進まない本当の理由

どれも特別な投資が必要な話ではない。社内のDXを進めていく中で、副産物として手に入るものが多い。

賃金の話を避けずに

社内環境を整えても、賃金が相場より明らかに低ければ人は来にくい。それは事実として受け止める必要があると思う。

ただ、原価管理ができていて利益が見えている会社は、賃上げの判断もしやすくなる。どの仕事でいくら利益が出ているかがわかれば、「ここまでなら賃金に回せる」という根拠が持てる。データがないまま「上げるべきか、上げたら赤字にならないか」と悩み続けるよりは、前向きな判断がしやすい。

→ 受注生産・多品種少量の中小製造業における原価管理の「落とし所」

DXが人材不足を直接解決するわけではない。しかし、社内環境の整備を通じて「選ばれる会社」に近づくことはできるし、原価管理を通じて賃上げの判断に根拠を持つこともできる。回り道に見えるかもしれないが、構造的な問題に対して打てる手としては、これが現実的な範囲ではないかと思っている。

---

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

• 中小製造業の「値決めできない」問題に、内製DXはどこまで効くか
• 中小製造業のデータ入力は、タブレットでは定着しない
• 中小製造業のナレッジ管理が進まない本当の理由
• 中小製造業がクラウドソーシングを使わないのは、もったいない

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

派遣はいいけど、クラウドソーシングは無理？

中小製造業で人手が足りないとき、まず検討されるのは派遣だろう。製造の現場に人を入れる、事務を手伝ってもらう——派遣は「人が来る」という形が見えやすいから、経営者にとっても現場にとっても馴染みがある。

一方で、クラウドソーシングとなると急にハードルが上がる。「うちみたいな製造業には関係ない」「情報漏洩が心配」「どう頼んでいいか分からない」。理由は様々だが、検討すらせずに選択肢から外している会社が多い。

しかし、派遣とクラウドソーシングは競合する手段ではなく、使い分けるものだと思っている。そして、使い分けられる会社のほうが強い。

派遣とクラウドソーシングは構造が違う

派遣は「人が来る」。クラウドソーシングは「仕事を出す」。この違いは大きい。

派遣の構造：

• 物理的に来てもらう（常駐が基本）
• 時間で契約する
• 地元の労働市場から探す
• ある程度の期間、継続的に来てもらう前提

クラウドソーシングの構造：

• リモートで完結する
• 成果物や業務単位で契約する
• 国内全域（場合によっては海外）から探せる
• 必要なときだけ、必要な分だけ頼める

派遣が向いているのは、現場に物理的にいる必要がある仕事。製造ラインの作業、来客対応、現場での検査——これは人が来ないと始まらない。

一方で、データ入力の設計、業務フローの整理、ちょっとしたツールの開発、デザイン、営業資料の作成——こうした仕事は、必ずしも現場にいなくてもできる。ここにクラウドソーシングが使える。

「国内全域から探せる」の意味

派遣で専門性の高い人材を見つけるのは苦労する。地元の派遣会社に登録している人の中から、自社の業務に合うスキルを持った人を探すことになる。数十人規模の中小製造業が、地元で都合よくITに強い人材やCADに詳しい人材を見つけられるかというと、かなり難しい。

クラウドソーシングなら、国内全域が対象になる。優秀な人材は多い。家庭の事情で通勤が難しい人、地方に住んでいて近くに仕事がない人、フリーランスとして専門スキルで勝負している人——こうした人たちが登録している。地元の派遣では絶対に出会えない人材に、スポットでアクセスできる。

普通なら雇おうとも思わないような専門性を持った人に、必要な分だけ仕事を頼める。これは中小製造業にとって、構造的な優位性だと思っている。

案件を見ていて思うこと

クラウドソーシングの案件を定期的にチェックしているが、成長意欲のある中小企業は貪欲にクラウドソーシングを活用している。業務改善のツール開発、データ分析、マニュアル整備、Webサイトの改修——自社で手が回らない仕事を外に出して、会社を前に進めようとしている。

「うちは製造業のBtoBだから」「うちみたいな規模では」と思っている会社もあるが、関係ない。クラウドソーシングは業種や規模を選ばない。使うかどうかは、会社の姿勢の問題だと感じる。

一方で、構造的な問題もある。買い叩きは実際に存在する。どう考えても安すぎる金額で発注している案件を見かけることがある。安く出せば応募は来るかもしれないが、まともな人材は相場を知っている。適正な価格を出さなければ、まともな成果は返ってこない。これは派遣でも外注でも同じことだが、クラウドソーシングでは特に顕著に出る。

情報漏洩のリスクにどう向き合うか

クラウドソーシングに踏み出せない理由として一番多いのが、情報漏洩のリスクだと思う。社外の人間に業務を任せる以上、このリスクをゼロにはできない。ただ、ゼロにできないのは派遣でも外注でも同じことで、問題はリスクの大きさではなく 制度設計 にある。

大事なのは、 外部の人間がアクセスできる情報を限定する制度設計 を作ること。

社内LANには入れない。グループウェアも、社内の情報がやり取りされている環境にそのまま入れるのはリスクがある。外部の人材とのやり取りは、専用のチャットチャンネルやクラウドストレージなど、業務に必要な範囲に絞った経路で行う。

これは相手を信用していないから、ではない。 お互いのため になる。万が一、社内で情報漏洩が起きたとき、社内の情報に広くアクセスできる外部の人間がいれば、当然その人が疑われる。アクセスできる範囲を最初から限定しておくことは、発注側を守るだけでなく、受注側の人間を守ることでもある。

以前の記事でも書いたが、外注先をチャットに入れる運用は実際にうまくいっている。クラウドソーシングでも同じ構造が使える。専用のチャンネルで仕事のやり取りをして、込み入った話はWeb会議に切り替える。必要十分な情報共有はこれで成立する。

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

インフラがないと始まらない

ここまで読んで気づくかもしれないが、クラウドソーシングを活用するには前提がある。 チャットとWeb会議の環境が社内に整っていること だ。

メールだけでクラウドソーシングの相手とやり取りするのは現実的ではない。返信に時間がかかる、ニュアンスが伝わらない、ファイルの受け渡しが煩雑——これではスポットの外部人材をうまく使えない。

逆に言えば、社内のコミュニケーション基盤を整えた会社は、副産物として外部人材の活用基盤も手に入れている。チャットにアカウントを追加すれば、社内メンバーと同じように仕事のやり取りができる。Web会議があれば、画面共有しながら図面や資料の確認ができる。

→ 中小製造業の拠点間コミュニケーションは、OSSとUSBイヤホンで十分だった

DXの入り口としてチャットやWeb会議を整備する話は以前の記事で書いた。あの投資が、外部人材の活用という形でさらにリターンを生む。

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

リモート環境は採用にも効く

クラウドソーシングのためにリモート環境を整えると、実は採用面でも変化が出る。

求人を出すとき、「一部リモート可」と一言入れるだけで、求職者の反応は違う。中小製造業の求人は勤務地が限られることがネックになりがちだが、事務系やIT系の業務でリモートの選択肢があるだけで、応募の間口は広がる。

クラウドソーシングのために整えたチャットやWeb会議の環境は、そのままリモート勤務の基盤になる。社内にリモートで仕事を進める経験が蓄積されていれば、採用した人材にも同じ仕組みを適用できる。

人材確保が難しい中小製造業にとって、リモート環境は「外部人材の活用」と「採用力の強化」の両方に効く投資になる。

優秀な人材に慣れること

一つだけ付け加えると、クラウドソーシングで見つかる優秀な人材は、社内のメンバーとは仕事の仕方が違うことがある。自分で判断して動く、曖昧な指示には確認を返してくる、成果物のクオリティが想定以上——そういう人材に慣れていないと、最初は扱いに戸惑うかもしれない。

しかし、会社を成長させたいと思うなら、そういう人材の力を借りることに意味がある。優秀な人材と仕事をする経験は、社内の仕事の進め方にも良い影響を与える。外部の力を借りることは、単にリソース不足を補うだけでなく、会社自体の仕事の水準を引き上げるきっかけにもなる。

---

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

• 中小製造業の「値決めできない」問題に、内製DXはどこまで効くか
• 中小製造業の社内連絡は、メールでも電話でもなくチャットがちょうどいい
• 中小製造業の拠点間コミュニケーションは、OSSとUSBイヤホンで十分だった
• 中小製造業の内製DXと外注の線引き

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

個別原価が出せないから判断できない、は本当か

受注生産の中小製造業で「どの仕事が儲かっているか分からない」という声はよく聞く。理想を言えば、案件ごとに材料費・外注費・工数・間接費を積み上げて個別原価を出したい。しかし現実には、多品種少量の現場で厳密な個別原価計算を回すのは手間がかかりすぎる。

→ 受注生産・多品種少量の中小製造業における原価管理の「落とし所」

以前の記事ではアワーレート方式で70点の精度を取るアプローチを書いた。これは全案件に同じ物差しを当てるための仕組みで、中小製造業にとっては現実的な落とし所だと思っている。

ただ、もっとシンプルに判断できる場面がある。 受注があふれていて、仕事を選べる状態 のときだ。

固定費はどのみち出ていく

受注が十分にある会社では、家賃・人件費・リース料といった固定費は、受注の有無にかかわらず発生している。どの案件を受けようが受けまいが、月末に出ていく金額は変わらない。

であれば、個別の受注を受けるかどうかの判断に固定費を持ち込む必要がない。固定費は受注全体でカバーするものであって、一つひとつの案件に按分して「この案件は赤字だ」と判定するのは、計算としては正しくても、判断の道具としては使いにくい。

変動費だけで判断する

ざっくり言えば、材料費や外注費は 「この受注を受けなければ発生しない費用」 になる。受けたから仕入れる、受けたから外注に出す——受注に紐づいて新たに出ていくお金。会計上の変動費の定義とは厳密には異なるが、この記事では便宜上これを変動費と呼ぶ。

発想を切り替える。受注を選べる状態なら、見るべき数字は 売値から変動費を引いた残り だけでいい。

• 売値100万、材料費30万、外注費20万 → 残り50万
• 売値80万、材料費15万、外注費10万 → 残り55万
• 売値120万、材料費70万、外注費30万 → 残り20万

この「残り」が大きい順に受注を取っていけば、固定費の回収に最も貢献する仕事を優先できる。3番目の案件は売値こそ一番高いが、手元に残る金額は一番少ない。売値だけを見ていると判断を誤る。

管理会計では限界利益とか貢献利益と呼ばれる考え方だが、名前はどうでもいい。 「材料と外注を引いて、いくら残るか」 だけ分かれば判断できる。

必要なデータは二つだけ

この判断に必要なのは、案件ごとの材料費と外注費だけ。どちらも仕入データや発注データから取れる数字で、新たに記録の仕組みを作る必要がないことが多い。

アワーレート方式では作業時間の記録が必要になる。15分単位の記録でも、現場に定着させるまでにはそれなりの時間がかかる。一方、材料費と外注費は請求書や発注書に金額が書いてあるので、集めるハードルが低い。

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

まずは変動費ベースの判断から始めて、余裕ができたらアワーレートに進む——という順番も現実的な選択肢になる。

工数の差が大きい場合はアワーレートを併用する

ただし、この方法が万能なわけではない。

同じ「残り50万」でも、製造に3日かかる案件と2週間かかる案件では話が違う。2週間かかる案件を受けている間に、3日の案件を3本こなせるかもしれない。変動費だけでは工数の差が見えない。

受注があふれている状態なら、キャパシティのどこに何を入れるかが重要になる。この判断にはアワーレートが効く。 「残り ÷ 作業時間」 を出せば、時間あたりの貢献度で案件を比較できる。

→ 受注生産・多品種少量の中小製造業における原価管理の「落とし所」

逆に言えば、案件ごとの工数にそれほど差がない業態なら、変動費だけの判断で十分に回る。

この判断が使える前提条件

繰り返しになるが、この方法が使えるのは 受注があふれていて選べる ときだけ。

受注が足りない状態でこの考え方を持ち込むと危険になる。「材料費と外注費さえ超えれば受ける」という基準で安い仕事を取り続ければ、固定費が回収できないまま走り続けることになる。受注が足りないときの課題は、原価管理ではなく営業の問題になる。

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

判断をシンプルにすることが内製DXの仕事

この記事で書いたことは、会計の知識がなくても実行できる。

見積データに材料費と外注費の項目があれば、Excelで「売値 − 材料費 − 外注費」の列を追加するだけでいい。案件の一覧を「残り」の降順でソートすれば、どの仕事を優先すべきかが一目で分かる。

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

経営者が日常的に使える判断の道具は、複雑なものより単純なものの方が強い。「材料と外注を引いて、いくら残るか」。この一つの数字が見えるだけで、受注の優先順位が変わる。完璧な原価計算ができなくても、この数字だけは押さえておくべきだと思っている。

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

---

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

• 受注生産・多品種少量の中小製造業における原価管理の「落とし所」
• 中小製造業の「値決めできない」問題に、内製DXはどこまで効くか
• 中小製造業の生産計画は、見積もりデータの再利用から始められる

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

価格を自分で決められない構造

受注生産の中小製造業には、価格を自社で決められないという構造的な問題がある。

顧客の言い値で受ける。相見積で他社と競り合い、一番安いところが取る。自社の原価に利益を載せた「正しい価格」で出したくても、市場がそれを許さない。値決めの主導権が自社にないまま、案件を回し続けている会社は少なくない。

この問題に対して「原価管理を入れれば解決する」と言い切るのは無責任だと思っている。構造の問題は仕組みだけでは変わらない。ただ、状況によっては内製DXが効く場面がある。受注が足りているかどうかで、打てる手がまったく変わる。

受注が足りているなら、原価管理が武器になる

受注がある程度ある会社にとって、原価が見えていないことの最大のリスクは 赤字の仕事に気づかないまま続けている ことにある。

→ 受注生産・多品種少量の中小製造業における原価管理の「落とし所」

受注ごとの利益がざっくりでも見えるようになると、いくつかの判断が変わる。

「蹴る」という選択肢が持てる。 赤字が確定している案件を見送ることで、その分のキャパシティを利益の出る仕事に充てられる。受注件数は変わらなくても、利益率が変わる。

「交渉する」という選択肢が持てる。 原価が見えていれば、「この価格だとこの仕様では対応が難しいが、ここを変えれば可能」という提案ができる。言い値で受けるか蹴るかの二択から、根拠のある交渉に変わる。データがない状態では、経験と勘で判断するしかない。データがあれば、少なくとも損する仕事を避ける判断の精度が上がる。

見積の精度が上がる。 過去の実績データと見積データを突合できるようになると、見積の「読み」が検証できる。赤字案件が多い顧客や製品に傾向があるなら、次の見積で価格を調整できる。

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

どれも劇的な変化ではない。しかし年間を通じて赤字受注を数件避けるだけで、利益への影響は数百万円単位になりうる。70点の精度でも、ゼロとは比較にならない。

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

受注が足りないとき、内製DXでは解決しない

一方で、受注が足りない会社に「原価管理を入れましょう」と言っても意味がない。蹴る余裕がないのに「この仕事は赤字です」と可視化しても、受けるしかないからだ。固定費を賄うために仕事を取り続けなければならない——この状況は、管理の精度を上げても変わらない。

受注が足りない会社の課題は、つまるところ 営業の問題 になる。

HPを作っても受注は来ない

営業の話になると「まずホームページを作りましょう」「SEOで集客しましょう」という提案が出てくることがある。しかし、受注生産の中小製造業で、HPからまとまった受注が来るケースはかなり稀。

なぜなら、製造業のBtoB取引はほとんどが 既存の関係性 で回っているから。既存顧客からのリピート、取引先からの紹介、業界のネットワーク——受注の大半はこうしたルートから来る。購買担当者がGoogleで「板金加工 小ロット」と検索して発注先を探すケースはゼロではないが、主流ではない。

HPが全く不要とは言わないが、HP単体で受注を増やそうとするのは、投資対効果としてはかなり厳しい。

外部の営業人材という選択肢

受注を増やすなら営業が必要。しかし中小製造業がフルタイムの営業社員を雇う余裕がないこともある。固定費が増えるし、製造業の営業ができる人材がすぐに見つかるとも限らない。

ここで検討したいのが、クラウドソーシングやフリーランスのプラットフォームで営業人材を外部から調達する という方法になる。

成果報酬型や業務委託で契約すれば、固定費を増やさずに営業リソースを確保できる。製造業の営業経験がある人がフリーランスとして活動しているケースは増えている。展示会だけでなく、オンラインで新規開拓を行うスタイルの営業もある。

ただし、外部の営業人材が機能するには前提条件がある。 製造現場とのコミュニケーションが回ること になる。

営業が機能するためのインフラ

外部の営業がリモートで動く場合、顧客から問い合わせを受けたとき、すぐに工場に確認を取れる必要がある。

「この仕様で対応できますか？」「納期はどのくらい見ればいいですか？」「材質を変えたらコストはどう変わりますか？」——営業の現場では、こうした確認が日常的に発生する。従来は営業が社内にいて、振り向いて設計や製造に聞けば済んだ。外部の営業にはこれができない。

メールでやりとりすると返答に時間がかかる。電話は相手の都合を無視する。ここで効いてくるのが、社内向けに構築したチャットとWeb会議のインフラになる。

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

外部の営業にチャットのアカウントを発行し、専用のチャンネルを作る。営業が「この仕様で対応できますか？」とチャットに投げれば、製造か設計が確認して返す。込み入った話ならワンクリックでWeb会議に切り替えて、図面を画面共有しながら話す。

→ 中小製造業の拠点間コミュニケーションは、OSSとUSBイヤホンで十分だった

以前の記事で外注先をチャットに入れる話を書いたが、構造はまったく同じ。外注先の代わりに、外部の営業人材が社内の情報にアクセスできる環境を用意するだけになる。

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

見積のスピードは営業力そのもの

もう一つ、内製DXが間接的に営業力を支える部分がある。 見積の回答スピードと精度 になる。

相見積の場面では、早く正確に返せること自体が競争力になる。他社が1週間かかる見積を翌日に返せるなら、それだけで顧客の印象は変わる。見積データを再利用できる仕組みがあれば、類似案件の見積は過去のデータをベースに短時間で出せる。

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

また、負荷状況が見えていれば「今なら短納期で対応できます」という提案もできる。これは余力があるときにしか使えないカードだが、営業にとっては強い武器になる。

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

内製DXの本当の価値は「判断の精度」

この記事で書いたことを整理すると、内製DXが経営に効くポイントは次の二つになる。

受注が足りているなら： 原価が見えることで、受ける・蹴る・交渉するの判断精度が上がる。赤字受注を避け、利益率の高い仕事にキャパシティを集中できる。

受注が足りないなら： 社内のコミュニケーション基盤が、外部営業人材の活用基盤に転用できる。見積のスピードと精度が、間接的に営業力を底上げする。

どちらにも共通するのは、内製DXの成果が 「ツールを作った」ではなく「判断の精度が上がった」 という形で経営に返ってくるということ。チャットを入れた、原価管理の仕組みを作った——それ自体は手段にすぎない。その手段を使って、経営者がより正確な判断をできるようになること。それが内製DXの本当の価値だと考えている。

---

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

• 受注生産・多品種少量の中小製造業における原価管理の「落とし所」
• 受注生産のデータは見積番号から始める ── 受注起点では見えないフィードバックループ
• 中小製造業の社内連絡は、メールでも電話でもなくチャットがちょうどいい
• 中小製造業の拠点間コミュニケーションは、OSSとUSBイヤホンで十分だった

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

「ちょっといいですか」が別拠点にも届く環境

以前の記事で、チャットツールは電話とメールの間を埋める「ちょうどいい」手段だと書いた。

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

今回はその続きの話。チャットを入れたあと、実際にどういう環境を作ったかという事例になる。

結論から言うと、OSSのチャット＋Web会議＋リモートデスクトップを1台のVPSに載せて、ハードウェアは1人あたり5,000円以下のセットで揃えた。これで拠点間のコミュニケーションのハードルが大きく下がった。

用意したもの

ソフトウェア（すべてOSS・無料）：

• Mattermost： チャットツール。Slackと同等の機能で、データは自社管理
• Jitsi Meet： Web会議ツール。Mattermost上のボタンからワンクリックで会議が始まる
• RustDesk： リモートデスクトップ。別拠点のPCを遠隔操作できる。TeamViewerの代替

ハードウェア（1人あたり）：

• USBオーディオアダプタ（スティック型、約1,000円）
• 有線イヤホンマイク（EarPods等、手持ちがあればそれでいい）
• Webカメラ（数千円のもので十分）

合計で1人あたり5,000円かからない。

インフラ：

• VPS 1台（8コア/24GBメモリ、月額数千円）
• Docker上にMattermost・Jitsi・RustDeskをすべて同居

なぜ商用サービスにしなかったか

Google WorkspaceやMicrosoft 365を入れれば、チャットもWeb会議もまとめて使える。Zoomを契約すればWeb会議は簡単に始められる。それは知った上で、OSSを選んだ。

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

一番大きな理由は、気軽に試せることにある。

商用サービスを導入するとなると、少額であっても稟議が要る。展開するなら説明責任が発生する。活用されるかどうかわからない段階で会社にお金を出してもらうと、「使われなかったらどうするのか」という話になる。判断の手綱が自分の手元から離れてしまう。

OSSなら、まず数人で試してみて、使われなければ静かにやめればいい。逆に手応えがあれば広げればいい。この「試して、だめなら引く」という判断を自分の裁量でできることが、結果的に導入のスピードを上げている。

データが手元に残る。 Mattermostのチャット履歴は自社のサーバーに保存される。サービス側の事情に左右されず、過去のやりとりを確実に手元に残せる。

入れ替えができる。 OSSの組み合わせなので、どれか一つが合わなければ他のツールに差し替えられる。JitsiをやめてBigBlueButtonにする、MattermostをRocket.Chatに変える——こうした選択肢が残る。商用サービスに全部載せた場合、この柔軟性はなくなる。

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

「ワンクリックで会議」が変えたこと

技術的な構成よりも、実際に使ってみて一番効いたのは チャットからワンクリックでWeb会議に入れる という体験だった。

一般的なWeb会議ツールでは、会議リンクを発行して共有し、参加者が入室するという流れになる。定例会議ならこれで十分だが、「ちょっと聞きたい」の場面では、チャットとの連携があるほうが手軽になる。

MattermostとJitsiを連携させると、チャット上のボタンを押すだけで会議が始まる。相手はチャットに表示されたリンクをクリックするだけで入れる。アカウント登録もアプリのインストールも要らない。

これによって、チャットで「この件、今ちょっと話せますか？」と送って、相手が「いいですよ」と返したら、そのままボタンひとつで画面共有しながら話せる。別拠点にいても、隣の席に声をかけるのに近い感覚で会話が始まる。

以前の記事で「チャットは電話への入口にもなる」と書いたが、このワンクリックの仕組みがあるかないかで、その入口の広さがまったく違ってくる。

ハードウェアは安くていい

Web会議というと、会議室にカメラとマイクスピーカーを設置して——というイメージを持つ人もいる。しかし拠点間の日常的なコミュニケーションに必要なのは、会議室の設備ではなく、各自のデスクにある手軽なセットのほう。

USBスティック型のオーディオアダプタに有線イヤホンマイクを挿せば、マイクとイヤホンの両方が使える。これが1,000円程度。Webカメラは数千円のもので画質は十分。ヘッドセットのような大げさなものは要らない。

大事なのは 全員が同じセットを持っている こと。特定の人だけが会議に参加できる環境では「ちょっと聞きたい」が機能しない。全員のデスクにイヤホンとカメラがある状態を作ることで、チャットからWeb会議への切り替えが日常になる。

リモートデスクトップがあると「見せて」ができる

RustDeskを入れた理由は、別拠点のPCを直接操作できるようにするため。

社内SEの業務では「画面を見ないとわからない」場面がよくある。Excelの設定がおかしい、プリンタが動かない、システムにエラーが出た——こうした問い合わせに電話やチャットのテキストだけで対応するのは限界がある。「どこのボタンを押しましたか？」「画面に何と出ていますか？」のやりとりを10往復するより、画面を直接見たほうが1分で解決する。

RustDeskはTeamViewerと同じように、相手のPCにアクセスして遠隔操作ができる。違いは、中継サーバーを自社で運用するのでデータが外部を経由しないことと、ライセンス料がかからないこと。

構築の難易度

正直に言えば、GWSやZoomをアカウント契約するのに比べれば、構築の手間はかかる。VPSの契約、Dockerのインストール、各サービスの設定、SSL証明書の取得、ドメインの設定——これらを自分でやる必要がある。

ただ、今はAIに設定手順を聞けばほぼそのまま動くレベルで回答が返ってくる。docker-composeのファイルもnginxの設定も、聞けば出てくる。以前なら公式ドキュメントを読み込んで試行錯誤していた作業が、かなり楽になっている。

→ 内製DXの開発にAIを使う ── VBAでも「AIに書かせる設計」はできる

気をつけるべきはセキュリティ。ファイアウォールの設定とポートの開放は、何を開けて何を閉じるかを理解した上でやる必要がある。ここだけは「AIが言ったからそのまま」ではなく、自分で判断すべきところになる。

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

コストの比較

ソフトウェアの費用がゼロなので、商用サービスで揃えた場合と比べると年間コストは桁が一つ違う。かかるのはVPS代だけ。

ただし、この差額は「自分で構築・運用する手間」との引き換えになる。社内に構築できる人がいなければ、商用サービスのほうが正解になることもある。

一つ知っておくべきこととして、Mattermostにはスマートフォン用のアプリがあるが、OSS版ではプッシュ通知に本番品質のサービスが提供されていない。通知が届くこともあるが、保証はない。基本はPCのブラウザやデスクトップアプリで使い、スマホのプッシュ通知には期待しないという前提で運用するのが現実的になる。

仕組みより「使われる状態」を作ること

この構成を入れて思ったのは、ツールを用意しただけでは使われないということ。

最初から全員が使ったわけではない。定着したのは、「チャットで聞いたらすぐ返事が来た」「画面共有したら一発で伝わった」という小さな成功体験が積み重なってからだった。

ツールの選定や構築は最初の一歩にすぎない。使われる状態になるまで付き合う覚悟がないと、仕組みだけ作って誰も使わないという結果になりかねない。

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

---

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

• 中小製造業の社内連絡は、メールでも電話でもなくチャットがちょうどいい
• 中小製造業のIT環境は「入れ替えられる設計」で組む ── OSSとSaaSの使い分け
• 中小製造業に Google Workspace は必要か
• 中小製造業のセキュリティは「守り方」より「戻し方」

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

属人化は避けられない、だから設計で対処する

VBAで作ったツールは属人化する。これはもう、ほぼ確実にそうなる。

以前の記事で「脱属人化ではなく属人化のトリアージ」と書いた。致命的リスクになる領域だけ仕分けて対処し、それ以外は属人化を許容する。この考え方は変わっていない。

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

ただ、VBAに関して言えば、もう少し具体的な話ができる。属人化を「なくす」のではなく、属人化しても 「引き継ぎやすい状態」 にしておく設計の話になる。

コントロールできるのは自分のVBAだけ

まず前提として、VBAの属人化には2種類ある。

他人が作ったVBA、他人から受け取ったVBA。 これはコントロールできない。中を読んでも意図がわからないコードが入っていたり、特定のシート構成を前提にしていたりする。壊れたら作り直すか、諦めるしかない。

自分が作るVBA。 こちらだけが設計でコントロールできる。

「VBAの属人化対策」と聞くと、コメントを丁寧に書くとか、コーディング規約を作るとか、そういう話を想像するかもしれない。もちろんそれも無意味ではないが、中小製造業の現場で効くのはもっと構造的な方法になる。

核心は「シートに状態を持たせない」こと

属人化しても引き継げるVBAツールの設計は、一言で言えば 「シートに状態を持たせない」 ことに尽きる。

以前の記事で、Excelのシートをデータシート・UIシート・出力シートに役割分離すると書いた。今回の話はその延長にあるが、もう一歩踏み込む。

→ 中小製造業のデータ加工業務は、Excelでも回せる

「シートに状態を持たせない」とは、ユーザーがシートに情報を蓄積していく使い方をさせないということ。書式設定も、罫線も、セルの配置も、全部VBAが生成する。ユーザーはボタンを押すだけ。VBAが毎回ゼロからシートを組み立てる。

こう設計しておくと、引き継ぎが劇的に楽になる。なぜなら、 VBAのコードさえあれば、同じものが再現できる から。シートの状態に依存していないので、「このセルにこの値が入っている前提で動く」という暗黙の前提がない。

極端な例：ボタン1つ、保存すら不要

最もシンプルなパターンを先に見せる。

表紙シートが1つだけあって、ボタンが1つ。押すと、外部のデータソース（CSVや別のExcelファイル、あるいはデータベース）からデータを取得して、帳票なりレポートなりを生成する。

この構成だと、ブック自体に保存する必要がない。データは外部にあるし、出力は毎回VBAが作り直す。ブックは「実行環境」であって「データの置き場」ではない。

極端な話、ブックが壊れても、VBAのコードさえ別に控えがあれば、新しいブックにコードを入れてボタンを配置するだけで復旧できる。

現実的なパターン：表紙・雛形・data の3シート構成

とはいえ、毎回外部からデータを取ってくる仕組みを作るのは、小規模な業務にはやりすぎになることが多い。データベースやCSV連携の仕組みまで作ると、VBA単体で済む話ではなくなる。

現実的によく使うのは、3つのシートで構成するパターンになる。

表紙シート。 ユーザーが操作する唯一のシート。ボタンがあり、必要なら入力欄もここに置く。

帳票雛形シート。 印刷用のテンプレート。レイアウトや書式はここで定義しておき、VBAがデータを流し込む。ユーザーは直接触らない。

dataシート。 データの蓄積場所。マスタや実績データをここに持つ。VBAを通じて読み書きする。ユーザーは直接触らない。

表紙にボタンを押すと、dataシートからデータを読み取り、帳票雛形にデータを入れて出力する。ユーザーが触るのは表紙だけ。雛形とdataは「VBAの管轄」として分離する。

「ちゃんと作ると、人はいじらない」

この構成にすると、面白いことが起きる。 使う人が怖くていじれなくなる。

関数だけで作ったシートは、みんな気軽にいじる。セルをコピーしたり、列を挿入したり、「ちょっとここ変えたいんだけど」と手を入れる。関数は壊しても影響範囲が見えやすいから、触る心理的ハードルが低い。そして、その「ちょっとした変更」が積み重なって、いつの間にか誰にも直せないシートができあがる。

一方、表紙・雛形・dataときれいに分かれていて、ボタンを押せば全部動くツールは、逆に触る気にならない。仕組みがちゃんとしているのが見てわかるから、下手にいじったら壊れそうだと感じる。

これは結果として 「いじられない設計」 になる。属人化対策のドキュメントを書くより、はるかに効果がある。

気をつけるなら、表紙に「雛形シートとdataシートは直接編集しないでください」と一言書いておくくらいで十分だと思う。逆に言えば、その一言で済む程度の構造にすることが設計の目標になる。

関数シートとの本質的な違い

以前の記事で、関数の限界について書いた。関数は「見る」ことしかできず、「処理する」にはVBAが必要だという話。

→ 中小製造業のExcel業務が「1シートで」で止まる理由

今回の話はそれとつながっている。関数で作ったシートは、データと処理と表示が全部同じシートに載っている。だから誰でもどこでも触れるし、どこを触っても影響がある。

VBAで構造を分離したツールは、データと処理と表示が分かれている。ユーザーが触れるのは表示（表紙）だけ。処理はVBAの中にあり、データはdataシートに閉じている。この分離が、「いじられない」効果を生む。

VBAを改造されたら終わりだが

この設計の唯一の弱点は、VBAそのものを改造されるケースになる。VBEを開いてコードを直接書き換えられると、設計の意図が崩れる。

ただし、中小製造業の現場でVBEを開いてコードを書き換える人は、かなり限られる。関数を触る人は多いが、VBAを触る人はほとんどいない。それ自体が一種の防御になっている。

自分はこの領域に関しては性善説でいいと思っている。お金や個人情報を直接扱うシステムなら話は別だが、生産管理や帳票出力といった業務ツールの範囲なら、悪意を前提にした対策は過剰になる。数十人規模の会社で、わざわざVBEを開いてコードを壊しにくる人はいない。どうしても気になるならVBAプロジェクトにパスワードをかけることもできるが、そこまでする場面はほとんどないだろう。

まとめ：属人化を前提にした設計

VBAの属人化を完全になくす方法はない。作った人が辞めれば、コードを読める人がいなくなるリスクは常にある。これはVBAに限らず、どの言語で作っても同じ。

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

ただし「シートに状態を持たせない」設計にしておくと、以下のことが変わる。

• ボタンを押せば同じ結果が出る。 シートの状態に依存しないから、誰が押しても同じ
• 壊れても復旧しやすい。 VBAのコードが残っていれば再構築できる
• 使う人がいじらない。 構造がしっかりしていると、心理的に触れなくなる

属人化は避けられない。しかし「いじられない設計」にしておけば、属人化のダメージを最小限に抑えられる。完璧なドキュメントを書くより、いじる余地のない構造を作る方が、中小製造業の現場には合っていると思う。

---

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

• 中小製造業のデータ加工業務は、Excelでも回せる
• 中小製造業のExcel業務が「1シートで」で止まる理由
• 中小製造業の内製DX ── Excel VBAで済む領域と、専用言語で作るべき領域

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