在庫同期を運用していると、いつかは「流してはいけない数字を流してしまった」という瞬間がやってきます。シートの並べ替えで行がずれた、テスト用の値を消し忘れた、単位が箱数と個数で入れ替わっていた。原因はさまざまですが、気づいたときの気持ちはだいたい同じで、心臓が一段速くなります。
けれども、在庫同期の事故は落ち着いて手順を踏めばほぼ確実に戻せます。大切なのは順番です。被害の拡大を止める、正しい数字を確定させる、確認しながら上書きする、そして再発しない形に直す。この記事では、その4段階を実際の手順として追いかけます。すでに間違いが起きてしまった前提で書いていますので、いま対応中の方はそのまま上から読み進めてください。
最初の5分でやること : 被害を止める
事故に気づいた直後の5分は、直すための時間ではなく、これ以上悪くしないための時間です。ここで数字を触りたくなる気持ちをぐっとこらえられるかどうかで、その後の復旧の難易度が大きく変わります。
まずスケジュール同期を止める
最初にやるべきことは、スケジュール同期の一時停止です。理由は単純で、間違った数字がシートに残っている限り、定期実行はそれを何度でも忠実にShopifyへ書き戻すからです。手作業でShopify側を直しても、次の実行でまた同じ間違いに上書きされてしまいます。
この「直したそばから戻される」状態は、復旧作業でいちばん消耗するパターンです。しかも本人は直したつもりでいるので、原因に気づくまでに時間がかかります。スケジュールを止めるのは数十秒で終わる操作ですから、状況の把握より先に、まずここを押さえてしまいましょう。停止したら、いつ止めたかをメモしておくと後の検証がぐっと楽になります。
どこまで広がったかを把握する
次に確かめるのは影響範囲です。全商品が壊れているのか、特定のSKUだけなのか。ロケーションが複数あるなら、どの拠点まで届いているのか。そして見落としがちなのが時間軸で、その間違った数字が何時間表に出ていたのかによって、対応すべきことの量が変わります。
特に重要なのが、その間に注文が入ったかどうかです。実際の在庫より多い数字を出してしまっていた場合、売り越しが発生している可能性があります。逆に少なく出していた場合は、売れるはずだった商品が品切れ表示になっていただけなので、在庫を戻せば済みます。前者は在庫の修正に加えて、注文への対応まで含めて考える必要があります。
この把握は、完璧でなくてかまいません。5分で分かる範囲を書き出すだけで十分です。むしろここで詳細を詰めすぎると、その間も誤った在庫が公開され続けます。ざっくりと輪郭をつかみ、後の工程で精度を上げていく。そのくらいの温度感で進めてください。
- 01対象のSKU : 全商品か、特定のカテゴリか、シートの特定の行範囲だけか
- 02対象のロケーション : どの拠点の実在庫が書き換わったか
- 03時間の幅 : 誤った数字が公開されていたのは何時から何時までか
- 04注文の有無 : その時間帯に該当SKUの注文が入っていないか
- 05在庫のずれる向き : 実際より多く出したのか、少なく出したのか
正しい数字を知る前に上書きしない
影響範囲が見えてくると、次は「とりあえず正しそうな数字を管理画面に打ち込んでしまおう」という誘惑が湧いてきます。これは気持ちとしてはよく分かるのですが、復旧の観点ではおすすめできません。記憶や勘で入れた数字は、間違っていても間違いだと気づけないからです。
さらに厄介なのは、手で入れた値が「正しい数字」の履歴を上書きしてしまう点です。事故前の値を確認する手がかりが減り、あとから真実を突き止めるのが難しくなります。この段階でやるべきなのは修正ではなく、記録です。いまShopifyに何が入っているか、対象SKUのスクリーンショットやCSVエクスポートで残しておくと、後の突き合わせで必ず役に立ちます。
正しい数字を突き止める
被害の拡大を止めたら、次は「本当は何個だったのか」を確定させる作業です。ここで頼れる手がかりは3つあります。シート側の編集履歴、Shopify側に残った証跡、そして最後は現物の棚です。上から順に当たっていきましょう。
シートの編集履歴が事故前の値を教えてくれる
在庫の単一の真実をスプレッドシートに置いているなら、いちばん確実な手がかりはシート自身の変更履歴です。多くの表計算ツールは、いつ・誰が・どのセルをどう書き換えたかを保持しており、事故前の状態をそのまま復元できます。まずは間違った同期が走った時刻の直前まで履歴をさかのぼり、当時の値を確認してください。
ここで注意したいのは、履歴からいきなり全体を巻き戻さないことです。事故の原因になった編集以外にも、その後に入った正当な入荷や棚卸しの更新が混ざっている可能性があるからです。安全なのは、履歴を「読む」用途に限定して、正しい値を別のシートに書き出すやり方です。復元ではなく参照として扱うと、良い更新まで消してしまう二次被害を避けられます。変更履歴の使い方そのものは、変更履歴で在庫シートを復元する手順で詳しく説明しています。
Shopify側にも証跡は残っている
シートの履歴だけでは足りない場合、Shopify側にも判断材料があります。商品の在庫には変更履歴があり、いつどの経路で数量が動いたのかを追えます。同期による更新なのか、注文による引き当てなのか、人手の編集なのかを見分けられるので、事故の入り口を特定するのに向いています。
あわせて、その時間帯の注文とフルフィルメントの状況も見ておきましょう。事故の間に出荷まで進んだ注文があれば、その分は実際に棚から出ています。つまり事故前の値をそのまま書き戻すと、今度は多すぎる数字になってしまいます。復旧で必要なのは「事故前の値」ではなく「事故前の値から、その後の実際の動きを反映した値」だという点を忘れないでください。
- 在庫の変更履歴 : 数量がいつ、どの経路で動いたかを確認できます
- その時間帯の注文 : 誤った在庫のもとで成立した注文がないかを見ます
- フルフィルメントの状況 : 出荷済みなら実在庫はすでに減っています
- 同期のログ : どの実行が問題の値を書き込んだのか、時刻を突き合わせます
食い違ったときは現物を数えるしかない
シートの履歴とShopifyの証跡を突き合わせても数字が一致しない、という場面はどうしても出てきます。このとき、どちらが正しいかを机の上で議論しても答えは出ません。在庫は現実の物ですから、最終的な判定は棚を数えることでしか下せないのです。
とはいえ、全商品を棚卸しする必要はありません。数える対象は、食い違いが出たSKUと、事故の影響を受けたロケーションだけで十分です。範囲を絞れば数十分で終わることも多く、その手間に見合うだけの確実さが手に入ります。数え終えたら、その数をまずシートに反映し、シートを正とした状態に戻してから次の段階へ進みましょう。
現物を数えるときは、数えた時刻も一緒に控えておくと安心です。数えている最中に出荷が走れば、その数はもう過去のものになります。数えた時刻と、その後に動いた分が分かっていれば、差を足し引きして今の正しい数に直せます。急いでいるときほど、この一行のメモが後で効いてきます。
修正を安全に反映する
正しい数字が確定したら、いよいよShopifyへ戻します。ここで急いで全件を流すと、事故の上に事故を重ねることになりかねません。範囲を絞り、確かめ、それから広げる。この3拍子で進めます。
あえて狭い範囲から流す
最初の修正同期は、対象を意図的に狭めます。影響を受けたSKUのなかから5件から10件ほど、できれば性格の違うものを選んでください。複数ロケーションを持つSKU、在庫がゼロになっているSKU、事故の間に注文が入ったSKU。こうした条件をひととおり含めておくと、少ない件数で多くのことを確かめられます。
流す前に接続テストを実行して、宛先のストアとロケーションが意図どおりかを確認しておくのも大切です。復旧作業は焦りやすく、普段なら間違えない場面で取り違えが起きます。特に開発ストアと本番ストアの両方を扱っている場合、この数十秒の確認が二次被害を防いでくれます。広げる前の確認項目は、フル同期前のチェックリストが使えます。
小さく確かめてから広げる
小さなまとまりを流したら、管理画面で一件ずつ目視で確認します。見るのは実在庫の欄です。販売可能の数字は未出荷の注文の影響を受けるため、シートの値と一致しないことがありますが、それは不具合ではありません。実在庫が意図どおりに入っていれば、その修正は正しく届いています。
ここで一件でも想定と違う値があれば、範囲を広げてはいけません。原因が分からないまま件数を増やすと、切り分けが一気に難しくなります。数件のうちに立ち止まって理由を突き止めるほうが、結果的にずっと早く終わります。すべて一致していることを確認できたら、対象を段階的に広げ、最後に全件を流しましょう。
- 01影響を受けたSKUから、条件の異なる5件から10件を選びます
- 02接続テストで宛先のストアとロケーションを確認します
- 03その小さなまとまりだけを同期し、管理画面で実在庫を目視で確認します
- 04全件一致していれば範囲を広げ、一件でも違えば止めて原因を調べます
- 05全体の同期を終えたら、最後にスケジュールを再開します
スケジュール再開はいちばん最後
全件の修正が終わったら、最後にスケジュール同期を再開します。順番が最後である理由ははっきりしていて、スケジュールはシートの内容を無条件に信じるからです。シート側がまだ正しくない状態で再開すると、せっかく直した数字がもう一度上書きされてしまいます。
再開する前に、シートが正になっていることをもう一度確かめてください。棚卸しで数え直した値は反映済みか、事故の原因になった編集は取り除かれているか、作業中に入った入荷は入力されているか。確認できたら再開し、次の自動実行が走ったあとにもう一度だけログと数件の在庫を見ておくと安心です。ここまで確認できれば、復旧は完了と言えます。
同じ事故を繰り返さないために
在庫が元に戻ったら、復旧作業としては終わりですが、運用としてはもう一歩あります。同じ事故がもう一度起きない形に整えるところまでが対応です。ただし、ここで力を入れすぎないことも同じくらい大切です。
人ではなく仕組みの弱いところを探す
事故のあと、つい「誰が入力したのか」に関心が向きがちですが、これは追いかけても得るものが少ない問いです。シートを共有して運用している以上、誰かが手を滑らせることは前提として織り込むべきで、たまたまその日その人だっただけ、というケースがほとんどだからです。
代わりに問うべきなのは、なぜその操作が事故につながる構造になっていたのか、です。並べ替えで行がずれたのなら、SKUと数量が別の行になりうる形になっていたということ。単位を間違えたのなら、列の見出しが単位を明示していなかったということ。原因を仕組みの側に置き換えると、直すべき対象が具体的になり、次の一手が決まります。
この置き換えには、もうひとつ良い効果があります。原因が仕組みの話になれば、当事者が萎縮せずに事実を話せるようになることです。何が起きたかを正確に共有できるチームほど、事故から学べる量は多くなります。振り返りの席では、誰がではなく何がという言葉から始めてみてください。
対策は「ひとつだけ」に絞る
事故の直後は、思いつく限りの対策を並べたくなります。しかし、いくつもの新しいルールを一度に足すと、たいてい数週間で守られなくなります。運用に定着するのは、手間がほとんど増えないものだけです。だからこそ、追加するガードレールはひとつに絞ってください。
選ぶ基準は、今回の事故を確実に止められたかどうかです。行がずれたのなら、並べ替えの範囲を固定するか、編集できる範囲を制限する。値の種類を間違えたのなら、入力できる値に制約をかける。宛先を取り違えたのなら、同期前に接続テストを挟むことを習慣にする。ひとつ入れて定着したら、次の機会にまたひとつ足せば十分です。次に同じことが起きたとき当日中に気づくには、在庫同期の監視とアラートの仕組みが効きます。
- 保護範囲 : 数式列や参照用の列を、うっかり編集できないようにします
- 入力規則 : 数量列に負の値や文字が入らないよう、値の種類を縛ります
- 接続テスト : 同期の前に宛先を確認する数十秒を、手順として固定します
- 対象の限定 : 同期する範囲を必要な行だけに絞り、作業用の行を巻き込まないようにします
手順を書き残して次の人に渡す
最後にやっておきたいのが、今回たどった手順を短い文書にまとめることです。難しいものである必要はありません。スケジュールをどこで止めるか、影響範囲として何を確認するか、正しい数字をどこで探すか、修正はどの順番で流すか。A4一枚に収まる分量で十分です。
この文書が効いてくるのは、次の事故が起きたときに担当していたのが自分ではない場合です。手順が残っていれば、その人は焦りながら判断を組み立てる必要がなく、上から順にたどるだけで済みます。在庫同期の事故でいちばん被害を大きくするのは、対応そのものではなく、対応の迷いです。一度書いておけば、そのコストを次からゼロにできます。
在庫同期の事故は、起きた瞬間はとても大きく見えますが、実際にはやるべきことが決まっている作業です。止めて、調べて、確かめながら戻す。そして最後に、同じ形で繰り返さないよう仕組みをひとつ直す。この流れを一度経験しておけば、次に同じことが起きても、慌てずに手を動かせるはずです。