工程管理システムの導入を成功させられるかどうかは、開発が始まる前の「要件定義」と、ベンダーに依頼するための「RFP（提案依頼書）」の質でほぼ決まります。どれだけ優秀なベンダーに発注しても、自社が何を作りたいのか、現場のどの課題を解決したいのかが曖昧なままでは、できあがったシステムは現場に合わず使われません。逆に、要件定義をしっかり固め、RFPで自社の要求を正確に伝えられれば、見積りの妥当性も判断でき、導入後のミスマッチを大きく減らせます。
本記事は、工程管理システムのRFP・要件定義書・提案依頼書を、発注側が自力で作り込めるように具体的に解説する「要件定義特化」の内容です。AsIs（現状）の工程フローの可視化から、ISA-95を前提とした役割分担、生産形態別の要件整理、機能要件と非機能要件の切り分け、そしてRFPに必ず盛り込むべき項目と見積りの妥当性を判断する軸まで、順を追って解説します。なお、工程管理システム導入の全体像をまだ把握していない方は、まず工程管理システムの完全ガイドから読むことをおすすめします。
▼全体ガイドの記事
・工程管理システムの完全ガイド
AsIsの工程フローを可視化する要件定義の第一歩
要件定義の出発点は、自社の現状（AsIs）の工程フローを正確に可視化することです。多くの製造現場では、生産計画から実績集計までの流れが属人化しており、ベテランの頭の中にしか正確な業務手順が存在しない、という状態が珍しくありません。この暗黙知を表に出し、誰が・どの順番で・何を使って工程を回しているかを図に描き起こすことが、すべての要件定義の土台になります。
現場ヒアリングでAsIsの工程フローを描く
AsIsの可視化は、生産管理担当者だけでなく、計画・現場の作業者・品質・出荷といった関係者に丁寧にヒアリングして進めます。「実際にどう計画を立てているか」「現場でどう進捗を記録しているか」「どこに無駄や手戻り、二重入力があるか」を細かく聞き取り、現状の工程フローを一枚の図にまとめます。このとき、表向きのマニュアル通りの手順ではなく、現場が本当にやっている「裏の手順」まで拾うことが肝心です。
この可視化の過程で、現状の課題が自然と浮かび上がります。日報をExcelに転記する工数、進捗確認のために現場を歩き回る時間、Excelファイルの版が複数できて混乱する問題など、AsIsを描くことで初めて「どこを直せば効果が大きいか」が明確になります。要件定義の質は、このAsIsの解像度の高さに比例すると言っても過言ではありません。
ToBeモデルで「あるべき工程の姿」を設計する
AsIsを可視化したら、次は「あるべき工程の姿」であるToBeモデルを描きます。システムを導入したあと、計画から実績までがどう流れるべきか、どの手作業がなくなり、どの情報がリアルタイムに共有されるべきかを設計します。ここで大切なのは、現状の業務をそのままシステムに置き換えるのではなく、無駄な工程を削ぎ落とし、業務そのものを改善する視点を持つことです。
ToBeモデルが曖昧なまま開発に進むと、できあがったシステムは現状の非効率をそのままデジタル化しただけ、という結果になりがちです。ToBeを明確にしておけば、ベンダーに「何を実現したいのか」を正確に伝えられ、提案の質も上がります。AsIsの可視化とToBeの設計は、要件定義の両輪であり、ここに時間をかけることが導入成功の最大の近道です。
ISA-95の役割分担と生産形態別の要件整理
要件定義では、工程管理システムが自社の情報システム全体の中でどの役割を担うのかを明確にする必要があります。ここで参照したいのが、製造業の国際的な階層モデルであるISA-95です。このモデルでは、生産を計画する上位の層（ERP）と、現場で生産を実行する層（MES・工程管理）が役割分担をしており、両者の境界をどこに引くかを要件定義の段階で決めておくと、後の連携トラブルを防げます。
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年で数百万円になるため、どこを自社で担うかをRFPの段階で示すことが、賢いコスト管理につながります。
見積りの妥当性を判断する軸
集まった見積りの妥当性を判断するには、費用相場を知っておくことが欠かせません。中小の生産管理・工程管理システムでは初期費用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が適用されるため、数百万円の導入費に対して百万円単位の補助が受けられる可能性があります。ただし、補助対象となる製品や経費の範囲は制度ごとに決まっているため、自社が導入したい工程管理システムが対象になるか、どの経費が補助されるかを事前に確認する必要があります。
注意したいのは、補助金ありきで製品や要件を歪めないことです。補助金は年度ごとに要件や補助率が変動するため、制度に振り回されると本来必要な機能を諦めることになりかねません。賢い進め方は、まず自社に最適な要件を固め、その導入が対象となる制度を探す、という順序です。補助金は「あれば得をするボーナス」と位置づけ、要件定義の本質である「現場の課題解決」を優先することが、長期的に見て正しい判断です。
まとめ
工程管理システムの要件定義とRFPは、AsIsの工程フローを現場ヒアリングで可視化し、ToBeのあるべき姿を描くことから始まります。ISA-95を下敷きにERPと工程管理の役割分担を決め、自社の生産形態に応じた要件を整理し、機能要件を必須・優先・将来に分類し、非機能要件とExcel連携・データ移行の要件まで漏れなく書き込む。これらをRFPにまとめ、費用相場と長期TCOを軸に見積りの妥当性を判断する、という一連の流れが導入成功の骨格です。
要件定義で大切なのは、技術仕様を細かく書くことより、「現場のどの課題を、どう解決したいのか」を起点に要求を言語化することです。ここが固まっていれば、ベンダーは課題解決の提案をしてくれ、見積りの妥当性も判断できます。riplaはフルスクラッチ受託と国内開発を組み合わせ、現場ヒアリングからのAsIs/ToBe整理、生産形態に即した要件定義、内製化を織り込んだコスト最適化までを一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、弊社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。