手段の選択肢は多いが、評価軸がぼやけている
DXを進めるにあたって、手段の選択肢は意外と多い。パッケージ導入、OSS導入、ベンダーによるフルスクラッチ開発、小規模ベンダーへの開発委託、内製エンジニアによるプログラミング、ローコード開発、業務委託の活用。どれがいいのかという問いに対して、一般的には「まずパッケージを検討し、合わなければスクラッチ」という順序が語られることが多い。
しかし多品種少量・受注生産の中小製造業という文脈に絞ると、この一般論はむしろ逆に作用すると感じている。
評価軸は「変化への追従速度」
この業態の最大の特徴は、業務プロセス自体が常に変動することにある。量産型とは決定的に違う点で、「一度作って終わり」のシステムでは対応できない。
パッケージもベンダー開発も、変更に対するリードタイムが長い。受注生産の現場は「来月からこのやり方に変えたい」が日常なのに、要件定義→見積→開発→テスト→リリースで数ヶ月かかるのでは、現場が先に進んでしまう。
どの手段が正解かを考えるとき、最も重要な評価軸は変化への追従速度になる。この軸で測ると、業務を最も深く理解している社内の人間が直接手を動かせる状態が、結果的に最も速い。
各手段の向き不向き
| 手段 | 向いている領域 | 落とし穴 |
|---|---|---|
| パッケージ導入 | 会計・給与・勤怠などコモディティ業務 | 生産管理系は多品種少量に合わないことが多い。カスタマイズ費が膨らみがち |
| OSS導入 | 特定機能の部品として（DB、BIツール等） | 運用・保守できる人が社内にいることが前提 |
| ベンダーフルスクラッチ | 大規模・長期安定の基幹系 | コストが大きく、知識がベンダー側に偏る |
| 小規模ベンダー開発 | 特定業務のツール化 | 柔軟だがドキュメントが手薄になりやすく、知識が社内に残りにくい |
| 内製（プログラミング） | 業務の中核、差別化に直結する領域 | 人材の採用・育成が最大の壁 |
| 内製（ローコード） | 現場主導の小さな改善、入口として | 複雑になると限界にぶつかる |
| 業務委託 | 内製の立ち上げ期、技術的なギャップ埋め | 知識が退場とともに流出するリスク |
どの手段にもメリットはあるし、うまくいっている会社もある。ただ、多品種少量の受注生産で「現場の変化に追いつける仕組み」を作ろうとすると、内製の優位性が際立ってくるというのが、現場を見てきた実感になる。
ベンダーの規模ではなく「知識の所在」の問題
大手ベンダーと小規模ベンダーにはそれぞれ異なるトレードオフがある。大手はスピードが遅くコストも高いが、ドキュメント整備や引き継ぎは最低限やってくれる。小規模ベンダーは柔軟で小回りが利くが、ドキュメントが手薄になりがちで、知識が社内にまったく残らないケースが多い。
しかし本質的な問題は、ベンダーの規模ではなく知識がどこにあるかだと思っている。大手がドキュメントを残してくれても、それを読んで理解できる人が社内にいなければ紙の束でしかない。小規模ベンダーに頼むこと自体は悪くないが、丸投げして納品物だけ受け取るのでは、ベンダーロックインの小規模版になるだけになる。
つまり、どの手段を選ぶにしても、社内に「理解できる力」がないと同じ構造的な問題にぶつかる。内製力はDXの一つの手段ではなく、すべての手段を機能させるための土台になる。
内製化の最大のハードルは人材
ここまで聞くと「内製化最高」となりがちだが、最大の問題はハードルの高さにある。中小製造業で事務作業をしている人に「プログラミングを覚えろ」と社内命令を出すのは現実的ではない。大企業のように潤沢な人材がいるわけでもない。
プログラミングは意欲の問題ではなく適性の問題で、業務で使えるレベルまで自走できるかどうかは「好きかどうか」にかなり依存する。中小製造業に入社する人の動機は「ものづくり」であって「プログラミングがしたい」ではない。ゴリゴリのプログラマーが社内にいること自体が例外的で、それを戦略の前提にはできない。
内製化にはレベルがある
「内製化＝社員全員がプログラマーになること」ではない。自分が考える内製力のレベル感はこうなる。
- レベル0： 完全外注。中身は誰もわからない
- レベル1： 仕組みを「理解できる」人がいる
- レベル2： 設定変更・軽微な修正ができる人がいる
- レベル3： ローコード等で業務ツールを作れる人がいる
- レベル4： プログラミングで自由に作れる人がいる
多くの会社はレベル0で、いきなりレベル4を目指すから「無理だ」となる。しかしレベル1〜2に引き上げるだけでも状況は劇的に変わる。ベンダーと対等に会話できるようになるし、「この変更は自分たちでできる」という判断ができるようになる。
「育成」ではなく「発掘」
全員に求めるのではなく、1人見つけるのが出発点になる。現場や事務の中に、Excelマクロを自発的に作っているような人がいることがある。あるいは趣味でPCを触るのが好きな人。そういう人に業務時間の一部を使って取り組んでもらう。
「社内命令でプログラミングを覚えろ」ではなく、すでに素養がある人を見つけて環境と時間を与える。命令ではなく発掘。これなら再現性がある。
AI支援がレベル間の壁を下げている
レベル4の人材を社内で見つけるのはほぼ運だと述べたが、ここに今、大きな変化が起きている。AIコーディング支援によって、レベル3の人がレベル4に近いアウトプットを出せる場面が増えている。
完全なレベル4にはならない。しかし中小製造業のDXに必要なのは、最先端のWebサービスを作ることではなく、自社の業務に合った実用的なツールを作って回すことだ。それなら、レベル3にAI支援を組み合わせた「レベル3.7」程度で十分回るケースが多い。
8割内製、2割外部という現実解
ゴリゴリのプログラマーを社内で育てようとしなくていい。ツールやExcelに強い人を1人見つけて、ローコードやAI支援を使える環境を整えれば、自社に必要な8割はカバーできる。残り2割は外部の力を借りればいい。
そしてその「残り2割の外部」が丸投げベンダーではなく、製造業の文脈がわかって一緒に作れる人間であれば、知識も社内に残る。
100%内製を目指すから非現実的に見える。コモディティ業務はパッケージで割り切り、製造の中核業務は内製を軸にし、足りない部分は伴走型の外部支援で補完する。この組み合わせが、中小製造業のDXにおいて最も再現性のある形だと考えている。