在庫管理システムを作るときに最初に決めるべきなのは、「どの機能を作るか」ではなく「在庫の数字を誰が、いつ、何に使うか」です。在庫管理の目的が欠品を防ぐことなのか、過剰在庫を減らすことなのか、棚卸しの手間を減らすことなのかによって、必要な機能と精度がまったく変わります。目的が曖昧なまま機能を並べると、大きなシステムを作ったのに現場は相変わらずExcelで数字を合わせている、という状態になりがちです。
自社開発か既製のクラウドサービスかの判断は、業務の独自性と他システムとの連携要件で決まります。入出庫と棚卸し、在庫数の確認が中心で、業務が一般的な流れに沿っているなら、クラウドサービスで十分なことが多いです。一方、製造工程と在庫が密接に絡む、独自の引当ルールがある、受注・会計・ECなど複数のシステムと細かく連携する必要がある、といった場合は、自社開発やクラウドサービスとの組み合わせを検討する価値があります。
この記事は、在庫管理の仕組みを見直そうとしている中小企業の経営者や、物流・購買・情報システムの担当者に向けて、在庫管理システムに必要な機能の整理、自社開発とクラウドサービスの判断基準、開発の進め方、よくある失敗までを具体的に解説します。
在庫管理システムで何を実現したいかを決める
在庫管理システムの目的は会社によって異なります。目的を決めないまま検討を始めると、比較の軸がなく、機能の多い製品や大きな開発計画に引きずられます。まずは、今困っていることを次のような目的に置き換えてみます。
- 欠品を防ぎたい：売れる商品が切れて販売機会を逃している。発注のタイミングを見逃している。
- 過剰在庫を減らしたい：売れない商品が倉庫を占め、資金が寝ている。どれが滞留しているか分からない。
- 在庫数を正確にしたい：帳簿と実際の数が合わない。棚卸しのたびに差異の原因探しに追われる。
- 作業を減らしたい：入出庫の記録、棚卸し、在庫報告の作成に時間がかかっている。
- 情報を共有したい：営業や店舗が在庫を確認するたびに倉庫へ電話で問い合わせている。
目的が1つに絞れなくても構いませんが、優先順位はつけます。「在庫数を正確にしたい」が最優先なら、入出庫の記録をその場で確実に行う仕組み（バーコード読み取りなど）に力を入れるべきです。「欠品を防ぎたい」が最優先なら、発注点の管理と通知が中心になります。
在庫管理システムに必要な機能の全体像
在庫管理システムに含まれる主な機能を整理します。すべてを最初から揃える必要はなく、目的に応じて選びます。
基本の機能
- 品目マスタ：商品・部品の品番、名称、単位、保管場所、仕入先、発注点などを管理する。
- 入庫：仕入れや製造で在庫が増えたときに記録する。発注データと照合して検品する機能を含むこともある。
- 出庫：販売や製造への払い出しで在庫が減ったときに記録する。
- 在庫照会：品目ごと・保管場所ごとの現在庫を確認する。
- 棚卸し：実際の在庫数を数え、帳簿との差異を記録・調整する。
- 履歴：いつ、誰が、何を、何個動かしたかを記録し、後から追えるようにする。
業務に応じて必要になる機能
- ロット・シリアル管理：製造ロットや個体ごとに在庫を管理する。食品や医薬品、精密部品などで、品質問題が起きたときに対象を特定するために必要になる。
- 使用期限・賞味期限の管理：期限の近いものから出庫する（先入れ先出し）ためのルールや、期限切れの警告。
- 発注点・発注提案：在庫が一定数を下回ったら発注を促す。過去の出庫量から発注量を提案する。
- 引当：受注に対して在庫を確保し、他の注文に回らないようにする。
- ロケーション管理：倉庫内の棚番号ごとに在庫を管理し、ピッキングの効率を上げる。
- 複数拠点の管理：複数の倉庫や店舗の在庫をまとめて見る、拠点間の移動を記録する。
- セット品・構成品の管理：複数の部品から組み立てる製品の、部品在庫と完成品在庫を連動させる。
連携の機能
在庫管理システムは単独で使われることは少なく、受注管理、購買、会計、ECサイト、POSなどと連携します。連携が必要な相手と、どのデータをどのタイミングでやり取りするかを早めに洗い出します。連携の要件が、自社開発かクラウドサービスかの判断にもっとも大きく影響します。
機能の優先順位を決める
すべての機能を一度に作ろうとすると、費用も期間も膨らみ、現場の負担も大きくなります。次の表のように、目的と業務の特性から優先順位をつけます。
| 機能 | 最初から必要になる状況 | 後回しにできる状況 |
|---|---|---|
| 入出庫・在庫照会・履歴 | ほぼすべてのケース | ― |
| 棚卸し | 帳簿と実数の差異が問題になっている | 品目数が少なく、目視で確認できる |
| ロット・期限管理 | 食品・医薬品・化学品など、追跡や期限が必須 | 期限や品質追跡の要件がない |
| 発注点・発注提案 | 欠品が売上に直結している | 発注は担当者の経験で回っている |
| 引当 | 受注から出荷までに時間差があり、二重販売が起きる | 受注即出荷で在庫を確保する必要がない |
| ロケーション管理 | 倉庫が広く、探す時間が大きい | 保管場所が少なく、探す手間が小さい |
| 複数拠点 | 倉庫や店舗が複数ある | 拠点が1つ |
この表で「最初から必要」に当てはまる機能を最初の版の範囲とし、それ以外は運用しながら追加していくのが現実的です。
自社開発かクラウドサービスかの判断基準
在庫管理の仕組みを用意する方法は、大きく3つあります。
- クラウドサービス（SaaS）を使う：月額料金で、一般的な在庫管理の機能をすぐに使える。
- 自社向けに開発する（受託開発・内製）：自社の業務に合わせて機能を作る。
- 組み合わせる：基本はクラウドサービスを使い、足りない部分や連携部分だけを開発する。
判断のための観点を表にまとめます。
| 観点 | クラウドサービスが向く | 自社開発・組み合わせが向く |
|---|---|---|
| 業務の流れ | 一般的な入出庫・棚卸しで回る | 製造工程や独自の引当ルールが絡む |
| 連携先 | 連携先が少ない、または製品が標準で対応している | 受注・会計・EC・製造など多数と細かく連携する |
| 変化の頻度 | 業務があまり変わらない | 事業の成長に合わせて業務を頻繁に変える |
| 導入の速さ | すぐに使い始めたい | 開発期間をとれる |
| 社内の体制 | システムの保守を担える人がいない | 保守を外部と契約できる、または社内に担当がいる |
| 在庫管理の位置づけ | 業務を回すための道具 | 在庫の扱い方そのものが競争力に関わる |
クラウドサービスで足りるかを確かめるには、自社の業務の流れを書き出し、製品の試用版で実際に一通りの操作をしてみるのが確実です。業務の流れは、担当者と作業を時系列で並べた図にしておくと、製品の機能と照らし合わせやすくなります。試用の結果、業務のほとんどが製品で回り、合わない部分が少しの運用の工夫で吸収できるなら、クラウドサービスを選ぶのが合理的です。
逆に、合わない部分が業務の中心にある場合や、合わせるために現場の手作業が大きく増える場合は、自社開発や組み合わせを検討します。費用の比べ方は在庫管理システムの費用で詳しく扱っています。
倉庫管理システムや基幹システムとの関係
在庫管理と似た言葉に、倉庫内の作業管理に特化したWMS（倉庫管理システム）や、販売・購買・会計までを統合したERPがあります。倉庫内のピッキングや出荷作業の効率化が主な課題ならWMS、全社の業務を一つの仕組みにまとめたいならERPが候補になります。在庫の数を正確に把握し、関係者で共有することが主な課題なら、在庫管理システムの範囲で十分なことが多いでしょう。どこまでを一つの仕組みで扱うかを最初に決めておくと、検討の範囲がぶれません。
在庫管理システムを開発する手順
自社開発や組み合わせを選んだ場合の進め方を示します。
- 現状の業務を書き出す：入荷から出荷まで、誰が何をどの順番で行い、どこに記録しているかを洗い出す。例外的な処理（返品、不良品、貸出、サンプル出荷など）も漏らさず挙げる。
- 目的と優先順位を決める：何を解決したいかを決め、最初の版に入れる機能を絞る。
- 在庫の数え方を決める：在庫を何の単位（個、箱、ケース）で、どの粒度（品目、ロット、ロケーション）で管理するかを決める。後から粒度を細かくするのは大変なので、ここは慎重に決める。
- 記録のタイミングと方法を決める：入出庫をいつ、誰が、どうやって記録するかを決める。その場で記録できないと数が合わなくなる。
- 連携の範囲を決める：受注・購買・会計・ECとどのデータをどのタイミングでやり取りするかを決める。
- 画面と帳票を設計する：現場の端末（PC、スマホ、ハンディ端末）に合わせた画面を作る。
- 小さく作って現場で試す：入出庫と在庫照会など、中心の機能から作り、一部の品目や倉庫で試す。
- 既存データを移行する：品目マスタと現在庫を移す。移行時点で実際の在庫を数え直すと、正確な状態から始められる。
- 範囲を広げ、機能を追加する：試した結果をもとに改善し、品目や拠点を広げ、発注点やロット管理などを追加する。
手順7の「小さく作って現場で試す」段階では、試す品目や倉庫を、在庫の動きが多く、問題が見えやすいところにするのがコツです。動きの少ない品目で試すと、問題が表に出ないまま範囲を広げてしまうことがあります。試験期間中は、現場の担当者から使いにくさを毎日聞き取り、すぐに直せるものは直していくと、本格的な展開のときに現場の受け入れが早くなります。
手順3と4は特に重要です。在庫管理システムの精度は、システムの機能よりも「現場が入出庫をその場で正しく記録できるか」で決まります。記録の手間を減らすためのバーコードやQRコードの活用は、バーコード・QR読み取りで在庫管理を効率化するシステム設計で詳しく解説しています。
現場で使われる設計にするための工夫
在庫管理システムが失敗する理由の多くは、機能の不足ではなく、現場で使われないことです。倉庫や店舗のスタッフは、手袋をしていたり、両手が荷物でふさがっていたり、PCから離れた場所で作業していたりします。事務所のPCで使うことを前提にした画面では、記録は後回しになります。
端末と入力方法を作業場所に合わせる
| 作業 | 向いている端末・入力方法 | 注意点 |
|---|---|---|
| 入荷検品 | ハンディ端末、スマホでのバーコード読み取り | 発注データと照合できると数え間違いが減る |
| 出庫・ピッキング | ハンディ端末、タブレット | ピッキングリストの順番を棚の並びに合わせる |
| 棚卸し | スマホ、ハンディ端末 | 通信が不安定な場所でも記録できるか確認する |
| 在庫照会 | PC、スマホ | 営業や店舗が自分で確認できるようにする |
| 品目マスタの登録 | PC | 登録ルールを決め、担当者を限定する |
入力を減らし、間違いに気づける画面にする
- 品番の手入力をなくし、読み取りや一覧からの選択にする
- 数量を入力したら、現在庫と入力後の在庫を並べて表示し、桁の打ち間違いに気づけるようにする
- 在庫がマイナスになる出庫は警告する
- 誰がいつ記録したかを残し、差異が出たときに追えるようにする
画面の使い勝手は、設計書を見ても判断できません。試作の段階で現場のスタッフに実際の作業場所で使ってもらい、迷う箇所や手間のかかる箇所を直していくことが大切です。
在庫データを経営判断に活かす
在庫管理システムに正確なデータがたまると、日々の作業だけでなく、経営の判断にも使えるようになります。たとえば次のような見方ができます。
- 滞留している在庫の一覧：一定期間出庫のない品目を抽出し、値下げや処分、仕入れの見直しを検討する。
- 品目ごとの回転の速さ：在庫を何日分持っているかを品目ごとに見て、持ちすぎ・持たなすぎの品目を見つける。
- 欠品の発生状況：どの品目がいつ欠品したかを記録し、発注点の設定を見直す。
- 棚卸し差異の傾向：差異が出やすい品目や保管場所を特定し、記録の方法や保管の仕方を改善する。
こうした見方は、最初の版から作り込む必要はありません。まずは入出庫の記録を正確にし、データがたまってから、必要な集計を追加していくほうが無駄がありません。売れ筋と死に筋を分けて管理の濃淡をつける考え方は、ABC分析の用語ページも参考になります。
具体的な場面で考える
架空の例として、部品を仕入れて組み立て、法人向けに出荷している製造業の会社を考えます。この会社では、部品と完成品の在庫をExcelで管理していましたが、製造で部品を使ったときの記録が漏れ、月末の棚卸しで毎回大きな差異が出ていました。
目的を整理すると、最優先は「部品在庫の数を正確にすること」、次に「部品の欠品で製造が止まらないようにすること」でした。一般的なクラウドの在庫管理サービスを試したところ、入出庫と棚卸しは問題なく使えましたが、完成品を1台作ると構成部品がまとめて減る、という処理を自然に扱えず、毎回手作業で部品ごとに出庫を記録する必要がありました。
そこで、部品と完成品の構成表を持ち、製造の完了を記録すると部品の在庫が自動で減る仕組みを中心に、最小限の在庫管理システムを開発することにしました。最初の版では、入出庫、構成表による部品の自動引き落とし、在庫照会、棚卸しの4つに絞り、発注点の通知は運用が安定してから追加しました。
このように、一般的な機能はクラウドサービスでも十分でも、業務の中心にある独自の処理が合わない場合は、その部分を軸に作るほうが現場の手作業を減らせます。
よくある失敗と避け方
- 機能を欲張る：最初からロット管理、ロケーション管理、需要予測までを入れようとして、開発が長期化し、現場も使いこなせない。目的に直結する機能から始める。
- 記録の方法を考えていない：画面は立派でも、入出庫をその場で記録する手段がなく、後でまとめて入力して数が合わない。記録のタイミングと方法を先に決める。
- 例外処理を見落とす：返品、不良品、貸出、サンプル出荷、拠点間移動などを想定しておらず、システム外の処理が増える。業務の洗い出しで例外を必ず挙げる。
- 在庫の単位を曖昧にする：箱で入荷して個で出荷する品目の単位換算を決めず、数がずれる。単位と換算ルールを品目マスタで管理する。
- 移行時に実数を数え直さない：Excelの数字をそのまま移すと、ずれた数字から新システムが始まる。移行時点で棚卸しをする。
- 連携を後回しにする：受注や会計との連携を後で考えると、二重入力が残り、データの不一致が起きる。連携の範囲は最初に決める。
検討を始める前のチェックリスト
- 在庫管理で解決したいことの優先順位が決まっているか
- 入荷から出荷までの業務の流れと、例外処理を書き出したか
- 在庫を管理する単位と粒度（品目・ロット・ロケーション）を決めたか
- 入出庫を誰がいつどうやって記録するかを決めたか
- 連携が必要なシステムと、やり取りするデータを洗い出したか
- クラウドサービスの試用版で業務を一通り試したか
- 最初の版に入れる機能と、後回しにする機能を分けたか
- 移行時に棚卸しを行う日程を確保できるか
よくある質問
Q. Excelの在庫管理からいきなりシステムに移しても大丈夫ですか？
可能ですが、一度にすべてを切り替えるより、一部の品目や倉庫から始めて、記録の方法が現場に定着してから広げるほうが安全です。Excelでの管理が限界に来ているかの見極め方は、Excelの在庫管理が限界になるサインと、システム化の進め方で解説しています。
Q. 在庫管理システムの開発にはどれくらいの期間がかかりますか？
必要な機能の範囲、連携先の数、既存データの状態によって大きく変わります。最初の版を入出庫・在庫照会・棚卸しなどの中心機能に絞れば、比較的短い期間で現場での試用を始められます。最初から多くの機能を盛り込むほど、期間は長くなります。
Q. 自社開発したシステムの保守はどうすればよいですか？
自社開発の場合、不具合の修正、業務の変化に合わせた改修、サーバーやセキュリティの対応などの保守が継続的に必要です。開発を依頼する時点で、保守の範囲と体制、費用の考え方を確認しておきます。社内に担当者がいない場合は、保守契約を結ぶのが一般的です。
Q. 需要予測の機能は必要ですか？
まずは発注点による通知など、ルールに基づく仕組みで十分なことが多いです。過去の出庫データが十分にたまり、季節変動や販促の影響を加味した予測が必要になった段階で、需要予測の機能を検討するのが現実的です。予測の精度は、入出庫の記録の正確さに左右されるため、まずは記録の精度を高めることが先です。
Otsumuに相談できること
品目数が限られ、入出庫と棚卸しが一般的な流れで回る場合は、クラウドの在庫管理サービスを試用し、自社で導入を進めるのが合理的です。業務の流れの書き出しや、在庫の単位・記録方法の決定は、現場をよく知る社内の担当者が主導するのがもっとも確実です。
一方で、製造工程と在庫が絡む、独自の引当ルールがある、受注・会計・ECなど複数のシステムと連携する必要がある、といった場合は、クラウドサービスだけでは現場の手作業が残りがちです。どこまでをサービスに任せ、どこを作るべきかの判断には、業務とシステムの両方を見られる視点が役立ちます。
Otsumuでは、業務の流れと在庫管理の目的を整理したうえで、クラウドサービスで足りるか、組み合わせるか、自社開発するかを一緒に判断します。開発する場合は、目的から逆算して必要な機能に絞り込み、AIを活用した少人数の開発で最初の版を短期間に形にし、現場で試しながら広げていきます。詳しくは在庫管理システム開発のページをご覧ください。
検討を始めたばかりの段階でも構いません。30分の無料相談で、現在の在庫管理の状況を伺いながら、進め方を整理します。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01