アパレル小売のEC・店舗在庫統合プロジェクト全記録
※ この事例は、プロジェクトマネジメントの学習を目的に作成した架空の事例です。登場する企業・人物・数値はすべて創作であり、実在のものとは関係ありません。
■ この事例の概要
アパレル小売のミライアパレルが、店舗在庫とEC在庫を1つにまとめるプロジェクトです。要件定義の途中で要件が186件から243件へ1.3倍に膨らみ、6月末の時点でSPIが0.86まで落ちました。
打ち手は要員追加ではなく、スコープを2段階に分けることでした。第1弾198件に絞り、残り45件を翌年度に送る。この判断により、春物商戦前の2025年3月1日稼働を動かさずに着地しています。
期間 | 費用 | スコープ |
|---|---|---|
2025年3月1日稼働(計画どおり) | 2億2,680万円(承認枠の97.8%) | 243件中198件を第1弾で実現 |
■ ミライアパレルという会社と、このプロジェクト
項目 | 内容 |
|---|---|
業界 | アパレル小売(実店舗+EC) |
会社 | 株式会社ミライアパレル(架空)/年商320億円/従業員1,240名 |
規模 | 直営68店舗、ECサイト1(EC売上比率18%)、物流拠点2 |
プロジェクト名 | 在庫一元化プロジェクト(社内呼称:UNITE) |
背景 | 店舗在庫とEC在庫が別システムで管理されており、相互に引き当てられない。ECで欠品表示された商品が、実際は店舗に在庫があるという状態が常態化していた |
期間 | 2024年4月1日〜2025年3月1日稼働(定着確認は5月31日まで) |
体制 | 社内8名+PMO1名+ベンダー14名(ピーク時20名) |
総工数 | 当初240人月 → 改定後252人月 |
平均単価 | 90万円/人月 |
当初契約額 | 2億1,600万円(240人月×90万円) |
承認予算枠 | 2億3,200万円(うち予備費1,600万円) |
新規開発規模 | 104KStep |
■ 何を成功とみなしたか
企画時に、QCDの目標を次のように置きました。数字で判定できる形にしてあります。
軸 | 指標 | 目標 |
|---|---|---|
Q(品質) | 受入テストでの重大不具合 | 0件 |
Q(品質) | 稼働後1か月の本番障害 | 3件以内 |
C(コスト) | 総費用 | 2億3,200万円以内 |
D(納期) | 本番稼働日 | 2025年3月1日(春物商戦の前) |
あわせて、このプロジェクトが最終的に狙う事業上の成果を3つ置きました。
成果指標 | 開始時 | 目標 | 測り方 |
|---|---|---|---|
欠品による販売機会損失 | 年4.2億円 | 年2.1億円 | 在庫切れ表示時の離脱数×平均単価 |
期末値引き率 | 22.0% | 17.0% | 期末セール実績÷定価総額 |
店舗からの在庫問い合わせ | 月1,800件 | 月600件 | 本部コールセンターの受電記録 |
■ 立ち上げ時に引いた計画
体制は、社内の業務部門を前面に出す形にしました。在庫の持ち方を決めるのは業務の判断であり、情報システム部門だけでは決められないからです。

チーム | 人数 | 主な責任 |
|---|---|---|
プロジェクトマネージャー | 1(専任) | 全体の計画・判断、ステコミ報告 |
PMO | 1(専任) | WBS・課題・リスク・TODOの維持、資料作成 |
業務チーム | 4(全員兼任) | 在庫引き当てルールの決定、店舗運用の確認 |
物流チーム | 2(専任1・兼任1) | 倉庫運用、WMS連携仕様 |
情シスチーム | 2(専任) | 基盤、データ移行、既存システム調整 |
ベンダーA社 | 12 | 設計・開発・テスト |
ベンダーB社 | 2(スポット) | 倉庫WMS側の改修 |
WBSは第3階層まで作り、工数を積み上げました。合計240人月が、そのまま契約額の根拠になっています。
WBS | 作業 | 当初(人月) | 改定後(人月) |
|---|---|---|---|
1 | プロジェクト管理 | 24 | 26 |
1.1 | 計画・統制 | 12 | 13 |
1.2 | 品質管理 | 6 | 6 |
1.3 | 移行統括 | 6 | 7 |
2 | 要件定義 | 32 | 44 |
2.1 | 業務要件 | 14 | 22 |
2.2 | システム要件 | 12 | 15 |
2.3 | 非機能要件 | 6 | 7 |
3 | 設計 | 48 | 52 |
3.1 | 基本設計 | 22 | 25 |
3.2 | 詳細設計 | 20 | 21 |
3.3 | 方式設計 | 6 | 6 |
4 | 開発 | 78 | 68 |
4.1 | 在庫基盤 | 34 | 34 |
4.2 | EC連携 | 18 | 18 |
4.3 | 店舗端末 | 16 | 10 |
4.4 | 倉庫WMS連携 | 10 | 6 |
5 | テスト | 40 | 42 |
5.1 | 単体・結合テスト | 18 | 19 |
5.2 | 総合テスト | 14 | 15 |
5.3 | 受入テスト支援 | 8 | 8 |
6 | 移行・定着 | 18 | 20 |
6.1 | データ移行 | 8 | 9 |
6.2 | 研修 | 6 | 7 |
6.3 | 立ち上げ支援 | 4 | 4 |
— | 合計 | 240 | 252 |
マイルストーンは6つ。このうち動かせないのはM5(本番稼働)だけで、他は調整可能という前提を最初に共有していました。
# | マイルストーン | 計画 | 実績 | 差 |
|---|---|---|---|---|
M1 | 要件確定 | 2024/6/28 | 2024/8/9 | +6週 |
M2 | 基本設計完了 | 2024/8/30 | 2024/9/27 | +4週 |
M3 | 開発完了 | 2024/11/29 | 2024/11/29 | ±0 |
M4 | 総合テスト完了 | 2025/1/31 | 2025/1/31 | ±0 |
M5 | 本番稼働 | 2025/3/1 | 2025/3/1 | ±0 |
M6 | 定着確認 | 2025/5/31 | 2025/5/31 | ±0 |
■ 第1四半期:数字の上では順調だった3か月
月 | 主な出来事 | 要件の合意状況 | SPI |
|---|---|---|---|
4月 | キックオフ、現行業務の棚卸し | 18/186件(10%) | 0.98 |
5月 | 店舗12店・倉庫2拠点へのヒアリング | 62/186件(33%) | 0.94 |
6月 | 要件レビュー。例外ケースが次々に出る | 126/243件(52%) | 0.86 |
4月と5月は、計画からの遅れが数%でした。この時点で誰も危機感を持っていません。ところが6月に入ると、レビューのたびに新しい要件が出てくるようになります。
■ 第2四半期:最初に崩れたのは要件確定だった
増えた要件を分類すると、偏りがありました。
分類 | 当初 | 追加 | 合計 | 追加された内容の例 |
|---|---|---|---|---|
在庫引き当て | 48 | 9 | 57 | 予約・取り置きがある場合の引き当て順序 |
店舗間移動 | 22 | 18 | 40 | 移動中在庫の扱い、移動元店舗の優先順位 |
EC連携 | 41 | 6 | 47 | セール価格の反映タイミング |
店舗端末 | 35 | 14 | 49 | 棚卸中・返品・交換時の例外処理 |
倉庫WMS連携 | 25 | 7 | 32 | 入荷検品で数量差異が出たときの処理 |
共通・非機能 | 15 | 3 | 18 | — |
合計 | 186 | 57 | 243 | — |
追加の32件(全体の56%)が、店舗間移動と店舗端末の例外処理に集中しています。本部の資料には「全店共通の運用」と書かれていましたが、実際の店舗ではやり方が分かれていました。
■ 何を見て「まずい」と判断したか
判断に使ったのは、EVMの2つの指標です。月次の数値は次のとおりです(単位:万円、いずれも累計)。
月末 | PV | EV | AC | SPI | CPI |
|---|---|---|---|---|---|
4月 | 900 | 880 | 880 | 0.98 | 1.00 |
5月 | 2,250 | 2,120 | 2,140 | 0.94 | 0.99 |
6月 | 3,700 | 3,180 | 3,320 | 0.86 | 0.96 |
7月 | 5,600 | 4,650 | 5,000 | 0.83 | 0.93 |
8月 | 7,900 | 6,720 | 7,380 | 0.85 | 0.91 |
9月 | 10,500 | 9,450 | 10,050 | 0.90 | 0.94 |
10月 | 13,600 | 12,780 | 13,180 | 0.94 | 0.97 |
11月 | 16,700 | 16,200 | 16,360 | 0.97 | 0.99 |
12月 | 19,000 | 18,810 | 18,810 | 0.99 | 1.00 |
1月 | 20,900 | 20,900 | 20,900 | 1.00 | 1.00 |
2月 | 22,100 | 22,100 | 22,100 | 1.00 | 1.00 |
3月 | 22,680 | 22,680 | 22,680 | 1.00 | 1.00 |
※ PVは9月の計画改定後のベースライン(BAC=2億2,680万円)に基づく数値です。

読み取ったのは次の2点です。
SPIの下げ幅がCPIより大きい:お金は想定どおり使えているのに、出来高が追いついていない。つまり「無駄遣い」ではなく「作業が前に進んでいない」状態
7月末のEAC(完成時総コスト予測):BAC÷CPI=21,600÷0.93=23,226万円。この時点で承認枠2億3,200万円を超える見込みになっていた
作業が進んでいない原因は要件が決まらないことなので、人を増やしても解決しません。この読みが、打ち手の方向を決めました。
■ 3つの案を比べて、何を選んだか
8月のステアリングコミッティに、3案を並べて出しました。
項目 | A案:全部作り切る | B案:2段階に分ける | C案:要員を増やす |
|---|---|---|---|
稼働日 | 2025年5月上旬 | 2025年3月1日(維持) | 2025年3月29日 |
追加工数 | +38人月 | +12人月 | +16人月 |
追加費用 | +3,420万円 | +1,080万円 | +1,440万円 |
成果への影響 | 目標を100%狙える | 初年度は目標の約8割 | 100%だが稼働が商戦後 |
主なリスク | 春物商戦を逃し、機会損失 約1.1億円 | 第2弾が翌年度予算の承認に依存 | 増員の立ち上がりに1.5か月。品質低下の恐れ |
判定 | × | ◎(採用) | △ |
決め手は、A案の「機会損失 約1.1億円」でした。これは春物商戦(3〜5月)の売上に対する欠品率から試算した数値で、追加費用3,420万円の3倍を超えます。作り切ることの価値より、商戦に間に合わせることの価値が大きいと判断しました。
B案の分割は、次のように線を引いています。
弾 | 含む範囲 | 要件数 | 工数 |
|---|---|---|---|
第1弾(2025年3月) | 在庫引き当て、EC連携、倉庫WMS連携、店舗端末の基本操作 | 198件 | 252人月 |
第2弾(2025年度) | 店舗間移動の自動最適化、取り置きの高度化、端末の例外処理 | 45件 | 38人月(次年度計上) |
第2弾に送った45件は「やらない」ではなく「翌年度にやる」です。この違いを業務部門に丁寧に説明したことが、合意を得られた理由でした。
■ 第3四半期:立て直しの実行
9月に計画を改定し、次の4つを同時に動かしました。
打ち手 | 内容 | 効果 |
|---|---|---|
スコープの分割 | 45件を第2弾へ。WBSの4.3・4.4を縮小 | 開発工数を78→68人月に |
予算の手当て | 予備費1,600万円から1,080万円を充当 | 承認枠内に収まる見通しに |
業務チームの時間確保 | 毎週火曜午後を専任時間として所属長と合意 | レビュー待ちの滞留が21日→7日に |
意思決定の前倒し | 設計方針の決定を週次から随時に変更 | 設計の手待ちが減少 |
3つ目が効きました。兼任の業務チームは本業を優先せざるを得ず、レビュー依頼が滞留していました。「20%参加」ではなく「火曜午後」と具体的な時間で押さえたことで、実際に時間が確保されています。
■ 第4四半期:稼働と、その後の3か月
総合テスト以降は計画どおりに進みました。品質のデータは次のとおりです。
工程 | テストケース数 | 検出不具合 | うち重大(A) | 不具合密度(件/KStep) |
|---|---|---|---|---|
単体テスト | 6,240 | 322 | 18 | 3.10 |
結合テスト | 2,080 | 187 | 14 | 1.80 |
総合テスト | 1,560 | 68 | 3 | 0.65 |
受入テスト | 620 | 10 | 0 | 0.10 |
工程が進むごとに密度が下がっており、収束しています(新規開発規模104KStepに対する密度)。受入テストでの重大不具合は0件でした。
移行は3回のリハーサルを実施しました。2回目で旧システムの商品コードに重複1,240件が見つかり、本番前に解消しています。
回 | 実施日 | 対象 | 所要 | 結果 |
|---|---|---|---|---|
第1回 | 2025/1/11 | 商品・取引先マスタ | 4時間20分 | 件数差異 38件。原因は廃番商品の扱い |
第2回 | 2025/2/1 | 全マスタ+在庫 | 6時間05分 | 商品コード重複1,240件を検出 |
第3回 | 2025/2/15 | 全データ(本番相当) | 5時間40分 | 差異0件。手順書を確定 |
本番 | 2025/2/28〜3/1 | 全データ | 5時間52分 | 差異0件。予定より8分早く完了 |
稼働後1か月の本番障害は2件でした(いずれも軽微、目標3件以内)。
■ 結果:QCDの計画と実績

軸 | 指標 | 目標 | 実績 | 判定 |
|---|---|---|---|---|
Q | 受入テストの重大不具合 | 0件 | 0件 | 達成 |
Q | 稼働後1か月の本番障害 | 3件以内 | 2件 | 達成 |
C | 総費用 | 2億3,200万円以内 | 2億2,680万円(97.8%) | 達成 |
D | 本番稼働日 | 2025年3月1日 | 2025年3月1日 | 達成 |
S | スコープ | 243件 | 198件(81.5%)+45件は翌年度 | 一部未達 |
事業上の成果は、稼働6か月後(2025年8月)に測定しました。
成果指標 | 開始時 | 目標 | 6か月後 | 達成率 |
|---|---|---|---|---|
欠品による販売機会損失 | 年4.2億円 | 年2.1億円 | 年2.6億円 | 76% |
期末値引き率 | 22.0% | 17.0% | 18.4% | 72% |
店舗からの在庫問い合わせ | 月1,800件 | 月600件 | 月740件 | 88% |
3つとも目標には届いていませんが、第2弾(店舗間移動の最適化)を送った影響を考えると、想定どおりの水準です。投資2億2,680万円に対し、初年度の効果は約1.9億円(機会損失の削減1.6億円+値引き削減0.3億円)と算定されました。
■ このプロジェクトで使っていた管理帳票
課題は全期間で142件。うち代表的なものを8件挙げます。
No | 発生日 | 区分 | 内容 | 担当 | 期限 | 完了日 |
|---|---|---|---|---|---|---|
C-018 | 5/20 | 業務 | 店舗間移動中の在庫をECで引き当てるか決まらない | 業務/佐野 | 6/14 | 8/2 |
C-031 | 6/3 | 業務 | 取り置き期限切れの自動解除ルールが未定 | 店舗運営/大橋 | 6/21 | 8/9 |
C-047 | 6/18 | システム | 倉庫WMSの入荷検品データが日次バッチのみ | 情シス/林 | 7/5 | 7/3 |
C-063 | 7/2 | 体制 | 業務チームが兼任で要件レビューの時間を取れない | PM/村瀬 | 7/19 | 7/26 |
C-078 | 7/22 | 業務 | セール価格のEC反映が店舗と異なるタイミング | EC/川口 | 8/9 | 8/8 |
C-095 | 9/10 | 計画 | 第2弾に送る要件の線引きが曖昧 | PM/村瀬 | 9/20 | 9/19 |
C-112 | 11/8 | 品質 | 結合テストで在庫引き当ての競合が再発 | A社/高瀬 | 11/22 | 11/20 |
C-131 | 2/14 | 移行 | 旧システムの商品コードに重複1,240件 | 情シス/林 | 2/21 | 2/20 |
C-018とC-031は、期限から7週間以上遅れています。この2件が要件確定の遅れの中心でした。9月以降は、期限内または期限前の完了に変わっています。
リスクは全期間で31件を登録しました。主要な6件です。
No | リスク | 影響度 | 発生確率 | 想定される影響 | 対応 | 結果 |
|---|---|---|---|---|---|---|
R-03 | 要件が確定せず設計に着手できない | 大 | 高 | 2か月の遅延 | 例外ケースを早期に洗い出す | 顕在化(8月) |
R-07 | 兼任により業務側の確認が滞る | 中 | 高 | 4週の遅延 | 火曜午後を専任時間として確保 | 顕在化(7月) |
R-11 | 春物商戦に稼働が間に合わない | 大 | 中 | 機会損失 約1.1億円 | スコープの2段階化 | 回避 |
R-15 | 移行データの品質不良 | 中 | 中 | 稼働延期 | リハーサルを3回実施 | 対応済 |
R-19 | 倉庫WMSベンダーの要員を確保できない | 中 | 低 | 2週の遅延 | 移行期の稼働を事前に契約 | 発生せず |
R-24 | 稼働直後に問い合わせが集中する | 中 | 高 | 店舗業務の停滞 | 2週間の臨時窓口を設置 | 対応済 |
TODOは週次で管理しました。計画を改定した9月第2週の一覧です。
No | 内容 | 担当 | 期限 | 状態 |
|---|---|---|---|---|
T-412 | 第2弾へ送る45件の一覧を作成 | 村瀬 | 9/13 | 完了 |
T-413 | 分割案をステコミ資料に反映 | PMO/岸 | 9/17 | 完了 |
T-414 | ベンダーA社へ改定見積を依頼 | 村瀬 | 9/13 | 完了 |
T-415 | 店舗運営部へ第2弾の内容を説明 | 大橋 | 9/20 | 完了 |
T-416 | 改定WBSを管理システムに登録 | PMO/岸 | 9/18 | 完了 |
T-417 | 予備費充当の申請書を作成 | 村瀬 | 9/24 | 完了 |
■ 振り返り:効いたこと、効かなかったこと
効いたこと | なぜ効いたか |
|---|---|
動かせない日付を1つだけに絞っていた | M5以外は調整可能と最初に合意していたため、分割の議論がすぐ始められた |
SPIとCPIを分けて見ていた | 「遅れているが無駄遣いはしていない」と読めたので、増員という誤った打ち手を避けられた |
3案を数字で並べた | ステコミがその場で判断できた。追加費用と機会損失を同じ土俵に載せたのが大きい |
兼任者の時間を曜日で押さえた | 割合での約束は守られないが、曜日と時間帯なら守られた |
効かなかったこと | 何が足りなかったか |
|---|---|
4〜5月の進捗報告 | SPIは見ていたが0.94程度だったため誰も動かなかった。要件の合意件数という先行指標を見るべきだった |
本部資料をもとにした要件定義 | 店舗の実態と乖離していた。先に3〜5店舗を回っていれば、例外ケースの多くを事前に拾えた |
ベンダーへの増員打診(7月) | 2名の増員を検討したが、教育に1.5か月かかると分かり断念。もっと早い時期でなければ効かない打ち手だった |
■ 自分の現場で使うなら
この事例から持ち帰れる手順は4つです。
動かせない日付を1つに決め、他は調整可能と明言しておく:立ち上げ時の合意事項として文書に残す
要件の合意件数を毎週数える:SPIより早く異変が出る。分母(全要件数)が増えたときが最初の警報
SPIとCPIを並べて読む:SPIだけ大きく下がるなら、原因は「決まらない」こと。人を増やしても解決しない
打ち手は必ず3案を数字で出す:追加費用と、やらなかった場合の機会損失を同じ単位で並べる
特に2つ目です。このプロジェクトで最初に崩れたのは要件の分母でした。186件が243件になった6月の時点で気づけていれば、対応はもっと楽だったはずです。