製番管理システム開発の進め方/やり方/流れや方法/手法/工程/手順

製番管理システム開発は、要件整理から定着まで、6フェーズで順に進みます。

  1. 要件整理:現場の業務を事実どおりに把握する
  2. 方式・製品選定:機能の対応範囲を比べて、方式を決める
  3. 設計・開発:製番を中心に、データと画面、連携を組み立てる
  4. テスト:発番から出荷までを、異常系も含めて検証する
  5. 稼働:小さく始めて、並行期間を置く
  6. 定着:入力率とKPIを継続して見る

各フェーズの完了条件を文書にし、決定事項を後工程へ持ち越さないようにすると、判断の抜け漏れや追加費用、現場の混乱を抑えやすくなります。全体像は製番管理システム開発の完全ガイドもご覧ください。

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

製番管理システム開発の全体像

製番管理システムを中心に、BOM、図面、工程実績、検査、原価をひも付けて示す図
出荷までの記録を案件単位でたどれます。

製番管理は、注文や製造案件ごとに固有の番号を親キーにして、関連する情報を集約する方法です。

標準品を品番やロットの総量で追う仕組みとは異なり、注文ごとに仕様が変わる個別受注生産や、機械・装置・産業設備の製造に向いています。

製番管理システムの概要

製番管理システムでは、受注や案件の発番を起点に情報を集約し、製造から出荷までを追跡します。

たとえば、装置1台を製番「S-26001」とし、図面の版数、発注、外注加工、組立時間、検査記録、出荷書類をひも付けます。

  • 一貫管理:BOM、図面、手配、工程実績、検査、出荷、原価を製番にひも付けて扱います。
  • 案件の追跡:親子製番、共通・代替部品、分納、再加工まで追えるデータ構造が求められます。

仕様変更が起きたときも、旧版の図面と新しい部品表を残しておけば、承認した人と時点をたどれます。

製番管理とロット管理の使い分け

製番管理は案件単位で、ロット管理はまとまり単位で追います。どちらを選ぶかは、自社が個別受注、繰返受注、見込生産のどれに近いかを初めに判定して決めます。

  • 製番管理:注文ごとの製品や部品を一件ずつ追う方法です。
  • ロット管理:同じ条件で作ったまとまりごとの流れを追う方法です。
  • 併用:個別仕様の産業機械は製番を基準にし、材料入荷や食品・化学品の品質追跡にはロットを使います。

量産品を一品ずつ製番管理すると、登録と入力の負担が増え、現場が回らなくなる可能性があります。一方で、受注ごとに仕様・納期・原価が異なる製品をロットだけで管理すると、案件別の赤字や設計変更が見えにくくなります。

最初にそろえる機能

まず、製番管理に必要な機能と連携の範囲を洗い出します。

  • 発番と構成:受注・案件の発番、製番別BOM、図面、仕様変更履歴
  • 手配と実績:所要量計算、購買・外注手配、工程計画、作業実績
  • 原価と品質:材料費・労務費・外注費・間接費、検査、不適合、是正履歴
  • 追跡と連携:製番から構成部品・仕入先への追跡と、販売・会計・在庫・WMS・CAD・PDM・設備IoT連携

外部システムと連携する場合は、対象データと責任部門も要件に含めておきます。

ポイント

製番管理を使うかは、注文ごとに仕様や納期、原価が変わるかで判断します。量産品が中心の会社なら、品番やロットの総量で足りるかを先に確かめてください。

製番管理システム開発の進め方と6フェーズ

要件整理、方式・製品選定、設計・開発とテスト、稼働と定着へ進む開発工程の図
前段階の決定事項を固めてから次へ進みます。

前の段階で決めたことは、次の段階の前提になります。そのため、フェーズごとに何を決め、何を次へ渡すかを明確にしておく必要があります。

フェーズ1:業務の事実を集める要件整理

要件整理では、現場の業務を事実どおりに把握します。まず、営業の受注から請求までを、一枚の業務フローにまとめます。設計、購買、製造の流れを中心に書き、外注、検査、出荷、請求といった前後の工程も、同じフローで追えるようにします。

業務フローを見ながら、誰が担うか、例外をどう扱うか、どのルールで管理するかを詰めます。

  • 業務と担当:発番、BOM確定、設計変更の承認、実績締めを担う人を明確にします。
  • 例外処理:分納、再加工、共通部品の複数案件引当、支給品、外注戻り、欠品、廃番の扱い
  • 管理ルール:設計変更や製番の分割・統合を例に、採番、親子関係、BOM版数、締め日、訂正権限、保存期間を決めます。

Excelや紙の台帳も集めておき、現場が紙に戻ってしまう条件もあわせて記録します。

この段階でまとめる文書は、業務フロー、用語集、データ項目一覧です。このほか、権限表、非機能要件、受入条件も文書にします。

フェーズ2:標準・設定・追加開発を分ける選定

方式ごとに機能の対応範囲をそろえて比べ、実際の業務の流れで合うかを確かめます。

  • 方式:標準クラウド、製造業パッケージ、半完成品のカスタマイズ、フルスクラッチの比較
  • 対応範囲:製番別BOM、個別原価、外注、モバイル実績、API、設計変更履歴を、標準・設定・追加開発に分けます。
  • 業務シナリオ:受注発番からBOM変更、欠品部品の代替、外注、実績登録、予定・実際原価の比較、出荷まで試します。

三菱電機デジタルイノベーションは、繰返生産向けMRP版、一品個別生産向け製番管理版、混在向けハイブリッド版を案内しています(出典: 三菱電機デジタルイノベーション株式会社、2026年8月確認)。

方式の分け方は、製造形態が混在する会社にとって、単一の方式に無理にそろえないための判断材料になります。

フェーズ3:製番を中心にデータをつなぐ設計・開発

基本設計では、製番を中心に、データと画面、連携ルールを組み立てます。

  • データ構造:受注、個別BOM、工程、在庫引当、購買、品質、原価、出荷の関係を定義します。
  • 識別項目:製番、子製番、品目コード、BOM版数、工程番号、ロット・シリアル、仕入先、作業者、原価要素の項目
  • 画面と連携:担当別画面を分け、二重計上防止、連携方向、再送、締め後訂正を設計します。

同じ部品を複数の案件で使う場合は、引当のルールも決めておきます。設計者は図面とBOM、購買担当は未手配と納期遅れを見られる画面を設けます。

現場ではバーコードやタブレットで実績を登録し、管理者は製番別の原価差異を確認します。現場の画面は項目を絞り、作業者が数秒で登録できる量にしておきます。

会計や販売管理と連携する場合は、二重計上を防ぐための連携の方向、エラー時の再送、締め後の訂正方法を決めます。

フェーズ4:製番単位で異常系を検証するテスト

画面が開くかを確かめるだけでは足りず、発番から出荷までの業務と例外処理もテストします。

  • 業務テスト:単体、結合、総合、受入テストで発番から出荷までを繰り返します。
  • 異常系:二重発番、BOM版数違い、欠品、代替、外注遅れ、再加工、分納、通信断、端末故障、連携先停止、締め後訂正を試します。
  • 受入条件:検知者、ステータス、在庫・原価の戻し方、監査ログを定めます。

あわせて、製番別の予定・実際原価や設計変更前の履歴、在庫と購買の数量が正しいかも確かめます。

特に、製造ラインを止めて切り替える場合は、旧システムへ戻す手順と、バックアップからの復旧時間も試験しておきます。

フェーズ5:小さく始めて並行期間を置く稼働

段階的に導入しながら切替の準備を進め、現場が迷わず運用できる状態にします。

  • 小さく開始:1工場・1製品群・代表的な数件の案件から始めます。
  • 範囲を拡張:受注、製番、BOM、手配、進捗から始め、実績、品質、原価、会計・WMS連携を追加します。
  • 切替準備:移行の件数・エラー数、正とする情報、並行期間の終了日を決めます。

移行の対象は、マスタ類、BOM、過去案件のデータです。マスタ類には、品目と取引先、工程、単価が含まれます。本稼働の前に照合を終えておけば、稼働後に数字の食い違いを探す手間を減らせます。

旧Excelを残す場合は、並行期間の間どちらを正として扱うかを、現場に伝えておく必要があります。問い合わせ窓口と障害優先度、代替帳票、休日の連絡先も定めておくと、本稼働後の対応に迷いが減ります。

フェーズ6:入力率とKPIを継続的に見る定着

研修が終わった後も支援と改善を続け、システムの利用を業務の成果につなげます。

  • 運用支援:役割別手順書、現場用語に合わせた画面、問い合わせ先、月次改善会を用意します。
  • 定期確認:導入後1か月、3か月、6か月に入力率、未手配、納期遅延、変更伝達時間、製番別粗利、仕掛在庫、購買リードタイムを見ます。
  • 改善:使われない項目を削り、現場の提案を次のリリースに反映します。

目標は、システムを使っているかどうかだけでなく、経営と現場の判断が変わったかで置きます。たとえば、原価速報を月末締めから週次の確認に変える、変更承認から現場確認までの時間を短くする、納期遅れを製番・工程・仕入先まで特定できるようにする、といった成果を目指します。

ポイント

各フェーズで決めたことを次の段階へ渡す前に、完了条件を文書で確かめられるかが判断の目安です。6フェーズの流れを一つずつ通して、抜けがないかを見直すと気づきやすくなります。

製番管理システム開発の費用相場とコストの内訳

製番数、拠点・ユーザー数、BOMの深さ、カスタマイズを費用の条件として示す図
見積もりでは自社の条件を一つずつ照らし合わせます。

製番管理システムに、公定価格はありません。費用は、製番数、拠点・ユーザー数、BOMの深さの3つで大きく変わるほか、工程、連携、端末、移行、カスタマイズの内容によっても変わります。ここで示す金額は、リサーチノートの類似相場と公開価格の目安で、製番管理だけの市場平均ではありません。

方式別の初期費用の目安

方式ごとの相場や公開価格は、機能と導入支援の範囲をそろえてから比べる必要があります。

  • クラウドSaaS:標準設定は0〜60万円程度が目安です。設定支援、初期データ整備、教育費は別に確認します。
  • 製造業パッケージ:ライセンス・設定は数十万〜数百万円、製番対応・連携・支援込みで300万〜1,500万円程度です。
  • 半完成品:帳票・原価・工程の公開例は400万円からで、要件により500万〜2,000万円程度です。
  • フルスクラッチ:小規模300万〜1,000万円、中規模1,000万〜5,000万円、大規模5,000万〜1億円以上の類似相場があります。

GEN株式会社は、GEN TRADINGを月額23,500円から(税別、GMSP除く)と公開しています(出典: GEN株式会社、2026年8月確認)。

ただし、製造向けの機能、ユーザー数、導入支援の費用は個別に確認する必要があります。公開価格は相場ではなく比較の起点にすぎず、費用レンジもいずれも要件と体制に基づく推定です。

見積金額の内訳

見積書は、工程ごとの作業と人月を対応させて見ると、どの作業が含まれているかが分かります。

  • 開発工程:要件定義、設計、画面・帳票、連携、テストの作業の有無
  • 導入作業:マスタ整備、データ移行、教育、切替、保守の範囲
  • 人件費と工数:費用の約60〜80%が人件費という目安を参考に、工程ごとの人月、レビュー、品質保証を比べます。

BOMの初期登録、過去製番の移行、図面の整理、原価要素の設定は、別作業になりやすい項目です。そのため、本体価格だけを見ていると予算が足りなくなります。

また、リサーチノートの人月単価の目安は、PMが90万〜150万円、SEが65万〜110万円、PGが50万〜90万円です。この数値は、市場全体を保証する統計ではなく、工数の感覚を確かめるための参考値です。

ランニングコストと導入期間を含めた見積もり

TCO(総所有コスト)と導入期間をまとめて見積もり、稼働後に必要な費用と期間も確保しておきます。

  • 運用費:年間保守、クラウド利用料、ユーザー追加、バックアップ、端末・バーコード機器を含めます。
  • 継続対応:API監視、法改正対応、更新検証を、TCOに加えます。
  • 導入期間:標準SaaSは即日〜数週間、パッケージは1〜6か月、半完成品は3〜9か月が目安です。
  • スクラッチの期間:小規模3〜6か月、中規模6〜12か月、大規模12か月以上が目安です。

リサーチノートでは、保守運用は初期費用の年15〜25%程度が目安です。24時間対応や端末保守の有無で変わります。また、移行や教育の短縮は手戻りを招くため、受入と定着の期間も確保しておきます。

ポイント

費用は製番数や拠点数、BOMの深さなどの条件で変わるため、公開価格だけで予算を決めないことが目安です。初期費用だけでなく、保守や導入期間を含めたTCOで比べると判断しやすくなります。

製番管理システムの見積もりを取る際のポイント

相見積もりでは、価格だけでなく、標準機能、追加開発、移行の範囲、テスト、稼働後の支援を比べます。RFPには、作る機能だけでなく、どの業務結果を、どのデータで、誰が確認すれば合格とするかを書きます。

RFPに入れる確認項目

RFPの項目は、製番と生産、業務範囲、環境と運用の三つに分けると、確認の漏れを減らしやすくなります。製番業務とシステム環境に加えて、例外時の判断条件も項目ごとに具体的に書いておきます。

  • 製番と生産:採番単位、親子製番、分納・再加工、BOM版数、共通・代替部品、所要量計算の記載
  • 業務範囲:購買・外注、工程実績、検査・不適合、原価の速報・確定時期、出荷・請求を含めます。
  • 環境と運用:拠点、ユーザー・権限、端末、通信断対応、API・EDI、図面、監査ログ、バックアップ、保存期間、移行対象を明記します。

「製番管理に対応しますか」と尋ねるより、具体的な場面を示すほうが、答えの中身を比べやすくなります。たとえば、設計変更時の未発注・発注済み・入荷済みの部品をどう扱うか、共通部品を複数の製番へ引き当てたときの原価配賦、実績の未入力を誰が検知するかを尋ねます。

回答を、標準、設定、追加開発、運用変更に分けてもらうと、各社の見積もりを同じ条件で並べられます。

デモとPoCで試す内容

実データを使い、業務の一連の流れと、導入候補からの回答を実際の操作で検証します。

  • デモ:実際の製品群と過去案件で、受注から製番、BOM、手配、変更、工程、外注、検査、出荷、原価まで操作します。
  • PoC:1製品群・1工場・数案件に絞り、正常系と異常系を実行します。
  • 評価:発番・BOM登録・実績入力の時間、未手配検知、原価差異、変更通知、帳票、APIエラー復旧を採点します。

画面の数よりも、営業・設計・購買・現場・経理が同じ製番を見て判断できるかを、評価の中心に置きます。そのうえで、「できる」と回答された機能は実際の操作で検証し、追加費用と制約を議事録に残します。

価格以外に比べる開発会社の条件

業務実績や支援体制に加えて、契約と運用に関する条件も比べます。

  • 経験と理解:個別受注・製造業の実績、要件定義担当者、製番別原価・BOMへの理解を確認します。
  • 導入・保守体制:端末・連携、移行経験、テスト体制、保守窓口と自社に近い導入事例を比べます。
  • 契約と安全性:要件変更時の単価と承認手順、納期遅延時の扱い、成果物の所有権、データの返却、解約時の移行支援、SLA、脆弱性、更新影響

事例は、製品形態、拠点数、外注比率、設計変更の頻度が自社に近いものを探します。

クラウドの場合は、データの所在、バックアップ、認証、多要素認証、通信断時の運用を確かめます。一方で、スクラッチの場合は、保守担当者が退職した後も改修できる体制かどうかを確認します。

法令・セキュリティ要件を見積に含める理由

製番には図面、仕入先、作業者、検査、価格、取引書類が集まるため、漏えいや改ざんの影響が大きくなります。

  • 工場セキュリティ:IT・設備ネットワークの分離、資産・アカウント管理、バックアップ、ログ監視、事故時の操業継続を確認します。
  • 電子取引:検索性、訂正削除の履歴、帳簿との関連、保存方法を、経理部門とすり合わせる項目です。
  • 委託取引:外注先、発注日、委託内容、受領・検査、支払、価格協議の履歴を購買・製番データと関連付けます。

経済産業省は2025年4月、中小製造事業者向けに工場セキュリティの重要性と始め方を示す解説書を公表しました(出典: 経済産業省、2025年)。

電子取引データを製番とひも付ける場合は、国税庁の概要資料も参考にしながら、経理部門と要件を確認します(出典: 国税庁「電子帳簿保存法の概要」、2026年8月確認)。

取適法は2026年1月1日に施行され、製造委託などの義務・禁止事項が整理されました。また、公正取引委員会は2026年6月、令和7年度の勧告件数を39件と公表しています(出典: 公正取引委員会、2026年)。

ポイント

見積もりは価格だけで比べず、RFPで決めた業務結果をデモやPoCで実際に確かめられたかを基準にします。契約と安全性の条件まで含めて比べると、後から追加費用が出る場面を減らせます。

製番管理システム開発でよくある質問(FAQ)

製番管理では、方式の選び方だけでなく、導入範囲と運用ルールにも疑問が出てきます。相談の場でよく出る質問に、判断の基準を添えて答えます。

製番管理システムは量産工場にも必要ですか?

すべての量産工場に必要とは限りません。標準品をロットや品番の総量で管理できるのであれば、ロット、在庫、工程の管理を優先できます。

量産と個別受注が混在する場合や、試作品・特注品だけを個別原価で追う場合は、MRPと製番を併用する方式が候補になります。

仕様、部品、納期、原価が受注ごとに変わる製品が売上や利益の中心であれば、製番管理の効果を検証する価値があります。

製番管理システムの開発期間はどのくらいですか?

発注側と開発会社は、方式ごとの目安を踏まえて、段階導入と品質基準の両方を計画します。

  • 期間の目安:標準設定は即日〜数週間、パッケージは1〜6か月、個別開発は3〜12か月以上です。
  • 期間を左右する要素:拠点、BOM・工程、会計・CAD・WMS連携、移行、受入テスト、教育の量で変わります。
  • 短縮方法:1工場・1製品群で受注、製番、BOM、手配、進捗から始め、原価・品質・外部連携を段階的に追加します。

期間を縮めるために要件整理と異常系テストを削ると、手戻りが増えます。そのため、短縮する範囲と品質基準は、発注側と開発会社で合意しておきます。

Excelから製番管理システムへ移行するときの注意点は何ですか?

移行の前にデータを整え、対象の範囲と照合の方法を決めておきます。

  • データ整理:品目コード、単位、取引先、工程、BOM版数、製番、在庫、原価項目の重複・欠損を調べます。
  • 移行範囲:稼働中製番、保証・保守対象、原価分析用履歴など、目的に応じて選びます。
  • 照合:製番数、BOM明細数、在庫数量、原価合計、未完了工程を前後で確認し、差異の理由を記録します。

部署間でコードを統合できない場合は、変換表と責任者を決めておき、移行後に正とするデータも合意します。

クラウド型とスクラッチ開発はどちらを選ぶべきですか?

方式を選ぶときは、標準業務の割合と、個別に作り込みたい業務を分けて考えます。

  • クラウド型:標準業務が多く、初期投資と運用負担を抑えたい場合に向きます。
  • 拡張・スクラッチ:固有の製番別原価、設備連携、複雑な工程、競争力に直結する業務を作り込む場合に検討します。
  • ハイブリッド:コアに製造業パッケージ、現場入力・申請にSaaSやローコード、周辺連携にAPIを使う方法もあります。

標準機能で変えられる業務と、競争力のために変えるべきでない業務を分けて、方式を判断します。

ポイント

製番管理を入れるかどうかは、量産品と個別受注の割合や、標準業務の割合を先に把握すると判断しやすくなります。量産と個別受注が混在するなら、MRPと製番の併用を候補にします。

製番管理システム開発の進め方まとめ

開発は、要件整理から定着まで、6フェーズで進めると判断の抜けを抑えやすくなります。

  1. 要件整理:業務の事実を集めて、文書にまとめる
  2. 選定:標準・設定・追加開発を分けて、方式を比べる
  3. 設計・開発:製番を中心に、データをつなぐ
  4. テスト:製番単位で、異常系まで検証する
  5. 稼働:並行期間を置いて、切り替える
  6. 定着:入力率とKPIを見続ける

その際は、製番を案件の親キーとして、個別BOM、設計変更、実際原価をつなぎます。手配、工程、品質、出荷も、同じ製番にひも付けて扱います。

導入前に確認するチェックポイント

初回の打ち合わせでは、製造形態と採番の決め方を、まず確かめます。そのうえで、製番にまつわる業務の扱いを、業務の流れに沿って確かめます。

  • 親子関係・BOM版数:製番の親子と、版ごとのBOMをどう扱うか
  • 設計変更:旧版の図面と新しい部品表を残し、承認した人と時点をたどれるか
  • 欠品・代替・再加工:欠品部品の代替や再加工を、どの製番で扱うか
  • 外注:外注加工と外注戻りを、製番にどうひも付けるか
  • 実績入力:現場の作業実績を、誰がどの画面で入力するか

さらに、原価の速報と確定、移行データ、連携の扱いも確認しておきます。権限と監査ログ、通信断、セキュリティは、運用の前提として確かめます。電子帳簿保存と取適法への対応も、あわせて確認しておきます。

確認が曖昧なまま価格だけで比べると、契約後の追加開発や運用の負荷につながります。

まず取り組むべき最初の一歩

まずは、業務の情報がどのようにつながっているかを把握します。

  • 対象を選ぶ:代表的な製品一つについて、受注から出荷までの製番を追跡します。
  • 現状を並べる:Excel、図面、発注、作業実績、検査、原価を見て、転記箇所と製番が途切れる場所を探します。
  • 選定に活用する:確認した事実をRFPとPoCのシナリオにし、方式や開発会社を比べます。

費用は初期開発だけでなく、移行・教育・連携・保守を含むTCO(総所有コスト)で見ます。

標準機能、設定、追加開発、運用変更を分けたうえで、成果は現場の入力から、経営による納期・品質・原価の判断までを含めて定めます。

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

会社紹介

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

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

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