製造業のシステムは何が必要？種類と選び方、パッケージか開発か

紙やExcelでの管理に限界が来た、今のシステムのサポート終了が迫っている、社長からシステム化を任された。製造業のシステムを調べ始めるきっかけはさまざまです。
ただ、生産管理システム・ERP・MESなど種類が多く、自社にどれが必要かは分かりにくいもの。パッケージ（多くの会社で使える既製のソフト）を選ぶ前提の記事が多く、独自に開発すべきかも判断しにくいのが実情です。

この記事で分かるのは、製造業で使うシステムの種類と役割、課題から必要なものを見極める方法、パッケージか独自開発かの判断基準。
一部の業務で試す進め方、費用と社長への説明の仕方、相談先の選び方まで、社内で説明するための材料がそろいます。

運営する当社EPICsは、250件以上の開発実績を持つ受託開発会社です。
業務診断から開発、現場への定着までを1社で支援し、SaaS（月額などで使う既製のソフト）で足りる場合は作らない選択肢も含めて中立に提案しています。（出典：EPICs 受託開発サービス／EPICs 業務改善のためのアプリ・システム受託開発サービス）

製造業のシステムにはどんな種類がある？役割と全体像

製造業で使われる主なシステムは、大きく4つに分けられます。
会社全体の情報をまとめる基幹システム（ERP）、工場の生産計画と実績を管理する生産管理システム、製造現場の作業を記録・指示するMES（製造実行システム）、在庫・販売・原価・工程などの業務ごとのシステムです。
すべてをそろえる必要はなく、課題のある業務から選べば足ります。

製造業のシステムの全体像を、一覧にまとめました。

システム	主に管理するもの	関係する業務・部門
基幹システム（ERP）	販売・購買・在庫・生産・会計など、会社全体の基幹業務の情報	経営 全部門
生産管理システム	何をいつどれだけ作るかの計画、資材の手配、工程の進み具合、実績や原価	生産管理 購買 工場
MES（製造実行システム）	製造現場の作業の指示と実績の記録、設備や検査の状況	製造現場 品質管理
在庫管理	材料・仕掛品（作りかけの製品）・製品の数と置き場所	資材 倉庫 生産管理
販売管理	見積・受注・出荷・請求	営業 出荷 経理
原価管理	製品ごとにかかった材料費や人件費などの費用	経理 生産管理 経営
工程管理	作業の予定と進み具合	製造現場 生産管理

受注から出荷・請求まで、システムは業務の流れでつながる

製造業のシステムは、受注から生産計画、製造、在庫、出荷・請求、原価の把握までの業務の流れに沿って、それぞれの段階を受け持つ形でつながっています。
種類に迷ったら、システムの名前より、業務の流れのどこを受け持つかで整理するのが近道です。

業務の流れと、主に受け持つシステムを対応させると、次のようになります。

• 受注、出荷・請求：販売管理
• 生産計画、資材の手配：生産管理システム
• 現場の作業と進み具合：MES（製造実行システム）、工程管理
• 材料・製品の数：在庫管理
• かかった費用：原価管理
• これらの情報と会計をまとめて扱う：基幹システム（ERP）

業務ごとのシステムがつながっていないと、注文の内容を販売管理と生産の指示書の両方に入力する二重入力が生まれ、転記ミスの原因になります。
二重入力を減らす方法は、次の章の課題別の解説で扱うテーマの1つです。

なお、設計を支えるCAD（設計図を作るソフト）やPLM（製品の設計情報の管理）は、この記事では扱いません（出典：LEXER「製造業で使われるITシステムとは？まとめて解説」）。

会社全体の情報をまとめるのが基幹システム（ERP）

基幹システム（ERP）は、販売・購買・在庫・生産・会計といった会社の基幹業務の情報を1つにまとめて管理するシステムです。
部門ごとに数字がばらばらな状態を解消し、同じ数字を全社で見られるようにします。

（出典：IM-Pressの製造業向けERPの解説記事）

一方で、ERPは対象の業務が広い分、導入の規模と費用が大きくなりやすいシステムです。
過度なカスタマイズ（自社向けの作り込み）は導入費用や保守の負担を増やすとされており、中小企業では、ERPを入れずに業務ごとのシステムをつないで使う形も選択肢になります。

（出典：IM-Pressの製造業向けERPの解説記事）

工場の計画と実績を管理するのが生産管理システム

生産管理システムは、何をいつどれだけ作るかの計画から、資材の手配、工程の進み具合、実績や原価までを管理する、工場の中心となるシステムです。
ERPが会計を含む会社全体を広く扱うのに対し、生産管理システムは工場の「作る」業務に絞って細かく管理する点が違います（出典：ITトレンドの生産管理システムの解説記事）。

受注ごとに仕様が変わる個別受注生産か、同じ製品をくり返し作る繰り返し生産かなど、生産方式によって合うシステムが変わる点にも注意が必要です。

生産管理システムで管理できる機能やERP・MESとの違い、既製品で足りるかの判断は、生産管理システムとは？できることと導入判断の目安の記事で詳しく解説しています。

製造現場の作業を記録・指示するのがMES（製造実行システム）

MES（製造実行システム）は、生産計画をもとに、製造現場の作業の指示や実績の記録、設備や検査の状況の把握を行うシステムです。
計画を担うERPや生産管理システムと、現場の設備や検査機器との間をつなぐ位置にあります。
生産管理システムが「計画と実績の管理」に重心を置くのに対し、MESは「現場の作業をその場で指示し、記録すること」に重心があるのが違いです。

（出典：MONOist「5分で分かるIoT時代のMESとは」）

MESは現場の設備とデータをやり取りすることが多いため、導入前に、今ある設備や工場のネットワークとつなげられるかを確かめることが欠かせません（出典：MONOist「5分で分かるIoT時代のMESとは」）。

在庫・販売・原価・工程は、業務ごとのシステムでも管理できる

在庫・販売・原価・工程の管理は、ERPや生産管理システムの機能として扱うほか、業務ごとの専用のシステムで管理することもできます。
「在庫が合わない」のように課題がはっきりしている業務だけを、先にシステム化したい場合に向いた選択肢です。

業務ごとの主なシステムと、受け持つ内容を並べます。

• 製造業の在庫管理システム：材料・仕掛品・製品の数と置き場所を管理する
• 製造業の販売管理システム：見積から受注、出荷、請求までの流れを管理する
• 製造業の原価管理システム：製品ごとにかかった材料費や人件費などを把握する
• 製造業の工程管理システム：作業の予定と進み具合を管理する（部品の受発注を含む場合もある）

自社に必要なシステムは？課題から逆算して決める

自社に必要なシステムは、製品の機能の多さではなく、いま現場で困っていることから逆算して決めると、選び間違いを防げます。
製品の機能から探し始めると、要らない機能まで含んだ大きなシステムを選んだり、本当に困っている業務が手つかずで残ったりしがちです。

何を選べばよいか分からないのは、多くの中小企業に共通する悩みでもあります。
日本政策金融公庫総合研究所の調査によると、ITベンダーに相談した中小企業の相談内容で最も多かったのは「目的に合うデジタルツールの選択」です。
その割合は75.7％にのぼります（全業種。出典：日本政策金融公庫総合研究所「デジタル化に取り組む中小企業の実態に関する調査」2025年5月21日）。

よくある課題と、まず検討するシステムの対応を表にまとめました。

よくある課題	現場で起きていること（例）	まず検討するシステム
在庫が合わない 欠品や作りすぎがある	帳簿と倉庫の在庫の数がずれ、急な欠品や余分な在庫が出る	在庫管理
製品ごとの利益や原価が分からない	売上はあるのに利益が残らず、どの製品で損をしているか分からない	原価管理
納期遅れが多い 進捗が見えない	注文がどの工程まで進んでいるか、現場に聞かないと分からない	工程管理 生産管理 （現場の実績はMES）
受注から出荷・請求まで、同じ情報を何度も入力している	注文書の内容を、Excel、生産の指示書、請求書へと書き写している	販売管理 システム同士の連携
特定の人しか分からない業務がある 人手が足りない	担当者が休むと、段取りや判断が止まってしまう	手作業の転記と口頭のやり取りを減らす仕組み
部門ごとに数字がばらばら	営業・工場・経理で、同じ月の数字が合わない	基幹システム（ERP） 既存システムの連携

在庫や原価が見えないなら、まず数字をそろえる仕組みから

在庫が合わない、製品ごとの原価が分からないといった「数字が見えない」課題には、在庫管理や原価管理の仕組みで、まず正しい数字をそろえることから始めます。
帳簿と現物の在庫がずれると欠品や作りすぎが起き、原価が分からないと値決めや受注の判断が勘に頼りがちになるためです。

在庫と原価のどちらも、入出庫や作業時間の記録を正しく取ることが前提になります。
誰が・いつ・何を記録するかを決めないまま高機能なシステムを入れても、数字は正しくなりません。

納期遅れや進捗が見えないなら、計画と現場の実績をつなぐ

納期遅れが多い、注文がどこまで進んでいるか分からないという課題には、生産計画と現場の実績をつなぐ工程管理や生産管理の仕組みが向いています。
現場の進み具合が紙の日報やホワイトボードでしか分からないと、遅れに気づくのが翌日にずれ込み、急ぎの注文が割り込んだときの判断も後手に回りがちです。

作業を終えるたびに現場で実績を記録できれば、工程の進捗管理をリアルタイムに行え、計画との差に早く気づけるため、段取りの組み替えや納期の相談を前倒しできます。
設備から稼働の状況や生産数を直接取り込みたい場合は、MES（製造実行システム）の領域です。

受注から出荷までの二重入力が多いなら、情報をつなぐ仕組みを先に

受注から出荷・請求まで同じ情報を何度も入力しているなら、新しい機能を足すより先に、1回の入力で情報をつなぐ仕組みを作るほうが効果が大きくなります。
注文書をExcelに転記し、生産の指示書に書き写し、請求書へ入力し直すたびに、手間と転記ミス（ヒューマンエラー）が増えるからです。

対策の中心は、販売管理を軸に受注の情報を生産・出荷・請求へ引き継ぐことと、今あるシステム同士をデータ連携させることにあります。
会社全体をまとめるならERPも選択肢ですが、範囲が広い分、費用と導入の負担が大きい点には注意が必要です。

人手不足や属人化が課題なら、手作業と口頭のやり取りを減らす

人手が足りない、特定の人しか分からない業務があるという課題には、手作業の転記や口頭でのやり取りを減らし、誰でも同じ情報を見られる仕組みから入れるのが近道です。
限られた人数で回すには、一人ひとりの手間を減らすことと、情報を特定の人に閉じ込めないことの両方が欠かせません。

中小の製造業では、人手の不足感が高い水準のまま。
経済産業省「2026年版ものづくり白書」の概要によると、中小企業の製造業の従業員過不足DI（従業員の過不足を示す指標）は、2025年にマイナス17.9でした。
マイナスは「不足」と答えた会社が「過剰」を上回っていることを表し、新型コロナウイルス感染症の拡大前（2019年）に近い水準とされています（出典：経済産業省「2026年版ものづくり白書」概要）。

具体的には、次のような仕組みから始めるのが一案です。

• 紙の作業日報を、タブレットからの入力に切り替える
• 段取りや判断の手順を記録し、誰でも見られる場所で共有する（手順の標準化）
• 口頭や電話で伝えていた作業の指示を、システム上の指示に置き換える

属人化した業務は、その人が何を見て、どう判断しているかを先に聞き取って手順書にしておくと、システムに載せる内容がはっきりします。

課題が複数あるなら、損失の大きい業務から順番を決める

課題が複数あるときは、すべてを一度に解こうとせず、損失や手間の大きい業務から順番を決めると、最初に作る範囲を絞り込めます。
範囲が絞れれば費用を抑えやすく、「なぜこの業務からか」を社長に説明するときの根拠としても使えるのが利点です。

順番を決めるときは、次の3点を目安にしましょう。

• 損失の大きさ：ミスや遅れによる作り直し、値引き、残業などの損失が大きいか
• 発生の頻度：毎日・毎回のように起きているか
• 期限の有無：今のシステムのサポート終了など、対応の期限があるか

最初の一歩は、今の業務の流れを書き出し、全体の流れを止めている箇所（ボトルネック）を見つけることです。

Excel・Accessや古いシステムからの切り替えで、つまずきやすい点は？

ExcelやAccess（データベースを作れるソフト）、古いシステムからの切り替えでつまずきやすいのは、新しく作る機能よりも、今のデータと業務をどう引き継ぐかの部分です。
作り始める前に「いつまでに切り替えるか」「データをどう移すか」「今の業務のどこを残し、どこを変えるか」の3点を決めておきましょう。

長く使ってきた古いシステム（レガシーシステム）ほど、引き継ぎは難しくなりがちです。
経済産業省の「DXレポート」は、既存のシステムが老朽化・複雑化して中身が分からない「ブラックボックス」になると、データの活用や連携が限られ、新しい技術の効果も限られると指摘しています（出典：経済産業省「DXレポート」2018年9月7日、3ページ）。

ExcelやAccessでの管理には、限界のサインがある

ExcelやAccessでの管理は手軽に始められる反面、扱うデータや使う人が増えると限界が来ます。
次のようなサインが出ていれば、システム化を考える時期です。

• ファイルが増えて、どれが最新版か分からない
• 複数人で同時に入力できず、入力待ちや上書きが起きる
• 集計や転記に、毎日・毎月まとまった時間がかかる
• マクロ（Excelの作業を自動で行う仕組み）や、Accessで作った生産管理・在庫管理の仕組みを直せるのが、特定の1人だけ
• ファイルが重く、開くのに時間がかかったり、壊れたりする

扱う量が少なく、使う人も限られているうちは、ExcelやAccessも手軽で直しやすい便利な道具です。
限界のサインが出始めた段階で考え始めれば、慌てずに準備を進められます。

古いシステムは、分かる人がいなくなる前に置き換えを考える

長く使ってきたシステムは、作った担当者や開発元がいなくなる前に、置き換えの検討を始めておきましょう。
DXレポートでも、保守できる人材がいなくなると、保守の費用が増え、セキュリティ上のリスクも高まると懸念されています（出典：経済産業省「DXレポート」2018年9月7日、3ページ）。

次のような事情があれば、期限から逆算して動き始める時期です。

• 今のシステムのサポート終了の予定がある
• システムを作った社内の担当者が、退職する予定がある
• 開発元が廃業した、または連絡がつきにくい

基幹システムの刷新を含め、置き換えには、今の仕組みの調査やデータの移し方の検討、試し運用が必要で、期限ぎりぎりでは間に合わないことも。
期限がある場合は、相談の最初に伝えておくのが得策です。

データの移し方を最初に決めないと、切り替えが止まる

置き換えでは、今のExcelやシステムに入っているデータを、新しい仕組みへどう移すかを最初に決めておかないと、切り替えの直前で作業が止まってしまいます。
データの問題は、実際に移す段階で見つかりやすいためです。

よくある問題を挙げます。

• 品番や取引先のコードの付け方が、新旧の仕組みで違う
• 新しい仕組みで必要な項目が、今のデータにない
• 同じ取引先が、別の名前で重複して登録されている

移行の前に済ませておきたい対策は、次の3つです。

• 移す前にデータを棚卸しし、不足や重複を洗い出す
• 一部のデータで試しに移し、正しく移せるかを確かめてから全体を移す
• 移行の期間中に、新旧の仕組みを並行して使うかどうかを決めておく

とくに品番や取引先といったマスタ（多くの業務が共通して使う基本の情報）は、ほかのデータの土台になるため、先に整えておくと移行を進めやすくなります。

今の業務を「残すところ」と「変えるところ」に分けてから作る

置き換えでは、今の業務をそのまま新しい仕組みに写すのではなく、残すところと変えるところに分けてから、何を作るかを決めます。
そのまま再現すると紙やExcelの時代の手間まで持ち込み、変えすぎると現場が慣れた手順が崩れて使われなくなるおそれがあるためです。

残すところと変えるところの線引きのコツは、現場の担当者に「この手順はなぜ必要か」を聞き取ること。
理由を説明できる手順は残す候補、「昔からそうしているから」以外に理由がない手順は変える候補です。

作る機能や条件を決める工程（要件定義）は、業務部門のユーザーが主体的に関わる必要性が増しているとされています（出典：IPA「ユーザのための要件定義ガイド 第2版」）。
現場の担当者が残す・変えるの線引きに加わることは、業務部門が要件定義に関わるという流れにも沿った進め方です。

パッケージで足りる？独自に開発すべき？判断の基準

製造業のシステムは、SaaSやパッケージをそのまま使うか、パッケージに追加開発するか、独自に開発するかの3つから選びます。
どれが合うかは、自社の業務を既製品の標準に合わせられるかどうかで決まり、最初から「作る」と決めず、まず既製品で足りるかを確かめるのが順番です。

3つの選択肢の違いを、表にまとめました。

選択肢	向いているケース	強み	注意点
SaaS・パッケージをそのまま使う	業務を製品の標準に合わせられる	導入までの期間と初期費用を抑えやすい 機能の更新は提供元が行う	業務を製品に合わせる必要がある 合わない部分は運用で補う
パッケージに追加開発する	大半は標準で足り、一部だけ独自の業務がある	標準の部分を活かしつつ、足りない部分を補える	追加開発が増えるほど、製品の更新のたびに手直しが必要になる
独自に開発する	自社ならではの業務や生産方式が強みになっている	業務に合わせて作れる 事業や業務の変化に合わせて直せる	作る内容を決める手間がかかる 公開後の保守の体制が要る

業務を標準に合わせられるなら、SaaS・パッケージで足りる

自社の業務が多くの会社と共通していて、進め方を製品の標準に合わせられるなら、SaaSやパッケージといった既製品で十分に足ります。
既製品は多くの会社の業務を前提に作られており、自社の業務がその前提に近いほど、そのまま使える部分が増えるからです。

会計や勤怠、一般的な受発注のように、進め方が会社ごとに大きく変わらない分野は、既製品が力を発揮しやすい代表例。
導入までの期間と初期費用を抑えやすく、機能の更新も提供元が行うため、自社で保守を抱えずに済みます。

SaaS・パッケージで注意したいのは、業務を製品に合わせる必要があり、合わない部分は手作業や運用の工夫で補うことになる点です。
導入前に試用期間やデモで、現場の担当者が実際の業務で使えるかを確かめておきましょう（出典：NTTデータ関西の製造業向けシステムの解説記事）。

一部の業務だけ合わないなら、パッケージに追加開発する

大半の業務は既製品の標準で足り、一部だけ自社独自の業務がある場合は、パッケージを土台に、足りない部分だけを追加で開発（カスタマイズ）する方法があります。
標準で足りる部分は既製品の強みをそのまま活かし、独自の部分にだけ手を加えるやり方です。

「パッケージだと必要な機能が含まれていない」という課題を挙げ、導入の工程に追加開発（アドオン開発）を組み込んでいる生産管理パッケージの提供元もあります（出典：両備システムズの製品ページ）。

注意したいのは、追加開発が増えるほど、製品が新しい版に更新されるたびに手直しの費用と手間がかかる点です。
導入前の見積もりで追加開発の範囲を確かめ、大きくなりそうなら独自に開発する選択肢と比べてみましょう。

自社ならではの業務が強みなら、独自に開発するほうが向く

自社ならではの業務の進め方や生産方式が強みになっている場合は、既製品に業務を合わせるより、独自に開発するほうが向いています。
既製品の標準に合わせると、他社との違いを生んでいた手順まで変えることになり、強みが失われかねないためです。

製造業のシステム開発で、独自に開発するほうが向きやすい場合の例を挙げます。

• 受注ごとに仕様が変わる個別受注生産で、標準の流れに収まらない
• 独自の工程や検査の手順があり、それが品質の決め手になっている
• 取引先ごとに異なる帳票や、取引先のシステムとの連携が必要

独自に開発する強みは、業務に合わせて作れることと、多品種少量生産（多くの種類を少しずつ作る生産）への切り替えや取引先の増加などで業務が変わったときにも、合わせて直せる拡張性です。

一方で、独自に開発する場合は、作る機能や条件を決める要件定義に時間がかかり、公開後の不具合への対応や改善を任せる保守の体制も必要になります。

独自に開発するときは、作った会社にしか直せない状態にならないよう、設計の資料やデータを自社で受け取れるかも確かめておきたい点です。

判断に迷ったら、4つの観点で比べる

どれを選ぶか迷ったときは、業務の独自性、既存のシステムや設備との連携、将来の変化、費用と保守の4つの観点で比べると判断しやすくなります。
1つの観点だけで決めると、導入したあとに別の面で無理が出やすいためです。

4つの観点ごとに、確かめることと向いている選択肢を表に整理しました。

観点	確かめること	既製品が向く場合	独自開発が向く場合
業務の独自性（生産方式を含む）	業務を標準の進め方に合わせられるか	合わせられる	合わせると強みが失われる
既存のシステムや設備との連携	今使っている会計ソフトや設備とつなぐ必要があるか	製品が連携に対応している	独自のつなぎ込みが必要
将来の変化	事業の拡大や法改正で、業務が変わる見込みがあるか	変化が少ない	変化に合わせて直したい
費用と保守	初期費用、月額の利用料、更新時の手直し、保守を誰が担うか	総額を抑えて早く始めたい	長く使う前提で、業務に合わせて直し続けたい

既製品か独自開発かの答えは、業務ごとに分かれてもかまいません。
会計は既製品を使い、自社独自の工程管理だけを作るといった組み合わせ方もあります。

独自に開発する場合も、作り方は1つではない

独自に開発する場合も、作り方はノーコード、AI駆動開発、スクラッチの3つがあり、業務や部分ごとに組み合わせて使い分けられます。
1つのシステムの中でも、部分によって求められる速さや堅さが違うため、作り方をそろえる必要はありません。

3つの作り方は、次のとおりです。

• ノーコード：プログラムを書かずに、画面の操作で作る開発
• AI駆動開発：AIにコードを書かせながら、人が確認して進める開発
• スクラッチ：プログラムを一から書く開発

それぞれの向き不向きを、優劣ではなく同じ基準で並べます。

作り方	向いている部分	強み	注意点
ノーコード	業務固有の手順や、独自の承認の流れ	画面や機能を素早く作れる 直しやすい	複雑な処理や大規模な利用では制約が出ることがある ツールの料金や仕様の変更に左右される
AI駆動開発	書類の読み取り・要約・分類などの文書処理	試作を素早く作れる	AIが書いたコードの品質を、人が確認する体制が要る
スクラッチ	基幹に関わる、止められない部分	自由度が高い 長く使う前提で作り込める	費用と期間がかかる

失敗しないためには？一度に入れず、一部の業務で試してから広げる

製造業のシステム導入で失敗を避けるには、一度に全社へ入れず、一部の業務で試して効果を確かめてから広げる進め方が有効です。
最初に試す範囲を小さくしておけば、合わなかったときの損失も小さく抑えられます。

期待どおりの効果が出ないことは、珍しくありません。
日本政策金融公庫総合研究所の調査では、デジタルツールの導入による業績全体へのプラスの影響について、中小の製造業に尋ねています。
「期待したほどの成果はあがっていない」が22.3％、「わからない」が30.5％という結果です（出典：日本政策金融公庫総合研究所「デジタル化に取り組む中小企業の実態に関する調査」2025年5月21日）。

一部の業務で試してから広げる進め方は、次の流れで進めます。

1. 現状を把握する
2. 一部の業務で試す
3. 結果を見て、拡げる・作り直す・止めるを判断する
4. ほかの業務へ広げる
5. 使いながら改善する

一度に全社へ入れると、合わなかったときに後戻りできない

全社の業務を一度にシステムへ切り替えると、現場に合わなかったときや効果が出なかったときに、後戻りがききにくくなります。
すべての部署の手順が同時に変わっていて、元のやり方に戻すことが難しいからです。

一度に入れた場合に起きやすい事態を挙げます。

• 多額の費用をかけたあとで現場が使いこなせないと分かっても、作り直す予算が残っていない
• 全部署が同時に新しい手順に変わるため、問い合わせや混乱が一度に集中する
• どこに問題があるのかを切り分けにくい

デジタル化の効果を確かめられていない会社が少なくない以上、影響の範囲を区切って確かめられる進め方を選べば、リスクと失敗を小さく抑えられます。

まず一部の業務や部署で試し、現場で使えるかを確かめる

最初は対象を一部の業務や部署に絞って試し、現場で本当に使えるか、効果が出るかを確かめます。
一部の業務で先に試す導入のしかたは「パイロット導入」と呼ばれ、小さく始めるスモールスタートの方法の1つです。

試す対象は、次の3つの目安で選ぶと、結果を判断しやすくなります。

• 困っている度合いが大きい：優先順位を付けたときに上位に来た業務
• 範囲を区切りやすい：1つのラインや1つの部署で完結する業務
• 協力してくれる担当者がいる：試しながら意見を出してくれる現場の人がいる業務

試す対象とあわせて、試す期間と、何をもって「うまくいった」とするかを、始める前に決めておきましょう。
基準がないまま試すと、終わったあとに続けるべきかを判断できません。

試した結果を見て「拡げる・作り直す・止める」を決める

試した結果を見て、ほかの業務へ拡げるか、合わなかった部分を作り直すか、効果が見込めなければ止めるかを決めます。
3つの選択肢をあらかじめ用意しておけば、結果に応じて迷わず次の一手を選べるためです。

判断の材料には、たとえば次のようなものがあります。

• 現場の担当者が実際に使っているか（利用率）
• 作業の時間や転記ミスが、試す前より減ったか
• 現場から出た不満や要望の中身

試した結果から「止める」と判断することも、失敗ではありません。
効果が見込めないまま全社に広げるより、試した段階で止めるほうが大きな損失を防げ、作り直す場合も影響の範囲が小さく済みます。

現場の担当者を最初から巻き込むと、使われるシステムになる

システムを実際に使う現場の担当者を検討の最初から巻き込むと、現場の手順に合った、使われるシステムになりやすくなります。
現場の手順や例外的な処理をいちばんよく知っているのは、毎日その業務をしている担当者だからです。

経済産業省の「2025年版ものづくり白書」の概要には、少人数ではデジタル化のプロジェクトが進まなかったことを踏まえ、社長をトップに各部門からメンバーを集めて推進した製造業の事例が紹介されています（出典：経済産業省「2025年版ものづくり白書」概要）。
決裁する経営者と現場の各部門の両方が加わる体制が、取り組みを前に進めた例です。

現場を巻き込む方法には、たとえば次のようなものがあります。

• 現場の担当者に、今の手順と困りごとを聞き取る
• 試作の画面を現場の人に触ってもらい、意見を集める
• 決裁する社長と、現場の担当者の両方が参加する場を設ける

情報収集を任された担当者だけで進めると、現場でしか分からない例外的な手順が抜け落ちやすく、気づくのが導入後だと作り直しの手間がかかります。

広げるときは、教え方と手順書で定着させる

ほかの業務や部署へ広げるときは、操作の教え方と手順書（マニュアル）を用意して、新しい手順を現場に定着させることが欠かせません。
最初に試した部署ではうまく使えていても、広げた先の部署で同じように使われるとは限らないためです。

製造業の現場では、教える側の人手も足りていません。
経済産業省「2026年版ものづくり白書」の概要では、製造業で人材育成に問題がある事業所の6割以上が、「指導する人材が不足している」を問題に挙げています（出典：経済産業省「2026年版ものづくり白書」概要）。
教える人に頼りきらず、手順書などで覚えられる仕組みが必要です。

定着させる工夫には、たとえば次のようなものがあります。

• 最初に試した部署の担当者が、ほかの部署に教える役を担う
• 画面の操作の手順を、短い手順書や動画にまとめる
• 使い始めの時期に、現場の声を集めて改善につなげる窓口を決めておく

費用はどう決まる？予算の目安と社内への説明の仕方

製造業のシステムの費用は一律の相場で決まるものではなく、対象にする業務の範囲と、既存のシステムや設備との連携、データの移行があるかどうかで大きく変わります。
予算は、公開されている目安を下限として見当をつけ、一部の業務から段階的に見積もっていくのが現実的です。

社内に予算を説明するときは、費用と一緒に「何がどれだけ良くなるか」を示す指標も用意しておきましょう。

費用は、対象業務の範囲と連携・データ移行の有無で大きく変わる

製造業のシステムの費用を大きく左右するのは、対象にする業務の範囲、生産方式の複雑さ、既存のシステムや設備との連携、使う人数と拠点の数、今のデータの移行の5つです。
どれも、作る画面や機能、確かめる作業の量を増やす要素にあたります。

5つの要素と、費用が上がりやすい例は次のとおりです。

費用を左右する要素	費用が上がりやすい例
対象にする業務の範囲（画面や機能の数）	在庫・販売・生産を一度にまとめて作る
生産方式の複雑さ	受注ごとに仕様や工程が変わる
既存のシステムや設備との連携	会計ソフトや工場の機械とデータをつなぐ
使う人数と拠点の数	複数の工場や拠点で使う
今のデータの移行	古いシステムのデータを整えてから移す

画面の数や利用人数といった規模で費用の区分を公開している開発会社もあり、自社の規模を当てはめると見当をつけやすくなります（出典：EPICs 業務改善のためのアプリ・システム受託開発サービス）。

中小製造業のデジタル化への支出は、100万〜1,000万円未満が最も多い

中小企業の製造業の2024年度のデジタル化への支出（投資額）は、100万〜1,000万円未満が約5割で最も多くなっています。
同じ規模の会社がどのくらいかけているかは、自社の予算を考えるときの参考の1つです。

日本政策金融公庫総合研究所の調査による、製造業の投資額の分布を表にまとめました（出典：日本政策金融公庫総合研究所「デジタル化に取り組む中小企業の実態に関する調査」2025年5月21日）。

2024年度のデジタル化への投資額	製造業の割合
100万円未満	34.2％
100万円以上1,000万円未満	48.4％
1,000万円以上1億円未満	16.6％
1億円以上	0.7％

この調査の投資額は、デジタルツールの導入費用に加え、システムの保守・運用、専門人材の獲得、従業員の教育などの費用も含む金額です。
システム1件の開発費用の相場ではないことと、調査の対象が日本政策金融公庫の取引先に限られることに注意してください。

公開されている費用は「段階ごとの下限」として読む

開発会社が公開している費用は、最低限の範囲で作った場合の下限の目安で、実際の金額は業務を聞き取ったあとの見積もりで決まります。
段階ごとに区切って費用を公開している会社もあり、その区切りに沿って考えると予算を立てやすいでしょう。

例として、運営会社である当社がDX・業務システム向けに公開している参考料金を示します。

段階・規模	内容	期間・費用の目安
業務診断	現状の把握、進め方の選定、段階的な導入の計画 （本開発を依頼した場合は全額充当）	30万円〜
一部業務のパイロット開発	対象業務を絞り、現場で効果と使い勝手を確かめる	50万円〜
小規模なシステム	〜15画面 〜1,000人想定	1ヶ月〜 80万円〜
中規模なシステム	31〜50画面 〜10,000人想定	3ヶ月〜 200万円〜
大規模・基幹システム	50画面〜 10,000人〜	4ヶ月〜 300万円〜

出典：EPICs 業務改善のためのアプリ・システム受託開発サービス

当社の参考料金は、いずれも「〜」の付いた下限の目安で、この金額に収まることを約束するものではありません。
一部の業務で試してから広げる進め方と組み合わせ、業務診断とパイロット開発から始めれば、最初の投資を小さく抑えられます。

初期費用だけでなく、使い続ける費用も含めて比べる

システムの費用は、導入するときの初期費用だけでなく、使い続ける間にかかる利用料や保守の費用も含めて比べましょう。
初期費用が安くても、使う年数が長くなるほど、後からかかる費用のほうが大きくなる場合があるためです。

使い続ける間にかかる費用には、次のようなものがあります。

• SaaSやパッケージの月額・年額の利用料と、利用人数が増えたときの増え方
• パッケージに追加開発した部分を、製品の更新のたびに直す費用
• 独自に開発したシステムの保守・メンテナンスの費用（不具合への対応、法改正や業務の変化に合わせた改修）
• サーバーやクラウドの利用料

比べるときは、何年使う前提かを先に決め、その期間の総コストで並べるのがコツです。
既製品は利用料がかかり続け、独自開発は初期費用がかかる一方で利用料の負担が小さい場合があるなど、期間をそろえると違いが見えます。

社内に説明するなら、着手前に効果を測る指標を決めておく

社内に予算を説明するときは、費用の見積もりと一緒に、導入で何がどれだけ良くなるかを測る指標（KPI）を着手前に決めて示すのが効果的です。
KPIは、取り組みの効果を数字で確かめるための指標のこと。費用と効果を並べて示すと、社長も投資に見合うかを判断しやすくなります。

指標がないまま始めると、導入後に効果を説明できません。
導入前の数値を先に測っておき、試したあとで同じ指標を比べることで、良くなったかどうかを示せます。

課題ごとの指標の例は、次のとおりです。

課題	指標の例
転記・二重入力が多い	1日の入力作業の時間 転記ミスの件数
在庫が合わない	帳簿と現物の在庫の差 欠品の回数
納期遅れが多い	納期どおりに出荷できた割合
原価が見えない	製品ごとの原価を出すまでの日数

経済産業省の「2025年版ものづくり白書」の概要によると、従業員規模が小さい企業では、デジタル技術を導入するきっかけとして経営者・役員の発案の割合が最も高くなっています（出典：経済産業省「2025年版ものづくり白書」概要）。
社長が自ら判断しやすいよう、導入前後の数字で効果を示すことが大切です。

どこに相談すればいい？相談先の種類と選び方

製造業のシステムの相談先は、パッケージのベンダー、SIer（システムインテグレーター。システムの構築を取りまとめて請け負う会社）、受託開発会社、ITコンサルの4つに分かれ、得意なことと提案の立場がそれぞれ違うのが特徴です。
自社がパッケージ寄りか、独自開発寄りか、まだ方向が決まっていないかによって、合う相談先は変わります。

デジタル化に取り組む中小企業の製造業では、59.3％が、デジタル化について外部に相談した先があると回答。
相談先がある企業（全業種）の相談相手では、ITベンダーが50.5％で最も多くなっています（出典：日本政策金融公庫総合研究所「デジタル化に取り組む中小企業の実態に関する調査」2025年5月21日）。

4つの相談先の違いは、次のとおりです（並び順に優劣はありません）。

相談先	得意なこと	向いているケース	気をつけたい点
パッケージのベンダー	自社製品の機能と導入の手順	使いたい製品の候補がある	提案は自社が扱う製品が前提になる
SIer	複数の製品や仕組みを組み合わせた全体の設計と取りまとめ	規模の大きい基幹システムを構築したい	小規模な案件に対応しているかを最初に確かめる
受託開発会社	業務に合わせた独自開発や、パッケージへの追加開発	既製品では業務に合わない部分を作りたい	得意な業種や規模が会社ごとに違う
ITコンサル	業務の整理、優先順位づけ、計画づくり	何から手を付けるか決められない	開発は別の会社に頼む形になることがある

パッケージのベンダーは、使う製品の候補があるときに向く

パッケージのベンダー（製品を開発・販売する会社や、その販売代理店）は、使いたい製品の候補があり、その製品を自社の業務に合わせて導入したいときに向いています。
自社製品の機能や導入の手順に詳しく、同じ製品の導入実績や、導入後のサポートの体制を持っているのが強みです。

一方で、パッケージのベンダーの提案は、基本的に自社の扱う製品を前提にしています。
ほかの製品や独自に開発する選択肢との比較は、自社でも行っておくと安心でしょう。

SIerは、複数の仕組みを組み合わせる大きな基幹システムに向く

SIerは、複数の製品や仕組みを組み合わせる、規模の大きい基幹システムの構築に向いています。
ERPや生産管理システム、既存のシステムとの連携を含めた全体の設計と、大人数での開発の取りまとめに慣れているのが強みです。

一方で、SIerには大きな案件を主に扱う会社もあるため、小規模な案件に対応しているかを最初に確かめておきましょう。
取りまとめを任せても、作る機能や条件を決める要件定義には、発注する側が主体的に関わる必要性が増しているとされています（出典：IPA「ユーザのための要件定義ガイド 第2版」）。

受託開発会社は、自社の業務に合わせて作りたいときに向く

受託開発会社（依頼を受けてシステム開発を行う会社）は、既製品では業務に合わない部分を、自社の業務に合わせて作りたいときに向いています。
特定の製品に縛られず、独自開発やパッケージへの追加開発を業務に合わせた範囲で提案しやすいのが強みです。小規模な案件から相談できる会社もあります。

受託開発会社で気をつけたいのは、得意な業種や規模が会社によってまちまちな点です。
現場の聞き取りや見学をするかなど、製造業の業務を理解しようとする姿勢があるかを確かめておきましょう。

作った会社にしか直せない状態を避けるため、契約の前に次の2点も確かめておきたいところです。

• 設計の資料、プログラムの中身（ソースコード）、データを自社で受け取れるか
• 作ったシステムの権利が、発注する側と開発会社のどちらにあるか

契約書の確認には、IPAが公開している「情報システム・モデル取引・契約書」が参考になります。
ユーザー企業とITベンダーのどちらかにメリットが偏らない契約書を目指したひな形です（出典：IPA「情報システム・モデル取引・契約書（第二版）」）。

なお、この記事は法律の助言ではないため、契約の内容は必要に応じて弁護士などの専門家に確認してください。

ITコンサルは、何から手を付けるかを整理したいときに向く

ITコンサル（企業のIT化の方針づくりや業務の整理を支援する会社）は、課題が多くて何から手を付けるか決められないときや、システム化の全体の計画を立てたいときに向いています。
特定の製品や作り方に縛られずに、業務の整理や優先順位づけ、要件の取りまとめを支援できるのが強みです。

一方で、ITコンサルの支援は方針づくりまでで、開発は別の会社に頼む形になることもあります。
支援の範囲と開発会社への引き継ぎ方は、依頼の前に確かめておくことが大切です。業務の整理の段階から、開発会社が一緒に進める形もあります。

相談先は立場で提案が変わるため、2種類以上に話を聞く

相談先は、扱う製品や得意な作り方によって提案の方向が変わるため、方向が決まっていない段階では、種類の違う相談先に2つ以上話を聞いて比べると判断しやすくなります。
ベンダーは製品を前提に、開発会社は作る方向で提案しがちなため、両方を並べると、既製品で足りる部分と作る部分が見えてくるでしょう。

社外の専門家だけでなく、身近な相手に相談する会社も少なくありません。
日本政策金融公庫総合研究所の調査では、相談先がある企業（全業種）の相談相手として、税理士・公認会計士が32.8％、自社の役員・従業員が27.7％でした（出典：日本政策金融公庫総合研究所「デジタル化に取り組む中小企業の実態に関する調査」2025年5月21日）。

相談の前には、課題の優先順位と効果を測る指標を1つの資料にまとめて渡すと、各社の提案を同じ条件で比べやすくなります。
商談で確かめたい質問は、システム開発の会社を選ぶときに商談で確かめる質問の記事にまとめました。製造業が集まる地域で相談先を探す方にも役立つ内容です。

製造業のシステム化を相談するならEPICs

EPICsは、現場の業務診断から開発、導入、現場への定着までを1社で支援する受託開発会社です。
業務診断で現場の実態や運用後に起きそうな課題、仕様の抜け漏れを先に洗い出してから、作るかどうかも含めて進め方を決めます。診断だけ、開発だけのご依頼も可能です。

進め方は、「現状把握→方針策定→パイロット→横展開（ほかの業務への展開）→継続改善」と段階を区切り、パイロットのあとに「拡げる・作り直す・止める」をお客様と一緒に判断します。

作り方は、業務固有の手順や独自の承認の流れはノーコード、書類の読み取り・要約・分類はAI駆動開発、基幹に関わる止められない部分はスクラッチと、業務領域ごとに使い分けるのが当社の方法です。
最終的な品質は、チームのレビューで担保します。

着手前には効果を測る指標（KPI）を設計し、測る仕組みをシステムに組み込むので、導入前後の比較を数字で示せるのも特徴です。

10年使う前提で保守しやすい構成で作り、業務の変化や法改正に合わせた改善と、公開後の保守まで長く伴走します。
ドキュメントを整備してコードとデータの所有権もお渡しし、移管しやすい状態を保つのも当社の方針です。

オプションで、操作の教え方や手順書の整備、現場の声を集める仕組みづくりといった現場定着の支援と、効果計測・経営報告の支援も行っています。

EPICsの開発実績は250件以上です。
北海道から沖縄まで全国の企業とオンラインで開発を進めてきた一方、近郊の企業で業種によっては、現場の確認や工程を見るために訪問することもあります。

まずは、今困っている業務と、いつまでに何を変えたいかを書き出してみてください。
それだけでも、相談先との話を具体的に進めやすくなります。

出典：EPICs 業務改善のためのアプリ・システム受託開発サービス／EPICs 受託開発サービス

生産管理システムとERP（基幹システム）は、何が違いますか？

扱う範囲と深さが違います。ERP（基幹システム）は、販売・購買・在庫・生産・会計など、会社全体の基幹業務の情報を1つにまとめて管理するシステムです。生産管理システムは、生産計画や資材の手配、工程の進み具合、実績や原価など、工場の「作る」業務に絞って細かく管理します。製造現場で作業を指示し、実績をその場で記録するのは、MES（製造実行システム）の役割です。中小企業では、ERPを入れずに、在庫管理や販売管理など業務ごとのシステムをつないで使う形もあります。

在庫管理や原価管理など、一部の業務だけシステム化しても意味はありますか？

はい、意味があります。課題がはっきりしている業務から始めるのは有効な進め方で、在庫が合わない、原価が見えないといった課題には、まず正しい数字をそろえる在庫管理や原価管理の仕組みが適した選択肢です。一部の業務で試して効果を確かめてから広げる形なら、合わなかったときも後戻りしやすくなります。ただし、将来ほかの業務とつなぐ可能性があるなら、今あるシステムや今後入れる仕組みと連携できるかを、導入の前に確かめておきましょう。

なぜシステムを入れても、効果が分からないまま終わることがあるのですか？

着手前に効果を測る指標を決めず、導入前の数値も測っていないため、比べる基準がないからです。

日本政策金融公庫総合研究所の2025年5月の調査では、デジタルツールの導入による業績全体へのプラスの影響について、中小企業の製造業の30.5％が「わからない」と答えています。防ぐには、入力作業の時間、転記ミスの件数、在庫の帳簿と現物の差、納期どおりに出荷できた割合などの指標を先に決め、導入前の数値を測っておくことが第一歩です。そのうえで一部の業務で試し、試したあとに同じ指標を比べれば、効果を数字で説明できます。

中小の製造業は、システムやデジタル化にどのくらい費用をかけていますか？

中小企業の製造業が2024年度にデジタル化に投じた金額は、100万〜1,000万円未満が48.4％で最も多く、100万円未満が34.2％、1,000万〜1億円未満が16.6％でした（日本政策金融公庫総合研究所の調査）。ただし、これはデジタルツールの導入費用に加え、システムの保守・運用や専門人材の獲得、従業員の教育などの費用も含む金額で、システム1件の開発費の相場ではありません。実際の開発費用は、対象にする業務の範囲、既存のシステムや設備との連携、データの移行の有無で大きく変わります。開発会社が公開している金額は、下限の目安として読むのが基本です。

納期遅れが多い場合、どのシステムから検討すればよいですか？

生産計画と現場の実績をつなぐ、工程管理や生産管理の仕組みから検討しましょう。現場の進み具合が紙の日報やホワイトボードでしか分からないと、遅れに気づくのが遅れ、急な割り込みの注文にも対応しにくくなるためです。作業を終えるたびに現場で実績を記録できれば、計画との差がすぐに分かり、段取りの組み替えや納期の相談を早めに行えます。補足：設備から稼働の状況や生産数を直接取り込みたい場合は、MES（製造実行システム）の領域になり、今ある設備とつなげられるかの確認が必要です。