PLMのRFP/要件定義書/提案依頼書について

PLM（製品ライフサイクル管理）の導入を成功させられるかどうかは、開発が始まる前の「要件定義」と「RFP（提案依頼書）」の出来でほぼ決まります。製品の良し悪しやベンダーの技術力よりも、自社が何を求めているかを正確に言語化できているかが、導入の成否を分けます。要件が曖昧なままRFPを出すと、ベンダーごとに前提の違う提案が集まって比較できず、開発に進んでからも仕様変更が連発し、カスタマイズ費が当初見積の倍近くに膨らみます。

本記事は、PLM導入のRFP・要件定義書・提案依頼書を、発注企業の視点から実務的にまとめる「要件定義特化」の解説です。ISA-95を前提とした既存システムとの役割分担、生産形態（受注設計型/繰り返し量産型/個別受注型）に応じた要件の出し分け、Excel連携やデータ移行の要件、補助金申請を見据えた要件整理まで、RFPに盛り込むべき観点を具体的に解説します。なお、PLMの全体像や費用相場をまだ把握していない方は、まずPLMの完全ガイドから読むことをおすすめします。要件を固めてからRFPを出せば、提案の質と比較精度が大きく変わります。

▼全体ガイドの記事
・PLMの完全ガイド

ISA-95を前提にした既存システムとの役割分担要件

PLMのRFPで最初に明確にすべきは、既存システムとの役割分担です。PLMは単独で完結するシステムではなく、ERP（基幹）やMES（製造実行）と連携して初めて効果を発揮します。役割分担を曖昧にしたままRFPを出すと、ベンダーによって「どこまでをPLMが担うか」の前提がずれ、提案を横並びで比較できなくなります。

製造業の情報システムは、ISA-95という国際標準の階層モデルで整理できます。ざっくり言えば、ERPが計画層（受注・調達・原価・在庫）、MESが実行層（製造指示・実績収集）を担い、PLMはそれらの上流にある「製品定義・設計情報・BOMの源泉」を担います。RFPでは、この三者のうち「自社では何をPLMに任せ、何を既存ERP/MESに残すのか」を明記する必要があります。たとえば、原価管理はERP側で行うのか、PLMで設計原価を試算するのか、といった線引きです。

この線引きが曖昧だと、機能の重複や、逆に「どちらも担当しない空白」が生まれます。BOMはPLMが正（マスター）を持ち、ERPはそれを受け取るのか、それとも双方で編集するのか。マスターの所在を一つに定めることが、データ整合性を保つ大原則です。RFPに「BOMマスターはPLMが保持し、ERPへは一方向で連携する」と明記するだけで、提案の前提が揃い、後の二重管理トラブルを防げます。役割分担は、PLM要件定義の出発点であり、ここを曖昧にしたまま先に進むと後工程のすべてが揺らぎます。

役割分担を定めたら、システム間の連携方法を要件として具体化します。連携をAPIで行うのか、CSVファイルの定期連携で行うのか、連携のタイミングはリアルタイムか日次バッチか。これらをRFPに明記しないと、ベンダーは自社の都合のよい前提で見積を作り、後から「リアルタイム連携は追加開発です」と言われかねません。連携部分はカスタマイズが必要になりやすく、費用と工期に大きく影響します。

RFPには、連携対象の既存システム名・バージョン、連携するデータ項目（BOM、品目マスター、図面、含有物質情報など）、連携方向（PLM→ERPか双方向か）、連携頻度を表形式で整理して添付すると、提案の精度が上がります。連携は標準機能で吸収しきれないことが多く、ここをフルスクラッチで作り込んだほうが自社業務に合うケースもあります。riplaはこうした連携要件の整理から、現場の業務に合った設計を支援しています。

あわせて、将来の拡張を見据えた要件も盛り込んでおくと安心です。今はPLMとEDM（図面管理）の範囲から始めるとしても、将来的にMESや品質管理システムと連携する構想があるなら、その拡張余地を要件に明記しておきます。最初から全機能を盛り込むのではなく、段階的に範囲を広げられる設計を求めることで、初期投資を抑えつつ将来の拡張に備えられます。RFPは「今の要件」と「将来の構想」を分けて記載すると、ベンダーが拡張性を考慮した提案をしやすくなります。

生産形態別の要件の出し分け

PLM要件で失敗がもっとも多いのが、自社の生産形態を要件に反映しきれないケースです。受注設計型（個別受注生産）と繰り返し量産型では、図面・BOMの扱い方も設計変更の頻度もまったく異なります。汎用的な要件のままRFPを出すと、自社の生産形態に合わない製品を選んでしまい、後から大規模なカスタマイズが必要になります。

受注設計型（顧客ごとに設計が変わる個別受注生産）では、案件ごとに図面とBOMが新規に発生し、過去設計の流用が効率を大きく左右します。この形態の要件では、「過去案件から似た設計を検索・流用できること」「案件単位で図面・BOMをひも付けて管理できること」「設計変更が案件途中で頻発しても版管理が破綻しないこと」が重要になります。量産前提の製品をそのまま使うと、案件管理の柔軟性が足りず、現場が使えないケースが起こります。

RFPには、自社の典型的な受注パターン（年間何案件、1案件あたりの図面枚数、流用率の目安など）を具体的に記載すると、ベンダーが現実的な提案をしやすくなります。抽象的な「個別受注に対応できること」では、提案が玉虫色になります。受注設計特化を売りにする国内パッケージも存在するため、自社の生産形態を要件で明確に示すことが、適切な製品選定の前提になります。

繰り返し量産型では、同じ製品を継続的に作るため、設計の安定性とBOMの正確な維持、設計変更時の影響範囲管理が要件の中心になります。一度確定した製品が長期間にわたって生産されるため、「いつ・誰が・なぜ変更したか」の履歴が長期保存され、過去の量産品の図面をいつでも参照できることが重要です。また、E-BOMからM-BOMへの変換を安定して回せること、設計変更が量産ラインへ正確に伝わることも欠かせません。

量産型の要件では、原価への影響も無視できません。設計変更がコストに直結するため、変更前後の原価差を試算できる機能や、ERPの原価管理との連携が要件に上がることがあります。RFPでは、自社が量産型なのか受注設計型なのか、あるいは両方が混在するのかを明示し、それぞれの要件を分けて記載することが、ミスマッチを防ぐ最大のポイントです。生産形態の見極めこそ、PLM要件定義の核心と言えます。

生産形態を要件に反映するうえで土台になるのが、現状（AsIs）と理想（ToBe）の業務フローの可視化です。設計者・調達・製造・品質保証といった関係者に「いま実際にどう図面を回し、どこで手戻りや待ちが発生しているか」をヒアリングし、現状の業務フローを描き出します。そのうえで、PLM導入後にどう変えたいか（ToBe）を設計し、両者の差分を要件に落とし込みます。

この一手間を省いて、いきなり「機能要件」だけを並べたRFPを出すと、製品の機能と現場の実務がかみ合わず、稼働後に「使われないシステム」になります。要件は機能の羅列ではなく、「現場のどの業務を、どう変えるためのものか」という文脈とセットで記述することが重要です。riplaが要件整理で最初に行うのも、この現場ヒアリングとAsIs/ToBeの可視化です。現場の業務から逆算した要件こそが、定着するPLMの設計図になります。

Excel連携・データ移行の要件

RFPで軽視されがちで、しかし導入後の満足度を大きく左右するのが、Excel連携とデータ移行の要件です。既存のExcel部品表や図面台帳をどう扱うか、過去の膨大なデータをどこまで移行するかを要件に落とし込まないと、稼働後に「既存資産が活かせない」「過去図面が見つからない」という不満が噴出します。

「Excelを完全に脱却する」という理想を掲げるRFPは多いですが、現場の実態は違います。設計部門のExcel部品表には独自のマクロやVLOOKUP、見やすいレイアウトが詰まっており、一気に廃止すると現場の生産性が落ちます。RFPには、「既存のExcel部品表をCSV変換なしでダイレクトに取り込めること」「PLMのBOMを既存と同じExcelレイアウトで出力できること」を要件として明記することをおすすめします。CSV変換を挟むと文字化けや列ズレで、かえって作業時間が増えます。

この「Excel共存・段階移行」を要件に据えることで、現場の反発を抑え、定着率を高められます。理想論で「全面脱Excel」を要件にすると、ベンダーは大規模な作り込みを提案し、費用が膨らんだ挙句、現場が従来のExcelに戻ってしまうという本末転倒が起こりがちです。riplaは、既存のExcel資産を活かしながらPLMと共存させる現実的な移行を一貫して重視しており、要件整理の段階からこの方針を反映します。

データ移行は、PLM導入で工数とリスクを見誤りやすい領域です。過去の全図面・全BOMを移行しようとすると、データ整備に膨大な工数がかかり、品質のばらつきも持ち込んでしまいます。RFPでは、「どの範囲を移行し、どこから新規運用に切り替えるか」の方針を示すことが重要です。たとえば「現行品と過去3年の図面のみ移行、それ以前はアーカイブ参照」といった現実的な線引きが、移行コストを抑えます。

あわせて、移行作業を誰が担うかも要件に含めるべきです。マスター登録やデータ整備を自社で巻き取れば（外注すれば30〜80万円規模）、その分を見積から除外でき、コストを抑えられます。一方、品質保証協定書を紙23件・PDFやPC保存12件で持つといったアナログ実態（スパイラル社90社調査）がある企業では、移行前のデータ整備そのものに時間がかかります。移行範囲と分担をRFPで明確にすることが、工期遅延と費用膨張を防ぎます。

移行で見落とされがちなのが、データの「品質」です。過去のExcel部品表には、表記ゆれ（同じ部品が複数の名称で登録されている）や、廃番品の混在といった汚れが蓄積していることが少なくありません。これをそのまま移行すると、せっかくのPLMに不整合を持ち込んでしまいます。RFPには、移行前のデータクレンジング（名寄せ・廃番整理）を誰がどこまで行うかを要件として記載しておくと、稼働後の「探したのに見つからない」「同じ部品が二重に出る」といったトラブルを未然に防げます。

補助金申請・内製化を見据えた要件整理

PLM導入は数百万〜数千万円規模の投資になるため、補助金活用と内製化によるコスト圧縮を、要件整理の段階から織り込むと費用負担を抑えられます。RFPと要件定義を、補助金申請の要件と整合させ、自社で巻き取れる作業を切り分けておくことが、賢い進め方です。

PLMはIT導入補助金などの対象になり得ます。補助率は対象や年度で1/2〜2/3と変動するため概要止まりにはなりますが、申請を見据えるなら、対象となる経費（ソフトウェア費・導入支援費など）と対象外の経費を要件・見積の段階で切り分けておく必要があります。補助金は要件・スケジュールが年度ごとに変わるため、申請可否を前提に計画を組むのではなく、「採択されれば自己負担が下がる」という位置づけで稟議を設計すると、予算ブレに振り回されずに済みます。

RFPには、補助金申請に必要な見積書の様式や、導入効果（生産性向上の数値目標）の記載を求める項目を入れておくと、申請時の資料作成がスムーズになります。ベンダーが補助金申請の支援実績を持つかも、提案依頼の評価項目に加えるとよいでしょう。補助金を上手に組み込むことで、実質的な投資額を下げられます。

なお、補助金の対象要件は数値目標（労働生産性の向上率など）の達成を求めることが多いため、要件定義の段階でPLM導入による効果指標を設定しておくと、申請も導入後の効果測定も一貫します。たとえば「図面検索・転記の事務工数を月◯時間削減」「設計リードタイムを◯%短縮」といった指標を、要件と稟議とROI試算で同じ数字に揃えておく。この整合が取れていると、補助金申請も社内承認もスムーズに進みます。

要件定義の段階で、「自社で巻き取れる作業」と「ベンダーに任せる作業」を分離しておくと、見積から不要な費目を外せます。マスター登録（30〜80万円）、現場教育（50〜100万円）、テスト運用（30〜80万円）、帳票レイアウトのExcel出力設定（20〜60万円）は、製品と業務を知る自社メンバーが主導したほうが精度が高く、外注すると割高になりがちな領域です。さらに導入前コンサル（1人月100〜200万円）を不要とすれば、合計で200〜400万円規模の削減も可能です。

RFPでは、「これらの作業は自社で実施するため、ベンダー側の作業範囲から除外する」と明記します。逆に、システムのアーキテクチャ設計や連携開発といった専門領域はベンダーに委ね、役割を線引きします。この内製化と外注の切り分けこそ、品質を保ちながら導入費を圧縮する現実的な解です。riplaは、自社で巻き取るべき範囲とプロに任せるべき範囲を一緒に見極めながら、コストと品質を両立する要件整理を支援します。

要件定義の仕上げとして、RFPにPoC（実機検証）を条件として組み込むことを強くおすすめします。本契約の前に、自社の生データで「典型的な受注パターンが企画から出図まで流れるか」「自社のデータ量で速度が落ちないか」「マニュアルなしで現場が触れるか」を検証する段階を設けるのです。これにより、カタログでは対応しているとされる機能が、自社の実環境で本当に動くかを契約前に確かめられます。

PoCを条件にすると、ベンダーも自社のデータで動く前提で提案せざるを得なくなり、提案の信頼性が上がります。数十万円規模のPoC投資が、リリース後に発覚する数百万円規模のカスタマイズ膨張を防ぐ保険になります。RFPには、PoCの実施範囲・期間・合否判定基準を明記し、合格を本契約の前提とする旨を盛り込みましょう。要件定義とPoCをセットで設計することが、PLM導入の失敗リスクを最小化する王道です。

まとめ

PLMのRFP・要件定義で押さえるべき観点を整理すると、ISA-95を前提にERP/MESとの役割分担とBOMマスターの所在を定め、自社の生産形態（受注設計型/量産型）に応じて要件を出し分け、Excelダイレクト連携とデータ移行範囲を明記し、補助金申請と内製化を見据えて作業範囲を切り分ける、という流れになります。とくに「BOMマスターはどこが持つか」「自社は受注設計型か量産型か」「Excelをどう共存させるか」の3点は、提案の前提を揃え、後のカスタマイズ膨張を防ぐ最重要ポイントです。

要件定義で大切なのは、製品の機能を並べることではなく、自社の業務と既存資産から逆算して「何を求めるか」を言語化することです。役割分担・生産形態・Excel共存・内製化という4つの軸で要件を固めてからRFPを出せば、提案の質と比較精度が大きく変わり、導入後のギャップも防げます。riplaはフルスクラッチ受託と国内開発の立場から、現場の業務を起点にした要件整理と、コストと品質を両立するPLM構築を一貫して支援します。費用相場や全体像の確認には、あらためて完全ガイドをご活用ください。

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