テックメモ

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の具体的な未来予測はどうでもいい ── それでも中小製造業が今から触るべき理由

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

• AIの具体的な未来予測はどうでもいい ── それでも中小製造業が今から触るべき理由
• 内製DXの開発にAIを使う ── VBAでも「AIに書かせる設計」はできる
• 中小製造業の内製DXと外注の線引き ──「自社固有」か「汎用」かで決める
• 中小製造業の内製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担当者に限らず、中小製造業で仕事をしていると、前例がない判断を求められる場面は多い。そのとき「こういうときはこう考える」という軸を自分の中に持っておくことが、仕事を進める上での地盤になる。

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

• 中小製造業のIT環境は「入れ替えられる設計」で組む ── OSSとSaaSの使い分け
• 中小製造業は「脱属人化」ではなく「属人化のトリアージ」
• 中小製造業の内製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%防げるわけではない。防御を固めても、すり抜けはゼロにならない。

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

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

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

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

• 中小製造業のセキュリティは「守り方」より「戻し方」 ── バックアップを自分で握る
• 中小製造業の内製DXと外注の線引き ──「自社固有」か「汎用」かで決める
• 中小製造業のIT環境は「入れ替えられる設計」で組む ── OSSとSaaSの使い分け

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

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

以前の記事で、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を常時起動してタスクスケジューラを設定する必要がある。

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

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のほうが合う場合もある。道具の選択は、技術の優劣ではなく、自分たちの働き方に合っているかどうかで決めるべきものになる。

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

• 中小製造業に Google Workspace は必要か
• 中小製造業の内製DX ── Excel VBAで済む領域と、専用言語で作るべき領域
• 中小製造業のIT環境は「入れ替えられる設計」で組む ── OSSとSaaSの使い分け

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

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に書かせる設計」はできる
• 中小製造業のExcel業務が「1シート」で止まる理由 ── 関数の限界と次の一歩
• 中小製造業の内製DX ── Excel VBAで済む領域と、専用言語で作るべき領域

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

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の中だけで使う内部的な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の具体的な未来予測はどうでもいい ── それでも中小製造業が今から触るべき理由

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

• AIの具体的な未来予測はどうでもいい ── それでも中小製造業が今から触るべき理由
• 中小製造業の内製DX ── Excel VBAで済む領域と、専用言語で作るべき領域
• 中小製造業のExcel業務が「1シート」で止まる理由 ── 関数の限界と次の一歩

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

合計は同じ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の正しい順番

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

• 中小製造業の内製DX ── 成否は「話す時間」があるかどうかで決まる
• 中小製造業は「脱属人化」ではなく「属人化のトリアージ」
• 中小製造業のセキュリティは「守り方」より「戻し方」
• 中小製造業の社内連絡は、メールでも電話でもなくチャットがちょうどいい

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

「とりあえずデータを集めよう」が失敗する理由

内製DXを始めると、「まず現場のデータを集めよう」という話になりやすい。作業日報をデジタル化する、検査結果を記録する、設備の稼働時間を取る。方向としては間違っていない。しかし、「何のために集めるか」が曖昧なまま始めると、集めたデータが使われないまま終わることが多い。

作業日報を毎日入力してもらっているのに、誰もそのデータを見ていない。検査結果をExcelに記録しているのに、集計したことがない。こういう状態は珍しくない。現場からすれば「入力しているのに何に使われているかわからない」となり、次第に入力が雑になるか、やめてしまう。

データ収集が続かない原因は、現場のやる気や入力ツールの問題ではなく、集める目的が設計されていないことにある。

集める前に「何と比較するか」を決める

以前の記事で「見える化の本質は基準と実績の突合」だと書いた。数字は1つでは意味がない。見積もりと実績原価を比較して初めてズレが見える。予定納期と実際の出荷日を比較して初めて遅れが見える。

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

実績データの収集も、この原則から逆算して設計するのが筋になる。先に「何と比較するか」を決めて、比較に必要なデータだけを集める。

たとえば、見積もりの想定工数と実際にかかった工数を比較したいなら、集めるべきは工程ごとの作業時間になる。予定納期と出荷実績を比較したいなら、各工程の完了日時が必要になる。品質基準と実測値を比較したいなら、検査結果の数値が要る。

比較対象が決まれば、何を・どの粒度で集めるかが自動的に決まる。逆に比較対象が決まっていなければ、「念のためこれも」「あれもあったほうがいいかも」と項目が膨らみ、入力負担だけが増えていく。

以前の記事で「管理側の欲を削る」と書いたが、データ収集の項目設計でもまったく同じことが起きる。管理側が「せっかくだからこの項目も」と追加するたびに、現場の入力負担が増える。比較対象から逆算すれば、この欲を削る根拠ができる。「この項目は何と比較するんですか？」と問えば、答えられない項目は削れる。

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

社外の要求と社内の改善は分けて考える

データ収集にはもう一つの目的がある。顧客の要求や法規制、会計上の義務など、社外から求められるデータの記録になる。

トレーサビリティの記録は顧客や業界規格が要求するもので、「何と比較するか」の問題ではない。求められた条件を満たす形で記録する。会計上の仕入・売上データも同じで、法律で決められた形式に従って残す必要がある。

この2つは性質が違う。

• 社外要求のデータ収集 → 条件が決まっている。条件を満たすように集めればいい
• 社内改善のためのデータ収集 → 何と比較するかを自分で決める必要がある

混同すると設計が崩れる。社外要求を満たすために集めているデータと、社内改善のために集めるデータを、同じ入力フォームに詰め込んで「全部入力してください」とやると、どちらの目的も中途半端になる。

まず社外要求のデータ収集は仕組みとして確実に回す。その上で、社内改善のために何を追加で集めるかを、比較対象から逆算して決める。この順番が大事になる。

入力は1回で完結させる

何を集めるかが決まったら、次は「どう集めるか」の話になる。

最初に押さえるべき原則は、入力は1回で完結させる こと。紙に書いてもらって、それを別の人がExcelやシステムに打ち直す——この二重入力は、手間が倍になるだけでなく、転記ミスの原因になる。

以前の記事で内製DXの弱点として「つなぎ目」の問題を書いた。紙からデジタルへの転記は、まさにこのつなぎ目になる。人の手で転記するたびに、数字の読み間違い、入力漏れ、コピー先の間違いが起きる。データの信頼性が下がれば、せっかく集めたデータで比較しても意味がなくなる。

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

「でも現場ではPCを使えない」という反論はあるだろう。それは次の話になる。

発生源の近くで、作業の切れ目に入力する

以前の記事で、タブレットを現場に持ち込んだが定着しなかった経験を書いた。手が汚れる、壊れる、作業のリズムが崩れる。最終的に紙に戻した。

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

そのときの結論は、固定PCを工場内の複数箇所に設置し、作業の切れ目で入力してもらう という方法だった。

ポイントは2つある。

1つ目は 「発生源の近くで入力する」 ということ。事務所に戻ってから入力する方式だと、記憶に頼ることになり、入力漏れや曖昧な数字が増える。現場の近くに入力場所があれば、作業直後に記録できる。

2つ目は 「作業の切れ目に入力する」 ということ。作業中に手を止めて入力させるのは現実的ではない。休憩前、段取り替えのとき、1ロット完了時——作業の自然な区切りを入力タイミングにする。リアルタイム性は多少落ちるが、作業のリズムを崩さないほうがデータは確実に残る。

入力のタイミングと場所は、事務所の人と現場の人で違う。事務所ならPCの前に座っているから、発生したタイミングですぐ入力できる。現場は作業の都合があるから、導線——つまり「どの動きの中で入力するか」——を設計する必要がある。この設計を省くと、「入力する暇がない」が常態化して、データが欠ける。

選択式にする手間は十分見返りがある

入力項目を決めたら、次に考えるのは入力方式になる。ここで強く勧めたいのが、できるだけ選択式にする こと。

自由入力にすると表記揺れが起きる。「SUS304」「sus304」「ステンレス304」「SUS 304」。人によって書き方が違う。後からデータを集計しようとしたとき、同じものなのに別のものとしてカウントされる。これは入力した人の問題ではなく、自由入力を許した設計の問題になる。

選択式にすれば、表記揺れはゼロになる。入力も速くなる。文字を打つより選ぶほうが早いし、入力ミスも起きない。

「でも選択肢を作るにはマスタ整備が必要で、それが大変」と思うかもしれない。しかし、完璧なマスタデータベースを用意する必要はない。

たとえば、ある帳票にすでにデータが入っているなら、そのデータをマクロで書き出してテキストファイルにし、それを選択肢のデータソースに使えばいい。見積書に品名の一覧があるなら、それを書き出すだけで品名の選択リストになる。以前の記事で「見積データを簡易マスタとして再利用する」と書いたが、考え方は同じで、今あるデータから選択肢は作れる。

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

選択式の導入には多少の手間がかかる。選択肢のデータを用意し、更新する仕組みも必要になる。しかし、この手間は十分に見返りがある。集めたデータが正確で集計可能な状態になるか、表記揺れだらけで使えないデータになるかの分かれ目になる。

インターフェースは「続けられるもの」を選ぶ

入力のインターフェースも重要になる。

PCならアプリケーションの画面を作るのが素直な方法で、入力フォーム・選択式・入力補完など、操作性を作り込める。以前の記事で書いた3層モデルで言えば、VBAで作る範囲のものから、C#やPythonで作るものまで、規模に応じて選べばいい。

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

ただし、専用の入力画面を作ることだけが選択肢ではない。たとえばチャットから定型フォーマットで送信して登録する方法もある。社内のチャットツールをすでに使っているなら、新しい入力画面を覚えてもらうより、普段使い慣れている環境で入力できるほうが定着しやすいこともある。

大事なのは、使う人が「面倒だからやめた」とならないインターフェース を選ぶこと。以前の記事で「工数がプラマイゼロのラインに抑える」と書いたが、入力インターフェースの選定でも同じ基準が使える。今のやり方（紙への記入、口頭での報告）と比べて、手間が増えないか、できれば減るか。この基準で選ぶ。

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

技術的に優れたインターフェースと、現場で続くインターフェースは違うことがある。最先端のWebアプリを作っても、現場の人が使いこなせなければ意味がない。見た目より操作のしやすさ、機能の多さより迷わなさ。入力する人の目線で設計する。

まとめ：集める前に決めること

実績データの収集を始める前に決めるべきことを整理する。

1. 何と比較するか。 比較対象（基準）を先に決める。基準がなければデータを集めても使い道がない
2. 何を集めるか。 比較に必要な項目だけに絞る。「念のため」の項目は入れない
3. いつ・どこで入力するか。 発生源の近くで、作業の切れ目に。入力の導線を設計する
4. どう入力するか。 入力は1回で完結させる。できるだけ選択式にする
5. 何で入力するか。 現場が続けられるインターフェースを選ぶ

この順番が大事になる。5から考え始めると——つまり「タブレットを入れよう」「日報アプリを導入しよう」とツールから入ると——1〜4が曖昧なまま進んで、集めたデータが使われない結果になりやすい。

データ収集は地味な作業になる。しかし、基準と実績の突合ができなければ、原価改善も納期短縮も品質管理も、すべて勘と経験頼りのままになる。逆に言えば、比較できるデータが1つでも揃えば、そこから改善のループが回り始める。まず1つ、最も効果が出やすい比較対象を決めて、そのデータだけを集めるところから始めればいい。

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

• 中小製造業の見える化は「基準と実績の突合」── 数字は比較して初めて意味を持つ
• 中小製造業の現場にタブレットを配っても定着しない ── 入力は「いつ・どこで」を設計する
• 中小製造業の内製DXには「管理精度型」と「工数削減型」がある

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

案件のファイルをもっと早く開きたい

共有フォルダに年度別や部署別でフォルダを分けて、ファイルを管理している会社は多い。普通に運用できている会社がほとんどだと思う。

ただ、受注生産で案件数が多くなってくると、「あの案件の図面どこだっけ」と探す場面が増えてくる。年度フォルダの中を開いて、顧客名で探して、その中のファイルを確認して——という手順を毎回やるのは地味に手間がかかる。

自分が現場で試して効果があったのが、製造番号（受注番号）をキーにしたフォルダ構成になる。これは既存のフォルダ管理を置き換えるというより、案件単位でファイルをまとめる仕組みを一つ加えるという話。

製造番号でフォルダを切る

受注生産の中小製造業なら、最もシンプルで効果的な方法がある。製造番号（または受注番号）でフォルダを作ること。

製造番号がわかれば、その案件に関するファイルはすべて一つのフォルダに入っている。図面も見積書も検査記録も発注書も、案件単位でまとまっている。

「あの案件の図面どこ？」→ 製造番号で開く → ある。これだけで、ファイルを探す時間の大半がなくなる。

フォルダ構造がデータベースの役割を果たす

この方法が効くのは、フォルダ構造自体が案件をキーにしたデータベースになっているからになる。

以前の記事で「受注生産のデータは見積番号から始める」と書いた。データベースでいえば、見積番号や製造番号が主キーで、それに紐づくデータ（図面、見積、検査記録）がぶら下がっている。フォルダ構造でも同じことができる。製造番号がフォルダ名、その中のファイルが紐づくデータ。

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

普通のデータベースと違うのは、誰でもエクスプローラーで開けるということ。特別なソフトがなくても、フォルダをたどれば必要なファイルにたどり着ける。

ソフトからも一発で開ける

ここからが実用的な話になる。フォルダを製造番号で切っておくと、業務ソフトとの連携が簡単にできる。

自分が実際にやった方法はこうなる。業務管理のソフトに「フォルダを開く」ボタンを付ける。ボタンを押すと、今見ている案件の製造番号に対応するフォルダが自動で開く。ソフトの中にはファイルを保存しない。あくまで普通のフォルダにあるファイルへの入口を提供するだけ。

Excel VBAでも同じことができる。セルに製造番号が入っていれば、VBAでパスを組み立ててエクスプローラーで開く。数行のコードで済む。

この設計のポイントは、ソフトはファイルへの便利な入口であって、ファイルの保管場所ではないということ。ソフトが壊れても、ファイルはフォルダにそのまま残っている。ソフトを入れ替えても、ファイルは影響を受けない。

ファイルをソフトに閉じ込めない

生産管理システムや文書管理システムの中には、ファイルをシステム内部に格納するものがある。登録したファイルはシステムからしかアクセスできない。

管理の観点からは正しい。勝手にファイルを移動されたり消されたりしない。バージョン管理もシステムが担う。大企業ならこの方が安全だろう。

しかし中小製造業では、これがリスクになることがある。

• システムが止まるとファイルにアクセスできない。 サーバーが故障したら図面が見られない。業務が止まる
• システムを入れ替えるとき、ファイルの移行が大変。 データのエクスポート機能がなければ、ファイルを取り出すだけで一仕事になる
• 業者に依存する。 ファイルの取り出しに業者の協力が必要になると、以前の記事で書いた「知識のロックイン」と同じ構造が生まれる

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

以前の記事で「入れ替えられる設計」の重要性を書いた。ファイル管理でも同じ原則が当てはまる。ファイルは普通のフォルダに、普通のファイルとして置いておく。 ソフトはそこへの便利な入口を提供するだけ。こうしておけば、ソフトが変わってもファイルは残る。

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

バックアップも楽になる

ファイルが普通のフォルダにあるということは、バックアップも単純になる。フォルダごとコピーすればいい。

以前の記事でバックアップの重要性を書いた。ファイルがシステム内部に格納されていると、バックアップにはシステムのエクスポート機能やデータベースのバックアップが必要になる。フォルダにあるなら、フォルダごと外付けHDDにコピーするだけで済む。

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

個人フォルダは残していい

共有フォルダの中に個人名のフォルダがある会社は多い。「田中」「鈴木」のようなフォルダに、それぞれが自分のファイルを入れている。

これを「属人化だからやめるべき」と言う人もいるが、個人フォルダは使いやすい。自分のファイルの置き場所がはっきりしているし、作業中のファイルを他の人に触られる心配もない。無理になくす必要はないと思っている。

ただし、案件の成果物が個人フォルダにしかない状態は避けたい。図面の最終版、提出した見積書、検査成績書。これらは案件に紐づく共有のファイルであって、個人のものではない。担当者が異動や退職したときに、案件のファイルが見つからないという事態になる。

以前の記事で「属人化のトリアージ」について書いた。ファイル管理でも同じ考え方が使える。個人の作業ファイルは個人フォルダに、案件の成果物は製造番号フォルダに。この使い分けだけ守れば、個人フォルダはそのまま残していい。

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

フォルダ整理のルールは最小限でいい

製造番号でフォルダを切る。案件に関するファイルはそのフォルダに入れる。この2つだけ守れば、細かい命名規則やサブフォルダのルールは最小限でいい。

現場のルールは少ないほど守られる。「製造番号のフォルダに入れてくれ」は守れる。「ファイル名は日付＋版数＋担当者名で、サブフォルダは種類別に分けて、命名はキャメルケースで」は守られない。

運用で大事なのは、新しい案件が発生したときにフォルダを自動で作る仕組みを入れておくこと。手動で作ると忘れるし、名前の揺れが出る。受注登録のタイミングでフォルダを自動生成するだけで、構造の一貫性が保てる。

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

• 中小製造業のIT環境は「入れ替えられる設計」で組む ── OSSとSaaSの使い分け
• 中小製造業のセキュリティは「守り方」より「戻し方」
• 中小製造業の内製DXと外注の線引き ──「自社固有」か「汎用」かで決める

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