概要
JTBD（Jobs to Be Done）: Why より Why を先に
「ダッシュボードを速くしたい」はソリューション要求。JTBD では「私は [状況] のとき、[ジョブ] をしたい。なぜなら [成果] を達成したいからだ」の形で本当のニーズを掘り起こす。ジョブを先に定義することで解決策の選択肢が広がり、ムダな機能開発を防ぐ。
RICE スコア: 定量的優先順位付け
RICE = Reach × Impact × Confidence / Effort。MoSCoW の「Must/Should」判断に定量根拠を与える。Reach の定義（エンドユーザー vs 内部ユーザー）を揃えないと比較が無意味になる点が最大の落とし穴。
ユーザーストーリーマッピング: 全体像の可視化
横軸=ユーザー行動フロー（変えない）、縦軸=優先度でストーリーを配置。MVP ラインを引くことで「どの行動フローのどのストーリーが MVP に入るか」が一目でわかり、スコープ漏れと認識齟齬を防ぐ。
プロダクト三層構造: 投資対象の分類
Layer 1（コア価値）→ Layer 2（機能）→ Layer 3（体験）の3層で整理。コア価値に直結しない機能追加リクエストを「Should/Could/Won't」に振り分けることで、PdM がスコープを守りながらステークホルダーを納得させる共通言語になる。
問題
ECサイト MOps チームで「Q3 キャンペーン配信基盤のロードマップ」を策定することになった。PdM として以下の悪い意思決定プロセスには 7つの設計上の問題 が潜んでいる。問題点を全て洗い出し、JTBD・MoSCoW・RICE スコア・ユーザーストーリーマッピング・プロダクト三層構造 を活用した Bad→Good ロードマップ設計を行え。
制約・前提条件
- チーム規模: PdM 1名、エンジニア 3名（スプリント 2週間）
- 対象システム: Argo Workflows × Pub/Sub × Cloud Run v2 × BigQuery × dbt
- Q3 期間: 2026-07-01〜2026-09-30（スプリント 6本）
- ステークホルダー: マーケティングMG、エンジニアリングMG、CFO
- 現状の課題: 配信失敗率 3.2%・ダッシュボード反映が翌日・A/B テストリードタイム 2週間
期待する回答形式: 問題点の列挙（番号付き）+ JTBD 仮説シート + プロダクト三層 + RICE スコア表 + ユーザーストーリーマップ + Q3 ロードマップ（KR 付き）
悪い意思決定フロー (Before)
このプロセスには 7つのビジネス/PM 設計の問題 が隠れています。
現状のロードマップ策定フロー — 根拠なし / JTBD なし / スコープ無限
# ① 機能リクエストを全員から収集（Slack で意見募集）
# 問題①: 全員が「これは最重要」と言う。優先順位の根拠なし
# ② マーケター: 「ダッシュボードを速くして」
# エンジニア: 「DLT を設定したい」
# CFO: 「AI を使った機能を入れてほしい」
# 問題③: ユーザーの「言葉（What）」をそのまま機能化。JTBD（Why）を掘っていない
# ③ 機能リストをスプレッドシートに並べる（40件）
# 問題④: 機能リスト ≠ ロードマップ。ユーザー行動フローが見えない
# ④ ROI 試算なし、工数見積もりなし
# 問題②: 「効果がある」は根拠にならない。RICE スコアがない
# ⑤ 全機能を Q3 ロードマップに入れる（優先度 = 全部「高」）
# 問題⑤: プロダクト三層（コア価値/機能/体験）の区別なし。全部同列
# ⑥ PdM が一人でロードマップを作り、完成後に共有
# 問題⑥: ステークホルダー合意プロセスなし。CFO/EM に突然提案
# ⑦ 機能リリース時に「成功の定義」がない
# 問題⑦: 何をもって完了/成功とするかの KPI が未定義のままリリース問題点サマリー（7点）
1全機能が「最優先」でスコープ無限 — MoSCoW で Must/Should/Could/Won't に分類し、チームで合意を取る
2ROI・工数試算なし — RICE = Reach × Impact × Confidence / Effort で定量化。比較可能にする
3ユーザーの「言葉」を機能化（JTBD 欠如） — 「ダッシュボードを速く」の背後にあるジョブ（翌朝の意思決定）を掘る
4機能リスト ≠ ロードマップ — ユーザーストーリーマッピングで横軸=行動フロー、縦軸=優先度で可視化
5プロダクト三層の混在 — コア価値/機能/体験の3層に分類し、投資対象の優先度を明確化
6ステークホルダー合意プロセスなし — RICE 根拠 + MoSCoW 分類を1枚スライドで三者 Sign-off
7成功指標（KPI）未定義 — 各フィーチャーに OKR の KR（数値・期限）を紐づける
ヒント（段階的開示）
ヒント1 — 方向性
現状の悪い意思決定プロセスの根本は「Why（なぜ作るか）を定義せずに What（何を作るか）から議論を始めている」点にある。プロダクト三層構造（コア価値→機能→体験）と JTBD で「ユーザーが雇用したいジョブ」を先に定義することが出発点。ジョブが定義されて初めて RICE スコアの Impact を正確に見積もれる。
ヒント2 — アプローチ
- 問題①: 全機能が「重要」→ MoSCoW でラベル付け（Must/Should/Could/Won't）
- 問題②: ROI 試算なし → RICE = Reach × Impact × Confidence / Effort で定量化
- 問題③: JTBD 欠如 → 「私は[状況]のとき、[ジョブ]をしたい。なぜなら[成果]を達成したいからだ」テンプレートで掘る
- 問題④: 機能リスト → ユーザーストーリーマッピング（横=ユーザー行動フロー、縦=優先度）
- 問題⑤: 三層混在 → Layer1（コア価値）/ Layer2（機能）/ Layer3（体験）に分類
- 問題⑥: 合意なし → RICE 根拠 + MoSCoW を1枚スライドで三者 Sign-off
- 問題⑦: KPI 未定義 → 各フィーチャーに OKR の KR（数値・期限・ベースライン）を設定
ヒント3 — 骨格
# RICE スコア計算式
RICE = Reach × Impact × Confidence / Effort
# Reach: 対象ユーザー数/期間（内部 vs エンドユーザーで桁が変わる）
# Impact: GMV 改善インパクト (0.25/0.5/1/2/3)
# Confidence: 確信度 % (80% = 0.8)
# Effort: スプリント工数（人×スプリント）
# ジョブ理論（JTBD）テンプレート
# 私は [状況] のとき、[ジョブ] をしたい。
# なぜなら [成果] を達成したいからだ。
# 現在は [制約] があるため、これができていない。
# プロダクト三層構造
# Layer 1: コア価値 = 「なぜ存在するか」
# Layer 2: 機能 = 「何ができるか」
# Layer 3: 体験 = 「どのように使うか」問題点分析（7点）
| # | 問題点 | 分類 | 改善方法 |
|---|---|---|---|
| 1 | 全機能が「最優先」でスコープ無限 | 優先順位 | MoSCoW でラベル付け + チーム合意 |
| 2 | ROI・工数試算なし（感覚優先） | 定量性 | RICE = Reach × Impact × Confidence / Effort |
| 3 | ユーザーの「言葉」を機能化（JTBD 欠如） | 顧客理解 | JTBD テンプレートで本当のジョブを掘る |
| 4 | 機能リスト ≠ ロードマップ | 可視化 | ユーザーストーリーマッピング（横=行動フロー） |
| 5 | プロダクト三層の混在 | 分類 | コア価値/機能/体験の3層に分離 |
| 6 | ステークホルダー合意プロセスなし | 合意形成 | RICE 根拠付き1枚スライドで三者 Sign-off |
| 7 | 成功指標（KPI）が未定義 | 計測 | 各フィーチャーに OKR の KR（数値・期限）を設定 |
プロダクト三層構造図 — MOps キャンペーン配信基盤
模範解答
① JTBD 仮説シート — 本当のジョブを定義する（修正③）
Bad — ユーザーの「言葉」をそのまま機能化
# マーケター: 「ダッシュボードを速くしてほしい」
# → そのまま「Materialized View を実装する」に変換
#
# 問題③: Why（ジョブ）を掘っていない
# → 実は「翌朝のミーティングまでに施策結果を判断したい」が本当のジョブ
# → 解決策は Materialized View 以外にも「Push 通知」「メール配信結果サマリー送信」もある
# → ジョブを定義しないと最適解を見落とすGood — JTBD テンプレートで本当のジョブを掘る
## JTBD 仮説シート（MOps キャンペーン配信基盤）
### ジョブ #1: リアルタイム意思決定
私は【キャンペーン施策を打った直後】、
【配信結果をリアルタイムで確認する】ジョブをしたい。
なぜなら【翌朝のミーティングで施策の継続/停止を判断したい】からだ。
現在は【ダッシュボード反映が翌日（24時間遅延）】のため、これができていない。
→ 採用する解決策: BigQuery Materialized View + Looker Studio Streaming
→ 却下した代替案: Push 通知（UX Layer — ジョブの中心でない）
→ 成功基準 KR: 配信結果の反映遅延を 24h → 1h 以内に短縮（2026-08-31）
### ジョブ #2: 仮説検証サイクルの高速化
私は【新しい件名・セグメントの仮説を持ったとき】、
【A/B テストをすぐに開始できる】ジョブをしたい。
なぜなら【週1本の仮説検証ペースを実現して施策精度を上げたい】からだ。
現在は【A/B テスト設計〜実施まで2週間かかる（設計書作成・承認・実装）】ため、これができていない。
→ 採用する解決策: A/B テスト self-service UI + GitHub auto-commit フォーム
→ 却下した代替案: エンジニアが毎回テスト設定（スケールしない）
→ 成功基準 KR: A/B テストのリードタイム 14日 → 3日以内（2026-09-30）
### ジョブ #3: 配信失敗の自動回復
私は【キャンペーン配信が失敗したとき】、
【手動介入なしに自動リトライ・通知される】ジョブをしたい。
なぜなら【失敗率 3.2% = 月約 1,600件 = 営業機会損失 ¥2.4M 相当】だからだ。
現在は【Pub/Sub DLT 未設定・障害検知が DataDog アラートのみ・手動リドライブ】のため対応が遅い。
→ 採用する解決策: Pub/Sub DLT（dead_letter_policy max_delivery_attempts=5）+ Cloud Run 冪等リトライ
→ 成功基準 KR: 配信失敗率 3.2% → 0.5% 以下（2026-08-15）
## ジョブ定義のアンチパターン
# ❌ ジョブ: 「AI を使った機能がほしい」
# → ソリューション要求 + CFO の「声」。JTBD ではない
# ✅ ジョブ: 「件名候補を30秒で3案生成し、A/B テストに入れたい」
# → 背後のジョブ（仮説検証高速化）が明確。AI はその解決手段の一つ② RICE スコア — 定量的優先順位付け（修正②）
Bad — 「重要そう」「効果がある」で優先順位決定
# NG: 施策会議での会話例
# マーケターMG: 「ダッシュボードのリアルタイム化が最重要です」
# CFO: 「AI 件名サジェストを入れないと競合に負ける」
# EM: 「DLT の設定が技術負債解消に必要です」
# PdM: 「全部やります」（根拠なし、工数計算なし）
# → 全部 Q3 に入れて全部未完了で Q3 終了Good — RICE スコアで定量優先順位付け
## RICE スコア算出表（Q3 ロードマップ候補）
# RICE = Reach × Impact × Confidence / Effort
# Reach: 対象ユーザー数/期間
# → エンドユーザー（配信先）: 50,000名/月
# → 内部ユーザー（マーケター）: 6名
# Impact: GMV 改善インパクト (0.25=最小/0.5/1/2/3=最大)
# Confidence: 確信度 % → 0.8
# Effort: スプリント数（1スプリント=1）
| 機能 | Reach | Impact | Conf | Effort | RICE | MoSCoW | JTBD |
|-------------------------------|:-------:|:------:|:----:|:------:|:------:|:------:|------|
| Pub/Sub DLT 配信失敗改善 | 50,000 | 3.0 | 0.90 | 1.5 | 90,000 | Must | #3 |
| ダッシュボードリアルタイム化 | 6 | 2.0 | 0.85 | 2.0 | 5.1 | Must | #1 |
| A/B テストセルフサービス化 | 6 | 2.0 | 0.75 | 3.0 | 3.0 | Should | #2 |
| セグメント管理 UI | 6 | 1.0 | 0.70 | 2.0 | 2.1 | Should | #2 |
| AI 件名サジェスト | 6 | 1.0 | 0.40 | 4.0 | 0.6 | Could | — |
| SMS チャネル追加 | 30,000 | 1.0 | 0.30 | 8.0 | 1,125 | Won't | — |
# RICE 解釈のポイント:
# ① Reach の定義を揃える
# - Pub/Sub DLT: エンドユーザー 50,000名（配信受取人）を Reach に使う
# - ダッシュボード RT化: 内部ユーザー 6名（マーケター）が Reach
# → 桁が異なるため比較する場合は定義を統一するか分けて評価する
#
# ② Confidence が低い機能（AI 件名サジェスト=0.4）は
# 小規模 PoC で確信度を上げてから再評価（Sprint 5-6 で探索）
#
# ③ SMS チャネルは RICE=1,125 と高く見えるが Effort=8 sprint = Q3 全体
# → Must 条件（Effort ≤ 3 sprint）を満たさない → Won't
#
# ④ Must の判定: RICE 数値 + コア価値直結度 + Effort ≤ 2 sprint の3条件
# 数値だけで機械的に決めない③ ユーザーストーリーマッピング（修正④）
Bad — 機能リストを並べただけのロードマップ
# NG: 機能リスト（40件）をスプレッドシートに並べる
# - Materialized View 実装
# - DLT 設定
# - A/B テスト自動化
# - セグメント管理 UI
# - AI 件名サジェスト
# - ...（全部「優先度: 高」）
#
# 問題: ユーザーの行動フローが見えない
# → どの行動フローでどの機能が必要かが不明
# → MVP ラインが引けない（全部入れようとする）
# → スコープ無限→全部未完了→チームが疲弊Good — ユーザーストーリーマッピング（横=行動フロー・縦=優先度）
## ユーザーストーリーマップ（マーケター視点）
行動フロー（横軸 — 変えない）:
[施策企画] → [ターゲット選定] → [コンテンツ制作] → [配信設定] → [効果測定] → [意思決定]
═══════════════════════════════════════════════════════════════════
Sprint 1-2 リリース（MVP / Must — KR-1: 失敗率 & KR-2: RT化）
───────────────────────────────────────────────────────────────────
施策企画: OKR-ICE スコアシート連動（既存フロー改善・ノーコスト）
ターゲット選定: BigQuery 直接確認（UI は Sprint 3 以降）
コンテンツ制作: 件名 A/B テスト事前登録フォーム（GitHub auto-commit）
配信設定: Pub/Sub DLT 設定（max_delivery_attempts=5）+ Cloud Run 冪等リトライ
効果測定: Materialized View + Looker Studio リアルタイム（24h → 1h）
意思決定: KR ターゲットライン付き週次スプリントレビュー（既存改善）
Sprint 3-4 リリース（Should — KR-3: A/B テスト & KR-4: 着手率）
───────────────────────────────────────────────────────────────────
施策企画: RICE スコア連動施策バックログ管理（Notion / Linear）
ターゲット選定: セグメント管理 UI MVP（SQL 直書き廃止）
コンテンツ制作: A/B テストセルフサービスポータル v1（リードタイム 14日→3日）
配信設定: カナリアリリース（5% → 20% → 100% 段階配信 Argo）
効果測定: BigQuery Z検定 SQL 自動化（Excel 手動計算廃止）
意思決定: 施策 RICE 予測 vs 実績 乖離レポート（Looker Studio）
Sprint 5-6 探索（Could — PoC / 探索）
───────────────────────────────────────────────────────────────────
コンテンツ制作: LLM 件名サジェスト PoC（Confidence 向上目的）
効果測定: DataDog APM × OTel トレース連携（ジョブ可観測性）
意思決定: Q3 OKR 達成率 × 施策別 ROI 自動レポート
═══════════════════════════════════════════════════════════════════
Won't（Q3 スコープ外）:
- SMS/LINE チャネル追加（Effort=8 sprint → Q4 検討）
- 推薦エンジン（協調フィルタリング）統合
- 自動送信時刻最適化（機械学習）
## マッピングのポイント:
# ① 横軸（行動フロー）は変えない
# → 施策企画 → 配信設定 → 効果測定 → 意思決定 の順は常に固定
# ② MVP ラインは「行動フロー全段がカバーされる最小セット」で引く
# → Sprint 1-2 だけで [施策企画 → 意思決定] の全フローが一周回る
# ③ Won't は「削除」でなく「Q3 スコープ外」として明示
# → ステークホルダーが「忘れたのではない」と分かる④ Q3 ロードマップ（1枚スライド形式）— 修正⑥⑦
## Q3 2026 MOps キャンペーン基盤ロードマップ（PdM 提案）
Objective: マーケターが「打つ→見る→決める」を当日中に完結できる配信基盤
KR-1: 配信失敗率 3.2% → 0.5%（by 2026-08-15）← Pub/Sub DLT
KR-2: ダッシュボード反映遅延 24h → 1h（by 2026-08-31）← Materialized View
KR-3: A/B テストリードタイム 14日 → 3日（by 2026-09-30）← セルフサービス化
KR-4: RICE ≥ 3.0 の施策の週次着手率 ≥ 80%（Q3 通算）← プロセス改善
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
スプリント計画 関連 KR
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Sprint 1（07/01-07/14）: Pub/Sub DLT × 冪等リトライ実装 → KR-1
Sprint 2（07/15-07/28）: Materialized View + Looker RT化 → KR-2
Sprint 3（07/29-08/11）: セグメント管理 UI MVP → KR-3 前提
Sprint 4（08/12-08/25）: A/B テストセルフサービスポータル v1 → KR-3
Sprint 5（08/26-09/08）: BigQuery Z検定 SQL + 乖離レポート → KR-4
Sprint 6（09/09-09/30）: AI 件名サジェスト PoC + Q3 総括 → Confidence向上
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
GCP インフラコスト変化（CFO 向け）:
BQ Materialized View 追加: +$10/月（既存 $200 スキャン → $10 差分更新 → 実質削減）
Cloud Run min_instance_count=1 追加: +$15/月（コールドスタート排除）
Net 変化: -$175/月（コスト削減）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Sign-off ステークホルダー 確認内容
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
□ マーケティングMG: KR-1〜4 の成功定義・目標値に同意
□ エンジニアリングMG: スプリント工数見積もり（各 Sprint の Effort）に同意
□ CFO: Q3 GCP コスト変化（-$175/月）に同意
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
ロードマップ運用ルール:
- 月次戦略レビューで KR 進捗を全員に共有（Looker Studio ダッシュボード）
- RICE < 1.0 の機能追加リクエストは「バックログ + 根拠追記後に再評価」ルール
- KR が2週連続未進展 → EM/PdM でブロッカー特定 + スコープ見直し
- Won't リストは月次レビューで「Q4 候補」として継続評価ポイント解説
JTBD はソリューションより先に定義する
「ダッシュボードを速くしたい」はソリューション要求。JTBD テンプレートで「私は[状況]のとき、[ジョブ]をしたい。なぜなら[成果]を達成したいからだ」と掘ることで、解決策の選択肢が広がる。Materialized View だけでなく Push 通知・メールサマリーも候補に入る。ジョブを先に定義することで、最適解を見落とさなくなる。
RICE の Reach: 内部 vs エンドユーザーで桁が変わる
Pub/Sub DLT 改善は配信先 50,000名が Reach → RICE=90,000。ダッシュボードは内部ユーザー 6名が Reach → RICE=5.1。桁が異なるため、単純比較でなく「コア価値への直結度 + Effort ≤ 2sprint + RICE 上位」の3条件で Must を判断する。
ストーリーマップ: 横軸は固定・縦軸で MVP ラインを引く
横軸（ユーザー行動フロー）は絶対に変えない。縦軸（優先度）で MVP ラインを引くと「どの行動フローの中のどのストーリーが MVP に入るか」が議論になる。これにより「施策企画 → 意思決定の全フローが Sprint 1-2 で一周回る MVP」が設計できる。
MoSCoW の「Won't」は削除でなく「スコープ外の明示」
Won't に入れた機能を「なかったことにする」のではなく、「Q3 スコープ外として明示し、Q4 候補として月次レビューで継続評価する」ルールにすることが重要。ステークホルダーが「忘れたわけではない」と分かることで信頼を維持できる。
プロダクト三層: コア価値が揺らぐ機能は常に Must
「マーケターが打つ→見る→決めるを当日中に完結できる」がコア価値。Pub/Sub DLT（失敗率 3.2%）とダッシュボードリアルタイム化はコア価値を直撃するため Must。AI 件名サジェストはコア価値の「周辺機能」であり Could（Confidence も低い）。三層で分類することで投資の優先度が明確になる。
実務への応用
MOps/販促チームの Q3 ロードマップ策定に直接適用できる:
- JTBD ヒアリング: マーケターに「今の仕事の中で一番フラストレーションを感じる瞬間はいつか？」と聞く。答えをそのまま機能化せず、JTBD テンプレートで整理する
- RICE 算出の実データ活用: BigQuery の
INFORMATION_SCHEMA.JOBSから「現在の集計コスト」「平均遅延時間」を実測値として Impact に使う。推測でなく実データで Confidence を上げる - Sign-off 1枚スライド: CFO 向けには「GCP コスト変化（-$175/月）」のみを強調。マーケティングMG には KR-1〜4 の数値目標。EM には Sprint 工数見積もりを重点説明
- Won't リストの見える化: Notion の「Q3 Won't リスト」ページに機能名・却下理由・再評価条件（例: Confidence ≥ 0.7 になったら再検討）を記録し、月次レビューで確認
実装優先順位: ① JTBD ヒアリング（翌週）→ ② RICE スコア算出 + MoSCoW 分類（同週）→ ③ ユーザーストーリーマッピングセッション（1時間、EM/マーケター同席）→ ④ Sign-off スライド配布 + CFO/EM/マーケティングMG 三者承認（Sprint 1 開始前）
今日のまとめ
ロードマップ設計の核心は「What より Why を先に定義すること」。JTBD でジョブを定義し、RICE でインパクトを定量化し、MoSCoW でスコープ合意を取り、ユーザーストーリーマッピングで全体像を可視化することで、「声の大きい人の機能要求」ではなく「ビジネス価値の高い順」に投資できるプロダクト開発プロセスが実現する。プロダクト三層構造でコア価値への直結度を判断基準にすると、PdM がステークホルダーを納得させながらスコープを守れる。