在庫数の更新は、全部を自動化しようとして止まるなら半分でいい

在庫の自動更新を作りかけて、途中でやめたことがあると思う。

止まった理由はたぶん技術ではない。「間違って在庫0を書き込んだら、どうなるんだろう」——その一点で手が止まる。

在庫更新は「転記（記録）」と「反映判断（発注量・モール優先度の決定）」の2つに分けられる。転記はスプレッドシート関数やGASに任せてよいが、判断は人に残す。半自動化で防げるのは転記ミスと二重入力で、需要変動による判断ミスまでは防げない。

• 在庫更新を1つの作業と見ず「転記」と「判断」に分けると、自動化できる範囲が見える
• 各モールのデータをスプレッドシートに集める転記部分は、関数やGASの定型処理に任せられる
• 半自動化で防げる事故と、防げない事故（需要変動・判断ミス）を先に区別しておく

全自動化が怖いのは、判断まで機械に渡す絵が浮かぶから

朝、出社してまずやることが決まっている。楽天の管理画面から昨日の受注データを落とし、Amazonの在庫レポートを落とし、自社カートの管理画面を開き、手元の在庫管理スプレッドシートに数字を打ち込む。数字が合わない行が数件出る。どこかで引当が二重になっているのか、返品の戻しが入っていないのか、順に追う。ここまでで小一時間。この作業を、毎朝やっている。

「在庫更新 自動化」で検索すると、出てくるのは在庫連携サービスの比較記事ばかりだ。月額いくら、対応モールがいくつ、初期費用がいくら。だが多くの担当者が本当に引っかかっているのは、そこではない。引っかかっているのは、機械が勝手に在庫数を書き換えて、売れる日に在庫0で表示され、売り逃す絵が浮かぶことだ。あるいは逆に、在庫がないのに注文を通してしまい、キャンセル連絡とレビューの低評価が残る絵が浮かぶ。

この不安には理由がある。「在庫更新」という一語のなかに、性質のまったく違う2つの作業が同居しているからだ。ひとつは記録すること。入荷した数を書く、出荷した数を引く、モールごとにバラバラの数字を1か所に集める。もうひとつは決めること。何個発注するか、どのモールに何個割り当てるか、この在庫を切らしていいのか。

「自動化しますか」と聞かれたとき、頭に浮かぶのは後者のほうだ。だから怖い。そして怖いので何も自動化せず、結局いちばん機械に向いている前者まで手で打ち続けることになる。おかしな話で、実際に事故を起こしているのは、決めることではなく打ち込むことのほうが圧倒的に多い。

だから最初にやるべきは、ツール選びではない。作業を2つに割ることだ。転記は渡す。判断は残す。この線を自分の手で引いてしまえば、「どこまで自動化するか」という漠然とした問いは、「この行は転記か、判断か」という答えの出る問いに変わる。この記事は、その線の引き方と、線の下側だけをスプレッドシートに任せる組み立て方の話をする。

なお、受発注から在庫まで含めた業務全体のどこを機械に渡せるかという広い線引きは、EC受発注・在庫管理の自動化は、どこからAIに渡していいのかにまとめてある。本記事はそのうち「在庫数の更新」という一工程だけを、実際に手を動かす粒度まで下ろしたものだと考えてほしい。

在庫更新という作業を「転記」と「反映判断」に分解する

線を引くには、まず作業を並べる必要がある。頭のなかで「在庫更新」と一括りにしているものを、実際に手が動いている順に書き出す。ある複数モール運用の現場を想定すると、おおむねこうなる。

手順	やっていること	種別
1	各モールの管理画面から受注・在庫のCSVを落とす	転記
2	落としたCSVをスプレッドシートに貼る	転記
3	モール別の商品番号を自社SKUに読み替える	転記
4	入荷予定・返品戻りを反映する	転記
5	SKU単位で在庫を合算し、前日との差分を出す	転記
6	残数の少ないSKUを拾い出す	転記
7	そのSKUを追加発注するか、いくつ発注するかを決める	判断
8	どのモールに何個出すか配分を決める	判断
9	決めた数を各モールの在庫項目に反映する	転記（結果の書き戻し）

9工程のうち、判断は7と8の2つしかない。残り7つは、入力が決まれば出力も決まる作業だ。ここに毎朝の小一時間が消えている。

どちらに分類すべきか迷ったら、次の3つで見分けられる。

• ルールを言葉にできるか。「モール別商品番号がこの列にあるので、対応表を引いて自社SKUに置き換える」は言葉にできる。「この商品は来週動きそうだから多めに持つ」は言葉にできない。できないものは判断だ
• 同じ入力なら、いつも同じ出力でいいか。合算は何度やっても同じ答えでいい。発注量は、同じ在庫数でも来週にセールがあるかどうかで変わる
• 間違えたとき、あとから検出できるか。転記ミスは元データと突き合わせれば必ず見つかる。判断ミスは、売り逃したあと・在庫が余ったあとにしか分からない

3つとも「はい」なら転記であり、機械に渡してよい。ひとつでも「いいえ」があるなら判断であり、人が押す場所として残す。この分類は、ツールを何にするかとは無関係に成立する。スプレッドシートでも、GASでも、有料の在庫連携サービスでも、線の位置は変わらない。変わるのは、線の下側を何で実装するかだけだ。

もうひとつ重要なのは、9番目の「決めた数を各モールに反映する」が転記に分類されることだ。決めるのは人だが、決まった数を管理画面に打ち込む作業自体は機械向きである。ここを判断だと思い込んで手打ちを続けている現場は多い。押すのは人、打つのは機械、という分け方ができる。

転記だけを自動化する範囲：各モールのデータを1枚に集める

転記を機械に渡すと決めたら、数式を書く前に決めることがある。在庫数の正本をどこに置くかだ。ここを決めないまま自動化すると、シートが増えるだけで、どれが正しいのか誰も答えられない状態になる。実際、シートが複数枚に増えたまま「どれが最新か」を誰も断言できない状態は起きやすい。

前提として確認しておきたいのは、基幹システムやWMSがある現場では、正本はそちらだということだ。その場合、これから作るスプレッドシートは正本ではなく、モール側の数字と基幹側の理論在庫を突き合わせるための作業台になる。ここを取り違えて、基幹があるのにシート側を正本として運用すると、会計や倉庫の数字と二重管理になって最悪の形になる。以下の話は「在庫の正本がスプレッドシートにある現場」か、「基幹はあるがモールとの突合だけシートでやっている現場」を想定している。自分がどちらかを先に確定させてほしい。

そのうえで、シートを役割ごとに3層に分ける。

• 取込シート（モール別・加工しない）：楽天の在庫、Amazonの在庫、自社カートの在庫を、それぞれ落としたままの列構成で置く。並べ替えも、列の削除もしない
• 統合シート（自社SKU単位）：取込シートを自社SKUに読み替えて突合し、SKUごとに1行に集約する
• 判断シート（人が見る画面）：残数が少ない、直近の出荷が急に伸びた、といった要注意のSKUだけを並べる

取込シートで加工しないのは、事故ったときの切り分けのためだ。統合シートの数字がおかしいとき、取込シートが生データのままなら「元データが変だったのか、突合の数式が変だったのか」を数分で判定できる。取込の時点で列を削ったり並べ替えたりしていると、この判定ができなくなる。

実務でいちばん効くのは、数式ではなく対応表

半自動化で最も手間がかかり、最も効果が出るのは、実はここだ。自社SKUとモール別商品番号の対応表を1枚作る。楽天側の商品管理番号やSKU管理番号、Amazon側の出品SKUやASIN、自社カート側の商品コード。これらは同じ商品でも別の文字列であり、しかも過去の担当者が付けた表記ゆれが必ず混ざっている。

この対応表がないと、どんな数式を書いても突合できない。逆に対応表さえ整えば、あとの集計は関数で片が付く。半自動化の作業量の感覚でいえば、対応表の整備が大半で、数式を書くのは最後の一手間という配分になることが多い。そして、この対応表は後述する「スプレッドシートを卒業して外部サービスに移る」局面でも必ず要求される資産になる。作り損にはならない。

集める方法は2系統ある

取込シートにデータを載せる経路は、大きく2つに分かれる。

• CSVを落として貼る／取り込む：各モールの管理画面から在庫・受注のCSVを出力し、シートに読み込ませる。準備が軽い代わりに、落とすタイミングまでの遅れが残る
• API経由で取得する：楽天RMS WEB APIやAmazon SP-APIといった正規の口から取得する。遅れは小さくできるが、認証情報の取得や実装の手間がかかる

どちらを選ぶかは、後述する「更新の遅れが何分まで許せるか」で決まる。なお、モール側の出力メニュー名や項目名は改定されることがあるため、実際の列構成と出力手順は現行の管理画面で確認してほしい。ここを固定的に覚え込むと、仕様が変わったときに気づけない。

複数のスプレッドシートにまたがってデータを引く場合、IMPORTRANGEで参照する形がよく使われる。

=IMPORTRANGE("参照元スプレッドシートのURL", "在庫リスト!A2:E")

この関数には最初に踏む必要のある手順と、いくつかの癖がある。初回は参照先へのアクセスを許可する操作を挟まないと参照が通らない。参照元のシート名を変えたり、列の順番を入れ替えたりすると追従せず、エラーとして表に出る。さらに、参照できるデータ量や更新の反映タイミングには上限がある前提で設計したほうがいい。具体的な上限値は公表されている範囲が限られるため、数値を暗記するのではなく「重くなったら分割する」構えで組むのが実際的だ。

SKU単位の集計には、モール別の取込シートを縦に連結してから集約する形が使える。

=QUERY(
  {
    QUERY(楽天取込!A:C, "SELECT A, C WHERE A IS NOT NULL", 0);
    QUERY(Amazon取込!A:E, "SELECT B, E WHERE B IS NOT NULL", 0)
  },
  "SELECT Col1, SUM(Col2) WHERE Col1 IS NOT NULL
   GROUP BY Col1 LABEL Col1 'SKU', SUM(Col2) '合計在庫数'"
)

ここに挙げた式は設計の型であって、そのまま貼れば動く完成品ではない。列の位置も、ヘッダー行の有無も、各社のシート構成で変わる。自分の環境で少量のデータから検証してほしい。

「反映案は機械が作り、確定は人が押す」半自動の組み立て方

関数で集計まで来たら、次は「決めた数をモールに書き戻す」部分だ。ここを全自動にすると冒頭の不安がそのまま現実になる。そこで反映案を作るところまでを機械、確定を押すところを人に割る。GASを使う場合の骨格はこうなる。

1. GASが統合シートを読み、現在のモール在庫数と、あるべき在庫数の差分を計算する
2. 差分のあるSKUだけを「反映待ちシート」に書き出す。何を何個から何個に変えるのか、変更前後の数字を並べて出す
3. 担当者が反映待ちシートを見て、問題ない行を承認する
4. 承認された行だけを、GASが実際にモール側へ反映する

3の「承認する」の作り方には、実装の重さと誤操作の起きにくさがトレードオフになる3つの形がある。

方式	操作	誤操作の起きにくさ	実装の重さ
チェックボックス	承認列のチェックをONにすると編集トリガーで反映が走る	低い（隣のセルを触って誤発火しうる）	軽い
カスタムメニュー	行を選び、メニューから「選択行を承認」を実行	中〜高	中
確認ダイアログ	実行前に「SKU◯◯を12→3に更新します」と出して確認させる	高い	重い

最初はチェックボックスで十分なことが多い。ただし、承認列の隣に他の入力列を置かない、承認済みの行はロックする、といった配置の工夫は入れておきたい。誤操作は「操作が難しいから」ではなく「隣にあるから」起きる。

人が押す形にすると、副次的な効果がひとつある。いつ・誰が・何を承認したかの記録が残ることだ。承認時にタイムスタンプと実行者を別シートへ追記しておくと、在庫がおかしくなったときに遡れる。手作業のときは「たぶん昨日の夕方に直した」で終わっていた話が、行として残る。

GASには、1回の実行時間や1日あたりのトリガー実行時間、設定できるトリガーの個数に上限がある。公式ドキュメントで示されている値は改定されうるので、着手時に現行の割り当てを確認してほしい。設計上の要点は数値の暗記ではなく、いつか上限に当たる前提で組むことにある。全SKUを毎回まわす作りは、SKUが増えた日に必ず落ちる。差分のある行だけを処理する、処理した位置を保存して次回はその続きから走らせる、といった分割を最初から入れておくほうが結果的に楽だ。

この「人間が読んでいた情報を機械に読ませ、確定だけ人に残す」という組み立ては、在庫に限った話ではない。受注メールの本文から必要な項目を抜き出す作業に同じ考え方を当てた例を受注メールからのデータ抽出を自動化するにまとめている。対象が在庫数か注文情報かが違うだけで、設計の骨は同じだ。

自動化してはいけない判断：発注量・欠品リスク・モール優先度

線の上側、つまり人に残す判断は3つに集約される。いくつ買うか（発注量）、切らしていいか（欠品リスクの許容）、どこに出すか（モール優先度）だ。なぜこれらを機械に渡すべきでないのか、理屈ではなく具体的な場面で押さえておきたい。

過去の出荷実績には、来週のイベントが写っていない

安全在庫を自動計算する考え方自体は古くからある。直近の平均出荷数に、リードタイムと変動幅を掛けて持ち数を決める。理屈は正しい。だがこの計算が見ているのは過去の出荷実績だけで、次に挙げるようなものは1件も入っていない。

• お買い物マラソンやスーパーSALEの買い回り。同じ商品でも、期間中と平常時では動き方が変わる
• クーポンやポイント倍率の設定。自社が撒いた原価が、そのまま需要の形を変える
• 実店舗や催事との在庫共有。ECの帳簿上は動いていないのに、棚からは減っている
• SNSや外部メディアでの露出。前日まで平常だった商品が、翌朝には想定外の受注数になっている
• 競合の動き。主力商品の競合が在庫を切らした、あるいは大幅な値下げを始めた
• 営業やマーケからの予定。大口受注の内示、来週から出す広告の出稿計画
• 予約販売・入荷待ち受付。売れた数と、いま出せる数が一致しない
• セット品・同梱品。1件の受注で複数SKUの在庫が動く
• 賞味期限やロット違い。数は足りているが、出せない在庫が混ざっている

どれも「過去の平均」の外側にある事情だ。機械はこれを知らないまま、堂々と発注数を出してくる。その数字が正しく見えてしまうところが、いちばん危ない。

そもそも判断には、両立しない要求が同時に来ている

もう一段深いところに、機械に渡せない理由がある。発注の判断は、単一の正解を探す作業ではないからだ。欠品は避けたい。だが在庫は圧縮したい。この2つは同時には満たせない。仕入先の最小ロットは決まっていて、半端な数では発注できない。期末が近ければ在庫を抱えたくないという別の力も働く。

つまり実際にやっているのは最適解の計算ではなく、矛盾する要求のなかで妥協点を選ぶことだ。どの要求を今回は優先するかは、その月の資金繰り、上長の方針、前回どちらを取って何が起きたかで変わる。この重み付けはシートのどこにも書かれていない。書かれていない以上、機械は計算しようがない。ここを「ルール化すれば自動化できるはず」と考えて数式に落とそうとすると、たいてい半年後に誰も意味の分からない係数が残る。

モール優先度は、売上ではなく手残りで決まる

在庫が限られていて、複数モールのどこに割り当てるかを決める場面も同じだ。単純に売れている順に割り当てればいい、とはならない。同じ1個を売っても、モールによって手元に残る金額が違うからだ。モールの手数料に加えて、ポイント原価、クーポン原価、送料負担、広告費が乗る。粗利で並べ替えると、売上の順位とは違う並びになることがある。

さらに、数字に出てこない事情もある。特定モールで在庫切れを繰り返すと検索順位や露出面で不利になる、という運用上の判断。基幹となる販路を優先して切らさない、という方針。これらは「今月の粗利を最大にする」という関数には入っていない。

正しい半自動化は、判断を奪わず材料を揃えること

ここで「じゃあ判断のところは今までどおり全部手作業か」となると、半分しか進まない。判断そのものは人に残すが、判断に必要な材料を揃えるところまでは機械の仕事だ。判断シートに並べるべきは、次のような列になる。

• 現在庫数（自社SKU単位・全チャネル合算）
• 直近7日と直近28日の出荷数、その比率（急に動き出した商品が目に入る）
• 入荷予定日と予定数、仕入先のリードタイムと最小ロット
• いまの在庫が何日分にあたるか
• モール別の在庫配分の現状
• 直近の粗利率（ポイント原価・クーポン原価を引いた後）

この6列が揃っていれば、発注量を決めるのに要する時間は短くなる。手作業のときに時間を食っていたのは、決めることではなく、決めるための数字を集めることだった。半自動化の効果は「判断が速くなった」ではなく「判断の前の準備が消えた」として現れる。

半自動化で防げる事故と、防げないリスク

導入前に、期待値を正しく置いておきたい。半自動化は万能ではない。むしろ「これは直らない」を先に知っておくほうが、運用が長持ちする。

種別	内容	半自動化で
転記ミス	CSV貼り付け時の列ズレ、1行ズレ、桁の打ち間違い	防げる
二重入力	同じ入荷を2回反映、複数人が同じ行を別々に更新	防げる
更新漏れ	「今日はまだ楽天側を反映していない」が誰にも見えていない	防げる
属人化	担当者が休むと在庫更新が止まる	ある程度防げる
需要の読み違い	売れると思って多く発注し、在庫が残る	防げない
イベント時の欠品	セール中に想定以上に出て切らす	防げない
実棚とのズレ	帳簿は10個だが、棚には8個しかない	防げない
元データの誤り	そもそも入荷時の検品数が間違っている	防げない

下4行に共通しているのは、スプレッドシートの外側で起きていることだ。半自動化が改善するのは「情報が正しく運ばれること」であって、「情報がそもそも正しいこと」ではない。実棚と帳簿のズレは棚卸しでしか埋まらないし、検品数の誤りは入荷時のオペレーションでしか防げない。ここを混同して「自動化したのにズレる」と落胆する必要はない。もともと守備範囲が違う。

静かに壊れるほうが、止まるより怖い

半自動化の運用でいちばん厄介なのは、エラーで止まることではない。エラーを出さずに間違った数字を出し続けることだ。参照元のシート名が変わって参照が切れれば、少なくとも表面にエラーとして出る。だが、モール側のCSVに列が1つ増えて位置がずれた場合、数式は何事もなく別の列の数字を合計し続ける。誰も気づかないまま、在庫数だけが少しずつ現実から離れていく。

これを完全に防ぐ監視の設計は、それだけで別の話になる。ここでは、最初に入れておくと効く最低限だけを挙げる。

• 最終更新時刻を統合シートの上部に出す。いつの数字を見ているのかが一目で分かるだけで、「更新されていないことに気づかない」がかなり減る
• 取込した行数を前回と比べる。昨日は1,200行あったのに今日は40行、という状態は、たいてい取得の失敗を意味する。極端に減ったら処理を止める
• エラー値の個数を数えるセルを1つ置く。参照エラーや不一致がシート全体でいくつ出ているかを数え、0以外なら色が変わるようにしておく

3つとも実装は数分で終わる。凝った異常検知を組む前に、これだけは入れておきたい。

作って終わりにはならない。壊されるのは外からだ

もうひとつ、半自動化を検討する時点で織り込んでおくべきコストがある。保守は必ず発生するということだ。しかも壊れる原因の多くは、自分の書いた数式ではなく外側にある。モール側がレポートの出力形式や項目を変える。利用していたAPIの旧バージョンが提供終了になる。認証やログインの手順が変わる。どれも自社の都合とは関係なく降ってくるし、こちらの準備が整うのを待ってはくれない。

だからこそ、最初から凝った仕組みを組まないほうがいい。仕組みが複雑なほど、外部の変更に追随する工数が増える。取込シートを加工せず生のまま置くこと、処理を差分だけに絞ること、承認を人に残すこと。この記事で挙げてきた設計は、どれも「壊れたときに直しやすい」という意味でも効いてくる。半自動化は作った日が完成日ではなく、直し続ける前提で持つものだと考えておきたい。

スプレッドシート運用の限界と、卒業を検討するサイン

ここまでの話は、すべて「いまのスプレッドシート運用のまま作業量を減らす」という前提で書いてきた。だが当然、この形には限界がある。どこで限界が来るのかを先に知っておくと、限界に達したときに慌てなくて済む。

よく語られるのは「SKUが◯件を超えたら専用ツールへ」という目安だ。EC運用系の情報では300〜500件あたりが分岐点として挙げられることがある。ただしこの数字は、特定の調査に紐づいた根拠のある数値というより、経験則として共有されている目安に近い。SKU数だけで決まる話ではない、と考えたほうがいい。実際に効いてくるのはSKU数 × チャネル数 × 更新頻度 ÷ 触れる人数のような掛け算のほうだ。300SKUでも4モールを1日3回更新していればつらいし、2,000SKUでも自社カート1本で1日1回なら回る。

件数より、次の5つが出ているかで見る

• シートを開くのに待たされるようになった。関数の再計算が終わるまで手が止まる。数式を1つ直すたびに待つ。この待ち時間は、削減したはずの転記時間を静かに食い戻す
• GASの上限を回避する工夫が、本業になってきた。処理を分割し、続きから走らせ、時間帯をずらす。こうした設計が在庫管理そのものより手間になったら、載せる器を間違えている
• ズレを直す作業が週次で発生している。月に一度の棚卸しでの微修正ならまだいい。毎週どこかが合わなくて調査に半日使っているなら、仕組みの側に問題がある
• 担当が休むと止まる。数式の意図が本人にしか分からない、承認の判断基準が本人の頭にしかない。属人化はスプレッドシートの宿命ではないが、放っておくと必ずそうなる
• 即時性の要求が上がった。マラソンやセールの最中、1時間前の在庫数では意思決定に使えない。CSVを落として貼るサイクルでは追いつかない、と感じ始めたら分岐点が近い

この記事ではツールの比較はしない。どのサービスが合うかは、扱う商材、倉庫の形、既存の基幹システムとの関係で変わりすぎるからだ。ただ、卒業を考えるときに知っておきたいことが1つある。

卒業しても、対応表とルールは自分で用意することになる

外部のサービスやOMSに移せば、SKUマスタも配分ルールも向こうが決めてくれる、ということはない。むしろ導入時にまず要求されるのが、自社SKUとモール別商品番号の対応表であり、どのチャネルを優先するかの方針であり、安全在庫の考え方だ。表記ゆれが残ったマスタのまま移行すると、移行先で同じズレが再生産される。

つまり、半自動化の過程で作った対応表と、転記／判断の線引きは、卒業しても持って行ける資産になる。逆に言えば、この整理をせずにいきなりツールを入れても、手作業がツール上の手作業に置き換わるだけで終わりやすい。順番としては、まず線を引いて対応表を作り、それでも追いつかなくなったら器を替える、が無理がない。

1チャネル・1カテゴリから始める、半自動化の第一歩

最後に、明日から動かせる形にしておく。全体を一気に組み替えようとすると、たいてい途中で止まる。始めるなら、対象を極端に絞る。

手順

1. 1週間、いまの作業を計測する。ストップウォッチまでは要らない。作業のたびに「何時何分から何時何分、楽天の在庫取込」とメモを残すだけでいい。1週間分あれば、どの作業が何回・何分かかっているかが出る
2. いちばん回数の多い転記を1つだけ選ぶ。1回あたりが長い作業ではなく、回数が多い作業を選ぶ。半自動化の効果は頻度に比例する
3. 対象を1チャネル・1カテゴリに絞る。SKU数が少なく、回転が速く、事故っても影響が限定的なところがいい。全モール全SKUを最初の相手にしない
4. 2週間、手作業と並走させる。自動化した結果と、これまでどおり手で作った結果を毎日突き合わせる。ここを飛ばして切り替えると、ズレていたことに気づくのが実害の後になる
5. ズレが出なくなってから、手作業をやめる。並走期間中にズレが出たら、それは失敗ではなく仕様の発見だ。列の構成、対応表の抜け、返品戻りの扱い。だいたいこのあたりから出る
6. 次の1チャネルに広げる。1本目で作った対応表と3層のシート構成は、2本目でそのまま使える。2本目以降は明らかに速い

効果は「削減時間」ではなく「判断に回った時間」で測る

成果を報告するとき、つい「毎朝60分の作業が15分になりました」と言いたくなる。だが、この測り方には落とし穴がある。浮いた45分が別の雑務で埋まったら、社内的には何も変わっていないように見えるからだ。

測るなら、こう置き換えたい。浮いた時間で何を見るようになったか。欠品しそうなSKUに前もって手を打てた件数、モール間の在庫配分を見直した回数、仕入先へのリードタイム確認を先回りできた件数。数え方は粗くていい。転記が減った分を判断に使った、という筋が通ることが重要だ。ここが示せないと、半自動化は「暇になっただけ」と受け取られかねない。

そしてこれは、社内での立ち位置の話でもある。在庫連携サービスを入れられる人は珍しくない。しかしどこまでを機械に渡し、どこから先を人の判断として残すかを自分で設計できる人は、それほど多くない。この線引きができる人は、ツールが変わっても、モールが増えても、同じ考え方で対応しやすい。転記が自動化されるほど、線を引ける人の役割は残りやすい。

その線引きが実務者としてどう評価されるのか、社内での評価や転職市場での見られ方についてはEC担当者の市場価値はどこで決まるのかで整理している。半自動化を設計できることが、自分の職務のなかでどこに位置づくのかを考えるときに読んでほしい。

よくある質問

GASが書けなくても半自動化はできますか

できます。転記の削減効果が最も大きいのは、実はコードではなく自社SKUとモール別商品番号の対応表と、シートを取込／統合／判断の3層に分ける構成です。この2つを整えたうえで、複数シートの参照と集計を関数で組むところまでなら、GASなしでも到達できます。GASが必要になるのは、決めた数値をモール側へ書き戻す段階と、決まった時刻に自動で取り込む段階です。まず関数だけで組み、手作業が残る箇所が明確になってから、その部分にだけコードを足すほうが失敗しにくくなります。

在庫連携サービスを入れれば、この作業は全部なくなりますか

転記の部分は大きく減りますが、判断は残ります。発注量、欠品を許容するかどうか、モール間の在庫配分の優先度は、どのサービスを使っても最終的に自社で決めることになります。また、導入時には自社SKUとモール別商品番号の対応表や、優先チャネルの方針を提出することになるのが一般的です。本記事の線引きと対応表の整備は、サービス導入を選んだ場合でも前段として必要になります。順序としては、線を引いてから器を選ぶほうが無理がありません。

モールのAPIを使うべきか、CSVで十分か、どう決めますか

判断軸は1つです。在庫数の更新が何分遅れるまで許容できるか。1日1回の更新で運用が成立しているなら、CSVを落として取り込む形で足ります。セール期間中に在庫が動く速さに追いつけない、1時間前の数字では判断できない、という状況が常態化しているなら、API経由の取得を検討する段階です。ただし認証情報の取得や利用条件は各モールの規定に従う必要があり、仕様も更新されます。着手前に現行の公式ドキュメントで要件を確認してください。

自動化を進めると、自分の仕事がなくなりませんか

なくなるのは転記であって、判断ではありません。本記事で分解した9工程のうち、機械に渡せるのは入力が決まれば出力も決まる作業です。何個発注するか、どのモールに何個割り当てるか、この在庫を切らしていいかは、過去の出荷実績の外にある事情を知っている人にしか決められません。むしろ、転記に使っていた時間が判断に回ることで、これまで手が回らなかった欠品の予防やチャネル間の配分見直しに着手できるようになります。仕事の量ではなく、内容が入れ替わると考えるほうが実態に近いはずです。

あわせて読みたい: 一元管理ツールの選び方｜楽天RMSだけで複数モールを回す限界とチェックリスト

あわせて読みたい：欠品と過剰在庫のアラートを、自分で組む