生産管理システムの刷新は、現状分析(アセスメント)、要件定義、RFP(提案依頼書)作成、ベンダー選定の順に進めると、移行後の業務停止や要件の漏れを防げます。
全体像については、生産管理システムのモダナイゼーションの完全ガイドでもあわせて確認できます。
▼全体ガイドの記事
・生産管理システムのモダナイゼーションの完全ガイド
レガシーシステム刷新の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
アセスメントと現状分析によるAS-IS可視化

経済産業省の「2025年の崖」では、レガシーシステムを放置した場合、2025年以降に年間最大12兆円の経済損失が生じるリスクが示されています。さらに、JUAS(日本情報システム・ユーザー協会)の調査でも、約7割の企業が基幹システムのレガシー化を経営課題と認識しています。
刷新では、現行システムの全体像を正確に把握するAS-IS可視化が欠かせません。なかには、仕様を把握している人がいないほどブラックボックス化したシステムもあります。
生産管理システムは、MESや工程、品質、在庫、原価管理、IoT連携などが複雑に絡み合っています。さらに、生産管理システムの仕様書は、長年の改修で未作成または未更新の場合もあります。
現状を把握しないまま要件定義や発注を進めると、移行後に現行の処理ができない、夜間バッチが終わらないといった問題につながります。刷新の失敗原因の多くは、技術そのものより現状分析と要件定義の精度不足にあります。
アプリ資産の複雑度と依存関係の可視化
要件定義の前にアプリ資産を棚卸しするのは、システムがどれほど複雑で、どこが互いに絡んでいるかを把握するためです。見る面は、プログラムの本数から、モジュール同士の結びつき、改修の偏り、使われていない処理までの4つです。
- プログラム本数
- モジュール間の依存関係
- 改修が集中している箇所
- 使われていないデッドコード
刷新が失敗する大きな原因は、現行の仕様書がない、または更新されず、システムがブラックボックス化していることにあります。これらを洗い出せば、システムの複雑度を客観的に把握できます。仕様が分からないまま要件を定めると、内容が不十分になりやすいからです。
富士通の「ソフトウェア地図」のような可視化ソリューションは、資産の複雑度や依存関係を地図のように描き出します。描き出された全体像は、刷新の難所や着手箇所を判断する材料になります。
担当者の経験や記憶に頼る現状把握には限界があるため、ツールで複雑度を定量的に捉えると、要件定義の精度を高められます。さらに、洗い出した結果は、後段のRFPでベンダーに現行構成を正確に伝える際にも役立ちます。
生産管理固有の業務と運用の棚卸し
生産管理の業務と運用では、工程や設備、現場の手作業が密接に絡み合っています。そのため、現場へのヒアリングと帳票・記録の確認で補いながら、5つの面を洗い出します。具体的には、次の項目を棚卸しの対象とします。
- 工程フロー:受注から出荷までの順序と分岐
- 帳票類:現場の帳票、指示書、ラベルの種類と様式
- 設備連携:設備、PLC、IoTセンサーとの連携構成と方式
- システム外の運用:Excelや紙の台帳、手作業による補完処理
- データ体系:マスタや取引データの項目、桁数、コード体系
見落としやすいのは、Excelや紙で続けている「裏の業務」です。仕様書に載らない運用は現場ヒアリングで把握し、移行後に現場が回らなくなる事態を防ぎます。
業務棚卸しと要件定義だけを外部に依頼する場合、費用相場は200万〜500万円程度が目安です。刷新本体の開発費に比べれば小さな投資ですが、業務棚卸しや要件定義を省くと、後工程で何倍ものコストとして跳ね返ります。そのため、発注側はアセスメントを、刷新全体のリスクを下げる先行投資として位置づけます。
要件定義によるTO-BEと移行要件の具体化

アセスメントの後は、TO-BE(あるべき姿)と移行要件を要件定義書にまとめます。その内容が、RFPの中核になります。
生産管理システムでは、性能や連携、データ移行などの非機能要件が成否を左右します。そのため、機能要件に加えて、これらも測定できる形で具体化しておきます。要件が曖昧なままだと、ベンダーごとに解釈が分かれ、見積もりを比べられません。
測定可能な性能要件とKPIの定義
生産管理システムの刷新では、性能要件をとくに丁寧に定めます。現行の処理性能を満たせなければ、刷新そのものが失敗とみなされるからです。
性能要件は、刷新後の処理が現行の水準で動くかを確かめる条件です。RFPには、現行構成図とあわせて、処理時間や接続数、データ量などを数値で示します。
- 夜間バッチ:原価計算バッチを翌朝6時までに完了するなどの時間条件
- 接続と応答:同時接続ユーザー数とピーク時のレスポンス目標
- 実績収集:製造実績を収集する際のリアルタイム性の要求水準
- 処理量:月末や繁忙期のデータ量を想定したスループット
数値をそろえると、ベンダーは共通の前提で設計と見積もりを行えます。たとえば、夜間バッチは現行の所要時間を実測し、刷新後の目標値とあわせて記載します。
また、刷新後に達成するKPIも定めておきます。KPIが明確であれば、刷新の効果を客観的に評価でき、ベンダーにも目指すゴールが伝わります。
代表例は、夜間バッチの処理時間短縮率、保守費の削減率、品質トレーサビリティの網羅率です。目標は、「バッチ処理時間を現行比で40%短縮する」「ロット単位の品質追跡を全工程で100%カバーする」のように、測定できる形で書きます。KPIは、要件定義でどれを優先するかを判断する基準にもなります。
MES・IoT連携要件とデータ移行要件の明記
生産管理システムは、MESや設備、IoTとの連携が前提になっています。そのため、要件定義では連携要件を漏れなく記述します。
MESとの実績データ連携の方式やタイミング、PLC・センサーのデータ収集インターフェースを、それぞれ整理します。上位のERPや会計システムとの連携項目も確認します。
現行の連携を一つでも見落とすと、移行後に工程が止まります。そのため、アセスメントで棚卸しした構成を要件に反映します。
もう一つ欠かせないのは、データ移行要件です。品目・工程・設備などのマスタと、製造実績・在庫・原価などの取引データについて、RFPに明記します。移行計画では、次の条件を定めます。
- 対象範囲:移行するマスタと取引データの範囲、期間
- 変換ルール:新旧データ項目の対応とコード体系の変換
- データ突合:件数・金額・在庫数の一致確認方法
- 切替計画:移行リハーサルの回数と本番切替方式
データ突合は、移行の品質を担保する最後の確認です。この確認の手順を決めておくことで、移行後の不整合を防ぎます。
RFP作成とベンダー選定の評価基準

要件定義をRFPにまとめたら、ベンダーを選定します。生産管理システムの刷新は、現場を止めずに段階的に進める、難易度の高いプロジェクトです。
ベンダーの実力差が結果を左右します。価格や提案の見栄えだけで選ぶと、移行の難所で立ち往生しかねません。そのため、ベンダーを横並びで比べるには、評価の観点をそろえる必要があります。
ベンダー評価の5つのチェックポイント
生産管理システムの刷新を任せるベンダーは、次の5つの観点で評価します。
- 同業界・同規模の実績:製造業で、自社に近い個別受注・量産などの生産形態を刷新した経験
- 段階移行の設計力:現行を動かしたまま機能単位で置き換えるストラングラーパターンなどの設計・実行力
- 停止時間の見積もり:移行時に生産を止める時間を正確に見積もり、最小化する具体策
- 保守体制:稼働後の障害に備える24時間365日の保守・運用体制
- 品質・セキュリティ認証:ISO9001(品質)やISO/IEC27001(情報セキュリティ)などの第三者認証
チェックリストを使い、各社を同じ基準で採点すると、提案内容を客観的に比べられます。
なかでも見極めたいのは、段階移行の設計力とダウンタイム見積もりの精度です。製造業ではシステム停止が生産停止に直結するため、一括で切り替えるビッグバン移行はリスクが高くなります。
現行を動かしながら機能を少しずつ新システムへ移すストラングラーパターンなどを、自社の工程に合わせて設計できるかどうかで、力量を見極めます。RFPでは、移行方式とダウンタイムを提案項目として求めます。なお、移行手法の詳細な比較は別記事に譲ります。
横並び比較の設計図としてのRFP作成
RFPは、各社を同じ条件で比べるための設計図です。そのために、前段の性能要件やKPI、連携・移行要件を、回答しやすい形に整えます。RFPには、次の情報と回答欄を盛り込みます。
- 要件と現行情報:現行構成図、性能要件と目標KPI、MES・IoT連携、データ移行要件
- 回答形式:提案様式、見積もりの内訳区分、ベンダー評価5項目への回答欄
- 提案への添付:移行方式とダウンタイムの見積もり、保守体制の具体的な内容、保有認証の写し
提案様式や見積もりの内訳区分を指定すると、各社の回答がそろい、横並びで比較しやすくなります。一方で、要件が曖昧だと前提の異なる見積もりが返ってきて、比較が成り立ちません。
RFPは、自社の要求水準を明確にし、各社の提案を客観的に採点する比較表の役割を果たします。作成に時間をかけることは、選定の質を高め、刷新プロジェクト全体の成否を左右します。
まとめ
ここまで、生産管理システム刷新のアセスメント、要件定義、RFP、ベンダー選定を順に見てきました。刷新が失敗する主な原因は、技術そのものではなく、現行仕様がブラックボックス化したまま、要件定義が不十分になることにあります。
アセスメントでは、富士通「ソフトウェア地図」のようなツールで、アプリ資産の複雑度と依存関係を可視化します。工程フローや帳票、設備連携などの棚卸しが、刷新成功の前提となるAS-IS可視化を支えます。
費用面では、業務棚卸しと要件定義だけを外部委託する場合の相場は、200万〜500万円程度です。一方で、この作業を省くと、後工程で何倍ものコストとして跳ね返ります。
要件定義では、夜間バッチ処理時間、同時接続数、実績収集のリアルタイム性を性能要件として定めます。さらに、移行後のKPIにはバッチ短縮率、保守費削減率、品質トレーサビリティ網羅率などを設定し、測定可能にします。加えて、MES・IoT連携要件と、マスタ・取引データの突合を含むデータ移行要件もRFPに明記します。
ベンダー選定では、製造業・生産管理の実績と段階移行の設計力を評価します。ダウンタイム見積もりの精度、24時間365日の保守体制、ISO9001・27001等の認証も確認します。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を創業。
