製造業のDXは受託開発とSaaSどちらから始める?― 「仕様書地獄」を避けるスモールスタートの考え方
「現場の紙運用、そろそろデジタル化しないと」——そう思ってIT企業に見積もりを頼んだら、数日後にこう返ってきた。「全ラインの点検項目と、例外的なエラー処理を、すべてExcelに洗い出してください」。毎日の生産と突発対応で手一杯なのに、過去の紙帳票を何十枚も引っ張り出して"仕様書"を書けと言う。数日悩んで、そっと書類を閉じる——。中小製造業でとても多い、この"入口での頓挫"。原因は「DXが不要」でも「現場が頑固」でもなく、DXの進め方の選択にあります。この記事では、その選び方を整理します(現場が入力を嫌う理由は「現場がDXをめんどくさがる本当の理由」)。
諦めの正体は「いきなり家を建てさせられた」こと
DXには、規模のまったく違う2つの進め方があります。ひとつは、自社専用にゼロから作り込むフルオーダー(受託開発)。半年〜2年かけて分厚い仕様書を書き、費用は数千万円規模になることも。もうひとつは、既製の現場特化SaaSを、いちばん困っている1点だけ試す方法です。冒頭の"仕様書の洗い出し"は前者のやり方で、しかもITに最も不慣れな現場管理職にそれを強いる——入口で潰れて当然です。諦めるべきだったのは「DX」ではなく、「いきなり全部を作り込もうとする発想」の方だった、というわけです。
オーダーメイド(受託開発)が抱えがちな3つの落とし穴
- ① 完成する頃には現場のルールが変わっている:作り込みに時間がかかるほど、納品時には前提が古くなり、結局"特注システムに現場が合わせる"ことになりがち
- ② 「チェック項目を1つ追加」に数十万円と待ち時間:気軽に直せないので、いつの間にかシステムの横に「紙メモ」が貼られ始める
- ③ 使いにくくても高くて捨てられない:誰も使わない"高価な置物"が工場に残る
ただし、これは受託開発が悪いという話ではありません。仕様が安定していて全社共通の基幹システム(会計・生産計画など)なら、作り込む受託開発が正解です。問題は、要件が固まりきらず変化も速い"現場の運用"にまで、いきなりフルオーダーを当てはめてしまうことにあります(大企業のERP刷新の文脈は「製造業の2027年問題」で詳解)。
受託開発が最も苦戦するのは「現場の泥臭い入力・ポカヨケ」
会計や受発注は帳票やルールが比較的標準化されていて、仕様書に起こしやすい領域です。ところが、工場現場の「どの原材料を・いつ開けて・どのロットと混ぜ・期限切れをどう止めるか」という泥臭い運用は、現場ごとに違い、例外処理の山になります。ここを受託開発の仕様書に起こそうとすると労力と費用が跳ね上がり、まさに冒頭の"洗い出し地獄"に陥ります。現場の一次データ入力とポカヨケこそ、受託開発で最も仕様化しにくいエリアなのです。
つまりDXの最適解は「受託開発か、SaaSか」の二択ではありません。基幹のマクロ管理(会計・生産計画)は重厚なシステムで固め、変化が速く仕様化しにくい現場のミクロな一次データ収集とポカヨケは、既製の軽量SaaSで即日回す——という"コンポーザブル(疎結合)な役割分担"が、最も失敗しにくい勝ちパターンです。基幹系はしっかり作り込み、現場系は身軽に。この切り分けが肝心です。
受託開発と現場特化SaaSの比較
| 観点 | フルオーダー(受託開発) | 現場特化SaaS |
|---|---|---|
| 初期費用 | 数百万〜数千万円規模 | 月額(撤退可能) |
| 始めるまで | 数か月〜2年(仕様書→開発→納品) | 今週〜すぐ試せる |
| 仕様書 | 分厚い洗い出しが必要 | 基本ゼロ(既製品を使う) |
| 項目の変更 | 追加開発費と待ち時間 | 管理画面で自分で編集 |
| 合わなかったとき | 投資が戻らない | 翌月に解約できる |
| 向くケース | 仕様が安定した全社共通の基幹系 | 変化が速い現場運用の一点突破 |
「小さく試して、ダメなら引き返す」は手抜きではない
まず、いちばん困っている1点だけを既製品で試す。合わなければ翌月やめればいい(月額なので数千万円をドブに捨てずに済む)。現場が「これなら楽になる」と感じたら、そのまま広げればいい。項目を変えたいなら、管理画面で直せばいい。これは手抜きではなく、リスクを最小限に抑えて現場を守る、いちばん賢い進め方です。全社一斉の大規模刷新は、かえってPoC疲れや現場の反発を招きがちで、"入力作業だけ増える逆効果DX"にもつながります(この落とし穴は「製造業DXとは」「MESとは」も参照)。さらに、撤退障壁が低いこと(月額制)は単なるコスト面のメリットにとどまりません。数千万円かけた受託システムは「使わなければ経営責任」となって現場に強制され疲弊しますが、月額SaaSは合わなければやめられるからこそ、「失敗しても傷が浅いから、現場が恐れずに試せる」という"心理的安全性"を生みます。これが、現場発の小さな改善が積み上がる土壌になります。
中小の現場ほど「スモールスタート」が向く理由
- 書類を書かない:今の作業のまま試せる。仕様書づくりに人を割けない現場でも始められる
- 重い投資をしない:月額でいつでも撤退できるので、失敗しても傷が浅い
- 現場が「楽になる」と思ったものだけ残す:使われないシステムを抱え込まない
仕様書づくりに半年かけられる余裕のある大企業は、じっくり新築すればよい。しかし、人手不足でギリギリ回している中小の現場こそ、「既製品を置いて試す」やり方が合っています。DXが進まない要因は全国的にも「リソース不足」「PoC疲れ」が上位に挙がっており(IPA・ものづくり白書)、身の丈に合った始め方を選ぶことが、そのまま定着率を左右します。
この分野を扱うなら ― QUALIKEEP でできること
私たちは、この「まず1つ置いてみる」ための現場ツールの一例として、開封後の期限やロットの記録をスマホ・スキャンで管理する QUALIKEEP を作っています。こだわったのは「仕様書ゼロで明日から試せる軽さ」と「現場はQRをかざすだけ」という点で、覚えることや複雑な操作、事前研修がいらない形にしています。合わなければ月額で撤退でき、材料や期限の設定は管理画面で自分で変えられます(追加の開発費はかかりません)。もちろん、これがすべての工場の正解だとは考えていません。ただ、「分厚い見積書を見てDXを諦めた」記憶があるなら、その"諦めた順番"を一度だけ疑ってみる価値はあります。
仕様書ゼロ・現場はスキャンだけ。まず1つ、明日から試してみませんか。
QUALIKEEP の機能や料金を詳しく見る →ご注意
本記事は一般的な考え方を整理したものです。受託開発とSaaSのどちらが適するかは、対象業務の仕様の安定性・規模・予算により異なります。自社の状況に合わせてご判断ください。
参考・出典
※ 外部サイトの内容・URLは変更される場合があります。最新の情報は各機関の公式ページをご確認ください。