製番管理システム開発の発注/外注/依頼/委託方法について

製番管理システムの発注・外注は、製番を案件の親キーとして受注、BOM、設計変更、購買、工程、外注、品質、原価、出荷までをつなぐ要件を固めてから、方式と委託先を選ぶことが成功の近道です。

「パッケージを導入するのか、スクラッチ開発するのか」「RFPには何を書けばよいのか」「見積金額の差はどこから生まれるのか」と迷う担当者は少なくありません。この記事では、製番管理システムを発注・外注・委託する際の進め方を、発注形態、要件整理、RFP、契約、費用相場、委託先の比較、受入テストまで順番に解説します。親記事の全体像とあわせて読むことで、自社に必要な範囲を過不足なく整理できます。

▼全体ガイドの記事
・製番管理システム開発の完全ガイド

製番管理システムの発注・外注で押さえる全体像

製番管理システムの発注で大切なのは、画面の数や機能の多さではなく、受注した一つの案件が出荷・請求・原価確定まで途切れず追えることです。製番を採番するだけでは、設計変更や共通部品、外注戻り、分納といった現場の例外を処理できず、結局はExcelや電話が残ります。

製番管理では、受注明細や製造案件ごとに一意の番号を付け、その番号に設計図面、個別BOM、部材の手配、作業実績、検査結果、外注先、出荷先、売上、実際原価をひも付けます。装置や機械のように受注ごとに仕様が変わる個別受注生産では、品番やロットの総量だけで管理するより、製番単位で追跡するほうが現場の判断と経営の採算管理を一致させやすいです。

発注時には、親製番と子製番の関係、共通部品を複数案件に引き当てる方法、再加工や返品時の扱い、設計変更前後の版数、原価を締める時点まで決めます。これらを曖昧にしたまま開発会社へ依頼すると、完成後に「このケースだけ登録できない」「原価が合わない」という追加開発が発生します。

発注の目的は「製番管理システムを導入すること」ではありません。たとえば、製番別の見積原価と実績原価の差異を月次で確認する、設計変更の伝達時間を短縮する、外注品の納期遅延を早く検知する、仕掛在庫を製番別に把握するといった経営・現場の成果に置き換えます。納期遵守率、製番別粗利、購買リードタイム、実績入力の当日登録率など、導入前後で比べられるKPIを二つから四つに絞ると、要件の優先順位も決めやすいです。

一方で、標準品を同じ条件で繰り返し生産する企業が、すべての業務を製番方式へ変更する必要はありません。ロット管理や品番別の総量管理が適する工程もあるため、製番、ロット、シリアル番号をどの業務で使い分けるかを最初に判断します。

発注形態はどれを選ぶべきですか？

発注形態は、標準クラウド、製造業パッケージ、半完成品のカスタマイズ、フルスクラッチの四つに分けて検討すると整理しやすいです。結論として、製番管理の中心機能はパッケージや半完成品で早く稼働させ、独自性が高い現場入力や連携だけを追加開発する構成が、費用と適合性のバランスを取りやすい傾向があります。

クラウドSaaSは、サーバーの購入やOSの更新を発注側が抱えにくく、利用開始までの期間を短くしやすい方式です。複数拠点で受注、製番、購買、進捗を共有したい企業や、まず一つの工場で小さく始めたい企業に適しています。現場でスマートフォンやタブレットから実績を登録できるか、QRコードやバーコードに対応するか、図面を安全に参照できるかをデモで確認します。

ただし、SaaSの料金はサービスごとに課金単位が異なります。ユーザー数、拠点数、外部連携、保守支援、データ保存量、追加帳票が別料金になることがあるため、月額だけで比べず、五年間の総保有コストで比較します。GENは公式サイトで製番管理、外注管理、原価管理、API連携、モバイル実績登録を案内し、GEN TRADINGについて月額23,500円からと表示していますが、これは同プランの公開例であり、製造向けプランの価格や導入支援費は別途確認が必要です（出典: GEN株式会社公式サイト、2026年確認）。

製造業パッケージは、受注、製番、BOM、MRP、購買、外注、工程、品質、原価など、製造現場で共通する機能を組み合わせて導入する方式です。日立システムズのFutureStageや三菱電機デジタルイノベーションのFactory-ONE、クラステクノロジーのQuickCIMなど、個別受注や製番を意識した製品が公開されています。大切なのは製品名の知名度ではなく、製番別BOMの版数、設計変更、子製番、個別原価、外注戻りが標準機能で扱えるかを確認することです。

パッケージは、業務を標準機能に合わせる範囲を決められると、開発期間と保守負担を抑えやすいです。逆に、既存帳票や社内独自の承認をすべて再現しようとすると、アドオンが増えてアップデート時の検証も重くなります。競争力に直結しない帳票や申請は標準機能やローコードへ寄せ、独自の見積計算や原価配賦だけを作り込む判断が現実的です。

半完成品は、受注生産向けの基本機能を土台に、見積計算、帳票、ワークフロー、外部連携などを自社仕様へ調整する方式です。マキナフローは公式サイトで半完成品とカスタマイズの価格総額を400万円から、フルスクラッチ開発を1,500万円から、導入までを6か月から1年以上と案内しています。これは一社の公開価格であり市場平均ではありませんが、方式の違いによる初期費用と期間を考えるための具体例になります（出典: マキナフロー公式サイト、2026年確認）。

フルスクラッチは、独自の製番別原価、特殊な工程計画、設備とのリアルタイム連携、複雑な親子製番を競争力の中心にする企業向けです。ただし、発注側にも業務を決める責任者、受入テストの担当者、リリース後の運用管理者が必要です。方式を決める際は、「自社固有で残す機能」と「業界標準に合わせる機能」を一覧にして、機能ごとに費用、納期、将来の保守性を比較します。

発注前の要件整理とRFPはどのように作りますか？

RFPは、システム会社に希望を伝える資料ではなく、各社が同じ条件で提案と見積を作るための基準書です。機能一覧だけでなく、現状の業務、対象範囲、データ、制約、運用体制、成果指標、提案してほしい内容まで書くと、価格差の理由を比較しやすくなります。完璧な仕様書を作る必要はありませんが、業務上の事実と希望を分けて記載します。

最初に、営業の見積・受注、設計の図面とBOM、購買の発注、外注の支給と受入、製造の指示と実績、品質の検査、倉庫の入出庫、出荷、請求、経理の原価締めを一枚の業務フローにします。各工程で「誰が」「いつ」「どの番号を使い」「何を登録し」「次の部門へ何を渡すか」を書き、Excel、紙、メール、基幹システムなど現在の情報源も併記します。

とくに、分納、追加工、再加工、代替部品、共通部品、外注先からの戻り、設計変更、欠品、廃棄、返品を実例で確認します。通常の一件だけを見ていると、最も費用がかかる例外処理が要件から抜けます。過去に問題が起きた案件を三つから五つ選び、システム上で最後まで追跡できるかを発注前の評価シナリオにします。

機能要件では、製番の発番規則、親子関係、重複防止、BOMの版数と変更履歴、所要量計算、在庫引当、購買・外注手配、工程進捗、作業時間、検査、不適合、出荷、製番別の材料費・労務費・外注費・間接費を明記します。製番から構成部品、仕入先、作業者、検査記録、出荷先へ戻れるトレーサビリティを、検索画面だけでなく帳票とデータ出力でも確認します。

非機能要件では、利用者数、拠点、稼働時間、応答時間、バックアップ、権限、監査ログ、データ保存期間、障害時の復旧目標、通信断時の現場入力、API・EDI・会計・WMS・CAD/PDMとの連携方式を指定します。工場をネットワークにつなぐ場合は、IT部門だけでなくOTや設備ネットワークの分離、アカウント管理、脆弱性対応、ログ監視、操業継続も対象にします。経済産業省は2025年4月、中小規模の製造事業者向けに工場セキュリティの具体的な手順や事例を示す解説書を公表しています（出典: 経済産業省「工場セキュリティの重要性と始め方」、2025年）。

提案説明では、ベンダーが用意した標準デモだけで判断しません。自社の実案件を匿名化し、一つの製番を発番して、受注明細、個別BOM、設計変更、部品の所要量、外注発注、入荷、作業実績、検査、分納、原価確定までを通します。その場で入力する人を営業、設計、購買、製造、品質、経理から出すと、担当者によって画面やデータの見え方が違う問題にも気づけます。

PoCでは、成功条件を数値にします。たとえば、製番から構成部品と外注品を三分以内に検索できること、設計変更の版数と承認者を履歴から確認できること、実績入力後に製番別原価へ反映されること、通信が一時的に切れても登録データを失わないことなどです。できなかった項目は、標準、設定、追加開発、業務変更のどれで解決するかを提案書に書いてもらいます。

契約形態とプロジェクトの進め方はどう決めますか？

製番管理システムは、要件が固まっている部分と、現場で試さなければ決められない部分が混在します。そのため、契約を一括で結ぶか、要件定義と開発を分けるか、準委任で伴走してもらうかを、開発の不確実性に合わせて決めます。契約名だけでなく、成果物、検収条件、変更手続き、責任分界、知的財産、データ返却、保守の範囲まで文書にします。

請負契約は、合意したシステムや成果物を完成させ、検収することを中心に置く契約です。要件、画面、帳票、連携、テスト仕様、マニュアル、移行データ、納品形式が十分に定義されている場合は、予算と完成条件を管理しやすいです。製番別原価の計算方法や例外処理が未確定なのに固定価格だけを求めると、見積にリスク費用が上乗せされるか、後から変更契約が増えます。

請負で発注する場合は、検収を「動けば完了」とせず、実案件を使った受入テストの合格条件にします。製番の重複、版数の不整合、外注品の未入荷、作業実績の訂正、分納、返品、原価締めなど、事前に決めたシナリオを満たすことを検収条件へ落とします。瑕疵対応の期間や、修正と追加要望をどう区別するかも契約書と仕様書で一致させます。

準委任契約は、専門家の知識や作業の提供を受ける形で、要件定義、現状分析、PoC、プロジェクト管理、運用改善などに向きます。現場を見ながら製番の採番規則や原価の締め方を決める段階では、作業時間や体制を合意し、会議体、成果物、報告方法、課題の扱いを明確にします。準委任だから成果物が不要なのではなく、業務フロー、要件一覧、試験計画、意思決定記録などの納品物を定義することが重要です。

要件定義を準委任で進め、確定した範囲を請負で開発する分割方式も選択肢です。発注側が判断を先送りしたまま準委任を長期化させると、毎月の費用だけが積み上がります。各フェーズの終了条件と、次の契約へ移る判断基準を設定し、月次で予算、課題、未決事項、変更要求を見直します。

製造現場では、発注後に対象工程や帳票が変わることがあります。変更を口頭やチャットだけで進めず、変更理由、対象製番、影響するBOM・画面・連携、追加工数、納期、費用、承認者を変更管理票へ記録します。設計変更で過去の製番データをどう扱うか、変更前の版を参照できるか、すでに発注した外注品へどう伝えるかも、システムとプロジェクトの両方で管理します。

外注先に製造や検査を委託する場合は、システム開発契約とは別に、委託内容、納期、検査、支払、再委託、情報管理、図面の利用範囲を整理します。2026年1月に取適法が施行され、対象取引では発注内容などの明示、記録保存、受領後60日以内の支払期日などが求められます。公正取引委員会は2026年6月の中部地区の運用状況で、措置822件、うち支払遅延275件、代金減額204件、買いたたき112件を公表しています（出典: 公正取引委員会「令和7年度における中部地区の取適法の運用状況等について」、2026年）。対象となるかは取引内容と資本金・従業員基準で変わるため、法務や経理と確認します。

製番管理システムの費用相場と見積の内訳

製番管理システムに全国共通の公定価格はありません。費用は、製番数、拠点数、ユーザー数、BOMの複雑さ、既存システムとの連携、現場端末、移行データ、カスタマイズ、教育、保守で大きく変わります。以下は、製造業の業務システムに関するリサーチノートの整理と公開価格例から作った2026年時点の検討レンジであり、発注前の予算取りに使う目安です。

クラウドSaaSの標準設定は、初期費用0〜60万円程度という一般的な検討目安がありますが、月額、初期設定、データ移行、導入支援を含むかで変わります。製造業パッケージはライセンスと設定で数十万〜数百万円、製番対応や連携を含めると300万〜1,500万円程度、半完成品のカスタマイズは500万〜2,000万円程度、フルスクラッチは小規模300万〜1,000万円、中規模1,000万〜5,000万円、大規模では5,000万円超になる可能性があります。これらは製番管理だけの市場統計ではなく、要件量から整理した推定レンジです（出典: NotebookLM Q&A「生産・製造」およびリサーチノート、2026年）。

同じくリサーチノートで整理した期間の目安は、標準SaaSの即日〜数週間、パッケージの1〜6か月、半完成品の3〜9か月、スクラッチの小規模3〜6か月・中規模6〜12か月・大規模12か月以上です。公開価格と自社の見積は一致しないため、相場から外れていると感じた場合は、金額の高低よりも、対象範囲、前提条件、含まれない作業を確認します。

見積書では、要件定義、基本設計、画面・帳票、製番とBOM、購買・外注、工程・実績、品質、原価、API・EDI、権限・監査ログ、データ移行、テスト、教育、並行稼働、リリース、保守を分けてもらいます。単に「システム開発一式」と書かれている見積は、安く見えても比較できません。各項目の工数、担当ロール、単価、前提、除外事項、追加時の単価を確認します。

ノート内のQ&Aでは、業務システム費用の約60〜80％が人件費となり、PMは90万〜150万円、SEは65万〜110万円、PGは50万〜90万円の一人月単価が目安として整理されています。これは個別案件の相場を断定する数字ではなく、体制と工数を読むための参考値です（出典: NotebookLM Q&A「生産・製造」、2026年）。保守運用は初期費用の年15〜25％程度を見込み、障害対応、法改正、脆弱性対応、バックアップ、問い合わせ、アップデート検証がどこまで含まれるかを確認します。

クラウドは初期費用が低く見えやすい一方、月額、ユーザー追加、連携オプション、データ移行、教育、サポートが継続します。買い切り型は月額がない場合でも、サーバー、OS、データベース、脆弱性対応、バージョンアップ、保守要員が必要です。五年間のライセンス・開発費、移行、教育、運用、保守、追加開発、終了時のデータ取り出しを合計すると、安い初期見積が必ずしも安いとは限りません。

比較表を作る際は、初期費用、月額・年額、導入支援、追加開発、連携、端末、教育、保守、障害時の費用、契約終了時のデータ返却を同じ欄に置きます。補助金を利用できる可能性があっても、採択や対象経費を前提にせず、補助なしで成立する予算を作ってから検討します。

委託先の選び方と見積比較のポイント

委託先は、会社規模や価格だけでなく、個別受注生産と製造現場を理解しているかで選びます。開発会社、パッケージベンダー、導入コンサルティング会社では得意領域が異なるため、RFPへの回答を同じ評価軸で採点し、提案時の担当者が導入後も関わるかまで確認します。

「製造業に多数の実績がある」という説明だけでは不十分です。個別受注、受注組立、繰返生産、ロット生産のどれか、製番別原価を使っているか、図面・BOMの変更履歴をどう管理したか、外注や複数拠点をどう連携したかを聞きます。可能なら、同規模・同業態の利用者から、導入期間、追加費用、現場定着、障害時の対応、導入後の保守について事実ベースで確認します。

事例を見るときは、導入前の課題、導入範囲、利用者数、稼働までの期間、導入後の変化が書かれているかを確認します。「見える化した」「効率化した」という表現だけでなく、納期回答の時間、実績入力の締め、棚卸し、原価差異の確認など、自社のKPIに近い変化があるかを見ます。ベンダーの自社発表である場合は、その点も踏まえて評価します。

相見積もりは、二社から四社程度へ同じRFPを渡し、質問の受付期間と回答期限をそろえると比較しやすいです。見積書は、要件定義費、開発費、ライセンス、移行、連携、テスト、教育、稼働支援、保守を分け、標準・設定・追加開発・対象外の区分を付けてもらいます。安い提案が、データ移行や受入テストを発注側の作業として除外していることもあるため、金額の下だけで判断しません。

評価シートには、要件適合度、製造業・個別受注の経験、提案の具体性、担当者の体制、スケジュールの妥当性、費用の透明性、保守・障害対応、セキュリティ、データの可搬性を入れます。製番別BOMの版数管理は標準か、共通部品を複数製番へ引き当てられるか、製番別実際原価をいつ締めるか、通信断時に実績を登録できるか、APIと追加開発費はいくらかという質問は、比較の差が出やすいです。

システムは稼働してからが本番です。問い合わせ窓口、障害の優先度、一次回答と復旧の目標、休日や夜間の対応、アップデート、脆弱性情報、バックアップ、データ復旧、操作教育の責任者を契約前に確認します。工場の停止が許されない時間帯がある場合は、メンテナンス可能な時間と代替運用を決め、復旧訓練も計画します。

発注側の役割も見積に含めます。現場から要件を集める業務責任者、判断を下す経営・部門責任者、マスタと移行データを整える担当者、試験を実施するユーザー、稼働後の管理者を決めます。委託先に丸投げすると、業務ルールの決定が遅れ、追加費用とスケジュール延長につながります。週次の課題管理、月次の経営報告、変更承認の会議体を作り、決定を記録します。

発注後の受入テストと運用定着はどう進めますか？

開発会社を選んだ後は、要件定義、設計、開発、テスト、教育、移行、並行稼働、リリースの順に進めます。全社一斉に切り替えるより、まず一工場や一つの製品群で製番発番から出荷・原価までを通し、課題を修正してから対象を広げるほうが、製造ラインへの影響を抑えやすいです。

受入テストでは、受注から製番発番、BOM展開、購買・外注、入荷、工程実績、品質検査、出荷、請求、原価締めまでを、実際に近いデータで確認します。正常系だけでなく、設計変更、部品欠品、代替部品、外注納期遅延、再加工、分納、返品、入力訂正、権限不足、通信断、連携エラーを試します。試験結果、証跡、未解決の不具合、回避策、再試験日を残し、合格基準を満たしたことを責任者が承認します。

マスタ移行も別の重要な試験です。品目、取引先、仕入先、工程、単価、在庫、BOM、過去の製番、図面、原価実績を何年分移すか、欠損値や重複をどう扱うかを決めます。移行後に製番から過去の記録へ戻れるか、旧システムと新システムの残高が一致するかを照合し、移行リハーサルを本番前に複数回行います。

教育は操作説明会を一度開くだけで終わらせません。営業、設計、購買、製造、品質、経理の役割ごとに、実案件を使った短い演習を行い、入力しないと次工程へ進めない項目、訂正できる人、困ったときの窓口を明確にします。現場には紙の手順書だけでなく、画面上の入力例やよくあるエラーの対処方法を用意し、稼働後の問い合わせを改善要望として記録します。

稼働後は、納期遵守率、製番別の見積と実績の差異、購買リードタイム、仕掛在庫、設計変更の伝達時間、実績の当日入力率、不適合の再発件数などを月次で確認します。数字が改善しないときに、システム機能の不足なのか、マスタや運用ルールの問題なのかを切り分けます。KPIを見ながら小さく改善することで、発注したシステムを現場の資産として育てられます。

よくある質問（FAQ）

製番管理システムの発注では、方式、価格、契約、社内体制に関する疑問が同時に出てきます。ここでは、発注前に特に確認されやすい質問へ直接回答します。

標準設定のクラウドSaaSは初期0〜60万円程度、製造業パッケージは数十万〜数百万円から、製番対応・連携込みでは300万〜1,500万円程度、半完成品のカスタマイズは500万〜2,000万円程度、スクラッチは要件によって数百万円から数千万円以上が目安です。これは公定価格ではなく、要件量と公開価格例をもとにしたレンジです。移行、教育、保守、追加開発を含む五年間の総額で見積もります。

相談できますが、現状の業務フロー、困っている案件、利用部門、既存システム、予算と希望時期だけでも整理してから相談すると、提案の精度が上がります。最初から完成したRFPを用意できない場合は、要件定義フェーズを準委任で依頼し、その成果物をもとに開発の相見積もりへ進む方法があります。口頭の要望だけで固定価格を求めず、未確定事項を明示します。

同じシステムで管理できる製品はありますが、製番とロットを同じ項目として扱えるとは限りません。受注案件ごとに追う製番、同じ条件のまとまりを追うロット、個体を一つずつ追うシリアル番号を、品目や工程ごとに使い分けられるか確認します。製番からロット、ロットから原材料、原材料から仕入先へ遡れるトレーサビリティが必要なら、デモで実データに近いシナリオを動かします。

自社業務を標準機能へ合わせられ、短期間で安定稼働させたい場合は、製造業パッケージと導入支援に強い会社が候補になります。独自工程、複雑な連携、固有の原価計算が競争力の中心なら、半完成品のカスタマイズやスクラッチ開発も比較します。どちらを選んでも、製番別BOM、設計変更、外注、原価、受入テスト、保守の担当範囲を同じRFPで確認することが重要です。

まとめ

製番管理システムの発注・外注では、製番を案件の親キーとして、受注、個別BOM、設計変更、購買、外注、工程、品質、原価、出荷までを一つの業務フローで整理します。発注形態は、標準SaaS、製造業パッケージ、半完成品、スクラッチを、自社固有の要件と五年間の総保有コストで比較します。RFPには正常系だけでなく、分納、欠品、再加工、代替部品、外注遅延、通信断、原価締めなどの例外を入れます。

一つ目は、製番、ロット、シリアル番号の使い分けと、製番別に追いたい情報です。二つ目は、標準機能へ合わせる範囲と、自社固有の業務として作り込む範囲です。三つ目は、費用、納期、検収、保守、データ返却を含む契約条件です。この三つを社内で合意してから相見積もりを取ると、価格の差を機能・工数・リスクの差として説明できます。

最初の一歩は、過去に納期遅延や原価差異、設計変更の伝達漏れが起きた案件を三つ選び、受注から出荷までのデータと担当部門を書き出すことです。そのうえで、製番から部品・外注・実績・品質・原価を追えることを必須条件にし、二社から四社へ同じRFPを渡します。提案とデモを比較し、現場が使い続けられる方式と委託先を選定してください。

▼全体ガイドの記事
・製番管理システム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。