棚卸・在庫照合アプリの開発費用｜バーコード・ロット・オフライン

棚卸のたびに紙、表計算、ハンディ端末の数字が食い違う。そんな現場で検討されるのが棚卸・在庫照合アプリだ。今回は、条件を裏まで確認するれむ3号と、操作で迷う場所を見逃さない戸惑井 源三が、棚卸・在庫照合アプリの開発費用を左右する要件を整理する。

れむ3号「僕はまず、費用表より『何を正しい在庫とするか』を見るよ。そこが曖昧だと、アプリを作っても差異の理由は消えない」

戸惑井 源三「わしは現場でどこ押したらええかが気になるな。手袋しとる人や、電波の弱い倉庫でも使えるんか。そこを飛ばしたら続かへんで」

棚卸・在庫照合アプリの開発費用を決める7要素

同じ「棚卸アプリ」でも、単一倉庫の数量入力と、複数拠点・ロット・期限・オフライン同期を扱う仕組みでは規模が違う。見積もりでは次を分けて考える。

1. 品目・ロケーション・単位の管理
2. バーコードやQRコードの読み取り
3. ロット、シリアル、使用期限の追跡
4. オフライン入力と再同期
5. 差異確認、再カウント、承認
6. 基幹・販売・会計システムとの連携
7. 端末、権限、監査ログ、運用支援

まず「正しい在庫」の基準を決める

れむ3号「うむん、在庫差異には原因がある。入出庫の未処理、単位換算、移動中、破損、誤ラベル。同じ差異でも処理は別だよ」

棚卸アプリの役割は、現物数を入力することだけではない。帳簿在庫との差異を表示し、誰が何を確認し、どう修正したかを残すことにある。基幹システムの数値を正本にするのか、承認済み棚卸結果で更新するのかを先に決める。

戸惑井 源三「数字が違うとき、赤く出るだけやと困るんや。『もう一回数える』『保留にする』『責任者を呼ぶ』が大きいボタンで分かると助かるな」

差異画面には、前回値、今回値、差異数、差異率、理由、写真やメモ、承認状態が必要になる場合がある。ただし、全部を一画面に詰め込むと操作しづらい。現場入力と管理者確認の画面を分ける設計が現実的だ。

バーコード対応で見落としやすい条件

バーコード読取は一見単純だが、既存ラベルの品質、コード体系、同一品目の複数単位、読み取り距離、照明で難易度が変わる。スマートフォンのカメラで足りる現場もあれば、専用スキャナーが必要な現場もある。

れむ3号「見積もり前に実物ラベルを集めよう。きれいなテストコードだけで成功しても、擦れた箱や反射する袋で読めなければファイナルラストにはできない」

• JAN、QR、社内コードなど何を読むか
• 一つの品目に複数コードがあるか
• 箱、ケース、バラで数量換算するか
• 読めない場合の検索・手入力を許すか
• 誤読時に取り消しや再入力ができるか

戸惑井 源三「手入力を全部禁止したら、ラベルが破れた一箱で止まってまう。逃げ道は要る。ただし、誰が手で入れたかは残したほうがええな」

ロット・期限・シリアルは費用に直結する

数量だけの棚卸ならデータ構造は比較的単純だ。ロット、期限、製造番号、保管状態まで追うと、読取順序や照合ルールが増える。先入先出の確認、期限切れ警告、回収対象の検索など、棚卸以外の業務にも広がりやすい。

機能を増やす前に、次を決める。

論点	確認例
管理単位	品目、ロット、シリアルのどこまで識別するか
期限	日付入力、コード読取、基幹から参照のどれか
状態	良品、破損、保留などを分けるか
追跡	誰が、いつ、どこで数えたか

れむ3号「機能一覧では同じ一行でも、ロット別の在庫更新には例外が多い。サンプルデータで一手先まで検証しておくと、追加費用の条件が見えるよ」

オフライン対応は「後で同期」だけではない

地下、冷蔵倉庫、広い工場では通信が安定しない。オフライン対応を入れるなら、端末に何を配るか、複数端末の入力が競合したときどちらを採用するか、紛失端末のデータをどう守るかを設計する。

戸惑井 源三「電波が戻ったら勝手に送るんか、わしが同期ボタンを押すんか。送れたかどうか、文字だけやなく色と印で分かると安心や」

同期失敗を黙って終わらせないことが重要だ。未送信件数、最終同期時刻、再送、管理者への通知を用意する。二重登録を防ぐID設計も必要になるため、オンライン専用より工数は増える。

連携方式で変わる初期費用と運用費

基幹システムとの連携は、API、ファイル連携、手動取込などがある。APIがあっても、項目や更新頻度、認証方式、利用上限が合わなければ追加開発が必要だ。

れむ3号「『連携できます』だけではまだわからないよ。商品マスタ、在庫残高、棚卸結果のどれを、いつ、どちら向きに送るかを表にしよう」

小規模なら、最初はCSVの出力・取込で運用を確かめる選択もある。リアルタイム性が必要か、締め処理までに反映できればよいかで判断する。ただし手動ファイルには、誤版、列ずれ、重複取込の対策が要る。

費用を抑える段階導入

具体的な金額は、拠点数、端末数、連携先、セキュリティ、データ量、保守範囲で変わる。根拠のない定額を置くより、見積もりを次の段階に分けるほうが比較しやすい。

第1段階：実証

一つの倉庫、一部品目で、スキャン、数量入力、差異確認まで試す。既存ラベルの読取率と、一人あたりの操作時間を測る。

第2段階：本番最小構成

権限、監査ログ、マスタ取込、承認、バックアップを加える。運用手順と問い合わせ先も決める。

第3段階：複数拠点・高度連携

オフライン同期、ロット・期限、複数倉庫、API連携、ダッシュボードなどを、効果と優先度を見て追加する。

戸惑井 源三「最初から全部載せるより、実際に一周やって『ここで迷った』を直すほうがええ。魚群が出たから当たる、と決めつけんのと同じやな。予算の上限は先に決めとこ」

見積依頼に添えるチェックリスト

• 対象拠点、品目数、ロケーション数、同時利用者数
• 使用端末とOS、専用スキャナーの有無
• 実物バーコードの種類と写真
• ロット、期限、シリアル、単位換算の要否
• オフラインが必要な場所と想定時間
• 連携先、利用可能なAPI・ファイル仕様
• 差異の承認経路と監査ログの保存期間
• 稼働希望時期、教育、保守、端末交換の範囲

れむ3号「比較では、総額だけでなく前提条件と除外項目をそろえる。角を取るように、後から変えにくいデータ構造と連携条件を先に押さえよう」

まとめ：現場テストを見積もりの一部にする

棚卸・在庫照合アプリの開発費用は、バーコード読取の有無だけでは決まらない。差異処理、ロット・期限、オフライン競合、基幹連携、権限と運用支援までが費用を動かす。

戸惑井 源三「わしの結論は、迷わず一件登録できて、間違えても戻れることや。速さだけやなく、現場が最後まで使えるかを見てほしい」

れむ3号「僕の結論は、実物ラベルと例外データで試すこと。うむん、条件をそろえれば、見積もりの差も説明できる。要件整理から必要なら、開発見積もりをご相談ください」