商品情報管理システム（PIM）の開発をベンダーに依頼するとき、成否を最初に左右するのがRFP（提案依頼書）と要件定義書の質です。どれだけ優れた開発会社に依頼しても、自社が何を求めているかを正確に言語化できていなければ、提案は的外れになり、見積もりも比較できず、完成したシステムは現場に合わないものになります。PIMは商品情報という業務の根幹を扱うだけに、要件の曖昧さがそのまま全チャネルの混乱につながります。
本記事は、商品情報管理システム（PIM）のRFP・要件定義書・提案依頼書を、発注企業の視点から「どう書けばよいか」に絞って解説する要件定義特化の記事です。現状業務（As-Is）の棚卸しから、商品コード・マスタの名寄せ要件、例外処理の3分類、OMO・基幹連携のアーキテクチャ要件、そしてRFPに盛り込むべき項目まで、具体的に掘り下げます。なお、PIM導入の全体像をまだ把握していない方は、まず商品情報管理システム（PIM）の完全ガイドから読むことをおすすめします。要件定義は、機能を並べる作業ではなく、業務を言語化する作業です。
▼全体ガイドの記事
・商品情報管理システム（PIM）の完全ガイド
現状業務（As-Is）を棚卸しする要件定義の起点
PIMの要件定義は、新しいシステムの機能を考えることから始めるべきではありません。まず行うべきは、現状の商品情報がどこに、どんな形で、誰によって管理されているかを徹底的に棚卸しすることです。Excelファイル、各部門の台帳、ECの管理画面、基幹システムのマスタといった商品情報の所在をすべて洗い出し、それらの間でどうデータが受け渡されているかを可視化します。この現状把握が、要件定義の土台になります。
関係部門へのヒアリングで業務フローを可視化する
現状把握の中心は、関係部門へのヒアリングです。商品情報は、商品企画、EC運営、卸営業、店舗、物流、経理といった複数の部門が、それぞれの目的で利用しています。各部門が「どんな商品情報を、いつ、どう使っているか」「どこに無駄や手戻りがあるか」を細かく聞き取り、現状の業務フロー（As-Is）を図に落とし込みます。このヒアリングを省くと、特定部門の都合だけで設計されたシステムができ上がり、他部門で使われなくなります。
リサーチでも、導入失敗の主因として要件定義不足と現場の巻き込み不足が繰り返し指摘されています。As-Isの業務フローを棚卸しし、現場を巻き込んで「あるべき姿（To-Be）」を描くことが、PIMが定着するかどうかを分けます。要件定義書には、この現状フローと改善後のフローを明記し、なぜそのシステムが必要なのかという背景まで含めることが望ましいです。背景を共有することで、ベンダーは表面的な機能ではなく業務課題に即した提案ができるようになります。
導入目的とスコープを最初に定義する
要件定義書の冒頭で必ず明確にすべきが、導入の目的とスコープです。商品登録工数の削減なのか、OMOの在庫一元化なのか、越境ECへの多言語配信なのか、目的によって優先すべき機能はまったく変わります。目的が曖昧なまま「とにかく商品情報を一元化したい」と書くと、ベンダーは何を提案すべきか判断できず、過剰または不足した見積もりが返ってきます。
あわせて、今回のプロジェクトで対象とする範囲（スコープ）と、対象外とする範囲を明示します。たとえば「今回は自社ECとモールへの配信を対象とし、紙カタログは次フェーズ」「在庫連携は対象だが、会計連携は現行のまま」というように線引きします。スコープを最初に固めることで、開発途中の要件膨張を防ぎ、見積もりとスケジュールの精度が上がります。目的とスコープの定義は、要件定義書のすべての判断の基準になります。
スコープを決める際は、フェーズ分割の可否も検討します。すべてを一度に作ろうとすると、開発期間が長くなり、リスクも費用も膨らみます。まず効果の大きい領域から着手し、段階的に範囲を広げる計画にすれば、早期に成果を出しながら、現場の反応を見て次の要件を磨けます。要件定義書には、第1フェーズの範囲と、将来フェーズに回す範囲を明記しておくと、ベンダーも現実的な提案がしやすくなります。
商品コード・マスタの名寄せ要件を定義する
PIMの要件定義で最大の関門になるのが、商品コードとマスタの名寄せです。リサーチでも、取引先や商品コード（SKU）体系の名寄せが基幹連携の最大の関門であり、連携要件の整理だけで数週間を要すると指摘されています。複数のシステムで別々のコードが振られている商品を、どう一意に対応づけるかを要件として定義しなければ、一元管理は成立しません。ここを曖昧にしたまま開発に進むと、後で必ず破綻します。
SKU体系・JAN・インストアコードの設計要件
商品コード設計の要件では、SKUを基準にJANコードやインストアコードをどう付与するかの規則性を定めます。リサーチでも、SKU基準でJAN/インストアコードを規則的に付与することの重要性が指摘されています。同じ商品にサイズやカラーのバリエーションがある場合、どの単位でSKUを切るか、親商品と子商品の関係をどう表現するかを、要件定義の段階で決めておく必要があります。この設計が後の在庫連携や配信の精度を左右します。
既存システムにすでにコード体系がある場合は、新しいPIMでそれを踏襲するのか、この機会に再設計するのかも要件として明記します。再設計する場合は、旧コードと新コードの対応表（変換マップ）をどう作るかまで含めて定義する必要があります。要件定義書に「商品コードの設計方針」と「既存コードからの移行ルール」を明確に書くことで、ベンダーは移行作業の工数を正確に見積もれます。コード設計は地味ですが、PIMプロジェクト全体の精度を決める要です。
データクレンジングと移行の要件を明記する
名寄せと並んで重要なのが、データクレンジングと移行の要件です。リサーチでも、データ移行前のクレンジングの重要性が強調されています。長年のExcel運用で蓄積した重複登録、表記ゆれ、廃番商品の残存といった乱れを、移行前にどう整えるかを要件として定義します。誰が、どの基準で、いつまでにクレンジングを行うのかを明記しないと、移行直前にデータの汚さが発覚してプロジェクトが遅延します。
要件定義書には、移行対象のデータ件数、データの現在の品質状態、クレンジングの責任分担（自社が行うのか、ベンダーが支援するのか）を盛り込みます。リサーチでは在庫管理システム導入企業の約75%が不満を抱えているとされ、その一因にデータ品質の問題があります。移行とクレンジングを軽視すると、せっかくのPIMが汚れたデータの一元管理になりかねません。移行要件を曖昧にしないことが、運用開始後のトラブルを防ぐ最大の保険です。
例外処理を3分類で定義する要件整理
要件定義で見落とされがちなのが、例外処理の扱いです。定型的な業務フロー（商品登録→承認→配信）は誰でも要件化できますが、実際の現場には、定型に収まらない例外が数多く存在します。リサーチでも、返品・値引・バックオーダー・分納といった例外処理の扱いが、システム導入の成否を分ける論点として挙げられています。商品情報管理でも、限定品や受注生産品、セット商品といった例外的な商品の扱いを要件として整理する必要があります。
自動化・手動・運用ルールの3つに仕分ける
例外処理を要件化する有効な手法が、3分類への仕分けです。リサーチが示すように、例外的な処理を「システムで自動化する」「システムで手動入力できるようにする」「システム外の運用ルールで対応する」の3つに分類します。すべての例外を自動化しようとすると開発費が膨らみ、逆にすべてを運用でカバーしようとすると現場が疲弊します。どの例外をどの方法で扱うかを意思決定することが、コストと現場負荷のバランスを取る要件整理の核心です。
たとえば、頻度が高く定型化できる例外は自動化の対象とし、頻度は低いが必ず発生する例外は手動入力で対応できるようにし、ごく稀で例外中の例外は運用ルールで個別対応する、という整理ができます。この3分類を要件定義書に明記しておくと、ベンダーは開発範囲を正確に把握でき、見積もりのブレが小さくなります。例外処理を「とりあえず全部システムで」と曖昧に書くと、開発費が想定外に膨らむ典型的な失敗につながります。例外こそ、最初に仕分けるべき要件です。
インボイス・法制度対応の数値要件を盛り込む
商品情報・価格に関わる法制度対応も、要件として明記すべき項目です。リサーチでは、インボイス制度、電子帳簿保存法、軽減税率への対応が論点として挙げられています。商品ごとに適用される税率（標準税率か軽減税率か）をマスタで管理し、価格表示や請求の連携先に正しく渡せる要件を定義します。とくに飲食料品や定期購読など、軽減税率の対象となる商材を扱う企業では、税率の区分を商品属性として持つことが必須です。
あわせて、返品や値引が発生した際の適格返還請求書の消費税処理など、例外的な税務処理にどう対応するかも、連携先システムとの責任分界を含めて要件化します。これらの法制度対応は「対応済み」という単語だけで済ませず、自社の商材と取引形態に即して、具体的にどの数値・どの区分を管理する必要があるかまで踏み込んで書くことが大切です。法制度の要件を曖昧にすると、運用開始後に税務処理で手戻りが発生し、現場の信頼を損ないます。
RFP（提案依頼書）に盛り込むべき項目
要件定義の内容を、ベンダーに正しく伝えるための文書がRFP（提案依頼書）です。RFPは、各社から比較可能な提案と見積もりを引き出すための共通の土台になります。RFPの記載が曖昧だと、各社がバラバラの前提で提案してきて比較ができず、選定が難航します。逆に、押さえるべき項目を漏れなく盛り込めば、提案の質が揃い、自社に最適なパートナーを選びやすくなります。
背景・機能要件・連携要件・非機能要件を記載する
RFPに必須の項目は、まず導入の背景と目的、現状の課題です。これを冒頭に置くことで、ベンダーは機能の羅列ではなく課題解決の提案ができます。次に機能要件として、商品マスタ管理、配信、ワークフロー、品質管理など、どの機能が必須でどれが任意かを区分して記載します。MoSCoW（必須・推奨・任意・対象外）のように優先度を付けると、ベンダーは取捨選択しやすくなります。
さらに重要なのが連携要件です。連携先のシステム名、連携するデータ、連携の方向と頻度を具体的に書きます。リサーチが指摘するSKU名寄せや後付け連動の隠れコストを避けるには、連携要件をRFPで詳細に示すことが欠かせません。加えて、性能・セキュリティ・可用性・サポート体制といった非機能要件も明記します。リサーチでも、トラブル時に業務を停止させないサポート体制が選定基準として重視されており、365日サポートの有無や費用をRFPで問うことが推奨されます。
予算・スケジュール・評価基準を提示する
RFPには、予算感とスケジュール、提案の評価基準も盛り込みます。予算をまったく示さないと、各社が想定する規模感がばらつき、比較が難しくなります。リサーチによれば、PIMを含むシステムの相場はクラウド初期0〜10万円・月3,000〜70,000円、セミオーダー100万円以上、フルスクラッチ500万〜数千万円と幅広く、どの規模を想定するかを示すことで提案の方向性が定まります。希望の稼働時期や、フェーズ分割の可否も明記します。
提案の評価基準を事前に示すことも有効です。機能適合度、連携実績、費用、サポート体制、開発体制のうち、自社が何を重視するかを伝えれば、ベンダーはそこに焦点を当てた提案をしてきます。リサーチでは、コンサルを活用した場合のERP導入成功率が85%に達するとされており、要件整理から伴走できるパートナーかどうかも評価軸になります。riplaはフルスクラッチ受託と国内開発の立場から、RFP作成段階での要件整理から伴走し、発注側が比較可能な提案を引き出せるよう支援しています。RFPは丸投げの道具ではなく、自社の意思を言語化する道具です。
非機能要件と運用・保守の要件を定義する
要件定義というと機能の話に注目が集まりがちですが、システムの安定運用を左右するのは非機能要件です。性能、可用性、セキュリティ、保守体制といった要件を曖昧にしたまま開発を進めると、リリース後に「動きが遅い」「障害時に業務が止まる」といった問題に直面します。商品情報は全チャネルの起点になるだけに、止まらない・遅くならないことが事業継続に直結します。非機能要件こそ、要件定義書で具体的な数値とともに定めるべき領域です。
性能・可用性・セキュリティの数値要件
非機能要件のうち、まず性能を数値で定義します。商品数が増えても検索や一括更新が一定の速度で応答すること、ピーク時のチャネル配信が滞らないことを、具体的な目標値として書きます。「快適に動くこと」といった曖昧な表現では、ベンダーは設計の基準を持てません。想定する商品数、同時利用者数、配信先の数を前提条件として示し、それに耐える性能を求めることが要件定義の役割です。
あわせて、可用性とセキュリティの要件も定めます。商品情報が止まると配信先すべてに影響するため、どの程度の稼働率を求めるか、障害時にどれだけの時間で復旧すべきかを明記します。セキュリティでは、価格や原価といった機密情報へのアクセス制御、操作ログの保全、外部連携時のデータ保護を要件化します。リサーチでも、トラブル時に業務を停止させないことが選定基準として重視されており、可用性とセキュリティの要件は、商品情報という基幹データを守るうえで欠かせません。
保守・サポート体制と将来拡張の要件
運用開始後を見据えた保守・サポート体制の要件も、要件定義書に盛り込みます。障害発生時の連絡経路と対応時間、平日のみか365日対応か、問い合わせの窓口とエスカレーションの仕組みを定めます。リサーチでも、トラブル時に業務を停止させないサポート体制が選定基準として挙げられており、サポートの範囲と費用を要件として明確にすることで、運用フェーズでの不安を減らせます。保守費用は導入後に継続的に発生するため、TCOの一部として早めに見積もる必要があります。
さらに、将来の拡張性も要件として書いておくと安心です。チャネルの追加、多言語・多通貨対応、商品数の増加、新しい基幹システムとの連携といった将来の変化に、システムがどこまで対応できるかを要件化します。今は不要でも、事業拡大の局面で「このシステムでは対応できない」と判明すると、再構築の大きなコストが発生します。riplaはフルスクラッチ受託と国内開発の立場から、機能要件だけでなく非機能・保守・拡張の要件まで含めて整理し、長く使えるPIMの要件定義を支援しています。要件定義は、目先の機能だけでなく、運用と将来までを見通す作業です。
まとめ
商品情報管理システム（PIM）の要件定義とRFPは、機能を並べる作業ではなく、自社の業務を言語化する作業です。現状業務（As-Is）の棚卸しと関係部門のヒアリングから始め、目的とスコープを定め、商品コード・マスタの名寄せとデータクレンジングの要件を固める。例外処理は自動化・手動・運用ルールの3分類で仕分け、インボイスなど法制度の数値要件も明記する。これらを背景・機能・連携・非機能の各要件としてRFPにまとめることで、比較可能な提案を引き出せます。
とくに名寄せと例外処理、連携要件の3点は、曖昧にすると開発費の膨張や運用開始後のトラブルに直結します。リサーチが示すERP導入の75%が失敗を経験する一方で、コンサル活用時は85%が成功するという数字は、要件整理に専門家を交える価値を物語っています。riplaはフルスクラッチ受託と国内開発を組み合わせ、要件定義とRFP作成から伴走し、現場に定着するPIMづくりを支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社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を創業。