工程管理システムの要件定義と発注は、現状把握、あるべき姿の設計、要件整理、RFP作成の順に進めると、導入後のミスマッチを減らせます。
AsIs/ToBeの整理から、発注側がRFP・要件定義書を自ら作る方法まで、順にたどります。全体像は工程管理システムの完全ガイドもご覧ください。
▼全体ガイドの記事
・工程管理システムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
AsIsの工程フローを可視化する要件定義の第一歩
要件定義は、自社の現状（AsIs）の工程フローを正確に可視化するところから始めます。多くの製造現場では、生産計画から実績集計までが属人化しており、正確な業務手順をベテランだけが把握している状態も珍しくありません。そのため、誰が、どの順番で、何を使って工程を回すかを図に描き、暗黙知を表に出すことが要件定義の土台になります。
現場ヒアリングによるAsIsの工程フローの作成
生産計画から実績集計までの実際の流れと現場の課題をつかむため、関係者への聞き取りでは次の点を確認します。
- 計画：実際の生産計画の立て方
- 進捗記録：現場での進み具合の記録方法
- 無駄や手戻り：二重入力などが発生している箇所
- 関係者：生産管理、計画、作業者、品質、出荷の各担当者
マニュアル上の手順だけでなく、現場が実際に行う「裏の手順」も拾い上げます。こうした可視化によって、現状の課題も浮かび上がってきます。
日報のExcel転記にかかる工数や、進捗確認で現場を歩く時間も把握できます。また、複数版のExcelによる混乱も見えるので、どこを直せば効果が大きいかが分かります。
要件定義の質はAsIsの解像度に比例するといえるほど、この可視化が欠かせません。
ToBeモデルによる「あるべき工程の姿」の設計
AsIsを可視化したら、次に導入後のToBeモデルを描きます。ToBeでは、計画から実績までの流れのほか、なくす手作業とリアルタイムで共有する情報を決めます。
- 業務の改善：無駄な工程を削って、業務そのものを改善する
- 実現したいこと：ベンダーに伝えられる具体的なToBe像
現状の業務をそのままデジタル化すると、非効率な工程も残りやすくなります。また、ToBeが曖昧なままでは、ベンダーに希望が伝わらず、提案の質にも影響します。
AsIsの可視化とToBeの設計は、どちらも要件定義で欠かせない作業です。そのため、ここに時間をかけることが、導入成功への近道になります。
ISA-95の役割分担と生産形態別の要件整理
要件定義では、工程管理システムが情報システム全体のなかで担う役割を明確にしておきます。その際、製造業の階層モデルであるISA-95が参考になります。
ISA-95では、生産計画の上位層（ERP）と現場の実行層（MES・工程管理）が役割を分担します。この境界を先に決めておけば、後から起きる連携トラブルを減らせます。
ERPと工程管理の役割分担の要件化
ERPや基幹システムがある企業では、どこまでをERPで担うかを先に決める必要があります。役割分担は、ERPと工程管理それぞれが担う範囲を明確にすることです。
- ERP：生産計画の大枠を立てる
- 工程管理：現場の詳細なスケジューリングと実績収集を担う
境界が曖昧だと、同じ機能を両方のシステムに作ってしまい、費用や運用が無駄になるおそれがあります。そこで、連携するデータの種類、受け渡すタイミング、方向も要件として定めます。
連携要件が曖昧なままだと、開発の後半になってデータの保有先が問題になり、手戻りにつながります。ISA-95を下敷きに責任範囲を分けることが、要件定義の中心です。
生産形態（受注/見込/個別）別の要件整理
工程管理システムに求められる要件は、生産形態によって変わります。そのため、生産形態ごとに要件を分けて整理します。
- 見込生産：定型的な工程を効率よく回す
- 受注生産・個別受注生産：案件ごとに工程を柔軟に組み替える
- 個別の部品表・工程表：Excelで作った表を取り込む
受注生産や個別受注生産では、工程が案件ごとに変わるため、柔軟な組み替えや表の取り込みが必須要件になります。要件定義書には、主たる生産形態と、その形態で必須となる要件を書いておきます。
見込生産向けパッケージを受注生産の工場に導入するといったミスマッチは、生産形態を明確にしておけば防げます。この整理が、製品選定とRFP作成の前提です。
機能要件・非機能要件とデータ移行の要件化
要件は、システムの機能を定める「機能要件」と、性能やセキュリティなど品質を定める「非機能要件」に分けて考えます。機能要件ばかりを固めると、稼働後に動作の遅さや同時アクセスの問題が表面化します。
両方をバランスよく定めてはじめて、システムを長く使い続けられます。
機能要件の必須・優先・将来による分類
機能要件を必須・優先・将来の三段階に分けておくと、予算が足りない場面でも、外せない機能から順に残せます。
- 必須機能：絶対に外せない機能
- 優先機能：あると望ましい機能
- 将来機能：将来的に欲しい機能
まず必須機能を確実に満たし、予算に余裕があれば優先機能を加えます。
中小の工程管理システムでは、初期費用800万〜1,500万円のうち、カスタマイズ費が200〜300万円になることがあります。これは全体の3〜4割にあたり、その多くは「あれば便利」な機能のカスタマイズです。
機能要件の優先度を分けておけば、必要な機能に予算を集中させられます。この優先度付けは、カスタマイズ費の膨張を抑えるのにも役立ちます。
非機能要件とExcel連携・データ移行の要件
製造現場で安定して使える仕様にするため、性能や稼働、安全性に関わる条件を具体的に決めます。
- 性能：画面の応答速度、同時利用人数
- 稼働・保護：稼働時間、バックアップ
- セキュリティ：必要な安全性の要件
製造現場では、多くの作業者がピーク時に同時入力しても速度が落ちないことが求められます。そのため、実際のデータ量と利用人数を前提に、性能を数値で定めておきます。
Excel連携とデータ移行も、要件として決めておきます。具体的には、既存のExcel部品表や過去の生産実績をどこまで引き継ぐかと、CSV変換なしでExcelを直接取り込めるかを定めます。
要件が定まっていないと、移行時に文字化けや列ずれが起こることがあります。逆に移行対象、形式、範囲を決めておけば、隠れたコストによる費用の膨らみを防ぎやすくなります。
RFPに盛り込む項目と見積りの妥当性判断
固めた要件は、ベンダーに伝えるRFP（提案依頼書）にまとめます。質の高いRFPは、比較できる提案や精度の高い見積りにつながります。
RFPが曖昧だと、各社が見積りの前提を別々に置くため、比べられなくなります。
RFPに必ず盛り込むべき項目
各社の提案や見積りを同じ条件で比べられるよう、RFPには必要な項目を最低限盛り込みます。
- 背景・目的：プロジェクトの背景と解決したい課題
- 業務情報：生産形態と業務概要、AsIs/ToBeの工程フロー
- システム要件：必須・優先・将来の機能、非機能要件
- 連携・移行：Excel、データ移行、既存システムとの連携要件
- 選定条件：想定スケジュール、予算感、評価基準
「解決したい課題」とToBeを明記すれば、ベンダーは機能の見積りにとどまらず、課題解決策を提案しやすくなります。さらに、自社で巻き取れる作業もRFPに明示しておくと有効です。
たとえば、マスター登録と現場教育を内製する前提にすれば、その分を見積りから除けます。テスト運用と帳票レイアウトの調整まで内製すると、導入費を3割ほど圧縮できる場合があります。
コンサル委託費は1人月100〜200万円が相場で、半年から1年の委託では数百万円になります。そのため、どの作業を自社で担うかを示すことが、コスト管理につながります。
見積りの妥当性を判断する基準
集まった見積りの妥当性を判断するには、費用相場を把握しておくことが欠かせません。
- システム全体：初期費用800万〜1,500万円
- カスタマイズ：200〜300万円
- 従業員10〜30名：初期100〜300万円、5年TCO 400〜900万円
- 従業員50〜100名：初期400〜1,000万円、5年TCO 1,600〜3,400万円
相場から大きく外れる見積りは、要件の認識違いや過剰・過少な提案を疑うきっかけになります。初期費用だけでなく、運用保守費を含む長期のTCO（総保有コスト）で比べます。
クラウド型では、数年後のバージョンアップで数百万円が請求される失敗もあります。そのため、5年・10年の総額で各社を並べて評価します。
内訳は、ライセンスと導入支援が分かれているかを確かめます。さらに、カスタマイズ、ハードウェア、保守も別々に示されているかを見ます。一式だけの見積りは避けるべきです。
判断基準があれば、安さだけに引かれず、費用対効果の高い提案を選べます。
体制・スケジュールと補助金申請の要件化
機能要件・非機能要件に加えて、推進体制、スケジュール、補助金の申請要件も決めておきます。これらは導入の進み方と実質負担に関わるため、要件定義の段階で枠組みを定めます。
推進体制と段階導入を見据えたスケジュールの要件
誰が推進し、現場の代表者がどう関わるかを要件定義書に記載します。現場のキーパーソンを含めた体制が、システム定着の前提になります。
- 現場の参画：要件定義の段階から現場が加わる
- 段階導入：進捗管理から実績・在庫へ広げる計画を立てる
早期に現場が参加すれば、リリース後の「聞いていない」「使いにくい」といった反発を減らせます。中小規模の導入期間は3〜6ヶ月が目安です。
各段階で習熟度を確かめられるよう計画しておきます。全機能を同時に稼働させることを急がない方針を要件定義に記載すれば、一斉導入の失敗を避けやすくなります。
補助金申請を見据えた要件の整え方
IT導入補助金などを使う場合は、申請要件を要件定義に織り込んでおきます。対象経費には補助率1/2〜2/3が適用され、導入費への補助を受けられる可能性があります。
- 対象製品：導入したいシステムが制度の対象になるか
- 対象経費：どの費用が補助対象になるか
数百万円の導入費に対し、百万円単位の補助を受けられる場合があります。ただし、対象製品と経費の範囲は制度ごとに決まっています。
補助金ありきで製品や要件を歪めると、必要な機能を諦めることになりかねません。また、制度の要件や補助率は年度ごとに変わります。
まず自社に合う要件を固め、その導入を対象とする制度を探します。補助金は、あれば得をするものと捉え、現場の課題解決を優先します。
まとめ
工程管理システムの要件定義は、現場ヒアリングでAsIsを可視化し、ToBeの姿を描くことから始まります。ISA-95を参考に、ERPとの分担や生産形態別の要件を決めます。
機能要件の優先度と非機能要件を整理し、Excel連携やデータ移行も含めてRFPにまとめます。そのうえで、費用相場と長期TCOをもとに見積りを判断します。
大切なのは、技術仕様より先に、現場の課題と解決したいことを言葉にすることです。要求が固まれば、ベンダーの提案や見積りを評価しやすくなります。
riplaはフルスクラッチ受託と国内開発を組み合わせます。現場ヒアリングからAsIs/ToBeの整理、生産形態に即した要件定義、内製化を踏まえたコストの抑え方まで、一貫して支援します。
全体像は完全ガイドをご覧ください。
▼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を創業。