小売・EC向け 業務システム・ECサイト開発
パッケージEC・POSで足りない部分だけを作る
買い取りや多店舗出店のようにパッケージECでは組めない販売フロー、店頭でその場で在庫を確認できない、店舗のデータが事務所のPCでしか見られない。小売・EC事業者の困りごとを、今あるPOSやECを活かし、足りない部分だけをスクラッチで作る形で解消します。ホームセンターの店頭業務、買い取り対応EC、モール型ECの事例をもとに、進め方と費用の目安をご説明します。
小売・ECでよくある課題
小売・ECからのご相談は、「売る仕組みはあるのに、その周りの業務が手作業のまま」という形で始まることがほとんどです。当社が手がけた店舗向けシステムとECの事例に共通していたのは、次の状態でした。
店頭で在庫がすぐ分からない
お客様に在庫を聞かれても、その場で答えられずバックヤードや電話での確認になります。全国チェーンでは店ごとに確認の仕方が違い、応対時間が延びていきます。
伝票が紙で、転記が多い
取り寄せや取り置き、配送の手続きを紙の伝票で受け、閉店後に事務所で入力する二重作業になっています。記入と転記の手間が、応対の遅れと処理ミスの出発点です。
店舗のデータが事務所のPCでしか見られない
POSや棚卸のデータを見るには事務所のPCが必要で、売場や外出先からは状況が分かりません。一方で、動いているシステムを作り直す大掛かりな投資は避けたいのが本音です。
ECパッケージが自社の販売フローに合わない
買い取り、複数の売り手による出店、購入前の審査や本人確認。一般的なECパッケージは「商品を並べて売る」ことに最適化されており、売る向きや売り手が増えると対応できません。
よくある現状: Excelの在庫表、紙の伝票、パッケージECの限界
上の課題の裏には、多くの場合「店舗の在庫はExcel、ECの在庫はECの管理画面」という二重管理と、「パッケージの標準機能に無い業務を人手で補う」運用があります。当社に寄せられる相談で特に多いのは次の3つです。
| 今の運用 | 起きていること | 限界のサイン |
|---|---|---|
| 店舗の在庫表（Excel）とECの在庫を別々に管理 | 同じ商品の在庫数が2か所にあり、売れるたびにどちらかを手で直す | ECで売れた商品が店頭にもう無い。その逆も起きる |
| 紙の伝票（取り寄せ・取り置き・配送手配） | 店頭で記入し、閉店後に事務所で入力する | 翌日まで状況が分からない。転記ミスの原因を追えない |
| パッケージECに無い業務を手作業で補う | 買い取りの査定や出店者ごとの精算を、メールとExcelで回している | 補う運用のほうが本体より重くなる |
すべてを作り直すべきだとは考えていません。POSやECパッケージが業務に合っているなら残し、合っていない部分だけを作るのが当社の基本です。Excelの在庫表を延命するかWeb化するかの判断はAccess・ExcelからWebシステムへの移行に、パッケージとスクラッチの向き不向きはスクラッチ開発とパッケージ導入の違いにまとめています。
SIAの解決方法
まず「店舗とECのどこでデータが二重になっているか」と「パッケージのどこで業務が詰まっているか」を確認し、作る範囲を決めます。店舗業務とECは別のシステムとして扱われがちですが、当社は在庫・会員・決済の3つの接点でつながる一つの販売フローとして設計します。
店舗業務とECの接点: 在庫・会員・決済
| 接点 | 店舗側にあるもの | EC側にあるもの | つながっていないと起きること |
|---|---|---|---|
| 在庫 | POSの販売実績、棚卸データ | ECの在庫数 | 売り越しと機会損失。店頭で「ECには在庫があります」と案内できない |
| 会員・顧客 | ポイントカード、会員台帳 | ECの会員 | 同じお客様が別人として登録され、購入履歴とポイントが分かれる |
| 決済・売上 | レジの売上 | 決済代行サービスの売上 | 日次の売上集計が2系統になり、経理が手で合算する |
3つを一度につなぐ必要はありません。困りごとが最も大きい在庫から始め、会員・決済は次の段階にする進め方が現実的です。
パッケージECで足りなくなるサイン
ECをパッケージやASPで始めるのは正しい選択です。ただ、次のどれかに当てはまると標準機能やプラグインでは対応しきれず、スクラッチか部分的な作り込みが必要になります。
| サイン | 具体例 | 当社の事例 |
|---|---|---|
| 販売の向きが「売る」だけではない | 買い取り、下取り、査定の依頼を受けてから成立させる | 買い取り×販売を融合したECサイト |
| 売り手が複数いる | 出店者ごとの登録・発送・精算と、運営者による決済・問い合わせの一元化 | モール型ECサイト、鮮魚ECアプリ「UOICHI」 |
| 法律上の手続きが取引フローに入る | 古物営業法で義務付けられた買い取り時の本人確認（身分証の確認） | 買い取り×販売を融合したECサイト |
| 店舗の業務システムとつなぐ必要がある | POS・在庫・会員との連携、店舗スタッフが店頭で使う画面 | サービスカウンター業務支援、iPad対応業務システム |
作り直さず追加する: 既存システムの低コスト拡張
「店舗のデータをiPadで見たい」といった要望は、動いているシステムを作り直さなくても満たせることが多くあります。電算機器製造会社の事例では、稼働中のWebシステムに追加する形でiPadからPOS・棚卸データを閲覧できる機能を構築し、開発コストと導入期間を最小限に抑えました。切り分けの基準は次のとおりです。
追加で済む
既存のデータベースやAPIに外から読み書きできる。足りないのは閲覧や入力の画面で、既存側の処理を変えなくてよい。
作り直しを検討する
既存の技術がサポート切れで保守できる人がいない。機能を足すたびに既存側を直す必要がある。
先に確認すること
サーバー・データベース・認証の構成をうかがい、追加できる範囲と作り直したほうが安い範囲を見積もりの前に切り分けます。
モール型ECの分業設計
複数の店舗が出店するモール型ECで決め手になるのは、運営者と出店者の役割分担です。自治体の地域活性化施策として構築したモール型ECでは、決済と問い合わせを運営者が一括で担い、出店者は商品の登録と発送に専念できる設計にしました。
| 業務 | 運営者（管理者） | 出店者（各店舗） |
|---|---|---|
| 商品・注文 | 掲載ルールの管理 | 商品の登録・更新、注文の確認と発送 |
| 決済・問い合わせ | 決済処理とお客様対応を一元化 | 商品に関する質問への回答 |
| 精算 | 売上の集計と出店者への精算 | 自店の売上確認 |
ITに不慣れな店舗でも参加できるよう、出店者側の操作は必要最小限に絞ります。「誰が何をやるか」を画面を作る前に決めるのが近道です。
自社でECを8年運営して分かったこと
当社は鮮魚のモール型ECアプリ「UOICHI」を自社で企画・開発し、2016年から2024年まで運営しました。企画・開発・運営・集客・出店者対応・事業のクローズまでを当事者として経験しているので、多店舗の出店管理、EC決済、産直の在庫・配送、アプリとWebの併行運用で何が起きるかを、お客様のECを設計する段階で先回りできます。
開発事例
店舗業務とECに関連する事例を5件ご紹介します。店舗業務の2件（ホームセンター、電算機器製造会社の店舗向け）、独自要件のECの2件、自社運営のECの1件です。他業種を含む全事例は開発事例にまとめています。
大手ホームセンターの サービスカウンター業務支援システム
サービスカウンターの在庫確認と各種手続きが紙の伝票運用で、全国の店舗で使える統一の仕組みがありませんでした。在庫データとつながったリアルタイム在庫確認と伝票の電子化を軸に構築し、店頭スタッフがその場で在庫を確認して手続きを完結できる流れにしました。店頭での応対スピードと事務処理の正確性が向上しています。詳しくは大手ホームセンター向け サービスカウンター業務支援システムをご覧ください。
電算機器製造会社の iPad対応業務システム
POS・棚卸データを見るには事務所のPCが必要で、一方で稼働中のWebシステムを作り直す投資は避けたいというご要望でした。既存のWebシステムに追加する形でiPadから閲覧できる機能を構築し、低コスト・短期間で導入しています。詳しくは電算機器製造会社向け iPad対応業務システムをご覧ください。
中古販売業の 買い取り×販売を融合したECサイト
一般的なECパッケージは買い取り側のフローに対応できず、古物営業の本人確認をオンラインで済ませる仕組みも必要でした。販売用のECと買い取りフローを一つのサイトに融合し、見積もり依頼から買い取り成立までオンラインで進められるようにしたうえで、身分証のアップロード機能で法的要件を満たしています。詳しくは買い取り×販売を融合した ECサイトをご覧ください。
地域店舗が出店できる モール型ECサイト
個店でECを立ち上げる体力がなく、大手モールは手数料と運用負荷が高い地域の商店のために、自治体の施策として複数店舗が出店できるモール型ECをPHP・MySQL・AWSで構築しました。決済と問い合わせは運営者が担い、出店者は登録と発送に専念する分業設計です。詳しくは地域店舗が出店できる モール型ECサイトをご覧ください。
自社サービス 鮮魚ECアプリ「UOICHI」
全国の鮮魚を一尾から購入できるモール型ECをiPhone・Android・ブラウザの3形態で提供し、8年間運営しました。ソーシャルプロダクツ・アワード2023で受賞、日経コンピュータにも掲載されています。詳しくは鮮魚ECアプリ「UOICHI」の企画・開発・運営をご覧ください。
費用の目安
費用は画面数と連携先（POS、決済代行、既存システム）の数でほぼ決まります。小売・ECの案件は、規模をおおむね次のように読み分けてください（いずれも税別、要件定義からリリースまで）。
- 既存のWebシステムやPOSへの閲覧機能の追加など、単機能のツール（画面数10未満）: 100〜300万円程度
- ECサイトの新規構築（決済・外部API連携・会員認証を含む）: 500〜2,000万円
- 店舗横断で使う業務システムの新規開発（〜20画面）: 500〜1,200万円。本部と全店、複数部門で使う中規模（〜60画面）: 2,000〜6,000万円
決済代行の手数料、サーバーやドメインの費用、商品データの登録作業は開発費とは別にかかります。リリース後の運用保守費は開発費の15〜25%／年が目安です。規模ごとの工数と人月単価は受託開発の費用相場に、ECサイトを含む種類別の目安はシステム開発の費用・相場にまとめています。要件定義だけを先に依頼したい場合は要件定義の費用相場をご覧ください。
よくあるご質問
関連する記事・サービス
店舗とECの間に、手作業が残っていませんか
今お使いのECやPOSの構成、店頭で使っている伝票、ECでやりたい販売フローをお聞かせいただければ、パッケージで続けられる範囲と作るべき範囲、概算のレンジを無料でお答えします。1店舗・1機能からのご相談も歓迎です。
無料相談はこちら