EC在庫管理「一元化できていない」から始まる失敗——多店舗展開の小売チェーン店長が実際に踏んだ3つの地雷と、立て直しの起点 ─ 在庫管理のDXに | 完全無償クラウド型ソフト「Spes」

失敗①　「もう売り切れ」なのに受注が止まらなかった

各モールの在庫数が連動していない場合、1つのモールで「残り3点」と表示されていた商品が、別のモールでほぼ同時に完売していることがある。

渡辺さんの場合、年末の繁忙期に人気のキャンドルホルダーで二重販売が発生した。楽天とYahoo!のどちらも「在庫あり」のまま受注を受け付け、実際の手元在庫は1点しかなかった。結果、片方の購入者に欠品のご連絡をしなければならず、クレームとキャンセルが同時に発生。そのモールの評価が下がり、翌月の自然検索順位も落ちた。

モールの評価低下は即座に売上へ響く。「欠品1件」ではなく「評価の毀損と売上機会の消失」がセットで起きる——この構造を、当時の渡辺さんは実感していなかったという。

失敗②　「どこに在庫があるか」がスタッフごとに違った

実店舗とEC倉庫の在庫を共有している場合、どちらの在庫を優先するかという判断基準が曖昧になりやすい。

渡辺さんの店では、実店舗スタッフがEC向けの商品を店頭で販売してしまうことが月に数回あった。売り場に並んでいる商品が「EC出荷予定の取り置き分」なのか「店頭在庫」なのかが、目視だけでは判断できない状態が続いていたためだ。スタッフは悪意なく動いているが、現場のルールと実態がずれていた。

こうした混乱が続くと、誰かが正しい在庫数を把握しているわけでもなく、誰もが「たぶん大丈夫」という感覚で動くようになる。これは小売業の現場ではよく起きる話で、渡辺さん特有の問題でもない。

失敗③　繁忙期の直前に棚卸しで数字が合わなかった

11月の棚卸しで、渡辺さんのチームはシステム上の在庫と実物の在庫に50点以上の差異を発見した。どのチャネルでどれだけ販売されたかの記録が各モールの管理画面に分散していたため、差異の原因を特定するだけで丸1日かかった。

原因はシンプルだった。Aという商品が、楽天で5点・Yahoo!で3点・実店舗で4点売れていたが、在庫の引き当てがそれぞれ独立して行われており、合計12点の売上に対して当初の在庫数との照合が誰もできていなかった。

棚卸し差異が大きいほど、翌シーズンの仕入れ判断も狂いやすい。「売れた数」ではなく「売れたように見えた数」を元に発注してしまうリスクが生まれる。繁忙期直前のこの混乱は、渡辺さんに「もう手作業での管理は無理だ」という認識を強く持たせるきっかけになった。

立て直しの起点——一元化を始めるときに整えること

まず確認すべきは「現在どのチャネルで在庫をどう持っているか」の全体像だ。楽天・Yahoo!・BASE・自社ECサイト・実店舗それぞれの在庫数を一覧で書き出すことが最初の作業になる。この段階で、チャネル間の在庫数の矛盾がどれほど大きいかが可視化される。

次に、在庫一元化のツールを選ぶ際に確かめるべき点として、以下が挙げられる。

複数モール対応の在庫管理システムでは、楽天・Amazon・Yahoo!などの受注データをAPI経由でリアルタイムに取得し、在庫の引き当てを自動で行う仕組みが一般的になっている。たとえばSpesのクラウド型在庫・受発注管理では、複数チャネルの在庫をリアルタイムで同期し、バーコード・ハンディ連携による実店舗との在庫一元管理にも対応している（機能詳細はこちら）。SKUが増えてきた段階での導入でも、柔軟なカスタマイズが可能な設計になっている。

連携テストの段階では、テスト商品を1SKU選んで在庫数を意図的に変動させ、各モールへの反映タイムラグを確認するのが実用的だ。「動くはず」ではなく「動いた」を確認してから本番移行する。

EC在庫の一元化、判断を先送りにするコストを見直す

渡辺さんが一元化を後回しにしていた期間、実際に発生したコストは「クレーム対応工数・評価低下による売上機会損失・棚卸し差異の調査時間」の3つだった。月次に換算すると、スタッフ2人分の工数に相当する時間が在庫管理の混乱対応に費やされていたという。

「ツールの月額費用が高い」という感覚は、現状維持の見えないコストと比較したときに初めて意味を持つ。損失の可視化と在庫一元化の効果を並べて検討した後に判断するのが、最も合理的な進め方だ。

Spesの機能ページでは、中小規模のEC事業者や多拠点小売向けの在庫連携機能について詳細を確認できる（参考情報として、e-Stat（政府統計ポータル）では電子商取引市場規模の推移も公開されており、EC事業者が抱える在庫管理負荷の背景を理解する参考になる）。

在庫一元化の具体的な進め方や、自社の現状にどのツールが合うかについて迷いがあれば、Spesへのお問い合わせからご相談ください。チャネル構成や現在の運用状況をお聞きしたうえで、適切な整理の仕方を一緒に考えます。

よくある質問

在庫一元化は、出店モールが2〜3チャネルでも必要ですか？

チャネル数が少なくても、在庫数が日次で変動する商品を扱っている場合は一元化の効果が出やすい。特に実店舗と並行してECを運営している場合、二重販売・在庫の優先順位の混乱は2チャネルでも十分に発生する。

既存のExcel管理から移行するのにどれくらいかかりますか？

商品マスタの整理が済んでいるかどうかで大きく変わる。SKU数が100以内で商品データが整理されている場合、テスト移行から本番稼働まで2〜4週間を目安にしている事業者が多い。商品マスタが分散している場合は、データ整理の工数を先に見積もることが現実的だ。

リアルタイム在庫更新でないと、どんな問題が起きますか？

定期バッチ（例：1時間ごとの更新）では、更新の間隔中に同一商品が複数チャネルで売れた場合に在庫数がマイナスになることがある。繁忙期のアクセス集中時に特に顕在化しやすく、キャンセル対応・クレーム対応の工数が一時的に急増する。