「現場の運用に合う仕組みが見つからない」「パッケージを入れたのに結局Excelが残った」。そうした行き詰まりから生産管理システムの開発を検討し始める製造業は少なくありません。本記事では、スクラッチとパッケージの違い、規模別の費用相場と導入期間の目安、そして開発を任せる外注先の選び方までを、公開されている相場データをもとに整理します。タイ・ASEAN拠点で開発する場合に増える論点にも触れます。
生産管理システムを「開発」するとは|スクラッチとパッケージの違い
生産管理システムを「開発する」と言ったとき、実際には性格の異なる複数の選択肢が含まれています。まずはこの整理から始めないと、社内の議論も、開発会社への相談も噛み合いません。
3つの選択肢を区別する
大きく分けると、次の3つです。
- スクラッチ開発。要件をゼロから設計し、自社専用の仕組みとして作る方式です。既製品の制約を受けないため、自社の生産方式や受発注ルールをそのまま形にできます。
- パッケージ導入。既に製品として完成しているシステムを購入または契約し、自社に合わせて設定していく方式です。クラウド型(SaaS)と自社サーバー設置型があります。
- パッケージ+アドオン開発。パッケージを土台にしつつ、足りない部分だけを追加開発する折衷案です。実務上はこの形が最も多く、「開発費用」の見積もりが膨らみやすいのもここです。
「開発」という言葉を使う担当者の多くは、実はこの3つ目を想定しています。にもかかわらず、社内の稟議では「パッケージ導入なので安いはず」と説明されてしまい、後から追加開発費で計画が崩れる。これは非常によくあるすれ違いです。
製造業の生産管理は独自ロジックが多い
一般的な会計や人事給与と違い、生産管理は企業ごとの差が極端に大きい領域です。同じ「受注生産」でも、内示の扱い方、手配の単位、工程の分割の仕方、外注先への支給ルールは会社ごとに異なります。参考にしたスクラッチ開発の解説記事でも、製造業の生産管理や独自の受発注ルールなど、業界・企業固有のロジックが多い場合はスクラッチ開発のほうが運用負荷を大幅に下げられる、と指摘されています。
つまり生産管理システムは、他の業務システムに比べてスクラッチ開発が合理的になりやすい領域だということです。ただし「独自ロジックが多いからスクラッチ」と短絡するのも危険で、その独自ロジックが本当に競争力の源泉なのか、単に過去の慣習が残っているだけなのかを見極める必要があります。
判断は5つの軸で行う
スクラッチかパッケージかを決める際の判断軸は、次の5つに整理できます。
| 判断軸 | スクラッチが向くケース | パッケージが向くケース |
|---|---|---|
| 業務の独自性 | 自社固有の生産方式・受発注ルールが競争力になっている | 業界標準的な流れで運用できる |
| 予算と時間 | 初期投資を確保でき、稼働までの時間も取れる | 短期間・低初期費用で立ち上げたい |
| 将来の拡張性 | 拠点追加や設備連携など、継続的に手を入れたい | 機能追加はベンダーの製品ロードマップに任せたい |
| 社内のIT体制 | 要件を語れる担当者がいる、または伴走してくれる相手がいる | 社内にIT担当が不在で、運用も任せたい |
| ベンダー依存リスク | ソースコードを保有し、将来別の会社にも引き継がせたい | 製品の継続性とサポートを重視する |
そしてもう1つ、見落とされがちな観点が総所有コスト(TCO)です。初期費用だけで比べるとパッケージが有利に見えますが、5年から10年の運用を通して見ると、毎年のライセンス費用、バージョンアップ対応費用、そしてアドオンの改修費が積み上がります。逆にスクラッチは初期費用が重い代わりに、ライセンス費が発生しません。比較するなら、必ず同じ年数の合計額で並べてください。
なお、既に稼働しているシステムがあり「作り直すか、延命するか」で迷っている場合は、生産管理システムの老朽化とリプレース判断で整理した6つの変数による採点方法が判断の助けになります。本記事は、その先で「では、どう作るか」を決める段階の話です。
生産管理システム開発の費用相場を規模別に比較する
費用は最も知りたい情報でありながら、最も答えにくい情報でもあります。ここでは公開されている相場データをそのまま提示し、なぜ幅が大きいのかを説明します。

スクラッチとパッケージの費用相場
スクラッチ開発とパッケージ開発の費用相場を比較した解説記事では、規模別に次の水準が示されています。
| 規模 | スクラッチ開発の費用相場 | パッケージ開発の費用相場 |
|---|---|---|
| 小規模 | 300万〜800万円 | 初期50万円〜に加えて月額数万円 |
| 中規模 | 800万〜3,000万円 | 200万〜1,000万円 |
| 大規模 | 3,000万〜1億円以上 | 1,000万〜5,000万円以上 |
この表で注目してほしいのは、小規模と大規模で桁が2つ違う点です。同じ「生産管理システムの開発」という言葉でも、扱う範囲が違えば別の買い物になります。
基幹システム全体で見た場合の相場
生産管理単体ではなく、販売管理や在庫、会計連携まで含めた基幹システムとして構築する場合は、別の相場感になります。同じ運営元が公開している基幹システムの費用相場記事では、次のように整理されています。
| 規模の目安 | 想定される範囲 | 費用相場 |
|---|---|---|
| 小規模(社員50名以下) | 販売管理・在庫管理などシンプルな機能 | 500万〜2,000万円 |
| 中規模(社員50〜300名) | 販売管理に在庫・会計連携を加えた構成 | 2,000万〜8,000万円 |
| 大規模(社員300名以上) | 複数拠点・グループ会社統合まで含む | 8,000万〜3億円以上 |
費用の幅がこれほど広くなる理由として挙げられているのは、カスタマイズ要件の多寡、連携する他システムの数、そしてベンダーの規模の3点です。裏を返せば、この3点を早い段階で固められれば、見積もりの幅は確実に縮まります。
費用の内訳は「単価×人数×期間」
スクラッチ開発の費用は、突き詰めればエンジニアの人件費です。外注先選びに関する解説記事によれば、エンジニアの月単価はおおむね40万円から200万円の範囲にあり、これに投入人数と開発期間を掛け合わせたものが開発費の主要部分になります。
この構造を理解すると、見積書の読み方が変わります。総額だけを見て高い安いを判断するのではなく、「何人月か」「その単価は妥当か」「その人月数は要件の量に見合うか」という3つに分解して質問できるようになるからです。単価が安くても人月数が膨らんでいれば総額は変わりませんし、単価が高くても短期間で終わるなら結果的に安く済むこともあります。
費用を抑えるための現実的な手段
同じ記事では、コストを下げる方向性として次のような手が挙げられています。
- 既存のライブラリやオープンソースソフトウェアを活用し、ゼロから作る範囲を減らす。
- 契約形態を工夫する。ただし準委任契約に寄せると発注側のリスクは増えるため、安易な選択は避ける。
- 補助金や助成金を活用する。申請の手間はかかりますが、対象になれば効果は大きい。
これらに加えて実務的に効くのは、初期スコープを絞ることです。5年後に必要かもしれない機能まで最初に作り込むと、費用も期間も膨らみ、しかもその機能は使われないまま終わることが少なくありません。
生産管理システムの導入期間はどれくらいかかるか
費用と並んで判断を左右するのが期間です。「来期から使いたい」という要望に対して、それが物理的に可能なのかを最初に確認しておく必要があります。
規模別の期間の目安
先に挙げた費用相場と同じ出典では、規模別の開発期間として次の水準が示されています。
| 規模 | スクラッチ開発の期間 | パッケージ導入の期間 |
|---|---|---|
| 小規模 | 2〜4ヶ月 | 1〜2ヶ月 |
| 中規模 | 4〜10ヶ月 | 2〜6ヶ月 |
| 大規模 | 10ヶ月〜2年以上 | 6ヶ月〜1年以上 |
ここで重要なのは、この期間が「開発会社が作業している期間」であって、「相談を始めてから本稼働するまでの期間」ではないという点です。実際のプロジェクトでは、この前後に発注者側の時間が必要になります。
期間の内訳を分解する
生産管理システムの導入期間は、おおよそ次のような段階に分かれます。
| 段階 | 主な作業 | 主に動く担当 |
|---|---|---|
| 構想・要件整理 | 課題の棚卸し、対象業務の範囲決め、概算予算の確定 | 発注側の情報システム部門と業務部門 |
| 発注先選定 | 提案依頼、複数社比較、契約 | 発注側の購買・法務を含む担当 |
| 設計・開発 | 詳細設計、実装、単体テスト | 開発会社 |
| テスト・データ移行 | 受入テスト、マスタ整備、既存データの移行 | 発注側と開発会社の共同 |
| 移行・定着 | 並行稼働、現場教育、運用ルールの調整 | 発注側の現場部門 |
相場として示されている期間が対応しているのは、このうち「設計・開発」の行だけです。しかも表を見て分かる通り、開発会社が主役になるのは5段階のうち1つで、残りは発注側が動かなければ前に進みません。「開発は半年と言われたのに、なぜ1年経っても使えないのか」という不満の多くは、この前後の工程を計画に入れていなかったことに起因します。自社のスケジュールを引くときは、開発期間の前後にそれぞれ助走と着地の時間が必要だという前提で、社内の関係者と早めに合意しておいてください。
期間が延びる典型的な原因
計画より遅れるプロジェクトには、共通のパターンがあります。
- 要件が固まらないまま開発を始めてしまい、途中で仕様変更が繰り返される。
- マスタデータの整備が想定より重い。品目マスタの重複や、実態と合わない工程マスタの棚卸しに、当初の見込みを大きく超える時間がかかることがあります。
- 現場のキーパーソンが多忙で、テストや確認に時間が取れない。
- 決裁のタイミングが年度予算に縛られ、承認待ちで数週間止まる。
このうち発注側の努力で最も改善しやすいのは、2番目のマスタ整備です。開発会社が決まる前から着手できる作業であり、ここを先行させておくとプロジェクト全体が驚くほどスムーズになります。
期間を短縮する考え方
期間を縮めたい場合、単純に人を増やしても効果は限定的です。それよりも、対象範囲を分割して段階的に稼働させるほうが確実です。たとえば最初のリリースでは受注から製造指示までに絞り、原価計算や外注管理は第2フェーズに回す。こうすれば最初の効果を早く得られ、その運用経験を次のフェーズの要件に反映できます。
失敗しない外注先の選び方|開発会社を見極める視点
生産管理システム開発の成否は、要件そのものよりも「誰と組むか」で決まる部分が大きいというのが実感です。同じ要件書を渡しても、相手が変われば出てくるものは変わります。

選定時に確認すべき4つの基本項目
外注先選びの解説記事では、押さえるべきポイントとして次の4点が挙げられています。それぞれについて、実際に何を聞けばよいかを整理します。
| 確認項目 | なぜ重要か | 具体的に聞くこと |
|---|---|---|
| 得意分野の一致 | Web制作が主体の会社に基幹系を頼むと、非機能要件の設計で苦労する | 直近3年で受注した案件の業種と種別の内訳 |
| スクラッチ実績と業界知識 | 生産管理特有の用語が通じないと、要件定義に余計な時間がかかる | 製造業向けの構築実績、工程管理や原価計算の経験 |
| コミュニケーション力 | 認識のズレは手戻りに直結する | 打ち合わせの頻度、議事録の作成主体、質問への回答速度 |
| アフターフォロー体制 | 稼働後の改修対応が止まると資産が死ぬ | 保守契約の範囲、対応時間帯、担当者の継続性 |
そして同じ記事が強調しているのが、複数社から見積もりを取ることの重要性です。1社だけの見積もりでは、その金額が高いのか安いのか、そもそも要件を正しく理解しているのかを判断する材料がありません。
提案内容を比較するときの実務的な注意点
複数社の見積もりを並べると、金額が大きく食い違うことがあります。このとき安いほうを選ぶ前に確認すべきなのは、前提条件が揃っているかどうかです。
- テストの範囲。受入テストの支援まで含むのか、開発会社の単体テストまでなのか。
- データ移行の扱い。既存データの抽出は誰がやるのか、変換ロジックの作成は費用に含まれるのか。
- 現場教育。マニュアル作成や操作説明会が含まれているか。
- 稼働後の保守。最初の数ヶ月の不具合対応が無償なのか、別契約なのか。
見積もりの前提を揃える具体的な進め方については、生産管理システムのRFP作成ガイドで、同じ要件でも提示の仕方によって見積額が大きく開いてしまう問題と、その対処法を詳しく扱っています。
避けたほうがよい兆候
提案や面談の場で次のような兆候が出た場合は、慎重に判断してください。
- 現場の業務を聞く前に、いきなり自社製品の説明を始める。
- 「何でもできます」と答え、できないことを一度も言わない。
- 見積もりの内訳が「システム開発一式」で、人月数も工程の内訳も示されない。
- 実際に担当するエンジニアが商談に一度も出てこない。
- 稼働後の体制について質問しても、具体的な人数や時間帯が返ってこない。
特に4番目は重要です。提案時の担当者と実際の開発担当者が別人であることは珍しくありませんが、その事実すら明かされない場合、稼働後のコミュニケーションで苦労する可能性が高くなります。
生産管理システムの導入事例に学ぶ、開発を成功させる進め方
「導入事例」を探している方の多くは、他社が具体的にどう進めたのかを知りたいのだと思います。ただし他社の事例は、業種も規模も生産方式も違うため、そのまま真似ても機能しません。ここでは個別企業の名前や数字ではなく、うまくいったプロジェクトに共通する進め方のパターンとして整理します。
進め方の基本パターン
多くの成功事例に共通するのは、次の順序を守っていることです。
- 現状の課題を、業務単位ではなく「困っている場面」で洗い出す。「在庫管理をシステム化したい」ではなく「引当済み在庫が実棚と合わず、月末に半日かけて突合している」という粒度まで下ろします。
- その場面ごとに、システムで解決できるものと、運用ルールの変更で解決できるものを仕分ける。後者をシステムに持ち込むと、費用も複雑さも無駄に増えます。
- 効果が大きく、かつ実現が容易な領域から着手する。最初のフェーズで目に見える成果を出すことが、社内の協力を得る最短経路です。
- 稼働後3ヶ月から6ヶ月の改善を、あらかじめ計画と予算に織り込む。作って終わりのプロジェクトは定着しません。
現場を巻き込む仕組みを先に作る
生産管理システムは、実際に入力するのが現場の担当者です。この人たちが「使いにくい」と感じた瞬間から、Excelでの二重管理が復活します。
有効なのは、開発の初期段階から現場のキーパーソンを1人か2人、正式なメンバーとしてプロジェクトに入れることです。会議に呼ぶだけでなく、画面設計のレビューと受入テストに責任を持ってもらいます。この役割の人がいるかどうかで、稼働後の定着率は大きく変わります。
データ移行とマスタ整備を軽く見ない
導入事例の記事にはあまり書かれませんが、実際のプロジェクトで最も揉めるのがここです。品目マスタに重複があり、同じ部品が3つのコードで登録されている。取引先マスタに廃業した会社が残っている。工程マスタが実際の作業と乖離している。こうした状態のまま移行すると、新システムでも同じ混乱が再現されます。
マスタ整備は開発会社に丸投げできません。どのコードを残すかは業務判断だからです。プロジェクト開始と同時に、社内で棚卸しの担当を決めてください。
効果の測り方を最初に決める
「導入してよかったのか」を後から議論しても答えは出ません。着手前に、何をもって成功とするかを数値で決めておきます。たとえば月末の在庫突合にかかっている時間、納期回答までのリードタイム、手配漏れの発生件数など、現在値が測れるものを選ぶのがコツです。現在値が分からない指標を目標にすると、効果検証ができなくなります。
そして、この指標は経営層と現場の両方が納得できるものにしてください。経営層だけが見る指標は現場の協力を得られず、現場だけが実感する改善は次の投資判断につながりません。両者が同じ数字を見ている状態を作ることが、システムを一過性のプロジェクトで終わらせないための条件です。
タイ・ASEANで生産管理システムを開発する場合に増える論点
日本国内での開発と、タイをはじめとするASEAN拠点での開発では、検討すべき論点が変わります。

現地の製造業を取り巻く環境の変化
タイの製造業に関する解説では、スマートファクトリーの導入が進み、ベトナムやインドネシアと比較したときのタイの位置づけが、単純な人件費の安さから高付加価値・高複雑性の生産へとシフトしていると整理されています。低コストだけを理由にタイで生産する時代は終わりつつあり、その分だけ生産の複雑さを管理する仕組みの重要性が増しているということです。
また、製造業向けITの動向としては、IoTデータとERPやMESの統合、いわゆるOTとITの連携によるデジタルツインやIIoT分析が2026年の重点領域として挙げられています。現場設備から上がるデータと、生産管理システムが持つ計画・実績データをどうつなぐかは、これから作るシステムでは避けて通れない検討項目です。
カスタムERPに関する海外の解説記事でも、稼働可能な設備、人員配置、資材の準備状況、保全スケジュール、納期を統合したスケジューリングが可能になること、リアルタイムの在庫監視と自動発注アラートによって在庫コストを下げられること、そしてIoTセンサーやAI分析基盤と直接連携できることが、既製品にはない利点として整理されています。
拠点特有の論点
タイ・ASEANでの開発では、日本国内には存在しない検討事項が加わります。
| 論点 | 具体的な内容 |
|---|---|
| 言語 | 画面とマニュアルの多言語対応。日本人駐在員、タイ人管理者、現場オペレーターで必要な言語が異なる |
| 帳票と税務 | 現地の会計・税務要件に沿った帳票。日本本社向けの報告様式との二重対応 |
| 本社連携 | 日本本社の基幹システムとのデータ連携。締めのタイミングや品目コード体系の違い |
| 人材の流動性 | 担当者が交代しても運用が続く設計。属人化した仕組みは持続しない |
| 保守の距離 | 障害時に現地で対応できる体制があるか。時差と移動時間は想定より重い |
現地開発というコスト最適化の選択肢
日本の開発会社に発注し、日本の単価で開発する方法もあれば、現地に開発拠点を持つパートナーに依頼する方法もあります。後者は人件費構造の違いからコストを抑えやすく、かつ現地の商習慣や法制度に沿った実装がしやすいという利点があります。
一方で、現地企業に直接発注する場合の最大の障壁は、日本語での要件定義と、日系製造業特有の商慣習の理解です。内示と確定注文の扱い、有償支給と無償支給の区別、検収のタイミング、日本本社への報告様式。これらは仕様書に書き切れない暗黙の前提を多く含みます。
そのため実務上は、日本語で要件を詰められ、かつ現地に開発体制を持つパートナーを選ぶのが最も無理のない形になります。TOMAS TECHはバンコクを拠点に、日系製造業向けの生産管理システムやエネルギー管理システムを提供しており、日本語での要件定義から現地での開発・保守までを一貫して担える体制を取っています。
なお、既に本社側でパッケージを標準採用していて、それを現地に展開する話であれば、開発ではなく適合性の検証が先になります。その場合の進め方はパッケージソフト導入支援とFit&Gap分析で詳しく扱っています。
よくある質問
生産管理システムの開発費用はいくらかかりますか
規模によって大きく変わります。公開されている相場では、スクラッチ開発の場合、小規模で300万〜800万円、中規模で800万〜3,000万円、大規模で3,000万〜1億円以上とされています。パッケージ導入であれば、小規模は初期50万円程度から始められる一方、大規模では1,000万〜5,000万円以上になります。
この幅が生まれる要因は、カスタマイズ要件の多さ、他システムとの連携数、そしてベンダーの規模です。概算を早く知りたい場合は、対象業務の範囲、想定利用人数、連携したい既存システムの3点を整理して相談すると、精度の高い回答が得られます。
スクラッチとパッケージのどちらを選ぶべきですか
自社の業務の独自性が競争力になっているかどうかが、最大の分かれ目です。独自の生産方式や受発注ルールが強みであれば、それをパッケージに合わせて捨てるのは損失になります。逆に、業務の流れが業界標準的であれば、パッケージのほうが早く安く立ち上がります。
判断に迷う場合は、初期費用ではなく5年から10年の総所有コストで比較してください。パッケージは初期が軽い代わりに、ライセンス費用、バージョンアップ対応、アドオンの改修費が継続的に発生します。この合計で並べると、印象が変わることがあります。
開発を始めてから使えるようになるまで、どれくらいかかりますか
開発作業そのものは、小規模なスクラッチで2〜4ヶ月、中規模で4〜10ヶ月、大規模では10ヶ月から2年以上が目安とされています。ただしこれは開発工程だけの期間です。実際には、この前に構想と要件整理、発注先選定の期間が加わり、後にテストとデータ移行、現場への定着の期間が加わります。相談を開始してから本稼働までの全体は、開発期間だけを見た場合よりかなり長くなると考えてください。
「来期から使いたい」という要望がある場合は、逆算して今から何を始めるべきかを整理することをおすすめします。特にマスタデータの棚卸しは、開発会社が決まる前から着手できる作業です。
まとめ
生産管理システムの開発を検討する際に押さえるべき点を整理します。
- 「開発」にはスクラッチ、パッケージ、パッケージ+アドオンの3つがあり、費用と期間の前提がそれぞれ違う。
- 費用相場はスクラッチで300万円から1億円以上、パッケージで50万円程度から5,000万円以上と幅が広い。幅の原因はカスタマイズ量、連携数、ベンダー規模の3点。
- 比較は初期費用ではなく、5年から10年の総所有コストで行う。
- 導入期間は開発工程だけを見ないこと。前後の要件整理、選定、テスト、データ移行、定着を含めた全体で計画する。
- 外注先は、得意分野の一致、製造業での実績、コミュニケーション力、アフターフォロー体制の4点で見極め、必ず複数社を比較する。
- 成功するプロジェクトは、課題を場面単位で洗い出し、効果が大きく実現が容易な領域から段階的に進めている。
- タイ・ASEAN拠点では、言語、帳票、本社連携、人材の流動性、保守の距離という論点が加わる。
最も避けたいのは、費用と期間の相場観を持たないまま1社だけに相談し、提示された金額が妥当かどうか判断できないまま進めてしまうことです。本記事の数値は、その判断の出発点として使ってください。
自社の生産管理をスクラッチで作るべきか、パッケージで足りるのか。まだ社内で方針が固まっていない段階でも構いません。TOMAS TECHはタイ・バンコクを拠点に、日系製造業向けの生産管理システム開発と現地での保守を手がけています。現状の課題整理や概算費用の見立てだけのご相談も承っていますので、お問い合わせフォームからお気軽にご連絡ください。