生産管理システムのモダナイゼーションのアセスメント/要件定義/RFPについて

長年使い続けてきた生産管理システムの刷新を検討する際、最初に直面する難関がアセスメント（現状分析）と要件定義、そしてRFP（提案依頼書）の作成です。製造現場のMESや工程管理、品質管理、在庫管理、原価管理、IoT連携といった機能が複雑に絡み合った既存システムは、長い年月のなかで度重なる改修を経て、現行の仕様を正確に把握している人がいない「ブラックボックス」と化していることが少なくありません。この状態のまま刷新プロジェクトを進めると、要件定義が不十分なまま発注に至り、移行後に「現行でできていた処理ができなくなった」「夜間バッチが終わらない」といった深刻なトラブルを招きます。刷新の失敗原因の多くは、技術の問題ではなく、現状分析と要件定義の精度不足にあります。

本記事では、生産管理システムのモダナイゼーションにおけるアセスメント、要件定義、RFP、ベンダー選定という一連の流れに絞り、刷新を成功に導くための実務的な勘所を解説します。AS-IS可視化のための資産棚卸し、RFPに織り込むべき性能要件や移行要件、そしてベンダーを横並びで比較するための評価基準まで、発注実務に落とし込んだ視点で掘り下げます。刷新全体の進め方や手法の体系から把握したい方は、あわせて生産管理システムのモダナイゼーションの完全ガイドもご覧ください。本記事は、その完全ガイドの内容を要件定義とRFPの実務に焦点を絞って深掘りする位置づけです。

▼全体ガイドの記事
・生産管理システムのモダナイゼーションの完全ガイド

アセスメントと現状分析によるAS-IS可視化

生産管理システムの刷新で最も軽視されがちでありながら、最も重要なのがアセスメント、すなわち現状分析の工程です。経済産業省が指摘する「2025年の崖」では、レガシーシステムを放置した場合、2025年以降に年間最大12兆円の経済損失が生じるリスクが示されています。JUAS（日本情報システム・ユーザー協会）の調査でも、約7割の企業が基幹システムのレガシー化を経営課題として認識しています。こうした背景のなか、刷新を成功させる前提として、現行システムの全体像を正確に把握するAS-IS可視化が欠かせません。

刷新が失敗する大きな原因は、現行の仕様書が存在しない、あるいは更新されておらず、システムがブラックボックス化していることにあります。仕様が不明なまま要件定義を進めれば、当然ながらその要件は不十分なものになります。まず取り組むべきは、アプリケーション資産そのものの棚卸しです。プログラム本数、モジュール間の依存関係、改修の集中している箇所、すでに使われていないデッドコードなどを洗い出し、システムの複雑度を客観的に把握します。

この資産可視化を支援するツールとして、富士通の「ソフトウェア地図」のような可視化ソリューションが活用されています。アプリケーション資産の複雑度や依存関係を地図のように描き出すことで、どの部分が刷新の難所になるのか、どこから手を着けるべきかを判断できます。担当者の経験や記憶に頼った現状把握には限界があるため、こうしたツールで定量的に複雑度を捉えることが、要件定義の精度を底上げします。可視化の結果は、後段のRFPでベンダーに現行構成を正確に伝える材料にもなります。

生産管理システムのアセスメントでは、アプリ資産の可視化に加えて、製造業固有の業務と運用の棚卸しが不可欠です。生産管理は、工程の流れや設備との連携、現場の手作業が密接に絡むため、システムの中だけを見ても全体像はつかめません。現行の業務がどのように回っているかを、現場へのヒアリングと帳票・記録の確認を通じて丁寧に洗い出す必要があります。

具体的には、次のような項目を棚卸しの対象とします。
・現行の工程フロー（受注から出荷までの工程順序と分岐）
・現場で使われている帳票や指示書、ラベルの種類と様式
・設備やPLC、IoTセンサーとのデータ連携の構成と方式
・システム外で運用されているExcelや紙の台帳、手作業の補完処理
・各種マスタやトランザクションのデータ項目と桁数、コード体系

とくに見落としやすいのが、システムに収まりきらずExcelや紙で運用されている「裏の業務」です。これらは現行システムの仕様書には載っていないため、現場ヒアリングでしか把握できません。こうした運用まで含めて棚卸しすることが、移行後の「現場が回らない」という事態を防ぎます。

なお、こうした業務棚卸しと要件定義のみを外部に依頼する場合の費用相場は、200万〜500万円程度が目安とされています。刷新本体の開発費に比べれば小さな投資ですが、ここを省くと後工程で何倍ものコストとして跳ね返ります。アセスメントは、刷新全体のリスクを下げるための先行投資と位置づけることが重要です。

要件定義でTO-BEと移行要件を具体化する

アセスメントで現状を可視化したら、次はTO-BE（あるべき姿）と移行要件を要件定義書に落とし込みます。ここで定義した内容が、そのままRFPの中核となります。生産管理システムは、性能や連携、データ移行といった非機能の要件が成否を左右するため、機能要件だけでなく、これらを測定可能な形で具体化することが求められます。曖昧な要件は、ベンダーごとに解釈がばらつき、見積もりの比較を成立させなくなります。

生産管理システムの刷新で特に重視すべきが性能要件です。現行の処理性能を満たせなければ、刷新は失敗とみなされます。RFPには、現行構成図とともに、次のような性能要件を具体的な数値で記載します。
・夜間バッチ処理の完了時間（例：原価計算バッチを翌朝6時までに完了）
・同時接続ユーザー数とピーク時のレスポンス目標
・製造実績の収集におけるリアルタイム性の要求水準
・月末や繁忙期のデータ量を想定したスループット

これらを数値で示すことで、ベンダーは前提を揃えて設計と見積もりを行えます。とくに夜間バッチは、現行で何時間かかっているかを実測し、刷新後の目標値とあわせて明記することが重要です。

あわせて、刷新によって何を達成するのかを示す移行後のKPIも定義します。KPIが明確であれば、刷新の効果を客観的に評価でき、ベンダーにも目指すゴールが伝わります。代表的なKPIとしては、夜間バッチの処理時間短縮率、保守費の削減率、品質トレーサビリティの網羅率などが挙げられます。たとえば「バッチ処理時間を現行比で40%短縮する」「ロット単位の品質追跡を全工程で100%カバーする」といった形で、測定可能な目標として記述します。こうしたKPIは、要件定義の優先順位を判断する軸にもなります。

生産管理システムは単独で完結するものではなく、MESや設備、IoTとの連携が前提となります。要件定義では、これらの連携要件を漏れなく記述する必要があります。具体的には、MESとの実績データ連携の方式やタイミング、PLCやセンサーからのデータ収集のインターフェース、上位のERPや会計システムとの連携項目などを整理します。現行で稼働している連携を一つでも見落とすと、移行後に工程が止まるため、アセスメントで棚卸しした連携構成をそのまま要件に反映します。

もう一つの重要な柱がデータ移行要件です。生産管理システムには、品目マスタや工程マスタ、設備マスタといったマスタデータと、製造実績や在庫、原価といった膨大なトランザクションデータが蓄積されています。これらを新システムへ正確に移行するための要件を、RFPに明記します。
・移行対象とするマスタとトランザクションの範囲と期間
・新旧データ項目のマッピングとコード体系の変換ルール
・移行後のデータ突合（件数・金額・在庫数の一致確認）の方法
・移行リハーサルの回数と本番移行の切替方式

とくにデータの突合は、移行の品質を担保する最後の砦です。マスタとトランザクションの双方で、件数や数量、金額が現行と一致することを確認する手順を要件として定めておくことで、移行後のデータ不整合を未然に防げます。

RFP作成とベンダー選定の評価基準

要件定義の内容を整理してRFPにまとめたら、いよいよベンダー選定です。生産管理システムのモダナイゼーションは、現場を止めずに段階的に進める難易度の高いプロジェクトであり、ベンダーの実力差が結果を大きく左右します。価格や提案の見栄えだけで選ぶと、移行の難所で立ち往生しかねません。ここでは、ベンダーを横並びで比較するための評価の観点を整理します。

生産管理システムの刷新を任せるベンダーは、次の5つの観点で評価することをお勧めします。
(1)同業界・同規模の実績：製造業、とくに自社と近い生産形態（個別受注・量産など）の生産管理システムを刷新した実績があるか
(2)段階移行の設計力：現行を稼働させたまま機能単位で順次置き換えるストラングラーパターンのような段階移行を設計・実行できるか
(3)ダウンタイム見積りの精度：移行時に生産を止める時間をどれだけ正確に見積もり、最小化する具体策を示せるか
(4)保守体制：稼働後の障害に備えた24時間365日の保守・運用体制を備えているか
(5)品質・セキュリティ認証：ISO9001（品質）やISO/IEC27001（情報セキュリティ）などの第三者認証を取得しているか

これらをチェックリスト化し、各社を同じ基準で採点することで、提案内容を客観的に比較できます。

とくに重要なのが、(2)の段階移行の設計力と(3)のダウンタイム見積りの精度です。製造業では、システム停止が生産停止に直結するため、一括での切替（ビッグバン移行）はリスクが高くなります。現行を動かしながら機能を少しずつ新システムへ移していくストラングラーパターンのような段階移行を、自社の工程に合わせて設計できるかどうかが、ベンダーの力量を見極める鍵となります。なお、こうした移行手法そのものの詳細な比較は別記事に譲りますが、RFPでは「どの方式で、どれだけのダウンタイムで移行するか」を提案項目として必ず求めることが重要です。

RFPは、単にベンダーへ要望を伝える書類ではなく、各社を同じ土俵で比較するための設計図です。前段で定義した性能要件やKPI、連携要件、データ移行要件を、ベンダーが回答しやすい形で構造化して記載することが重要です。提案の様式や見積もりの内訳区分を指定しておけば、各社の回答がそろい、横並びの比較が容易になります。逆に、要件が曖昧なRFPでは、ベンダーごとに前提が異なる見積もりが返ってきて、比較が成立しません。

具体的には、RFPに現行構成図、求める性能要件と目標KPI、MES・IoT連携要件、データ移行要件、そして前述のベンダー評価5項目への回答欄を盛り込みます。あわせて、提案には移行方式とダウンタイムの見積り、保守体制の具体的な内容、保有する認証の写しを添付してもらうよう求めます。こうした作り込みによって、RFPは自社の要求水準を可視化し、各社の提案を客観的に採点できる比較表へと機能します。RFP作成に時間をかけることが、結果的にベンダー選定の質を高め、刷新プロジェクト全体の成否を左右します。

まとめ

本記事では、生産管理システムのモダナイゼーションにおけるアセスメント、要件定義、RFP、ベンダー選定について解説しました。刷新失敗の主因は技術ではなく、現行仕様のブラックボックス化による要件定義の不十分さにあります。富士通「ソフトウェア地図」のようなツールでアプリ資産の複雑度と依存関係を可視化し、生産管理固有の工程フローや帳票、設備・PLC連携、Excel・紙運用、データ項目を棚卸しするAS-IS可視化が、刷新成功の前提です。業務棚卸しと要件定義のみでも200万〜500万円が相場ですが、ここを省けば後工程で何倍ものコストとして跳ね返ります。

要件定義では、夜間バッチ処理時間や同時接続、実績収集のリアルタイム性といった性能要件と、バッチ短縮率や保守費削減、品質トレーサビリティ網羅率などの移行後KPIを測定可能な形で定義します。あわせてMES・IoT連携要件と、マスタ・トランザクションの突合を含むデータ移行要件をRFPに明記することが重要です。ベンダー選定では、(1)製造業・生産管理の実績、(2)段階移行の設計力、(3)ダウンタイム見積りの精度、(4)24時間365日の保守体制、(5)ISO9001・27001等の認証、という5つの観点で各社を横並びに評価します。RFPを比較の設計図として作り込むことが、納得のいくベンダー選定と生産管理システム刷新の成功につながります。

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

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

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

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

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

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。