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

システム化の依頼が来たら、まず疑うこと

内製DXを進めていると、社内からシステム化の依頼が出てくる。「この週報をExcelじゃなくてシステムで入力できるようにしてほしい」「この集計作業を自動化してほしい」。

依頼が来たら作る。それが内製DX担当者の仕事に見える。しかし、ここで一つ立ち止まって考えるべきことがある。

その業務は、そもそも必要なのか。

以前の記事で、内製DXには「管理精度型」と「工数削減型」の2つがあると書いた。管理精度型は見えないものを見える化する。工数削減型は手間を減らす。どちらも「業務が存在する」ことを前提にした改善になる。

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

しかし実際の現場には、存在自体が疑わしい業務がある。ここに手を入れるのが第三の選択肢、「廃止型」 になる。

誰も見ていない資料が作られ続ける構造

中小製造業の現場で、こういう光景は珍しくない。

  • 毎週作成される週報。上司は読んでいない
  • 月次で集計される実績表。会議資料に載るが、その数字について議論されたことがない
  • 日報を全員に書かせているが、集計も分析もされずフォルダに溜まっていく
  • 「前任者がやっていたから」という理由だけで続いている帳票

これらは、始まった当初には目的があったはず。しかし目的が形骸化しても、作業だけが慣性で残る。やめるきっかけがないから続いている。誰かが「これ要りますか?」と聞かない限り、止まらない。

そしてここに「この資料の作成をシステム化してほしい」という依頼が来る。システム化すれば作成の手間は減る。しかし、誰も見ていない資料の作成が楽になっただけで、無駄がデジタルに移っただけになる。

プロセス改善がいちばん効く場合がある

ツールを作って業務を効率化するのが内製DXの仕事だと思いがちだが、業務プロセスそのものを見直すほうが効果が大きいケースは多い

たとえば、ある帳票の作成に毎週2時間かかっているとする。これをシステム化して30分に短縮すれば、週1.5時間の削減になる。しかし、その帳票が実は不要だったとわかれば、削減効果は週2時間。しかもシステムを作る工数がゼロになる。

作るより、やめるほうが速い。

もちろん、すべての業務を疑い始めたら何も進まない。しかし少なくとも「システム化してほしい」という依頼が来たとき、作り始める前にその業務の目的と利用実態を確認する工程を挟むだけで、無駄なシステムを作るリスクを大幅に減らせる。

ただし、DX担当者1人では「やめる」は決められない

ここが現実の壁になる。

「この資料、誰が見ていますか?」は正論だが、依頼してきた上司や他部門に対して、DX担当者の立場からは聞きにくい。特に中小企業では、DX担当者が若手だったり兼任だったりして、業務の要否を問える位置にいないことが多い。

「やめましょう」と提案するのは、その業務を続けてきた人の仕事を否定するように聞こえかねない。正しいことを言っていても、組織の中では通らないことがある。

だから廃止型のDXは、DX担当者単独ではできない。経営者の協力が必要になる。

経営者の役割は「やめていい」と言うこと

内製DXにおける経営者の役割は、予算を出すことだけではない。管理精度型であれば「何を見たいか」を決める。工数削減型であれば「何を優先するか」を決める。

廃止型では、経営者の役割は 「やめていい」と言うこと になる。

DX担当者が「この帳票、システム化の前に利用状況を確認したいのですが」と聞ける空気を作る。確認した結果「実は誰も使っていない」とわかったとき、「じゃあやめよう」と判断を下す。この判断はDX担当者にはできない。業務を廃止する権限を持っているのは経営者だけになる。

逆に言えば、経営者が「やめていい」と言えない組織では、廃止型のDXは機能しない。不要な業務がシステム化され、無駄が効率よく回り続ける。

そしてもう一つ、経営者自身が気をつけるべきことがある。以前の記事で、管理精度の向上は経営者の判断力を引き上げる「武器」だと書いた。これは正しいが、武器は多ければ多いほどいい、とはならない。

管理精度の天井は、経営者の判断力で決まる

経営者が「あれも見たい、これも把握したい」と求めると、その分だけ現場の入力負荷が増え、DX担当者の開発負荷が増え、管理帳票が増える。武器を増やしすぎた結果、どの数字も中途半端にしか見ない状態になれば、武器を持っていないのと同じになる。

廃止型DXの対象は、現場が惰性で続けている業務だけではない。経営者自身が過去に「見たい」と言って作らせた管理帳票も含まれる。かつて必要だと思って作らせたが、今は見ていない。しかし自分が頼んだ手前、やめようとは言い出しにくい。こうして経営者側からも不要な業務が生まれ続ける。

本当に使う武器だけを手元に残す。それは現場に「やめていい」と言うのと同じかそれ以上に、勇気が要ることかもしれない。

「やめていいか」を確認する方法

とはいえ、経営者もすべての業務の利用実態を把握しているわけではない。DX担当者側から判断材料を出す必要がある。ここは角の立たない形で確認する方法がある。

要件定義として聞く:

システム化の依頼が来たとき、作り始める前に確認するのは当たり前のことになる。「この資料は誰がいつ、どういう判断に使っていますか?」は、要件定義として自然な質問であり、業務の要否を問うているようには聞こえない。

この質問に明確な答えが返ってこない場合、その業務は形骸化している可能性が高い。

データで確認する:

ファイルサーバーに置かれている資料であれば、最終アクセス日時を確認できる。半年間誰も開いていないファイルがあれば、それは事実として示せる。人に「見ていますか?」と聞くと角が立つが、データが示す事実に対しては反論しにくい。

どちらの方法も、DX担当者が「この業務は不要です」と言っているのではなく、事実を集めて経営者に判断材料を渡しているだけになる。判断するのは経営者。DX担当者の仕事は、判断できる材料を揃えることになる。

DXは1人では回らない

このシリーズでは、内製エンジニアがAIを活用して社内ツールを高速開発するアプローチを繰り返し勧めてきた。しかし内製DXは、技術だけで完結する話ではない。

管理精度型のDXでは、経営者が「何を見たいか」を決めなければ設計できない。廃止型のDXでは、経営者が「やめていい」と判断しなければ動けない。工数削減型ですら、現場の協力がなければ定着しない。

DX担当者は道具を作れる。しかし、何を作るか、何をやめるかの判断は、経営者と一緒にやるしかない。内製DXの成否を分けるのは、技術力よりも、経営者とDX担当者が同じ目線で業務を見られる関係があるかどうかになる。

新しいツールを作る前に、まず今ある業務を一緒に眺めてみる。「これは何のためにやっているんだっけ?」と問い直す。その結果やめられる業務が見つかれば、それはシステムを1本作るより大きな成果になることがある。作ることだけがDXではない。やめることもDXになる。


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

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

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

「AIで○○が自動化される」は、当たるかどうかわからない

AIに関する予測は毎月のように出てくる。プログラミングは自動化される、設計はAIがやる、営業メールは全部AIが書く、工場の検査は画像認識に置き換わる。

こうした具体的な予測が当たるかどうかは、正直わからない。5年前に「RAGで社内ナレッジが自在に引き出せる」と言われていたが、以前の記事で書いた通り、現時点でそれが中小企業の現場で安定して動いているケースは少ない。一方で、コード生成のように予想以上に早く実用化した領域もある。

中小製造業がAI・RAGと付き合うための現実的な整理

個別の予測は外れることも多い。「来年にはこれが自動化される」という話に一喜一憂しても仕方がない。

ただし、大局は決まっている

個別の予測は当てにならないが、大きな方向は決まっている。AIは今後、電気やインターネットと同じレベルのインフラになる。 これはもう予測ではなく、既定路線と言っていい。

PCが普及した1990年代を思い出すとわかりやすい。当時「PCで何ができるか」の具体的な予測は玉石混交だった。「紙はなくなる」と言われたが紙はまだある。「全員がプログラマーになる」とも言われたがそうはなっていない。しかし「PCが業務インフラになる」という大局だけは完全に当たった。今、PCが使えない会社は存在できない。

インターネットも同じだった。「ネットで何が変わるか」の個別予測は外れだらけだったが、「ネットが前提になる」という大局は不可逆だった。

AIも同じ構造をたどっている。「AIで具体的に何が自動化されるか」の予測に振り回される必要はない。しかし「AIがインフラになる」という大局に対して準備しない、という選択肢はない。

「成果が出てから始める」では遅い

中小企業の経営者が慎重になるのは理解できる。限られた予算と人手の中で、成果が見えないものに投資するのはリスクに感じる。「もう少し事例が出てから考える」というのは、一見合理的な判断に見える。

しかしインフラの転換期において、この判断は裏目に出ることが多い。

PCの導入も、早い段階で触り始めた会社と、「ウチにはまだ早い」と様子を見ていた会社で、数年後に大きな差がついた。差がついたのは、PC自体の性能ではなく、組織がPCを使いこなすまでの学習時間があったかどうかだった。

AIも同じことが起きる。ツールの性能は日進月歩で上がっていくが、組織がAIを使いこなすための学習は一朝一夕にはいかない。「何を聞けばいいかわからない」「どの業務に使えるかピンとこない」——これは触って試して失敗して、初めて超えられる壁になる。成果が出てから始めようとしても、その時点では学習期間を経た他社との差がすでに開いている。

全社員に配っても使われない問題

以前の記事で、「全社員にAIツールを配る」アプローチはPCスキルのばらつきや「何を聞けばいいかわからない」という壁があると書いた。この状況は現時点でも大きくは変わっていない。

中小製造業がAI・RAGと付き合うための現実的な整理

実際、ChatGPT EnterpriseやMicrosoft Copilotを全社展開した企業でも、継続的に使い込んでいるのは全体の1〜2割で、残りは数週間で使わなくなるという話はよく聞く。短期のROIで測れば、全社員分のライセンス費用に見合っていないと評価されてもおかしくない。

しかし、これを「失敗」と見るかどうかは、何を期待していたかによる。

全社員が即座にAIを使いこなして生産性が上がる——そう期待していたなら確かに失敗になる。しかし、組織としてAIに触れ始める最初の一歩——そう位置づけるなら、使わなくなった8割も含めて「AIというものが存在する」という認識が社内に共有されたこと自体に意味がある。

挑戦自体が資産になる

中小製造業がAIに取り組む価値は、今すぐの成果ではなく挑戦の過程で組織に蓄積されるものにある。

  • AIに何を聞けば使えるのか、何を聞いても無駄なのかの肌感覚
  • 自社の業務のうち、どこにAIが効きそうで、どこには効かないかの見極め
  • 「AIを使う」という行為への心理的なハードルの低下

これらは導入事例を読んだだけでは得られない。自分たちで触って、うまくいかない経験も含めて初めて身につく。

以前の記事で、内製DXは内製エンジニアがAIを活用して社内システムを高速開発するアプローチが最も効果的だと書いた。この考えは変わっていない。ただし、内製エンジニア以外の社員がAIに触れること自体を否定しているわけではない。全社員の生産性が即座に上がることを期待するのではなく、組織全体がAIに慣れるプロセスに投資していると捉えれば、短期の利用率の低さは問題にならない。

中小製造業がAI・RAGと付き合うための現実的な整理

環境を与えるコストは思ったほど高くない

AIツールのライセンスは月額数千円程度。社員一人あたりの人件費と比べれば誤差の範囲になる。1〜2割しか使わなかったとしても、その1〜2割が月に数時間分の作業を効率化すれば、十分に元は取れる計算になる。

合わせて意識したいのがPCのスペック。AIツールに限った話ではないが、メモリ不足でExcelが固まる、ブラウザのタブを開くたびに動作が重くなる——こうした環境では、そもそも新しいツールを試す気が起きない。SSDと十分なメモリを積んだPCは、体感の待ち時間を減らすだけでなく、「ちょっと試してみるか」という心理的なハードルも下げる。

AIツールの月額数千円とPCの数万円の差額をケチるよりも、社員が新しい道具に触れやすい環境を整えるほうが、長期的にはリターンが大きい。

AIは「改善」ではなく「変化」、ただし土台がなければ乗れない

業務改善には2種類ある。今あるやり方をより良くする「改善」(1→2)と、やり方そのものが変わる「変化」(1→A)になる。

このシリーズでやってきたのは、ほとんどが「改善」にあたる。Excelのデータの持ち方を正す、紐づけのキーを入れる、見積番号と受注番号をつなげる。どれも今の業務の延長線上で、やり方の根本は変わっていない。

一方、AIの登場は「変化」の側にある。同じ作業を速くやるだけではなく、誰が何をできるかのルール自体が変わる。コードを書ける人の裾野が変わる。今まで人手でやるしかなかった判断の一部が委譲できるようになる。これは改善の延長にはない、ルールの変更になる。

しかし、変化に乗るには土台が要る。

AIにデータを読ませたくても、データが整っていなければ読ませるものがない。AIで業務を自動化したくても、業務プロセスが整理されていなければ何を自動化すべきかわからない。AIを活用できる内製エンジニアがいても、現場との信頼関係がなければツールは使われない。

このシリーズで書いてきたデータの文法、紐づけの設計、プロセスの見直し、現場とのコミュニケーション——これらは地味な改善の話だが、同時にAIという変化に乗るための土台づくりでもある。改善を飛ばして変化には行けない。 逆に、改善だけやっていて変化を見ないと、気づいたときにはルールが変わった世界に取り残される。

両方が要る。地味な改善で足元を固めながら、AIという変化の方向を見ておく。どちらか片方では足りない。

具体的な予測ではなく、構えを取る

「AIで何ができるようになるか」の具体的な予測を追いかけるのは、情報収集としては面白いが、経営判断の根拠にはしにくい。予測が当たるかどうかに賭けるのはギャンブルになる。

代わりに取るべきは、AIがインフラ化したときに対応できる組織の構えを今から作っておくことになる。

具体的には、このシリーズで繰り返し書いてきたことと変わらない。

  • データの持ち方を正しくしておく(AIが活用できるデータの土台)
  • 内製エンジニアを育て、AIを開発の加速に使う(最も確実にROIが出る領域)
  • 社員がAIに触れる機会を作る(学習コストは早く払うほど安い)

AIの進化は速いが、だからといって「最新のAIが出てから考える」のでは永遠に始められない。今の時点で完璧なAI活用戦略を立てる必要はない。むしろ、完璧な戦略が立てられないからこそ、小さく始めて試行錯誤する。その試行錯誤の蓄積こそが、数年後にインフラ化したAIを使いこなすための土台になる。

予測に乗るのではなく、構えを取る。それが、中小製造業にとって最も現実的なAIとの付き合い方になる。


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

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

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

数字を単体で見せることの危うさ

内製DXで社内のデータを可視化する場面が増えてくると、「この数字を見えるようにしてほしい」という依頼が出てくる。売上推移、原価率、在庫金額、不良件数。それぞれの数字を出すこと自体は難しくない。

しかし、数字を単体で見せると判断を誤ることがある。

原価率が下がっていれば「改善した」と見える。在庫金額が増えていれば「資産が増えた」と見える。どちらも単体では正しい読み方に見えるが、この2つを並べると、まったく違う景色が見えてくることがある。

内製DXの担当者は、データを経営者に渡す立場にいる。会計の専門家である必要はないが、渡す数字が単体で見ると誤解を招く構造になっていないかは知っておく必要がある。今回は在庫と原価という、中小製造業で最も身近で、かつ最もつなげて見るべき数字の組み合わせを取り上げる。

在庫が増えると、原価率が良くなる仕組み

会計上、売上原価は次のように計算される:

売上原価 = 期首在庫 + 当期製造コスト − 期末在庫

この式の意味するところは単純で、期末の在庫が多ければ売上原価は小さくなり、利益は大きくなる。在庫が増えただけで、売上が同じでも利益の数字が変わる。

たとえば、ある月の状況がこうだったとする:

通常月 在庫増加月
売上 1,000万円 1,000万円
期首在庫 200万円 200万円
当月製造コスト 800万円 900万円
期末在庫 200万円 350万円
売上原価 800万円 750万円
原価率 80% 75%

在庫増加月は通常月より100万円多く作っている。しかし売上は同じ。売れなかった分が在庫として150万円積み上がっている。

会計上の売上原価は「200+900-350=750万円」となり、原価率は75%。通常月より良い数字が出る。製造コストは増えているのに、原価率は改善している。

これは会計の仕組み上そうなるだけであって、実態として効率が良くなったわけではない。

DX担当者がこの構造を知っておくべき理由

この話は経理の人間なら知っている。しかしDX担当者がデータを可視化する立場になったとき、この構造を知らないまま数字を出すと危険なことが起きる。

たとえば、月次の管理レポートを作ってくれと頼まれたとする。会計ソフトから原価率を引っ張って、推移グラフを作る。3ヶ月連続で原価率が下がっている。「改善傾向です」と報告する。

しかし同じ期間に在庫が膨らんでいたら、それは改善ではなく在庫の積み増しで原価率が良く見えているだけかもしれない。このレポートを受け取った経営者が「原価は順調だ」と判断してしまえば、在庫の問題に気づくのが遅れる。

数字を出す人間が構造を知らなければ、正確な数字で経営者をミスリードすることになる。 データが間違っているのではなく、見せ方が足りない。

ちゃんとした原価計算でも起きる

全部原価計算で個別原価を管理している会社でも、同じ構造の問題が起きる。

全部原価計算では、固定費(設備の減価償却費、工場の賃料など)を生産量で割って製品に配賦する。生産量が増えれば1個あたりの固定費負担が下がるので、製品の単位原価が下がる。

  • 月産100個なら、固定費500万円 ÷ 100個 = 1個あたり5万円
  • 月産150個なら、固定費500万円 ÷ 150個 = 1個あたり約3.3万円

原価が下がった。改善が進んだ。——しかし増産した50個が売れずに在庫になっていたら、それは改善ではなく、固定費を在庫に押し込んだだけになる。

以前の記事でアワーレート方式による個別原価管理を書いた。アワーレート自体は正しい管理手法だが、生産量が増えたときに単位原価が下がる構造は同じになる。原価データだけを見ていると改善に見えるものが、在庫データと並べると実態が違うことがわかる。

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

一方で、個別原価計算をやっていない会社でも同じ罠にはまる。会計ソフトから出てくる月次の原価率だけ見ていて、「今月は原価率が下がった、いい傾向だ」と思っている。在庫と並べていないから気づかない。ある日、倉庫を見て「なんでこんなに在庫があるんだ?」となる。

ちゃんと原価を見ている会社も、なんとなく見ている会社も、在庫が増えると利益が良く見えるという同じ罠にハマる。ハマる経路が違うだけになる。

ゴールドラットが指摘した構造

この問題を最も鋭く指摘したのが、エリヤフ・ゴールドラットの『ザ・ゴール』になる。

工場の「効率」を上げろと言われる。機械を止めるな、稼働率を上げろ。稼働率を上げるためには作れるだけ作る。作った分は在庫になる。原価計算上は単位コストが下がる。帳簿上は利益が出ている。しかしキャッシュは在庫に寝ていて、実際には金が回っていない。

ゴールドラットはこの構造を「原価計算が工場の判断を狂わせる」と表現した。原価を下げるための合理的な行動(稼働率を上げる、大ロットで作る)が、在庫の山を生み、キャッシュフローを悪化させる。

「たくさん作ったほうが1個あたりのコストが安い」という感覚は、規模を問わず現場に染みついている。その感覚が正しい場面もあるが、売れる見込みのない製品を在庫として積み上げる根拠にしてはいけない。在庫は帳簿上は資産だが、実質的には回収できていないキャッシュになる。

部門ごとのKPIが全部「良好」なのに、会社全体がおかしくなる

この問題がさらに厄介なのは、各部門がそれぞれの評価指標で見ると全員「良い仕事をしている」ように見えることにある。

  • 製造部門は稼働率で評価される。機械を止めず、たくさん作っている。KPIは良好
  • 経理は原価率を見ている。生産量が増えて単位原価が下がっている。KPIは良好
  • 営業は売上で評価される。在庫の問題には関心がない。売上が立っていればKPIは良好

各部門のKPIがすべて「順調」を示しているのに、会社全体では在庫が膨らみ、キャッシュが倉庫に寝ている。部門単位の数字をいくら集めても、全体の矛盾は見えない。

これは在庫と原価に限った話ではなく、部門ごとに評価指標が分かれている組織で構造的に起きる問題になる。各部門が自分のKPIを最適化する合理的な行動を取った結果、全体では非合理な状態が生まれる。

DX担当者がデータを可視化するとき、部門ごとのレポートをそれぞれ作るだけでは、この矛盾には気づけない。部門をまたいで数字をつなげて初めて、「各部門は順調なはずなのに、なぜ全体がおかしいのか」が見える。

「つなげて見せる」のがDX担当者の仕事

ここまでの話を踏まえて、DX担当者として最低限やるべきことを整理する。

原価率も在庫金額も、会計ソフトの中にすでに存在しているデータになる。問題はこの2つが別々の帳票・画面に出てくるため、並べて見る習慣がないことにある。

月次で2つの数字を並べるだけで、見え方が変わる:

原価率 期末在庫金額
1月 78% 320万円
2月 75% 380万円
3月 73% 450万円
4月 76% 420万円

原価率が下がっているのに在庫金額が増えていたら、効率改善ではなく在庫の積み増しを疑うサインになる。逆に、原価率が上がっていても在庫が減っていれば、滞留在庫を吐き出している健全な状態かもしれない。

新しいデータを取る必要はない。すでに会計ソフトにある数字を、並べて見える形にするだけ。しかしこの「並べる」という行為こそが、データを情報に変える最小単位の仕事になる。

もう一歩踏み込むなら、在庫を品目別または製品グループ別に見て、どこに滞留があるかを把握する。ただしこれは棚卸のデータがその粒度で残っていることが前提になる。以前の記事でデータの文法について書いたが、棚卸データも「あとから分析できる形」で残していなければ、数えた事実だけがあってデータとして使えないことになる。

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

在庫と原価に限らない

今回は在庫と原価の組み合わせを取り上げたが、「1つの数字だけ見ると良く見えるのに、別の数字と並べると実態が違う」という構造は他にもある。

  • 売上が伸びているのに、入金サイトが延びていたらキャッシュは増えていない
  • 生産量が増えているのに、不良率も上がっていたら実質的な生産性は変わっていない
  • 受注件数が増えているのに、1件あたりの粗利が下がっていたら忙しくなっただけ

この「並べて見る」原則を一般化すると、見える化の本質は 基準と実績の突合 に帰着する。

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


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

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

品質管理の正体はデータ管理 ── 中小製造業のトレーサビリティと統計管理を阻むもの

品質管理の「手法」は足りている

品質管理の教科書は山ほどある。QC7つ道具、なぜなぜ分析、FMEA、SPC(統計的工程管理)。手法そのものは体系化されていて、学ぼうと思えばいくらでも学べる。

しかし中小製造業の現場で品質管理が回っていないとき、原因は手法を知らないことではない場合が多い。管理図を描きたくてもデータがない。不良の傾向を分析したくても記録が残っていない。トレーサビリティを求められても、どのロットがどの材料でいつ誰が作ったのか追えない。

品質管理の問題に見えて、実はデータ管理の問題であるケースが非常に多い。

トレーサビリティは「紐づけ」の問題

トレーサビリティとは、製品がどの材料から、どの工程を経て、いつ、誰の手で作られたかを追跡できる状態を指す。顧客からのクレーム対応、リコール時の影響範囲の特定、工程改善のための原因分析——いずれもトレーサビリティがなければ始まらない。

ここで必要なのは高度なシステムではなく、データ同士の紐づけになる。

受注番号、ロット番号、仕入先、材料ロット、工程、作業日、作業者。これらの情報がバラバラに存在していても、紐づけのキーがあれば追跡できる。逆に、どれだけ丁寧に検査記録を書いていても、紐づけのキーがなければ追跡できない。

受注番号と製品の紐づきは、規模の小さい工場でも大抵できている。受注を受けて製品を作る以上、どの注文に対して何を作ったかは自然と追える。

切れがちなのは、その先——仕入の情報との紐づけになる。どの受注の製品に、どの仕入先から、いつ届いた、どのロットの材料を使ったか。ここが結びついていないケースが非常に多い。検査成績書には「合格」と書いてあるが、使った材料のロットまでは追えない。これではクレームが入ったとき、同じ材料ロットで作った他の製品を特定できない。材料起因の不良なのか工程起因なのかの切り分けもできない。

もう一つ切れやすいポイントがある。以前の記事で、生産管理ではバッファ在庫を置いて前後工程を分断する考え方が有効だと書いた。管理の負荷を下げるには良い考え方だが、品質の追跡という観点では、このバッファ在庫が情報の断絶点になりやすい。前工程で加工された部品がバッファに入った時点で、どのロットの材料をいつ加工したものかという情報が消え、後工程ではただ「棚にある部品」として使われる。生産効率のための分断が、トレーサビリティの分断にもなってしまう。

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

ここは割り切りが要る。全部品にロット番号を貼って追跡するのは中小の体力では現実的でないことが多い。ただし、少なくともバッファ在庫に入れるタイミングで「いつの加工分か」がわかる程度の単位管理——たとえば加工日や加工週で棚を分ける、現品票に加工日を書く——をしておくだけで、問題発生時の追跡範囲は大幅に絞れる。完璧な個体追跡でなくても、「3月第2週の加工分」まで絞れれば、全数回収よりはるかにましになる。

以前の記事で、受注生産の仕入管理は受注番号を軸にした紐づけで成り立っていると書いた。品質管理のトレーサビリティもまったく同じ構造になる。受注番号を一本の串として、仕入・工程・検査・出荷のデータを通す。特別な仕組みは要らない。串になるキーが存在し、各記録にそのキーが入っていること。それだけで追跡は可能になる。

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

紙の記録が悪いのではない

誤解のないように書いておくと、紙の検査記録が悪いわけではない。中小製造業の現場で、検査のたびにPCを開いて入力するのが現実的でない場面は多い。

問題は紙かデジタルかではなく、その記録に紐づけのキーが入っているかどうかになる。

検査記録の用紙に受注番号(またはロット番号)の記入欄があり、それが確実に書かれていれば、紙の記録でもトレーサビリティは成立する。後からデジタル化したくなったときも、キーさえあれば紐づけられる。

逆に、キーのない記録を何年分積み上げても、それは「記録した」という事実があるだけで、追跡可能な品質データにはなっていない。

検査データは「社外への証明」になる

このシリーズでは、原価や負荷、仕入といった社内向けのデータ管理を中心に書いてきた。これらは自社の判断のために使うデータであり、保管方法はExcelファイルで十分だった。

しかし検査データは性質が異なる。検査成績書は顧客への品質保証の証拠であり、クレーム対応時の根拠資料であり、業種によっては法令や規格(ISO 9001など)で保管期間が定められている。社内の管理データとは違い、「あとから出せること」が要件になる

ここで問題になるのが、紙の検査記録のまま何年分もファイルキャビネットに積み上がっている状態になる。記録は存在するが、3年前の特定の受注番号の検査成績書を探そうとすると、棚を端から探すことになる。顧客から急ぎで求められたとき、見つからないのは「記録がない」のと実質同じになる。

紙で記録すること自体は問題ないと先に書いた。ただし保管については、検索できる状態を維持する必要がある。現実的な方法としては、紙の記録をスキャンしてPDFにし、ファイル名に受注番号と日付を入れて保存するだけでも十分に機能する。検索キーがファイル名に入っていれば、フォルダの中から探せる。

以前の記事で、管理精度の向上は経営者の判断力を引き上げる「武器」だと書いた。原価の見える化や負荷の可視化は、経営者が攻めの判断をするためのデータになる。

管理精度の天井は、経営者の判断力で決まる

一方、品質保証のデータは 「防具」 になる。経営者が日常的に見るものではない。しかしクレームが入ったとき、取引先の監査が来たとき、万が一リコールが必要になったとき、このデータがあるかないかで会社が受けるダメージがまったく変わる。武器と違って、防具は使わずに済むに越したことはない。しかし持っていなければ、一撃が致命傷になりかねない。

紐づけのキーと、検索可能な保管。この二つが揃っていれば、紙ベースの運用でも防具としての機能は果たせる。

統計的品質管理はデータの「形」が前提

統計的工程管理(SPC)は品質管理の中でも特にデータへの依存度が高い領域になる。Xbar-R管理図を描くには、同じ測定項目の数値データが時系列で蓄積されている必要がある。工程能力指数(Cp、Cpk)を算出するにも、十分な件数の測定値が規則的に記録されていなければならない。

ここで壁になるのが、データの「形」の問題になる。

以前の記事で、Excelのデータには「文法」があると書いた。1セル1値、型の統一、1行1件。品質データにもこの文法がそのまま当てはまる。

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

測定データが使えない形で残っている例:

日付 検査結果
3/5 外径 φ10.02、内径 φ5.01、OK
3/5 外径 φ10.05(※上限ギリギリ)、内径 φ4.98
3/6 OK

人間が読めば内容はわかる。しかしこのデータから管理図は描けない。数値と判定とコメントが1つのセルに混在し、測定項目が行ごとに違う形で書かれている。

使える形:

日付 受注番号 測定項目 測定値 規格下限 規格上限 判定 備考
2025-03-05 J-2501 外径 10.02 9.95 10.05 OK
2025-03-05 J-2501 内径 5.01 4.95 5.05 OK
2025-03-05 J-2502 外径 10.05 9.95 10.05 OK 上限ギリギリ
2025-03-05 J-2502 内径 4.98 4.95 5.05 OK
2025-03-06 J-2503 外径 10.01 9.95 10.05 OK
2025-03-06 J-2503 内径 5.02 4.95 5.05 OK

この形であれば、外径だけをフィルタして時系列に並べれば管理図が描ける。受注番号でフィルタすれば特定案件の検査結果が一覧できる。工程能力指数も計算できる。そして受注番号というキーを通じて、仕入データや工程データとも紐づく。

今すぐSPCをやるかどうかは関係ない。データの持ち方さえ正しければ、やりたくなったときにすぐできる。持ち方が間違っていれば、まずデータの整形から始めることになり、過去のデータは使えない。

「全数記録」で破綻するパターン

品質データの管理を始めようとすると、「全工程・全項目を記録しよう」という話になりがちになる。しかし中小製造業の現場で全数記録を徹底しようとすると、記録作業の負荷が高すぎて破綻するケースが多い。

以前の記事で、生産管理において全工程をスケジューリングするのではなく管理ポイントを絞る考え方が有効だと書いた。品質管理でも同じ発想が使える。

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

押さえるべきポイントは3つ:

  1. 受入検査 ── 材料・部品が入ってきた段階。ここで記録を残せば、不良発生時に材料起因かどうかを切り分けられる
  2. 最終検査 ── 出荷前の段階。製品品質の最後の砦であり、顧客に対する品質保証の根拠になる
  3. クレーム・不良記録 ── 発生した問題の記録。これがなければ改善のサイクルが回らない

この3点だけ押さえれば、品質の追跡は8割方カバーできる。中間工程の記録は、特定の工程で不良が頻発しているなど、必要性が見えてから追加すればいい。最初から全部やろうとして、結局どれも中途半端になるよりも、3つを確実に残す方がはるかに実効性がある。

不良データは「件数」ではなく「分類」で持つ

不良の記録で最もよく見るのが、月次で不良件数だけを集計しているケース。「今月の不良は12件」という数字はあるが、どの工程で、どんな種類の不良が、どの程度の頻度で起きているかがわからない。

パレート図を描いて不良の優先順位をつけるには、不良の分類データが必要になる。分類といっても、最初から細かく定義する必要はない。

日付 受注番号 工程 不良区分 内容 数量
2025-03-05 J-2501 機械加工 寸法不良 外径公差外れ 2
2025-03-06 J-2503 溶接 外観不良 ビード不整 1
2025-03-07 J-2505 組立 欠品 ボルト不足 1

不良区分を5〜10種類程度に絞り、ドロップダウンリストで選択式にしておく。自由記述にすると「寸法不良」「寸法NG」「寸法はずれ」のように表記がゆれて集計できなくなる。これもデータの文法の記事で書いた、名称の統一と選択式の原則がそのまま効く話になる。

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

この形でデータが蓄積されれば、月次でパレート図を作って「先月は寸法不良が6割を占めている。機械加工の外径加工を重点的に見直す」という判断ができる。件数だけでは見えなかった改善の優先順位が、分類データによって見えるようになる。

品質管理のDXは検査装置の導入ではない

品質管理のDXというと、三次元測定機や画像検査装置の導入を思い浮かべるかもしれない。確かにこれらの装置は測定の精度と速度を上げてくれる。しかし、装置が吐き出すデータの受け皿が整っていなければ、高精度な測定値が紙に印刷されて棚にファイルされるだけで終わる。

品質管理のDXの本質は、検査装置の導入ではなくデータの設計にある。

  • どの情報を、どのタイミングで、どの形式で記録するか
  • データ同士をどのキーで紐づけるか
  • 蓄積したデータをどう集計・分析できる形にしておくか

これはExcelの使い方の範囲内でできることであり、新しいシステムも高価な装置も必要ない。紙の検査記録であっても、紐づけのキーと記録項目の設計が正しければ、品質データとして機能する。

手法は教科書から学べる。装置は必要になれば買える。しかしデータは、正しい形で蓄積し始めなければ、後から取り返すことができない。品質管理の最初の一歩は、検査の厳格化でも装置の導入でもなく、記録の設計を見直すことにある。


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

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

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

全員が同じ部屋にいるなら、この話は要らない

事務所に全員が座っていて、声をかければ伝わる会社なら、コミュニケーションツールの話はほとんど意味がない。振り向いて話せばいい。

しかし現実には、事務所と工場が離れている、支店がある、業務委託の外注先とやりとりがある、営業が外に出ている——こうした「同じ場所にいない人との日常的な連絡」が発生する会社は多い。そしてこの連絡手段が、たいていの場合メールか電話に偏っている。

どちらも長く使われてきた道具だが、中小製造業の日常のやりとりには、実はどちらも微妙に合っていない。

電話の問題:相手の都合を無視する

電話は即座に伝わる。それが強みだが、同時に最大の弱点でもある。

電話をかけるということは、相手が今何をしていようと中断させるということになる。工場で作業中の人が事務所からの電話で手を止める。集中して見積もりを作っている人が電話で思考を切られる。電話はかける側の都合で成立するが、受ける側の都合は考慮されない。

もう一つの問題は、電話では考える時間がないということ。何かを判断しなければならない場面で、電話口で即答を求められる。「ちょっと確認して折り返します」と言えればいいが、そのまま口頭でやりとりが進んでしまうことも多い。結果として、十分に考えないまま判断が行われる。

そして電話には記録が残らない。「電話で言った・言わない」のトラブルは、どの会社でも経験があるのではないかと思う。

メールの問題:遅い、埋もれる、確認頻度が低い

メールは記録が残る。これは電話にない利点。しかし別の問題がある。

まず、広告メールやメルマガが多すぎる。業務メールが営業メールの山に埋もれて、重要な連絡を見落とすことがある。受信トレイの整理自体が仕事になっている人もいる。

次に、確認頻度が低い。メールを一日に2〜3回しか開かない人は珍しくない。朝と昼と終業前に確認する、というペースだと、急ぎではないが当日中に返事がほしい連絡が翌日に回ることがある。

さらに、メールは構造的に1対1のやりとりに偏る。CCで複数人に共有はできるが、関係者全員がスレッドを追えているかどうかは確認しようがない。結果として、情報が特定の人の間だけに閉じてしまう。

チャットは「ちょうどいい」位置にある

チャットツールは電話とメールの間を埋める存在になる。

電話ほどリアルタイムではない。 相手が手を止められるタイミングで読めばいい。作業中に通知が来ても、区切りがいいところで確認すれば済む。相手の集中を奪わない。

メールほど遅くない。 チャットは通知の仕組みが軽いので、メールよりも確認頻度が上がる。「見たらさっと返す」という習慣がつきやすく、数分〜数十分で返事がやりとりされることが多い。

考える余裕がある。 電話のように即答を求められない。メッセージを読んで、少し考えてから返信できる。判断を伴うやりとりでは、この「考える間」が地味に重要になる。

記録が残り、共有しやすい。 チャンネル(部屋)に関係者を入れておけば、やりとりが自然と共有される。「AさんとBさんの間で決まったことを、Cさんが知らなかった」という問題が起きにくい。

「ちょっと確認したい」のハードルが下がる。 電話するほどではないが、メールを書くほどでもない——この中間の連絡が、チャットだと気軽にできる。その結果、確認不足による手戻りが減る。

導入のハードルは低い

チャットツールの導入は、DXの中でも最もハードルが低い部類に入る。

データの移行も、業務フローの設計も要らない。アカウントを作って、部署やプロジェクトごとにチャンネルを作って、使い始めるだけ。合わなければやめればいい。

選択肢はいくつかある。

  • Slack: 最も知名度が高い。無料プランでも基本的な機能は使える。ただし無料プランではメッセージの履歴に制限がある
  • Microsoft Teams: Microsoft 365を契約しているなら追加コストなし。ただしメール・カレンダー・ファイル共有と一体化しているため、以前の記事で書いたロックインのリスクは意識しておく必要がある
  • Mattermost: OSSのチャットツール。自社サーバーで運用するため、やりとりのデータは完全に手元に残る。以前の記事でIT環境の「入れ替え可能な部品」として紹介した

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

どれを選ぶかは、会社の状況とIT環境への考え方で決めればいい。重要なのはツールの選定ではなく、電話とメールの間を埋める連絡手段を持つということになる。

LINEを業務で使う問題

チャットツールの話をすると、「うちはLINEで連絡している」という会社に出会うことがある。

LINEは個人のコミュニケーションツールとしては優れている。しかし業務で使うには問題がある。

個人アカウントと業務が混在する。 休日に業務連絡が個人のLINEに飛んでくる。プライベートと仕事の境界が曖昧になる。

退職時にデータが消える。 社員が辞めると、その人のLINEアカウントとともにやりとりの履歴が消える。業務上の判断経緯や連絡事項が失われる。

検索や整理ができない。 グループLINEは時系列で流れていくだけで、話題ごとに整理できない。過去のやりとりから情報を探すのが困難になる。

LINE WORKSという法人向けサービスもあるが、いずれにしても「個人のLINEで業務連絡」は早めに脱却したほうがいい。

外注先もチャットに入れる

社内のチャットが回り始めたら、次に考えたいのが外注先(協力工場)をチャットに乗せることになる。

中小製造業では、外注先とのやりとりはベテランの担当者が電話やFAXで回していることが多い。技術的な相談、納期の調整、品質の確認——これらはベテランの経験と人間関係で成り立っている。この関係自体を変える必要はない。

問題は、外注先との連絡がベテラン1人に集中していることにある。経理が請求書の内容を確認したいとき、購買が納期を聞きたいとき、すべてベテランを経由する。ベテランが不在だと止まる。ベテランが退職したら関係ごと消える。以前の記事で書いた属人化の構造そのものになる。

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

外注先にチャットのアカウントを作り、専用のチャンネルを設けるだけで、この構造が変わる。

ベテランと外注先の技術的なやりとりは今まで通り。しかし経理が「先月の請求書の明細を確認したい」と直接チャットで聞ける。購買が「来週の入荷予定を教えてほしい」と直接やりとりできる。ベテランを通す必要がない用件が、ベテランを通さずに済むようになる。

外注先にとっても、窓口が1人だけという状態より安心感がある。担当者がつかまらなくてもチャットに投げておけば、誰かが見てくれる。電話で何度もかけ直す手間がなくなる。

外注先の中には、スポットで加工を依頼する相手もいれば、自社にはない設備や技術を持っていて、その外注先がいなければ受けられない仕事がある——という戦略的な相手もいる。後者との関係は、自社が受注できる仕事の幅に直結する。こうした外注先との関係がベテラン1人に閉じていると、属人化リスクの中でも最も重い部類に入る。チャットで日常的に複数人がつながっておくことは、連絡効率の話だけではなく、会社にとって代えがきかない関係を維持するための手段でもある。

もちろん、外注先のIT環境やリテラシーの問題はある。ただ、外注先も世代交代は進んでいる。スマートフォンでチャットを使うこと自体は、すでに日常になっている人が増えている。社内で「メールと電話だけ」から脱却できたなら、外注先との関係でも同じステップが踏めるかもしれない。

テキストの限界と、電話への入口

一方で、テキストベースのやりとりにも限界がある。

「Aの場合はBで、ただしCが未確定ならDに切り替えて、その場合の納期はEで……」のように、条件が複数重なる話をチャットで書こうとすると、メッセージの情報量が膨れ上がる。書くほうも大変だし、読むほうも正確に解釈するのが難しくなる。

こういう場面では、テキストに固執する必要はない。チャットで「この件、ちょっと今から電話(Web会議)いいですか?」と一言送って、口頭に切り替えればいい。

実はここにチャットツールのもう一つの価値がある。チャットは電話への入口にもなる。いきなり電話をかけると相手の都合を無視することになるが、チャットで「今いいですか?」と聞いてからなら、相手が受けられるタイミングで通話に移れる。テキストで済む話はテキストで、込み入った話は口頭で。この切り替えがチャット上で自然にできることが、電話やメールだけの環境にはなかった柔軟さになる。

テキストは冷たく見える

もう一つ、テキストベースのコミュニケーションで気をつけたいことがある。文字だけのやりとりは、思った以上に冷淡に映る

「了解です」「確認します」「対応お願いします」——書いた側にはそのつもりがなくても、受け取る側は素っ気なく感じることがある。対面なら表情や声のトーンで補えるニュアンスが、テキストではすべて削ぎ落とされる。

自分の経験でも、チャットでのやりとりが事務的になりすぎて、チーム内の雰囲気が硬くなったことがある。対策として意識しているのは二つ。

一つは、絵文字やリアクションを意識的に使うこと。「了解です」より「了解です👍」のほうが柔らかくなる。チャットツールにはメッセージへのリアクション機能があるので、「いいね」や「ありがとう」をワンクリックで返せる。小さなことだが、やりとりの温度を保つのに効く。

もう一つは、ときどき口頭のコミュニケーションを意識的に混ぜること。チャットの効率が良いからといって、すべてのやりとりをテキストに寄せすぎると、人間関係の部分が削れていく。週に一度の短い通話や、たまの対面でのやりとりが、チャットでは伝わらない信頼関係を補ってくれる。

チャットツールは便利だが、万能ではない。効率と人間関係のバランスを取ることも、運用の一部になる。

まとめ

チャットツールの導入は、社内の連絡手段を一つ増やすだけの話になる。導入コストも運用の手間も小さいので、試してみて合わなければやめればいい。事務所と工場が離れている会社、支店とのやりとりが頻繁な会社、外部の協力先と日常的に連絡を取る会社であれば、検討する価値がある。


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

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

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

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

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

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

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

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

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

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

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

データの「文法」がある

日本語を話すのに文法を意識しなくても通じる。しかし文章として書き残すなら、文法が要る。主語と述語がなければ読み返したときに意味がわからなくなる。

データも同じで、その場で見て理解できればいいだけなら、どんな書き方でも構わない。しかしデータとして蓄積し、後から集計したり、別のツールで読み込んだり、データベースに移したりするなら、守るべきルールがある。

ここではそれを「データの文法」と呼ぶことにする。IT経験者にとっては当たり前のことばかりだが、ITの経験がない人がExcelで業務データを管理している現場では、これらが守られていないケースが非常に多い。

ルール1:1つのセルに値は1つだけ

悪い例:

数量
3個(うち1個は予備)
5個 ※納品済み

良い例:

数量 備考
3 うち1個は予備
5 納品済み

1つのセルに複数の情報を詰め込むと、集計ができなくなる。「数量の合計を出したい」と思っても、「3個(うち1個は予備)」というセルは数値として計算できない。

値と補足情報は別のセルに分ける。これだけで、データとしての使い道がまったく変わる。

ルール2:数字のセルには数字だけ、日付のセルには日付だけ

悪い例:

納期 単価
3月中旬 約1,200円
未定 応相談

良い例:

納期 納期備考 単価 単価備考
2025-03-15 中旬目安 1200
未定 応相談

数字の列に「未定」や「約」が入ると、その列全体が文字列になる。日付の列に「3月中旬」と書くと、並べ替えも期間の計算もできなくなる。

確定していない情報は備考列に逃がして、データの列は型を統一する。データベースでは「この列は数値」「この列は日付」と型が決まっている。Excelでも同じ考え方で運用しておけば、将来の移行がそのままできる。

ルール3:名称は表記を統一し、選択式にする

悪い例:

得意先
株式会社山田製作所
(株)山田製作所
山田製作所
ヤマダ製作所

これは人間が見れば全部同じ会社だとわかる。しかしデータとしては4つの別々の得意先になる。「山田製作所の受注合計」を出そうとしても、表記が揺れているせいで正しい数字が出ない。

対策は二つ。

  • 得意先マスタを別シートに作り、入力はドロップダウンリストで選択式にする。 手入力をさせない
  • コードを振る。 得意先コード「Y001」のように、名称とは別に一意のコードを持たせる。名称が変わってもコードで紐づけられる

わずかな表記ゆれでも、データとしては致命的になる。自由入力をやめて選択式にするだけで、この問題はほぼ消える。

ルール4:データは上から下に、1行1件で登録する

悪い例:

1月 2月 3月
A製品 10 15 12
B製品 8 20 5

人間が見る分にはわかりやすい。しかしこの形式は、月が増えるたびに列が増えていく。1年で12列、3年で36列。集計も面倒になるし、データベースにはこの形では入らない。

良い例:

製品 年月 数量
A製品 2025-01 10
A製品 2025-02 15
A製品 2025-03 12
B製品 2025-01 8
B製品 2025-02 20
B製品 2025-03 5

1行に1件のデータを、上から下に積んでいく。行が増えるだけで列は増えない。この形式なら、フィルタで特定の製品や期間を絞り込めるし、ピボットテーブルで自由に集計できる。データベースに移すときもそのまま入る。

見た目は冗長に感じるかもしれないが、データとしての使い勝手はこちらのほうが圧倒的に高い。見やすさが必要なら、このデータを元にピボットテーブルや別シートで見やすい表を作ればいい。データの持ち方と見せ方は分ける

ルール5:色や罫線で状態を管理しない

悪い例:

赤く塗ったセルは「未完了」、黄色は「保留」、緑は「完了」——現場でよく見るパターンだが、これは人間にしか読めない。プログラムやデータベースは色を判定できない。

良い例:

案件名 ステータス
A案件 未完了
B案件 保留
C案件 完了

状態は文字データとして列に持つ。こうすれば「未完了の件数」をCOUNTIF関数で出せるし、フィルタで絞り込める。色で管理していると、目で数えるしかない。

色をまったく使うなという話ではない。ステータス列の値に応じて条件付き書式で色をつければ、見た目のわかりやすさとデータとしての正しさを両立できる。色は「表示」であって「データ」ではない。この区別が重要になる。

ルール6:同じ構造のシートやブックは、行と列を必ず揃える

同じフォーマットのExcelファイルを月ごとや拠点ごとに作ることがある。月次の実績表、拠点別の在庫表、案件ごとの見積書など。

このとき、行と列の構造が完全に同じであることが絶対条件になる。

たとえばA拠点の在庫表は「A列が品名、B列が数量」なのに、B拠点では「A列が品番、B列が品名、C列が数量」になっている——こうなると、VBAで複数ファイルをまとめて処理することができなくなる。人間はレイアウトの違いを見て判断できるが、プログラムは「B列の数字を合計する」としか書けない。列がずれていれば、間違った数字を集計するか、エラーで止まる。

同じ構造のファイルを複数作る場合は、テンプレートを一つ決めて、必ずそこから複製する。列の追加や順序の変更は、全ファイルに対して同時に行う。1つでも構造が違うファイルが混ざると、自動処理の前提が崩れる

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

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

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

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

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


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

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

管理精度の天井は、経営者の判断力で決まる ── 「コスト削減」では説明できないDXの話

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

整理すると、こうなる。

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

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

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

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

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

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

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

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

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

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


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

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

中小製造業のセキュリティは「守り方」より「戻し方」 ── バックアップを自分で握る

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

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

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

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

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

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

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

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

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

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

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

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

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

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

具体的には:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

具体的には:

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

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

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

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

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

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

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

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

SaaSが合う領域もある

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

中小製造業に Google Workspace は必要か ── 「全部クラウド」の前に考えるデータの主権

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

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

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

全部入りの手軽さは本物

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

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

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

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

見落とされる長期コスト

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

併用という現実解

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

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

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

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

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

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

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

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

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

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

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

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


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

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