中小製造業のナレッジ管理が進まない本当の理由 ── Wikiを入れても書かれない

ナレッジ管理の必要性は誰もがわかっている

「ベテランの知識を残さなければ」「属人化を解消しなければ」。中小製造業に限らず、どの会社でも一度は話題に上がるテーマだろう。

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

しかし、実際にナレッジ管理が回っている中小企業はほとんどない。Wikiを導入しても更新されない。共有フォルダにマニュアルを置いても誰も書かない。「時間がないから」と言われるが、時間を与えても結果は変わらないことが多い。

問題はツールでも時間でもない。もっと手前にある。

自分の仕事を言語化できない

中小製造業の現場で長年働いてきた人たちは、仕事はできる。段取りも判断も的確。ただし、自分がやっていることを文章として書き出す訓練はしていない。

「なぜこの順番で加工するんですか?」と聞くと、「こうやるもんだから」と返ってくる。本人の中には明確な理由があるはずだが、それを言葉にする回路が普段使われていない。日記を書いたことがない人にいきなり業務手順書を書けと言っても、何から書けばいいかわからないのと同じことだと思う。

これは能力の問題ではなく、経験の問題になる。自分の業務を内省して、他人にわかる形で言語化する。この作業には慣れが要る。

効率化の先にナレッジが残らない問題

ナレッジ管理とは別の角度から、似た問題を抱えている会社がある。業務の多くを外注や派遣で回し、社内にはマネジメントと事務だけが残るような組織。効率化としては合理的に見えるが、実際に話をすると、業務の深みや知見の蓄積がほとんど感じられないことがある。

これは外注先に知識が分散してしまい、社内に残るのは「誰に何を頼むか」という段取り情報だけになっているケースだと思う。日常の業務は回る。しかし、外注先が変わったとき、要件が変わったとき、自社だけでは判断も対応もできない。業務の「どうやって」「なぜこうするのか」が社外にあるので、組織としての厚みがない。

ナレッジ管理が難しいのは、言語化できないからだけではない。そもそも知識が社内に存在しない、という状態にも陥りうる。

仕組みを与えれば回る組織、回らない組織

こう言うと失礼に聞こえるかもしれないが、事実として書いておく。

リモートワーク前提のスタートアップのように、言語化やドキュメント作成に慣れた人材が集まっている組織であれば、Wikiや仕組みを与えるだけで回る。リモートで仕事をするには文章で伝える力が前提になるから、書くスキルが自然と揃っている。

中小製造業の現場はそうではない。道具を用意して、時間を与えて、「書いてください」と言っても、それだけでは動かない。「書ける人がいない」という前提から出発しないと、施策は空振りに終わる。

現実的な解は「聞き取り役」を置くこと

本人に書かせるのが難しいなら、聞き出す側を用意するしかない。言語化が得意な人間がベテランの隣に座り、質問して、答えを構造化して残す。

ここで求められるのは、ただ話を聞くことではなく、業務の文脈を理解した上で「それはつまりこういうことですか」と翻訳できる力になる。業務を知らない人が聞いても、表面的なメモにしかならない。逆に、業務を理解している人間が聞けば、「この判断の裏にはこのロジックがある」というところまで掘り下げられる。

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

この役割は、内製DXエンジニアの仕事として自然に成り立つ。システムを作る前に業務を聞き取る工程があり、その過程で得た知識を記録として残していけば、ナレッジ管理はシステム開発の副産物として進んでいく。

一度にやろうとしない

経営者がナレッジ管理に乗り気になると、「全部門一斉にやれ」という号令が出がちになる。しかし、ナレッジの蓄積はそんなに簡単ではない。

通常業務と並行しながら、少しずつ聞いて、少しずつ残す。1回の聞き取りで完璧な手順書ができるわけではない。断片的なメモが溜まり、何度か同じ人に聞き直し、少しずつ精度が上がっていく。年単位の時間がかかる覚悟を持って、じっくり取り組むものになる。

これは見積データの再利用と同じ考え方で、日々の業務の中で自然にデータが溜まる構造を作るのが理想になる。ナレッジも同じで、特別なプロジェクトとして一気にやるのではなく、日常の業務改善やシステム構築の中で少しずつ蓄積していく方が、現実的だし定着もしやすい。

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

完璧なマニュアルを目指さない

もう一つ大事なのは、最終形をいきなり目指さないこと。

「完全な業務マニュアル」を作ろうとすると、永遠に完成しない。狙うべきは、「この人がいなくなったとき、次の人がゼロからではなく30点からスタートできる状態」で十分。

判断の根拠を一言メモで残す。「この客は仕上げにうるさいから最後に検品を入れる」──この一文があるだけで、引き継ぎのダメージは大幅に変わる。完璧な手順書ではなく、判断の手がかりを残すこと。これがナレッジ管理の現実的な着地点だと考えている。


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

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

中小製造業のシステム導入に100点はない ── 検収後の現実と、そこからやれること

パッケージは「失敗」しにくい

最初に整理しておくと、パッケージソフトの導入で根本的な失敗が起きることはあまりない。パッケージは仕様通りに動く。合う合わないはあっても、動かないということは基本的にない。

問題が起きやすいのは、フルスクラッチやカスタマイズの領域になる。自社の業務に合わせて作り込む部分で、エラーが出る、消せないデータが残る、依頼したはずの機能が実装されていない、といったことが現実に起きる。

「失敗」の線引きは曖昧

ただし、何をもって「失敗」とするかは人による。「自分が言った要望が入っていない」と思う人もいれば、「これで十分」と思う人もいる。見方の違いであって、明確な基準があるわけではない。

ある程度客観的に「失敗」と言えるのは、こういうケースだろう。

  • 操作するとエラーが出る
  • 不要なデータが削除できない
  • 依頼した機能が実装されていない、または仕様通りに動かない

逆に、「もう少しこうしてほしかった」というレベルの不満は、失敗というよりすり合わせ不足の話になる。

100%成功した導入はない

自分は過去に何度もシステム導入に関わってきたが、100%思い通りに仕上がったケースはない。小さなエラーは必ず残るし、どうしてもソフト側で実現できない機能が出てくる。

象徴的なのは、業者のSEが「この機能はシステムでは対応できないので」と言って、対策用のExcel VBAを書いて持ってくるケース。システム化するために導入したはずなのに、結局Excelで補完しているという本末転倒な状況は珍しくない。

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

検収が終わればそこで線が引かれる

システム導入には検収というプロセスがある。納品物を確認して「これで受け取ります」と合意する手続きになる。

検収が終わった後に見つかる問題は、保守契約の範囲内で対応してもらえる軽微なものに限られる。「あの機能が足りない」「ここの動きが違う」と言っても、追加費用なしでは対応してもらえないことが多い。

つまり、検収後のシステムが「完璧ではないが致命的でもない」状態であれば、そのまま使い続けることになる。これはどこの会社でも同じで、100点のシステムを使っている会社はほぼないと思っていい。

すぐには止められない現実

「合わないなら別のシステムに変えればいい」と思うかもしれないが、中小企業にとってそれは簡単ではない。

フルスクラッチやカスタマイズで作ったシステムは、資産として減価償却の対象になる。金融機関からの融資で導入している場合もある。会計上も資金繰り上も、導入して数年で捨てるという判断は取りにくい。

現実的には、最短でも5年程度は使い続ける前提になる。だからこそ、「検収後にどう付き合うか」が重要になってくる。

使いながらできることをやる

検収後のシステムに不満があっても、ただ我慢して使い続けるだけが選択肢ではない。特にフルスクラッチで作られたシステムの場合、内部に手を入れられる余地があることが多い。

ただし、契約上はシステムの内部を勝手に触ることが禁止されている場合もある。保守契約の範囲外の操作で問題が起きた場合、責任を問われる可能性がある。

ここは交渉の余地がある。不具合が多く残っている状態なら、「これだけ問題が残っているので、自分で対応させてほしい。それが難しいならきちんと修正してほしい」と伝える。開発元が小規模なシステム会社であれば「自分で触ってもらって構いません」と柔軟に対応してくれることも多い。

大事なのは、 「自分で操作していい」という許可をメールなど文面で残しておくこと。 口頭の了承だけだと、後から「勝手に触られた」と言われたときに守れない。この一手間が、自分で手を入れる際の保険になる。

その上で、できることは意外とある。

  • DBに直接接続する。 システムのデータベースにVBAやSQLで接続し、システム側では出せないレポートや集計を自分で作る。データさえ取れれば、足りない機能を補完できる場面は多い
  • サーバーの設定を見て理解する。 権限設定や接続先の構成を把握しておくと、トラブル時に業者を待たずに対処できることがある
  • 業者に頼らず直せる範囲を広げる。 マスタデータの修正、帳票のレイアウト変更など、自分で触れる部分を少しずつ増やしていく

これらは一朝一夕にはできないが、5年使い続ける前提であれば、じっくり取り組む時間はある。

次の入れ替えに向けた準備

5年後に入れ替えのタイミングが来たとき、前回と同じ轍を踏まないための準備もこの期間にできる。

今のシステムを使いながら「何が足りなかったか」「どの業務がシステムに乗らなかったか」を記録しておく。検収前には気づかなかった問題点が、日々の運用の中で見えてくる。

このデータがあれば、次の導入時に「ここだけは絶対に実現してほしい」と具体的に伝えられる。要件定義の精度が上がるだけで、同じ失敗を繰り返す確率は大幅に下がる。

手作業で検証してからシステム化する ── 中小製造業で「作ったのに使われない」を防ぐ方法

完璧を求めず、使いながら育てる

システム導入に100点はない。これを最初から受け入れておくだけで、検収後の心構えが変わる。

70点のシステムを自分の手で80点に近づけていく。足りない部分はExcelやVBAで補完する。そして5年後の入れ替え時には、今回の経験を活かしてより良い判断をする。

中小製造業のシステムとの付き合い方は、導入して終わりではなく、使いながら育てていくものだと思っている。


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

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

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

AIが実装を肩代わりする時代に、何が残るか

以前の記事で「AIはインフラになる」と書いた。また別の記事で「VBAでもAIに書かせる設計ができる」と書いた。

AIの具体的な未来予測はどうでもいい ── それでも中小製造業が今から触るべき理由
内製DXの開発にAIを使う ── VBAでも「AIに書かせる設計」はできる

この2つを合わせると、1つの問いが出てくる。AIが実装を肩代わりするようになったとき、内製DXエンジニアの仕事はどう変わるのか。

答えから言えば、 実装の「先」にある仕事——業務の理解、問題の分解、指示、検証——が本業になる。 コードを書く時間が減り、コードを書く前と書いた後の仕事が増える。

これは効率が上がるという話ではない。仕事の中身が変わるという話になる。

「何を作るか」を決める力がすべてになる

AIにコードを書かせるとき、最も重要なのは「何を書くか」の指示になる。「月別の売上集計を出して」ではなく、「受注データのうちステータスが完了のものを対象に、出荷日ベースで月別に集計し、前年同月との差額を並べて返す」——ここまで分解して初めて、AIは正確なコードを出してくる。

この分解ができるのは、業務を理解している人だけになる。「出荷日ベース」なのか「受注日ベース」なのか、「完了」の定義に何が含まれるのか、前年同月と比べるべきなのか前月と比べるべきなのか。こうした判断は業務の文脈がわからなければ下せない。

以前の記事で「DX担当者の仕事はコードを書くことではなく、現場の言葉と技術の言葉の通訳だ」と書いた。AIが実装を担うようになると、この通訳の役割がさらに重要になる。現場が「こういうのが見たい」と言ったことを、AIが実行できる精度の指示に翻訳する。その翻訳精度が、アウトプットの質を決める。

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

「全部読んで確認する」はどこかで限界が来る

AIがコードを書くスピードは速い。しかし、出てきたコードが正しいかどうかを確認するのは人間の仕事になる。

今の段階では、AIが書いたコードを全部読んで、1行ずつ確認して、動作をテストする——これで回る。VBAの関数を1つ書かせる、Excelの集計ロジックを1つ組ませる。このレベルなら、人間がすべて目を通すことは十分可能になる。

しかし、AIがもっと大きな範囲のコードを書くようになったとき——システム全体の処理を書かせる、複数のモジュールをまとめて生成する——「全部読む」というやり方は限界が来る。量が多すぎて、読んで理解すること自体がボトルネックになる。

ではどうするか。 テストの仕組みを使って、結果で検証する。

今のExcel VBAでもすでにやっていることがある。セルにテスト用の値を入れて、関数を呼び出して、期待通りの結果が返ってくるか確認する。これをもう少し系統的にやるだけの話になる。「この入力に対してこの出力が返るはず」というテストケースを先に作っておいて、AIが書いたコードをそのテストに通す。コードを全行読まなくても、テストが通れば正しく動いていると判断できる。

これは今すぐ必要な話ではないが、AIの活用範囲が広がるにつれて必要になる考え方になる。コードを「読んで確認する」から「テストで検証する」へ。確認の方法自体が変わっていく。

「どう作るか」の設計が、AIへの指示になる

以前の記事で「VBAのロジックをFunctionに切り出すとAIに書かせやすくなる」と書いた。これは「コードの構造を整理する」という話だが、もう一段引いて見ると、 設計がAIへの作業指示になる という構造の変化を意味している。

これまで設計とは「人間が修正しやすいように構造を分けること」だった。これからは「AIに担当範囲を伝えやすいように構造を分けること」が加わる。

たとえば、1つの大きな処理をAIに丸ごと書かせると、何がどうなっているか把握しにくい。しかし「この部分は入力の整形」「この部分は計算ロジック」「この部分は出力の組み立て」と分けてあれば、それぞれを個別にAIに書かせて、個別に確認できる。

この「分け方」を決めるのが設計であり、AIに実装を任せる時代になると、設計の意味がより直接的に問われるようになる。

ドメイン知識が唯一の差別化になる

AIはプログラミングの知識を持っている。ロジックを書く力は持っている。しかし、自社の業務のことは知らない。

受注生産で見積番号がどう使われているか。アワーレートをどう計算しているか。この取引先には特殊な納品ルールがあること。検査記録のどの項目が法的に必要で、どの項目が社内管理用なのか。こうした知識はAIの中にはない。

以前の記事で「自社固有の領域は自分たちで理解すべき」と書いた。AIの時代になっても、これは変わらない。むしろ強化される。AIが汎用的な実装力を提供するようになった分、 差がつくのは業務をどれだけ深く理解しているか になる。

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

コードを書くスキル自体の価値は相対的に下がる。代わりに、業務を理解して正しい問いを立て、AIに的確な指示を出し、出てきた結果を業務の文脈で検証する——この一連の能力が、内製DXエンジニアの中核的な価値になる。

今やるべきことは変わらない

これまで書いてきたことの延長にある。

AIが実装を担う時代に向けて、内製DXエンジニアが今やるべきことは、結局このシリーズで繰り返し書いてきたことと同じになる。

  • 業務を深く理解する。 データがどこにあるか、誰がどう使っているか、何が問題なのか。この理解がAIへの指示の精度を決める
  • データの持ち方を整える。 AIに読ませるにしても、整っていないデータは使えない。データの文法を正すことは、AI活用の土台でもある
  • 小さく試して検証する習慣をつける。 AIが書いたコードを検証する力は、日常の業務で仕組みを試行錯誤する中で身につく

以前の記事で「改善と変化の両方が要る」と書いた。地味な改善で足元を固めること自体が、AIという変化に乗るための準備になっている。

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


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

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

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

記事が伝えるのは考え方であって、正解ではない

このシリーズでは、原価管理、生産計画、データの持ち方、ツール選定など、内製DXの具体的な進め方を書いてきた。しかし、記事に書いてあることをそのまま自社に当てはめれば済むわけではない。会社の規模、業種、経営者の方針、現場の空気——すべて違う。最終的には自分で判断する必要がある。

DX担当者の日常は、判断の連続になる。このデータは残すべきか捨てるべきか。この業務はツール化すべきか手作業のままにすべきか。この仕組みは自分で作るべきか業者に頼むべきか。1つ1つの判断に唯一の正解はないが、 判断の基準 を持っているかどうかで、判断の速さとブレの少なさが変わる。

ここでは、自分がDXを進める中で持っている判断基準を書く。DX固有の話というより、仕事全般に使える考え方でもある。抽象的な内容になるが、判断基準というものはある程度抽象的でないと、個別の場面に当てはめられない。

依存先は常に分散させる

1つの仕入先に集中すると、その仕入先が値上げしたとき、廃業したとき、対応が悪くなったときに逃げ場がない。これは調達の基本だが、DXでもまったく同じことが言える。

1つのツールにすべてを載せると、そのツールが使えなくなったとき、業務が止まる。1人の担当者にすべてを任せると、その人がいなくなったとき、何もわからなくなる。1つの業者にすべてを委ねると、その業者の言い値が自社のコストになる。さらに言えば、依存先の実力が自分たちの天井になる。仕入先がそれ以上のことをできなければ、自社もそこで止まる。

以前の記事で「入れ替えられる設計」と書いたのは、この考え方を仕組みの設計に適用したものになる。

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

属人化のトリアージも同じ文脈で読める。属人化の本質は「依存先が1人に集中している状態」であり、致命的リスクとは「その1人がいなくなったときに業務が止まる状態」を指している。

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

常に変化を求める

「今のやり方でうまく回っているから変えなくていい」——この判断が正しいことはもちろんある。しかし、自分たちが止まっている間も、周りは動いている。ライバルは常に変化しているので、動かなければ自分たちが遅れる。現状維持を選び続けると、変化する力そのものが衰える。

製造業を取り巻く環境は、ゆっくりだが確実に変わっている。取引先がデータでのやりとりを求めてくる。熟練者が引退する。原材料が高騰する。そのときに動ける体制があるかどうかは、普段から小さな変化を積み重ねているかどうかで決まる。

DXで言えば、「今のExcel運用で困っていないから」と何も手を打たないでいると、データが属人化し、引き継ぎが困難になり、いざ変えようとしたときにはもう手遅れ——という事態になる。困ってから動くのでは遅い。困る前に少しずつ変えておく。

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

常にコストと時間を削る方向で考える

安くする。早くする。この2つは業務改善の原動力になる。なぜなら、自分たちより安く・早く提供するライバルは常に現れるからで、これはビジネスの基本原則になる。

重要なのは、大きな投資で一気に変えるのではなく、小さな改善を継続すること。1件の見積にかかる時間を10分短縮する。月次の集計作業を半日から2時間にする。このレベルの改善を積み重ねるほうが、中小製造業のDXでは現実的だし、定着もしやすい。

以前の記事で「管理精度型と工数削減型」を分けて書いたが、工数削減型のDXはまさにこの判断基準の延長線上にある。

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

逆に言えば、コストも時間も変わらない改善は、優先度を下げていい。「デジタル化すること」自体が目的になっていないか、常に問い直す。以前の記事で「『作る』前に『やめる』を考える」と書いたのもこの視点になる。

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

業務改善と技術革新は別の戦い

小さな改善を積み重ねることと、大きな技術革新が起きることは、別の話になる。

業務改善でExcelの入力を効率化し、集計を自動化し、データの流れを整えても、それだけでは業界を変えるような技術革新には勝てない。AIが業務の前提を変える、クラウドが情報の持ち方を変える——こうした変化が起きたとき、小さな改善の積み重ねは一瞬で意味を失うことがある。

しかし、技術革新はいつ起きるかわからない。そして技術革新が起きていない間は、業務改善の戦いになる。日々のコストを1円でも削り、納期を1日でも縮め、ミスを1つでも減らす。この積み重ねが競争力の差になる期間のほうが、実際には長い。

だから両方やる。日常は業務改善を回しながら、技術革新の動きにはアンテナを張っておく。以前の記事でAIについて「具体的な未来予測はどうでもいい、それでも今から触るべき」と書いたのは、この考え方に基づいている。業務改善を止めてAIに賭けるのではなく、業務改善を続けながらAIにも触っておく。どちらか一方ではなく、両方持っておくことが、どちらの局面でも戦える状態になる。

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

目的だけを見て、手段にこだわらない

DX担当者が現場とやりとりしていると、「やり方」へのこだわりに出くわすことが多い。この手順で入力したい、この並び順で表示してほしい、このExcelのフォーマットは変えないでほしい。

相手のこだわりを真正面から否定すると、関係が壊れる。しかし、すべてのこだわりに応えていると、仕組みが複雑になり、保守できなくなる。

ここでの判断基準は、 目的に影響するかどうか で切り分けること。入力手順が結果のデータに影響するなら、こだわるべき。表示順がただの好みであれば、相手に合わせればいい。フォーマットの変更が業務フローに波及するなら慎重に進める。

以前の記事で「成否は話す時間があるかどうかで決まる」と書いた。現場と話す中で、相手のこだわりが「目的」なのか「手段」なのかを見極める。手段へのこだわりは、否定せずに受け入れるか、別の方法で目的だけ達成する。

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

多様性と集中は、時間で切り替える

「選択と集中」は正しい。リソースが限られている中小製造業なら、なおさら集中したほうが成果は出やすい。一方で、「未来は予測できないから多様性を確保しておくべき」というのも正しい。1つに賭けて外れたときのダメージは大きい。

この2つは矛盾しているように見えるが、時間軸で切り替えれば矛盾しない。

まず多様性の段階。何かを選ぶ前に、広く試す。Excel VBAでもいい、GASでもいい、OSSでもいい。触ってみて、自社の業務に合うかどうかを確かめる。この段階では「絞らない」ことが正解になる。

次に集中の段階。試した中から選んだら、そこに集中して改善を続ける。あれもこれも並行して使い続けると、どれも中途半端になる。決めたら、決めたものを磨く。

そして、環境が変わったら再び多様性の段階に戻る。一度決めたことに固執せず、また広く試して、また絞る。このサイクルを回すことが、変化に対応しながら力を集中させる方法になる。

判断基準は「答え」ではなく「方向」

ここに書いたことは、自分の判断基準であって、普遍的な正解ではない。会社の状況が変われば判断も変わるし、自分自身の考えも変わるかもしれない。

ただ、判断基準を持っているかどうかで、迷う時間が減る。基準がないと、1つ1つの判断をゼロから考えることになる。基準があれば、「この場合はこの方向」と即座に仮決定ができて、そこから微調整すればいい。

DX担当者に限らず、中小製造業で仕事をしていると、前例がない判断を求められる場面は多い。そのとき「こういうときはこう考える」という軸を自分の中に持っておくことが、仕事を進める上での地盤になる。


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

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

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

DXを進めると、攻撃される面も増える

このシリーズでは、NASでファイルを共有する、VPNで外から社内にアクセスする、サーバーを立てて業務データを集約する、といった話を書いてきた。どれも業務を効率化するための仕組みだが、同時にサイバー攻撃の侵入口を増やしていることになる。

何も導入していなければ、攻撃者から見て「入る場所がない」。しかしVPNを設置すれば、そこが入口になる。NASをネットワークに繋げば、そこが標的になる。DXとは便利にすることだが、便利にした分だけリスクも増える。この構造を意識しているかどうかで、対策のスタンスが変わってくる。

中小製造業にとって一番怖いのはランサムウェア

サイバー攻撃には色々あるが、中小製造業にとって最もダメージが大きいのはランサムウェアになる。社内のファイルを片っ端から暗号化して使えなくし、復号と引き換えに身代金を要求する攻撃。

大企業であれば情報漏洩のほうがダメージが大きいかもしれない。しかし中小製造業の場合、データが暗号化されて業務が止まること自体が致命的になる。見積データが開けない、図面が見られない、受注履歴が消える。出荷が止まれば売上が止まる。復旧までの数日〜数週間、会社が丸ごと機能停止する。

以前の記事で「やられた後にどう戻すか」を書いた。今回はその手前、「そもそもやられないために何をするか」の話になる。

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

侵入経路はだいたい決まっている

ランサムウェアの侵入経路は、実はそれほど多くない。警察庁の統計でも、主な経路は次の三つに集中している。

  • VPN機器の脆弱性。 最も多い経路。VPN機器のファームウェアにセキュリティ上の穴が見つかり、そこから侵入される。FortinetやPulse Secureなど、中小企業でよく使われている機器で実際に起きている
  • リモートデスクトップ(RDP)。 外部からPCに接続するための仕組み。ポートが外部に開いたまま放置されていると、パスワードの総当たり攻撃で突破される
  • メール。 不審な添付ファイルやリンクからマルウェアに感染し、そこからランサムウェアが展開される

VPNとRDPで全体の7〜8割を占めている。メールは印象ほど多くなく、むしろネットワーク機器の脆弱性が主戦場になっている。

分からなければ業者に頼む

セキュリティ対策は、このシリーズで書いてきた内製DXとは少し性質が異なる。

内製DXでは「自社固有の領域は自分たちで理解すべき」と書いてきた。しかしセキュリティは自社固有ではない。ネットワーク構成の設計、ファイアウォールの設定、VPN機器の選定と運用——これらは製造業だろうとサービス業だろうと共通の技術領域になる。

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

だから、セキュリティの設計や運用は業者に任せていい。むしろ任せたほうがいい場面が多い。ただし、以前の記事でも書いた通り、丸投げと任せることは違う。業者に「セキュリティお願いします」とだけ言うのではなく、自分たちが 何を守りたいのか は伝えられるようにしておく。

  • うちの業務データはここにある
  • 最悪止まっても1日で復旧できれば耐えられる
  • バックアップはここに取っている

こういう情報を自分たちで把握しておくだけで、業者との会話が成り立つようになる。

自分でやるなら、最低限ここから

業者に頼むほどではない、あるいは自分でできる範囲でまずやりたい、という場合。中小製造業のIT環境には「ランサムウェア以前の問題」が山ほどあるので、まずそこから手をつける。

セキュリティソフトをインストールして、アップデートを適用する。 セキュリティソフトの期限が切れている、あるいは最初から入っていない。Windows Updateも「再起動が面倒」「更新すると遅くなる」で何年も止めている——こういう環境は珍しくない。Windows標準のDefenderでも、有効になっていて定義ファイルが最新であれば基本的な防御はできる。ソフトを入れて終わりではなく、OSも含めてアップデートを止めないことが重要になる。既知の脆弱性を放置するリスクのほうがはるかに大きい。

利用しているWebサービスのパスワードを複雑にする。 メールのパスワードが全員共通、PCのログインパスワードが全台共通、あるいはパスワードなしで使っている。こういう状態では、退職者でもそのままアクセスできるし、誰がどの操作をしたかも追えない。メール、クラウドストレージ、業務システム、会計ソフト——ログインが必要なサービスすべてについて、推測しにくいパスワードを個別に設定する。パスワードマネージャーの導入まで考える必要はない。まず「共通をやめる」だけで大きく変わる。

NASやネットワーク機器のパスワードも複雑にする。 NAS、WiFiアクセスポイント、スイッチ、プリンター。こうしたネットワーク機器にも管理画面があるが、初期パスワードのまま、あるいはWiFiのパスワードが「123abc」のような文字列で運用されていることが多い。これらの機器はネットワーク上でつながっているので、一つが突破されると他にも影響が及ぶ。管理画面にログインして、パスワードを変更する。WiFiのパスワードも同様になる。

UTMやルータなど外部ネットワークと接する部分は、専門家に頼むか、マニュアルを見ながら慎重に設定する。 ここまでの対策は社内の衛生管理であり、自分でできる範囲の話。しかしUTM(統合脅威管理)やルータは、インターネットと社内ネットワークの境界に立つ機器になる。ファイアウォールの設定、ポートの開閉、VPN機器のファームウェア更新——この領域は設定を一つ間違えると外部から丸見えになる。自信がなければ業者に頼む。自分でやるなら、メーカーのマニュアルやサポートページを確認しながら慎重に進める。「なんとなく動いているからいいだろう」で放置するのが一番危ない。

完璧を目指さない

ここに書いたことを全部やっても、ランサムウェアを100%防げるわけではない。防御を固めても、すり抜けはゼロにならない。

だからこそ、以前の記事で書いた「やられた後にどう戻すか」が重要になる。バックアップをネットワークから切り離した場所に持ち、復旧手順を把握しておく。防御と復旧は両輪で、どちらか片方だけでは機能しない。

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

今回の記事は「やられる前の最低限の備え」。あの記事は「やられた後の最低限の備え」。この二つをセットで考えることが、中小製造業にとって現実的なセキュリティの全体像になる。


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

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

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

食わず嫌いされているスプレッドシート

以前の記事で、Google Workspaceのデータ主権の問題について書いた。機能だけ借りてデータは手元に持つ、という使い分けを提案した。

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

ただ、リスクがあるから使うなという話ではない。開発プラットフォームとして見ると、Googleスプレッドシート+GAS(Google Apps Script)にはExcel VBAにはないメリットが確実にある。今回はその具体的な得意・不得意の話をしたい。

まず言っておきたいのは、スプレッドシートは食わず嫌いされていることが多いということ。サービスが出始めた頃は確かに使い物にならなかった。Excelと比べて遅い、関数が少ない、操作感が違う。その頃の印象を引きずっている人がまだ多い。

しかし今のスプレッドシートは相当進化している。例えば、1つのセルに関数を入れれば末尾の行まで自動で展開されたり、別のスプレッドシートからデータを引っ張ってこられる関数がある。他にも同時編集ができるので「誰かが開いているから編集できない」がないなど、Excelにはない便利さが確実にある。

ただしプラットフォームごと入る必要がある

スプレッドシートとGASの話をする前に、大前提がある。 Google Workspaceはチーム単位で導入しないとメリットが出にくい。

全員がMicrosoft Officeを使っている中で、1人だけGoogleスプレッドシートを使っても、ファイルのやりとりのたびに変換が発生する。同時編集もできない。GASで作った仕組みも、Googleアカウントを持っていない人には使えない。

使えないわけではないが、メリットが限定される。スプレッドシート+GASの強みは、チーム全員がGoogle Workspace上にいる前提で成立する。

導入を検討するなら、外出やリモートワークが多い会社は相性がいい。ブラウザさえあれば同じファイルにアクセスできるので、場所を選ばない。逆に全員が同じ事務所にいて、ローカルのExcelで十分回っているなら、あえて乗り換える理由は薄い。

Excel VBAとは得意・不得意が逆

このシリーズではExcel VBAを中心に書いてきた。スプレッドシート+GASはその「クラウド版」のような存在だが、得意・不得意がきれいに逆になる。

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

Excel VBAが得意でGASが苦手なこと:大量データの処理。 Excelは手元のPCで動くので、数万行のデータでもストレスなく扱える。VBAの処理も、PCのスペックが許す限り一気に回せる。

スプレッドシートはブラウザ上で動くため、数千行あたりからもたつきが出る。描画が非同期で、セルに値を入れてもワンテンポ遅れて反映されることがある。Excelに慣れた人にとっては、この遅延が地味にストレスになる。GASにも実行時間の制限がある。処理が長くなるとタイムアウトする。VBAなら気にしなくていい「トリガー」や「バッチ処理」という概念を意識して設計する必要が出てくる。

GASが得意でExcel VBAが苦手なこと:共有と定時実行。 スプレッドシートは最初から共有前提で作られている。同時編集、権限管理、変更履歴が標準で付いている。VBAのExcelファイルで「共有ブック」を使ったことがある人なら、あのつらさとの差は歴然としている。

GASのトリガー機能も大きい。「毎朝8時にこの処理を実行する」がコード数行で実現できる。VBAで同じことをやるには、PCを常時起動してタスクスケジューラを設定する必要がある。

Excel VBA スプレッドシート+GAS
大量データ(数万行〜) 得意 苦手(数千行で重くなる)
処理速度 PC性能次第で高速 実行時間制限あり
同時編集 苦手 標準機能
定時実行 環境構築が必要 トリガーで簡単
環境構築 バージョン差・設定の罠あり ブラウザだけで動く
オフライン 問題なし 基本的にネット必須

データが増えると別の道具が必要になる

Google Workspace環境で開発を進めていくと、ある時点で壁にぶつかる。データ量の壁になる。

スプレッドシートで数千行のデータを集計するGASを書いて、トリガーで毎朝実行する。最初は快適に動く。しかしデータが増えてくると、処理が重くなり、タイムアウトに引っかかるようになる。

Excel VBAなら、同じデータ量の増加に対して「PCのメモリを増やす」「処理を最適化する」で対応できる。しかしスプレッドシート+GASでは、プラットフォーム側の制約を超えられない。

結果として、Google Workspace環境ではデータ量が増えるとBigQueryやAppSheetのような専用サービスにデータ処理を移行する流れになりやすい。これは3層モデルで言えば第三層への移行と同じ構造だが、移行先がGoogleのエコシステム内に限定されやすいという点が異なる。

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

Excel VBAの場合、第三層への移行先はC#やPythonなど、プラットフォームに依存しない選択肢が取れる。ここに、以前の記事で書いた「入れ替えられる設計」の考え方がつながる。

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

ファイル形式の選択は思った以上に重い

技術的な得意・不得意とは別に、もう一つ考えておくべきことがある。 データをどのファイル形式で蓄積していくか という問題になる。

Google Workspaceを数年運用すると、スプレッドシート、ドキュメント、スライド、GASのスクリプト——すべてがGoogleの形式でデータが積み上がっていく。お試しで使っている段階なら乗り換えは簡単だが、数年分の業務データとロジックが載った状態から別のプラットフォームに移行するのは、現実的にはかなり厳しい。

ただし、これはGoogleだけの問題ではない。Microsoft 365に全部載せても同じことが起きる。Excelのマクロ付きファイル、SharePointのワークフロー、Power Automateの設定——どのプラットフォームでも、深く使えば使うほど移行コストは上がる。Googleが潰れるリスクを心配するなら、Microsoftにも同じことは言える。

大事なのは、どちらが安全かではなく、 データをプラットフォーム固有の形式に閉じ込めすぎないこと になる。以前の記事で「データの文法」として書いたCSVで出力できる形でデータを持つ、という原則はここでも効く。スプレッドシートでもExcelでも、業務データ本体はCSVやDBに落とせる構造にしておけば、プラットフォームの乗り換えが必要になったときにデータだけは救える。

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

どちらを選ぶかは働き方で決まる

結局のところ、Excel VBAとスプレッドシート+GASのどちらが優れているかという話ではない。

事務所にいる時間が長く、手元のPCでデータを扱う業務が中心なら、Excel VBAのほうが自然。 PCのパワーをフルに使える。データ量の制約も緩い。オフラインでも動く。

外出やリモートが多く、複数拠点でデータを共有する必要があるなら、スプレッドシート+GASが向いている。 ブラウザさえあればどこでも使える。同時編集とトリガーが最初から使える。

中小製造業の場合、工場と事務所が一体になっていて、ほぼ全員が同じ場所で働いているケースが多い。そういう環境ではExcel VBAのほうが素直にハマることが多い。このシリーズでExcel VBAを中心に書いてきたのは、そういう現場が想定読者だからになる。

ただ、拠点が複数あったり、営業が外で動く時間が長かったりする会社なら、Google Workspace+GASのほうが合う場合もある。道具の選択は、技術の優劣ではなく、自分たちの働き方に合っているかどうかで決めるべきものになる。


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

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

内製DXエンジニアの道具箱 ── Excel・テキストエディタ・SQLの組み合わせ

Excelの外にも道具がある

以前の記事で、Excelの中にも複数の層があると書いた。ワークシートの操作、標準の関数、VBAでのシート操作、VBAで作るオリジナル関数。これらを重ねて使うのが現実的なやり方になる。

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

しかし、内製エンジニアの仕事は定型業務の仕組みを作ることだけではない。むしろ、仕組み化した後のほうが「想定外の問い合わせ」が増える。

「先月の不良率が跳ねたんだけど、品番別に見たい」「この顧客、去年と比べて発注ペース落ちてない?」「基幹システムから出力したデータ、フォーマットがおかしいから整形してほしい」

こういう突発的な調査・分析は、あらかじめ仕組み化しておくことが難しい。そのつど発生して、そのつど違う切り口が求められる。定型業務ならVBAやシステムで自動化すればいいが、不定形の仕事には「手で道具を使い分ける力」が要る。

こういうときに自分が使っているのは、大きく分けて3つの道具になる。Excel、テキストエディタ、SQL。どれも高価でも難解でもない。しかしこの3つを組み合わせると、突発的なデータ加工業務はほぼカバーできる。

テキストエディタ:大きなファイルと正規表現

Excelには行数の上限がある。100万行を超えるデータは開けない。しかし業務データがそこまで大きくなることは少ないから、普段は問題にならない。

テキストエディタが必要になるのは、Excelとは違う操作が求められるときになる。

正規表現が使える。 「数字3桁+ハイフン+数字4桁のパターンを探す」「特定の文字列の前後を一括で置換する」といった、パターンに基づいた検索・置換ができる。Excelの検索置換では対応しにくい柔軟なテキスト操作が可能になる。

矩形選択ができる。 通常のテキスト選択は行単位だが、矩形選択なら列方向に範囲を選んでコピー・削除・挿入ができる。固定長のテキストデータを切り出すとき、特定の位置の文字列だけ抜き出したいときに使える。

大きなファイルをそのまま開ける。 数百MBのログファイルやCSVでも、専用のテキストエディタなら固まらずに開ける。中身を確認して、必要な部分だけ切り出してからExcelに持っていく、という使い方になる。

自分はEmEditorを使っているが、大きなファイルを軽快に開けて正規表現と矩形選択ができるエディタなら何でもいい。道具は何を使うかより、何ができるかのほうが大事になる。

SQL:集計と突合の言語

SQLはデータベースの操作言語として知られているが、内製DXの文脈では「集計と突合の道具」として使う。

Excel関数でも集計はできる。SUMIFSで条件付きの合計、COUNTIFSで条件付きのカウント。しかし、条件が複雑になってくると関数の組み合わせでは限界が来る。

グループ化と集計。 「品番ごと・月ごとの出荷数量を集計して、前年同月と比較する」。こういう多段階の集計は、SQLなら数行で書ける。Excelのピボットテーブルでもできるが、条件が増えるほどSQLのほうが見通しがいい。

複数テーブルの突合。 「発注データと入荷データを発注番号で突合して、未入荷のものだけ抽出する」。以前の記事で、2つのデータをつなげる瞬間に壁が来ると書いた。SQLのJOINは、まさにこの壁を越えるための道具になる。

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

条件の組み合わせ。 「過去6ヶ月の注文実績があり、かつ今月の受注がなく、かつ前年同月には受注があった顧客の一覧」。こういう条件の組み合わせは、SQLのWHERE句で書くと明快になる。関数で同じことをやろうとすると、何重にもネストした式になって読めなくなる。

SQLを使うには何らかのデータベースが必要になるが、大掛かりなシステムは要らない。ExcelのデータをCSVで書き出して、SQLiteのような軽量なデータベースに読み込ませれば、すぐにSQLで操作できる。VBAからSQLを実行する方法もある。

AI:道具箱の使い方が変わる

ここまで書いたテキストエディタやSQLは、自分で操作を覚える必要があった。正規表現の書き方、SQLの構文、それぞれの道具に固有のスキルが要る。

AIの登場で、この前提が変わりつつある。

「このCSVを品番別に集計するSQL書いて」「この形式のテキストから日付だけ抜き出す正規表現を教えて」——こういう聞き方をすれば、AIがコードやパターンを書いてくれる。道具の操作方法を全部覚えていなくても、「何をしたいか」を言語化できれば、AIが道具を代わりに操ってくれる。

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

これは道具箱のハードルを大きく下げる。以前なら「SQLを覚える時間がない」で止まっていた人でも、AIに聞きながら使えば結果にたどり着ける。道具箱に入っている道具の数は同じでも、使いこなせる人の裾野が広がる。

ただし、AIが出した結果が正しいかどうかを判断するのは自分になる。業務を理解していなければ、AIの出力が合っているかどうかを検証できない。道具の敷居は下がっても、使う人間の理解力が要ることは変わらない。

仕組み化と道具箱の役割分担

内製エンジニアの仕事には2つの面がある。

繰り返す業務は仕組みにする。 毎月の集計、定期的なレポート、日常の入力業務。これらはVBAやシステムで自動化して、自分の手から離す。以前の記事で書いた「Excelでも回せる」というのは、この定型業務の仕組み化の話になる。

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

突発的な調査・分析には道具箱で対応する。 「今すぐこのデータを調べてほしい」「この2つのデータを突合したらどうなる?」——こういう不定形の仕事は、仕組み化のしようがない。そのつど手持ちの道具を組み合わせて対応する。

テキストエディタでCSVを整形して、SQLで集計して、結果をExcelに貼り付けて仕上げる。こういう連携は定型の手順ではなく、そのときの課題に応じて組み立てるものになる。

天井は道具ではなく、自分の理解力

この道具の組み合わせで「ほぼなんでもできる」と書いたが、正確に言えば「自分が理解できる範囲のことは、ほぼなんでもできる」になる。

標準偏差を使った分析が必要だとしても、標準偏差の意味を自分が理解していなければ、道具がいくらあっても正しい分析はできない。逆に、やりたいことの意味を理解していれば、たいていの処理はこの3つの道具のどれかで実現できる。

以前の記事で「管理精度の天井は経営者の判断力で決まる」と書いた。道具の話も同じ構造になる。 天井を決めるのは道具の性能ではなく、使う人間の業務理解力。

中小製造業のDX、管理精度の「天井」はどこにあるか ── 経営者の判断力という上限

高価なBIツールや分析プラットフォームを導入しても、使う側が「何を見たいか」「なぜその数字が重要か」を理解していなければ、ダッシュボードは飾りになる。逆に、ExcelとテキストエディタとSQLという安価な道具でも、業務を理解した人間が使えば、経営判断に必要な情報は十分に引き出せる。

これが内製エンジニアの価値

以前の記事で、内製DXにおける道具選びの3層モデルを整理した。市販ソフト、Excel VBA、専用言語。

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

定型業務はこの3層のどこかで仕組み化すればいい。しかし仕組み化できない突発的な仕事——調査、分析、トラブル対応——は、どの層にも収まらない。そこを埋めるのが、今回の道具箱の話になる。

内製エンジニアの価値は、定型業務を仕組み化する力だけではない。「急ぎで調べてほしい」と言われたときに、手持ちの道具で素早く対応できる力。業務を理解した上で、適切な道具を選んで組み合わせ、必要な情報を引き出す。大きなシステムに頼らず、現場の課題にその場で対応する。

道具そのものは誰でも手に入る。Excel、テキストエディタ、SQLの入門書はいくらでもある。しかし 「この業務にはどの道具を使えばいいか」を判断できるのは、業務を知っている人間だけ になる。道具を知っているだけでも、業務を知っているだけでも足りない。両方を持っていることが、内製エンジニアの強みになる。


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

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

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

AIにコードを書かせる時代は、もう来ている

以前の記事で、AIの具体的な未来予測を追いかけるより構えを取ることが大事だと書いた。その中で「コード生成は予想以上に早く実用化した領域」とも触れた。

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

Claude Code、GitHub Copilot、Cursor——こうしたAIコーディングツールを使えば、「こういう処理がほしい」と自然言語で説明するだけで、動くコードが出てくる。完璧ではないが、ゼロから書くより格段に速い。

内製DXの開発にこれを使わない手はない。

1人のDX担当者がカバーできる範囲が変わる

中小製造業の内製DXは、たいてい1人か2人の担当者で回している。以前の記事で「大半はExcel VBAで回る」と書いたが、それでも1人が書けるコードの量には限界がある。

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

AIコーディングツールを使うと、この限界が緩和される。ロジックの実装速度が上がる。調べ物の時間が減る。「この関数、どう書くんだっけ」という停滞がなくなる。結果として、1人のDX担当者がカバーできる業務の幅が広がる。

以前の記事で「内製と外注の線引き」を書いたが、AIによって「1人で内製できる範囲」が広がることで、これまで外注に出していた開発の一部を内製に引き戻せるケースも出てくる。

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

ただし、VBAとAIの相性には偏りがある

ここからが本題になる。

AIコーディングツールは万能ではない。特にExcel VBAの領域では、AIに書かせやすい処理と書かせにくい処理がはっきり分かれる。

AIが苦手なのは、シートを直接操作するコード。 セルの位置、シートの名前、レイアウトの構造——こういった「そのExcelファイル固有の文脈」に依存する処理は、AIに正確に伝えるのが難しい。「A列の3行目から始まるデータを、B列のヘッダーが"数量"の列と照合して……」という指示は、人間が口頭で説明するのと同じくらい曖昧になりやすい。結果として、出てくるコードはセルの参照位置がずれていたり、想定と違うシートを操作したりする。

AIが得意なのは、入力と出力が明確な純粋なロジック。 「日付と数量のリストを受け取って、月別の合計を返す」「単価と数量と割引率から金額を計算する」「2つの配列を共通キーで突合して差分を返す」——こうした処理は、入力と出力の仕様さえ伝えれば、AIはかなり正確なコードを書いてくる。

この差は、AIの能力不足ではなく、問題の構造に起因する。シート操作は「文脈依存」、ロジックは「文脈非依存」。AIは文脈非依存の問題が得意になる。

Excelでやりたいことを実現する手段は1つではない

Excelで何かをやりたいとき、実はいくつかの手段を重ねて使える。

まず、ワークシートの操作だけでできることが意外と多い。 A列とB列の文字列を結合する、オートフィルで連番を振る、並べ替えやフィルターでデータを整理する。これはコードを一切書かない操作だが、データの下ごしらえとして重要な層になる。

その上に、ワークシート関数で計算を加える。 VLOOKUP、SUMIFS、INDEX/MATCHなど。以前の記事で書いた「見る」の範囲はこれで対応できる。

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

さらに、VBAでシートを操作する。 セルを読み書きする、シートを追加する、ファイルを開いて処理する。以前の記事で書いた「処理する」の領域はここから始まる。

そして、VBAでオリジナルのワークシート関数を作る。 VBAでFunctionプロシージャを書くと、ワークシート上で標準の関数と同じように使える。自社の業務に特化した計算——独自の原価計算ロジック、特殊な納期の算出、自社ルールに基づく割引計算——を関数化できる。

これらは排他的ではない。ワークシートの操作でデータを整え、標準関数で基本的な計算を行い、足りない部分をVBAで補い、複雑なロジックはオリジナル関数に切り出す。層を重ねて使うのが現実的なやり方になる。

ここにAIとの相性を重ねると、こうなる。

手段 AIとの相性 理由
ワークシート操作 手作業なのでAIの出番がない
ワークシート関数 関数自体は定型だが、シートのレイアウトに依存
VBAでシート操作 セル位置・シート構造への依存が大きい
VBAでオリジナル関数 入力→処理→出力が明確。純粋なロジック

AIと最も相性がいいのは、オリジナルのワークシート関数。 入力と出力が明確で、AIにとって「仕様どおりの関数を書く」という得意な形に収まる。しかも、VBAの中だけで使う内部的なFunctionとしてではなく、ワークシート関数として作ると、シート上でそのままテストできる。セルにテスト用の値を入れて、関数を呼び出して、期待通りの結果が返ってくるか確認する。VBAのデバッガを使うより直感的で、動作確認が速い。

AIの登場によって、この層の重ね方に新しい判断基準が加わった。AIに書かせやすい部分を意識的にオリジナル関数として切り出すという設計判断になる。

ロジックをFunctionに切り出す

VBAで何かの処理を書くとき、以前なら1つのSubプロシージャにまとめることが多かった。シートからデータを読んで、計算して、結果を書き込む。全部が一つの塊になっている。

これからは、意識的に分けたほうがいい。

シートを触る部分(入出力)ロジックの部分(計算・判断) を分離する。ロジックはFunctionとして切り出す。Functionは引数でデータを受け取り、戻り値で結果を返す。シートのことは知らない。

こうすると、Functionの部分はAIに書かせられる。「こういう入力を受け取って、こういう処理をして、こういう出力を返すFunctionを書いて」——これはAIが最も得意とする指示の形になる。

シートを触る部分——どのセルから読んで、どのセルに書くか——は、そのファイルの構造を知っている自分が書く。ロジックはAIに任せる。この役割分担が、VBAでAIを活かすための設計方針になる。

コードの品質も上がる

「AIに書かせやすい構造にする」ことが、そのままコードの品質向上にもつながる。

ロジックをFunctionに切り出すということは、処理の責任を明確に分離するということ。以前の記事で、VBAが大きくなるとコードの見通しが悪くなり、「一部を変えたら別の場所が壊れる」問題が起きると書いた。Functionへの分離は、この問題の緩和になる。AIのために構造を整えたら、結果として保守しやすいコードになった——という副産物がある。

まずは1つの関数をAIに書かせてみる

やることは単純になる。

今作っているVBAの中で、計算や判断のロジックが入っている部分を見つける。その部分をFunctionとして切り出せないか考える。引数と戻り値を決める。そして、AIに「こういう関数をVBAで書いて」と頼んでみる。

出てきたコードが完璧かどうかはわからない。テストは必要になる。しかし、ゼロから自分で書くよりは速い。そして何度かやっていると、AIにどう指示すれば精度が上がるかの肌感覚がついてくる。

以前の記事で「挑戦自体が資産になる」と書いた。コーディングにAIを使うことは、その最も具体的で、効果の見えやすい入口になる。

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


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

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

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

棚卸ししても判断に使えない

受注生産の中小製造業でも、在庫の問題は起きる。受注生産だから在庫は少ないはず——理屈ではそうだが、現場を見ると材料棚には端材が積み上がり、加工途中の仕掛品が棚に並び、出荷待ちの製品が通路を塞いでいることは珍しくない。

毎月棚卸しをやる。数を数えて、金額を出して、帳簿と突き合わせる。そこで「在庫金額1,200万円」という数字が出る。

しかし、この数字を見て何か判断できるかというと、できないことが多い。1,200万円は多いのか少ないのか。去年より増えたのか減ったのか。増えたとして、それは問題なのか正常なのか。棚卸しの数字だけでは、そこまでわからない。

以前の記事で「データは単体では意味がない」と書いた。在庫金額もまさにそうで、総額だけ見ていても判断の材料にならない。しかし在庫の場合、原価と並べる前にやるべきことがある。 在庫そのものを「分けて見る」 ことになる。

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

フロー在庫とストック在庫

受注生産の在庫を見るとき、最も有効な切り口は 「フロー」と「ストック」 の区別になる。

フロー在庫は、特定の受注に紐づいて生産の流れの中を動いているもの。注文Aのために買った材料、注文Bの加工途中の部品、注文Cの完成品で出荷待ちのもの。これらはすべて行き先が決まっている。受注番号で追える。いずれ出荷されて売上になり、キャッシュとして回収される。

ストック在庫は、特定の受注に紐づいていないもの。どの注文にも割り当てられていない材料、キャンセルで浮いた仕掛品、行き先のない完成品。これらは帳簿上は資産だが、出荷の見込みが立っていない。キャッシュが寝ている状態になる。

受注生産では、本来ほとんどの在庫がフローであるべきになる。注文が入り、材料を手配し、加工して、出荷する。この流れの中にある在庫は「動いている在庫」であって、管理上の心配は少ない。

問題はストック在庫になる。そして厄介なのは、フロー在庫とストック在庫が区別されないまま「在庫1,200万円」と合算されていることにある。

素材:ストックの最大の発生源

受注生産であっても、材料はロットで買わざるを得ないことが多い。鋼材は定尺で入荷する。ネジやボルトは箱単位。塗料は缶単位。注文に必要な量だけピッタリ買えることはまずない。

たとえば、ある注文でSUS304の板材が必要になる。定尺1000mm×2000mmで入荷して、必要な分を切り出す。残りの端材は棚に戻す。次の注文でも同じ材種が必要になるかもしれないし、ならないかもしれない。

この端材は、入荷した時点ではフロー在庫だった。注文Aのために買ったものだから行き先がある。しかし切り出した瞬間、残りはストック在庫に変わる。行き先が決まっていない。次に使える注文が来るまで、材料棚で眠ることになる。

この「フローからストックへの転換」が、受注生産の素材在庫で日常的に起きている。定尺材を買うたびに端材が発生し、少しずつストックが積み上がる。

管理上の問題は、この端材が把握されているかどうかになる。端材の材種・サイズ・量がわかっていれば、次の注文で新品を買う前に「使える端材がないか」を確認できる。把握されていなければ、使える端材があるのに毎回新品を買い、端材はさらに溜まっていく。

もう一つ、素材で厄介なのが 紐づきで買った小さな部品 になる。

大きな材料は目に見える。鋼材が棚に積まれていれば誰でも気づく。しかし小さな部品——特殊なボルト、Oリング、電子部品——は棚の奥に紛れたり、別の注文の部品と混ざったりして、物理的に見つからなくなることがある。

ネジやボルトのような汎用品を発注点方式で管理しているなら問題は少ない。在庫が減ったら補充する、意図的なストックだから管理もシンプルになる。しかし、特定の注文向けに紐づきで買った小物部品は事情が違う。

注文Aのために買った特殊部品が、入荷後に現場で見つからなくなる。組み立て担当が探しても出てこない。納期が迫っているから、もう1個発注する。数日後、最初の部品が別の棚から出てくる。同じ部品が2個になる。片方はフローとして使われ、もう片方は行き先のないストックになる。

この「見つからないから再発注」のパターンは、1回あたりの金額は小さい。しかし繰り返されると積み上がる。しかも小さいから棚卸しでも見落とされやすい。気づいたときには、使い道のない特殊部品が引き出しの中に散在している。

定尺材のストック化が「ロット買いの構造」から来るのに対して、小物部品のストック化は 「物理的に見えない」 という現場の問題から来る。原因が違うから、対策も違う。端材は台帳で管理すればいいが、小物部品は保管場所のルール——注文番号ごとに箱を分ける、入荷したらすぐ所定の場所に置く——という物理的な整理が先になる。

それでも紐づき小物の滞留は完全には防げないことが多い。月次の棚卸しでも小さな部品は見落とされやすいから、問題が大きい品目については別途手を打つ必要がある。たとえば再発注が頻繁に起きている品目だけ抜き出してリスト化し、棚卸しとは別に現物を確認する。全品目に手間をかける必要はない。「ストック化しやすい品目」に絞って注意を向けるだけでも、積み上がりを早い段階で把握できる。

仕掛品:止まったフローに注意する

受注生産の仕掛品は、基本的にフロー在庫になる。注文Aの部品を加工している途中、注文Bのユニットを組み立てている途中——いずれも受注番号に紐づいていて、行き先が決まっている。

以前の記事で、生産管理ではバッファ在庫を置いて前後工程を分断するポイントスケジューリングが有効だと書いた。このバッファとして意図的に置いている仕掛品も、最終的には出荷につながるフロー在庫になる。

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

仕掛品で問題になるのは、 「止まったフロー」 になる。

注文がキャンセルされた。しかし加工途中の部品はラインに残っている。品質問題が出て、手直しするか廃棄するか判断が保留になっている。必要な部品が入荷せず、組み立て途中のまま棚に置かれている。

これらはもともとフロー在庫だったが、何らかの理由で流れが止まり、実質的にストック在庫になっている。そして「止まったフロー」は見つけにくい。もともと受注番号が紐づいているから、台帳上はフロー在庫のまま残っていることが多い。受注番号があるから「まだ動いている」ように見えるが、実際には動いていない。

仕掛品のストック化は、在庫管理の問題というより生産管理の問題になる。しかし「この仕掛品は動いているのか止まっているのか」を把握すること自体は、フロー/ストックの区別で見えてくる。

完成品:受注生産なら本来ゼロに近い

受注生産の完成品在庫は、本来ほとんど存在しないはずになる。作ったらすぐ出荷する。それが受注生産の基本的な流れになる。

完成品が倉庫にある場合、ほとんどは 「出荷待ち」 になる。顧客の検収待ち、他の注文と合わせて一括出荷する待ち、輸送手配の待ち。これらはまだフロー在庫で、出荷日が決まっているなら管理上の問題は小さい。

完成品がストック在庫になるケースは限られているが、起きると影響が大きい。

  • 注文がキャンセルされたが、完成品がすでに仕上がっている
  • 検収で不合格になり、手直しするか再製作するか保留になっている
  • 見込みで作った製品(営業の「たぶん受注できる」で先行生産したもの)が売れていない

完成品のストック化は、素材や仕掛品と違って金額が大きくなりやすい。材料費に加えて加工費も乗っているから、1件でも滞留すると在庫金額へのインパクトが大きい。

逆に言えば、完成品のストック在庫が発生していたら、それは在庫管理の問題ではなく、受注プロセスや営業との連携の問題になる。

分けて見ると、同じ数字でも意味が変わる

フローとストックを分けると、棚卸しの数字の見え方が変わる。

会社A 会社B
在庫金額(合計) 1,200万円 1,200万円
うちフロー在庫 1,000万円(83%) 600万円(50%)
うちストック在庫 200万円(17%) 600万円(50%)

合計は同じ1,200万円だが、中身はまったく違う。

会社Aは在庫の大半が受注に紐づいている。出荷すればキャッシュに変わる。在庫金額としては問題ない。

会社Bは在庫の半分が行き先のないストックになっている。600万円が倉庫に眠ったまま、出荷の見込みが立っていない。合計の1,200万円という数字だけ見ていたら、この違いに気づけない。

以前の記事で「見える化の本質は基準と実績の突合」だと書いた。在庫管理でいえば、フロー在庫の「基準」は受注に対して必要な量であり、それと実際の手持ちを突き合わせることになる。ストック在庫にはそもそも基準がない。基準がないものは突合のしようがないから、まず「基準のない在庫がどれだけあるか」を把握すること自体が最初のステップになる。

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

まず「分ける」ところから始める

フロー/ストックの区別は、高度なシステムがなくてもできる。

棚卸しのときに、各品目に対して「これはどの注文向けか」を確認する。受注番号が紐づけば(あるいは紐づくことが明らかであれば)フロー。紐づかなければストック。これだけになる。

以前の記事で、仕入管理は受注番号を軸にした紐づけで成り立っていると書いた。在庫の分類も同じ軸が使える。受注番号がついているかどうか。ついていないものがストック在庫として溜まっていないか。

中小製造業の仕入管理は「今のやり方」から始める ── 受注番号を軸にした紐づけの実践

最初は棚卸しの際に「フロー/ストック」の列を1つ追加するだけでいい。全品目を完璧に分類する必要はない。金額の大きいものから見ていけば、ストック在庫がどこに集中しているかは見えてくる。

受注生産の在庫管理で大事なのは、正確な数を数えることではない。 在庫の中身を分けて見ること になる。フローなら流れに任せればいい。ストックなら「なぜ止まっているのか」「使える見込みがあるのか」を判断する必要がある。「在庫1,200万円」を「フロー1,000万円+ストック200万円」に分解する。それだけで、次に何をすべきかが見えてくる。


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

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

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

いきなり改善に入ってはいけない

DXを始めよう、となったとき、最初に出てくる話は「原価を見える化したい」「生産計画をシステム化したい」「日報をデジタル化したい」といった改善テーマであることが多い。気持ちはわかる。目に見える成果がほしいし、経営者もそこに期待している。

しかし、改善テーマからいきなり着手すると、たいてい途中で詰まる。

データを見える化しようとしたが、そもそもどこにどんなデータがあるのかわかっていなかった。ツールを作ったが、現場との関係ができていなくて使ってもらえなかった。システムを動かし始めたら、バックアップが取れていなくて一度のトラブルで振り出しに戻った。

改善は大事だが、改善の前にやるべきことがある。 今ある状態を把握し、守る こと。ここでは「地固め」と呼ぶ。地盤が固まっていない場所に建物を建てても、傾くか崩れるかになる。

最初の一手:コミュニケーション基盤を作る

DX担当者がまず必要とするのは、現場と話せる環境になる。

以前の記事で「DXの成否は話す時間があるかどうかで決まる」と書いた。DX担当者の仕事はコードを書くことではなく、現場の言葉と技術の言葉の通訳であると。この「話す」ための基盤が、地固めの第一歩になる。

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

具体的には2つのことをやる。

1つ目は、チャットツールの導入。 以前の記事で「電話でもメールでもなくチャットがちょうどいい」と書いた。チャットは導入障壁が最も低いDXで、アカウントを作ってチャンネルを設定すれば、その日から使い始められる。

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

ただし、ここで言いたいのはツールの話だけではない。チャットを入れる本当の目的は、 DX担当者が現場と日常的にやりとりできる導線を作る こと。「何かあったらこのチャンネルに投げてください」という窓口があるだけで、現場からの相談や気づきが格段に届きやすくなる。DX担当者にとっても、わざわざ現場に足を運ばなくても軽い確認ができるようになる。

チャットと合わせて、 リモートデスクトップも用意しておくといい。 DX担当者はツールの導入やトラブル対応で、現場のPCを操作する場面が出てくる。拠点が離れていれば、そのたびに移動するわけにはいかない。電話越しに「今どの画面が出ている?」とやりとりするより、相手の画面を直接見て操作するほうが圧倒的に早い。Windows Proならリモートデスクトップ機能が標準で使える。Homeエディションや、ネットワーク構成的に標準機能では対応しにくい場合は、RustDeskのようなOSSのリモートデスクトップツールがある。

2つ目は、上長の合意を取ること。 以前の記事で「管理精度型のDXはトップダウン寄りで進める」と書いた。地固めの段階でも同じことが言える。

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

DX担当者が現場を回ってデータの棚卸しや業務のヒアリングをする時間を、上長が「仕事」として認めてくれるかどうか。ここが確保されないと、「早くツールを作れ」というプレッシャーの中で、地固めを飛ばして改善に走ることになる。

この2つは順番というより同時に進める話で、チャットを入れるタイミングで上長に「まず現状を把握する時間をください」と合意を取っておく。DX担当者としてのポジショニング——「この人はまず現場を見て、そこから判断する人だ」——を最初に示しておくことが、後の仕事をやりやすくする。

二手目:現状を把握する

コミュニケーション基盤ができたら、次は現状把握になる。やることは2つあるが、実際には同時にやれる。

データの棚卸し。 社内のどこに、どんなデータが、どの形式で存在しているかを把握する。見積データはExcelで営業が持っている。受注データは会計ソフトにある。図面はファイルサーバーの中。検査記録は紙で現場に置いてある。個人PCのデスクトップにしか存在しないExcelもある。

この棚卸しは、後でデータの文法を整えたり見える化を進めたりするための地図になる。地図なしに改善を始めると、「あのデータがあると思っていたのになかった」「同じデータが3箇所に別々の形式で存在していた」という事態になる。

属人化のトリアージ。 以前の記事で「脱属人化ではなく属人化のトリアージ」と書いた。致命的リスク、深刻なリスク、軽微なリスクの3段階で仕分ける方法になる。

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

この2つは別々にやる必要がない。データの棚卸しをすれば、自然と属人化リスクが見えてくる。

「この見積ロジックは○○さんの頭の中にしかない」——データの棚卸しで見積データの所在を確認していたら、ロジックが属人化していることがわかった。「このExcelは△△さんしか触れない」——ファイルの管理者を確認していたら、特定の人にしかわからない業務が見つかった。「サーバーのパスワードは□□さんしか知らない」——IT環境の棚卸しで致命的リスクが見つかった。

データがどこにあるかを調べる過程で、「誰がそれを握っているか」が見える。属人化のトリアージとデータの棚卸しは、同じ作業の2つの側面になる。

棚卸しの結果は、簡単なリストでいい。どこに何があって、誰が管理していて、なくなったらどれくらい困るか。完璧な文書を作る必要はない。ざっくりでも把握できていれば、次の手が打てる。

三手目:現状を守る

棚卸しで見えたものを、次は守る。

以前の記事で「セキュリティは守り方より戻し方」と書いた。防御を完璧にすることはできない。大事なのは、何かが起きたときに戻せる状態にしておくことになる。

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

棚卸しの結果を見れば、何を守るべきかは見えている。

バックアップの確認。 サーバーのバックアップは取れているか。それは本番環境と切り離された場所に保管されているか。復元テストをやったことがあるか。個人PCにしかない重要データはないか。以前の記事で書いたように、バックアップは「ある・なし」ではなく「どこにあるか」が問題になる。

致命的リスクの解消。 棚卸しで見つかった致命的リスク——パスワードが1人しか知らない、サーバー構成を誰も把握していない——を最優先で対処する。文書化するだけでいい。高度なシステムは不要で、パスワード管理の台帳を作る、構成図を1枚書く、それだけで致命的リスクは解消できる。

この段階でやることは地味で、成果物として見せにくい。「バックアップを確認しました」「パスワードを文書化しました」では、経営者へのアピールにはならないだろう。しかし、これをやっていないまま改善を進めた場合のリスクは大きい。サーバーが壊れてデータが飛んだ、担当者が急に辞めて業務が止まった——このどちらかが起きたとき、地固めの価値がわかる。

地固めが終わってから、改善に入る

ここまでの3手を整理する。

手順 やること 目的
一手目 チャット導入+上長の合意 話せる環境と、動ける時間を確保する
二手目 データの棚卸し+属人化トリアージ 今あるものを把握する
三手目 バックアップ確認+致命的リスクの解消 今あるものを守る

この3手の間、新しいツールは1つも作っていない。業務フローも変えていない。やったのは、コミュニケーションの基盤を作り、現状を把握し、守っただけになる。

しかしこの地固めが終わると、改善の土台が整っている。

  • どこにどんなデータがあるか把握できている → データの文法の整理に着手できる
  • 属人化リスクが仕分けられている → 何から手をつけるかの優先順位が見えている
  • バックアップが確保されている → 新しい仕組みを試しても、壊れたら戻せる安心感がある
  • 現場との関係ができている → ツールを作ったときに使ってもらえる

改善の具体的な進め方——データの文法をどう整えるか、見える化をどこから始めるか、VBAで作るか専用言語で作るか——は、このシリーズの他の記事で書いている。地固めが終わった段階で、自社の状況に合った記事を参照してほしい。

「地味」がDXの最初の仕事

DXと聞いて期待するのは、ダッシュボード、自動化、AI活用——そういう派手な絵面かもしれない。しかし、中小製造業のDXで最初にやるべきことは、驚くほど地味になる。チャットを入れる。データがどこにあるか調べる。バックアップを確認する。パスワードを文書化する。

地味だが、これを飛ばして改善に入った会社は、どこかで足元をすくわれる。データが消える、担当者がいなくなる、現場が協力してくれない。改善の前に地固めをしていれば防げたことばかりになる。

以前の記事で「手作業でできることしかシステムにできない」と書いた。同じように、 把握していないものは改善できない 。まず知る、守る、その後に変える。この順番を守ることが、中小製造業のDXを確実に進める最初の一歩になる。

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


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

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