テックメモ

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

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

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

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

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

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

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

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

変動費だけで判断する

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

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

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

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

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

必要なデータは二つだけ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

用意したもの

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

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

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

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

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

インフラ：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

構築の難易度

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

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

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

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

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

コストの比較

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

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

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

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

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

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

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

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

---

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

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

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

VBAで作ったツールは、現場でいじられて壊れる

VBAで業務ツールを作って現場に渡す。しばらくすると「なんか動かなくなった」と言われる。見に行くと、シートの列が増えていたり、セルの書式が変わっていたり、「ちょっとここに項目を足したくて」と構成が変わっている。

Excelで作った業務ツールは、使う人の「ちょっとした変更」が積み重なって壊れていく。設計が甘いとVBAツールでも同じことが起きるが、設計次第で 「いじる気にならない」 状態にすることができる。

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

まず前提として、VBAが壊れる経緯にも2つのパターンがある。

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

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

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

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

壊れにくいVBAツールの設計は、一言で言えば 「シートに状態を持たせない」 ことに尽きる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

まとめ：「いじらせない」のではなく「いじる気にさせない」

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

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

ルールやドキュメントで「触るな」と言うより、触る余地のない構造を作る方が、中小製造業の現場には合っている。

そしてこの設計は、属人化への対処にもなる。作った人が辞めても、VBAのコードさえ残っていれば同じものが再現できる。以前の記事で「脱属人化ではなく属人化のトリアージ」と書いたが、「いじられない設計」は結果として属人化のダメージも最小限に抑える。

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

---

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

• 中小製造業に「脱Excel」は必要か
• 中小製造業のExcel業務が「1シートで」で止まる理由
• 中小製造業の内製DX ── Excel VBAで済む領域と、専用言語で作るべき領域

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

DXの相談先がない

中小製造業でDXの相談を受けていると、「ちょうどいい相談先がない」という声をよく聞く。業者に声をかければ、自社の規模に合わないパッケージの導入を勧められる。展示会で話を聞いても、数百人規模の会社が前提のサービスばかり。検索しても、出てくるのは抽象的な「DX推進」の記事ばかりで、自社の現場にどう当てはめればいいかわからない。

社内にITに詳しい人がいない会社も多い。誰かがIT担当にされて、手探りで情報を集めている——そういうケースは珍しくない。

この記事では、そういった相談を受けたとき、頭の中で何が動いているかを整理してみる。

依頼書からは始まらない

内製DXの仕事は、要件定義書や依頼書から始まるイメージがあるかもしれない。しかし数十人規模の中小製造業で実際に起きていることは、もっと雑然としている。

作業者が「これ、毎回手で集計するの面倒なんですよね」と言う。管理者が「この数字、一覧で見られないかな」と聞いてくる。きっかけは、廊下ですれ違ったときの一言だったり、昼休みの雑談だったりする。

内製DXの仕事は、この 相談 から始まる。そして相談を受けた瞬間に、頭の中でいくつかのことが同時に動き始める。

データがあるかないかを、一瞬で判断する

「この数字を見たい」という要望を聞いたとき、最初にやっているのは、その数字を作るためのデータが既にあるかどうかの判断になる。

あるなら話は早い。ないなら、誰が、どこで、どうやってそのデータを入力するのかを想像する。入力する人の手間がどれだけ増えるか。マスタデータは揃っているか。揃っていないなら、マスタを整備するところから始めなければいけないのか。

このシミュレーションは、理屈で組み立てているわけではない。どのファイルがどこにあるか、どの作業を誰がやっているか、今のデータがどういう形で保存されているか——そういうことが頭に入っているから、要望を聞いた瞬間に実現可能性が見える。

以前の記事で、AIに代替されない能力として「膨大なコンテキスト」と書いた。このシミュレーションが、まさにその具体的な使い方だと思う。ドキュメントには書かれていない現場の構造が頭に入っていないと、この判断はできない。

→ 中小製造業の内製DX ── AIに代替されない能力は現場でしか身につかない

このシミュレーションは、現場での経験が長くなるほど精度が上がる。いけそうだと感じたものは実際にいける。ダメそうだと感じたものは、ほぼダメになる。

「いけそう」の閾値

ここでいう「いけそう」は、技術的に実装できるかどうかではない。

「いけそう」の閾値は、無理なく自然に使い続けられるかどうか にある。使う人にとって無理がない範囲に収まっているかどうか。この見極めが、相談を受けた時点での最も重要な判断になる。

画面がすべて

いけそうだと判断したら、小さく作ってみる。このとき内部の設計やデータ構造よりも、 画面 のほうがはるかに重要になる。

使う人にとって、システムの中身は見えない。見えるのは画面だけで、判断するのは操作の流れだけ。だから最初に見せるべきは、動くプロトタイプの画面になる。

以前の記事で、現場へのデータ入力は「いつ・どこで」を設計すると書いた。画面のプロトタイプを見せるのは、まさにこの設計を現場と一緒に検証する作業だと言える。

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

細かい話に聞こえるかもしれないが、事務職ならタブキーでフォーカスが移動するかどうかを気にする人がいる。現場なら「自分で数字を打つのは無理だから選択式にしてほしい」という声が出る。こういう操作の感覚は、仕様書には書けない。画面を見せて、触ってもらって、初めて出てくる。

画面を見ながら「これなら大丈夫そう」という反応が得られたら、ほぼ問題ない。逆に「こんな操作を毎回やるのは無理」と言われたら、そこで設計を見直すか、場合によっては中止の判断をする。

以前の記事で「話す・聞く・見せる・また話す」と書いた。画面を見せるのは、この「見せる」の部分にあたる。

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

使われなくなることは、普通にある

ここまでのプロセスを経ても、使われなくなることはある。

部門長が意気込んで始めたプロジェクトでも、「やっぱりその数字、今は要らないかもしれない」と言われることがある。機器の追加購入が必要だとわかった途端に、中止になることもある。理由は拍子抜けするほど単純なことが多い。

これに対して一喜一憂していたら、この仕事は続けられない。

以前の記事で、実績データ収集は「何と比較するか」から逆算すると書いた。この考え方で設計しても、そもそも「比較する」という行為自体を管理者がやめてしまえば、仕組みごと不要になる。

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

使われるものは自然に使われる。使われないものは自然に使われなくなる。どれだけ設計を工夫しても、最終的には現場が「続けるかどうか」を決める。コントロールできる部分はあるが、限界もある。

大事なのは、技術者として手を抜かないこと と、自分の作品だと思わないこと を両立させることだと思う。依頼された仕事には全力で取り組む。しかし、成果物に対して個人的な執着を持たない。これを作ったのは自分だ、使ってほしい、という感情は、判断を鈍らせる。

中止の判断が出たら、それは単に「今はこの仕組みが要らなかった」という情報が得られただけのこと。その経験が、次の相談でのシミュレーション精度を上げる。

相談の精度を上げるもの

相談を受ける、シミュレーションする、小さく作る、見せる、結果に執着しない。内製DXの日常はこの繰り返しで、特別な方法論ではない。

ただし、この繰り返しの精度を決めているのは、ツールでも手法でもなく、現場で蓄積したドメイン知識だと思う。内製DXエンジニアは現場に出る時間を削ってはいけない。相談の精度を上げるのは、開発スキルではなく、現場を知っている時間の蓄積だから。

---

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

• 中小製造業の内製DX ── AIに代替されない能力は現場でしか身につかない
• 中小製造業の内製DXには「管理精度型」と「工数削減型」がある
• 中小製造業の内製DX ── 成否は「話す時間」があるかどうかで決まる

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

コードを書けることが武器だった時代

少し前まで、中小製造業で「ちょっとしたスクリプトが書ける」「VBAで業務ツールを作れる」というだけで、社内では貴重な存在になれた。周りにできる人がいないので、簡単なプログラムでも武器になった。

この状況が変わりつつある。AIコーディングツールの進化で、業務をある程度理解している人なら、自分でツールを作れるようになってきた。「Excelのこの作業を自動化して」とAIに指示すれば、それなりのVBAが出てくる。以前の記事で「AIが実装を肩代わりする」と書いたが、その流れは加速している。

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

実装力の価値が相対的に下がったとき、内製DXエンジニアに残る武器は何か。

AIにはコンテキストの限界がある

以前の記事で「ドメイン知識が唯一の差別化になる」と書いた。これをもう少し掘り下げると、ドメイン知識の正体は 膨大なコンテキスト だということに気づく。

中小製造業の現場には、どこにも書かれていない情報が大量にある。この取引先には特殊なルールがある。この工程は図面通りにやると品質が出ない。この人に聞けば本当のことがわかるが、あの人に聞くと建前しか返ってこない。過去にこういう失敗があったから、今のやり方になっている。

こうしたコンテキストはドキュメント化されていない。されていないどころか、当事者自身が「これは情報だ」と自覚していないことも多い。以前の記事で「現場の人は自分の仕事を言語化できない」と書いたのと同じ構造になる。

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

AIのコンテキストウィンドウは広がり続けている。しかし、ドキュメント化されていない情報はAIに渡しようがない。渡せない情報は、AIには使えない。この「渡せない膨大なコンテキスト」を自分の中に持っていることが、AIに代替されない能力の土台になる。

身体性 ── 現場に立たないと見えないもの

コンテキストはどうやって蓄積されるか。デスクに座ってデータを眺めていても、表面的な情報しか入ってこない。

現場に立つと、データにならない情報が入ってくる。機械の音で調子がわかる。人の動線を見れば、どこで作業が滞っているか見える。誰が誰に聞きに行っているかを観察すれば、情報の流れと属人化のポイントが見える。机の上に貼ってあるメモ、ホワイトボードの走り書き、棚の整理のされ方——こうした「ノイズ」の中に、業務の本当の姿が埋まっている。

以前の記事で「データの棚卸しをすれば、自然と属人化リスクが見えてくる」と書いた。しかし棚卸しの精度は、現場を自分の足で回っているかどうかで大きく変わる。ファイルサーバーを検索するだけの棚卸しと、現場の机の上まで見て回る棚卸しでは、拾える情報の量が違う。

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

この 身体性 ——五感を使って現場の情報を拾う能力——はAIに渡せない。カメラやセンサーで現場をモニタリングしても、「あ、ここが詰まっているな」という直感的な気づきは、現場に立った経験の蓄積がないと生まれない。

構造化能力 ── 混沌を仕組みに変える力

身体性で拾った情報と、膨大なコンテキスト。これだけなら、現場のベテランも持っている。ベテランは現場のことを誰よりも「わかっている」。

しかしベテランは、わかっていることを構造化できない。「なんとなくこうやっている」「長年の勘でこうしている」。これを データの設計やシステムの仕組みに落とせる かどうかが、内製DXエンジニアとベテランの違いになる。

以前の記事で「DX担当者は現場の言葉と技術の言葉の通訳だ」と書いた。通訳とは、片方の言葉をもう片方に変換する仕事になる。現場のベテランが「こういう感じでやっている」と言ったことを、データベースの項目定義やシステムのロジックに変換する。この変換ができるのは、 現場の言葉も技術の言葉も両方わかっている人 だけになる。

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

AIは構造化が得意に見える。しかしAIが構造化できるのは、すでに言語化された情報だけになる。言語化されていない現場の暗黙知を、まず言語化し、それから構造化する——この二段階の変換が、人間にしかできない仕事として残る。

この3つは順番がある

身体性、膨大なコンテキスト、構造化能力。この3つは同時には身につかない。順番がある。

まず身体性が先に来る。 現場で身体を使って仕事をする経験がなければ、何を見るべきかがわからない。データを見ても「この数字の裏に何があるか」が想像できない。

次にコンテキストが溜まる。 現場にいる時間が積み重なると、個々の業務がつながって見えてくる。「あの工程が遅れると、この工程にこう影響する」「この取引先がこう言うときは、実はこういう意味だ」。断片的な情報が文脈として厚みを持ち始める。

最後に構造化能力が加わる。 溜まったコンテキストを、データやシステムの形に落とす力。これは技術的なスキルだが、前の2つがないと空回りする。現場を知らずにデータベースを設計しても、使われないマスタテーブルが増えるだけになる。

自分のキャリアがまさにこの順番だった。生産管理として現場で10年。この間に業務の身体感覚とコンテキストが蓄積された。その上で社内SEに転じて、蓄積されたものをシステムの形に落としていった。もし最初からSEとして入社して、いきなりフルリモートで業務システムを設計しろと言われていたら、まともなものは作れなかったと思う。

フルリモートでは積み上がらないもの

リモートワークを否定するつもりはない。チャットもリモートデスクトップも、以前の記事で便利な道具として紹介した。

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

しかし、チャットで流れてくるのは 相手が言語化できた情報だけ になる。言語化できない情報——現場の空気、人の動き、ホワイトボードの走り書き——はリモートでは拾えない。

内製DXの記事シリーズで繰り返し「現場に出向け」「話す時間を確保しろ」と書いてきたのは、この身体性とコンテキストの蓄積を止めるなという意味でもある。効率を求めてリモートに閉じると、AIと同じ制約——渡された情報しか扱えない——を自分に課すことになる。

AIが実装を代替する時代に、AIと同じ情報源しか持っていなければ、差別化はできない。AIが持てないもの——身体で蓄えた現場の感覚と、年月をかけて積み上げた膨大なコンテキスト——を持っていることが、内製DXエンジニアの武器になる。

泥臭さが最後に残る

以前の記事で「改善を飛ばして変化には行けない」と書いた。

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

同じことがスキルにも言える。AIツールを使いこなす力は大事だが、それは構造化能力の一部であって、土台ではない。土台は、現場に足を運び、人と話し、業務の混沌を自分の中に取り込む——この泥臭い蓄積にある。

コードを書く力の価値は下がっていく。しかし、現場の混沌を整理する力の価値は上がっていく。そしてその力は、現場で身体を使わないと身につかない。効率化やAIの話が華やかであればあるほど、この泥臭い部分が見過ごされがちだが、内製DXの本当の差別化は、結局ここにある。

---

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

• AI時代の内製DXエンジニア ── 実装の先にある仕事が本業になる
• 中小製造業の内製DX ── 成否は「話す時間」があるかどうかで決まる
• 中小製造業のナレッジ管理が進まない本当の理由 ── Wikiを入れても書かれない
• 中小製造業の内製DXは「改善」の前に「地固め」から始める

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

誰も全貌を把握していない

DXの地固めとして「データの棚卸し」が必要だという話は以前の記事で書いた。

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

棚卸しの中で最も厄介なのが、Excelファイルの整理だと思っている。共有フォルダを開くと、大量のExcelファイルが並んでいる。名前を見てもわからないものが多い。中を開いても、いつ誰が何に使っているのか判別がつかない。

しかもこれが共有フォルダだけなら良い方で、個人PCのデスクトップやCドライブの奥にも散在している。社内のExcelファイルの全貌を把握している人は、まずいない。

「使っていますか？」が当てにならない理由

普通に考えれば、関係者に聞けばいい。「このファイル、使っている人はいますか？」と。

しかし実際にやると、これがうまくいかない。

• 本人が忘れている。 毎月1回だけ使うファイル、年次の棚卸しでだけ使うファイルは、聞かれても思い出せないことがある
• ショートカットの名前が違う。 デスクトップに「売上集計」というショートカットを置いているが、元ファイルは「2019_uriage_v3_final.xlsx」という名前で、別のファイルだと思っている
• マクロの中から参照されている。 別のExcelのVBAが裏でこのファイルを読みに行っているが、使っている本人はそのことを知らない
• 前任者から引き継いだまま放置されている。 「なんとなく消さないでおいてある」ファイルが大量にある

結果、「使っていない」と返ってきたファイルが、実は使われていたということが起きる。逆に「使っている」と言われたファイルが、もう何年も開かれていなかったりもする。聞いて回るだけでは、正確な現状は見えてこない。

「移動して反応を待つ」という方法

自分がたどり着いたのは、少々強引だが確実な方法になる。

正体がわからないファイルを、元の場所から別のフォルダに移動する。

削除ではない。「退避」フォルダに移すだけ。ファイルは残っているので、いつでも戻せる。

すると何が起きるか。そのファイルを実際に使っている人が、開こうとしたときに「ファイルが見つかりません」とエラーが出る。ショートカットもリンクも切れる。そうすると、その人から連絡が来る。

「あの、○○というファイルが見つからないんですけど」

この連絡が来た時点で、そのファイルは確実に使われていることがわかる。誰が、何の目的で使っているかも、その場で聞ける。聞いて回るより、はるかに正確な情報が取れる。

前提としてフォロー環境が必要

ただし、この方法には前提がある。 ファイルが見つからないときに、すぐに相談できる環境が整っていること。

チャットがあれば、「○○ファイルが見つかりません」と一言投げるだけでいい。DX担当者はすぐに対応して、退避フォルダから戻せる。

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

この導線がないと、ファイルが消えたと思って騒ぎになったり、DX担当者に連絡が届かないまま業務が止まったりする。地固めの第一歩としてチャットを入れておく理由は、こういうところにもある。

この方法の弱点：1年はかかる

反応を待つ方法の弱点は、時間がかかること。

月次の処理で使っているファイルなら1ヶ月以内に連絡が来る。しかし、年に1回しか使わないファイルは、1年待たないと判明しない。年次決算、年末調整、繁忙期だけ使う特殊な集計ファイル——こういうものは意外と多い。

だから、この方法だけに頼るわけにはいかない。現実的な進め方はこうなる。

1. まず聞ける範囲で聞く。 各部署のキーパーソンに、日常的に使っているExcelを教えてもらう。完璧でなくていい。主要なものが把握できれば十分。

2. ファイルの最終更新日で機械的にふるいにかける。 2年以上更新されていないファイルは、使われていない可能性が高い。ただし、参照専用で開くだけのファイルは更新日が変わらないので、これだけでは確定できない。

3. 残ったものを退避する。 聞いても更新日で見てもわからないものを、退避フォルダに移す。

4. 1年は様子を見る。 この間に連絡が来たファイルは戻し、用途を記録する。1年経っても連絡が来なかったファイルは、ほぼ使われていないと判断できる。

重要なのは、どの段階でも 削除はしない ということ。退避であって削除ではない。万が一のときに戻せる状態を維持しておく。

棚卸しの目的はファイルの削減ではない

ここまで書くと「不要ファイルの整理術」に見えるかもしれないが、本当の目的はそこではない。

棚卸しの目的は、 どのExcelが、誰によって、何の業務に使われているかを可視化すること にある。

この情報が手元にあると、DXの次の一手が打てる。

• どのファイルが業務の流れの中で重要なのかがわかる → データの文法の整理対象が決まる
• 同じようなデータが複数のファイルに散在していることがわかる → 二重入力の解消ポイントが見える
• 特定の人しか触れないExcelが見つかる → 属人化のトリアージと重なる

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

棚卸しはファイルの掃除ではなく、DXの地図作りだと思っている。どこに何があるかわかっていれば、何から手をつけるかが見えてくる。

---

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

• 中小製造業の内製DXは「改善」の前に「地固め」から始める
• 中小製造業のExcelが「1シート」で止まる理由 ── 関数の限界と次の一歩
• 中小製造業は「脱属人化」ではなく「属人化のトリアージ」

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

一度にやろうとしない

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

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

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

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

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

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

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

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

---

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

• 中小製造業は「脱属人化」ではなく「属人化のトリアージ」
• 中小製造業の内製DX ── 成否は「話す時間」があるかどうかで決まる
• 中小製造業の内製DXは「改善」の前に「地固め」から始める

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

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

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

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

「失敗」の線引きは曖昧

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

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

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

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

100%成功した導入はない

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

• 「ERP」という言葉の解像度が低すぎる ── 中小製造業が本当に必要な仕組みを考える
• 手作業で検証してからシステム化する ── 中小製造業で「作ったのに使われない」を防ぐ方法
• 中小製造業の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の具体的な未来予測はどうでもいい ── それでも中小製造業が今から触るべき理由

---

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

• AIの具体的な未来予測はどうでもいい ── それでも中小製造業が今から触るべき理由
• 内製DXの開発にAIを使う ── VBAでも「AIに書かせる設計」はできる
• 中小製造業の内製DXと外注の線引き ──「自社固有」か「汎用」かで決める
• 中小製造業の内製DX ── 成否は「話す時間」があるかどうかで決まる

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