RFP（提案依頼書）と要件定義書には、目的や現状業務、要望の優先度を書きます。現場の例外や移行・連携費用、保守の条件も盛り込むと、ミスマッチや追加費用を防げます。
全体像は小売業界のシステムの完全ガイドもご覧ください。
▼全体ガイドの記事
・小売業界のシステムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
RFP（提案依頼書）に盛り込むべき項目
RFP（提案依頼書）は、自社の要望を開発会社に伝え、比較できる提案を各社から得るための文書です。記載が粗いと各社が別々の前提で見積を出すため、金額を横並びで比べられません。
RFPの書き方を整えれば、提案を同じ条件で比べられるようになります。最低限盛り込む項目と、見積を比較可能にする書き方を押さえておきます。
目的・現状業務・予算・スケジュールの明示
提案の前提をそろえるため、RFPには次の項目を盛り込みます。
- 目的：解決したい課題を具体的に示す
- 現状：業務フローと既存システムの構成
- 予算・日程：予算の幅とスケジュール
RFPの冒頭では、導入の目的を具体的に書きます。「レジ業務を効率化したい」より、人手不足を背景にレジ要員を減らし、ピーク時の回転を上げたいと書くほうが、提案の方向性がそろいます。
業務フローには、受発注・在庫管理・会計の流れを示します。既存システムも併せて書いておくと、連携や移行の要否を開発会社が正確に見積もれます。
予算を伏せると足元を見られると考える発注者もいます。ただ、予算の幅を示せば、その範囲で実現できる提案を受けられます。
中小小売のIT予算は、一般に売上高の1〜3%、または従業員1人あたり年15〜40万円が目安とされます。この水準を参考に予算感を示すと、過大なシステムの提案を避けられます。
MUST要件とWANT要件の切り分け
曖昧なまま出すと、開発会社がすべてを必須とみなして見積を膨らませたり、重要な機能を落としたりするおそれがあります。そのため、要望はMUST（必須）とWANT（あれば望ましい）に切り分けます。
切り分けは、必須度に応じて次の2区分で行います。
- MUST：絶対に外せない機能
- WANT：予算次第で見送れる機能
優先度を示すと、各社の提案を比べやすくなります。さらに、段階的な投資にもつながります。
切り分けが不十分だと、開発中に要望が増え続けるスコープクリープが起き、費用と期間が膨らみます。要件の幅しだいで、総額が何倍にも変わることがあります。
小売の開発費は、小規模（在庫・簡易売上）で300万〜700万円、中規模（POS・発注・会員・EC連携）で700万〜1,800万円です。
大規模（多店舗・EC統合・複数倉庫）は1,800万〜4,000万円以上が相場とされます。MUSTとWANTの切り分けは、この予算を管理するうえで欠かせません。
現場の例外ケースを織り込む要件定義
小売システムの要件定義では、現場の例外ケースが抜けやすいので注意が必要です。返品や値引きなど、店頭では通常と異なる操作が日常的に発生します。取り置きやクーポン併用も、そのひとつです。
例外が要件から漏れていると、稼働後に必要な操作ができず、現場とのミスマッチが表面化します。その結果、システムが使われなくなるおそれもあります。
返品・値引き・クーポン併用の運用ルールの要件化
返品・値引き・クーポン併用などの例外操作を洗い出し、それぞれをシステム上でどう扱うかを文章にします。
- 返品：レシート有無、交換か返金か、セール品の可否
- 値引き：見切り品、会員割引、複数クーポンの併用可否
- 運用の差：本部の規定と店舗現場の判断
本部の厳格なマスタ管理と、店舗現場の柔軟な判断には食い違いがあります。本部は値引きを規定内に抑えたい一方、現場では常連客への端数値引きや在庫処分に対応します。
現場ヒアリングで双方の事情をすり合わせ、本部の統制と現場の裁量のバランスを要件に落とし込みます。
要件が曖昧なまま開発すると、仕様変更で費用と期間が膨らみます。さらに、稼働後に現場独自の例外運用が始まるおそれもあります。
現場ヒアリングによる暗黙のルールの掘り起こし
暗黙のルールを要件に反映するには、次の方法で現場の情報を集めます。
- 聞き取る：現場スタッフやベテランが知る運用、店舗ごとの慣習
- 観察する：店頭業務や繁忙時間帯のスタッフの動き
- 要件に反映する：操作順や入力項目を実際の作業に沿わせる
例外ケースの多くは、マニュアルに書かれていない暗黙のルールです。ベテランだけが知る運用や店舗ごとの慣習は、本部の担当者がRFPを書く作業のなかでは拾いにくいものです。
本部やベンダーに任せきりにしたプロジェクトは、業務とシステムが合わなくなりやすいとされています。
自社の業務を知る現場と一緒に要件を作ることが、ミスマッチの防止につながります。この工程に時間とコストをかけると、手戻りが減り、総額も抑えられます。
ヒアリングでは会議室で聞くだけでなく、店頭オペレーションの観察も有効です。レジ前の動線や商品の並べ方から、口頭では出てこないルールが見つかります。
データ移行・連携費用の要件明示
小売システムの見積では、データ移行と外部システム連携の費用がトラブルになりやすいものです。「本体に含まれるはず」と思い込んでいると、見積から漏れることがあります。
漏れた費用は、後から数十万〜100万円規模の追加費用として発覚することもあります。要件定義の段階で移行・連携の範囲と費用を明示的に確認すると、隠れコストを防げます。
データ移行とクレンジングの工数の扱い
既存システムやExcel台帳からの移行は、単純なコピーでは済みません。商品マスタや顧客マスタの表記ゆれや重複を整理するクレンジングには、想定以上の工数がかかります。
移行要件には、作業範囲や検証方法など、次の項目を含めます。
- 対象：移行するデータの種類と件数
- 担当・検証：自社対応か委託か、データの正しさの確認方法
- 本番移行：リハーサルの実施有無と営業を止める時間帯まで事前に詰める
作業費用も見積に含めるよう、各社に求めます。移行を軽く見ると、稼働直後に在庫数や会員ポイントが合わなくなり、信頼を失うおそれがあります。
データ移行は、独立した予算とスケジュールを持つ工程として要件に入れます。このように位置づけると、トラブルの回避につながります。
会計・EC・WMS連携の追加開発費の見積条件
小売システムは、会計ソフト・EC・倉庫管理（WMS）などと連携すると、業務が一気通貫になります。見積では、連携の範囲と将来の拡張も確認します。
- 見積条件：外部システム名・バージョン、標準連携か追加開発か
- 将来の拡張：ECや複数倉庫への連携費用
- データの流れ：売上の行き先、在庫の引き当て先、会計への計上時期
連携が標準機能で済む場合と個別開発が必要な場合があり、後者には数十万〜100万円の追加費用がかかります。RFPでは、追加費用の概算も各社に示してもらいます。
今は店舗のPOSだけでも、将来はECや複数倉庫へ広がる可能性があります。その拡張には費用の幅も大きく、物流をフルスクラッチで作る場合は200万円以上、基幹システム全体の再構築では1,000万円を超えることもあります。
連携要件をデータフロー図にすると、見落としが減り、連携箇所とやり取りするデータが明確になります。連携の全体像は、段階的な投資計画を立てる際の基礎にもなります。
図をRFPに添付すると、開発会社が連携範囲を正確に見積もれます。言葉だけで連携を書くより、データの流れで示すほうが、隠れコストの防止につながります。
サポート・保守のSLA定義
システムは稼働後も、運用と保守が続きます。小売の現場では、レジが止まるとすぐに売上も止まるため、障害時の復旧速度が死活問題になります。
そのため、要件定義でサポート・保守のSLA（サービス品質保証）を明確にしておきます。障害時の対応条件は、事前に定めておく必要があります。
障害時の対応時間と復旧目標の定め
SLAで定める代表的な項目は、障害発生時の対応時間と復旧目標です。次の条件を明記します。
- 対応時間：平日日中のみか、24時間365日か
- 復旧条件：一次回答までの時間と復旧目標時間（RTO）
- 営業時間：店舗の営業時間、土日祝、繁忙期をカバーする体制
安価なレジの故障で復旧に3日かかった例もあります。たとえば、1日の売上が20万円の店舗なら、機会損失は60万円になります。
サポートの水準は、損失リスクに照らして決めます。営業時間中に使われる小売システムでは、店舗の営業時間をカバーする体制が欠かせません。
土日祝に営業する店舗は、土日のサポートが含まれるかも確認します。RFPに営業時間と繁忙期を記し、必要な時間帯を各社に求めておけば、「肝心なときに連絡がつかない」事態を防げます。
契約終了時のデータエクスポート条件
将来の乗り換えに備えて、契約終了時のデータについて次の条件を要件に入れます。
- 対象と形式：商品マスタ・顧客データ・購買履歴をCSVなどで出力
- 費用：エクスポートに追加費用がかからないこと
出力形式を確認しておかないと、乗り換えの際にデータを取り出せないおそれがあります。こうした状態は、データを取り出せずベンダーから抜け出せない「ベンダーロックイン」と呼ばれます。
導入時に撤退の条件を定めておくと、長期的にシステムを選ぶ自由度を保てます。データのポータビリティ（持ち運びやすさ）を確保すれば、乗り換えの選択肢も残ります。
独自仕様への依存を避け、要件定義の段階で出口まで設計しておきます。これは、長く使えるシステムを選ぶうえで欠かせない点です。
たとえば、サービスの値上げや品質低下があっても、別のシステムへ移る選択肢が残ります。
非機能要件とベンダー選定の基準
性能・セキュリティ・可用性などの非機能要件は、見落とされやすい項目です。あわせて、どの開発会社に依頼するかという選定基準も、RFPに含めるべき大事な論点です。
性能・セキュリティ・可用性の非機能要件
非機能要件には、次の観点を含めます。
- 性能：想定負荷と許容する処理速度
- セキュリティ：情報保護とバックアップの方針
- 可用性：稼働率の目標と障害時の復旧手順
性能では、ピーク時の同時アクセス、レジの処理速度、ECのページ表示速度などを扱います。セールや繁忙期に会計が滞ると機会損失に直結するため、想定取引量と許容レスポンスを示しておきます。
顧客情報や決済データを扱うため、暗号化とアクセス権限を明記します。ランサムウェアの平均被害額は2,386万円（JNSA）とされ、中小小売でも対策が必要です。
バックアップからの復旧手順も決めておきます。こうした目に見えにくい要件を軽視すると、障害時の業務やシステムの信頼性を損ないます。
小売の現場理解を重視した選定基準
RFPの最後には、開発会社の選定基準を定めておきます。価格や機能に加えて、次の点も比べます。
- 現場理解：中小小売の業務、同業種の導入実績、支援事業者登録
- 契約形態：成果物に責任を持つ請負は仕様確定後、準委任は要件検討中
- 単価：受託80〜120万円、フリーランス60〜80万円（月額）
- 見積内訳：各工程の費用と含む作業・含まない作業
小売特有の例外業務や商習慣への理解は、要件定義の質と現場への定着を左右します。契約は、フェーズに応じて使い分けるのが現実的です。
提案は見積総額だけでなく、内訳の明瞭さも評価の軸になります。要件定義から保守まで、工程ごとに費用と対象範囲を確認します。
一式の金額だけで内訳のない提案は、追加費用が膨らむリスクがあります。RFPで工程別の見積を求めると、各社を比べられ、長く付き合えるパートナーの選定にもつながります。
RFPと要件定義の丁寧さは、提案の質とプロジェクトの成否に影響します。
まとめ
小売業界のシステム導入では、RFPに目的と現状業務、予算とスケジュールを示し、要望はMUSTとWANTに分けます。そのうえで、現場の例外を聞き取り、移行・連携費用やSLA、データ出力の条件も要件に含めます。
返品・値引き・クーポン併用の例外を現場ヒアリングで掘り起こし、本部の統制と現場の裁量のバランスも要件に反映します。
移行・連携費用、サポートSLA、契約終了時のデータ出力を要件に入れると、隠れコストとベンダーロックインを防げます。
要件定義を開発会社に任せきりにせず、現場の知見を取り入れることが大切です。
中小小売のIT予算の目安である売上高の1〜3%を念頭に置き、MUSTとWANT、例外業務を時間をかけて詰めると、手戻りや総額を抑えられます。
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を創業。