生産管理システム更改のアセスメント/要件定義/RFPについて

生産管理システムの更改は、アセスメント、要件定義、RFP作成とベンダー選定の順に進めると、現場を止めずに移行しやすくなります。

更改は、ハードウェアの保守期限切れ(EOL)、基幹サーバーの設備更新、サポート終了などを契機に検討されることがあります。全体像は生産管理システム更改の完全ガイドもご覧ください。

▼全体ガイドの記事
・生産管理システム更改の完全ガイド

アセスメント(現状分析・AS-IS可視化)の進め方

現行システムの資産棚卸しを、インフラ、アプリケーション、データベース、外部連携の四つに分けた図。
対象を分けて並べると、調査の抜けを見つけやすくなります。

生産管理システムは、工程・品質・原価・在庫管理などの基幹業務を支えています。新規開発と比べて、既存の仕組みを止めずに置き換える難しさがあります。

そのため、まずアセスメントで現行システムの実態を把握します。AS-IS(現状)が見えないまま要件定義へ進むと、想定外の連携や移行対象データが判明し、手戻りにつながります。

製造業のシステムは設備や現場端末との接続が複雑で、机上の確認だけでは見落とすことがあります。だからこそ、アセスメントは更改の成否を左右する最重要工程です。

資産棚卸しとブラックボックス化の解消

ブラックボックス化したシステムの全体像をつかむには、現行システムを構成する要素を漏れなく洗い出す必要があります。資産棚卸しでは、インフラ、アプリケーション、データベース、外部連携の四つを対象にします。

  • インフラ:サーバーやネットワーク機器
  • アプリケーション:プログラム本数
  • データベース:テーブル構成
  • 外部連携:他システムとのインターフェース一覧

仕様書がない場合は、稼働中のソースコードやデータベース定義から仕様を逆引きするリバースエンジニアリングが必要です。また、担当者の退職や世代交代で属人化した運用ノウハウは、この段階で文書に残しておきます。

丁寧に棚卸しをすると、更改の対象と移行の難しさを客観的に把握でき、要件定義やRFP作成の精度も高まります。

ソフトウェア地図による複雑度・依存関係の可視化と費用目安

大規模で依存関係が複雑な場合は、富士通の「ソフトウェア地図」が役立ちます。資産の複雑度やプログラム間・データ間の依存関係を図示します(出典:富士通)。

特に、生産管理システムの更改範囲を検討するときは、資産の依存関係と複雑度が判断材料になります。

  • 移行単位の判断:機能間の結びつきから、切り出して移行する単位を検討
  • 可視化による課題の定量化:複雑なモジュール、重複処理、未利用機能を数値で示し、合意形成や予算化に活用

要件定義や業務棚卸しだけを外部に委託する費用は、200万〜500万円程度が一つの相場です。

更改本体より小さな投資ですが、上流の確認を省くと、後工程で追加コストが生じることがあります。そこで、アセスメントへの予算配分は、後工程のコストを抑える投資として戦略的に検討します。

ポイント

要件定義へ進む前に、現行システムの構成要素と外部連携、依存関係を洗い出せているかが目安です。洗い出しが不十分だと、移行対象や連携の抜けが後から見つかり、手戻りの原因になります。

要件定義で押さえるべきポイント

製造業システムの非機能要件として、生産実績登録やバッチ処理、障害時の復旧目標時間、ネットワーク境界対策、生産品目や拠点の拡大を示すチェックリスト。
四つの観点を具体化すると、ベンダー評価や受け入れ基準につながります。

現状を把握した後は、要件定義に進みます。更改では、新規開発のように要件をゼロから考えるのではなく、現行機能を「残すもの」「捨てるもの」「新たに加えるもの」に仕分けます。

製造業には現場運用や法令対応、設備連携など固有の要件があるため、汎用的な業務システムとは異なる観点で整理します。

機能要件と非機能要件の整理

機能要件では、工程・品質・原価・在庫管理で何ができる必要があるかを決めます。そのために、現行の帳票やマスタ、計算ロジックを棚卸しして、必要な機能を選びます。

使われていない機能まで移植すると、複雑さもそのまま引き継いでしまいます。そこで、業務部門を交えて要件を精査します。

非機能要件はシステムの品質を左右するもので、製造業では特に重視されます。工場の操業を支えるため、次の4つの観点で具体化します。

  • 性能:ピーク時も生産実績登録やバッチ処理を要求時間内に完了
  • 可用性:工場操業中の停止を避け、障害時の復旧目標時間(RTO)を設定
  • セキュリティ:工場網と情報システム網の境界対策やアクセス権限を管理
  • 拡張性:将来の生産品目追加や拠点拡大に耐える構成

非機能要件は数値で定義します。たとえば、「速いこと」ではなく「実績登録のレスポンスを3秒以内」とします。

また、「止まらないこと」は「稼働率99.9%以上」と具体化します。数値にすると、ベンダー評価や受け入れ基準が明確になります。

製造業特有の連携・現場運用要件と移行範囲・KPI設定

現場(製造ライン)の運用要件は、要件定義に含めておく必要があります。現場作業や設備連携を把握したうえで、移行後の運用や成果まで見据え、現場運用、システム連携、データ移行、成果指標の四つを要件として定めます。

  • 現場運用:ハンディターミナルや現場端末での実績入力、バーコードやICタグでの進捗記録
  • システム連携:MES(製造実行システム)、PLC(プログラマブルロジックコントローラー)、IoTセンサー、ERP・会計・販売管理との接続を定義
  • データ移行:要件定義でロット・原価・在庫の移行先と旧システムでの参照範囲を決定
  • 成果指標:処理時間短縮、保守費削減、照会時間などのKPIを設定

トレーサビリティを担保するには、ロット管理も欠かせません。

机上の検討だけでは要件が漏れやすいため、製造ラインを観察し、現場担当者への聞き取り内容を要件に反映します。

連携仕様やデータ更新のタイミングがずれていると、生産現場の停止につながるおそれがあります。そのため、設備連携ではリアルタイム性と通信の信頼性も定めます。

ロット情報や原価、在庫は、長期にわたって参照される資産です。また、KPIを設定すると、更改の目的が関係者で共有され、プロジェクトの方向がぶれにくくなります。

ポイント

要件定義では、現行機能を残す・捨てる・加える仕分けと、非機能要件の数値化ができているかが判断の目安です。製造業特有の連携や現場運用も含めて決めておくと、提案の条件がそろいます。

RFPの作成項目とベンダー選定の評価観点

RFPに含める現行構成図と機能要件、非機能要件の数値目標、移行後のKPIと方式、製造業特有の連携とデータ移行範囲を四つのパネルで示す図。
情報のまとまりごとに整理すると、各社へ同じ提案条件を渡せます。

要件定義で固めた内容は、RFP(提案依頼書)にまとめてベンダーへ提示します。RFPは、複数社から同じ条件で提案を受け、客観的に比較・評価するための文書です。

更改では、現行システムの制約や移行の難しさが提案を左右します。そのため、現状を正確に伝えることが、ベンダー選定の質につながります。

RFPに含めるべき項目一覧

ベンダーが移行の難しさを見積もり、提案の条件をそろえられるよう、RFPには次の情報を記載します。

  • 現行構成図・機能要件:サーバー、ネットワーク、外部接続と工程・品質・原価・在庫の業務機能
  • 非機能要件:性能、可用性、セキュリティの数値目標
  • 移行後のKPI・移行方式:処理時間短縮や保守費削減の目標、段階移行などの進め方
  • 製造業特有の連携・データ移行範囲:MES・PLC・IoT、ERP等との接続仕様とロット・原価・在庫の対象データ

移行方式は慎重に選ぶ必要があります。全機能を一度に切り替えるビッグバン方式は、障害時の影響範囲が大きく、工場の操業が止まるリスクがあります。

一方で、ストラングラーパターンは機能単位で新旧を並行稼働させ、段階的に置き換えます。リスクを分散できる現実的な選択肢です。

また、RFPに想定方式を示すと、ベンダーから具体的な移行設計を引き出せます。

ベンダー評価の5つのチェックポイントと製造業での着眼点

RFPへの提案は、客観的な基準で評価します。選定では、次の5点を確認します。

  1. 同業界・同規模の実績:近い業種・規模の更改経験
  2. 段階移行の設計力:ストラングラーパターンなどの具体的な設計力
  3. ダウンタイム見積り:移行停止時間を現実的に算出できるか
  4. 24時間365日の保守体制:操業時間に合わせた障害対応や問い合わせ対応
  5. 品質・セキュリティ認証:ISO9001やISO/IEC27001などの保有状況

工場が止まると生産停止や出荷遅延、機会損失につながるため、製造業では特にダウンタイムの見積りを重視します。

停止時間の最小化と切り戻し(ロールバック)手順の具体性は、ベンダーの実力を測る重要な指標です。さらに、過去の実停止時間や切り戻しの判断基準も確認します。

同業界・同規模の実績では、設備連携や法令対応など、自社固有の課題に対応した経験を確かめます。

評価観点を点数化して複数社を同じ基準で比べると、印象に左右されにくい選定につながります。

ポイント

RFPに移行方式や連携・データ移行の範囲を書き込めているかが、判断の目安になります。ベンダー選定では、ダウンタイムの見積りを重視すると、工場の停止リスクを見極められます。

まとめ

更改の上流工程では、アセスメント、要件定義、RFP作成とベンダー選定を、この順に進めます。

アセスメントでは、資産を棚卸しして、ブラックボックス化を解消します。また、ソフトウェア地図などで複雑度や依存関係を図にすると、現状を把握できます。

機能要件と数値化した非機能要件を整理し、現場運用や設備連携も定義します。さらに、ロット・原価・在庫の移行範囲とKPIも決めます。

RFPには現行構成図から移行方式までを盛り込みます。ベンダーは、同業界の実績、段階移行の設計力、ダウンタイム見積り、24時間365日の保守体制、品質・セキュリティ認証の5観点で評価します。

生産管理システムの更改では、現状を把握し、稼働を止めずに置き換えることが欠かせません。上流の文書と評価軸を整えておくと、後工程の手戻りやプロジェクトの混乱を防ぎやすくなります。

製造業では、ダウンタイムの最小化と設備・法令対応への配慮が成否を分けます。上流工程を着実に進めることが、生産現場に合う次世代システムへの移行につながります。

会社紹介

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

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

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

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

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

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