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