百貨店業界のシステム開発は、業務の洗い出し、RFPと小規模な検証、段階導入の順で進めると、予算とリスクを管理しやすくなります。
発注の前に業務の流れを整理しておくと、開発会社への依頼内容がそろい、提案や見積もりを公平に比べられます。
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
百貨店業界のシステム開発を発注する前に知るべき全体像
百貨店のシステムは、一つのパッケージで完結するとは限りません。そのため発注する側は、店舗、EC、テナントのあいだでデータがどう流れるかを描き、外商、物流、会計も含めて整理しておく必要があります。共通化する領域と、個別に連携する領域を分けておくと、発注前の準備が進めやすくなります。
テナントとブランドが混在するデータ構造
百貨店には、直営売場のほかに、ブランド直営店や催事、外部テナントがあります。さらに食品売場もあり、運営の形はいっそう多様です。
各社でPOSや在庫管理が異なる場合、全館の売上・在庫・顧客情報をひとつにまとめるには、対応表が必要になります。たとえば、商品コード、店舗コード、ブランドコード、テナントコードを突き合わせる表です。
- 商品・SKU：商品、サイズ、カラー、ブランド、販売形態の粒度（どこまで分けて持つか）
- 店舗・ブランド：店舗コードとブランドコードの対応
- テナント：出店者ごとの売上と在庫の把握
SKUの持ち方によって在庫精度と分析結果が変わるため、粒度は発注前に決めておきます。
店舗・EC・顧客データをつなぐOMO基盤
経済産業省の調査によると、2024年の国内BtoC-EC市場規模は26.1兆円です。BtoC-EC化率は9.8%です（出典：経済産業省「令和6年度電子商取引に関する市場調査」、2025年）。
百貨店では、店舗の接客力とECの利便性を両立させるため、顧客IDや購買履歴、ポイント、在庫、配送状況を連携させる設計が求められます。
テナントごとに顧客情報の利用範囲や売上計上ルールが異なるため、権限と契約の整理を技術設計の前提に置きます。
発注前に整理すべき百貨店業界のシステム要件
RFPを作る前に、発注する側は業務をシステム機能ではなく、取引と判断の流れとして洗い出します。
理想の業務フローだけを書くと、店舗やテナントの実情が抜けるおそれがあります。そのため、稼働後にExcelや手作業へ戻ることがないよう、現行業務も合わせて確認します。
消化仕入とテナント精算のルールの明文化
消化仕入では、商品が売れた時点でテナントから仕入れたとみなします。そのため、精算の計算対象と変更の手順を先に決めておく必要があります。
- 売上と仕入：売上確定と仕入計上の関係
- 料率と負担：販売手数料、歩合家賃、値引き、クーポン、ポイントの扱いの定義
- 精算後の管理：返品、締め後の訂正、計算式の変更権限、監査ログの要否
料率や対象売上がテナントごとに異なる場合は、契約条件をマスタで管理すると扱いやすくなります。また、月次の精算では、担当者が検算できる仕組みも要ります。
RFPには、精算できることだけでなく、計算式の変更権限と締め後の訂正方法も記載します。
外商・友の会・ギフト業務の対象範囲
外商、会員、ギフトでは扱う情報が異なるため、対象業務を分けて整理します。
- 外商：購買履歴や提案商品を見ながら接客し、掛け売りや配送まで進めることがあります。
- 友の会：積立残高、利用、返金、会員資格などの管理が欠かせません。
- ギフト：お中元・お歳暮では、複数の配送先、商品、のし名入れ、希望日を受注し、その内容を倉庫のピッキングと梱包の指示へ正確に渡します。
後から業務を足すと連携範囲が膨らむため、初期機能と将来連携する機能を分けて決めておきます。
百貨店業界のシステム開発を外注する進め方
発注は、現状把握、構想、RFP、提案比較、契約、要件定義の順に進みます。そのあと、開発、テスト、移行、運用設計へと続きます。
全面刷新を一度に依頼せず、売上・在庫・顧客のうちどこから効果を出すかを先に決めます。範囲を絞れば、予算とリスクを管理しやすくなります。
パッケージ導入・SaaS・受託開発の選び方
業務の標準化度と、独自運用の重要性に応じて、発注形態を選びます。
- SaaS・パッケージ：業務が標準化され、既存機能に合う場合は候補になり、導入期間を短くしやすいです。
- 受託開発：独自の外商運用や複数テナント精算が競争力に直結するなら、この形態が合います。
- 組み合わせ：標準機能を使い、差分だけを個別に開発する方法もあります。
特に、消化仕入などの例外を製品に無理に合わせると、現場が別管理を始めるおそれがあります。
RFPと小規模な検証による不確実性の削減
RFPには、提案の前提になる業務とシステムの情報をそろえます。見積もりを左右する条件も、ここで具体的に書いておきます。
- 案件の前提：背景、目的、対象業務、利用者、納期、予算枠を記載します。
- システム情報：現行環境、データ項目、連携先、非機能要件など。
- 提案依頼：提案してほしい内容と、判断に使う条件を明記します。
テナント別の閲覧範囲、在庫を何分以内に反映するか、障害時に手作業へ切り替えるかは、見積額を大きく左右します。
本開発の前に、精算計算や在庫連携といった難所だけをPoC（小規模な検証）で確かめる方法もあります。
レガシーを止めない段階移行
長年使ってきた基幹システムには、仕様書にない例外処理や担当者の手順が残っていることがあります。
- 現行機能をそのまま再現する前に、画面、帳票、バッチ、データ連携、手作業を洗い出し、廃止できる業務を見極めます。
- 顧客IDや商品マスタなどの共通データを整えたうえで、次にECや在庫を切り替えます。
- 最後に会計・精算を切り替え、並行稼働と段階リリースを組み合わせます。
なお、IPAの「DX動向2025」は、日本企業のDX成果が米国・ドイツより低く、個別業務の最適化にとどまりやすい傾向を示しています（出典：IPA、2025年）。
部門単位の刷新で終わらせないため、全館の業務指標を最初に決めておきます。
契約形態の選び方（請負と準委任）
要件と成果物を固定できる部分は請負、調査や要件定義など変更が多い部分は準委任が向いています。
百貨店の案件は関係部門やテナントが多いため、全工程を請負で固定すると、変更のたびに追加費用や納期調整が生じやすくなります。
請負契約の範囲と完成条件
請負契約では、受託者が成果物を完成させ、発注者がそれを検収します。合格の条件は、契約の段階で明確にしておきます。
- 契約に記載：画面・機能一覧、連携仕様、性能、テスト条件を定めます。
- 納品と検収：納品物と検収期限を、契約書や仕様書に記載しておきます。
- 変更範囲：要件変更が請負の範囲に混ざると、受託者側のリスクが価格に上乗せされます。
リサーチノートの実案件知見では、仕様を固定した請負は、変更を前提にした準委任と比べて1.3〜1.5倍程度の見積もりになり得ます。
この幅は案件の前提によって変わるため、根拠と前提を確かめてから比べます。
準委任契約で検討と改善を進めやすくする場面
準委任契約では、受託者が専門知識や作業を提供し、発注者と協力して課題を解決します。
- 向く工程：現行調査、要件定義、プロトタイプ、移行計画、運用改善など、成果の形が変わりやすい工程に適しています。
- 成果管理：月次の成果物、意思決定事項、課題一覧、次月のゴールを合意します。
- 契約の組み合わせ：開発は請負、要件定義と運用改善は準委任に分ける方法もあります。
作業時間だけで管理すると成果が見えにくくなるため、成果物を基準に進み具合を見ることが欠かせません。
百貨店業界のシステム開発費用相場とコストの内訳
費用は、対象店舗数、テナント数、連携先、データ移行量で変わります。外商・友の会機能、セキュリティ、24時間運用の有無も影響します。
百貨店向けに店舗・EC・会員・在庫・複数倉庫を統合する基盤を新規開発する場合、初期検討の目安は1,800万円〜4,000万円以上です。この金額は要件を切り分けるための予算レンジで、一律の市場価格ではありません。
初期費用の内訳と準備費
見積もりには、現状分析や業務整理、要件定義といった初期の工程から、開発、テスト、データ移行、教育までの作業が含まれます。そのほか、UI設計や連携、プロジェクト管理の工数も見積もりに入ります。既存システムの仕様が分からない場合は、調査に追加の工数がかかります。
テナント別の精算ルールを一つずつ確かめる作業や、過去データのコード変換は、機能一覧だけでは把握しにくいコストです。
ランニングコストと投資対効果の分け方
初期費用と稼働後の費用、導入効果は分けて比較します。
- 運用費：稼働後も、クラウド利用料、保守、監視、障害対応、ライセンス、端末更新、セキュリティ対策の費用がかかります。
- 投資効果：売上増加のほか、精算作業時間、在庫照会時間、問い合わせ件数、欠品や売り越し、レジ待ち時間などをKPIに設定し、投資回収を判断します。
- 効果測定：段階導入では、最初の機能でどの効果を何か月後に測るかも見積もりに含めます。
初期費用だけで比べると、安価な提案が後から高額な追加保守につながることがあります。
委託先の見積もりを比較するポイント
見積金額だけでなく、前提条件と対象外を横並びにして比べることが基本です。担当体制や工程別の工数、検収条件も同じ並びで見比べると、差が分かりやすくなります。
データ移行やテナント調整、リリース後の伴走が含まれるかで、実質的な価格が変わります。
見積もりの前提条件と対象外
「在庫連携一式」「移行対応一式」のように一式でまとめられた見積もりは、中身が見えず、比較や追加費用の予測がしにくくなります。
- 連携と移行：連携本数、APIの有無、ファイル連携の頻度、移行対象の年数を確かめます。
- 例外と分担：テナントごとの例外の数、テストデータ作成の担当
- 追加費用：仕様変更の単価と、追加テナントの接続費用を尋ねます。
これらが明確になると、稟議後の予算超過を防ぎやすくなります。
百貨店業務への理解とプロジェクト体制の見極め
百貨店特有の業務理解と実績、契約後の支援体制を確認します。
- 業務知識：消化仕入、販売手数料、外商、友の会、ギフト物流についての理解度
- 実績と体制：担当範囲、稼働店舗数、移行方法、障害対応、現場への定着支援を確認します。
- 責任と引き継ぎ：契約後の責任者と、業務会議への参加の有無を見ます。
提案を担当する人と実装を担当する人が別なら、役割分担を確かめておきます。
特定のベンダーしか保守できない構成を避けるため、ソースコード、設計書、API仕様を確認しておきます。
データの所有権と引き継ぎ条件も、契約前に確かめることが大切です。
MUSTとWANTの分離と段階導入
すべての要望を初回リリースに詰め込むと、百貨店では予算も納期も膨らみます。必須要件と追加要望は、分けて扱います。
- MUST：売上計上、精算、在庫、顧客ID、権限、会計連携など
- WANT：高度なレコメンド、全社ダッシュボード、外商向けの追加機能など
MUSTには、止められない業務や法令・監査に関わる要件を含めます。一方で、WANTは稼働後の効果を見てから追加します。
RFPに「初回」「次期」「将来」の3段階を設けると、各社の設計力を比較できます。
発注後のプロジェクト体制で失敗を防ぐ方法
システム部門だけで決めると、現場の重要な判断が抜けることがあります。店舗や外商、物流の担当者を、初めから判断の場に入れておくことが欠かせません。
発注者は業務の優先順位と意思決定を担い、委託先は技術設計と実装を担います。この役割分担を先に明確にしておくと、判断が止まりにくくなります。
意思決定者と現場代表の配置
業務とシステムの判断が滞らないよう、役割と会議の進め方を決めておきます。
- 責任者：経営層のスポンサー、業務責任者、情報システム責任者、プロジェクトマネージャーを決めます。
- 現場代表：店舗、外商、物流、経理の代表を置きます。
- 会議と業務判断：会議体ごとに、決める内容と期限を定めます。
判断が必要な論点は、課題管理表に残しておきます。
値引きや取り置き、返品、催事対応といった現場の例外は、標準化するものと残すものに分けて対話で決めます。そのように決めたことが、現場への定着につながります。
業務シナリオテストと運用引き継ぎ
テストは、実際の業務シナリオに沿って行います。テナント売上に値引きとポイントを反映し、返品、月末の歩合家賃計算、会計連携まで確かめます。
ギフトでは複数配送先とのし名入れ、外商では掛け売りと配送を検証します。ECでは在庫引当と店舗受取も確認します。
リリースの前に、障害時の手作業、問い合わせ窓口、権限変更、マスタ登録の担当者を決めておきます。
よくある質問
費用だけでなく、業務ルールの理解と移行後の運用支援も判断材料になります。担当者から寄せられることの多い質問を、次に取り上げます。
百貨店のシステム開発費用は最低いくらですか？
小規模な業務改善や既存SaaSとの連携なら、対象を限定して始められます。
店舗・EC・在庫・会員・精算を統合する基盤開発は、初期検討の目安が1,800万円〜4,000万円以上です。リサーチノートに基づく目安です。
店舗数、テナント数、移行データ、連携先を明確にしたうえで、段階ごとに見積もりを取り寄せると、比べる材料がそろいます。
パッケージ導入と受託開発はどちらが良いですか？
標準化できる業務はパッケージやSaaSを使い、独自性の高い領域は個別開発する組み合わせが適しています。
消化仕入、テナント精算、外商などは、自社の差別化に関わる領域として検討します。
現場の例外処理を製品に合わせられるかどうか、追加開発の保守費用、将来のデータ持ち出しの可否を比べます。
RFPがない状態でもシステム会社へ相談できますか？
相談できます。まず、現状の課題と対象部門を整理しておくと、初期相談が円滑に進みます。現行システムや困っている業務も合わせて伝えられると、話が早くなります。
希望時期と予算の上限も用意しておきます。複数社を公平に比べる段階では、共通のRFPや質問票を使うと、提案の違いを同じ条件で見られます。
各社に同じ前提で提案してもらうことで、提案の差がそのまま比べられるようになります。
古い基幹システムを止めずに移行できますか？
可能です。ただし、現行仕様とデータの依存関係を調べ、並行稼働、段階的な切り替え、切り戻しの条件を設計しておく必要があります。
経済産業省とIPAの2025年の報告では、技術の古さだけでなく、変化への適応性やブラックボックス化の確認も挙げられています（出典：経済産業省・IPA、2025年）。
全機能を一度に移すよりも、共通マスタや連携APIから着手するほうが、安全性を高められます。
まとめ
百貨店のシステム開発では、一般的な販売管理の機能を比べるだけでなく、業務フローを整理してRFPを作ることが欠かせません。必須要件と追加要望も、ここで分けておきます。
消化仕入とテナント精算、外商・友の会は、対象に含めます。そのうえで、ギフトの物流や、店舗とECの在庫・顧客連携も範囲に入れます。
発注を成功させるポイント
標準化できる領域にはSaaSやパッケージを使い、独自性の高い領域を受託開発する方法が基本です。
要件が固まった工程は請負、変更が多い調査や要件定義、改善は準委任に分けると、過度な固定化を避けられます。
見積もりでは、価格だけでなく前提と対象外を見ます。移行や保守、引き継ぎの扱いと、ベンダーロックイン対策も確認します。
参考情報
参照した資料は、経済産業省「令和6年度電子商取引に関する市場調査」とIPA「DX動向2025」です。
もう1件は、経済産業省「レガシーシステムモダン化委員会総括レポート」です。
- https://www.meti.go.jp/press/2025/08/20250826005/20250826005.html
- https://www.ipa.go.jp/digital/chousa/dx-trend/dx-trend-2025.html
- https://www.meti.go.jp/press/2025/0528_001.html
費用レンジと契約形態の差、百貨店特有の業務整理は、リサーチノートとシステムSIの実案件知見に基づく発注検討上の目安です。
▼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を創業。