在庫管理システムの開発｜費用と機能の考え方

01はじめに｜この記事でわかること

要点：この記事では、在庫管理システムの費用の決まり方、必ず入れる機能と業種で変わる機能、進め方、相談前に決めておくことを見ていきます。読み終えるころには、見積書の金額の理由がわかります。

「在庫管理システムって、いくらぐらいかかりますか」。最初のご相談で、いちばん多いのがこの質問です。

正直なところ、この段階ではお答えできません。100万円で足りることもあれば、1,000万円を超えることもあります。差を生むのは機能の豪華さではなく、品目の数と拠点の数、そして触る人の数です。

この記事は、2000年創業のWeb制作・システム開発会社ZenWeb Japanが、Webシステム開発の実案件からまとめました。

まずは、在庫管理システムの基本を動画で押さえておいてください。

02在庫管理システムとは｜数字と現物を合わせる仕組み

要点：在庫管理システムとは、入庫と出庫を記録して「今どこに何個あるか」を把握する仕組みです。目的は数を数えることではなく、帳簿と現物を一致させ続けることにあります。崩れると欠品と過剰在庫が同時に起きます。

会社の中には、在庫の数字がいくつも存在します。営業が見る受注可能数、倉庫が数える実物、経理が使う棚卸高。ずれると、営業は売れる在庫を売り逃し、倉庫は無いものを探します。システムの仕事は、3つをひとつにまとめることです。

そのために、次の情報を1件ずつ記録していきます。

• いつ動いたか。入庫・出庫・移動・返品の日時。
• どこにあるか。倉庫、棚、フロアといった保管場所。
• 何が動いたか。品番のほか、ロットやシリアル、サイズや色で分けることもあります。
• 誰が動かしたか。作業者を残すと、差異が出たときに追えます。
• いくつ確保されているか。受注で押さえた分（引当）を、空き在庫と分けて持ちます。

特に大事なのが「引当」です。倉庫に100個あっても、80個が受注で押さえられていれば売れるのは20個です。この区別が無いと、在庫はあるのに出荷できない事故が起きます。

03Excelの在庫管理はどこで限界が来るか

要点：Excelでの在庫管理は、品目数よりも「同時に入力する人数」で限界が来ます。1人なら十分に回りますが、2人以上が同じ表を触り始めると上書きと二重入力が起きます。拠点が2つになると数字が合わなくなります。

Excelが悪いわけではありません。立ち上げ期にはむしろ優秀です。すぐ作れて、誰でも直せて、費用もかかりません。問題は、規模が大きくなると通用しなくなる点です。

限界のサインは、だいたい次の順番で出てきます。

1. ファイルが増える。「最新版」「最新版_修正」が並び始めます。
2. 締めが遅れる。月初の数字を出すのに、複数の表を突き合わせることになります。
3. 棚卸差異が説明できなくなる。数が合わない理由を、誰も追えなくなります。
4. 特定の人しか触れなくなる。関数とマクロが複雑になり、担当者が休むと止まります。

3つ目まで来ていたら、システム化を考える時期です。見極め方はExcel業務をWebシステム化すべきサインで整理しています。

出典：ZenWeb Japanの開発実績データ（2024〜2026年、日本国内）。在庫管理の相談時ヒアリング記録をもとに分類。同じ規模でも業務の内容により変わります。

04開発の3つの選択肢｜クラウド・パッケージ・オーダーメイド

要点：在庫管理システムの選択肢は、クラウドサービス、パッケージ、オーダーメイド開発の3つです。判断の軸は費用ではなく、自社の業務をシステムに合わせられるかどうかです。合わせられるならクラウドが最短です。

いきなり開発を選ぶ必要はありません。まずクラウドで足りないかを確かめてください。

• クラウドサービス（月額数千円〜数万円）。扱い方が一般的な商材の会社向け。帳票や単位の細かい指定は効きません。
• パッケージ導入（初期数百万円＋メンテナンス）。業種が定型に近い中堅企業向け。カスタマイズ費が積み上がります。
• オーダーメイド開発（初期100万円台〜）。独自の単位や工程がある会社向け。要件が固まらないと期間が伸びます。

開発を選ぶべきなのは、業務のほうを変えられないときです。受注前に在庫を仮押さえする商習慣、ケースとバラの単位換算、得意先ごとの独自伝票。こうした事情は標準機能から外れやすく、無理に合わせると現場が二重管理を始めます。

逆に、標準的な入出庫と棚卸だけなら開発は過剰です。迷うときはノーコード・ローコード・スクラッチの違いと費用が目安になります。

05必ず入れる基本機能6つ

要点：どの業種でも外せない基本機能は、入庫・出庫・在庫照会・引当・棚卸・履歴の6つです。揃っていれば、在庫管理システムとして最低限の役目は果たします。ここを削ると安く作れても運用が回りません。

最初の見積りでは、機能を欲張らないほうがうまくいきます。次の6つに絞ってください。

• 入庫登録。仕入れや返品で増えたとき、品番・数量・保管場所を記録します。
• 出庫登録。出荷や社内使用で減ったときに記録します。伝票番号とひも付けると後で追えます。
• 在庫照会。今の在庫数を拠点別・保管場所別に見る画面。現場が一番よく使います。
• 引当管理。押さえた分とまだ売れる分を分けます。売り越しを防ぐ要です。
• 棚卸。実地で数えた数を入力し、差異を一覧で出します。理由を残せる欄も用意します。
• 操作履歴。誰がいつ何を動かしたかを残します。差異を追えるかが変わります。

この6つなら、規模にもよりますが2〜3か月で動くものができます。半年ほど使ってから足りない機能を足す進め方が、結果としていちばん安く収まります。

最初から全部を盛り込むと、要件定義が終わらず金額だけが膨らみます。この落とし穴は要件定義で失敗しない進め方で扱っています。

06業種で変わる追加機能｜ロット・賞味期限・シリアル

要点：基本の6機能に何を足すかは、業種によってはっきり分かれます。食品なら賞味期限とロット、医療機器ならシリアル単位の個体管理、アパレルならサイズと色のSKU管理です。この追加分が、見積り金額の差を生んでいます。

同じ在庫管理システムでも、業種が違えば中身は別物です。下の表は、実際の案件で追加された機能を業種別に並べたものです。

出典：ZenWeb Japanの開発実績データ（2024〜2026年、日本国内）。要件定義書の機能一覧をもとに業種別に集計。同業種でも取扱商材により変わります。

ご自身の業種の行で「これは要る」と思ったものは、最初の相談で必ず伝えてください。あとから追加すると、データの持ち方から作り直しになります。特にロットとシリアルは後付けが高くつきます。

07費用の内訳｜何にお金がかかっているのか

要点：開発費の大半は人件費です。プログラムを書く時間だけでなく、要件を決める打ち合わせ、テスト、データ移行、操作説明まで含みます。見積書の金額は、作業にかかる人数と月数を足したものです。

中身を知ると、削れるところと削れないところが見えてきます。開発費はおおむね次の5つに分かれます。

• 要件定義。何を作るかを決める工程。全体の15〜20%程度で、削ると後で倍返しになります。
• 設計・開発。画面とデータベースを作る工程。全体の50〜60%といちばん大きな割合です。
• テスト。動作の確認。15〜20%程度で、現場の方に触ってもらう時間も含みます。
• データ移行。Excelや旧システムから在庫データを移します。マスタが乱れていると膨らみます。
• 導入・教育。マニュアル作成と操作説明。人数が多い会社ほどかかります。

削りやすいのはテストと教育です。ただし、削った現場はほぼ確実に混乱します。人月単価と工数の関係はシステム開発の見積もりの見方で解説しています。

安くしたいなら、工程を削るのではなく、作る機能を減らしてください。

なお、初期費用だけでは判断できません。稼働後はメンテナンス費が毎年かかります。相場は初期開発費の15〜20%前後で、サーバー代は別途です。

08規模別の費用と期間の目安

要点：在庫管理システムの開発費は、1拠点で基本機能のみなら100〜250万円、棚卸と帳票まで入れて250〜600万円が目安です。販売管理やECとつなぐと600万円を超えます。金額を押し上げるのは連携先の数です。

幅があるのは、同じ機能でも品目数や現場の運用で工数が変わるためです。出発点として見てください。

出典：ZenWeb Japanの開発実績データ（2024〜2026年、日本国内）。業務システム案件の見積り構成をもとに整理。メンテナンス費は含みません。実際の金額は要件により変わります。

2段目から3段目で金額が跳ね上がります。差を生むのは在庫の機能ではなく、他システムとの連携です。つなぐ相手が増えるほど、確認と調整が増えていきます。金額の考え方はシステム開発の費用相場もご覧ください。

09開発の進め方｜要件定義から本稼働まで

要点：在庫管理システムの開発は、要件定義、設計、開発、テスト、データ移行、稼働の順に進みます。全体で見ると、要件定義と移行の準備に想像以上の時間がかかります。プログラムを書く工程が長いわけではありません。

進め方は他の業務システムと変わりませんが、在庫管理には特有の山場が3つあります。

1. 現場の作業手順を洗い出す。倉庫の動きを担当者の手元まで見せてもらいます。机上で済ませると、稼働後に使われなくなります。
2. 品目マスタを整える。品番の重複、廃番の混在、単位のばらつきを直します。御社側でしか判断できません。
3. 棚卸に合わせて切り替える。実地棚卸のタイミングで初期在庫を登録すると、開始時点の数字が揃います。

2番目のマスタ整理は、開発と並行して進めると全体が縮みます。後回しにすると、移行の直前で数週間止まります。

使い勝手を早めに確かめたいときは、設計の前に画面の下書きを共有してもらってください。役割はワイヤーフレームとは？作り方と制作の流れで説明しています。

10既存システムとの連携をどこまでやるか

要点：連携は便利ですが、増やすほど費用と期間が伸びます。最初は販売管理との受注データ連携だけに絞り、会計や生産は後回しにするのが現実的です。つなぐ相手が1つ増えるごとに、テストの手間はぐっと増えます。

「せっかく作るなら全部つなぎたい」。よくわかります。ただ連携は相手側の都合にも左右され、思ったように進まないことが多い工程です。優先順位は次の順番をおすすめします。

• 販売管理・受注システム。受注の時点で自動的に引当が立つので、効果がいちばん大きいです。
• ECサイト・モール。複数店舗で売る場合、在庫の同期は売り越し防止に直結します。
• 会計システム。棚卸高の連携。月次の締めが楽になりますが、急ぎではありません。
• 生産管理。部品と完成品を同時に動かす必要が出てから検討してください。

実際の構成は物流システム開発の事例｜配車・在庫・倉庫管理で紹介しています。

11ハンディ・バーコード・ラベルの選び方

要点：読み取り機器は、専用のハンディターミナルとスマートフォンの2択です。1日の読み取り件数が数百件を超えるなら専用機、それ以下ならスマホで足ります。判断の基準は現場の作業件数であって、予算ではありません。

システムを作っても、入力が手打ちのままでは間違いは減りません。読み取りの仕組みまで含めて考えてください。

• スマートフォン・タブレット。1日数十〜百件程度なら十分です。追加費用がほぼかからず、Webシステムをそのまま使えます。
• 専用ハンディターミナル。1日数百件以上、または手袋や低温環境で使う場合に向きます。読み取りが速く、落としても壊れにくいです。
• 据置型スキャナ。出荷検品の台が決まっている場合に有効です。両手が空き、梱包と同時に進められます。

ラベルは、既存の商品バーコードをそのまま使えるか先に確認してください。使えるなら、貼る作業が不要になります。

12導入後1年で何が変わるか｜棚卸差異の推移

要点：在庫管理システムの効果は、稼働直後には出ません。入力が定着する3か月目あたりから棚卸差異が減り始め、1年ほどで棚卸にかかる日数がはっきり短くなります。焦らず、半年は様子を見る前提で計画してください。

稼働した翌月に「思ったほど変わらない」と言われることがあります。失敗ではなく、順番の問題です。まず入力が正確になり、次に数字が合い、最後に作業時間が減ります。

出典：ZenWeb Japanの開発実績データ（2024〜2026年、日本国内）。稼働後の運用支援記録をもとに集計。品目数と現場体制により変わります。

最後の行の「循環棚卸」は、全品を一斉に数えず、区画ごとに毎月少しずつ数える方式です。ここまで来ると年末に倉庫を止めずに済み、いちばん実感しやすい変化になります。

13失敗しやすい3つのパターン

要点：在庫管理システムの開発でつまずくのは、機能を盛り込みすぎたとき、現場が要件を見ていないとき、品目マスタが整っていないときです。技術的な難しさで失敗する案件は、実はそれほど多くありません。

うまくいかなかった案件の原因は、だいたい次の3つに集まります。

1. 最初から全部を作ろうとした。足すうちに要件が固まらず、期間も費用も膨らみます。まず基本6機能で動かしてください。
2. 倉庫の担当者が打ち合わせに出ていない。本社だけで決めると、現場と合わない画面ができます。1回でいいので、実際に入力する方に見てもらってください。
3. 品目マスタが乱れたまま移行した。重複した品番や廃番が混ざると、稼働直後から差異が出ます。

3つとも開発会社側だけでは防げません。御社側で誰が決めるのかをはっきりさせるのが、何よりの対策です。線引きはシステム開発の外注と内製の判断基準を参考にしてください。

14相談前に決めておく5項目と、使える補助金

要点：相談前に決めておくと話が早いのは、品目数、拠点数、利用人数、つなぎたいシステム、稼働させたい時期の5つです。この5つがあれば、初回の打ち合わせで概算の幅までお出しできます。予算額は最後で構いません。

資料は不要です。次の5つを、わかる範囲でメモしておいてください。

1. 扱っている品目の数。おおよそで十分です。廃番を含むかも一言添えてください。
2. 拠点と倉庫の数。他社の倉庫を借りている場合も含めます。
3. システムを触る人数。倉庫・営業・経理の内訳がわかると精度が上がります。
4. つなぎたいシステム。今使っている販売管理や会計ソフトの名前を控えてください。
5. 稼働させたい時期。棚卸や決算に合わせたい場合は必ず伝えてください。

費用面では公的な支援制度も選択肢に入ります。中小企業庁は、業務効率化に向けたソフトウェア導入を支援するIT導入補助金や省力化投資補助金を用意しています（中小企業庁「2025年版中小企業白書」）。同じ資料では、DXの問題点に「費用の負担が大きい」「人材が足りない」を挙げる企業が多いことも示されています。条件は年度ごとに変わります。

15まとめ｜判断の順番

要点：在庫管理システムは、困っている作業の特定、クラウドで足りるかの確認、基本6機能での開発、という順に判断してください。この順番を守ると、必要以上に大きなシステムを作らずに済みます。

1. 今どの作業で数字が合わなくなっているかを、言葉にする。
2. クラウドサービスで足りないかを確かめる。足りるなら、それが最短です。
3. 足りない理由がはっきりしたら、基本6機能に絞って開発する。
4. 半年ほど使い、本当に必要だとわかった機能だけを足していく。
5. 連携は、効果の大きい販売管理から一つずつ進める。

在庫管理は作って終わりではありません。現場が毎日触るものだからこそ、小さく始めて育てるほうがうまくいきます。顧客側のデータも整えたい場合は顧客管理システムの開発｜CRMを自社で作るもご覧ください。

16よくある質問

要点：在庫管理システムの開発について、ご相談の場でよくいただく質問をまとめました。期間、開発を選ぶ基準、データ移行、機器の必要性、メンテナンス費の5つです。

1. 在庫管理システムの開発にはどのくらいの期間がかかりますか？

基本機能だけなら2〜3か月、棚卸や帳票まで含めると3〜5か月が目安です。他システムとの連携が入ると5か月を超えます。品目マスタの整理に時間がかかる場合は、1〜2か月足して考えてください。

2. クラウドサービスではなく開発を選ぶ基準は何ですか？

業務のほうを変えられないときです。受注前の仮押さえ、独自の単位換算、得意先ごとの伝票など、標準機能から外れる事情があるなら開発が向きます。入出庫と棚卸だけならクラウドで十分です。

3. 今のExcelのデータはそのまま移行できますか？

移行できますが、そのままではありません。品番の重複、廃番の混在、単位のばらつきを整理する作業が必要です。御社側でしか判断できないため、早めに着手してください。整っていれば移行自体は数日で終わります。

4. ハンディターミナルは必ず必要ですか？

必要ありません。1日の読み取りが数十件から百件程度なら、スマートフォンのカメラで十分です。専用機を検討するのは、1日数百件以上を読む現場や、手袋をしたまま作業する現場です。

5. 開発した後のメンテナンス費用はどのくらいかかりますか？

初期開発費の15〜20%前後が年間の目安です。別途、サーバー代が月額で発生します。メンテナンスの中身は会社ごとに差が大きいので、障害対応の範囲と連絡手段を契約前に確認してください。