販売管理システムの開発をベンダーに依頼するとき、成否を最初に決めるのが「RFP（提案依頼書）と要件定義をどこまで具体的に詰められるか」です。受注・出荷・在庫・請求という基幹業務を扱う販売管理は、現場ごとに例外処理が多く、要件を曖昧にしたまま開発を進めると、リリース後に「現場の業務に合わない」「想定外の追加費用がかかった」というトラブルに直結します。だからこそ、RFP・要件定義書の作り込みが、投資の無駄を防ぐ最大の防御策になります。
本記事は、販売管理システムのRFP・要件定義書・提案依頼書の作り方を、発注企業の視点から解説する「要件定義特化」の記事です。返品・値引・バックオーダー・分納といった例外処理の3分類、取引先・商品コードのマスタ名寄せ要件、OMO・EC連携のアーキテクチャ要件、インボイス・電帳法の数値要件まで、一次データの知見を交えて具体的に整理します。読み終えるころには、ベンダーに渡すRFPに「何を、どの粒度で書くべきか」が明確になるはずです。なお、販売管理システムの費用相場や導入形態の全体像をまだ把握していない方は、まず販売管理システムの完全ガイドから読むことをおすすめします。
▼全体ガイドの記事
・販売管理システムの完全ガイド
As-Is業務フローの棚卸とRFPの骨子
RFPと要件定義の出発点は、現状（As-Is）の業務フローを正確に棚卸しすることです。販売管理の失敗の多くは、現場が日々どう業務を回しているかを把握しないまま、理想論だけでシステムを設計することから生まれます。ここでは、業務フローの可視化とRFPに盛り込むべき骨子を整理します。
受注から請求までの業務フローを棚卸する
まず行うべきは、見積→受注→出荷→請求→入金という一連の流れを、実際の担当者へのヒアリングをもとに可視化することです。誰が、いつ、どんなツール（Excel、紙、メール、FAX）で、どんな情報を扱っているかを書き出すと、無駄な転記や二重入力、属人化したルールが浮かび上がります。一次データでも、As-Is業務フローの棚卸が要件定義の起点であり、ここを飛ばすと現場非定着の失敗につながると整理されています。
業務フローを棚卸す際は、「正常系」の流れだけでなく、現場で頻繁に起きる「例外」を必ず洗い出すことが重要です。標準的な流れは誰でも語れますが、システムが現場に使われるかどうかは、例外をどう扱えるかで決まります。受注担当・営業・経理・倉庫といった関係者から、「いつもの流れと違うのはどんなときか」を丁寧に引き出すことが、後の要件定義の精度を大きく左右します。
RFPに必ず書くべき項目と粒度
RFP（提案依頼書）には、プロジェクトの目的・背景、対象業務の範囲、現状の課題、実現したい機能要件、非機能要件（性能・セキュリティ・可用性）、連携対象の既存システム、想定予算とスケジュール、ベンダーに求める体制と保守条件を盛り込みます。とくに重要なのが、目的と課題を具体的な数字や場面で示すことです。「業務を効率化したい」では曖昧で、「月1,000件の受注の手入力をなくし、誤出荷を減らしたい」と書けば、ベンダーは的確な提案ができます。
RFPの粒度は、細かすぎても粗すぎても問題です。実現したい業務の姿（ToBe）と解決したい課題を明確にしつつ、具体的な実装方法はベンダーの提案に委ねるのが理想です。各社の提案を同じ土俵で比較できるよう、評価基準（機能適合度、費用、体制、サポート、実績）をあらかじめ整理しておくと、提案の良し悪しを客観的に判断できます。RFPは単なる依頼書ではなく、自社の要件を社内で整理し、ベンダーと認識を揃えるための重要なドキュメントです。
ToBe（あるべき業務の姿）と定量目標を描く
As-Isの棚卸と並んで重要なのが、改善後のあるべき業務の姿（ToBe）を描くことです。現状の課題を洗い出すだけでなく、「この業務はどうあるべきか」を能動的に設計しなければ、システムは単なる現状の電子化に終わってしまいます。受注処理を何分短縮するか、誤出荷を何%減らすか、月末の照合作業を何時間削減するかといった定量的な目標を、ToBeとして掲げることが大切です。
定量目標があると、要件定義の優先順位づけと、導入後の効果測定の基準が明確になります。たとえば「月1,000件の受注の手入力をゼロにする」という目標があれば、その実現に必要な機能が要件の中心になり、それ以外は優先度を下げられます。一次データでも、ToBeモデルの作成を怠った1億円のサイトが現場に使われず廃止になった失敗が示されています。ToBeを定量的に描くことは、投資の目的を見失わないための羅針盤になります。
例外処理（返品・値引・バックオーダー・分納）の3分類
販売管理の要件定義でもっとも差がつくのが、例外処理の扱いです。一次データでも、業務の3〜4割を占めるバックオーダーや分納などの例外を「自動化・手動・運用ルール」の3つに仕分ける要件定義ノウハウが、競合の解説で欠落していると指摘されています。ここでは、この例外処理の3分類という考え方を掘り下げます。
洗い出すべき例外処理の種類
販売管理で頻発する例外には、返品（出荷後に商品が戻ってくる）、値引き（特別な事情で価格を下げる）、バックオーダー（在庫切れで入荷を待つ注文）、分納（一度の注文を複数回に分けて納品する）、締め処理（請求の締め日をまたぐ取引）などがあります。これらは標準的な「見積→受注→出荷→請求」の流れから外れる処理であり、現場では日常的に発生します。要件定義では、まず自社にどんな例外があるかを網羅的に洗い出すことが出発点になります。
例外処理を軽視すると、リリース後に「この返品パターンが処理できない」「分納の場合に請求が二重になる」といった問題が噴出します。これらは現場がシステムを使わなくなり、Excelに回帰する最大の原因です。例外は地味で語られにくいものですが、業務の3〜4割を占めるという事実を踏まえれば、ここを要件定義で詰めることが、現場定着の成否を分けると分かります。
自動化・手動・運用ルールへの仕分け方
洗い出した例外は、すべてをシステムで自動化する必要はありません。むしろ重要なのは、「システムで自動化するもの」「システム上で手動操作するもの」「システム外の運用ルールで対応するもの」の3つに仕分けることです。発生頻度が高く定型化できる例外は自動化の価値が高い一方、まれにしか起きない複雑な例外は、無理に作り込むと開発費が膨らみます。頻度と複雑さを軸に、どこまでシステム化するかの線引きを行うのが要件定義の腕の見せどころです。
たとえば、頻繁に発生する分納は自動化し、年に数回しかない特殊な返品はシステム上で手動入力し、極めてまれな例外は運用手順書で人が判断する、といった仕分けが考えられます。この3分類をRFPと要件定義書に明記しておけば、ベンダーは過不足のない見積もりを出せ、自社も「どこまで作るか」のコスト判断ができます。すべてを自動化しようとすると費用が跳ね上がり、逆に例外を無視すると現場が使えないシステムになります。この線引きこそ、販売管理の要件定義の核心です。
頻度と複雑さの2軸で優先順位をつける
例外処理の仕分けを実務に落とし込む際は、「発生頻度」と「処理の複雑さ」という2軸でマッピングすると判断しやすくなります。頻度が高く複雑さが低い例外は、自動化の費用対効果が最も高い領域です。逆に、頻度が低く複雑さが高い例外を無理に自動化すると、開発費がかさむ割に使われず、投資が無駄になります。この2軸の整理を要件定義書に図として添えると、ベンダーとの認識合わせがスムーズになります。
注意すべきは、頻度の判断を担当者の感覚に頼らず、実データで裏づけることです。「たまにある」と思っていた例外が、実際に集計すると月の取引の2割を占めていた、というケースは珍しくありません。過去の取引データから例外の発生件数を実測し、その数字をもとに自動化の範囲を決めることで、要件の優先順位を客観的に定められます。例外処理の要件定義は、感覚ではなくデータで線を引くことが、後悔しない設計につながります。
マスタ名寄せとOMO・EC連携のアーキテクチャ要件
既存システムや外部チャネルと連携する場合、要件定義でもっとも工数を要するのがマスタの名寄せと連携アーキテクチャの設計です。ここを曖昧にすると、後付けの連動開発で数十万〜100万円の隠れコストが発生します。ここでは、マスタ名寄せ要件とOMO・EC連携のアーキテクチャ要件を整理します。
取引先・商品コードの名寄せ要件を整理する
会計・在庫・CRMなど複数のシステムを連携させる場合、取引先コードや商品コード（SKU）の体系を統一する「名寄せ」が最大の関門になります。同じ取引先や商品が、システムごとに別のコードで管理されていると、データを突合できません。一次データでも、名寄せは連携要件の整理だけで数週間かかる関門であり、後付けの連動開発費が数十万〜100万円の隠れコストになると指摘されています。要件定義では、どのコード体系を正（マスタ）とするか、変換ルールをどう設計するかを明確にする必要があります。
名寄せ要件をRFPに明記するときは、連携対象システムの現行コード体系を棚卸し、統一後のコード設計方針と、移行時のデータクレンジング範囲を示します。商品コードは、SKU基準でJANコードやインストアコードを規則的に付与する設計が望ましく、ここを曖昧にすると移行後にデータの不整合が頻発します。名寄せは地味な作業ですが、連携の成否を握る要であり、要件定義の段階でしっかり工数とコストを見込んでおくことが、後の隠れコストを防ぎます。
OMO・EC連携と売り越し防止のアーキテクチャ要件
ECと実店舗を併売する場合、在庫の一元化と売り越し防止のアーキテクチャを要件として明確にする必要があります。POSとECの在庫変動を同期させる際、同期の頻度やタイムラグの許容範囲、どのチャネルにいくつ在庫を引き当てるかの按分ルール、安全在庫の持ち方を定義します。一次データでも、POS-EC同期のタイムラグによる売り越しと、それを防ぐAPI連携アーキテクチャの設計が競合の空白だと指摘されています。要件定義では、この同期の仕組みを技術要件として具体化します。
具体的には、在庫の単一の正（マスタ）をどのシステムが持つか、API連携をリアルタイムにするかバッチにするか、店舗受取やEC注文の店舗在庫出荷といったオムニチャネル特有の動線をどう扱うかを定めます。これらを要件定義で詰めておかないと、リリース後に売り越しが頻発し、得意先の信頼を損ないます。OMO・EC連携は「在庫数を同期するだけ」では不十分で、按分・安全在庫・同期方式までアーキテクチャとして設計することが、要件定義の重要な責務です。
EDI規格・取引先別商慣行の連携要件
BtoB取引で大手取引先と連携する場合は、EDI（電子データ交換）規格への対応を要件に含める必要があります。流通BMSや全銀EDIといった規格に沿ってデータをやり取りするには、ゲートウェイの仕組みや変換ルールの設計が求められます。一次データでも、流通BMSや全銀EDI規格への対応とゲートウェイの仕組みが、BtoB特有の連携要件として整理されています。取引先がどの規格を求めるかを事前に確認し、要件に明記しておくことが重要です。
あわせて、取引先別の価格体系やリベートといった商慣行の連携要件も具体化します。掛率や個別単価をどのマスタで管理し、受注時にどう自動適用するか、リベートの算定条件をどう定義するかを要件として書き下します。これらを曖昧にすると、リリース後に手作業での価格修正が残り、自動化の効果が薄れます。BtoBの連携要件は、技術的な規格対応と、商慣行のマスタ設計の両面を要件定義で詰めることが、現場で使えるシステムへの近道になります。
インボイス・電帳法の数値要件と検収基準
法制度対応と検収基準も、要件定義書に欠かせない項目です。「インボイス対応」と書くだけでは不十分で、例外処理まで含めた具体的な要件と、完成を判定する検収基準を定めておく必要があります。ここでは、法制度の数値要件と検収基準の決め方を整理します。
適格返還請求書・軽減税率の例外要件
インボイス制度への対応要件では、適格請求書の発行だけでなく、返品・値引き時の「適格返還請求書」の消費税処理を要件に含めることが重要です。一次データでも、「対応済み」の単語止まりで、返品・値引時の適格返還請求書の処理や軽減税率の例外処理レベルの解説は空白だと指摘されています。要件定義書には、自社で発生する返品・値引きのパターンを具体的に列挙し、それぞれで税額がどう計算されるべきかを明記します。
軽減税率が関わる商材を扱う場合は、税率の混在した取引でも正しく区分経理できることを要件に加えます。電子帳簿保存法への対応では、電子取引データの保存形式・検索要件を満たすことを明記します。電子インボイスとEDI連携、入金消込の自動化まで視野に入れれば、経理の生産性が大きく向上します。法制度要件は「対応している」では曖昧で、自社の例外パターンまで具体的に書き下すことが、後の手戻りと税務リスクを防ぎます。
非機能要件と検収基準を定める
要件定義書には、機能要件だけでなく非機能要件も明記します。同時アクセス数やレスポンス速度といった性能要件、障害時の復旧目標（RTO・RPO）、バックアップ方針、アクセス権限とセキュリティ要件などです。一次データでも、トラブル時に業務が停止しないサポート体制が選定基準として重視されており、可用性とサポートの要件を曖昧にしないことが大切です。365日サポートが必要か、何時間以内の復旧を求めるかを具体的に定めます。
検収基準は、「何ができれば完成と認めるか」を客観的に定義するものです。各機能のテストケース、例外処理の動作確認項目、性能の合格ラインを事前に決めておけば、リリース時の「言った・言わない」のトラブルを防げます。検収基準を要件定義の段階で合意しておくことは、発注者とベンダー双方を守る重要な取り決めです。riplaはフルスクラッチ受託と国内開発の立場から、例外処理の3分類・名寄せ・法制度の例外まで踏み込んだ要件整理と、明確な検収基準の設計を重視しています。要件定義書は、投資の無駄を防ぐ最良の保険なのです。
データ移行とマスタクレンジングの要件
要件定義で忘れてはならないのが、旧システムやExcelからのデータ移行の要件です。商品・取引先・在庫・過去取引のデータを新システムへ移す際、データが汚れたまま移行すると、移行後に重複や不整合が頻発します。一次データでも、データ移行前のクレンジングと、SKU基準での規則的なコード付与が肝だと整理されています。要件定義書には、移行対象データの範囲、クレンジングの責任分担、移行後の検証方法を明記しておく必要があります。
とくに、長年運用してきたマスタには、重複登録や表記ゆれ、すでに取引のない休眠取引先などの「ゴミデータ」が溜まっていることが多くあります。これを移行前に整理しないまま移すと、新システムでも同じ混乱を引き継いでしまいます。データ移行は単なる作業ではなく、マスタを整える絶好の機会だと捉え、クレンジングの工数と責任を要件定義で明確にしておくことが、移行後のトラブルを防ぐ鍵になります。移行要件の曖昧さは、リリース直後の混乱に直結します。
まとめ
販売管理システムのRFP・要件定義書は、As-Is業務フローの棚卸を起点に、例外処理（返品・値引・バックオーダー・分納）を自動化・手動・運用ルールの3つに仕分け、取引先・商品コードの名寄せ要件とOMO・EC連携のアーキテクチャを具体化し、インボイス・電帳法の例外処理まで数値で書き下すことが要諦です。とくに業務の3〜4割を占める例外処理と、連携の関門である名寄せを曖昧にしないことが、隠れコストと現場非定着を防ぐ鍵になります。
要件定義で大切なのは、すべてを自動化しようとせず、頻度と複雑さに応じて作り込む範囲を見極めることです。そのうえで非機能要件と検収基準を明確に定めれば、ベンダーは過不足のない提案ができ、発注者は投資の妥当性を判断できます。riplaはフルスクラッチ受託と国内開発を組み合わせ、現場の業務と商慣行から逆算した要件整理を一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社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を創業。