PLM（製品ライフサイクル管理）の導入は、RFP（提案依頼書）と要件定義書の出来でほぼ決まります。RFPには、既存システムとの役割分担、生産形態、データ連携や移行の範囲を明記します。
製品の良し悪しやベンダーの技術力よりも、自社の要求を正確に言語化できているかが成否を分けます。言語化が甘いと、カスタマイズ費が当初見積の倍近くに膨らみます。全体像や費用相場は、PLMの完全ガイドでご確認ください。
▼全体ガイドの記事
・PLMの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
ISA-95を前提にした既存システムとの役割分担要件
PLMのRFPで最初に明確にすべきは、既存システムとの役割分担です。PLMは単独で完結するシステムではなく、ERP（基幹）やMES（製造実行）と連携して初めて効果を発揮します。
役割分担を曖昧にしたままRFPを出すと、「どこまでをPLMが担うか」の前提がベンダーごとにずれ、提案を横並びで比較できなくなります。
PLM／ERP／MESの機能分担を線引きする要件
製造業の情報システムは、ISA-95という国際標準の階層モデルで整理できます。ざっくり言えば、ERPが計画層（受注・調達・原価・在庫）を、MESが実行層（製造指示・実績収集）を担います。
PLMは、それらの上流にある「製品定義・設計情報・BOMの源泉」を担います。そのうえで、RFPでは、この三者のうち「自社では何をPLMに任せ、何を既存ERP/MESに残すのか」を明記する必要があります。たとえば、原価管理はERP側で行うのか、PLMで設計原価を試算するのかといった線引きが必要になります。
この線引きが曖昧だと、機能が重複するか、逆に「どちらも担当しない空白」が生まれます。BOMでいえば、PLMが正（マスター）を持ち、ERPはそれを受け取るのか、双方で編集するのか、という問いです。マスターの所在を一つに定めることが、データ整合性を保つうえでの大原則です。
RFPに「BOMマスターはPLMが保持し、ERPへは一方向で連携する」と明記しておけば、提案の前提が揃い、後の二重管理トラブルを防げます。役割分担はPLM要件定義の出発点です。ここを曖昧にしたまま進むと、後工程のすべてが揺らぎます。
- 機能ごとの担当：ERP・MES・PLMのどこが担当するかを一覧にする
- 担当の空白：どの担当にも入らない機能が残っていないかを洗い出す
連携インターフェース・データ受け渡しの要件
役割分担を定めたら、システム間の連携方法を要件として具体化します。連携はAPIで行うのか、CSVファイルの定期連携で行うのかを決めます。タイミングも、リアルタイムか日次バッチかを具体的に定めておく必要があります。
これらをRFPに明記しないと、ベンダーは自社に都合のよい前提で見積を作り、後から「リアルタイム連携は追加開発です」と言われかねません。連携部分はカスタマイズが必要になりやすく、費用と工期に影響します。連携は標準機能で吸収しきれないことが多く、その部分をフルスクラッチで作り込んだほうが、自社の業務に合うケースもあります。
RFPには、連携対象の既存システム名とバージョン、連携するデータ項目（BOM、品目マスター、図面、含有物質情報など）、連携方向（PLM→ERPか双方向か）を書き込みます。
- 連携の頻度：表にまとめてRFPに添付すると、提案の精度が上がります
- 標準機能で足りない連携：フルスクラッチで作り込む選択肢も検討する
あわせて、将来の拡張を見据えた要件も盛り込んでおくと安心です。今はPLMとEDM（図面管理）の範囲から始める場合でも、将来MESや品質管理システムと連携する構想があるなら、その拡張余地を要件に明記しておきます。
全機能を最初から盛り込むより、段階的に範囲を広げられる設計を求めるほうが、初期投資を抑えつつ将来の拡張に備えられます。さらに、RFPでは「今の要件」と「将来の構想」を分けて書くと、ベンダーが拡張性を考慮した提案をしやすくなります。
riplaは、こうした連携要件の整理から、現場の業務に合った設計を支援しています。
生産形態別の要件の出し分け
PLM要件で失敗がもっとも多いのは、自社の生産形態を要件に反映しきれないケースです。受注設計型（個別受注生産）と繰り返し量産型では、図面・BOMの扱い方も設計変更の頻度も大きく異なります。汎用的な要件のままRFPを出すと、生産形態に合わない製品を選んでしまい、後から大規模なカスタマイズが必要になります。
受注設計型・個別受注型の要件
受注設計型（顧客ごとに設計が変わる個別受注生産）では、案件ごとに図面とBOMが新規に発生し、過去設計をどれだけ流用できるかが効率を左右します。
この形態の要件では、「過去案件から似た設計を検索・流用できること」「案件単位で図面・BOMをひも付けて管理できること」「案件の途中で設計変更が頻発しても版管理が破綻しないこと」が重要になります。量産前提の製品をそのまま使うと、案件管理の柔軟性が足りず、現場で使えないケースが起こります。
RFPに「個別受注に対応できること」とだけ書くと、提案が玉虫色になります。受注設計特化を売りにする国内パッケージも存在するため、自社の生産形態を要件で明確に示すことが、適切な製品選定の前提になります。
- 規模の数字：年間の案件数、1案件あたりの図面枚数、流用率の目安を書くと、現実的な提案を得やすくなります
- 現場での確認：候補製品を実際の案件の流れに当てはめ、業務に合うかを確かめる
繰り返し量産型の要件
繰り返し量産型では、同じ製品を継続的に作るため、設計の安定性とBOMの正確な維持、設計変更時の影響範囲管理が要件の中心になります。
量産型の要件では、原価への影響も無視できません。設計変更がコストに直結するため、変更前後の原価差を試算できる機能や、ERPの原価管理との連携が要件に上がることがあります。
RFPでは、量産型か受注設計型か、あるいは両方が混在するのかを明示し、それぞれの要件を分けて書くことで、ミスマッチを防げます。生産形態の見極めこそ、PLM要件定義の核心と言えます。
- 変更の履歴管理：「いつ・誰が・なぜ変更したか」を長期保存し、過去の量産品の図面を参照できること
- 量産ラインへの伝達：E-BOMからM-BOMへの変換を安定して回し、設計変更を正確に届けること
AsIs／ToBe業務フローの要件への落とし込み
生産形態を要件に反映するうえで土台になるのが、現状（AsIs）と理想（ToBe）の業務フローの可視化です。この作業を省いて「機能要件」だけを並べたRFPを出すと、製品の機能と現場の実務がかみ合わず、稼働後に「使われないシステム」になります。
要件は、「現場のどの業務を、どう変えるためのものか」という文脈とセットで書きます。現場の業務から逆算した要件こそが、定着するPLMの設計図になります。
- 現場へのヒアリング：設計者・調達・製造・品質保証に、いまの図面の流れと、手戻りや待ちの起きている箇所を聞く
- 理想像の整理：PLM導入後の姿（ToBe）を描き、現状との差分を要件に落とし込む
riplaも要件整理では、まずこの確認から着手しています。
Excel連携・データ移行の要件
RFPで軽視されがちですが、導入後の満足度を左右するのが、Excel連携とデータ移行の要件です。
既存のExcel部品表や図面台帳をどう扱うか、過去の膨大なデータをどこまで移行するかを要件に落とし込まないと、稼働後に「既存資産が活かせない」「過去図面が見つからない」という不満が噴出します。
Excelダイレクト取込・出力の要件
「Excelを完全に脱却する」という理想を掲げるRFPは多いものの、現場の実態は異なります。設計部門のExcel部品表には独自のマクロやVLOOKUP、見やすいレイアウトが詰まっており、一気に廃止すると現場の生産性が落ちます。
CSV変換を挟むと、文字化けや列ズレで、かえって作業時間が増えます。RFPには、Excelとの連携を要件として明記することをおすすめします。
- 取込の方式：既存のExcel部品表を、CSV変換なしでダイレクトに取り込めること
- 出力の形式：PLMのBOMを、既存と同じExcelレイアウトで出力できること
この「Excel共存・段階移行」を要件に据えると、現場の反発を抑え、定着率を高められます。逆に、理想論で「全面脱Excel」を要件にすると、ベンダーは大規模な作り込みを提案し、費用が膨らんだあげく、現場が従来のExcelに戻ってしまうという本末転倒が起こりがちです。
riplaは、既存のExcel資産を活かしながらPLMと共存させる現実的な移行を一貫して重視しており、要件整理の段階からこの方針を反映します。
過去図面・マスターの移行範囲の要件
データ移行は、PLM導入で工数とリスクを見誤りやすい領域です。過去の全図面・全BOMを移行しようとすると、データ整備に膨大な工数がかかり、品質のばらつきも持ち込んでしまいます。
RFPでは、「どの範囲を移行し、どこから新規運用に切り替えるか」の方針を示すことが欠かせません。
- 移行対象の絞り込み：現行品と過去3年の図面のみ移行し、それ以前はアーカイブ参照にして移行コストを抑える
- 外注費の圧縮：マスター登録やデータ整備を自社で担い、外注すれば30〜80万円規模になる分を見積から外す
一方、品質保証協定書を紙23件・PDFやPC保存12件で持つといったアナログ実態（スパイラル社90社調査）がある企業では、移行前のデータ整備そのものに時間がかかります。移行範囲と分担をRFPで明確にすることが、工期遅延と費用膨張を防ぎます。
移行で見落とされがちなのが、データの「品質」です。過去のExcel部品表には、表記ゆれ（同じ部品が複数の名称で登録されている）や、廃番品の混在といった汚れが蓄積していることが少なくありません。
これをそのまま移行すると、せっかくのPLMに不整合を持ち込んでしまいます。RFPには、移行前のデータクレンジング（名寄せ・廃番整理）を誰がどこまで行うかを要件として記載しておくと、稼働後の「探したのに見つからない」「同じ部品が二重に出る」といったトラブルを未然に防げます。
補助金申請・内製化を見据えた要件整理
PLM導入は数百万〜数千万円規模の投資になるため、補助金活用と内製化によるコスト圧縮を、要件整理の段階から織り込むと費用負担を抑えられます。
RFPと要件定義を補助金申請の要件と整合させ、自社で巻き取れる作業を切り分けておくことが、賢い進め方です。
IT導入補助金に整合させる要件
PLMはIT導入補助金などの対象になり得ます。補助率は対象や年度で1/2〜2/3と変動するため、申請を見据えるなら、対象の条件を都度確認しておく必要があります。
補助金は年度ごとに要件やスケジュールが変わるため、申請可否を前提に計画を組むのではなく、「採択されれば自己負担が下がる」という位置づけで稟議を設計します。そうすると、予算のブレに振り回されずに済みます。
RFPには、補助金申請に必要な見積書の様式や、導入効果（生産性向上の数値目標）の記載を求める項目を入れておくと、申請時の資料作成がスムーズになります。
- 補助対象の区分：ソフトウェア費・導入支援費などの対象経費と対象外の経費を、要件・見積の段階で切り分ける
- 申請支援の経験：ベンダーの補助金申請の支援実績を、提案依頼の評価項目に加える
補助金を上手に組み込むことで、実質的な投資額を下げられます。補助金の対象要件は数値目標（労働生産性の向上率など）の達成を求めることが多いため、要件定義の段階でPLM導入による効果指標を設定しておくと、申請も導入後の効果測定も一貫します。
たとえば「図面検索・転記の事務工数を月◯時間削減」「設計リードタイムを◯%短縮」といった指標を、要件と稟議、ROI試算で同じ数字に揃えておきます。この整合が取れていれば、補助金申請も社内承認もスムーズに進みます。
内製化で巻き取る範囲を分離する要件
要件定義の段階で、「自社で巻き取れる作業」と「ベンダーに任せる作業」を分離しておくと、見積から不要な費目を外せます。たとえば、マスター登録は30〜80万円、現場教育は50〜100万円、テスト運用は30〜80万円の規模です。
また、帳票レイアウトのExcel出力設定（20〜60万円）は、製品と業務を知る自社メンバーが主導したほうが精度が高く、外注すると割高になりがちな領域です。さらに、導入前コンサル（1人月100〜200万円）を不要とすれば、合計で200〜400万円規模の削減も可能です。
- 自社分の明記：自社で実施する作業は、ベンダー側の作業範囲から外すと明記する
- 専門領域の担当：アーキテクチャ設計や連携開発などを、ベンダーに委ねる範囲として線引きする
この内製化と外注の切り分けこそ、品質を保ちながら導入費を圧縮する現実的な解です。riplaは、自社で巻き取るべき範囲とプロに任せるべき範囲を一緒に見極めながら、コストと品質を両立する要件整理を支援します。
PoC（実機検証）のRFPへの組み込み
要件定義の仕上げとして、RFPにPoC（実機検証）を条件として組み込むことを強くおすすめします。
本契約の前に、自社の生データで「典型的な受注パターンが企画から出図まで流れるか」「自社のデータ量で速度が落ちないか」「マニュアルなしで現場が触れるか」を検証する段階を設けるのです。これにより、カタログでは対応しているとされる機能が、自社の実環境で本当に動くかを契約前に確かめられます。
PoCを条件にすると、ベンダーも自社のデータで動く前提で提案せざるを得なくなり、提案の信頼性が上がります。数十万円規模のPoCで、リリース後に発覚する数百万円規模のカスタマイズ膨張を防げます。
RFPには、PoCの内容を具体的に書き込みましょう。
- 事前の取り決め：PoCで検証する範囲・期間と、合否判定の基準を決める
- 条件の明文化：合格を本契約の前提とすることを、RFPに盛り込む
要件定義とPoCをセットで設計することが、PLM導入の失敗リスクを最小化する王道です。
まとめ
PLMのRFP・要件定義で押さえるべき流れは、ISA-95を前提にERP/MESとの役割分担とBOMマスターの所在を定めることから始まります。そのうえで、自社の生産形態（受注設計型/量産型）に応じて要件を出し分け、Excelダイレクト連携とデータ移行範囲を明記します。最後に、補助金申請と内製化を見据えて作業範囲を切り分けます。
とくに「BOMマスターはどこが持つか」「自社は受注設計型か量産型か」「Excelをどう共存させるか」の3点は、提案の前提を揃え、後のカスタマイズ膨張を防ぐ最重要ポイントです。
要件定義で大切なのは、自社の業務と既存資産から逆算して「何を求めるか」を言語化することです。製品の機能を並べることは、その後の話です。
役割分担・生産形態・Excel共存・内製化という4つの軸で要件を固めてからRFPを出せば、提案の質と比較精度が変わり、導入後のギャップも防げます。
riplaはフルスクラッチ受託と国内開発の立場から、現場の業務を起点にした要件整理と、コストと品質を両立するPLM構築を一貫して支援します。
費用相場や全体像の確認には、あらためて完全ガイドをご活用ください。
▼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を創業。