多店舗の商品管理は、「在庫が見える」だけでは足りません。

この事例の根拠と読み方

根拠は、AMELAの移行元ケース資料、CMS登録内容、AMELAが公開するReStockケースページと、2026年8月28日に確認した操作可能なデモです。公開ケースにはAMELAのロゴと事例表記があり、買取査定、全店在庫、販売登録、商品履歴、粗利・店舗分析をAMELAと構築した範囲として記録しています。

• 確認できること：買取成立・不成立の記録、在庫への登録、店舗・カテゴリ・状態による絞り込み、商品詳細、販売登録、買取から販売までの履歴、商品・店舗・カテゴリ単位の金額表示、CSV出力の操作。
• 確認できないこと：本番の店舗数、商品数、処理性能、開発期間・工数、工数削減、売上・粗利の改善、在庫回転、機会損失、出店速度、セキュリティ水準、SLA、可用性の実績。
• 公開上の扱い：企業名、プロジェクト名、画面、商品名、店舗名、日付、件数、金額は、機密保持のため承認済みの仮名またはモックです。デモ値を顧客の本番実績として扱いません。

AMELAがつないだのは、画面ではなく商品状態です

AMELAのケース資料では、Vue.js、Element UI、Vuex、NestJS、TypeORM、MySQLを用いた構成と、店舗・本部の役割を分ける方針が示されています。公開デモでは、査定フォームで登録した商品が在庫一覧へ移り、詳細画面で販売を登録すると履歴と金額表示が更新される流れを確認できます。

読者が使える実践ツール

要件定義の前に、次の「状態・粗利・権限・受入確認シート」を埋めると、既存SaaSで足りる範囲と個別開発が必要な範囲を比較できます。記入例は公開デモの操作をもとにしたもので、本番の運用値ではありません。

• 商品ID：買取受付から販売完了まで同じIDで追う。再査定、分割・セット化、重複登録時の扱いを決める。
• 状態：査定中、成立、不成立、在庫中、取り置き、販売済み、返品を定義し、各遷移の実行者と取り消し権限を決める。
• 粗利：販売前は「販売予定価格－買取価格」、販売後は「実売価格－買取価格」を基本例とする。税、手数料、修理費、送料、値引きを含めるか決める。
• 店舗・本部権限：店舗は自店の商品を更新、本部は全店を参照する、という初期案から、価格変更・CSV出力・マスタ編集の承認者を決める。
• 履歴：誰が、いつ、どの値を、何から何へ変更したかを残す。訂正時に元の記録を消すか、取消履歴として残すか決める。
• 受入確認：成立・不成立、登録、絞り込み、販売、返品、店舗間移動、権限外操作、CSVの計算一致を役割別に確認する。

評価データには、実際のカテゴリ構成、価格帯、返品・移動の例外、同時利用者数、保持期間を含めてください。粗利の定義と受入用の正解データを先に合意すると、画面の見た目だけで合否を決めるリスクを減らせます。