Shopifyで在庫同期を始めるとき、意外と後まで効いてくるのがロケーションをいくつ作るかという判断です。倉庫や店舗の数だけ素直に並べればよさそうに見えますが、ロケーションの数は同期のしくみそのものの大きさを決めてしまいます。多すぎても少なすぎても、日々の在庫更新はじわじわと重くなっていきます。
この記事では、列のマッピングや同期の設定といった具体的な作業に入る前の、「そもそもいくつに分けるか」という設計判断だけをじっくり扱います。分けるべき場面、まとめてよい場面、そして迷ったときの決め方まで、ご自身の売り場や倉庫を思い浮かべながら読み進めていただければ幸いです。
ロケーションの数が同期の重さを決める理由
ロケーションは、在庫を保管し、出荷し、販売する場所の単位です。Shopifyは在庫数をロケーションごとに別々に持つため、ロケーションを増やすほど在庫の見え方は細かくなります。ただしその細かさは、同期する側から見ると、そのまま維持すべきデータ量と手間の増加になって返ってきます。まずはこの構造をはっきりさせておきましょう。そもそもロケーションが何を指すのかは、Shopifyロケーションの正体で整理しています。
行と列は掛け算で増えていきます
在庫同期の規模は、SKUの数だけでは決まりません。実際に維持しなければならない数量は、SKUとロケーションの組み合わせの数です。500SKUを1ロケーションで扱っているなら管理するのは500個の数字ですが、ロケーションが4つになれば2,000個になります。「倉庫が2つ増えただけ」という体感と、実際のデータ量の増え方には、かなり大きな開きがあります。
スプレッドシートを在庫の正となる場所として使う場合、ロケーションごとの手持ち数は別々の列として持つのが基本の形です。つまりロケーションを1つ足すと、シートには列が1本増えます。列を増やすこと自体は簡単ですが、その列を毎回正しく埋め続けられるかどうかが、同期の精度をそのまま左右します。
- 500SKU × 1ロケーション = 500個の数量を維持することになります
- 500SKU × 4ロケーション = 2,000個の数量を維持することになります
- ロケーションを1つ足すごとに、シートには列が1本増えます
- 空欄や更新の止まった値も、同期のたびに「その数字」として扱われます
ここで見落とされがちなのが、埋まりきらない列の存在です。誰も更新していない列は、同期のたびに古い数字を持ち込むか、判断に迷う空欄として残り続けます。維持しきれない列を最初から作らないことが、結果としていちばん確実な精度対策になります。
ロケーションの数だけ、数える人が必要になります
ロケーションは、Shopifyの管理画面で作るだけなら数分で終わります。けれども、そこに入る数字は誰かが実際に数えなければ生まれません。棚卸しの担当、入出庫を記録する人、差異が出たときに調べる人。ロケーションを1つ作るということは、これらの役割をもう1セット増やすということでもあります。
運用が回らなくなるロケーション設計には、共通のパターンがあります。「そこを数える人が決まっていない」ロケーションが混ざっているのです。数える人がいない場所の数字は、いつのまにか誰も信じなくなり、最終的には同期の対象から外されてしまいます。増やすかどうか迷ったら、まず「そこを数えるのはどなたですか」と自問してみてください。具体的な名前で答えられないなら、まだ分けるタイミングではありません。
場所が増えるほど、ズレの発生源も増えます
在庫のズレは、たいてい「動いたのに記録されていない」瞬間に生まれます。店舗間の移動、倉庫内の棚替え、サンプル出しや返品の戻し入れ。ロケーションが多いほど、こうした移動の経路が増え、記録漏れの機会も比例して増えていきます。
しかもロケーションをまたぐ移動は、合計在庫が変わらないぶん気づきにくいという厄介さがあります。全体では合っているのに、内訳だけが少しずつずれている。この状態は、実際に「在庫があるはずの場所から出荷できない」場面になって初めて表面化します。ロケーションを増やすときは、その分だけ移動の記録ルールも一緒に決めておく必要があります。
ロケーションを分けるべき3つの条件
では、どんなときに分けるべきなのでしょうか。距離や建物の数ではなく、次の3つの観点で見ると判断がぶれにくくなります。どれか1つでもはっきり当てはまるなら、分ける価値があります。
在庫が物理的に別々に置かれているとき
いちばん分かりやすい条件は、在庫が物理的に離れた場所にあり、片方の在庫をもう片方の注文にそのまま使えない場合です。東京の倉庫にある10個と、大阪の店舗にある3個は、合計すれば13個ですが、大阪の注文にすぐ使えるのは3個だけです。この違いを1つの数字で表そうとすると、必ずどこかで実態と食い違います。
ロケーションを分けておけば、同じ商品でも「東京は在庫あり、大阪は在庫切れ」という状態をそのまま表現できます。シート側でも、東京用の列と大阪用の列を分けて持つだけで済みます。物理的に別々のものは、データの上でも別々にしておく。これがいちばん素直で、後から迷いの少ない設計です。
出荷元が違うとき
2つ目の条件は、そこから実際に注文を出荷しているかどうかです。出荷元が違えば、配送料も、お届けまでの日数も、送り状の発行元も変わります。どのロケーションから引き当てて出荷するかをShopifyが判断できるのは、そもそもロケーションが分かれている場合だけです。
逆に言えば、そこから一度も出荷しない保管専用のスペースは、必ずしも独立したロケーションである必要はありません。ただし将来そこから出荷する予定があるなら、早めに分けておいたほうが移行はラクになります。「いま出荷しているか」と「近いうちに出荷する見込みがあるか」の両方で考えてみてください。
別々に数えているとき
3つ目は、棚卸しの単位です。別々のタイミングで、別々の人が数えているなら、その数字はすでに別々のものとして存在しています。それをわざわざ1つに合算してからShopifyに入れる運用は、足し算の手間が毎回増えるだけでなく、どちらの数字が古いのか分からなくなる原因にもなります。
数えている単位と、同期する単位を一致させる。地味ですが、これが在庫同期の精度をいちばん確実に上げてくれる考え方です。現場で使っている棚卸し表がすでに場所ごとに分かれているなら、それがそのままロケーション設計の答えになっていることも少なくありません。
- 01在庫が物理的に別々に置かれていて、片方をもう片方の注文にそのまま使えない
- 02そこから実際に注文を出荷している、または近いうちに出荷する予定がある
- 03別々のタイミング・別々の担当者が、その在庫を数えている
分けなくてよい場面
分ける条件と同じくらい大切なのが、分けなくてよい場面をはっきりさせておくことです。次のようなケースでロケーションを増やすと、得られるものに比べて維持の手間ばかりが大きくなってしまいます。分けすぎた結果として起きる事故は、マルチロケーション同期でやりがちな失敗にまとめました。
同じ棚を複数のチームが触っているだけのとき
オンライン担当と店舗担当がそれぞれ在庫を見ていても、実際に置かれている棚が同じなら、それは1つのロケーションです。組織の都合でロケーションを分けてしまうと、同じ棚の同じ在庫が2つの数字として存在することになり、どちらを信じればよいのか分からなくなります。
この場合に必要なのは、ロケーションを分けることではなく、その棚の数字を誰が更新するのかを1つに決めることです。担当者が複数いること自体は問題ありません。数字の入口が複数あることが問題なのです。シートを在庫の正とするなら、その棚に対応する列を更新する人を決めておくだけで、多くの混乱は消えていきます。
引当済みや不良品といった状態を分けたいとき
予約分、検品待ち、不良品といった区分は、場所ではなく在庫の状態です。これらを別ロケーションとして作りたくなる気持ちはよく分かりますが、そうすると出荷元でも棚卸し単位でもないロケーションが増え、注文の引き当て先の候補にも紛れ込んでしまいます。
こうした状態の区分は、シート側の列として持つほうが扱いやすいことが多いです。たとえばシートに販売可能数と検品待ちを別の列で持ち、Shopifyに同期するのは販売可能数の列だけにする、という形です。ロケーションは場所を表し、シートの列は状態も表せる。この役割分担を意識すると、設計はぐっとすっきりします。
レポートのためだけに分けたくなったとき
エリア別の売れ行きが見たいから、商品カテゴリごとに在庫を把握したいから。そうした理由でロケーションを増やすのは、たいていの場合おすすめできません。レポートのための区分は、あとから集計で作り直せます。しかしロケーションを増やした分の運用負荷は、毎日かかり続けます。
判断に迷ったら、「この区別を見て、誰かが何かを決めているか」と問いかけてみてください。価格を変える、補充をかける、販売を止める。そうした具体的な行動につながっていない区別なら、それは分析の切り口であって、ロケーションとして持つべきものではありません。
完璧なロケーション構成を初日に当てる必要はありません。運用しながら、足りない境界線だけを足していけば十分です。
ちょうどよい数に落ち着かせる進め方
ここまでの条件を踏まえたうえで、実際にどう決めていけばよいのでしょうか。おすすめは、粗く始めて、シートで試して、定期的に見直すという3段階の進め方です。順に見ていきましょう。
迷ったら粗く始めます
分割は後からでも比較的簡単にできますが、統合はそうはいきません。すでに数量が入っているロケーションを1つにまとめるには、過去の数字の付け替えと、そのあいだの運用の停止が必要になります。だからこそ、迷っている時点では分けないほうが安全です。
具体的には、まず「実際に出荷元になっている場所」の数だけロケーションを作るところから始めてみてください。多くのショップにとって、これは2つか3つに収まるはずです。しばらく運用してみて、内訳が見えないことで実際に困る場面が出てきたら、そのときに分ければ十分間に合います。1つから増やしていく移行の進め方は、単一ロケーションから複数ロケーションへの移行にまとめています。
Shopifyで作る前に、シートで形にしてみます
ロケーションを増やす前に、まずスプレッドシート上でその形を作ってみるのがおすすめです。想定するロケーションのぶんだけ列を用意し、実際の在庫数を1週間ほど手で埋めてみる。それだけで、その設計が日々の運用に耐えるかどうかが、かなりはっきり見えてきます。
このとき確認したいのは、数字の精度ではなく「列が埋まるかどうか」です。毎回空欄になる列があれば、そのロケーションはまだ早いというサインです。逆にすべての列が無理なく埋まるなら、その構成でShopify側のロケーションを作り、接続テストで列とロケーションの対応を確かめてから、本番の同期に進めます。シート上での形は、1枚のシートで複数ロケーションを扱う列設計がそのまま使えます。
- 想定するロケーションのぶんだけ、シートに列を用意します
- 1週間ほど、実際の数量を手で埋めてみます
- 毎回空欄のまま残る列がないかを確認します
- 問題なければShopifyにロケーションを作り、接続テストで対応を確かめます
- そのうえでスケジュール同期に載せ替えます
見直しのタイミングを先に決めておきます
ロケーション設計は、一度決めたら終わりというものではありません。店舗が増えたり、物流を外部に切り替えたり、季節商品を別の場所に置いたりと、事業のほうが先に変わっていきます。だからこそ、四半期に一度は見直すといったタイミングを最初に決めておくと、設計が現実から離れていくのを防げます。
見直しのときに見るべきものは、そう多くありません。ここ3か月まったく数量が動いていないロケーションはないか、逆に1つの列に複数の場所の在庫が混ざっていないか、そして各ロケーションを数える人がいまも決まっているか。この3点だけで、増やすべきか減らすべきかはだいたい判断できます。