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