生産管理システム刷新は、現状分析（アセスメント）、要件定義、RFPと評価の順に進めると、移行漏れや想定外の追加開発を防げます。
刷新全体ではなく、アセスメントからRFPまでの範囲に焦点を絞ります。全体像は生産管理システム刷新の完全ガイドもご覧ください。
▼全体ガイドの記事
・生産管理システム刷新の完全ガイド
レガシーシステム刷新の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
現状アセスメント（AS-IS分析）の進め方
刷新の出発点は、現行システムの状態（AS-IS）を正確に把握するアセスメントです。仕様書がないレガシー環境では、機能・データ・連携を可視化すること自体が大きな関門になります。ここを省くと、要件定義以降の全工程が土台を欠いた砂上の楼閣になります。
資産棚卸しとソフトウェア地図による複雑度の可視化
刷新の範囲と影響を見積もるには、どの資産がどの業務に結びついているかを、資産ごとに洗い出す必要があります。
- 構成資産：プログラム、データベース、連携の一覧と、業務との対応関係
- 利用状況：使われている処理と、使われていない機能の切り分け
- 依存関係：資産どうしのつながりと、複雑度の見える化
複雑度の可視化には、専用ツールの活用が有効です。富士通の「ソフトウェア地図」は、アプリケーション資産の複雑度や依存関係を示します（出典：富士通）。ツールを使うと、属人的な調査に頼らず、構造を客観的に把握できます。
生産管理では、工程・品質・原価が複雑に絡み合っています。そのため、機能に手を入れるときは、他の機能やデータへの波及を把握しておく必要があります。
把握していないと、移行時に想定外の不具合を招きます。たとえば受注の変更は、所要量計算、工程指示、原価計算へと連鎖します。関係を地図にしておくと、影響範囲を見積もりやすくなり、後工程のリスクも抑えられます。
資産棚卸しと複雑度の可視化にも、相応の費用と工数がかかります。要件定義・業務棚卸しのみを切り出す場合、費用相場はおおむね200万〜500万円です。
この段階の投資を惜しむと、後工程で手戻りが起き、総コストが膨らむ可能性があります。アセスメントは、刷新全体のリスクを下げる先行投資です。
業務プロセスとデータフローの整理
現場の実態と刷新後の移行を見通すため、業務とデータを次の観点で整理します。
- 業務フロー：受注から所要量計算、製造指示、工程実績、品質検査、原価集計までの流れ
- 現場運用：手作業やExcelでの補完の洗い出しと、システムと実業務の照合
- ユーザー部門：現場の運用ルールと例外処理の確認
- 移行データ：マスタの整合性、過去データの保持範囲、変換ルールの確認
- 成果物：構成図、業務・データフロー図、機能一覧、課題リスト
仕様書からは、現場の運用ルールや例外処理が見えにくく、それが要件定義の精度に影響します。さらに、ユーザー部門の参画不足は、刷新が失敗する要因にもなります。
これらをアセスメント段階で見通しておくと、後のデータ移行トラブルを未然に防げます。また、AS-IS分析は、TO-BE（あるべき姿）を描くための土台です。
成果物は、ベンダーに現状を伝える共通言語になります。後工程の要件定義やRFP作成にも、そのまま活用できる形で整理しておきます。加えて、調査で終わらせず、プロジェクト全体で再利用できる資産として残すと、上流工程の投資を最大限に活かせます。
要件定義で押さえるべき観点とKPI設定
現状を把握できたら、次に刷新後のあるべき姿を定める要件定義に進みます。発注側と開発会社は、機能要件に加えて性能と移行後のKPIも明確にします。成功の判断基準を決めておかないと、完成後に成果を評価できません。
機能要件・性能要件・移行後KPIの明確化
要件とKPIは、現状を基準にして刷新後の状態を評価できる形にしておきます。
- 機能要件：維持、改善、廃止の対象とする機能の決定
- 性能要件：処理時間、同時アクセス数、応答時間の目標値
生産管理では、受注から原価までの各機能を現場の運用に合わせて定めます。そのうえで、不要な機能は廃止の対象とし、刷新後のシステムをシンプルに保ちます。
レガシー刷新では、性能要件が特に重要です。夜間バッチの処理時間、同時アクセス数、応答時間を数値で定めます。
数値を明記すると、ベンダーへの期待値が明確になります。たとえば、現行で8時間かかる処理を、どこまで短縮するかを目標値にします。
移行後のKPIには、処理時間の短縮率、保守費の削減額、業務時間の削減量などを含めます。KPIを要件定義に盛り込めば、刷新を機能の置き換えで終わらせず、経営的な効果を伴う設計につなげられます。また、KPIは稟議で投資対効果を示す根拠にもなります。
KPIを設定するには、まず現状値（ベースライン）を測っておく必要があります。現行のバッチ時間や年間保守費が分からなければ、刷新後との比較ができません。
アセスメント段階で測った値を要件定義のKPIの起点にすると、刷新の効果を客観的に評価できます。なお、改善目標は現状値からの相対差で定めます。
データ移行と段階移行の要件
移行要件では、対象データと移行方式を具体化しておきます。
- 対象データ：移行範囲とデータ変換ルールの決定
- 移行方式：新旧並行の段階移行か、一括切り替えかの選択
- 停止時間：移行時に許容できるダウンタイムの定義
マスタや過去実績は膨大になりやすく、データマッピングも複雑になりがちです。こうした状況で要件化が曖昧なままだと、移行トラブルの原因になります。
生産管理は現場を止められないため、機能単位の段階移行を要件に明記しておくと、業務停止のリスクを抑えられます。出荷停止などを避けるには、稼働への影響も要件に含める必要があります。
現行機能をそのまま再現する「現行踏襲」に偏ると、開発費が膨らみ、将来の保守も難しくなります。一方で、パッケージやSaaSの標準機能に業務を合わせられるかも、要件定義で見極めます。自社固有の要件だけをカスタマイズの対象にする取捨選択が、再びレガシー化する事態を防げます。
RFPに盛り込む項目とベンダー評価の基準
要件定義が固まったら、発注側はRFP（提案依頼書）にまとめ、ベンダーに提案を依頼します。RFPの精度は提案の質を左右します。依頼が曖昧だと、提案も曖昧になり、後の認識のずれにつながります。
RFPに必須の項目
各社が同じ前提で提案できるよう、RFPには最低限次の項目を盛り込みます。
- 現状と目的：現行構成図、刷新の目的、達成したいKPI
- 要件：機能・性能要件、データ移行の方針と範囲
- 移行と運用：段階移行、並行稼働、許容ダウンタイム、保守体制
- 予算と日程：予算規模と希望スケジュール
現行構成図がないと、ベンダーは複雑さを把握できず、正確な見積りを出せません。また、KPIが曖昧だと、成果の責任範囲も不明確になります。
アセスメントの情報をRFPに反映すると、精度の高い提案や見積りを得やすくなります。さらに、発注側も各社の提案を公平に比べられます。
生産管理では、24時間稼働の現場も多く、障害時の復旧体制やサポートの時間帯が運用品質を左右します。こうした条件を初回のRFPで明示しておくと、後の食い違いを減らせます。
ベンダー評価の5つのチェックポイント
実務でよく用いられるベンダー評価のチェックポイントは、次の5つに整理できます。
- 同業界・同規模の実績：近い刷新経験の有無
- 段階移行の設計力：機能単位で移行を組み立てる力
- 停止時間の見積もり：現実的な移行時間の提示
- 保守体制：24時間365日の対応体制
- 認証：ISO9001（品質）、ISO27001（情報セキュリティ）などの保有
同業界・同規模の実績と段階移行の設計力は、生産管理の刷新で重視すべき観点です。加えて、製造業の工程・品質・原価や、現場を止められない制約への理解も欠かせません。
実績の中身を確かめ、自社に近い課題をどう解決したかを尋ねると、提案の実効性を見極めやすくなります。また、評価基準をスコアリングシートにまとめ、定量と定性の両面で採点すると、評価が担当者によって偏るのを抑えられます。
価格だけで選び、ベンダーに任せきりにすると、刷新が炎上する事例もあります。特に、RFPの精度と評価の客観性は、上流工程で刷新の成否を左右します。
提案書だけでなく、提案の過程での対話も判断材料になります。現状や課題を深く掘り下げる姿勢は、要件を理解しようとしている表れです。
製品やパッケージありきの提案は、刷新後のミスマッチにつながる傾向があります。また、回答の丁寧さや質問の鋭さも、評価軸に加えます。
まとめ
現状アセスメント、機能・性能・移行後KPIの要件定義、RFPの記載項目と5つのベンダー評価観点を取り上げました。資産棚卸しと複雑度の可視化から、データと段階移行の要件、現行構成図とKPIを示すRFPまで、上流工程の要点を一続きで見てきました。
刷新の成否は、技術選定より前のアセスメントと要件定義の精度で決まります。上流工程を丁寧に進めると、移行漏れや想定外の追加開発を防ぎ、刷新成功の土台になります。要件定義・業務棚卸しの200万〜500万円は、後工程のリスク低減につながる投資です。
▼開発を相談する前に読みたい無料ホワイトペーパー
・レガシーシステム刷新の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。