メーカー向けのシステムのRFP/要件定義書/提案依頼書について

メーカー（製造業）向けのシステムを開発・導入するうえで、プロジェクトの成否をもっとも大きく左右するのが要件定義です。とくにメーカーのシステムは、生産計画・部品表・在庫・調達・原価といった業務が複雑に連鎖し、現場ごとに長年の改善で培われた暗黙知が積み重なっているため、これをいかに正確に要件として整理し、RFP（提案依頼書）や要件定義書に落とし込めるかが、現場に使われるシステムになるか、使われず混乱を招くかの分かれ目になります。実際、現場理解を欠いたまま汎用ERPを導入し、生産ラインが混乱して調達が一時停止した事例も報じられています。

本記事は、メーカー向けのシステムのRFP・要件定義書・提案依頼書を、発注企業の視点から具体的に解説する「要件定義特化」の記事です。現場ヒアリングとAsIs/ToBeモデルの描き方、製造特有の商習慣（生産計画・BOM・原価）を要件に落とす方法、発注側のユーザー協力義務という法的論点、データ移行・マスター整備、そしてRFPに盛り込むべき項目までを、製造の実務に即して掘り下げます。読み終えるころには、ベンダーに渡すRFPの骨子が描けるはずです。なお、全体像をまだ把握していない方は、まずメーカー向けのシステムの完全ガイドから読むことをおすすめします。

▼全体ガイドの記事
・メーカー向けのシステムの完全ガイド

現場ヒアリングとToBeモデルから始める進め方

メーカー向けシステムの要件定義は、機能の一覧を埋めることから始めるべきではありません。出発点は、現場が「実際にどう作業を進め、どこに無駄や手戻りがあるか」を徹底的にヒアリングすることです。製造現場の業務は、生産管理者・現場作業者・調達・原価管理・品質保証と多くの関係者が関わり、それぞれの段取りや判断が複雑に絡み合っています。この実態を理解せずに要件を固めると、現場と噛み合わないシステムになります。

要件定義の王道は、現状の業務フロー（AsIs）を可視化し、あるべき業務の姿（ToBe）を描き、そのギャップをシステムで埋めるという順序です。ここで陥りがちなのが「DXが流行りだから」という曖昧な目的で高機能なシステムを導入し、現場の反発を招くパターンです。目的が曖昧なまま多機能を入れると、現場は「今までのやり方の方が楽だ」と感じて使わなくなります。まず「何のために、どの業務を、どう変えるのか」という目的を明確にすることが、すべての出発点です。

重要なのは、システム導入を単なる「今のやり方の電子化」で終わらせず、業務そのものを見直す機会（AX＝業務変革）と捉えることです。ToBeを描く過程で、長年続けてきた無駄な工程や二重管理を廃止する判断が必要になります。現場の業務フローを標準化し、システムに合わせられる部分は合わせ、本当に自社固有で譲れない部分だけをカスタマイズする。この線引きを要件定義で明確にすることが、過剰カスタマイズによる費用の高止まりを防ぎます。AsIs/ToBeの整理は、機能要件を書く前の最重要工程です。

ヒアリングでは、生産管理者だけでなく、現場で実際に手を動かす作業者、部材を手配する調達、原価を締める経理、検査を担う品質保証まで、幅広い関係者の声を拾うことが欠かせません。製造現場には「この製品はこの段取りで作る」「この取引先には特急対応できる」といった、文書化されていない暗黙知が大量に存在します。これを言語化して要件に落とし込まないと、システムが現実の運用に合わなくなります。

ヒアリングの質が、後工程の手戻りを大きく左右します。要件定義の段階で現場の暗黙知を拾いきれていないと、開発が進んでから「この例外処理がないと現場が回らない」という要望が次々に出て、仕様変更が膨らみます。だからこそ、要件定義には現場を巻き込み、時間をかけて業務の実態を可視化する価値があります。この丁寧なヒアリングこそが、生産ラインの混乱という最悪の失敗を避ける防波堤になります。現場起点で要件を組み立てる姿勢が、メーカーシステムの要件定義の核心です。

ヒアリングで現場の実態が見えてきたら、次に決めるべきは「どこまで業務をシステムの標準に合わせ、どこからを自社固有のカスタマイズとするか」という線引きです。この線引きを要件定義で明確にしないまま開発に進むと、現場の「今までどおりにしたい」という要望をすべて受け入れることになり、過剰カスタマイズで費用が膨らみます。カスタマイズの追加は1件あたり100万〜1,000万円に達することもあり（出典：ripla）、線引きの甘さが予算超過に直結します。

判断の基準は、「その要件は競争力の源泉か、それとも単に慣れたやり方への固執か」です。自社の強みを生み出す固有の工程はカスタマイズする価値がありますが、一般的な事務処理まで作り込むのは無駄です。要件定義の段階で、現場の要望を「標準で吸収する」「業務側を見直す」「どうしても必要だから作り込む」の三つに仕分けすることが、費用とベンダーロックインの両方を抑えます。この仕分けは現場との対話が必要で、なぜ標準に合わせるのかを丁寧に説明することが、後の定着にもつながります。標準化とカスタマイズの線引きは、要件定義が担う最も価値の高い意思決定の一つです。

製造特有の商習慣を要件に落とす

メーカーの要件定義が、ほかの業種と決定的に異なるのが「製造特有の業務をどう要件に落とすか」です。生産計画、部品表（BOM）、所要量計算、原価計算といった製造業固有の論点を、自社の実態に即して仕様化できるかが、現場で使えるシステムになるかどうかを決めます。ここを汎用パッケージの標準機能に無理に合わせると、現場が回らなくなります。

製造特有の要件で、もっとも丁寧な仕様化が必要なのが部品表（BOM）と原価計算です。製品の構成がどれだけ複雑か、設計変更がどの頻度で発生するか、どの単位で原価を把握したいか（製品別・工程別・ロット別）といった点を、自社の実態に即して定義する必要があります。これらが曖昧なまま開発に進むと、導入後に「BOMが現実の製品構成と合わない」「原価が見たい粒度で出ない」というトラブルに直結します。

生産計画についても、自社が「受注生産か、見込生産か、その混在か」によって必要な機能が大きく変わります。負荷平準化や納期回答をどこまで自動化したいか、特急対応の例外処理をどう扱うかといった点を要件で固めておくことが、後の手戻りを防ぎます。あわせて、重い図面・部品表データを扱う場合は、クラウドかオンプレミスかというインフラ要件も要件定義で議論すべきです。製造の重いデータは通信速度の観点からオンプレが有利になる場面があり、これを後回しにすると性能要件で揉めます。製造固有の論点を一つずつ仕様化することが、要件定義書の中核を成します。

原価をどの粒度で見たいかは、要件定義のなかでも特に意見が割れる論点です。製品別だけでよいのか、工程別・ロット別・顧客別まで分解したいのかによって、現場が入力すべき実績データの細かさが変わります。細かく見たいほど現場の入力負担が増えるため、「経営が見たい粒度」と「現場が無理なく入力できる粒度」のバランスを、要件定義で擦り合わせる必要があります。理想だけで細かい原価管理を要件化すると、現場が入力しきれずデータが埋まらない、という本末転倒に陥ります。経営の要求と現場の実態の折り合いをつけることが、使われる原価機能の前提です。

要件定義で見落とされがちなのが、データ移行とマスター整備（クレンジング）です。新しいシステムに既存の品目マスタ・取引先マスタ・BOM・在庫データを移すとき、重複や表記揺れ、古い情報をそのまま持ち込むと、せっかくのシステムが「ゴミデータを高速処理するだけ」になってしまいます。本番稼働前に、基幹データ・現場の在庫データ・実物在庫の三者を一致させる泥臭い調整が欠かせません。

このデータ移行・クレンジングは、要件定義の段階で「誰が、いつまでに、どの粒度でデータを整備するか」を明確に役割分担しておくべき領域です。ここを曖昧にすると、開発の終盤で「マスタが整理されておらず移行できない」と判明し、稼働が大幅に遅れます。マスター整備は地味で時間のかかる作業ですが、システムの精度を支える土台です。要件定義書には、機能要件だけでなく、このデータ移行の範囲・責任・スケジュールも明記しておくことが、稼働後のトラブルを防ぎます。

社内稟議を突破するROIの算出ロジック

要件定義と並行して、見落とされがちなのが「この投資をどう社内で承認してもらうか」という稟議の準備です。どれだけ良い要件定義書を作っても、経営層が投資を承認しなければプロジェクトは始まりません。メーカーのシステム投資は数百万円から数億円に及ぶため、説得力のあるROI（投資対効果）の算出ロジックを、要件定義の段階から組み立てておく必要があります。ここは多くの解説が手薄な領域であり、丁寧に準備するほど差がつきます。

システム投資の評価基準は、社内の階層によって異なります。現場は「使いやすさ」を、生産管理は「面積生産性や稼働率」を、経営は「ROIや利益率」を重視します。稟議を通すには、この階層ごとに刺さる言葉で価値を語る必要があります。現場には操作のしやすさと負担軽減を、経営には金額に換算した効果を提示する。要件定義の段階で、誰にどの価値を訴えるかを意識しておくと、稟議資料の説得力が増します。

具体的には、特急外注の年間削減額、集計工数の削減時間と人件費換算、原価の見える化による利益改善見込みを、自社の実数値で積み上げます。一次データでは、特急外注を年最大20%、集計を月100時間以上削減し、2〜3年で投資を回収した事例が報告されています（出典：ripla）。これらの効果率を自社の外注費や工数に当てはめれば、回収年数が概算できます。階層別の評価基準を要件定義の段階で押さえておくことが、現場・経営の双方を納得させる土台になります。

稟議を強くするには、目に見える金額効果だけでなく、非財務価値の数値化も有効です。たとえば、属人化していたベテランの暗黙知をシステムに残すことによる技術継承、納期遵守率の向上による顧客満足、品質トレーサビリティによるリコールリスクの低減、さらにはCO2削減量といった環境価値まで、定性的に語られがちな価値をできる限り数字で示します。これらは直接の金額にはなりにくいものの、経営判断では無視できない要素です。

投資回収の計算では、将来のキャッシュフローを現在価値に割り引くDCF法（割引キャッシュフロー法）の考え方を取り入れると、長期にわたる効果を説得力ある形で提示できます。単年度の損益だけでなく、5年・10年のスパンで効果を積み上げて見せることで、初期投資の大きさに対する経営の抵抗を和らげられます。要件定義の段階でこうしたROIロジックを準備しておくことが、稟議の停滞でプロジェクトが宙に浮くリスクを防ぎ、円滑な意思決定につながります。算出の根拠となる現状数値も、ヒアリングのなかで集めておくとよいでしょう。

RFPの項目と発注側の協力義務

要件が整理できたら、それをRFP（提案依頼書）に落とし込み、ベンダーへ渡します。RFPの質が、ベンダーからの提案の質と見積りの精度を決めます。同時に、発注側であるメーカー自身が「ユーザーとしての協力義務」を負うことを理解しておくことも、トラブルを避ける鍵です。

RFPには、システム化の目的・背景、対象業務の範囲、機能要件、非機能要件（性能・可用性・セキュリティ）、データ移行の範囲、予算と納期、そして保守・運用の条件を盛り込みます。とくにメーカーでは、重いデータを扱う性能要件、基幹システムとの連携要件、保守サポートのSLA（サービス品質保証）を明確に書くことが重要です。保守費は一般に開発費の15〜20%が目安とされ、開発費3,000万円なら年450万〜600万円、オンプレ運用では年500万〜1,500万円規模になることもあります（出典：ripla）。この保守条件をRFPで明示しないと、稼働後の運用コストが見えません。

RFPで業界特有の現場感を理解しているベンダーを見極めることも大切です。製造業の業務を理解しないベンダーに丸投げすると、標準パッケージに業務を無理に合わせる提案になりがちです。ヘルプデスクや伴走型サポートの有無、導入後の定着支援まで含めて、サポート体制を比較できるようRFPを設計してください。見積りを比較するときは、安さだけでなく「自社の製造業務をどこまで理解した提案か」を軸に判断することが、後の失敗を防ぎます。

見積りの妥当性を判断するには、内訳の粒度にも注目してください。一式いくらという大括りの見積りは、後から「これは別費用」と追加請求される余地を残します。要件定義・設計・開発・テスト・データ移行・教育・保守といった工程ごとに費用が分かれ、前提条件が明記された見積りほど信頼できます。とくにデータ移行費や教育費、稼働後の保守費が見積りに含まれているかは、必ず確認すべき点です。これらが抜けた見積りは安く見えても、後で総額が膨らみます。RFPの段階で見積りの様式を指定しておけば、複数ベンダーを同じ土俵で比較でき、判断の精度が上がります。

要件定義でぜひ知っておきたいのが、システム開発はベンダーだけの責任ではなく、発注側であるユーザーにも「協力義務」があるという法的論点です。ベンダーのプロジェクトマネジメント義務だけでなく、ユーザーが要件を適時に提示し、意思決定を行い、仕様を凍結する協力を怠ると、発注側の責任が問われることがあります。要件を曖昧にしたまま、開発の終盤で大量の追加要望を出すと、トラブルの原因になります。

実際の判例でも、この協力義務が重く扱われています。旭川医大病院とNTT東日本の事件では、控訴審（札幌高裁・平成29年8月31日）でユーザー側の協力義務違反が認定され、169項目中124項目が開発対象外とされたうえで、ユーザー側のみに約14億1500万円の支払いが命じられました（出典：ripla）。これは医療機関の事例ですが、要件を固めきれずに追加要望を繰り返す発注側のリスクを示す警鐘です。だからこそ、要件定義の段階で仕様をしっかり固め、凍結のルールを決めておくことが、メーカー自身を守ることにつながります。

まとめ

メーカー向けのシステムの要件定義は、機能一覧を埋める作業ではなく、現場ヒアリングでAsIsを可視化し、目的を明確にしてToBeを描き、製造特有の生産計画・BOM・原価・データ移行を一つずつ仕様化していく営みです。RFPには機能要件だけでなく、性能・連携・保守SLAまで盛り込み、業界の現場感を理解したベンダーを見極める。同時に、発注側であるメーカー自身にもユーザー協力義務があり、旭川医大の約14億1500万円判決が示すように、要件を固めきれない発注側のリスクは小さくありません。要件定義こそが、生産ライン混乱という最悪の失敗を避ける最大の防波堤です。

要件定義は時間と手間のかかる工程ですが、ここを丁寧に進めるほど、後の開発・導入の手戻りが減り、結果として総コストを抑えられます。現場を巻き込み、暗黙知を言語化し、製造固有の要件とデータ移行まで詰めきることが、現場に使われるシステムへの最短ルートです。riplaはフルスクラッチ受託と国内開発を組み合わせ、製造現場の業務から逆算した要件整理と、RFP・要件定義書の作成を一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

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

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

株式会社riplaの会社HPはこちら

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

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。