🎬 シナリオ
MOps（Marketing Ops/販促システム）チームに、マーケティング部門から新しい訴求施策の相談が持ち込まれた。競合ECサイトの多くが商品一覧・詳細ページで「残り3点」「残りわずか」といった在庫僅少表示を行っており、購入の緊急性を演出してCVR（購入転換率）を高めている。マーケティング部長は「うちのサイトにも導入したい」と依頼してきた。
ただし、この手の施策には社内に苦い記憶がある。1年前、CS部門が主導して似たような「在庫わずか」表示を検討したことがあった。当時は在庫データが日次更新（1日1回の連携）だったため、実際には在庫が十分にある商品にまで「残りわずか」と表示されてしまう不具合が発生し、これに気づいたユーザーがSNSに「在庫あるのに嘘の表示で急かされた」と投稿。プチ炎上とまではいかなかったものの社内で問題視され、法務部門から待ったがかかって施策自体がお蔵入りになった経緯がある。
法務部門の担当者に今回の再検討を相談したところ、次のような懸念が示された。「景品表示法には『有利誤認表示』という規制があります。実際の取引条件よりも著しく有利であると誤認させる表示は、それが結果的に事実と異なっていた場合、法令違反として問題になり得ます。在庫僅少表示は、正確性を欠くとまさにこれに該当しうる典型例です。今回導入するなら、表示の正確性をどう担保するかを先に詰めてください」
一方でエンジニアリング側の状況は当時から変わっている。現在、商品在庫データは物流部門が管理する倉庫管理システム（WMS）から15分間隔のバッチ処理でECサイト側に連携される仕組みが整っており、日次更新だった1年前よりはデータの鮮度が改善している。とはいえ「15分間隔」である以上、表示時点と実際の在庫数の間に最大15分程度のタイムラグが生じる可能性は残る。
確認できている制約:
- 在庫データはWMSから15分間隔のバッチ連携。リアルタイム反映ではない
- 過去の類似施策は法務NGで一度お蔵入りになった経緯がある（表示の正確性が争点だった）
- 開発体制はエンジニア1名（あなた）、デザイナー0.2名（既存バッジデザインの流用中心）、4週間以内でのリリースを想定
- 対象は商品一覧ページ・商品詳細ページ（他チャネルは対象外）
📝 課題
あなたのタスク: 上記の状況をもとに、「在庫僅少表示（残りわずかバッジ）機能」のPRDを作成してください。背景/課題/ゴール/非ゴール/要件/成功指標/オープンな論点の7セクションを必ず含めること。
🔍 ヒント（段階的開示）
取り組む前のヒント
- 今回のシナリオには「CVRを高めたい」という要求と「表示の正確性を欠くと法的リスク・炎上リスクがある」という制約が同時に存在する。この2つを両方とも「課題」に落とし込めるかがポイント
- 過去の失敗（日次更新時代の誤表示によるプチ炎上）が「なぜ今回は違う設計にするのか」の根拠になる。背景に事実として書き、課題でその教訓をどう活かすかにつなげると筋が通る
- 15分間隔のバッチ更新という技術的な前提は、「表示できる情報の粒度」（具体的な残数か、定性的な表現か）や「更新が止まった場合のフェイルセーフ」といった要件に直結する。ここを見落とすと法務レビューで詰められる
- ゴール・成功指標には「伸ばしたい指標（CVR）」と「守りたい上限（表示に関するクレーム・法務指摘の件数）」の両方を置けるとよい
- 非ゴールでは、シナリオ中で明示的に絞り込まれている範囲（対象チャネル、リアルタイム化の是非）に加え、「なぜ今回はそこまでやらないのか」の理由も書けるとなおよい
📚 背景知識・用語解説
PRD（Product Requirements Document、プロダクト要求仕様書）とは、「何を」「なぜ」作るのかをチーム全員が同じ理解で進められるようにするための文書です。エンジニアやデザイナーが実装方針（How）を検討する前提として、PdM（またはPdM役）が「何を解決したいか（Why/What）」を明文化する役割を持ちます。
過去の失敗を課題設定に活かす: 今回のように「過去に一度お蔵入りになった施策の再挑戦」を企画する場合、過去の失敗をなかったことにせず、背景に事実として明記し、課題セクションで「前回と何が変わったから再挑戦できるのか」「前回の教訓をどう設計に反映するのか」まで書くことが重要です。これを省くと、レビューする側（今回で言えば法務担当）は「また同じ失敗を繰り返すのでは」という不信感を拭えません。
データの鮮度とフェイルセーフ設計: 今回のようにバッチ更新でデータを連携している場合、表示している情報は常に「ある時点のスナップショット」であり、リアルタイムの実態と乖離しうるという前提を要件に組み込む必要があります。具体的には、①表示できる情報の粒度を「事実と乖離しても実害が小さい表現」に抑える（例: 具体的な残数ではなく定性的な表現にする）、②データが古くなりすぎた場合は表示自体を止める、という2種類のアプローチがあり、両方を組み合わせることでリスクを下げられます。
ガードレール指標（Guardrail Metric）: 「伸ばしたい指標」だけでなく、「悪化させてはいけない指標」を事前に決めておく考え方です。今回で言えば「対象商品群のCVR」が伸ばしたい指標、「表示の正確性に関するCS問い合わせ・法務指摘の件数」がガードレール指標にあたります。
✅ 模範解答
背景
- 競合ECサイトの多くが、商品一覧・詳細ページで在庫僅少表示（「残り◯点」「残りわずか」等）を実装し、購入の緊急性を演出することでCVR向上を図っている
- 1年前、CS部門主導で類似施策を検討した際、当時は在庫データが日次更新であったため、実際には在庫が十分にある商品にまで「残りわずか」と表示される不具合が発生。ユーザーがSNSに「在庫あるのに嘘の表示」と投稿し、法務部門から待ったがかかって施策自体が中止になった経緯がある
- 現在、在庫データはWMS（倉庫管理システム）から15分間隔のバッチ処理でECサイト側に連携されており、日次更新だった1年前よりデータの鮮度は改善している。ただし15分間隔である以上、表示時点と実在庫数の間に最大15分程度のタイムラグが生じる可能性は残る
- 法務部門からは、景品表示法の「有利誤認表示」規制に抵触するリスクが事前に指摘されている
課題
- 在庫僅少表示は競合対比でのCVR向上が期待できる一方、表示の正確性を欠くと、1年前と同様の炎上リスクおよび景品表示法上の法的リスクを負う
- 在庫データが15分間隔のバッチ更新である以上、表示内容と実在庫数の乖離を完全にゼロにすることはできない。「乖離が発生しうる」という前提のもとで、乖離が発生しても実害が小さい設計にする必要がある
- 「CVRを最大化したい」というマーケティング部門の要求と、「不正確な表示を避けたい」という法務部門の要求は本質的にトレードオフの関係にあり、どちらか一方だけを追う設計にすると、1年前と同じ経緯（法務NGでの施策中止）を繰り返しかねない
ゴール
- 在庫が少ない商品に対し、法務レビューを通過する形で視認性の高い在庫僅少表示を行い、対象商品群のCVRを改善する
- 表示の正確性に起因するCS問い合わせ・法務からの指摘を発生させない（1年前の再発を防ぐ）
非ゴール（今回やらないこと）
- 全商品への常時の在庫数表示（対象は在庫僅少の商品のみとし、通常在庫のある商品には表示しない）
- 在庫僅少を理由にした動的な価格変更（値上げ等）。今回はあくまで表示のみのスコープとする
- WMS連携のリアルタイム化（新規基盤構築）。データ鮮度の課題は表示側の設計（定性表現・フェイルセーフ）で対応し、連携基盤そのものの刷新は今回のスコープに含めない
- EC以外のチャネル（SNS広告・メールマガジン等）での在庫僅少訴求。まずはECサイト内（一覧・詳細ページ）に限定して効果とリスクを検証する
要件
機能要件
| ID | 要件 | 詳細 |
|---|---|---|
| F1 | 在庫僅少バッジの表示 | 在庫数がしきい値（暫定: 5点）以下の商品に対し、商品一覧ページ・商品詳細ページにバッジを表示する |
| F2 | 定性表現への統一 | バッジの文言は「残り◯点」という具体的な数値ではなく、「残りわずか」という定性的な表現に統一する。具体的な数値を表示すると、バッチ更新のタイムラグにより数値が実態とずれた際に、誤認表示として指摘されるリスクが高まるため |
| F3 | データ鮮度に基づく自動非表示 | 在庫データのバッチ更新が想定時刻（15分間隔）から一定時間（暫定: 30分）以上遅延している場合、当該時点のデータに基づくバッジ表示を自動的に停止する。更新が止まっている状態で「古い在庫僅少情報」を表示し続ける事故を防ぐフェイルセーフ |
| F4 | 対象外商品の除外 | 予約商品・入荷待ち商品・在庫連携の対象外となっている商品は、バッジ表示の対象から除外する |
| F5 | 法務レビューの実施と記録 | リリース前に、表示条件（しきい値・文言・非表示ロジック）について法務部門のレビューを受け、レビュー結果と合意内容を文書として残す |
| F6 | 効果測定用のイベントトラッキング | バッジ表示の有無による商品ごとのCVRを比較できるよう、表示イベントと購入イベントを紐付けて計測する |
非機能要件
| ID | 要件 | 詳細 |
|---|---|---|
| N1 | 表示速度への影響を出さない | しきい値判定・鮮度判定のロジックが、商品一覧ページの表示速度（既存のパフォーマンス基準）に悪影響を与えないこと |
| N2 | しきい値・文言の運用側での調整 | しきい値（5点）や表示文言は、コード変更を伴わずに運用担当者が設定変更できる形にする。法務から指摘があった場合に迅速に対応するため |
成功指標
| 指標 | 現状値 | 目標値 | 計測方法 |
|---|---|---|---|
| 在庫僅少バッジ表示商品群のCVR | 計測なし（新規） | リリース後1ヶ月でバッジ非表示群と比較し、優位な差があるかを確認する | 商品ごとの表示イベント×購入イベントの突合（A/Bテスト的な比較） |
| 表示の正確性に関するCS問い合わせ件数 | 0件（施策自体が存在しないため） | 0件を維持する | CS部門の問い合わせカテゴリ集計 |
| リリース後の法務指摘件数 | - | 0件（リリース前レビューで論点を出し切り、リリース後の指摘発生を防ぐ） | 法務部門からのエスカレーション記録 |
オープンな論点
- しきい値「5点」は暫定値であり、商品カテゴリによって適正在庫水準が異なる（例: アパレルはサイズ違いで在庫が分散するため、同じ5点でも意味合いが異なる）ため、カテゴリ別にしきい値を変えるべきかは未検討。企画会議で議論したい
- 「残りわずか」という一段階の定性表現だけでよいか、それとも「あと少し」「残りわずか」のような段階的な表現にすべきかは未決定。段階を増やすほど訴求力は上がりうるが、誤認表示リスクも比例して上がる可能性がある
- WMSのバッチ更新間隔を15分からさらに短縮すべきかどうかは、更新頻度短縮に伴うインフラコストとのトレードオフであり、今回のPRDのスコープ外だが将来的な論点として残しておく
- 法務レビュー（F5）にどの程度のリードタイムがかかるかは未確定。4週間のスケジュールにレビュー期間をどう組み込むか、企画会議で法務担当と調整が必要
💡 なぜこう作るのか
⚠️ よくある失敗パターン
| 失敗パターン | なぜ問題か | 改善策 |
|---|---|---|
| 過去の失敗を背景に書かず、新規施策として提案する | レビューする側（今回は法務）が「前回と何が変わったのか」を判断できず、口頭で経緯を説明する羽目になり、PRDの文書としての価値が下がる | 過去の失敗は事実として背景に明記し、課題セクションで「前回との違い」を明示する |
| 技術的な制約（バッチ更新の間隔）を無視して具体的な数値表示を要件にする | 開発が進んでから「数値がずれる」という問題が発覚し、法務レビューやQA段階で要件の作り直しが発生する | 技術的な制約が表示の粒度に与える影響を、要件定義の早い段階で洗い出す |
| CVRという主指標だけを成功指標に置く | 施策が「数値上は成功」していても、表示の正確性に関する問題が水面下で進行していることに気づけない | ガードレール指標（今回はCS問い合わせ件数・法務指摘件数）を必ず成功指標に含める |
| フェイルセーフ（データが古くなった場合の挙動）を要件に含めない | 「バッチが遅延した場合どうなるか」という運用時に必ず起きうる状況への回答がPRDにないため、実装時にエンジニアが独自判断で仕様を決めてしまい、後から仕様として合意されていない挙動が発覚する | 「正常系」だけでなく「データが古い・更新が止まった場合」のような異常系の挙動も要件に含める |
🏆 実務での使いどころ
在庫僅少表示のような訴求施策は、マーケティング的な効果とコンプライアンス上のリスクが表裏一体になっている典型例です。特に一度社内で失敗した施策を再挑戦する場面では、PRDが「前回何が問題で、今回はどう解決したか」を説明する文書としての役割を担います。エンジニア出身でPdM/PM方向を目指す場合、法務・CS・マーケティングという立場の異なる関係者それぞれの懸念を1つのPRDの中に同時に反映させる書き方に慣れておくと、実際の現場で「効果を求める事業部門」と「リスクを警戒する管理部門」の板挟みになった際にも、両方の要求を要件・成功指標として具体的に落とし込んで説明できるようになります。
🚀 次のステップ
このPRDの要件（F1〜F6）のうち、特にF3（データ鮮度に基づく自動非表示）は「バッチ更新が遅延したらどうなるか」という条件分岐が絡む要件です。次はこの要件をユーザーストーリー形式（テーマ4-2）に分解し、受け入れ条件（テーマ4-3、Given-When-Then形式）で「更新が29分遅延した場合」「31分遅延した場合」のような境界値を明確にする練習に進むとよいでしょう。また、しきい値5点の妥当性やカテゴリ別の扱いは、次回以降にRICEスコアリングやKanoモデル（PdM-優先順位カテゴリ）で優先度を検討する材料にもなります。