製造業界のシステムのRFP/要件定義書/提案依頼書について

製造業界のシステム開発を外部ベンダーに依頼するとき、その成否を最初に左右するのが要件定義とRFP（提案依頼書）の質です。製造業は、生産形態（個別受注・繰返生産・見込生産）や工程の組み方が会社ごとに大きく異なり、現場の暗黙知が業務に深く埋め込まれています。これを言語化せず「いい感じに作ってほしい」とベンダーに丸投げすると、現場と噛み合わないシステムが出来上がり、巨額の投資が無駄になります。

本記事は、製造業界のシステムのRFP・要件定義書・提案依頼書の作り方を、発注側（ユーザー企業）の視点から具体的に解説する「要件定義特化」の内容です。現状業務の可視化（AsIs）とあるべき姿（ToBe）の描き方、ユーザーの協力義務を踏まえた要件凍結、図面・部品表など外部連携やデータ移行・クレンジングの要件、SLAや保守を含めたRFPの記載項目まで、法的リスクの一次データとあわせて整理します。なお、製造業システムの全体像をまだ把握していない方は、まず製造業界のシステムの完全ガイドから読むと、要件定義の位置づけが理解しやすくなります。

▼全体ガイドの記事
・製造業界のシステムの完全ガイド

現状業務の可視化とToBe設計の進め方

製造業の要件定義は、いきなり「欲しい機能」を並べることから始めてはいけません。まず行うべきは、現状の業務がどう回っているかを可視化することです。受注から生産計画、調達、製造、検査、出荷、原価集計まで、誰が・どの帳票で・どう処理しているかを洗い出す。この現状（AsIs）の理解なしに描いた要件は、現場の実態と乖離します。要件定義の出発点は、現場ヒアリングと業務フローの可視化です。

製造業の業務には、ベテランの判断や現場の慣行といった暗黙知が大量に埋め込まれています。「この得意先の注文はいつも納期を優先する」「この工程は天候で歩留まりが変わる」といった知識は、帳票には現れません。要件定義では、生産管理・現場リーダー・調達・品質・経理など各部門にヒアリングし、こうした暗黙知を言語化することが不可欠です。ここを飛ばすと、システムが現場の判断を再現できず、結局Excelや紙に戻ってしまいます。

「DXが流行りだから」といった曖昧な目的で高機能なシステムを入れようとすると、現場の反発を招き、定着しません。ヒアリングを通じて「現場が本当に困っていること」を起点に目的を定めることが重要です。トップダウンで決めた理想論ではなく、現場の課題から逆算した要件こそが、使われるシステムを生みます。ヒアリングは手間がかかりますが、後の手戻りコストを考えれば最も費用対効果の高い工程です。

現状を可視化したら、次は「あるべき業務の姿（ToBe）」を描きます。ここで重要なのは、現状の業務をそのままシステム化するのではなく、ムダや属人化を整理して業務を標準化することです。現状をそっくり再現しようとすると、複雑な個別仕様が積み上がり、過剰カスタマイズによる高止まりやバージョンアップ困難、ベンダーロックインを招きます。パッケージを使う場合は、できる限り業務をシステムの標準に合わせる発想が、長期的なコストを抑えます。

もちろん、製造業には標準化しきれない競争力の源泉となる固有業務もあります。ToBe設計では、「標準に合わせてよい業務」と「自社の強みとして作り込むべき業務」を切り分けることが肝心です。この切り分けがRFPの要件の濃淡になり、ベンダーの工数見積もりの精度を左右します。すべてを作り込もうとすればフルスクラッチは1,000万〜数億円に膨らみますが、標準活用と作り込みを賢く配分すれば、投資を必要な部分に集中できます。

ToBe設計のもう一つの効果は、要件に優先順位がつくことです。あるべき姿を描くと、「これは初期リリースで必須」「これは第2フェーズでよい」といった段階分けが見えてきます。すべてを一度に実現しようとせず、効果の大きい業務から段階的に作る計画を立てることで、初期投資を抑えつつ、早期に効果を出せます。要件定義は、機能を列挙する作業ではなく、限られた予算をどの業務に優先配分するかを決める、経営的な意思決定のプロセスでもあるのです。

協力義務を踏まえた要件凍結とプロジェクト体制

要件定義は、ベンダーに任せきりにできる工程ではありません。システム開発では、ベンダー側のプロジェクトマネジメント義務だけでなく、発注側（ユーザー）にも「協力義務」という法的責任があります。要件を固める段階での発注側の関与不足や、合意した要件の後からの大量変更は、プロジェクト失敗の主因であり、裁判でユーザー側が責任を問われる事例も実在します。

システム開発のトラブルは、ベンダーだけの責任とは限りません。旭川医大病院とNTT東日本の事件では、控訴審（札幌高裁・平成29年8月31日）でユーザー側の協力義務違反が認定されました。発注側が次々と追加要望を出し、169項目のうち124項目が当初の開発対象外だったと判断され、結果としてユーザー側のみに約14億1,500万円の支払いが命じられています。要件を曖昧にしたまま走り、後から大量に変更を求めると、発注側が法的責任を負うことを示す重い事例です。

この教訓から、要件定義書には「何を作るか」を明確に書き切り、発注側が責任を持って要件を確定させることが求められます。要件は早い段階で凍結し、それ以降の変更は正式な変更管理プロセスを通す。製造業は設計変更や仕様変更が多い業界だからこそ、この変更管理のルールをRFPの段階で取り決めておくことが、後の紛争を防ぎます。協力義務は、発注側が要件定義に主体的に関わることへの法的な裏付けでもあります。

要件を確定させ、変更管理を回すには、社内のプロジェクト体制が機能している必要があります。RFPの段階で、誰が要件の最終意思決定者か、各部門の窓口は誰か、どの会議体で承認するかを明確にしておくことが大切です。製造業は現場・生産管理・調達・品質・経営と関係部門が多く、これらの意見を取りまとめる体制がないと、要件がいつまでも固まりません。

特に、現場の使いやすさを重視する立場、面積生産性を重視する立場、ROIを重視する経営層では、評価基準が異なります。この階層別の評価基準の違いを早期に擦り合わせ、優先順位を合意しておくことが、稟議の突破にもつながります。要件定義は技術文書である前に、社内の合意形成のプロセスです。riplaはフルスクラッチ受託の立場から、現場の業務から逆算した要件整理と、関係部門の合意形成までを伴走する進め方を重視しています。

要件定義の体制で見落とされがちなのが、実際にシステムを使う現場担当者の巻き込みです。意思決定者や管理者だけで要件を固めると、現場の実務感覚が抜け落ち、「管理側は見たいが現場は入力できない」要件になりがちです。要件定義の段階から、各工程のリーダーや実務担当者を巻き込み、画面イメージや入力の流れをレビューしてもらうことで、定着しやすい要件に近づきます。

現場を巻き込むことには、もう一つの効果があります。要件定義の段階から関わった現場担当者は、システムを「自分たちが作ったもの」と感じ、稼働後の定着の推進役になってくれます。逆に、上から降ってきたシステムは反発を招きやすいものです。要件定義は、技術仕様を固める場であると同時に、現場の納得と当事者意識を醸成する場でもあります。この観点を持つかどうかが、稼働後の定着率を大きく左右します。

外部連携・データ移行・クレンジングの要件

製造業のシステムは、単体で完結することはほとんどありません。CAD・設計システム、会計システム、得意先や仕入先とのEDI、設備のIoTなど、外部とのデータ連携が必須です。さらに、既存システムからのデータ移行も避けて通れません。これらをRFPの要件として明記しておかないと、開発後半で「連携が想定外に重い」「移行データが汚くて使えない」という問題が噴出します。

外部連携の要件は、相手があるだけに事前協議が欠かせません。得意先とのEDI（電子データ交換）は、相手のシステム仕様に合わせる必要があり、仕様変更には相手との調整時間がかかります。物流のEDI仕様変更では、最低でも3ヶ月前から事前協議を始めるべきとされるように、外部連携は自社の都合だけでは進みません。RFPには、どの相手と・どのフォーマットで・どの頻度で連携するかを具体的に記載します。

図面や部品表のような大容量データは、連携方式の設計が重要です。CADの3D図面をクラウド経由でやり取りすると通信速度がボトルネックになるため、図面実体はオンプレミスに置き、管理情報だけを連携するといった構成判断が必要です。設備のIoT連携も、どの設備から・どんなデータを・どう取り込むかを要件化します。外部連携は「つながればよい」ではなく、データ量・頻度・相手の都合まで含めて要件定義することが、後の手戻りを防ぎます。

要件定義で見落とされがちなのが、データ移行とマスター整備（クレンジング）です。品目マスタ・取引先マスタ・部品表といった既存データには、重複登録・表記揺れ・廃番品の放置など、長年の汚れが溜まっています。これを放置したまま新システムに移行すると、いわば「ゴミデータを高速処理するだけ」のシステムになり、せっかくの投資効果が損なわれます。データクレンジングを要件に含めることは、地味ですが極めて重要です。

移行の要件では、どのデータを・どの粒度で・どこまでさかのぼって移すかを定めます。あわせて、基幹システム上の在庫・現場が把握している在庫・実物の在庫という三つの在庫を本番前に一致させる調整も必要です。この泥臭い作業を誰が・いつ・どこまで担うかをRFPで明確にしないと、本番直前に大混乱します。データ移行・クレンジングの工数とコストは、見積もりに含まれているかを必ず確認してください。隠れコストになりやすい領域です。

クレンジングは、新システム導入を「マスター整備の好機」と捉えると前向きに進められます。長年放置されてきた重複や表記揺れを、この機会に整理し、命名ルールを統一する。一度きれいなマスターを作っておけば、新システムの効果は最大化され、その後の運用も楽になります。要件定義では、移行対象データの棚卸しと、クレンジングの担当・期限・判断基準まで具体的に決めておくことが、本番稼働をスムーズにする鍵です。ここを曖昧にした移行は、ほぼ確実にトラブルを生みます。

RFPに盛り込むSLA・保守・選定基準

RFPは要件を伝えるだけの文書ではなく、ベンダーを公平に比較し、運用開始後の関係を取り決める文書でもあります。SLA（サービス品質保証）、保守体制、費用の内訳、選定基準まで盛り込むことで、提案の比較が容易になり、契約後のトラブルも減らせます。製造業は生産が止まると損害が直撃するだけに、運用面の取り決めは特に重要です。

SLAでは、障害時の復旧目標時間や問い合わせの応答時間、サポートの対応時間帯を定めます。製造ラインを止められない企業ほど、復旧時間の短さが死活問題になります。あわせて、保守費用の相場感を押さえておくことも重要です。保守費は一般に開発費の15〜20%が目安とされ、3,000万円の開発なら年450万〜600万円、オンプレミス運用では年500万〜1,500万円かかることもあります。これを見込まずに導入すると、運用フェーズで予算が破綻します。

RFPには、初期費用だけでなく、こうした保守・運用の年間コスト（TCO）の見積もりを求める項目を入れるべきです。安い初期費用に飛びついた結果、保守費やカスタマイズ追加費（1件100万〜1,000万円）で総額が膨らむケースは珍しくありません。導入後数年間の総コストで比較できるよう、RFPで費用の内訳を明示させることが、賢いベンダー選定の前提になります。

SLAでは、サポートの体制だけでなく、データのバックアップ頻度や、障害時のデータ保全についても取り決めておくと安心です。製造業のシステムには、生産実績や原価、品質記録といった失われると業務に支障が出るデータが蓄積されます。これらをどう守り、有事にどう復旧するかを要件として明記することで、運用フェーズの不安を減らせます。SLAは契約書の付属物ではなく、生産を止めないための実務的な取り決めだと捉えるべきです。

ベンダー選定では、機能や価格だけでなく、製造業の現場感やノウハウを理解しているかが重要な基準になります。製造業特有の生産形態や工程の機微を理解しないベンダーは、要件のヒアリングで的を外し、現場と噛み合わないシステムを作りがちです。RFPには、同業種の実績や、現場ヒアリングをどう進めるかの提案を求める項目を入れ、業界理解の深さを見極めましょう。

もう一つの選定基準が、導入後の伴走力です。システムは導入して終わりではなく、現場に定着して初めて成果が出ます。操作教育、運用ルールの定着、トラブル時のサポートまで伴走できるベンダーかどうかが、長期的な成否を分けます。RFPで保守・サポート体制を具体的に問い、提案内容を比較することが大切です。要件定義とRFPに手間をかけることは、製造業システムという大きな投資を成功に導く、最も確実な保険になります。

選定では、複数のベンダーから提案を受け、同じRFPに対する回答を比較することも重要です。RFPの記載が具体的であるほど、各社の提案を同じ土俵で比較でき、価格・機能・体制の違いが明確になります。逆にRFPが曖昧だと、各社が前提を勝手に置いて見積もるため、比較自体が成立しません。要件を丁寧に言語化したRFPは、自社の業務整理になるだけでなく、ベンダーを公平に評価し、最良のパートナーを選ぶための土台にもなるのです。

RFP・要件定義の段階で、稼働前の受け入れテスト（UAT）と本番稼働の判定基準を取り決めておくことも重要です。「どんな状態になったら本番に移行してよいか」を曖昧にしたまま進めると、不具合を残したまま稼働を強行し、グリコの事例のように出荷・生産が止まる事態を招きます。要件に対して、誰が・どんな観点で・どこまで確認したら合格とするかを、あらかじめ定義しておくことがリスク管理になります。

製造業では、本番稼働の前に一定期間、新旧システムを並行運用して結果を突き合わせる検証が有効です。並行運用で現場が新システムに慣れ、データの整合も確認できれば、一気に切り替えるリスクを大きく下げられます。RFPには、こうしたテスト期間や並行運用の想定も盛り込み、ベンダーの提案に含まれているかを確認しましょう。受け入れ基準と移行計画を要件段階で固めることが、稼働後の生産停止という最悪の失敗を防ぐ最後の砦になります。

まとめ

製造業界のシステムの要件定義・RFPは、現場ヒアリングによる現状（AsIs）の可視化と、業務を標準化したあるべき姿（ToBe）の設計から始まります。ユーザーの協力義務を踏まえて要件を早期に凍結し、変更管理のルールを定めることが、旭川医大事件のような法的リスクを避ける鍵です。EDI・図面・設備の外部連携やデータ移行・クレンジングを要件に明記し、SLA・保守費（開発費の15〜20%）・業界理解と伴走力を選定基準に据えることが、投資を成功に導きます。

要件定義で大切なのは、ベンダーに丸投げせず、発注側が主体的に業務を言語化し、関係部門の合意を形成することです。手間はかかりますが、ここに投じた時間が、後の巨額の手戻りや法的紛争を防ぎます。riplaはフルスクラッチ受託と国内開発を組み合わせ、現場の業務から逆算した要件整理と、合意形成・データ移行までの伴走を一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。

株式会社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を創業。