生産管理システムの開発で決める6つのこと【2026年版】生産方式・BOM・所要量計算・実績収集・原価

「生産管理システムを作りたいが、何から決めればいいのか分からない」——製造業の方からこうした相談をよく受けます。機能一覧を見せられても、自社の工場の流れに当てはまるのかが判断できない。パッケージのデモは繰り返し生産が前提で、1個ずつ図面が違う自社の受注には合わない。前に入れたシステムは現場が使わず、結局Excelに戻った。そういう経験をお持ちの方ほど、機能の数ではなく「何が難しいのか」を先に知りたいはずです。

結論から言うと、生産管理システムの開発で最初に決めるのは機能ではなく、自社の生産方式です。受注生産か見込生産か、手配を製番でつなぐのか所要量計算(MRP)で回すのか。ここが決まらないと、部品構成(BOM)の持ち方も、工程と実績の取り方も、原価の集め方も決まりません。逆にここさえ決まれば、以降の設計は自社の業務をマスタとルールに写し取る作業に変わります。

そして、もうひとつの分かれ目は実績収集です。どれだけ良い計画機能を作っても、現場が入力しなければ数字は1日遅れ、意思決定には使えません。入力を軽くする設計に手間をかけたシステムだけが定着する、というのが実情です。

本記事では、生産方式で設計が変わる理由、部品構成(BOM)と所要量計算(MRP)、工程と製造指図と実績収集と在庫の引当、ロット管理とトレーサビリティと原価、Excel・紙・ホワイトボードからの移行、外部チームで作る場合の進め方、よくある質問の順に解説します。用語はJIS Z 8141(生産管理用語)と原価計算基準で定義を確認し、資料によって定義がずれる箇所はそのずれごと書きました。費用相場は本記事では扱わず、既存の記事に譲ります。

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。当社は製造業の生産管理システムの開発にも対応していますが、この記事では売り込みではなく「何を決める必要があるのか」という設計論点だけを整理しました。最後の章では、外部チームに出せる範囲と社内に残すべき範囲を率直に書いています。

生産管理システムの開発が難しい理由——生産方式が決まらないと設計が始まらない

生産管理システムの開発で最初に詰まるのは、機能の多さではありません。同じ「工程管理」という言葉が、工場によってまったく違うものを指すことです。1個ずつ図面が違う受注生産の工場と、毎日同じ製品を流す見込生産の工場では、管理したい単位も、計画の作り方も、原価の集め方も別物になります。ここを先に決めないまま機能一覧から要件を組み立てると、どの機能も「半分だけ合っている」状態で完成します。

JISの定義で整理する——受注生産と見込生産は「誰が仕様を決めるか」で分かれる

生産管理の用語は、日本産業規格 JIS Z 8141(生産管理用語)で定義されています。この規格は2022年3月22日に改正され、JIS Z 8141:2001 は JIS Z 8141:2022 に置き換えられました。2022年版の適用範囲は「鉱工業における生産管理において用いる主な用語」で、用語は基本・生産システム・生産計画・生産統制・作業管理などに分類されています(日本産業標準調査会のJIS検索で規格本文を閲覧して確認。確認日2026年9月21日)。

現行の2022年版では、受注生産(3204)は「顧客が定めた仕様の製品を生産者が生産する形態」、見込生産(3203)は「生産者が市場の需要を見越して企画・設計した製品を生産し、不特定な顧客を対象として市場に出荷する形態」と定義されています。違いは生産量でも工場の規模でもなく、仕様を誰が決めるかです。顧客が決めるなら、注文が来るまで何を作るか分からない。自社が決めるなら、注文が来る前から作れる。この一点が、システムの骨格を左右します。

なお、用語の呼び名も番号も版によって変わります。2022年版の見出し語は「BOM,部品構成表」(3307)で、資材所要量計画(2101)の定義文もこのBOMを参照する形になっています。一方、2001年版を引いた解説記事では「部品表」という見出し語のまま説明されていることが多く、手元の資料がどちらの版かで用語が食い違います。要件定義の場で規格を引くときは、必ず版(2022年版か2001年版か)を添えてください。以降の定義は、すべて現行のJIS Z 8141:2022の条文によります。

手配の系統は2つある——製番管理方式と資材所要量計画(MRP)

材料や部品をいつ手配するかを決める仕組みには、大きく2つの系統があります。

JIS Z 8141:2022 は、製番管理方式(3212)を「製造命令書において、対象製品に関する全ての加工及び組立の指示書を準備し、同一の製造番号をそれぞれにつけて管理する方式」と定義しています。注文1件に製造番号を振り、その番号に材料も工程も実績も原価もぶら下げる方式です。一方、資材所要量計画(2101)は「MPS、BOM、生産計画情報及び在庫情報に基づいて、資材の必要量(所要量)及び必要時期を求める生産管理体系」と定義されています。注文とは切り離し、計画と部品構成と在庫から必要量を計算する方式です。

ここで注意したいのは入力の並びです。ベンダーの解説記事の多くは、MRPの入力を「MPS(基準生産計画)・BOM・在庫情報の3つ」と説明しますが、2022年版の定義文はMPSとは別に「生産計画情報」も挙げています。基準生産計画まで作り込むのか、週次の生産計画表で足りるのかは、工場によって違います。要件定義では、定義の言葉ではなく自社で実際に何を入力できるかから逆算してください。

自社がどちらかを判定する5つの問い(混在している工場のほうが多い)

次の5つの問いに答えると、自社の手配の系統がどちら寄りかが見えます。

判定の目安は、5問のうち3つ以上が製番管理寄りなら製番中心、3つ以上がMRP寄りならMRP中心、どちらも2つ以下なら混在型として両方を設計する、という線引きです。

実務では、量産品は見込みで作りカスタム品は受注ごとに設計変更が入る、という混在型の工場のほうが多数です。混在型では「どの品目群をどちらで回すか」を品目マスタの属性として持たせ、画面と帳票を切り替える設計にします。最初からひとつの仕組みに寄せようとすると、どちらの現場からも使いにくいシステムになるので要注意です。

ERPの生産モジュール、MES、生産管理システムの守備範囲の違い

言葉の整理も先にしておきます。ERPの生産モジュールは会計と在庫に接続した計画側を、MES(製造実行システム)は現場の指示と実績収集を、生産管理システムはその中間で計画と実行をつなぐ層を担うのが一般的な分け方です。ただしこの区分は各社の製品説明に依存するもので、JIS Z 8141:2022 に「MES」という用語は立てられていません(CIMの注記に関連システムの一例として名前が出るだけです)。自社が作ろうとしているものが3つのどれに当たるかで悩むより、計画・指示・実績・在庫・原価のどこまでを一つのシステムで持つかを範囲として書き出すほうが、要件定義は前に進みます。パッケージとスクラッチのどちらで作るかという一般論は「スクラッチ開発とは」の記事に譲ります。

ここまでで、自社は製番管理寄りかMRP寄りか、あるいは混在型か。その答えを持ったうえで、次の部品構成の話に進んでください。

部品構成(BOM)と所要量計算(MRP)——多階層展開、リードタイム、計画が狂う3つの原因

生産管理システムの中心にあるのは、画面でも帳票でもなく部品構成のデータです。ここが正しくないと、必要量の計算も、原価の積み上げも、納期の回答も連鎖して狂います。そして部品構成は、たいていの工場で「設計部門のファイル」と「現場の頭の中」に分かれて存在しています。開発でいちばん時間がかかるのは、この二つを一つのデータに寄せる作業です。

部品表(BOM)の定義と、現場に複数の表が併存する理由

JIS Z 8141:2022 は「BOM,部品構成表」(3307)を「製品又は親部品を生産するのに必要な子部品の、種類及び数量を示したもの」と定義しています。注記では木構造のストラクチャ型と表形式のサマリー型という2つの表現形式を挙げていますが、表を何枚持つかは規定していません。

ところが実際の工場では、少なくとも2種類の表が併存します。設計部門が図面から起こす表(業界ではE-BOMと呼ばれます)と、製造部門が実際の作りやすさに合わせて組み替えた表(同じくM-BOM)です。設計の表には「ねじ4本」としか書かれていないものが、製造の表では「サブ組立A」という中間品にまとめられている。逆に、設計では1つの部品が、製造では切断・曲げ・溶接の3工程に分かれる。この呼び分けはJISの用語には含まれておらず、各社の製品説明や実務慣行に由来するものです。規格の定義を根拠に「BOMは1つ」と決めてしまうと、要件定義の最初の打ち合わせで設計部門と製造部門が衝突します。

要件として決めるのは次の3点です。どちらの表を正とするか。もう一方をどう同期するか(手作業か、変換ルールを持つか)。そして、購買部門が使う調達用の表を別に持つかどうか。

多階層BOMの展開——員数、歩留まり、代替品、中間品を品目にするかどうか

部品構成は階層構造を持ちます。製品の下に組立品、その下に部品、さらに下に材料。この階層を上から順に必要量へ変換していくことを展開と呼びます。展開の設計で必ず論点になるのが次の4つです。

この4つのうち、中間品の扱いがもっとも影響範囲の広い決定です。中間品を品目として立てれば在庫として数えられ、別の製品にも流用できますが、その分だけ入出庫の記録が増えます。工程の途中として扱えば入力は軽くなりますが、仕掛品の所在が分からなくなります。どちらが正しいということはなく、棚卸の精度と現場の入力負担のどちらを取るかという交換条件です。

設計変更(ECN)をいつから効かせるか——有効日付を持たせないと過去が再現できない

部品構成は固定されたものではありません。設計変更が入れば構成が変わります。このとき「いつから新しい構成を使うか」をデータとして持たないシステムを作ると、過去に作った製品の構成を後から再現できなくなります。

必要なのは、部品構成の各行に有効開始日と有効終了日を持たせることと、切り替えの基準を決めることです。基準には、日付で切り替える、在庫を使い切ってから切り替える、指定の製造ロットから切り替える、という選択肢があります。品質問題で過去に遡って調査するとき、「その日にその製品はどの構成で作られたか」を答えられるかどうかがここで決まります。

所要量計算(MRP)に必要な3つの入力と、計画が狂う3つの原因

JIS Z 8141:2022 は資材所要量計画(2101)を「MPS、BOM、生産計画情報及び在庫情報に基づいて、資材の必要量(所要量)及び必要時期を求める生産管理体系」と定義しています。MPSは生産計画情報の一形態ですから、実務で用意するものは計画・部品構成・在庫の3つと考えて差し支えありません。逆に言えば、この3つが正しくなければ出力も正しくありません。

計画が狂う原因は、現場ではほぼ次の3つに集約されます。

1. 在庫情報が現物と合っていない。帳簿上あることになっている材料が棚にない。あるいはその逆。所要量計算は帳簿の数字しか見ないので、差異はそのまま誤った手配になります
2. 部品構成が最新でない。設計変更が反映される前に計算が走る。上の有効日付の設計がここに効きます
3. リードタイムが実態と違う。マスタに入っている調達日数が、何年も前に入力されたまま更新されていない

3つとも、機能の不足ではなくマスタの運用の問題です。だからこそ、生産管理システムの開発では「誰がいつマスタを更新するか」を業務ルールとして決め、更新のしやすい画面を作ることが、計算ロジックそのものより優先されます。

リードタイムには2つの意味がある——調達の時間と製造の時間を分けて持つ

最後に、地味ですが毎回もめる項目を挙げておきます。JIS Z 8141:2022 のリードタイム(1206)の定義は2つあり、「発注してから納入されるまでの時間」と「素材が準備されてから完成品になるまでの時間」です。前者は調達、後者は製造の話で、単位も管理する部門も違います。同規格は、生産の着手から完了までを指す「生産リードタイム」(3304)を別の用語として立てています。

システム上は、品目マスタに調達リードタイム、工程マスタに製造リードタイムを分けて持ち、納期回答ではその合計に余裕日数を足す、という設計が素直です。1つの項目にまとめてしまうと、遅れたときに調達が悪いのか製造が悪いのかが分からなくなります。

部品構成と所要量計算は、機能を作る話ではなくマスタを整える話です。ここに時間をかけずに先へ進むと、稼働後に「計算結果が信用できない」と言われ、現場がExcelに戻ります。

工程・製造指図・実績収集と在庫の引当——現場の入力をどこまで軽くできるかで決まる

計画をどれだけ精緻に作っても、現場から実績が返ってこなければ何も管理できません。生産管理システムが定着するかどうかの分かれ目は、計画機能の出来ではなく、実績を入れる仕組みが現場の手の動きに合っているかどうかです。2025年版ものづくり白書でも、デジタル技術の導入にあたって約2.5割の企業が新たな人材を確保せず導入部署の既存人材だけで対応しているとされており、入力の手間を吸収する人員の余裕は現場にありません。

工程マスタと作業手順——「標準時間を持つか」で設計が二段階に分かれる

工程マスタには、品目ごとに「どの順番で、どの設備・職場を通るか」を登録します。ここまでは全社共通ですが、そこに標準時間(この工程に何分かかるか)を持たせるかどうかで、システムの重さが変わります。

標準時間を持たない設計なら、工程は順序と担当職場の情報だけになり、マスタ整備は比較的軽く済みます。一方、標準時間を持たせると、能力の山積み、納期の逆算、労務費の配賦が計算できるようになりますが、全品目・全工程の時間を測って登録し、更新し続ける運用が必要になります。中小規模の工場では、まず主要品目の上位20〜30%だけ標準時間を持ち、残りは実績の平均から後で埋める、という段階的な進め方が現実的です。

段取り時間を工程時間と分けて持つかどうかも先に決めてください。段取りが長い工程を持つ工場では、ここを分けないと計画がまったく合いません。

製造指図と進捗管理——指図の単位を製番にするか、ロットにするか、日付にするか

製造指図は、現場に「何を、いくつ、いつまでに作るか」を伝える単位です。この単位の決め方が、そのまま実績の集まり方を決めます。

JIS Z 8141:2022 では進捗管理(4104)を「仕事の進行状況を把握し、日々の仕事の進み具合を調整する活動」と定義しています。調整する活動である以上、把握した情報が遅れて届けば、調整はできません。指図の単位が大きすぎる(例えば1か月分をまとめて1件)と、途中経過が見えず、完了するまで進捗が0%のままになります。逆に細かすぎると、指図の発行と消込だけで担当者の一日が終わります。

前の章で見た手配の系統がここにも効きます。製番管理の工場では製番が指図の単位になり、MRP中心の工場では製造ロットが単位になります。混在型の工場では、両方の単位を持ち、画面上でどちらの軸でも進捗を見られるようにする設計が要ります。

実績収集の粒度を決める表——工程完了だけか、開始と終了か、作業者と設備まで取るか

実績収集は、取れる情報と現場の負担が正面から衝突する領域です。粒度の選択肢を整理すると次のようになります。

多くの工場で現実的なのは、上から2番目か3番目です。いちばん下まで取りに行く設計は、目的(労務費を配賦したい、設備投資の判断をしたい)がはっきりしている場合だけにしてください。目的のない粒度の細かさは、入力されない項目を増やすだけで、かえってデータの信頼性を下げます。

現場の入力を軽くする4つの手——バーコード、後追い入力、既定値、端末の置き場所

入力を軽くする方法は、突飛なものではなく次の4つに集約されます。

1. 識別をバーコードや二次元コードにする。指図票に印刷したコードを読むだけで、品目・指図・工程が特定できる状態にします。手入力の項目は数量と不良数だけに絞る
2. 後追い入力を正式な運用として認める。その場で入力できない工程があるのは当たり前です。禁止するのではなく、「当日中に入力する」「入力者と実施時刻を分けて記録する」という形で設計に織り込みます
3. 既定値を効かせる。予定数量をそのまま完成数量の初期値にし、差がある場合だけ直す。作業者は前回選択を保持する。画面を開いた瞬間に9割埋まっている状態を作ります
4. 端末を手の届く場所に置く。事務所のパソコンまで歩く運用は必ず形骸化します。工程の横にタブレットや固定端末を置けるか、手袋のまま操作できるか、粉じんや水滴に耐えるか。これはソフトウェアの要件ではなく設置の要件ですが、定着はここで決まります

この4つに手間をかけずに「現場の意識を変える」方向で解決しようとするのは、失敗のもとです。

在庫の引当——「あるのに引き当てられない」を作らない設計

実績が入ると在庫が動きます。ここで必要になるのが引当の設計です。引当とは、在庫のうち特定の指図や注文に割り当てて確保することを指します。

決めるのは3点です。第一に、何に対して引き当てるか(受注、製造指図、出荷指示)。第二に、引当のタイミング(受注時に押さえるか、出庫時に初めて減らすか)。第三に、引当済みの在庫を他へ振り替えられるか、振り替えるなら誰が承認するか。

よく起きるのが「倉庫には現物があるのに、システム上は引き当てられない」という状態です。原因はたいてい、古い注文に紐づいたまま解除されていない引当か、保管場所の区分が細かすぎて別の場所の在庫を見に行けない設計です。引当は確保する機能であると同時に、解除する機能でもあると考えて、解除の導線を最初から作ってください。在庫そのものをどこまで自前で作るかについては「在庫管理システム 自作」の記事もあわせてご覧ください。

工程と実績の設計は、取れる情報を増やす競争ではありません。現場が毎日続けられる操作の範囲に、必要な情報を収める作業です。

ロット管理とトレーサビリティ、原価——どこまで追い、どこまで作り込むか

ここからは、生産管理システムで最も「どこまでやるか」を迷う2つの領域を扱います。ロットの追跡と原価です。どちらも技術的に不可能なことはほとんどなく、決めるべきは範囲です。そして範囲を決めるのはシステム側ではなく業務側だという点が、両方に共通しています。

先入先出とロットの引当——理論上の順番と、現物の置き場所は一致しない

JIS Z 8141:2022 は「ロット,バッチ」(1220)を「何らかの目的の下に、ひとまとまりにされた有形物のグループ」と定義しています。広い定義で、何を1ロットとするかは自社で決めることになります。製造日単位か、原材料の入荷単位か、釜や炉の1回分か。食品や医薬品、電子部品のように後から追跡が要る業種では、この定義がそのまま追跡の粒度になります。

先入先出は、古いロットから使う運用ルールです。システム上は引当の際に有効期限や入庫日の古い順に候補を出すだけですが、問題は現物です。棚の手前に新しいロットが置かれていれば、現場は手前から取ります。システムが古い順を指示しても、現物が取りにくい場所にあれば運用は破れます。

設計として打てる手は3つです。引当時に対象ロットと保管場所を画面と指図票に明示する。指示と違うロットを取った場合に、理由を選んで記録できるようにする(禁止ではなく記録にする)。そして、期限が近いロットを一覧で警告する。3つ目は倉庫のレイアウト変更を促す材料にもなります。

トレーサビリティの定義と、追う範囲の決め方——上流へ何段、下流へ何段

トレーサビリティは、JIS Q 9000:2015(品質マネジメントシステム—基本及び用語)の3.6.13で「対象の履歴、適用又は所在を追跡できること」と定義されています。注記では、製品・サービスについて材料及び部品の源、処理の履歴、提供後の分布及び所在に関係し得るとされています。この規格は対応国際規格ISO 9000:2015と一致する規格で、同じ項番3.6.13の原文でも定義と注記の内容は同じです(確認日2026年9月21日)。

注目したいのは、定義に「どこまで」が入っていないことです。範囲は自社で決めます。決め方としては、上流と下流を段数で表現するのが実務的です。

• 上流へ1段: 自社の製品ロットから、直接使った原材料ロットまで
• 上流へ2段以上: さらにその原材料を供給した先のロット番号まで(取引先の協力が要る)
• 下流へ1段: 自社の製品ロットから、出荷先(納品書単位)まで
• 下流へ2段以上: 出荷先の先、最終消費者に近いところまで(自社だけでは完結しない)

要件定義では「上流1段・下流1段を自社システムで担保し、それ以上は取引先への照会で対応する」のように書きます。この一文があるかないかで、開発の規模が数倍変わります。回収訓練を一度やってみて、何時間で追えたかを測ってから範囲を決めると、議論が具体的になります。

標準原価と実際原価——原価計算基準の定義と、差異を誰が使うか

原価は、企業会計審議会が昭和37年11月8日に公表した「原価計算基準」に定義があります。実際原価は「財貨の実際消費量をもつて計算した原価」、標準原価は「財貨の消費量を科学的、統計的調査に基づいて能率の尺度となるように予定し、かつ、予定価格又は正常価格をもつて計算した原価」とされています(確認日2026年9月19日)。

この2つを両方持つと、差額(原価差異)が出ます。差異が出ること自体は正常で、むしろ差異を見るために標準原価を置きます。問題は、差異を誰がいつ見て、何を判断するかを決めずにシステムを作ってしまうことです。決めていないと、月次で差異の一覧が出力され、誰も開かないという状態になります。

システムの要件として決めるのは次の4点です。

とくに労務費の配賦基準は、前の章の実績収集の粒度と直結します。実工数で配賦したいなら、工程の開始と終了を取る必要がある。配賦基準を先に決めずに実績の粒度を決めると、後から取り直しになります。

能力計画と納期回答——負荷と余力をどこまでシステムに持たせるか

最後に納期回答です。JIS Z 8141:2022 は負荷(1228)を「人又は機械・設備に課せられる仕事量」、余力管理(4103)を「各工程又は個々の作業者について、現在の負荷状態と現有能力とを把握し、現在どれだけの余力又は不足があるかを検討し、作業の再配分を行って能力と負荷とを均衡させる活動」と定義しています。

システムでできることは、工程ごとの負荷を積み上げて、能力を超えている期間を可視化するところまでです。そこから先の平準化(残業でしのぐか、外注に出すか、納期を交渉するか)は人の判断で、自動化しようとすると条件設定だけで膨大になります。

現実的な線引きは、負荷の山積みを表示するところまでをシステムに持たせ、納期回答は「標準リードタイム+余裕日数」で暫定回答し、負荷が超えている期間だけ担当者が手で調整する、という形です。無制限能力で計算した納期をそのまま顧客に回答する設計にしてしまうと、守れない納期を量産することになるので要注意です。

追跡の範囲も原価の作り込みも、正解は業種と規模で変わります。決められるのは業務側だけだ、という前提で要件定義に臨んでください。

Excel・紙・ホワイトボードからの移行——最初に詰まる4つと、着手する順番

ここまでの設計論点は、すべて「現在の運用をデータに写す」作業に帰着します。多くの工場では、現在の運用はExcelの進捗表、受注番号ごとのバインダー、そして工場の壁に貼られたマグネット式のホワイトボードで成り立っています。この3つからの移行で、ほぼ例外なく同じ場所で詰まります。

最初に詰まる4つ——品目コード、現物と帳簿のずれ、例外処理、担当者しか知らない手順

1. 品目コードが統一されていない。同じ部品が、図面では「A-1023」、購買の発注書では「A1023」、現場では「上蓋(旧型)」と呼ばれている。移行作業の最初の数週間は、ほぼこの名寄せに費やされます。ここを飛ばして仮コードで進めると、稼働後にデータが二重になります
2. 現物と帳簿がずれている。Excelの在庫表と実際の棚の数が合わない。移行時に全数の棚卸をするか、差異を許容して一定期間並走するかを先に決めておかないと、稼働初日から数字が信用されません
3. 例外処理が言語化されていない。「急ぎの注文は課長が口頭で割り込ませる」「不良が出たら隣の工程の人が直して報告しない」。こうした例外は必ずあり、そして必ず件数が多いものから順にシステムを壊します。例外を禁止するのではなく、例外として記録できる導線を作るのが設計の仕事です
4. 担当者しか知らない手順がある。なぜその順番で流すのか、なぜその材料だけ多めに手配するのかを、本人以外が説明できない。ヒアリングで「いつもの通りです」と返ってきた項目は、後で必ず問題になります

この4つは開発会社の力では解決できません。社内で業務を説明できる人を専任に近い形で置けるかどうかが、プロジェクトの成否を分けます。要件定義の進め方そのものは「要件定義 進め方」の記事に譲りますが、生産管理に限って言えば、この4つの棚卸しが要件定義の中身の大半を占めます。

着手する順番——品目とBOM→在庫→工程と実績→計画→原価

一度に全部を置き換えようとすると、ほぼ確実に途中で止まります。下流の機能は上流のデータが揃って初めて正しい値を出すので、次の順番で段階的に進めるのが定石です。

段階1と2だけでも、多くの工場では「探す時間」が目に見えて減ります。効果が出る順番で並んでいることも、この順序を勧める理由です。既存の基幹システムを刷新する場合の段階移行の考え方は「レガシーシステム刷新 外注」の記事も参考になります。

ホワイトボードを消さないまま並走する期間をどれだけ取るか

移行で最も軽視されるのが、並走期間の設計です。新しいシステムに入力しながら、これまでのExcelとホワイトボードも同時に維持する期間のことです。

並走は二重入力になるので現場は嫌がりますが、これを省くと、稼働直後に不具合が出たときの逃げ場がなくなります。目安としては、工程と実績収集(段階3)で1〜2か月、在庫(段階2)で棚卸を1回挟むまで。並走をやめる判断基準を「システムの数字と手作業の数字が2週間連続で一致したら」のように事前に決めておくと、現場との合意が取りやすくなります。

そして、ホワイトボードをすべて消す必要はありません。朝礼で全員が同じ絵を見るという機能は、端末の画面では代替しにくいものです。システムのデータを大型ディスプレイに映して置き換えるのか、ホワイトボードは残して役割を分けるのかも、移行計画に書いておいてください。

移行は、品目コードの名寄せから始めて原価で終わる。この順番を守ることが、稼働後に現場の信頼を失わないための条件です。

外部チームで生産管理システムを作る場合の進め方——当社の位置づけと役割分担

ここまで読んで、「社内に開発の手がないので外に出したい」と考えた方が多いと思います。最後に、外部チームを使う場合にどこまでを出せるのかと、当社がこの領域でどういう位置にいるのかを、率直に書きます。

外に出せる範囲と、社内に残すべき範囲——業務を説明できる人を外注できない

生産管理システムの開発で外に出しやすいのは、仕様が文書になったあとの実装、テスト、リリース後の保守です。逆に外に出せないのは、自社の工場で何が起きているかを説明する役割です。

前の章で挙げた4つの詰まりどころ(品目コードの名寄せ、現物と帳簿のずれ、例外処理、担当者しか知らない手順)は、いずれも工場の中にしか答えがありません。開発会社がヒアリングで引き出せるのは、聞かれたことに答えられる範囲だけです。「いつもの通り」で済まされている手順は、聞かれないので出てきません。

したがって役割分担は、業務要件と受入判断を社内、設計以降の実装と保守を外部、という線が基本になります。社内に置く人は専任でなくとも構いませんが、現場に指示を出せる立場であることが条件です。開発会社の選び方そのものは「システム開発会社 選び方」の記事に譲ります。

当社の位置づけ——製造業の生産管理システムの開発に対応しています

当社はベトナム・ホーチミンを拠点に、日本人PMまたはブリッジSEをフロントに置いたラボ型の開発チームを提供しています。2,000名以上のIT人財データベースから直接アサインし、公開単価は実務3年目安で1,500USD(約22.5万円 / 1USD=150円換算目安)、5年で2,000USD、10年目安・ブリッジSEで3,000USD。最小構成は日本人PMフロント+2〜3人月で月額約80万円からです。1名から契約でき、増員は約1週間、縮小や交代は1か月単位で対応しています。

そのうえで、当社の位置づけを書きます。当社は製造業の生産管理システムの開発に対応しています。サイトで公開している実績は、介護記録SaaS「CareViewer」の継続開発(日本語ブリッジSE1名+フルスタック2名)、ヘルスケアの「HELTEQ」(フルスタック4名)、金融系マッチングサービス(PM1名+フルスタック2名)、決済アプリ、AIチャットボット、求人プラットフォーム、コーポレートサイトなどです。

ただし、生産管理は業務知見が設計そのものです。BOMの持ち方も引当の解除の導線も、工場の運用を知らなければ「言われたとおりに作る」ことしかできません。外部チームだけで要件定義を完結させようとするのは、どの会社に頼んでも失敗のもとです。構想段階からご相談いただく場合も、業務要件を決めて受入を判断する人を御社側に置いていただくことが前提になります。その前提が置けるかどうかを、最初に確認させてください。

当社の体制が合いやすい切り出し方と、費用の調べ方

とくに、次のような切り出し方であれば、当社の体制が合います。

• 要件と画面仕様が社内または業務に強いベンダーで固まっており、実装とテストだけを継続的に回したい場合
• 実績収集の端末画面や、既存システムとのデータ連携のように、業務ロジックへの依存が小さく独立性の高い部分を切り出す場合
• 稼働後の保守と小さな改修を、固定の月額で継続的に依頼したい場合

いずれも、業務を説明できる人が御社側にいることが前提です。品質面では、日本人PMによる設計レビュー、Gitのプルリクエストによるコードレビューの標準化、リリース前のダブルチェックを標準の運用としています。契約と支払いは日本国内法人・日本法準拠で、海外送金は不要です。ベトナムとの時差は2時間、祝日は2026年で年12日(労働法112条の法定は11日で、2026年からベトナム文化の日が加わります)、テト(旧正月)は2026年は2月14日から22日で、この期間は稼働が止まります。

費用の目安を先に知りたい方は、機能別の相場をまとめた「業務システム開発 外注 費用」の記事をご覧ください。生産管理は業界特性で幅が大きい領域なので、相場の数字はあくまで初期の予算感の目安として使ってください。

現在の体制と要件をお聞かせいただければ、当社が請けられる範囲かどうかの判断と概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。

生産管理システムの開発に関するよくある質問

最後に、相談の場で実際によく出る5つの疑問に答えます。どれも「自社はどちらか」を判断するための材料として読んでください。

Q1. パッケージで足りるのか、自社開発すべきかはどう判断しますか

判断の軸は、自社の生産方式と、競争力の源泉がどこにあるかの2つです。繰返し生産が中心で、工程の流れが業界標準に近いなら、パッケージの標準機能で足りる可能性が高くなります。逆に、個別受注で製番ごとに工程が変わる、独自の原価の見方が競争力になっている、という場合は標準機能に業務を合わせきれません。判断の順序としては、まず本記事の6つの論点を自社の言葉で書き出し、その一覧をパッケージのデモで突き合わせてください。合わない項目の数と、その項目が業務の中心かどうかで決まります。パッケージとスクラッチの一般的な違いは「スクラッチ開発とは」の記事にまとめています。

Q2. どこから作り始めるのがよいですか

品目マスタと部品構成(BOM)からです。次に在庫の入出庫、その次に工程と実績収集、そのあとに生産計画と所要量計算、最後に原価という順番になります。下流の機能は上流のデータが揃わないと正しい値を出せないため、順番を入れ替えると「動くが信用されない機能」ができます。

Q3. 現場が使ってくれないのが心配です。対策はありますか

入力の手間を減らす設計に、開発費の相応の割合を配分してください。具体的には、指図票のバーコード化、既定値の作り込み、工程の横に置ける端末、後追い入力を正式な運用として認めること、の4つです。加えて、実績を入力した人が自分の画面で何かの役に立つ(自分の工程の進み具合が見える、翌日の予定が分かる)状態を作ると定着が早くなります。入力するだけで何も返ってこない画面は、必ず形骸化します。

Q4. MESやERPとは何が違うのですか

一般的な整理では、ERPの生産モジュールは会計や在庫と接続した計画側、MES(製造実行システム)は現場の作業指示と実績収集、生産管理システムはその中間で計画と実行をつなぐ層を指します。ただしこの区分は各社の製品説明に基づくもので、JIS Z 8141:2022(生産管理用語)にMESという用語は立てられていません(CIMの注記に名前が出るだけです)。名称で悩むより、計画・指示・実績・在庫・原価のどこまでを1つのシステムで持つかを範囲として書き出すほうが実務的です。

Q5. 開発にはどのくらいの期間がかかりますか

期間は範囲と生産方式で大きく変わるため、一律の目安を示すことはできません。確かなのは、品目コードの名寄せとマスタ整備に想定より時間がかかること、そして段階1(品目とBOM)から段階5(原価)まで一度に進めると途中で止まりやすいことです。当社のラボ型の体制では1名から開始でき、最短2週間で立ち上げ、増員は約1週間、縮小と交代は1か月単位という単位で調整しますが、期間の見通しを左右するのは開発体制よりも社内のマスタ整備の速度。

まとめ: 生産方式を決め、マスタを整え、実績入力を軽くする——この順番が生産管理システム開発の分かれ目

生産管理システムの開発で最初に決めるのは、機能ではなく生産方式です。受注生産か見込生産か、手配を製番でつなぐのか所要量計算(MRP)で回すのか。JIS Z 8141 の定義では、受注生産と見込生産は「誰が仕様を決めるか」で分かれ、製番管理方式とMRPは手配の紐付け方が違います。ここが決まって初めて、部品構成(BOM)の持ち方、工程と実績の取り方、在庫の引当、原価の集計単位が決まります。混在している工場のほうが多いので、品目群ごとにどちらで回すかを属性として持たせる設計にしてください。

そのうえで、開発の前半で時間を使うべきなのはマスタです。設計部門の表と製造部門の表をどちらを正とするか、中間品を品目にするか、設計変更をいつから効かせるか、リードタイムを調達と製造に分けて持つか。所要量計算が狂う原因は、機能の不足ではなく在庫のずれ・構成の古さ・リードタイムの放置という運用の問題に集約されます。そして実績収集は、取れる情報を増やす競争ではなく、現場が毎日続けられる操作の範囲に必要な情報を収める作業です。バーコード、後追い入力の公認、既定値、端末の置き場所——この4つに手間をかけたシステムだけが定着します。移行は品目コードの名寄せから始め、在庫、工程と実績、計画、原価の順に進めてください。

最後に率直に書きます。当社は製造業の生産管理システムの開発に対応しています。ただし生産管理は業務知見が設計そのものであり、外部チームだけで要件定義を完結させるのは失敗のもとです。業務要件を決めて受入を判断する人を御社側に置いていただければ、仕様が固まったあとの実装と保守はもちろん、実績収集の端末画面やデータ連携のように独立性の高い部分からでも着手できます。費用の目安は業務システム開発を外注する費用、在庫を自前で作れるかの判断は在庫管理システムの自作もあわせてご覧ください。現在の体制と要件をお聞かせいただければ、当社が請けられる範囲かどうかの判断と概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。