倉庫が二つ、三つと増えていくと、Shopifyの在庫同期は「数字を流す仕組み」である前に、「どの数字をどこへ流すのか」を決める作業になります。その決めごとが、現実の倉庫とShopifyロケーションの対応づけ、いわゆるマッピングです。スプレッドシートを在庫の唯一の正とし、ロケーションごとのオンハンド在庫を別々の列で持つ運用でも、どの列がどのロケーションに届くのかが定まっていなければ、同期は正しく動きようがありません。
マッピングは一度決めれば終わりだと思われがちですが、実際には運用の中で静かに壊れていきます。ロケーションの名前が変わる、新しい店舗が途中で増える、シートに列が一本挿入される。どれも現場では日常的な出来事で、しかも在庫同期のことを考えて行われるわけではありません。この記事では、崩れにくいマッピングの組み立て方と、崩れかけたときに早く気づくための習慣を、順を追ってご紹介します。
マッピングは同期が依存する約束事です
設定画面の上では、マッピングは数分で終わる作業に見えます。倉庫を選び、ロケーションを選び、保存する。それだけです。けれども、その数分で決めたことに、以後のすべての同期が依存します。マッピングは設定項目というより、シート側とShopify側が交わす約束事だと考えたほうが実態に近いでしょう。約束が守られている限り数字は正しい場所へ届き、約束が静かに破られた瞬間から、誰にも気づかれないまま在庫がずれ始めます。ロケーションそのものの理解は、Shopifyロケーションの正体から始めるのが近道です。
表示名ではなく、変わらない識別子で結ぶ
最初に意識したいのは、何を手がかりに結ぶかです。いちばん手軽なのは表示名で、人間にとって分かりやすいのも確かです。ただし表示名は、いつでも誰かが変更できます。組織変更に合わせて「東京倉庫」を「東日本DC」に改めた、店舗名にブランド名を足した。そうした変更は現場では珍しくありませんし、在庫同期への影響を考えたうえで行われることは、まずありません。
ですから、突き合わせの手がかりは、人が気軽に書き換えない安定した識別子に寄せておくのが安全です。Shopifyのロケーションには固有の識別子があり、表示名を変えてもそれ自体は変わりません。シート側にも、表示名とは別に、その識別子を控える列を一本用意しておきましょう。人が読むための名前と、仕組みが照合するための識別子。この二本立てにしておくだけで、改名をきっかけとした事故はほとんど防げます。
識別子をすぐに用意できない事情がある場合でも、せめて「このロケーション名と、この列のヘッダーは勝手に変えない」という取り決めだけは共有しておいてください。名前で結ぶこと自体が悪いわけではありません。名前が変わりうるという前提を、誰も持っていない状態が危ないのです。
まずは一対一の対応から始める
二つ目の原則は、最初のマッピングをできるだけ単純にすることです。現実の倉庫ひとつに対して、Shopifyのロケーションひとつ。この一対一の形から始めてください。単純すぎるように感じるかもしれませんが、単純だからこそ、数字が合わないときに原因をたどれます。列とロケーションが一本の線で結ばれていれば、確認すべき場所はいつもひとつです。
最初から凝った形にしたくなる気持ちは分かります。二つの倉庫の在庫を合算してひとつのロケーションに出したい、安全在庫を差し引いた数を見せたい。そうした要望は、運用が進めば必ず出てきます。ただ、合算や加工を挟んだ瞬間、表示されている数字がどこから来たのかが見えにくくなります。まずは素直な一対一で走らせ、実際の受注と出荷を一巡させてから、必要なぶんだけ複雑さを足していくほうが、結果的に早く安定します。
対応表をチーム全員が見える場所に置く
三つ目は、決めたマッピングを頭の中ではなく、チームの誰もが見られる場所に書き残すことです。おすすめは、在庫を管理しているスプレッドシートにタブを一枚足して、そこに対応表を置く方法です。同期の設定と同じ場所にあれば、誰かが列を触ろうとしたときに自然と目に入ります。最低限、次の項目が並んでいれば十分です。
- 現実の倉庫や店舗の名前（現場が普段呼んでいる呼び方）
- Shopify側のロケーション名と、その固有の識別子
- シートのどの列がその拠点の在庫数を持っているか
- その拠点の数字を誰が更新しているか（担当者や部署）
- いつ、誰が、なぜこの対応を変えたかのひとこと
この一枚があると、担当者が交代しても、休暇中に別の人が対応することになっても、同じ判断ができます。逆にこれがないと、対応関係は設定した人の記憶の中だけに存在することになり、その人が席を外した日にすべてが止まります。マッピングを仕組みにするというのは、要するに、記憶を表に移すということです。
現場でよくある三つのかたち
ひとくちに倉庫といっても、Shopifyのロケーションとして扱うものの性格はさまざまです。ここでは実際によく見かける三つのかたちを取り上げ、それぞれマッピングでどこに気をつけるとよいかを見ていきます。自社の構成がどれに近いかを考えながら読んでみてください。
自社倉庫
もっとも素直なのが、自社で運営している倉庫です。在庫を数えているのも、出荷しているのも自分たちなので、シートの数字と現物のずれが起きにくく、更新の頻度も自分たちで決められます。マッピングとしては、倉庫ひとつにロケーションひとつを割り当てるだけで、ほとんど迷うところがありません。
注意点があるとすれば、同じ建物の中を「保管エリア」「返品置き場」「検品待ち」などに細かく分け、それぞれをロケーションにしたくなる場合です。社内の管理としては便利ですが、ロケーションが増えるほど、シートの列も、確認すべき数字も増えていきます。販売できる在庫を持つ場所だけをロケーションとして扱い、社内の区分は別の方法で管理するほうが、同期はずっと見通しよく保てます。
出荷もする実店舗
次に多いのが、店頭で販売しながら、オンライン注文の出荷も担う実店舗です。この形の難しさは、在庫が動く理由が二つあることにあります。店頭で売れて減る分と、オンラインの注文を出荷して減る分が、同じ棚の上で混ざるのです。シートの数字を更新するタイミングが遅れれば、そのぶんだけ売り越しの余地が生まれます。
マッピング自体は店舗ひとつにロケーションひとつで構いませんが、その列を誰がいつ更新するのかは、他の拠点より少し丁寧に決めておきましょう。開店前と閉店後のように更新のタイミングを固定し、同期のスケジュールもその直後に置いておくと、店頭の実態とオンラインの表示が近い状態を保ちやすくなります。
3PLや仕入先をロケーションとして扱う
三つ目は、外部倉庫（3PL）や、ドロップシップで直送してくれる仕入先を、ひとつのロケーションとして扱うかたちです。ここで扱う在庫は、自分たちの手元にありません。数字は先方から届く報告に依存し、その報告は日次だったり週次だったり、形式もまちまちです。
だからこそ、この種のロケーションでは「数字の鮮度」を対応表に書き添えておくことをおすすめします。誰から、どんな頻度で、どの形式で受け取った数字なのか。それが分かっていれば、多少の遅れを見込んだ運用ができますし、数字が合わないときに、シートの問題なのか先方の報告の問題なのかを切り分けられます。外部拠点は、対応づけそのものより、数字が届くまでの経路を書き残すことのほうが大切です。
マッピングが壊れる三つの場面
マッピングは、たいてい派手には壊れません。エラーが出て止まるより、静かにずれたまま動き続けるほうがずっと多いのです。ここでは、実際によく起きる三つの壊れ方を取り上げます。どれも防ぎようがないものではなく、起こりうると知っているだけで対処が変わります。
ロケーションが改名される
いちばん多いのが改名です。拠点の呼び方が変わる理由はいくらでもあります。移転した、運営会社が変わった、社内の呼称を統一した。そして名前を変えた人は、在庫同期のマッピングがその名前を手がかりにしているとは、たいてい知りません。
表示名で結んでいた場合、改名の瞬間に対応が切れます。運がよければ同期が「該当なし」で止まり、運が悪ければ別の似た名前の場所に数字が届きます。前者ならすぐ気づけますが、後者は数字が入っているぶん、しばらく気づけません。識別子で結び、対応表には表示名も併記しておく理由は、まさにここにあります。統合や無効化を伴う場合は、ロケーションの無効化・統合を安全に行う手順の順序を守ってください。
設計後に新しいロケーションが増える
二つ目は、シートの設計が終わったあとで、新しいロケーションが追加される場面です。ポップアップストアを開いた、繁忙期だけ外部倉庫を借りた、返品専用の拠点を作った。Shopify側では数分で追加できてしまうので、シート側の準備が置き去りになりがちです。
この場合、新しいロケーションに対応する列がシートに存在しないまま、Shopify上ではそのロケーションで在庫を持てる状態になります。結果として、そのロケーションの在庫だけが誰にも更新されず、古い数字のまま販売され続ける、ということが起こります。ロケーションを増やす作業と、シートに列を足して対応表を更新する作業は、必ずひと続きの手順として扱ってください。
シートの列がずれる
三つ目は、シートそのものの変化です。誰かが集計用の列を途中に挿入した、見やすさのために列の順序を入れ替えた、不要に見えた列を削除した。表計算ソフトの上ではごく自然な操作ですが、列の位置で在庫数を読み取っている場合、これは数字の行き先を付け替える変更に等しくなります。
しかも、値そのものは入り続けるので、同期はエラーになりません。大阪の在庫が東京のロケーションに、東京の在庫が別の拠点に、それぞれもっともらしい数として書き込まれます。列の追加や並べ替えを禁止する必要はありませんが、行ったときは必ず対応表を見直し、次の同期の前に確認する。この一手間が、静かなずれを防ぎます。
在庫同期の事故のほとんどは、止まったから起きるのではありません。止まらずに、間違ったまま動き続けたから起きるのです。
ずれに早く気づくための習慣
壊れ方が分かれば、対策は難しくありません。必要なのは高度な監視の仕組みではなく、いくつかの地味な習慣です。同期の前に確かめる、同期のあとに抜き取りで見る、そして後から追えるように記録を残す。この三つで、たいていのずれは小さいうちに見つかります。
本番の前に接続テストを通す
最初の習慣は、本番の同期を走らせる前に接続テストを通すことです。テストは、シートとShopifyの間の道が実際につながっているか、指定した列がねらいどおりのロケーションに向いているかを、在庫を書き換えずに確かめる手段です。数十秒で終わる作業ですが、この数十秒が、誤った数千個ぶんの書き込みを防いでくれます。
特に、対応表を更新した直後、シートの列に触れた直後、ロケーションを追加した直後は、必ずテストを挟んでください。「何も変えていないはずだから大丈夫」という判断がいちばん危ないところで、実際には誰かが何かを変えているものです。変更のあとには一度テストを通す、という習慣にしてしまえば、その判断自体が不要になります。接続テストの読み方は、同期前の接続テストにまとめています。
同期のあとに数点だけ突き合わせる
二つ目は、同期のあとの抜き取り確認です。全SKUを見る必要はありません。むしろ全部を見ようとすると続かないので、毎回同じ数点を決めて、それだけを見るようにします。次のような選び方をしておくと、少ない手間で広い範囲を見張れます。
- 01動きの速い定番SKUを一点。日々の数字が正しく届いているかの目安になります
- 02複数のロケーションに在庫を持つSKUを一点。列とロケーションの取り違えはここに現れます
- 03外部倉庫や仕入先に置いているSKUを一点。報告の遅れが数字に出ていないかを見ます
- 04最近追加したロケーションのSKUを一点。設定漏れはたいていここで見つかります
- 05在庫がゼロのはずのSKUを一点。ゼロが正しくゼロとして届いているかを確かめます
記録を残し、後からたどれるようにする
三つ目は、同期の記録を残しておくことです。いつ実行され、どのロケーションに、いくつの値が書き込まれたのか。この記録があると、「昨日の夕方から数が合わない」という相談を受けたときに、その時刻の前後で何が起きたかをたどれます。記録がなければ、原因の推測から始めるしかありません。
記録は、犯人探しのためではなく、切り分けのためにあります。同期がそもそも走っていなかったのか、走ったけれど古い数字を書いたのか、正しく書いたけれど現物のほうが動いていたのか。この三つは、対処がまったく違います。スケジュールで自動実行している場合はなおさら、実行の履歴とシートの更新履歴を、後から突き合わせられる状態にしておきましょう。
倉庫とロケーションの対応づけは、在庫同期の中でもいちばん地味な部分です。それでも、ここが曖昧なままだと、その先でどれだけ丁寧に数字を作っても、正しい場所には届きません。変わらない識別子で結ぶ、まずは一対一で始める、決めたことを見える場所に書き残す。そして、同期の前後に小さな確認を挟む。この積み重ねが、数字を信じられる状態を保ってくれます。