清掃業向け清掃用品在庫管理システム開発の進め方/やり方/流れや方法/手法/工程/手順

清掃用品在庫管理システムの開発は、在庫フローの整理、最小機能の設定、段階的な検証の順に進めます。そうすると、欠品と棚卸の負担を減らせます。

在庫フローの捉え方から費用と見積もりまで順に扱います。全体像は、清掃業向け清掃用品在庫管理システム開発の完全ガイドもご覧ください。

▼全体ガイドの記事
・清掃業向け清掃用品在庫管理システム開発の完全ガイド

清掃業向け清掃用品在庫管理システムの概要

中央の保管庫イラストの周囲に、営業所の資材庫、車両、個人ロッカー、現場の仮置き棚を配置した図。
同じ用品でも、置き場所が変われば在庫の所在も変わります。

清掃業の在庫管理は、倉庫の数量を数えるだけの業務ではありません。用品は中央倉庫から車両や現場へ移り、使用、返品、廃棄されます。その流れを記録することが、在庫管理の中心になります。

対象は、洗剤、ワックス、モップ、クロス、手袋、ごみ袋、ペーパー類、清掃機器の消耗部品です。現場が増えるほど、帳簿と実在庫の差が開きがちです。

倉庫・車両・現場を一つの在庫フローで捉える考え方

保管場所ごとに在庫を定義しておき、中央倉庫から車両への積み込みは「移動」、車両から現場への持ち出しは「出庫」として登録します。

  • 使用・返品:現場で使った量と余った量を分けて扱う
  • 現場間の融通:別現場へ移した数量
  • 廃棄:破損や期限切れによる数量

この区分を分けておくと、どれだけ使われ、どれだけ戻り、どれだけ捨てられたかが分かります。そのため、発注量を決める根拠として使えます。ロケーションには、営業所の資材庫、車両、個人ロッカー、現場の仮置き棚も登録します。

入力では、「どこから」「どこへ」「何を」「いくつ」「誰が」「いつ」動かしたかを記録します。一方で、電話やLINEの依頼を、あとでExcelへ転記する運用では、差異が出ても原因をたどれません。

清掃用品ならではの品目情報の持たせ方

商品マスタには、商品名のほか、メーカーや仕入先、品目コードを登録します。また、JANやQRコード、標準単位も持たせます。

  • 数量と発注:ケース入数、容量、仕入単価、リードタイム
  • 在庫基準:発注点、安全在庫、代替品の登録
  • 単位換算:ケースを開封した後、バラへ換算するルール

「洗剤A 1ケース」と「洗剤A 12本」を別商品として登録すると、在庫量と発注数を比べられません。そのため、換算ルールはシステムと作業手順の両方に定めます。

洗剤や薬剤のように必要な品目に限っては、SDS、保管区分、危険有害性を管理します。加えて、希釈方法、廃棄上の注意、ロット、開封日も記録します。

経済産業省の化管法SDS制度では、指定化学物質を規定含有率以上含む製品を事業者間で譲渡・提供する場合に、SDS提供義務が示されています(出典:経済産業省「化管法SDS制度」、2026年確認)。

対象となる品目は、法務担当者や安全管理担当者と確認します。なお、清掃用品すべてを一律に規制対象とみなすのではなく、品目ごとに判断します。

ポイント

在庫は場所ごとの数量ではなく、移動・出庫・返品・廃棄の流れで捉えられるかが判断の目安です。品目情報も、換算ルールや危険品の管理まで含めて判断材料にします。

清掃用品在庫管理システム開発の進め方

要件整理、選定、設計開発、テスト、稼働準備を順に並べた5つの開発工程パネル。
前段で決めた業務ルールを、後段の設計や受入確認へつなげます。

開発は、機能一覧を業者へ渡す前に、現場の物の流れと判断ルールを整理するところから始めます。要件整理から定着まで、段階を追って進めます。

1. 要件整理で決める現状とMVP

最初の2〜4週間程度で、管理対象と関係者、既存システムとの接続を確認します。あわせて、実数と業務イベントを整理します。

  • 対象数:品目数、中央倉庫数、現場・車両数、利用者数、仕入先数
  • 運用量:月間入出庫件数と棚卸頻度
  • 現場条件:通信圏外の有無とバーコード利用状況
  • 分散データ:Excel、紙、LINE、電話、作業報告に分かれた情報

業務イベント単位で整理すると、現場の動きに沿った一覧になります。さらに、会計や販売管理との接続、入力者、承認者も、この一覧に含めます。

MVPには、商品、仕入先、ロケーションのマスタと、入庫・出庫・移動・返品・廃棄を含めます。棚卸と発注点アラートに加え、スマートフォン入力とCSV出力も対象です。

一方で、AI需要予測、重量IoT、自動発注は、実績データを蓄積した後の候補です。顧客ポータルや複雑な会計APIは、実績が増えてから検討します。

この段階の成果物は、業務フローと品目項目表、権限表です。加えて、非機能要件と機能の優先順位表も作ります。

2. 選定で比べる方式と現場適合性

候補となる方式は、現場の規模と統合範囲に合わせて選びます。方式ごとに向く状況が違うため、あらかじめ整理しておきます。

  • 標準SaaS:1〜数拠点で早く始めたい場合の候補
  • 業界パッケージ:作業、契約、請求、原価も統合する場合に検討する方式
  • 個別開発:独自の補充ルールや既存ERP連携が、競争力に直結する場合

候補は、標準SaaS、SaaSへの初期設定・連携追加、kintoneなどのローコードです。業界パッケージやスクラッチ開発も含めて比べます。

デモでは、実データに近いシナリオを使います。たとえば、中央倉庫から車両へ1ケースを移し、現場で3本使ったうえで、残りを別現場へ移す流れを確かめます。

納品書と棚卸差異の扱いも確認します。また、片手で操作するスマートフォン入力、通信断の扱い、SDS閲覧、拠点別権限を、候補3社以上で同じ条件で試します。

3. 設計開発での入力のしやすさと例外の定義

管理者向けの画面より先に、現場が毎日使う出庫画面を設計します。そのため、読み取りと最小限の入力で登録できる導線にします。

  • 基本操作:商品コードをQRやバーコードで読み取る
  • 入力項目:数量と移動先の入力
  • 例外処理:換算、未登録品の申請、代替品の承認
  • 在庫制御:マイナス在庫と後日入力の可否

設計書には、画面とデータ項目、権限を書きます。加えて、エラーや通知、外部連携、バックアップと復旧方法も明記します。さらに、換算、未登録品の申請、代替品の承認は、例外として処理の流れを定義します。

個人情報保護委員会の通則ガイドラインが示す安全管理措置を踏まえます。そのうえで、作業員名や連絡先の扱い、現場担当者へのアクセス範囲も決めます。

要件には、操作ログと退職者アカウントの無効化を含めます。さらに、暗号化やバックアップ、障害時の復旧目標も入れます(出典:個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」、2026年確認)。

4. テストで再現する実際の在庫差異

開発会社の機能テストだけで終わらせず、関係者が代表品目と過去伝票を使って受入テストを行います。正常系と異常系の両方を試します。

  • 正常系:入庫、出庫、移動、棚卸、発注、納品確認
  • 異常系:数量不足、二重スキャン、期限切れ、代替品を試す
  • 運用例外:通信断、権限外操作、返品、廃棄を確かめる

発注、倉庫、現場、経理の担当者が参加します。合格条件は、画面の表示ではなく業務結果で決めます。

確認するのは、棚卸後の実在庫とシステム在庫が合うことと、発注点を下回ると通知されることです。加えて、ケースをバラへ換算しても総量が保たれ、登録者を履歴から追えることも条件に入ります。

不具合、仕様変更、教育課題は、分けて管理します。さらに、重大な障害が残る場合に稼働日を延期する判断基準も定めます。

5. 稼働と6. 定着での小さな測定と段階的な展開

稼働準備、段階導入、効果測定を順に進めて、現場に運用を定着させます。

  1. 全拠点を一斉に切り替えるのではなく、中央倉庫と1〜3現場程度でパイロットを始めます。品目コードを整理してから、実棚で初期在庫を確認して登録します。
  2. 切り替え時は、旧Excelの更新停止時刻と最終棚卸の責任者、緊急時の紙伝票、問い合わせ窓口、旧運用へ戻す条件を決めておきます。
  3. 定着後は、現場入力率、棚卸にかかる時間、在庫差異率、欠品件数、緊急購入件数、発注から入荷までのリードタイム、滞留在庫金額を、月次で測ります。
  4. KPIでは、毎日の入力だけでなく、欠品や棚卸巡回の減少、発注判断が担当者の経験だけに頼らなくなったかを評価します。

情報セキュリティ面では、IPAの中小企業向け情報セキュリティ対策ガイドライン第4.0版も参照します(出典:IPA「中小企業の情報セキュリティ対策ガイドライン第4.0版」、2026年確認)。

バックアップ、クラウド利用、インシデント時の連絡体制は、定期的に見直します。

ポイント

判断の目安は、機能一覧より先に現場の物の流れと判断ルールが整理できているかです。段階ごとに成果物と合格条件を決めておくと、途中での手戻りが出にくくなります。

清掃用品在庫管理システムの費用相場の目安

標準SaaSから個別開発まで5方式の初期費用目安を範囲付きの横棒で比較した図。
方式を変えると、初期費用の幅も大きく変わります。

費用は、拠点、利用者、品目、入力方法、連携範囲、データ移行量によって変わります。そのため、初期費用と月額、導入支援は、分けて考えます。端末・ラベル・IoTや保守も、別の項目として見ておきます。

公開価格のSaaSと個別開発の見積もりは、同じ基準で並べられるものではありません。なお、ここで示すのは、リサーチノートと公開料金を照合した初期予算の目安で、確定価格ではありません。

方式別の初期費用と期間の比較

方式ごとの初期費用と期間は、標準利用か個別対応かによって幅があります。そのため、目安を並べて比べます。

  • 標準SaaS:初期0〜50万円、月額数千円〜15万円程度、導入1〜3か月が目安です。
  • SaaS追加対応:初期30〜300万円、月額1〜30万円程度、期間2〜5か月が目安です。
  • ローコード:初期100〜800万円、月額数万円〜20万円程度、期間3〜8か月が目安です。
  • 業界パッケージ:導入・カスタマイズは初期300〜1,500万円、期間3〜9か月が目安です。
  • 個別開発:清掃業向けの開発や複数拠点の基幹連携では、初期1,000〜5,000万円以上、期間6〜18か月以上になることがあります。

標準SaaSは、小規模な会社や1〜数拠点で、マスタ、入出庫、棚卸、発注点アラートを早く始めたい場合の選択肢です。追加対応には、初期設定、データ移行、API連携が含まれることもあります。

費用と期間は、機能数だけでなく、移行や教育によっても変わります。さらに、既存システム連携、承認、監査、保守体制も、費用と期間を左右します。

相場の目安として使う公開料金

公開料金は、標準SaaSで足りる範囲の予算を考える参考になります。ここでは、ZAICO公式料金の例を確認します。

  • スターター:2026年6月の改定後、月額8,980円です。
  • ベーシック:2026年6月の改定後、月額49,800円です。
  • プロフェッショナル:月額150,000円からです。

基本人数は、スターターがフル利用者3名と閲覧10名、ベーシックがフル利用者10名と閲覧10名です。

QR・バーコード、棚卸、発注点、拠点管理などの機能は、プランごとに整理されています(出典:株式会社ZAICO「料金プラン」、2026年6月改定)。

ただし、この料金は清掃業向けの個別開発の相場ではありません。初期設定や品目データの整備、バーコード発行は、別料金になることもあります。さらに、現場教育、API、端末、追加オプションも、別料金になる場合があります。

現場管理SaaSと在庫SaaSを組み合わせる場合は、ユーザー課金が重複しないかを確認します。作業報告から出庫を自動で連携できるかも確かめます。

開発費だけでなく運用費まで含めた見積もり

個別開発では、費用配分と運用費を合わせて確認します。配分は案件によって変わるため、目安として見ておきます。

  • 要件定義・基本設計:要件定義10〜15%、基本設計15〜20%程度です。
  • 詳細設計・開発:詳細設計10〜15%、開発30〜40%程度を占めます。
  • テスト・移行導入:テスト15〜20%、移行・導入5〜10%程度です。

要件定義やデータ移行を極端に削った見積もりには、注意が必要です。たとえば、商品コードの重複や単位の不統一、古い仕入先名、現場名の表記揺れは、開発後になるほど修正費がかさみます。

ランニングコストには、SaaS利用料またはサーバー費、保守、問い合わせ対応が含まれます。加えて、バックアップや通信費も含めて考えます。端末やラベルプリンターの費用も、同じ枠で見ておきます。バーコード発行、教育、追加連携も、ランニングコストの一部として扱います。

保守費を初期開発費の年10〜20%程度とする見積もりもあります。そこで、対応時間や障害復旧、軽微改修の範囲、OSアップデート対応を契約書で確かめます。

月額が安くても、データ出力や退会時の移行費が高くなる場合があります。したがって、3〜5年の総額で比べます。

ポイント

費用は、拠点、利用者、品目、連携範囲、データ移行量で変わります。判断の目安は、初期費用だけでなく、月額、保守、移行、教育を含めた総額で比べられているかです。

見積もりを取る際のポイント

見積もりの精度は、機能数よりも、現状データと運用ルールの具体性で決まります。「在庫を一元管理したい」だけでは、依頼の解釈が分かれてしまいます。

そこで、誰がどの端末と場所から何を入力し、誰が承認し、どの帳票を出すかは、一日の流れに沿って伝えます。

発注前に整理するチェック項目

依頼前に、見積もりの前提となる業務量と要件を洗い出しておきます。

  • マスタ・単位:商品、仕入先、現場、ロケーションの件数と、ケース、箱、本、リットルなどの換算
  • 入出庫:月間の入出庫、返品、廃棄の件数を把握する
  • 在庫基準:発注点、安全在庫、棚卸頻度、差異処理の取り決め
  • 現場機器:スマートフォン、バーコード、圏外現場の有無
  • 品目管理:SDS、ロット、期限を扱う品目の範囲

会計、販売、勤怠、作業報告との連携や、権限、ログ、バックアップ、復旧目標も、整理しておきます。

代表的な商品マスタ10〜30件、発注書、納品書、現場別の補充依頼、棚卸表、使用中のExcelを用意します。なお、個人情報や取引先情報は、渡す前に匿名化します。

マスタ整備を自社とベンダーのどちらが担うかと、誤登録を誰が検収するかも、見積もりの前提に明記します。

候補会社への同じシナリオによる提案依頼

同じRFPと実務シナリオを、候補会社へ渡します。機能数よりも、現場の運用に合うかどうかで比べます。

  • 日常業務:現場入力、拠点・車両管理、発注点の確認
  • 品目情報:SDS添付、ロット・期限への対応を見る
  • 周辺業務:会計・作業報告との連携、移行、教育、保守の比較

清掃業の理解を確かめるため、未開封のケースと開封後のバラの管理方法を質問します。あわせて、車両に積んだ資材を出庫として扱う時点や、現場間の融通の記録方法も尋ねます。

提案書では、標準機能、設定対応、追加開発、運用回避を分けて示してもらいます。「要相談」や「別途見積」が多い項目は、追加になる可能性があるものとして一覧にします。

契約時には、成果物、設計書とソースコードの納品範囲、検収条件、変更単価を確認します。データの所有権や解約時の出力条件も、確かめます。

障害時の対応時間や再委託、終了後の保守窓口も、契約で確認します。

失敗しやすい見積もりと対策

経営層だけで要件を決め、現場入力を後回しにすると、定着が難しくなります。操作の負担は、選定の段階で確かめます。

  • 現場参加:倉庫、現場、発注、経理、情報システムが選定に加わる
  • 操作確認:短時間のテストで入力手順と合否を判断する
  • 段階導入:使用量と欠品の影響が大きい品目からの開始

たとえば、車両へ積んだ資材の登録に5画面もかかるなら、忙しい作業の前には使われなくなります。操作は、実際の現場で試しておきます。

全品目を完璧に登録してから稼働させる必要はありません。洗剤、手袋、ごみ袋、ペーパー類などから始めて、特殊機器部品や低頻度品は第二段階に回します。

KPIが改善しないときは、原因をシステムだけに決めつけないようにします。発注点や入力時期に加え、品目コード、保管場所、責任者の各項目に分けて見直します。

ポイント

判断の目安は、見積もりの精度が機能数ではなく、現状データと運用ルールの具体性で決まっているかです。候補会社には同じシナリオを渡し、提案内容を比べます。

よくある質問(FAQ)

会社の規模や現場数、既存システム、化学品の管理範囲に応じて判断が変わるため、よくある質問をまとめます。

小規模な清掃会社でもシステム開発は必要ですか?

小規模な会社がいきなり個別開発をする必要はありません。1〜数拠点で品目や入出庫、棚卸、発注点を管理するなら、公開料金のある在庫SaaSを試せます。

まずは、現場に定着するかを確認します。現場、契約、作業報告、原価、請求まで一体で扱う場合は、ローコードや業界パッケージも比べます。

通信が不安定な現場でも入力できますか?

製品ごとに対応が異なるため、オフライン入力と再接続後の同期を実機で確認します。複数人が同じ品目を出庫した場合の競合も、試しておきます。

未送信データの保持期間やエラー通知、後から修正した履歴も確認します。ただし、機能がない場合は、通信できる倉庫で出庫する運用の負担も見積もります。

清掃用品のSDSやロットまで管理すべきですか?

すべての品目を同じ深さで管理する必要はありません。洗剤や薬剤など安全管理に関わる品目は、SDSや保管注意、希釈方法を管理します。さらに、ロットや開封日、期限まで管理しておくと、確認を速められます。

化管法、労働安全衛生法、消防法などへの該当性は、商品ごとに確認します。システム要件と法的な判断は、混同しないように分けて考えます。

SDSは、ファイルを添付するだけでなく、改訂日と最新版の管理責任者も記録します。

会計・販売管理・作業報告と連携するべきですか?

二重入力の負担と連携開発費を比べて判断します。まずはCSVで月次連携し、項目と責任部署を固めてからAPIへ進む方法もあります。

作業報告の完了時に標準使用量を出庫し、発注の確定時に仕入情報を会計へ渡すなど、連携する場面を限定します。そうすると、初期費用と障害の影響範囲を小さくできます。

ポイント

判断の起点は、会社の規模、現場数、既存システム、化学品の管理範囲です。小規模なら公開料金のある在庫SaaSを試し、業務をまとめて扱うならローコードや業界パッケージも比べます。

まとめ

清掃業向けの在庫管理システムは、中央倉庫、車両、現場、返品、廃棄の流れを標準化します。在庫表示にとどまらず、欠品や棚卸の負担を減らす仕組みです。

進め方は、要件整理、選定、設計開発、テスト、稼働、定着の順です。各段階で成果物と合格条件を決めてから、次の段階へ進みます。

最初に決めるMVPと在庫責任者

管理対象の品目や保管場所、ケースとバラの換算を決めます。加えて、発注点、現場入力、棚卸、SDSなど、初期運用の範囲も定めます。

商品マスタの責任者と、入出庫の登録者、発注承認者、差異の確認者も明確にします。責任者が曖昧なままだと、どの方式を選んでもデータは更新されません。

候補会社に渡す実データに近いシナリオ

見積もりでは、初期費用に加えて、月額、保守、移行、教育を含めた総額を確認します。さらに、端末や連携、解約時のデータ出力も、総額の判断に含めます。

候補会社には、中央倉庫から車両、現場、別現場へ資材を移すシナリオと、ケースをバラへ換算するデータを渡します。そして、1〜3現場のパイロットでKPIを測り、効果を確認できた機能から全社へ広げます。

▼全体ガイドの記事
・清掃業向け清掃用品在庫管理システム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。