US-004:在庫管理と在庫ロック機能
基本情報
| 項目 | 内容 |
|---|---|
| ID | US-004 |
| タイトル | リアルタイム在庫管理と在庫ロック機能の実装 |
ユーザーストーリー
As a システム管理者
I want SKU単位で在庫を管理し、注文時に即座に在庫をロックできる
So that ピーク時でも在庫整合性を保ち、オーバーセルを防止できる
日本語記述
システム管理者として、ピーク時の大量注文でもオーバーセルを防止するために、リアルタイムで在庫を管理し注文確定時に即座に在庫をロックできる機能が必要である。
背景・目的
ビジネス背景
ファッションECでは、セールやタイムセール時に秒間数千のリクエストが集中し、同一商品への同時注文が頻発する。在庫管理の不備はオーバーセル(販売可能数を超えた受注)を引き起こし、顧客満足度の低下や業務負荷の増大につながる。プロジェクト概要では、「ピーク時における在庫整合性の保持」が明確な要件として定義されている。
ユーザーニーズ
- 顧客視点: 注文確定時に在庫があることを保証してほしい
- 運営視点: オーバーセルによる顧客対応コストを削減したい
- 倉庫視点: 正確な在庫数に基づいてピッキング作業を行いたい
- マーケティング視点: 在庫連動でプロモーションを自動制御したい
現状の課題
- 在庫数の更新タイミングによる不整合リスク
- 複数拠点(倉庫)の在庫を統合管理する必要性
- カートに追加した商品と注文確定時の在庫ギャップ
- 予約販売、セール在庫など特殊な在庫タイプへの対応
受入基準(Acceptance Criteria)
機能要件
AC-1: SKU単位の在庫数管理
Given SKUマスタに商品が登録されている
When 在庫数を登録・更新する
Then SKUごとに在庫数が管理される
詳細説明:
- 在庫数(Quantity)はSKUごとに管理
- 在庫数は負数にならない(バリデーション)
- 在庫数変更は全てInventoryTransactionとして履歴記録
AC-2: 注文確定時の在庫ロック(原子操作)
Given ユーザーが注文を確定する
When 在庫引当APIが呼び出される
Then 対象SKUの在庫が原子的にロックされ、在庫数が減算される
詳細説明:
- 在庫ロックは楽観ロックで実装
- ロック処理中に他のトランザクションが同じ在庫を減らせない
- 在庫不足の場合は即座にエラーを返す(ロールバック)
- 在庫ロックIDを発行し、OrderLineに記録して追跡可能にする
AC-3: 在庫ロックの解放(キャンセル・決済失敗時)
Given 注文確定後に決済が失敗またはキャンセルされる
When 在庫ロック解放APIが呼び出される
Then 在庫数が元に戻される
詳細説明:
- 在庫ロック解放は必ずInventoryTransactionに記録
- 解放処理も原子的に実施(部分的な解放は許可しない)
- 解放理由(キャンセル、決済失敗、返品等)を記録
AC-5: 在庫数のリアルタイム参照
Given ユーザーが商品詳細ページを閲覧
When 在庫状況を確認する
Then リアルタイムの在庫数が表示される
詳細説明:
- 「在庫あり」「残りわずか(5個以下)」「在庫切れ」の3段階表示
- 在庫数 = 現在の在庫数量
AC-6: 在庫トランザクション履歴の記録
Given 在庫数が変動する操作が発生
When 入庫、出庫、引当、解放、調整などが実施される
Then 全ての在庫変動がInventoryTransactionに記録される
詳細説明:
- トランザクションタイプ(入庫、出庫、引当、解放、調整)
- 変動前数量、変動量、変動後数量
- 関連する注文ID、オペレーターID、理由
- タイムスタンプと監査ログ
非機能要件
パフォーマンス
- 在庫参照APIのP95レスポンスタイム: 50ms以内
- 在庫ロックAPIのP99レスポンスタイム: 200ms以内
- 同一SKUへの同時1000並列ロックリクエストでデータ不整合が発生しない
セキュリティ
- 在庫操作は認可チェック必須(管理者権限)
- 在庫数の直接変更は監査ログに記録
- APIアクセスはレート制限
可用性
- 在庫サービスのSLA: 99.95%
保守性
- 在庫不整合検知の自動アラート
- 在庫数が負数になる異常を即座に検知
- 在庫トランザクション履歴から任意時点の在庫数を再計算可能
UI/UX要件
画面遷移
[在庫一覧] → [在庫詳細] → [在庫調整]
↓
[在庫履歴]
インタラクション
- 在庫数が閾値以下の場合は警告色(黄色・赤)で表示
- 在庫調整時は確認ダイアログを表示
- 在庫トランザクション履歴はページネーション対応
依存関係
前提条件
- SKUマスタが構築されている
- データベース(PostgreSQL)でトランザクション分離レベルが適切に設定されている
依存するストーリー
- なし(基盤的なストーリー)
ブロッカー
- 在庫ロック戦略の技術選定(楽観ロック)
- 初期在庫データのインポート方法
参考資料
外部参照
備考・コメント
設計上の決定事項
- 在庫ロックは楽観ロックを基本とする
- 在庫トランザクション履歴は無期限保存(監査要件)
将来の拡張性
- 店舗在庫との統合(オムニチャネル)
- AIによる需要予測と自動発注