生産管理システム選定で失敗しない：要件定義の質問リスト50（RFPひな形付き）
なぜ生産管理導入は失敗するのか（最初に押さえる3点）
要件が「機能の羅列」になってしまう
「工程別進捗が見たい」「在庫を見たい」だけでは比較できません。
頻度・粒度・入力者・確認者・遅延時の対応まで具体化して初めて要件になります。
現場運用が決まらないまま、ベンダー比較を始めてしまう
運用が未確定のままでは見積精度が上がらず、導入後に追加費用・追加期間が発生しやすくなります。
業務の回し方を先に固めるほど、導入の確度は高まります。
導入後の「定着」を要件に含めていない
システム導入は出発点であり、定着しなければ効果は出ません。
教育・権限・マスタ管理・保守体制まで含めて検討することで、導入後の停滞リスクを大きく下げられます。
質問リストの使い方
各質問について「現状」「あるべき姿」「優先度（必須／できれば／不要）」「期限」を整理します。まずは社内で前提を揃え、後工程の比較や見積がブレない土台を作ります。
50問すべてを満たす製品は現実的ではありません。まずは必須（Must）を20問程度に絞り、比較軸を固定します。これにより、ベンダー選定が「印象」ではなく「要件」で進むようになります。
入力者・確認者・更新頻度・例外処理など、運用の実態に沿って要件を確定します。可能であれば、実際の運用モデル（成功事例）を確認しながら固めることで、見積精度と導入の確度が大きく高まります。
質問リスト50
A. 目的・範囲
- 導入の最優先目的は何ですか（納期遵守／在庫削減／原価精度／負荷平準化など）
- 最初に対象にする工場・ライン・製品群はどこですか（段階導入の範囲）
- 2年後に達成したいKPIは何ですか（可能な限り数値で定義）
- 業務変更（標準化）とシステム変更（カスタマイズ）の優先順位はどちらですか
- 導入後の運用責任者（業務オーナー）は誰ですか
B. マスタ・品目体系
- 品目コード体系は統一されていますか（枝番・規格・ロット・版の扱い）
- 単位（個／kg／m等）と換算はどう管理しますか
- ロケーション（棚番）管理は必要ですか。必要な場合、粒度はどこまでですか
- BOM（部品表）の版管理・有効期間は必要ですか
- 工程マスタ（工程名・設備・標準工数・段取り）は整備されていますか
C. 受注・出荷
- 受注の入力元は何ですか（手入力／CSV／EDI／外部システム等）
- 納期回答はどのタイミングで、何を根拠に行いますか
- 受注変更（数量・納期・仕様）の履歴管理は必要ですか
- 出荷検品の方法はどうしますか（バーコード／紙／二重チェック等）
- 売上計上のタイミングと締め処理はどうしますか
D. 生産計画・負荷
- 計画の単位は何ですか（製番／ロット／指図、日次・週次など）
- 計画の立案者は誰で、更新頻度はどれくらいですか
- 負荷計画は必要ですか（設備負荷／人員負荷／外注負荷）
- 段取り・兼務・優先順位のルールはありますか
- 計画変更時の現場展開（指示書／端末表示／通知）はどうしますか
E. 工程・進捗
- 実績収集の単位は何ですか（開始/完了、良品数、不良数、工数など）
- 実績入力は誰が、どこで、何を使って入力しますか
- 工程内の仕掛（WIP）をどこまで可視化したいですか
- 遅延の定義（何分/何日で遅延扱いか）とアラート先はどこですか
- リワーク（手直し）や工程戻りはどう記録しますか
F. 在庫・購買・外注
- 発注点管理や所要量計算（MRP）は必要ですか
- 入荷・検収の方法はどうしますか（検品必須／抜取／ロット管理）
- 外注工程の進捗・納期・支給材はどう管理しますか
- 在庫評価（先入先出／移動平均）と棚卸頻度はどうしますか
- 不適合品（隔離在庫）の扱いはどうしますか
G. 品質
- 不良の分類軸は定義されていますか（工程×原因×品目×担当者など）
- 検査成績書や測定データの記録は必要ですか
- トレーサビリティの範囲はどこまで必要ですか（材料ロット→製品ロット等）
- クレーム対応（是正処置・再発防止）の記録は必要ですか
- 品質コスト（不良費用）を把握したいですか。粒度はどこまでですか
H. 原価・工数
- 原価管理の目的は何ですか（見積精度／実績原価／利益管理など）
- 標準原価の構成（材料・加工・外注・間接）の定義はありますか
- 工数は誰のどの時間を集計しますか（直接/間接、準備含む等）
- 見積と実績の差異分析をどの単位で行いますか
- 原価計算の締め（タイミング・確定ルール）はどうしますか
I. 権限・運用・保守
- 権限（閲覧/編集）を部門・役職で分ける必要はありますか
- 監査ログ（誰がいつ何を変えたか）は必要ですか
- マスタ変更の承認フローは必要ですか
- 現場教育（トレーニング・マニュアル・定着支援）は誰が担いますか
- 障害時の連絡・復旧・サポート時間帯の要件は何ですか
J. 連携・データ・移行
- 会計・給与・販売管理など外部システム連携は必要ですか
- データ移行対象（品目・在庫・受注残・指図残）の範囲はどこですか
- CSV入出力の要件（フォーマット・自動化・検証）はありますか
- BI/ダッシュボードは必要ですか。指標は何ですか
- セキュリティ要件（バックアップ、アクセス制御、監査、端末管理等）は何ですか
まずは質問リスト50から、必須（Must）を20項目程度に絞り込み、社内で合意してください。
そのうえで、入力者・確認者・更新頻度・例外処理まで具体化し、ベンダーへ同じ前提で照会すると、見積と提案の比較が一気にしやすくなります。
ベンダー比較のスコアリング方法（失敗しない採点表）
- 必須／できれば／不要の3段階で整理します
-
要件をすべて「重要」にすると評価が破綻します。まずは必須（Must）だけで比較できる状態にし、次に「できれば（Want）」で差を見ます。
- 採点の前に“比較の前提”を揃えます
-
比較対象の範囲（対象工場・製品群・工程）、運用の更新頻度、入力方法（誰がどこで入力するか）を揃えないと、見積・工期・対応可否の比較が正しくできません。
- 機能だけでなく“導入と定着”を評価に入れます
-
教育、権限設計、マスタ管理、運用設計支援など、導入後に回る状態まで支援できるかを評価軸に含めます。ここが弱いと、導入後の停滞が起きやすくなります。
- カスタマイズ方針と費用の出方を明確にします
-
「どこまで標準でできるか」「何をカスタムとするか」「カスタムが増えたときの費用・工期の増え方」を事前に確認し、想定外の追加を防ぎます。
- サポート体制を“運用目線”で比較します
-
問い合わせ手段、対応時間、障害時の一次対応、復旧方針、アップデート運用など、現場が困る場面を想定して比較します。運用が止まらない体制かが重要です。
- スコアは“総合点”より“必須の充足”を優先します
-
総合点が高くても、必須要件が欠けていれば候補から外します。必須の充足を満たした上で、次にWantで差を見ます。
採点ルール（運用例）
本記事では、比較がブレないように、以下のルールでスコアリングします。
- 必須（Must）＝2点／できれば（Want）＝1点／不要＝0点 として採点します。
- 必須（Must）が1つでも「未対応」または「要カスタムで高額」 の場合は、原則として候補から外します（総合点で逆転させません）。
- 「対応」とする条件は、標準機能で実現できること、または 追加費用・追加期間が事前に明確 であることとします。
- 見積の前提が揃わないと比較できないため、採点前に 対象範囲（工場・製品群・工程）／運用（入力者・頻度・例外処理） を統一します。
- 最終判断は、総合点よりも 必須の充足＋導入後の定着（教育・運用設計・サポート） を重視します。
次のアクション（要件を固めて失敗確率を下げる）
ここまで整理できたら、次にやるべきことは「要件を増やすこと」ではなく、「必須を絞り、運用に落とすこと」です。このような手順で進めると、比較の精度と導入の確度が大きく高まります。
要件定義は、テンプレートを埋めること自体が目的ではありません。自社の現場運用に合わせて論点を整理し、導入後に回る形に落とし込むことが重要です。
プロフェクトでは、現状の業務を踏まえたうえで、要件の優先順位付けと運用の具体化を支援しています。検討初期の段階でも構いませんので、ご関心があればお問い合わせください。
※お問い合わせの際は、「要件定義の相談」と添えていただけるとご案内がスムーズです。
この記事が気に入ったら
いいね または フォローしてね！
コメント