個別受注生産管理システムの開発は、受注ごとに異なる仕様・納期・原価を製番でつなぎ、6フェーズで進めます。要件整理から定着まで、段階ごとに現場の確認を挟みながら進めます。
また、個別受注の現場では、設計変更後の図面が分からない、手配状況を追えない、見積と実績原価が合わないといった問題が起こりやすいです。
▼全体ガイドの記事
・個別受注生産管理システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
個別受注生産管理システム開発の全体像
個別受注生産とは、顧客ごとに仕様、数量、納期が異なる製品を、注文を受けてから設計・調達・製造する方式です。
機械装置や金型、治具、産業設備、試作機、特注部品などでは、製品コードと標準工程を前提にした見込生産向けの管理方法だと、情報が分断されやすいです。
個別受注に必要な管理単位
管理の中心になるのは、引合や見積を起点に発番する案件番号と製番です。受注後は、この製番に案件内の明細、図面や仕様の版、部品構成表（BOM）をひも付けます。さらに、工程や外注から検査結果、出荷、請求、実績原価まで、同じ製番にひも付けます。
- 受注変更時：最新版のBOMと図面だけでなく、発注残、工程指示、検査項目、見積原価まで連鎖して確認できる必要があります。
- よくある落とし穴：顧客がモーターの型式変更を依頼した場合、営業の受注情報だけを更新しても業務は完了しません。
一つの変更では、設計がBOMの版を上げ、購買が旧部品の発注残を確認し、製造が作業指示を差し替え、原価担当が見積との差額を把握する必要があります。そのため、この一連の履歴を同じ製番で追える構造が、個別受注生産管理システムの土台になります。
見込生産向けシステムとの違い
見込生産では、需要予測や在庫水準をもとに、あらかじめ決めた製品と工程を計画することが多いです。一方、個別受注では、受注のたびに仕様、納期、BOM、工程、仕入先、原価の前提が変わります。
- 選定の分かれ目：個別製番手配とMRP手配を混在できるか、類似品の構成を複写しながら変更履歴を残せるかです。
- オービックの例：個別受注型生産・販売管理テンプレートでは、個別製番と計画生産を併用するハイブリッド製造が示されています。
また、製番別・費目別の原価予算と実績管理、PDM（BOM）との連携も示されています。
自社にも標準部品や保守部品の計画生産もある場合は、個別受注だけに絞らず、両方の生産方式を一つのデータモデルで扱えるかを確認することが有効です。
先に決めるべき機能とKPI
個別受注の機能は、製番を軸に受注から原価確認までをつなぐ、次の5領域で整理できます。
- 案件・製番：引合・見積・受注管理、製番管理
- 設計・調達：BOMと図面の版管理、所要量計算、購買・外注
- 製造・納期：工程・負荷・納期管理、現場実績
- 原価・品質：見積原価と実績原価、品質・トレーサビリティ
- 基幹連携：販売・会計連携
機能は一覧の全部を作り込むより、業務シナリオごとに優先順位を決めるほうが現実的です。たとえば「受注変更時に旧版の指示を止められるか」「部品不足時に納期影響を見積もれるか」「完成後に案件別の粗利を説明できるか」といった問いに答えられるかで、必要な機能を選びます。
導入効果は、納期遵守率、見積粗利の予測誤差、仕掛在庫、原価締めにかかる日数、手配漏れ件数、設計変更の反映時間などで測ります。
「原価を見える化する」という目標は、具体的には、月次締め後にしか分からない案件原価を、受注時・製造中・完成時の3段階で確認できる状態にすることです。
この状態まで具体化しておくと、必要な入力と画面を絞り込みやすくなります。
個別受注生産管理システム開発の進め方
開発では、現行業務とデータのつながりを先に整理してから、適合する方式と範囲を決めます。
6フェーズは、要件整理から定着まで順に進みます。各フェーズで現場に確認する質問と成果物を決めます。
フェーズ1：要件整理による製番業務の洗い出し
最初に、営業の引合・見積から原価締めまでを一つの業務フローとして描きます。前半は受注、製番発行、設計、BOM確定までで、後半は購買、外注、製造、検査、出荷、請求の順に並べます。
- 工程ごとの受け渡し：部門をまたいで、各工程の「誰が」「いつ」「どの番号で」「どのデータを更新し」「次の部門へ何を渡すか」を一覧にします。
- 紙と個人台帳：紙の日程表や個人管理の台帳も、例外処理を含めて対象にします。
要件では、製番を受注明細単位で発番できるか、BOMを多階層で保持できるかを確認します。
要件には、図面と仕様書の版・承認履歴を残せるかも含めて確かめます。
発注残や外注先在庫を追えるかに加えて、材料費・外注費・労務費・経費を製番へ集計できるかも確認します。
要件は「必ず必要」「改善したい」「将来拡張」に分け、最初のMVPは案件、製番、工程、原価などKPIに直結する範囲へ絞ります。
フェーズ2：選定でのFit to Standardの判断
候補を選ぶときは、機能数や知名度より、自社の業務シナリオが標準機能で成立するかを見ます。
- デモの進め方：実案件を使い、受注後の図面変更、部品欠品、外注先への支給を試します。
- 後工程の確認：納期の前倒しや分納請求、完成後の見積原価と実績原価の比較も確認します。
パッケージやクラウドに業務を合わせるFit to Standardには、短期導入とアップデートを受けやすいという利点があります。ただし、法令や顧客監査、競争優位に直結する独自工程まで無理に変える必要はありません。標準で対応できない要件は、運用変更、アドオン、API連携、スクラッチの順に代替案を比べ、カスタマイズを最小化できるかを判断します。
フェーズ3：設計・開発でのデータ連携の確定
設計では、画面の見た目より先に、マスタと履歴の中身を定めます。マスタには、案件番号、製番、品目、BOM、工程があり、仕入先、作業者、原価要素なども含みます。履歴には、受注、設計変更、発注、実績、検査を残す形になります。
- 案件と製番の関係：同じものとして扱うのか、案件の中に複数の製番や分納明細を持たせるのかを決めないと、後で原価や請求の集計が崩れます。
- 外部連携：会計、販売管理、CAD・PDM、WMS、EDI、IoT端末が対象です。連携方向や頻度、再送の扱い、責任分界を仕様書に書きます。
工場設備とつなぐ場合は、ITネットワークとOTネットワークの分離、ゲートウェイ経由の収集、端末の認証と権限を設計段階で決めます。2025年4月に経済産業省が中小製造事業者向けの工場セキュリティ解説書を公表しているため、便利さだけでなく停止時の影響と復旧方法も要件に含めます。
フェーズ4：テストでの異常系と移行データの検証
テストでは、要件単位の単体テスト、連携を含む結合テスト、業務担当者が行う受入テストを分けて、受注から請求までの一連のシナリオで確認します。例外的な場面では、権限不足、通信断、連携エラーも含めて再現し、エラーが誰に通知され、どの画面から復旧できるかまで検証します。
- 業務の例外：設計変更、部品欠品、外注遅延、特急、分納、返品などを再現します。
- 移行テスト：移行対象の項目を洗い出し、重複や表記ゆれを先に整理します。
移行対象には、品目、仕入先、顧客、BOM、図面版があり、未完了製番、発注残、在庫、原価残高も含まれます。旧Excelの値は、そのまま取り込まず、製番の採番規則とマスタコードを統一してから移します。
まず、一拠点または一製品群で試行し、移行件数、金額、在庫数量、未完了案件数を照合したうえで、切戻し条件と並行稼働期間を決めます。
フェーズ5：稼働での現場停止の回避
稼働日は、全社一斉に切り替える方法と、拠点・製品群・業務の単位で段階導入する方法を比較します。
- 仕掛案件の扱い：個別受注では仕掛中の製番が多いため、切替日前に受注した案件を旧運用で完了させるか、新システムへ移すかを案件単位で決めます。
- 新旧併用時の備え：新旧で同じ製番を二重発番しないルール、障害時の紙伝票、緊急発注の承認者も準備します。
稼働判定では、ログインできるかより、当日の業務が予定時間内に完了するかを見ます。対象は、受注登録、製番発行、発注、作業実績です。検査、出荷、請求も含めます。
マスタの登録漏れやバーコード端末の通信不良は稼働直後に起きやすいため、問い合わせ窓口、優先度、一次回答時間、ベンダーの復旧目標を明確にします。
フェーズ6：定着での入力と改善の習慣化
定着では、システムの操作研修に加えて、入力する理由と、入力しなかった場合の影響を部門ごとに説明します。
- 営業・設計・購買：営業には納期回答と見積粗利、設計には最新版BOM、購買には手配漏れと納入予定を示します。
- 製造・経営：製造には作業指示と実績、経営には製番別の採算を示すと、現場の納得を得やすくなります。
稼働後1か月、3か月、6か月のレビューを設定し、入力率、手配漏れ、納期遵守率、原価締め日数を確認します。
AIによる納期予測や見積支援は、製番・原価・工程実績のコードが揃ってから、段階的に導入します。改善要望は、法令や安全に関わるもの、業務停止を防ぐもの、KPIに効くもの、便利機能の順に優先順位を付けます。
個別受注生産管理システムの費用相場とコストの内訳
費用は、会社規模、拠点数、ユーザー数、BOMの複雑さで大きく変わります。API連携やデータ移行、現場端末、カスタマイズの範囲も、費用を左右します。
以下は、2026年時点の公開価格と製造業務システムの公開情報をもとに整理した初期仮説です。推定レンジには個別受注案件全体の統計ではないものも含まれるため、予算取りに使い、発注額を断定する材料にはしないことが大切です。
導入形態別の費用レンジ
小規模なクラウド・SaaS導入は、初期0万〜50万円、月額3万〜10万円程度が比較の出発点になります。
- 例外となる製品：TECHS-S NOA（個別受注型機械・装置業向け）は、初期費用の最小構成が125万円から、月額利用料が4万5,000円からです。
- 表示の条件：価格は税別で、ユーザーアカウント数やオプション、ハードウェア・対応機器などにより変動します。
TECHS-S NOAは公式価格が示されている製品のため、安価なSaaSの一般論と同列には扱えません（出典: 株式会社テクノア「TECHS-S NOA 価格・動作環境」、2026年2月更新）。
パッケージの標準導入は、中小企業の初期仮説として100万〜500万円程度、製造業務システム全体の一般的なレンジでは100万〜1,000万円程度が目安になります。会計・CAD・PDM・WMS・EDIとの連携や複数拠点対応が加わると、500万〜1,500万円程度の推定レンジも検討対象です。
独自工程を深く組み込むフルスクラッチは、1,000万円から数億円まで幅があり、規模と要件を分けて見る必要があります。
見積に含めるべき初期費用の内訳
初期費用は、ライセンスまたは利用開始費、要件定義、基本設計・詳細設計、設定・開発で区切って確認します。さらに、外部連携、データクレンジングと移行、テスト、教育、稼働支援も、別の項目として扱います。
- 周辺機器と設定：現場端末、バーコードリーダー、プリンター、ネットワーク、バックアップ、セキュリティ設定が別見積になっていないかも確認します。
- 一式表記：特に「移行一式」「導入支援一式」とだけ書かれた項目は、対象データ、件数、作業回数、検証方法を具体化します。
スクラッチや追加開発では、要件定義を含む人月、設計・開発、結合テスト、受入支援、プロジェクト管理を分けると比べやすいです。開発費だけが安く見えても、設計変更の追加費用、データ移行の再実施、障害対応、バージョンアップ、法改正対応が別料金なら、総額は変わります。
契約前に、変更管理の単価と、納品後に誰がどこまで保守するかを確認します。
月額・保守を含む5年TCOでの比較
クラウドは初期費用が低く見えやすい一方、ユーザー数、オプション、追加ストレージが月額や別契約に含まれることがあります。連携、サポート、端末費も、同様に含まれる場合があります。
- パッケージやスクラッチ：初期投資が大きくても、利用料、サーバー、保守、バックアップ、アップデート、障害対応の費用が別に発生します。
- 比べ方：初期費用だけでなく、導入時、1年後、3年後、5年後の累計を同じ条件で試算します。
保守費は、初期導入費の年5〜15％、または開発費の年15〜25％という一般的な仮置きがされることもありますが、契約条件によって異なります。仮置きの数字を相場として断定せず、問い合わせ対応時間、障害復旧、法改正、脆弱性対応、バックアップ復元、データ抽出の範囲を見積書で確認します。
見積は、必要な業務を5年間安定して運用できる総額で比べます。
個別受注生産管理システムの見積ポイント
見積の精度は、発注先の提案力だけでなく、発注側が業務とデータの前提をどれだけ伝えられるかで決まります。
仕様書には、機能名を並べるだけでなく、製番を軸にした業務シナリオを記します。あわせて、対象拠点・ユーザー・品目数、現行データ、連携先を書きます。移行範囲と導入後のKPIも記します。
候補各社へ同じ条件を提示すると、価格と提案範囲を比較しやすくなります。
RFPに書くべき業務シナリオと質問
RFPには、個別受注の適合性を見極めるための業務シナリオを、次のように記載します。
- 受注後の仕様変更時に、旧版の図面・BOM・作業指示・発注残をどう扱うか。
- 類似品のBOMを複写したとき、何を承認するか。
- 材料不足や外注遅延が納期へ与える影響をどう確認するか。
- 有償支給・無償支給の在庫と消費差異をどう管理するか。
- 分納や返品を、製番原価と請求にどう反映するか。
これらの質問に答えられるかどうかで、候補製品の強みと弱みが見えてきます。さらに、APIやCSVの仕様、会計・CAD・PDM・WMSとの連携、権限と監査ログについても質問します。
データの保管場所、バックアップと復元、障害時の連絡経路、脆弱性対応、法改正時の責任分界も、あわせて確認します。電子取引データを扱う場合は、国税庁が案内する電子取引関係の保存要件や検索性を確かめます。法定保存対象や適用時期は、税務担当者・専門家と擦り合わせます。
デモ・PoCでの正常系以外の確認
提案書の内容だけで判断せず、自社の実案件を使ってデモまたはPoCを行います。
- 営業と設計：営業担当者が見積を登録し、設計担当者が図面とBOMの版を更新します。
- 購買と製造：購買担当者は発注残を確認し、製造担当者は実績を入力します。
経理担当者が製番別原価を確認するところまで、一つの案件で通します。入力者が変わるたびにExcelへ戻る場合は、システム間の境界に課題が残っています。
PoCの合格条件は、操作感の良さだけでなく、データの正しさ、権限、履歴、連携エラーからの復旧、処理時間で定めます。たとえば「設計変更を登録してから、影響する発注残と工程を10分以内に確認できる」「分納後も未出荷数量と製番原価が一致する」など、業務結果で測れる条件にします。
ベンダーのサンプルデータだけで評価せず、自社のデータで試すことが大切です。
開発会社の実績と責任範囲の確認
開発会社は、製造業の導入社数だけでなく、自社に近い業種の実績を確認します。
- 実績と体制：機械・金型・設備・部品加工などの実績、個別受注と見込生産の混在経験、要件定義を共同で進める体制を確かめます。
- テクノアの製品：TECHS-S NOAは個別受注型の機械・装置業向けで、公開価格があります。
フューチャー・ワンのInfiniOne ERPは個別受注と見込生産の両方に対応し、有償・無償支給や外注先在庫の管理を掲げています。製品の方向性が自社の課題に近いかを、公式情報と実デモの両方で判断します。
中堅以上で設計・生産・購買・経理を横断したい場合は、オービックのようにPDM（BOM）、製番別原価、個別製番手配とMRP手配の混在を掲げる製品も候補になります。
ただし、公式サイトの機能説明や導入社数は、自社への適合や導入効果を保証するものではありません。そのため、プロジェクト責任者、移行担当、教育担当、保守窓口、障害時の復旧責任を、提案書と契約書で確認します。
過剰なカスタマイズと導入リスクの抑制
カスタマイズを増やすほど、初期費用だけでなくテスト範囲、アップデート影響、保守負担も増えます。
- 再現の範囲：既存帳票を完全に再現する、個人ごとのExcel操作をそのまま画面化するといった要望は、業務上の必須条件か、慣れの問題かを分けて検討します。
- 標準との差：競争優位にならない部分は標準へ寄せ、差別化につながる工程や判断だけを追加開発の候補にします。
工場のシステムでは、停止が製造・出荷・取引先へ波及する可能性があります。経済産業省は2025年4月、中小規模の製造事業者向けに、工場セキュリティの重要性と始め方を具体的な事例・手順とともに示しました。
導入時は、アカウント管理、最小権限、端末更新、ネットワーク分離を確認します。そのうえで、バックアップ、復元訓練、委託先の責任分界も確かめます。便利な連携機能を先に増やさないようにします。
個別受注生産管理システム開発でよくある質問
個別受注のシステム開発では、費用だけでなく、自社の例外処理や移行のしやすさ、現場で使い続けられるかも判断材料になります。導入前によく相談される疑問について、実務上の考え方を示します。
個別受注生産管理システムはパッケージとスクラッチのどちらがよいですか？
まずは個別受注の標準機能があるパッケージやクラウドを比較し、独自工程や競争優位に関わる部分だけを追加開発する方法が現実的です。
パッケージで製番、BOM、工程、原価、外注、変更履歴を無理なく扱えるなら、スクラッチより短期間で始めやすく、アップデートも受けやすいです。
標準製品で業務の核心が成立しない場合に、ハイブリッド構成やスクラッチを検討します。
個別受注生産管理システムの開発期間はどれくらいですか？
標準機能中心のクラウド導入は1〜3か月、パッケージ標準導入は3〜6か月、連携や追加開発を含む導入は6〜12か月程度が初期検討の目安です。
これは、個別受注案件の全社導入に共通して保証される期間ではありません。拠点数、移行データ、現場端末、受入テスト、並行稼働によって変わります。
見積では、要件定義から稼働後支援までの工程と、発注側が準備する作業を分けて確認します。
Excelから個別受注生産管理システムへ移行できますか？
移行はできますが、Excelファイルをそのまま取り込めば完了するわけではありません。まず、顧客、品目、仕入先、BOM、図面版を整理します。在庫、未完了製番、発注残も整えたうえで、重複・表記ゆれ・欠損を直してから移行します。
過去データをすべて移すのか、未完了案件と直近の実績だけを移すのかを決め、一拠点や一製品群で移行リハーサルを行うと切替リスクを抑えられます。
設計変更が多い会社でもシステムを定着させられますか？
定着させるには、変更の影響範囲を確認して承認する流れを、システムに組み込みます。変更前後の図面・BOM・工程・発注・原価を製番で追い、旧版の指示が現場に残っていないかを確認します。
変更が起こる実案件でPoCを行い、設計、購買、製造、品質、営業が同じ判断基準を持てるようにすることが有効です。
まとめ：6フェーズによる個別受注生産管理システムの定着
開発では、機能を増やす前に、受注から製番、BOM、設計変更までの流れを定義します。さらに、購買・外注、工程、検査の流れも定めます。原価と出荷・請求の流れは、次のとおり定めます。
- 原価：見積との差額を製番で把握する流れ
- 出荷・請求：出荷から請求までを同じ製番で追う流れ
この流れを押さえることが、個別受注生産管理システム開発の基本です。
見込生産向けの標準工程だけでは扱いにくい仕様変更、特急、分納、支給品、外注遅延も、実案件で確認します。
導入を成功させる6つの判断
まず、要件整理では製番業務とKPIを一覧にし、選定ではFit to Standardとカスタマイズの境界を決めます。
次に、設計開発ではマスタ、履歴、外部連携、権限、セキュリティを固め、テストでは設計変更や欠品などの異常系と移行データを検証します。
最後に、稼働では仕掛案件と切戻し条件を管理し、定着では利用部門ごとの効果を測定して、段階的に改善します。
最初に準備する資料
最初の一歩は、代表的な案件を3〜5件選ぶことです。その案件について、見積から完成までの帳票やExcel、図面、BOMを集めます。発注、実績、検査、請求、原価の記録も含めます。
- 提案の前提整理：案件ごとの違いと共通部分を整理してRFPに反映し、複数社のデモと見積を同じ条件で比較します。
- 価格以外の観点：5年TCOや移行・教育・保守、現場の入力負担を含めて判断し、将来のデータ活用や障害時の復旧も対象にします。
▼全体ガイドの記事
・個別受注生産管理システム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。