この記事では、Googleスプレッドシートで在庫管理表を設計する基本から、共有設定、SUMIFやCOUNTIF、QUERYなどの関数の使い方、棚卸しと履歴を残す運用方法まで順に説明します。商品数や拠点数が増えたときに起きる限界も整理し、表を改善して使い続けるのか、在庫管理システムへ移行するのかを判断する材料を提供します。
この記事で分かること
- Googleスプレッドシートで在庫管理を始めるときのシート構成
- 入庫・出庫・棚卸しを記録し、現在庫を計算する考え方
- SUMIF、COUNTIF、IFERROR、QUERYなどの関数の使い分け
- 共有権限、入力規則、保護範囲で事故を減らす方法
- 履歴、棚卸し、バックアップを含めた日々の運用ルール
- 在庫表が複雑になったときに見直すべきシステム化の基準
Googleスプレッドシートが在庫管理に使われる理由
複数人で同じ情報を確認できる
ファイルをメールで回覧する方法では、どれが最新か分からなくなりやすく、担当者が編集している間は別の人が入力できません。Googleスプレッドシートなら、ブラウザ上の一つのファイルを共有し、入庫担当、出庫担当、管理者が同じ表を確認できます。編集内容が保存されるため、パソコンごとに別ファイルを保管する運用よりも、更新場所を集約しやすい点が利点です。
ただし、同じ表を見られることと、業務データが自動的に正しくなることは別です。入力する列、数量の単位、更新するタイミングを先に決め、表の構造を守れるようにします。特に「現在庫」のセルを直接書き換える設計は、いつ誰が何を動かしたか追跡できなくなります。現在庫は入出庫の記録から計算し、修正が必要な場合は調整理由を履歴へ残す形が安全です。
小規模な業務の試作に向いている
商品数が少なく、保管場所が一つで、入出庫の種類も限られている場合は、必要な項目を絞った表から始められます。新しいパッケージを選び、初期設定や教育を行う前に、現場でどの情報を記録するか確認するための試作にも活用できます。入力画面や帳票の要件が固まっていない段階では、列を追加して試す柔軟さが役立ちます。
反対に、複数の拠点が同時に入出庫し、受注引当、ロット、賞味期限、仕入先別の発注まで扱う場合は、表の追加だけで対応しようとすると管理が複雑になります。最初から将来の機能をすべて詰め込まず、いま困っている作業と必要な精度を確認することが出発点です。
在庫管理表の基本構成を決める
商品マスタと入出庫履歴を分ける
一枚の表に商品名、現在庫、入庫日、出庫先、担当者をすべて詰め込むと、並べ替えや集計のたびに入力済みの行を壊しやすくなります。まず、商品を一意に識別する商品マスタと、数量が動いた事実を記録する入出庫履歴を分けます。商品マスタには商品コード、商品名、カテゴリ、単位、保管場所、発注点、停止フラグなどを登録します。入出庫履歴には日時、商品コード、区分、数量、相手先、担当者、備考を記録します。
現在庫は、商品マスタの数量セルへ手入力するのではなく、入出庫履歴を集計して表示します。入庫を正の数量、出庫を負の数量として一列に統一する方法もありますが、担当者が意味を理解しにくい場合があります。入庫数量と出庫数量を別列にし、区分の入力規則を設ける方法なら、入力画面の分かりやすさと集計のしやすさを両立できます。
列名と数量の単位を固定する
列名が担当者ごとに違うと、集計式や引き継ぎで混乱します。例えば「商品コード」「商品名」「入庫数量」「出庫数量」「在庫調整数量」「処理日」「担当者」のように、意味が分かる名称を最初に決めます。個数、箱、キログラムなどの単位も商品マスタで定義し、一つの商品の履歴で単位を混在させないことが重要です。
箱で仕入れ、個で販売する商品では、入数を登録して基準単位へ換算します。現場が箱数を入力するのか、個数へ換算した値を入力するのかを決め、両方を入力して二重に数えないようにします。単位換算を数式で行う場合も、入数が空欄や文字列になっていないか確認する列を用意します。
拠点と在庫状態を区別する
倉庫、店舗、車載在庫、検品待ちなどを同じ「在庫」として合計すると、実際に出荷できる数量を誤認します。履歴に拠点コードと状態を持たせ、利用可能、引当済み、検品待ち、返品予定などを分けて表示します。最初は一拠点でも、将来的に増える可能性があるなら、拠点列を後から追加するのではなく、最初から空欄を許容した列として用意すると拡張しやすくなります。
関数で現在庫と発注候補を計算する
SUMIFで商品ごとの入庫・出庫を集計する
商品コードが入出庫履歴のA列、入庫数量がD列、出庫数量がE列にあるとします。商品マスタの各行にある商品コードを参照して、入庫合計を求める式は=SUMIF(入出庫履歴!A:A,A2,入出庫履歴!D:D)です。出庫合計はE列を対象にし、現在庫を「期首在庫＋入庫合計−出庫合計」として計算します。実際のシートでは範囲を必要な行に絞り、列を挿入したときに意図しない範囲を参照しないか確認します。
数量の修正を履歴に追記する場合、過去行を上書きせず、新しい調整行を追加します。これにより、日付を指定した集計や、棚卸し前後の差異確認ができます。入力者が同じ行を何度も修正すると履歴としての意味が失われるため、運用ルールとして「記録後は原則追記」と共有します。
COUNTIFとIFで未入力や発注点を確認する
商品マスタに発注点があり、現在庫が発注点以下になった商品を見つけるには、=IF(現在庫セル<=発注点セル,"発注確認","")のような判定を使います。発注確認と表示されたら即座に注文するのではなく、発注残、入荷予定、販売予定、最低発注数量を確認します。COUNTIFは、商品コードの重複や、状態が「未処理」の行数を確認するのに利用できます。
未入力をゼロとして扱うと、登録漏れと本当のゼロ在庫を区別できません。IFERRORでエラー表示を隠すだけにせず、商品コードが存在しない、数量が数値でない、単位が未登録といった異常を別の確認列に表示します。エラーを見えなくすることは、データを正しくすることではありません。
QUERYやFILTERで確認用の一覧を作る
履歴が増えると、元データを直接並べ替えて探すよりも、確認用の一覧を別シートで作るほうが安全です。QUERYを使えば、拠点や期間、状態などの条件で対象行を抽出し、商品別の集計を表示できます。FILTERは「発注確認」の商品だけを表示するような簡単な一覧に向いています。関数を複雑にする前に、どの担当者がどの画面を何の判断に使うかを決めます。
関数による一覧は、元の履歴と自動的に同期できる一方、条件式を変更した人が意図せず対象を外すリスクがあります。式を置くシートと入力するシートを分け、関数セルを保護します。月別集計やカテゴリ別集計を追加するときも、元データに直接列を増やすのではなく、目的ごとの表示シートへ切り出すと保守しやすくなります。
共有設定と入力ミスを減らす仕組み
閲覧者と編集者を役割で分ける
共有リンクを知っている全員が編集できる設定は、手軽でも在庫表には向きません。管理者、入力担当、閲覧だけの担当を分け、必要な範囲へ権限を付与します。社外の仕入先へURLを渡す必要がある場合は、在庫表全体ではなく、必要な情報だけを別ファイルや帳票で共有します。退職や異動があったときは、共有相手を見直す手順も決めておきます。
入力規則と保護範囲を設定する
区分、拠点、在庫状態、担当者などは自由入力にせず、候補から選べる入力規則を使います。商品コードも、可能なら商品マスタを参照した選択にし、表記ゆれを減らします。関数を置いた現在庫列や見出し行は保護し、入力担当が書き換えられるセルを必要な範囲に限定します。保護は誤操作を減らす機能であり、入力内容の正しさや悪意のある持ち出しを完全に防ぐものではありません。
更新時刻と担当者を記録する
履歴に処理日だけでなく、入力した担当者と確認者を残すと、差異が出たときの調査が進めやすくなります。関数で現在時刻を表示するだけでは、後から値が変わることがあります。確定した処理日時を入力する運用か、別のフォームやスクリプトで記録する運用かを決めます。重要な数量を変更した場合は、備考に理由と関連伝票番号を残します。
共有運用の設計や、現在の表がどこまで使えるかを整理したい場合は、開発前診断・ロードマップの相談で、業務の範囲とデータ構造を確認できます。診断を使うかどうかにかかわらず、先に困っている作業、入力者、必要な出力を紙に書き出すと、表の修正とシステム化を比較しやすくなります。
毎日の入力から棚卸しまでの運用ルール
入力の締め時間と処理の順番を決める
入庫した商品を先に棚へ置き、後でまとめて入力すると、入力前の数量を出庫してしまうことがあります。入荷、検品、棚入れ、出庫、返品などの状態を業務に合わせて整理し、いつ表へ記録するかを決めます。バーコード読み取りを使わない場合でも、伝票番号や写真など、元の取引をたどる情報を備考へ記録すると確認が早くなります。
営業日終了時に一括更新する運用では、その間に別の人が編集しないルールが必要です。リアルタイム入力が必要な業務なら、入力担当ごとに仮置きシートを作って後で転記するより、同じ履歴へ追記する方法を優先します。担当者が交代する時間帯や休日の入力方法も、例外として事前に決めておきます。
棚卸しの差異を調整履歴に残す
棚卸しでは、表の計算在庫と実地数量を並べ、差異の理由を確認します。差異を見つけたら現在庫セルを直接書き換えるのではなく、棚卸し調整という区分で履歴を追加します。数量、棚卸し日、拠点、確認者、理由を残せば、次回の棚卸しで同じ場所や商品を重点確認できます。破損、紛失、数え間違い、入出庫の記録漏れなど、理由を選択式にすると集計もしやすくなります。
バックアップと変更履歴を確認する
共有ファイルでも、入力ミスや列削除は起こります。ファイルの変更履歴で復元できる場合がありますが、履歴の確認を担当者任せにすると、必要な時に戻せません。日次または週次でスナップショットを保存する、確定した月のシートを編集不可にする、バックアップの保管場所と期間を決めるなど、復旧手順を明文化します。
バックアップはコピーを作るだけでなく、復元できるかを確認して初めて役に立ちます。テスト用の複製で、商品マスタ、入出庫履歴、集計シートが正しく参照されるかを定期的に確認します。個人のアカウントだけが所有者になっている場合は、会社で管理できる所有権や引き継ぎ方法も確認します。
Googleスプレッドシートで起きやすい限界
同時編集と処理順の管理が難しい
複数人が同じ商品の数量を同時に入力すると、入力順が業務の順番と一致しないことがあります。入庫と出庫を別々のシートへ入力して後で合算する構成では、反映前の数字を見て判断する時間帯も生まれます。更新が多い時間帯に、誰がどの処理を確定したかを表だけで制御するのは難しくなります。
入力担当が増えたときは、フォームなどで入力項目を固定する方法もあります。ただし、フォームを追加すれば必ず解決するわけではありません。訂正、取消、返品、分納といった状態変化をどう記録するかを先に定め、担当者が二重入力しない流れを作る必要があります。
権限とデータ分離に限界がある
シートの一部を保護しても、ファイル全体を閲覧できる人から情報を完全に隠せるとは限りません。店舗ごとに自店の在庫だけを見せ、本部には全店を見せるような細かな権限が必要になった場合、ファイルを分けるほど転記や集計が増えます。閲覧範囲と入力範囲が業務上の役割と一致しないなら、権限を前提にしたシステムを検討する時期です。
履歴・承認・連携が複雑になる
発注、受注、出荷、入荷を一連の状態として管理したい場合、シートでは状態列と関数が増えていきます。メールや別の販売管理表と連携するためにコピー＆ペーストを繰り返すと、転記時点で在庫がずれる原因になります。承認者、承認日時、差し戻し理由、送信済みかどうかまで追跡する必要があるなら、単なる一覧表ではなく業務システムとして設計する必要があります。
次のような状態が複数重なったら、関数の追加だけで延命する前に、在庫管理システムの導入方法を比較してください。
- 複数の担当者が同時に更新し、同じ商品に重複や上書きが起きる
- 倉庫・店舗ごとの在庫を権限付きで管理する必要がある
- 受注や発注、入荷、棚卸しの状態を一つの履歴で追跡したい
- 在庫差異を調査するたびに別ファイルやメールを探している
- 関数を変更できる人が限られ、担当者が休むと修正できない
表を改善するかシステム化するかの判断手順
まず業務とデータの境界を整理する
いきなりツールを選ばず、商品数、拠点数、1日の入出庫件数、入力者数、扱う単位、必要な履歴期間を整理します。次に、在庫の正解をどの処理で確定するかを決めます。検品が終わった時点で入庫とするのか、発注した時点で入荷予定へ加えるのかなど、業務上の定義が曖昧なままでは、どのツールを選んでも数字が一致しません。
表の改善で解消できる問題を切り分ける
列名の不統一、入力規則の不足、数式の保護漏れ、バックアップ手順の欠如は、表の設計を見直すことで改善できる場合があります。まずは入力シートと集計シートを分け、履歴を追記型にし、異常を確認できる列を設けます。そのうえで、一定期間運用しても同時編集の衝突や権限の問題が残るなら、システム化の要件が明確になります。
導入範囲を小さくして比較する
すべての拠点を一度に切り替える必要はありません。商品数が多い一つのカテゴリや、一つの倉庫を対象に、商品マスタ、入出庫、棚卸し、在庫確認までを試します。試験期間中は、入力時間、差異の件数、確認に要した時間、例外処理の数を記録します。表の改善、既製システム、個別開発を同じ業務条件で比べると、価格だけでなく現場の負担も判断材料になります。
よくある質問
Googleスプレッドシートだけで在庫管理を続けられる規模はどのくらいですか？
商品数や拠点数だけで一律に決めることはできません。入力頻度、同時編集者、必要な権限、ロットや期限の有無、受注・発注との連携、履歴をどれだけ厳密に残すかで適切な方法は変わります。少人数・少拠点で、履歴と入力ルールを守れるなら表を改善しながら使える場合があります。更新衝突、転記、権限設定、監査の負担が増えた時点で、システム化を比較するのが現実的です。
関数が壊れたときに現在庫を復元できますか？
履歴を追記型で残し、商品マスタと関数シートを分けていれば、数式を戻して再計算できる可能性があります。現在庫を直接上書きしている場合は、変更前の数量や理由が分からず、復元に時間がかかります。定期的な複製、関数セルの保護、棚卸し調整の記録を組み合わせ、復元手順を実際に試しておくことが大切です。
既存のExcel在庫表をGoogleスプレッドシートへ移せますか？
移せる場合がありますが、数式、マクロ、外部リンク、文字コード、日付や数量の形式を確認する必要があります。変換後に現在庫が一致するか、入力規則や権限が意図どおりかを、少数の商品で照合してから全体へ広げます。移行を機会に、不要な列や古い商品コードを整理すると、移行後の運用が安定しやすくなります。
まとめ
Googleスプレッドシートは、複数人で在庫を確認しながら、入出庫履歴と関数を使って小規模な管理を始められる手段です。商品マスタと履歴を分け、現在庫を記録から計算し、入力規則と保護範囲を設定すると、単純な手入力表よりもミスを減らせます。棚卸し調整、担当者、処理日時、バックアップまで含めて運用を設計することが重要です。
一方で、同時編集の衝突、拠点ごとの権限、受注や発注との連携、承認と監査の履歴が増えると、関数やシートを足すだけでは管理しにくくなります。現在の表を改善して解消できる問題と、業務の仕組み自体を変える必要がある問題を切り分け、商品数や拠点数だけでなく、入力者と例外処理の負担を基準に判断してください。
在庫管理を見直す際は、まず実際の入出庫手順と、数字がずれる場面を整理します。そのうえで、スプレッドシートの改善、既製システム、個別の在庫管理システムを同じ条件で比較すると、必要な投資と導入範囲を決めやすくなります。
