商品管理システムの開発・導入で成否を分ける最大の工程が、要件定義です。どれほど優れたパッケージやベンダーを選んでも、自社の業務要件が正確に言語化されていなければ、できあがるのは現場に合わないシステムです。とくに商品管理は、定型的な入出庫だけでなく、返品・値引・バックオーダー・分納といった例外処理が業務の3〜4割を占めることもあり、この例外をどう要件に落とし込むかが難所になります。RFP（提案依頼書）の質が、見積もりの精度とベンダー選定の成否を直接左右します。
本記事は、商品管理システムのRFP・要件定義書・提案依頼書の作り方を、発注企業の視点から実務的に解説する「要件定義特化」の内容です。As-Is業務フローの棚卸しから、例外処理を「自動化・手動・運用ルール」の3つに仕分ける要件定義ノウハウ、商品コード（SKU）・取引先コードの名寄せ要件、OMO・EC連携のアーキテクチャ要件、インボイス・電帳法の数値要件まで、RFPに盛り込むべき項目を具体的に示します。読み終えるころには、ベンダーが正確に見積もれるRFPの骨格が描けるはずです。なお、商品管理システムの全体像をまだ把握していない方は、まず商品管理システムの完全ガイドから読むことをおすすめします。
▼全体ガイドの記事
・商品管理システムの完全ガイド
As-Is業務フローの棚卸しと要件の起点
要件定義は、いきなり「欲しい機能」を並べることから始めてはいけません。出発点は、現状（As-Is）の業務フローを正確に棚卸しすることです。商品の入荷から保管、受注、出荷、請求、棚卸までの一連の流れを、誰が・いつ・何を使って処理しているかという粒度で可視化します。この棚卸しを飛ばして理想だけを語ると、現場の実態と乖離したシステムになり、導入後にExcel運用へ逆戻りする典型的な失敗を招きます。
現状業務の可視化とヒアリングの進め方
As-Is業務フローの棚卸しでは、受注担当・倉庫・営業・経理といった関係者全員にヒアリングを行います。ポイントは、マニュアルに書かれた建前のフローではなく、現場が実際にどう処理しているかという本音のフローを引き出すことです。「マニュアル上はこうだが、実際は担当者の判断でこう処理している」という暗黙の運用こそが、要件定義で押さえるべき重要な情報になります。ここを取りこぼすと、システム化後に「これでは仕事にならない」という反発が起きます。
ヒアリングで集めた情報は、業務フロー図や業務一覧表として文書化します。各業務について、入力（インプット）・処理・出力（アウトプット）・関係者・使用システムを整理すると、どこに無駄や手戻り、属人化があるかが見えてきます。ERP導入の75%が進行中に何らかの失敗を経験するという調査もありますが、その多くは現状業務の理解不足が遠因です。As-Isの可視化は地味な作業ですが、ここに時間をかけることが、結果的に手戻りを減らし、総コストを下げる最も確実な投資になります。
ToBe設計とスコープ確定の考え方
As-Isを可視化したら、次にあるべき業務の姿（ToBe）を設計します。現状の無駄や手戻りを、システム化によってどう解消するかを描くわけです。ここで重要なのは、現状のフローをそのままシステムに置き換えるのではなく、業務そのものを見直す視点を持つことです。長年続けてきた手作業の中には、システム化を機に廃止できるものや、簡素化できるものが必ず含まれています。
あわせて、今回のシステム化で対応する範囲（スコープ）を明確に確定させます。すべてを一度にシステム化しようとすると、開発期間が長期化し、費用も膨らみ、リスクが高まります。優先度の高い業務から段階的に進めるフェーズ分けを行い、第1フェーズで何を実現し、第2フェーズ以降に何を回すかをRFPに明記します。スコープが曖昧なRFPは、ベンダーの見積もりをぶれさせ、後の追加費用トラブルの温床になります。スコープの線引きこそ、要件定義の最重要判断だと言えます。
例外処理を3分類で仕分ける要件定義
商品管理システムの要件定義で最も差がつくのが、例外処理の扱いです。定型的な入出庫フローは誰でも要件にできますが、返品・値引・バックオーダー（取り寄せ）・分納といった例外は、業務の3〜4割を占めることもありながら、要件定義で見落とされがちです。ここを曖昧にしたまま開発に進むと、現場は例外をシステムで処理できず、Excelや手作業に逃げ、システムの在庫データが信頼できなくなります。例外処理の仕分けこそ、商品管理の要件定義の真価が問われる部分です。
自動化・手動・運用ルールの3分類基準
例外処理は、すべてをシステムで自動化しようとすると開発費が膨らみ、現実的ではありません。そこで有効なのが、洗い出した例外を3つに仕分けるアプローチです。すなわち「システムで自動化する」「システムの画面から手動で処理する」「システム外の運用ルールで対応する」の3分類です。発生頻度が高く影響の大きい例外は自動化し、頻度は低いが必要な例外は手動処理の画面を用意し、ごく稀な例外は運用ルールで対応する、という現実的な落としどころを決めます。
この3分類を行うには、各例外の発生頻度と業務インパクトを定量的に把握する必要があります。「返品は月に何件あるか」「分納はどの取引先で発生するか」といったデータを集め、自動化する価値があるかを判断します。すべてを自動化する豪華なシステムは、費用に見合わないことが多いものです。逆に必要な例外を運用ルール任せにしすぎると、属人化やミスが残ります。この線引きを要件定義書に明記することで、ベンダーは正確に開発範囲を見積もれるようになります。
情物一致と例外処理の境界を要件化する
商品管理の根幹にあるのが、情物一致（システム上の在庫情報と現物の在庫が一致している状態）です。例外処理がきちんと要件化されていないと、この情物一致が崩れます。たとえば返品された商品をシステムに戻し忘れる、分納の途中経過を記録しない、といった抜けがあると、システムの在庫数と実際の在庫数がずれていきます。要件定義では、どの例外がどのタイミングで在庫数に反映されるかを、漏れなく定義しなければなりません。
とくにバックオーダーや分納は、情物一致を崩しやすい代表例です。受注したが在庫がない商品を取り寄せる、一度の受注を複数回に分けて納品する、といったケースでは、引当・出荷・在庫の状態を細かく管理しなければ、二重出荷や在庫の二重計上が起きます。要件定義書には、こうした例外時の在庫の状態遷移をシナリオとして明記し、ベンダーと認識を合わせておくことが不可欠です。情物一致を保つための例外処理の境界設計が、運用後の在庫精度を決定づけます。
マスタ名寄せとコード設計の要件
商品管理システムの要件定義で、技術以上に時間と労力を要するのがマスタデータの整備です。とりわけ商品コード（SKU）と取引先コードの名寄せは、連携や移行の成否を左右する最大の関門です。複数のシステムや拠点で別々のコードが使われている状態を放置したまま開発に進むと、後から数字が合わない、連携できないといった問題が噴出します。コード設計とデータクレンジングを要件定義の正式な作業項目として位置づけることが重要です。
SKU・商品コード体系の設計要件
商品コード（SKU）の設計は、商品管理システムの土台です。要件定義では、SKUの命名規則、JANコードやインストアコードとの対応、規格・サイズ・カラーといったバリエーションのコード化方針を明確に定めます。コードに意味を持たせる（カテゴリや産地を桁で表す）か、連番にするかといった設計方針は、後々の検索性や拡張性に影響します。新商品が増えても破綻しない、規則性のあるコード体系を設計しておくことが、長く使えるシステムの前提になります。
既存システムからの移行を伴う場合は、旧コードと新コードの対応表を作る作業も要件に含めます。複数システムで別々に付与されていた同一商品のコードを一つに統一する名寄せ作業は、SKUの数が多いほど膨大になります。この名寄せだけで数週間を要することも珍しくなく、要件定義の段階で工数を見込んでおかないと、プロジェクト全体のスケジュールが狂います。RFPには、データ移行とコード名寄せの責任分担と工数を明記し、誰がどこまでクレンジングを担うかを合意しておくことが大切です。
OMO・EC連携アーキテクチャの要件
実店舗とECを併用する企業では、在庫一元化のアーキテクチャを要件として明確に定義する必要があります。POSとECの在庫をどのタイミングで同期するか（リアルタイムか、バッチか）、在庫の正データをどのシステムに置くか、店舗注文をECで受け取るといったOMO特有の動線をどう実現するか。これらを要件として詰めておかないと、リリース後に在庫同期のタイムラグによる売り越しが発生します。
連携アーキテクチャの要件化では、「どのシステムが在庫の唯一の正データを持つか」を最初に決めることが肝心です。商品管理システムを在庫の正データとし、POSもECもそこを参照・更新する構成にすれば、在庫の二重計上を防げます。あわせて、連携の方式（API・CSV・EDI）、連携の頻度、障害時の挙動（連携が止まったときどうするか）まで要件に含めると、ベンダーは堅牢な設計を提案できます。「API連携可」という一言で済ませず、アーキテクチャレベルで要件を言語化することが、OMO在庫一元化の成否を分けます。
インボイス・電帳法の数値要件とRFPの完成
商品管理システムが扱う売上・請求データは、税法・会計制度に直結します。インボイス制度（適格請求書等保存方式）と電子帳簿保存法（電帳法）への対応は、要件定義で曖昧な表現を避け、具体的な数値・条件として落とし込むべき領域です。「法対応済み」という抽象的な言葉で要件を済ませると、返品時の処理や保存要件の細部でミスマッチが生じ、運用後に手作業の補正が必要になります。
適格返還請求書・軽減税率の数値要件
インボイス対応の要件は、適格請求書に登録番号・税率ごとの消費税額・適用税率を記載できることを基本とし、それに加えて返品・値引時の適格返還請求書を正しく発行できることまで含めて定義します。返品時に消費税をどう戻すか、複数税率が混在する取引でどう区分集計するかを、具体的な処理ルールとして要件化します。軽減税率（8%）と標準税率（10%）が混在する場合は、商品マスタの税率区分の持ち方まで踏み込んで要件を書くべきです。
電帳法への対応では、電子取引データの保存形式、検索要件（取引年月日・取引金額・取引先での検索が可能なこと）、タイムスタンプや訂正削除の履歴管理といった具体的な要件を明記します。これらは「対応している」かどうかではなく、自社の取引形態において法的要件を満たす保存・検索が実現できるかという観点で詰める必要があります。税務・会計の制度要件は、後から「実は満たせていなかった」では済まされないため、要件定義の段階で社内の経理・税務担当を巻き込み、数値・条件レベルで合意することが欠かせません。
RFP・提案依頼書に盛り込む構成項目
ここまで整理した内容を、ベンダーが正確に見積もれる形でRFP（提案依頼書）にまとめます。RFPには、プロジェクトの目的・背景、対象業務とスコープ、機能要件（標準機能と個別要件）、非機能要件（性能・可用性・セキュリティ）、データ移行・連携要件、例外処理の3分類一覧、法対応要件、想定スケジュールと予算感、ベンダーへの評価基準を盛り込みます。これらを網羅することで、各ベンダーから比較可能な提案を引き出せます。
RFPの質は、見積もりの精度に直結します。要件が曖昧だと、ベンダーはリスクを見込んで高めに見積もるか、安く見積もって後から追加費用を請求します。クラウド型なら初期0〜10万円・月額数千〜数万円、セミオーダーなら100万円以上、フルスクラッチなら500万円から数千万円という相場感を踏まえ、自社の要件がどの規模に当たるかをRFPの段階で見極めることが大切です。精緻なRFPは、適正な見積もりと、現場に合うシステムを引き寄せる最良の投資だと言えます。
非機能要件と体制・サポートの要件化
要件定義というと機能要件に目が向きがちですが、商品管理システムは業務を止められない基幹システムであるため、非機能要件と運用・保守体制の要件化も同じくらい重要です。機能が揃っていても、ピーク時に動作が遅い、障害時に長時間業務が止まる、といった状態では業務に使えません。RFPでは、性能・可用性・サポート体制についても具体的な水準を要件として示すべきです。
性能・可用性・セキュリティの非機能要件
非機能要件では、まず性能を数値で定義します。同時アクセスするユーザー数、ピーク時の受注件数、在庫照会のレスポンス時間など、自社の業務量を踏まえた目標値を示します。月末・期末や繁忙期に処理が集中しても耐えられる性能であることを、具体的な数字で要件化します。あわせて、棚卸しや夜間バッチといった重い処理が、日中の業務に影響しないことも要件に含めます。
可用性については、システムが停止した場合に業務がどれだけ止まるかを想定し、許容できる停止時間や復旧目標を定めます。受発注を止められない事業では、可用性の要件が投資判断の重要な軸になります。セキュリティ面では、原価や取引先別価格といった機微なデータへのアクセス制御、通信の暗号化、データのバックアップ方針などを要件化します。これらの非機能要件を曖昧にすると、後から「想定していた性能が出ない」「セキュリティが不十分だった」という深刻な問題に発展します。
導入後のサポート・保守体制の要件
システムは導入して終わりではなく、運用してからが本番です。RFPには、導入後のサポート・保守体制についても要件を盛り込みます。トラブル発生時の問い合わせ窓口、対応時間帯、障害時の駆けつけや復旧の体制、法改正への対応方針などを明確にします。とくに受発注を止められない事業では、業務時間中にトラブルが起きてもすぐに連絡が取れ、迅速に対応してもらえる体制があるかが、選定の決め手になります。
あわせて、要件定義から運用までを通じて、発注側・ベンダー側それぞれの役割分担と体制も明文化しておくべきです。発注側の窓口担当、意思決定者、現場の検証担当を誰にするかを決め、ベンダー側のプロジェクト体制と合わせて整理します。導入後の保守費用や追加開発の単価感もRFPで確認しておくと、トータルコスト（TCO）を見誤りません。機能要件だけでなく、こうした非機能・体制・サポートまで含めて要件化することが、長く安定して使えるシステムを実現する条件です。
まとめ
商品管理システムの要件定義・RFPは、As-Is業務フローの棚卸しから始まり、例外処理の3分類（自動化・手動・運用ルール）、SKU・取引先コードの名寄せとコード設計、OMO・EC連携アーキテクチャ、インボイス・電帳法の数値要件という順で固めていきます。とくに商品管理特有の難所は、業務の3〜4割を占める例外処理と、情物一致を保つための在庫の状態遷移設計、そしてマスタ名寄せにあります。これらを曖昧にしたまま開発に進むことが、現場非定着とExcel回帰という最も多い失敗の根本原因です。
RFPの質が、見積もりの精度とベンダー選定の成否を決めます。要件を数値・条件レベルまで言語化し、スコープと責任分担を明確にすることで、適正な提案と現場に合うシステムを引き寄せられます。riplaはフルスクラッチ受託と国内開発の立場から、現場の業務と例外処理から逆算した要件定義と、精緻なRFP作成の支援を得意としています。要件定義の前提となる全体像を確認したい場合は、完全ガイドもあわせてご活用ください。
株式会社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を創業。