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