アナログ倉庫から脱却した地方小売店X社の在庫管理システム導入成功事例
ユースケース概要：地方小売店X社が抱えた在庫管理の課題
地方都市で創業50年を迎えた小売店X社は、これまで紙帳簿とエクセルで在庫管理を行ってきました。しかし、取り扱う商品点数が増えるにつれ、入荷・出荷のタイミングがずれるトラブルが多発し、棚卸しの作業は年に一度の大行事となっていました。経営者の鈴木氏は、在庫管理業務の効率化を図るべく、社内にシステム導入の必要性を感じるようになります。
従業員数は10名弱で、IT担当者は常駐しておらず、これまでの仕入れや販売促進はすべてアナログ中心でした。経営判断のスピードが遅く、見切り商材を適切に売り切るタイミングを逃すこともしばしば。こうした業務フローの非効率さが、結果的に販売機会損失や過剰在庫によるコスト増大を招いていました。
そこでX社では、在庫管理をデジタル化し、売れ筋・在庫切れを即時に把握できるWebシステムを導入するプロジェクトを立ち上げます。プロジェクトを円滑に進めるため、X社は開発会社の選び方から費用相場、予算策定、発注までを計画的に進める必要がありました。本記事は、その一連の流れを時系列で解説し、読者である事業担当者やマネージャーが自社に適した開発会社を選ぶ際の参考となることを目指しています。
発注検討の背景と開発会社選び
X社が初めてシステム開発を検討するにあたり、まず直面したのが「どのようなシステムを、どの規模で構築するのか」を明確化することでした。予算としては中小企業向けの在庫管理システムの相場が500万円程度であるという情報を得ていましたが、実際の導入費用は要件次第で上下します。
経営者の鈴木氏はまず、同業他社が導入して成功している事例をインターネット検索で調査し、複数のパッケージ導入とオーダーメイド開発の比較を行いました。パッケージを利用する場合のメリットは初期費用が抑えられ、費用相場も事前に把握しやすい点です。しかし、X社のように「独自の棚卸しフロー」「季節商材に対応した受注処理」「POSレジ連携」が必要となるケースでは、カスタマイズ費用が高額になるリスクがあります。
一方でオーダーメイド開発の場合は、自社の業務フローにぴったりフィットするシステムを構築できますが、予算は開発会社の見積り次第で増減します。X社では予算目安として600万円を想定し、機能要件を明文化したうえで数社にRFP（提案依頼書）を送付し、相見積もりを取得することにしました。
RFP作成にあたっては、以下のポイントを押さえることが重要です。
-
業務フローの詳細記載：倉庫入荷、在庫引当、レジ連動、棚卸しなどの具体的な業務フローを図示し、どのタイミングでデータ連携が必要かを明確化する。
-
予算・費用概算の提示：600万円前後を想定していること、開発会社には機能ごとに見積りを細分化してもらう旨を明示する。
-
開発スケジュールの希望：発注からローンチまで6ヶ月程度を目安とし、マイルストーンを設定する。
これを受けて、X社は過去に中小企業向けシステム開発を多く手がけるA社、B社、C社の3社にRFPを発行しました。開発会社の選び方のポイントは以下のとおりです。 -
実績と業界理解：地方の小売業向けに同様のシステムを開発した実績があるかどうか。営業担当やエンジニアとのヒアリングを通じて、業務理解度を確認した。
-
開発スタイルとコミュニケーション：リモート対応の可否や、頻繁に要件すり合わせができる体制が整っているか。X社にはITリテラシーの高い担当者がいないため、開発会社からのサポート体制が重要である。
-
費用見積もりの透明性：見積書を項目ごとに明細化し、「要件定義」「設計」「開発」「テスト」「運用保守」の各フェーズにかかる費用を把握しやすいようにしているか。
最終的に、X社ではA社をパートナーに選定しました。A社は「地方の小売業向けに10年以上の開発実績があり」「要件定義から運用保守まで一貫体制でサポート可能」「相場感を踏まえた契約形態を提示できる」点が評価されました。A社の初回見積では概算600万円、開発期間6ヶ月以内が提示され、X社の予算・相場観と合致していたため、発注を決定しました。
要件定義フェーズの苦労と学び
要件定義はプロジェクトの基盤を構築する重要なステップです。X社の要件定義では、以下のような苦労がありました。
-
業務フローの可視化不足：これまでアナログで運用していたため、実際の棚卸し手順や仕入れ発注ルールが曖昧になっており、A社との最初のワークショップで多くの擦り合わせが必要だった。
-
非IT担当者の要望抽出：経営者や店長、レジ担当者からヒアリングを実施しましたが、「在庫数を一定以下にすると発注アラートを出す」「売れ筋商品を自動でランク付けする」といった曖昧な要望が多く、これを具体的にシステム要件に落とし込むまでに時間を要した。
-
優先度の設定：限られた予算内でシステム開発を収めるため、すべての要望を盛り込むのではなく、「必須要件」「優先度高」「将来的に検討」の3階層に分け、開発スコープを絞り込む必要があった。
これらの課題を解決するために、A社とX社は以下の施策を講じました。
-
業務フローチャートの共同作成
-
店舗スタッフを交えて実際の倉庫作業やレジ操作を観察し、A社のコンサルタントが詳細な業務フローチャートを作成。紙ベースのフロー図から、Googleスプレッドシート上でリアルタイムに共有・編集できる形に置き換えた。
-
クライアント側の担当者が「ここは退社後に入力している」「この商品の棚卸しは手作業が複雑でミスが多い」など現場の実態を説明し、その場でA社がフローに反映。これにより、要件漏れや認識齟齬が少なくなり、要件定義資料の完成までに要した期間は約1.5ヶ月と、当初の2ヶ月より早期に完了した。
-
-
ワイヤーフレームとプロトタイプによる要件提示
-
要件定義の終盤で、A社はFigmaを使用した簡易ワイヤーフレームを提供し、画面レイアウトや機能配置をクライアントに可視化。X社は実際にFigma上で画面遷移を確認しながら「ここにプルダウンがほしい」「ボタンはもっと大きく」「このラベルはわかりにくい」といったフィードバックを即時に行えた。
-
プロトタイプを使うことで、「どの画面で何を入力するのか」「どのタイミングでアラート表示が出るのか」といった具体的なイメージを関係者全員が共有でき、要件定義段階での手戻りを最小限に抑えられた。
-
-
優先度マトリクスでスコープを調整
-
X社は「当面は自動発注アラートよりも棚卸し効率化を優先したい」という意見を管理チームで合意。A社とともに、優先度マトリクスを作成し、「必須要件としての在庫数リアルタイム集計」「棚卸し専用画面でのスキャン入力機能」「低在庫アラート」は開発初期に実装、「自動発注アラート」「売れ筋ランク付け」はフェーズ2として後日検討することに決定した。
-
このようにフェーズ分割することで、当初予定の予算600万円以内で要件定義フェーズから開発フェーズへスムーズに移行でき、発注範囲を明確化した上で開発会社への発注を行えた。
-
開発プロセス開始からテストまでの取り組み
要件定義フェーズが完了すると、いよいよ開発会社A社による実装フェーズが始まります。開発プロセスはアジャイル手法をベースに、2週間単位のスプリントで進められました。X社は社内にIT担当者がいないため、A社から常駐するスクラムマスターをアレンジしてもらい、コミュニケーションの窓口を一本化。これにより、開発会社とクライアント間の要件確認が滞ることなく円滑に進みました。
-
スプリント0：環境構築と初期設計
-
X社の倉庫にテスト用のモバイルスキャナとバーコードプリンターを設置し、A社エンジニアとリモートで連携。バーコード読み取り機能の動作確認や、サーバー側の環境構築（AWS上にEC2、RDS、S3を構築）を実施。
-
モバイル端末からリアルタイムに在庫データが更新される仕組みをPoC（概念実証）として検証し、テスト中に顕在化した通信遅延やネットワーク切断時の挙動を改善。結果として、SDKレベルでのエラーリトライ機能を実装し、現場での安定稼働を確保する基盤を完成させた。
-
-
スプリント1～3：コア機能の開発
-
スプリント1では在庫閲覧画面と棚卸し入力画面を開発。X社のスタッフが実際にスキャナを使って棚卸し入力を行い、A社がUIの操作性や入力待ち時間を改善。エンジニアがGitHub上でプルリクエストを作成し、X社側はGitHubのプレビュー機能を使ってフィードバックを実施。短いコミュニケーションサイクルにより、翌営業日には修正が完了する進捗感が得られた。
-
スプリント2では棚卸しデータの集計ロジックと、低在庫アラートの通知機能を実装。Firebase Cloud Messaging（FCM）を導入し、モバイルアプリにプッシュ通知を送る形で「在庫数5点以下の商品」が発生した際に現場スタッフへ即時通知。X社のマネージャーは即座に必要発注数を把握できるようになり、人的ミスによる品切れを大幅に減らすことに成功した。
-
スプリント3ではレジシステムとのAPI連携を開始。既存のPOSレジからCSV出力される売上データを自動連携させ、在庫システム側で引き当て処理を行う仕組みを構築。これにより、レジ打ちのたびに在庫数がリアルタイムで更新され、エクセル手入力によるタイムラグがなくなった。
-
-
スプリント4～5：テストと品質保証
-
ユニットテストはJestとMochaを併用し、フロントエンド・バックエンドそれぞれでテストケースを作成。テストカバレッジは80％以上を目標とし、GitHub ActionsによるCI/CDパイプラインで自動実行。テストに失敗した場合は自動で担当エンジニアへSlack通知が飛ぶ仕組みに。
-
総合テストフェーズでは、X社から選定した社内テスター3名がテスト仕様書に沿って検証。バグはGitHub Issueで管理し、A社はWeeklyでバグレポートを提出。Issueの優先度を「Critical」「High」「Medium」「Low」の4段階に分類し、重要度の高い不具合から順次修正。これにより、リリース前に検知されたバグ数は20件程度まで減少し、品質が一定水準に到達した。
-
リリース直前の準備とローンチ
いよいよ開発が完了し、地方小売店X社の在庫管理システムを本番環境にリリースする段階です。これまで要件定義から開発・テストまでを約6ヶ月間で行い、テストフェーズで20件ほどの不具合を修正できたことは大きな前進でした。ここからは、リリース直前に実施した準備作業と、実際のローンチに向けた取り組みを紹介します。
まず、X社と開発会社A社は本番環境のインフラ設定を最終確認しました。AWS上の本番サーバーはテスト環境からセキュリティ設定やパフォーマンス設定を引き継ぎつつ、アクセス負荷が増えた場合にスケールアップできるオートスケーリング設定を追加実装しました。また、バックアップスケジュールを明文化し、データベースのRDSスナップショットを毎日深夜1時に取得するように設定しています。これは、万が一の障害発生時に迅速に復旧できる体制を整えるためです。
次に、X社内での操作マニュアルと教育を実施しました。管理画面の使い方やバーコードスキャナの操作手順をまとめたPDFドキュメントを作成し、スタッフ全員に配布。さらに、レジ担当者や倉庫スタッフ向けに2時間程度のハンズオン研修を行い、実際に棚卸し作業やコンディションアラート受信のシミュレーションを行いました。非ITのスタッフでもシステムの使い方を容易に理解できるように、画面キャプチャに注釈をつけたマニュアルを作成したことで、運用開始後すぐに現場で活用できる準備を整えました。
運用開始日の当日は、A社からサポート担当者がX社へリモート参加し、スタッフが不安なく本番運用を行えるように常駐サポートしました。また、リリース後24時間以内に発生した不具合は即座に対応し、重大度の高いものは数時間以内にパッチを本番環境へデプロイしました。具体的には「棚卸し画面で一部の商品コードが正しく反映されない」「在庫アラートが通知されない」などの軽微なバグが発生しましたが、どちらも即修正され、X社スタッフからも「スムーズに対応してもらえた」という声が多く寄せられました。このように、リリース直前の入念なインフラ設定と現場研修、24時間サポート体制が、ローンチ成功のカギとなりました。
運用開始後の改善サイクルと費用対効果
システム運用を開始すると、実際の業務フローに則した課題が多数浮上しました。これらを改善することで、開発会社への追加発注費用を最小限に抑えつつ、システム価値を向上させることができました。
運用開始後1ヶ月間は、X社の業務担当者が日常的に使用しながら「ここをもっと簡単にしたい」「棚卸し入力時に誤入力しやすい」といったフィードバックをA社へ定期的に報告。A社は2週間ごとにスプリントを回し、小規模な改修を行いました。例えば、以下のような改善を実施しています。
-
バーコードスキャナのUI改善：一部の老年スタッフがスキャン時に画面遷移が遅いと感じるため、入力フィールドの自動フォーカス機能を強化し、スキャン後のカーソル移動を即座に行うよう調整。これにより、作業スピードが従来比で約15％向上した。
-
在庫アラートの閾値設定機能追加：初期要件では在庫5点以下でアラート通知する仕様でしたが、季節商材では売れ行きに応じて閾値を柔軟に変更したいという要望が浮上。A社は管理画面へ閾値設定画面を追加し、商品カテゴリごとに個別設定できるようにした。これにより、余剰在庫を防ぐ精度が高まり、費用対効果が向上した。
-
CSV出力のカスタマイズ：月次棚卸しデータを会計ソフトに取り込むため、エクセルではなく指定のCSVフォーマットで出力したいという要望に対応。A社はCSVテンプレートを3種類用意し、ダウンロード時にフォーマットを選べるようにしたことで、外部システム連携時の工数を大幅に削減。
これらの改善を短期間で実施できたのは、A社との運用保守契約で「月間10時間分の軽微改修」を含むパッケージプランを結んでいたため、追加費用を抑えられた点が大きいです。仮に単純な時給換算で10時間あたり5万円であれば、月額5万円で継続的に改修を受けられる計算となり、これまで発注を都度見積もりしていた場合に比べて相場費用を大きく下回るコストで運用できました。
また、運用開始後3ヶ月時点で費用対効果を評価したところ、以下のような成果が見えてきました。
-
棚卸し工数の削減：月次棚卸しにかかっていた作業時間は従来15人日（約120時間）でしたが、システム導入後は3人日（約24時間）に短縮。人件費換算で約30万円相当の削減効果を達成。
-
在庫回転率の改善：在庫切れや過剰在庫を減らした結果、商品回転率は前年同期比で20％向上。キャッシュフロー改善につながり、月々の運転資金負担を約50万円削減。
-
ヒューマンエラー減少：エクセル手入力時に発生していた入力ミスがほぼゼロになり、会計処理時の修正工数を大幅に削減。これにより、事務作業コストとして年間約60万円を節約できる見込み。
これらの成果を総合すると、X社が想定していたシステム導入費用600万円に対し、初年度だけで約140万円のコスト削減効果が得られました。投資回収期間（ROI）は約4年と想定されていましたが、実際には約3.5年で回収できる見込みとなり、費用対効果は高い結果となったのです。
プロジェクト成功の要因と学び
X社が在庫管理システム導入プロジェクトを成功させることができた要因は、以下のように整理できます。
-
開発会社選びと発注タイミングの適切さ
-
RFPに業務フローや予算目安、スケジュール希望を正確に記載し、A社を選定できたことで相場感に合った費用で発注できた。
-
オーダーメイド開発でありながらフェーズ分割（フェーズ1：コア機能、フェーズ2：追加機能）を行ったことで、初期予算を超過せずに要件を整理し、必要な機能だけを優先して開発した。
-
-
要件定義の徹底とワイヤーフレーム活用
-
アナログ業務の可視化が不十分だった段階でA社と共同で業務フローを作成し、非IT担当者の要望を具体的に引き出した。
-
ワイヤーフレームやプロトタイプを用いることで、要件定義段階で認識齟齬を防ぎ、開発スコープを明確にできた。
-
-
アジャイル手法を取り入れた開発サイクル
-
2週間スプリントで開発を進め、早い段階でコア機能を動かすPoCを実施。現場での業務検証を繰り返すことで、品質を向上させるとともに不要な機能開発を削減した。
-
テスト自動化とCI/CD環境を整備することで、バグ修正や品質保証コストを抑えつつ、開発スピードを落とさなかった。
-
-
運用保守契約での継続的改善体制
-
月間10時間の軽微改修が含まれる契約プランにより、小規模なUI改善や機能追加を迅速に実装し、運用開始後の課題を速やかに解決。
-
APMツールを用いたパフォーマンス監視とSLA契約により、システムダウンや障害発生時の対応を明確化し、稼働後のリスクを最小化した。
-
-
現場スタッフへの丁寧な研修とコミュニケーション
-
ITに不慣れな現場スタッフへの操作研修を十分に行ったことで、運用開始後のシステム受け入れ率が高まった。
-
フィードバックサイクルを確立し、運用中に改善要望が発生した際はすぐに対応。これによってユーザーの満足度を維持し、導入効果を最大化できた。
-
これらの要因が重なり、X社は在庫管理に伴う業務負荷を大幅に軽減し、コスト削減と売上向上を同時に達成できました。非IT企業が初めてシステム開発を発注する場合は、開発会社の選び方や要件定義、発注スコープの整理、予算・費用相場の把握といった要素が成否を左右します。本事例を参考に、読者の皆様も自社業務に最適なパートナー選定とプロジェクト運営を検討してみてください。
次期フェーズでの拡張ポイントと考慮事項
在庫管理システムの導入が一通り完了したものの、X社ではさらなる業務効率化や売上拡大を目指し、次のフェーズを検討しています。以下では、今後の拡張ポイントと注意点を示します。
-
自動発注機能のフェーズ2実装
-
フェーズ1では在庫アラートのみを実装しましたが、フェーズ2では「発注候補リストを自動生成し、発注書を自動作成してFAXやメールで仕入先へ送付する機能」を追加予定です。
-
ここでの注意点は、仕入先ごとにフォーマットが異なるケースがあるため、多様なFAXレイアウトやメールテンプレートを一元管理できる設計が必要になることです。発注ミスを減らすため、サプライヤーコードや商品マスタ連携を強化することが重要です。
-
-
販売分析レポートとBIツール連携
-
X社では売れ筋ランキングを週次で把握していますが、今後はBI（Business Intelligence）ツールを活用して「日別・時間帯別の売上推移」「地域別購入傾向」「キャンペーン実施前後の売上比較」といった分析を行う計画です。
-
BIツール連携にはデータ連携用APIの開発が必要となり、開発会社への費用発注見積もりも再度取得する必要があります。相場感としては、BI連携機能の実装だけで約100万円～150万円程度を想定しています。
-
-
スマホアプリでの発注・検品サポート
-
現在はモバイルブラウザ対応のWebアプリですが、倉庫作業をさらに効率化するため、スマホアプリでのバーコードスキャン・検品機能を追加する予定です。
-
オフライン対応の要否や、iOS・Androidそれぞれのアプリストア申請費用を含めた予算検討が必要です。また、スマホアプリの場合はストア公開までの審査期間も考慮し、開発スケジュールを余裕を持って確保する必要があります。
-
-
マルチ拠点展開とクラウドコストの最適化
-
X社では今後支店を新たに2店舗展開する計画があるため、マルチ拠点で在庫情報を共有できる仕組みが求められます。AWSリソースを現状のEC2+RDS構成から、Aurora ServerlessやDynamoDBなどのマネージド型データベースへ移行し、拠点増加に伴うスケーラビリティを確保することを検討中です。
-
クラウドコストの相場は月額数万円から数十万円に増減しますので、「予算を先に抑えたい」「費用を柔軟にコントロールしたい」場合はオートスケール設定を最適化し、使用量に合わせた課金モデル（たとえばAurora Serverlessの従量課金）を選択すると良いでしょう。
-
まとめ
以上が、地方小売店X社がアナログ倉庫から脱却し、在庫管理システムを導入した成功事例の全貌です。非IT企業が初めてシステム開発を発注する際に陥りがちな「要件定義の曖昧さ」や「開発会社選びの失敗」「予算・費用相場の見誤り」といった課題を、具体的なユースケースを通じて解説しました。X社は開発会社A社と協力し、要件定義を徹底的に行うことで費用超過を防ぎ、アジャイル開発による迅速な改善サイクルを回した結果、最終的に約950万円でプロジェクトを完了できました。
また、運用開始後も継続的に改善を続けたことで、「棚卸し工数の削減」「在庫回転率の向上」「ヒューマンエラーの削減」といった成果を挙げ、費用対効果を最大化しています。今後のフェーズ2では自動発注やBI連携、スマホアプリ導入を検討し、さらなる業務効率化を目指す計画です。
事業責任者やマネージャーの皆様は、本事例を参考に自社の業務課題を整理し、開発会社の選び方や発注スコープの決め方、予算策定のコツを押さえていただければ幸いです。特に中小企業が初めてシステム開発を行う場合は、要件を可視化し、相見積もりで相場感を把握したうえで適切な開発会社へ発注することを強くお勧めします。
