概要
MVP はボトルネック1点を解消する
「全自動化」を最初の MVP にすると6ヶ月では終わらない。最もペインが大きい「セグメント更新2日リードタイム」を15分に短縮するだけで十分な価値が出る。
KPI は GMV 分解ツリーで設計する
「開封率を上げたい」ではなく「GMV ← CVR ← CTR ← 開封率」とツリーで考えることで、どこの指標を動かせば GMV が伸びるか議論できる。
MoSCoW で "Won't" を最初に合意する
スコープ外を明示しないと要求が際限なく増える。Won't の合意を最初に取ることがスコープ管理の要であり、PM の信頼につながる。
ロードマップはビジネス価値軸で説明する
技術詳細でなく「マーケ部長: 施策速度3倍」「事業部長: エンジニア工数40h/月削減」という価値軸でステークホルダーに伝える。
問題
ECサイトの MOps チームにて、「メールキャンペーン自動化基盤」のプロダクト企画が立ち上がった。あなたはエンジニア兼PM補佐として、プロダクトロードマップを設計し、MVP(最小実用製品)を定義せよ。また、四半期レビューで使えるKPI ダッシュボード設計(BigQuery + Looker Studio)と、エンジニアへのスプリント計画(バックログ優先順位付け)を一緒に提示すること。
シナリオ
現在のメール配信は手動オペレーションで以下の課題がある:
- 担当者がCSVを手作業でMA(Marketing Automation)ツールにアップロード
- セグメント条件の更新が毎回エンジニア依頼(2日リードタイム)
- 配信後の効果計測(開封率・クリック率・CVR)はバラバラのExcelで管理
- 月間配信数: 約40万通、GMVへの貢献が不明瞭
目標: 6ヶ月でメールキャンペーン配信フローをエンジニア工数ゼロで運用可能にする。
制約・前提条件
- チーム構成: エンジニア3名(Backend×1, DE×1, Frontend×1)、マーケター2名
- 技術スタック: Python, GCP(BigQuery / Cloud Run / Pub/Sub), Argo Workflows, dbt
- MA ツール: 既存の外部 SaaS(API 提供あり)
- ステークホルダー: 事業部長(KPI重視)・マーケ部長(運用効率重視)
- 予算: 開発工数のみ(新規インフラ費 月10万以下)
期待する回答形式: (1) ロードマップ(3フェーズ)、(2) MVP の定義(ユーザーストーリー + 受け入れ条件)、(3) KPI 設計(ツリー構造)、(4) バックログ優先順位(MoSCoW法)、(5) リスクと対策
現状の課題 (Before) vs 目標 (After)
現在の手動フローには 4つの構造的課題 がある。MVP はここを解消する。
現状フロー — 手動オペレーション(問題だらけ)
# 現在のキャンペーン配信フロー
1. マーケター → エンジニアに Slack でセグメント変更依頼
リードタイム: 2営業日 ⚠️
2. エンジニアが BigQuery でクエリを書いてCSV出力
手作業 × 月20件 = 月40h消費 ⚠️
3. マーケターが MA ツールにCSVを手動アップロード
ファイル形式ミスで再送 多発 ⚠️
4. 配信後の効果計測
- MA ツール: 開封率・CTR(別画面)
- GA: CVR(別ツール)
- 注文DB: GMV(別DB)
→ バラバラのExcelで手集計 ⚠️
# 結果: KPI の因果関係が不明瞭
# メール経由 GMV 貢献 = 不明
目標フロー — 自動化後(6ヶ月後)
# 自動化後のキャンペーン配信フロー
1. マーケターが UI から直接セグメント条件を設定
リードタイム: 15分以内 ✅(2日→15分)
2. BigQuery から自動でセグメントリストを生成
dbt: stg_customers → mart_segments ✅
3. Argo Workflows が MA API へ自動連携
CSV アップロード不要 ✅
4. 効果計測の自動集計
dbt: mart_email_kpi_daily
- 開封率・CTR・CVR・GMV を BigQuery で統合
- Looker Studio ダッシュボードで可視化 ✅
# 結果: KPI の因果関係が可視化される
# メール経由 GMV 貢献 = リアルタイムで確認可能
課題サマリー(4点)
1セグメント更新に2日リードタイム — エンジニアがボトルネック。MVP ではここを最優先で解消する。UI からマーケターが直接変更できれば15分に短縮
2月40時間のエンジニア手作業 — CSV 出力・アップロードが繰り返し発生。Argo Workflows + MA API 連携で自動化できる
3効果計測がバラバラのExcel管理 — MA/GA/注文DB が別々で GMV への貢献が測れない。dbt で統合すれば四半期レビューが30分で完了する
4GMV 貢献が不明瞭でROI 判断ができない — 投資対効果が見えないと経営判断の材料にならない。KPI ツリーで可視化することで施策判断の速度が上がる
ヒント(段階的開示)
ヒント1 — 方向性
MVP を「全自動化」にしてはいけない。最初は「最も痛みが大きい1点」を解消する。今回は「セグメント更新の2日リードタイム」がエンジニアとマーケターの最大ボトルネック。まずここを解消するだけで価値が出る。ロードマップは「M1: セグメント自動化 → M2: 配信自動化 → M3: 効果計測統合」の3段階で考えること。
ヒント2 — アプローチ(各成果物の設計方針)
- ロードマップ設計: 各フェーズに「誰が何を得るか」を明記する。技術詳細より「マーケ部長: 施策速度3倍」「事業部長: 工数40h削減」という価値軸を前面に出す
- MVP 定義: ユーザーストーリー形式「〜として、〜したい、なぜなら〜」で書く。受け入れ条件は「テスト可能な形式(✅ ブラウザから15分以内に...)」で記述する
- KPI ツリー: GMV を頂点に「配信数 → 開封率 → CVR → 注文単価」で分解。dbt で
mart_email_kpi_dailyを設計し Looker Studio に繋ぐ - MoSCoW: Must(MVP必須)/ Should(次フェーズ)/ Could(あれば良い)/ Won't(スコープ外)で仕分ける。Won't の合意が最重要
ヒント3 — KPI ツリーと dbt モデルの骨格
【KPI ツリー】
GMV(メール経由)
└─ 配信数 × 開封率 × CTR × CVR × AOV(注文単価)
└─ セグメント精度(オプトアウト率で逆算)
【dbt mart_email_kpi_daily 骨格】
SELECT
campaign_date,
campaign_id,
COUNT(*) AS sent_count,
SAFE_DIVIDE(COUNTIF(is_opened), COUNT(*)) AS open_rate,
SAFE_DIVIDE(COUNTIF(is_clicked), COUNTIF(is_opened)) AS ctor,
SAFE_DIVIDE(COUNTIF(is_purchased), COUNTIF(is_clicked)) AS cvr,
SAFE_DIVIDE(SUM(revenue), COUNTIF(is_purchased)) AS aov
FROM {{ ref('int_email_events') }}
GROUP BY 1, 2
【MoSCoW サンプル】
Must : セグメント UI, BQ→MA API 連携, 基本 KPI 監視
Should: Pub/Sub トリガー配信, Looker Studio ダッシュボード
Could : 件名 A/B テスト
Won't : 多言語対応, SMS 連携
PM の落とし穴(よくある失敗)
| # | 落とし穴 | なぜ問題か | 正しいアプローチ |
|---|---|---|---|
| 1 | MVP を「全部入り」で定義する | 6ヶ月で終わらない → 信頼失墜 → スコープ圧縮で中途半端な物が出来上がる | 最大ボトルネック1点を解消する MVP に絞る(セグメント自動化から) |
| 2 | KPI を「開封率を上げる」と設定する | 開封率が上がっても GMV が伸びなければ意味がない | GMV を頂点にツリーで分解。「どの指標を動かせば GMV が伸びるか」で設計 |
| 3 | Won't を合意せずスタートする | 「SMS も対応して」「多言語も」と要求が際限なく増える | キックオフ時に Won't リストをステークホルダー全員と合意する |
| 4 | ロードマップを技術詳細で説明する | 事業部長には「dbt incremental」が何か伝わらない | 「エンジニア工数40h/月削減」「施策速度3倍」の価値軸で説明する |
プロダクトロードマップ図 — 3フェーズ全体俯瞰(SVG)
模範解答
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Phase 1(Month 0-2): 【セグメント自動化】
目的 : マーケターが自律的にセグメント条件を変更できるようにする
成果物:
- セグメントビルダー UI(Cloud Run + React / FastAPI)
- dbt ステージング: stg_customers, stg_orders → mart_segments
- BigQuery DAY パーティション設計(顧客マスタ)
成功指標:
- エンジニアへのセグメント変更依頼数: 週20件 → 0件
- セグメント更新リードタイム: 2日 → 15分以内
ステークホルダー価値:
- マーケ部長: 「自分で変えられる」= 施策速度 3倍
- 事業部長: エンジニア工数削減 40h/月(= 40万円/月相当)
Phase 2(Month 2-4): 【配信ワークフロー自動化】
目的 : CSV 手動アップロードをゼロにし、スケジュール配信を自動化する
成果物:
- Argo Workflows: BQ セグメントリスト → MA ツール API 自動連携
- Cloud Pub/Sub によるトリガー配信(カート放棄・購入後フォロー)
- DLQ(Dead Letter Queue)でエラーハンドリング + DataDog アラート
成功指標:
- 手動オペレーション工数: 月40h → 8h(80%削減)
- 配信エラー率: < 0.5%
ステークホルダー価値:
- マーケ部長: 週次キャンペーンが "ボタン1つ" で完結
- 事業部長: カート放棄メールで回収率 +X%(計測開始)
Phase 3(Month 4-6): 【効果計測統合・ダッシュボード】
目的 : メール経由 GMV を可視化し、施策の ROI 判断を可能にする
成果物:
- dbt: mart_email_kpi_daily(開封/クリック/CVR/GMV を BQ で統合)
- Looker Studio ダッシュボード(四半期レビュー対応)
- DataDog + OTel でパイプライン全体監視
成功指標:
- メール経由 GMV 可視化: ゼロ → リアルタイム表示
- KPI レビュー準備工数: 半日 → 30分
ステークホルダー価値:
- 事業部長: 「メールへの投資対効果」が数値で見える
- マーケ部長: 施策ごとの CVR 比較でスピード改善判断が可能
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
━━ MVP(Phase 1)— ユーザーストーリー + 受け入れ条件 ━━
【US-01】セグメント作成・保存(Must)
マーケターとして、
エンジニアに頼まずセグメント条件(購入回数・最終購入日・会員ランク等)を
UIから設定・保存したい。
なぜなら、施策実施スピードが現状の1/6(2日→15分)になるから。
受け入れ条件:
✅ ブラウザからセグメント条件を入力 → 保存できる(エンジニア作業不要)
✅ 保存後 15分以内に BigQuery で対象者リストが生成される
✅ 対象者数がプレビューとして UI に表示される(± 5%以内の精度)
✅ dbt test: stg_customers の NOT NULL / unique 制約がパスしていること
✅ セグメント上書き時に旧リストが保全される(Audit log)
【US-02】配信スケジュール設定(Must)
マーケターとして、
セグメントに対して配信スケジュール(日時)を UI から設定したい。
なぜなら、毎回エンジニアにリクエストすると2営業日のロスが発生するから。
受け入れ条件:
✅ スケジュール設定 → 指定日時に自動で MA API へ名簿が送信される
✅ 送信成功/失敗がメールで担当者に通知される(5分以内)
✅ 送信ログが Cloud Logging に 90日保全される
✅ MA API rate limit 超過時はリトライキューに積まれる(DLQ)
【US-03(Should)→ Phase 2】
マーケターとして、
カート放棄後1時間でトリガーメールを自動送信したい。
→ Phase 2 の Pub/Sub トリガー配信で対応(今回スコープ外)
━━ MVP 完了の定義(Definition of Done)━━
1. エンジニアへのセグメント変更依頼がゼロになったことをスラックログで確認
2. 2週間のトライアル期間中、マーケターが週3回以上自律操作していること
3. dbt test が CI でパス(Github Actions)していること
4. 負荷テスト: 1,000セグメント同時保存で 15分以内に完了すること
-- models/mart/mart_email_kpi_daily.sql
-- メールキャンペーン KPI 日次集計
-- Phase 3 で実装。Looker Studio のダッシュボードソースとなる
{{ config(
materialized='incremental',
incremental_strategy='insert_overwrite',
partition_by={
'field': 'campaign_date',
'data_type': 'date',
'granularity': 'day'
},
cluster_by=['campaign_id', 'segment_id']
) }}
{% set LOOKBACK_DAYS = 3 %}
WITH email_events AS (
SELECT *
FROM {{ ref('int_email_events') }}
{% if is_incremental() %}
WHERE campaign_date >= DATE_SUB(CURRENT_DATE(), INTERVAL {{ LOOKBACK_DAYS }} DAY)
{% endif %}
)
SELECT
campaign_date,
campaign_id,
campaign_name,
segment_id,
-- 配信量
COUNT(*) AS sent_count,
COUNTIF(is_opted_out) AS optout_count,
-- エンゲージメント
COUNTIF(is_opened) AS opened_count,
COUNTIF(is_clicked) AS clicked_count,
COUNTIF(is_purchased) AS purchased_count,
-- 売上
COALESCE(SUM(revenue), 0.0) AS total_revenue,
-- レート指標(NULL安全 SAFE_DIVIDE)
SAFE_DIVIDE(COUNTIF(is_opened), COUNT(*)) AS open_rate,
SAFE_DIVIDE(
COUNTIF(is_clicked), NULLIF(COUNTIF(is_opened), 0)
) AS click_to_open_rate, -- CTOR
SAFE_DIVIDE(
COUNTIF(is_purchased), NULLIF(COUNTIF(is_clicked), 0)
) AS cvr,
SAFE_DIVIDE(
COALESCE(SUM(revenue), 0.0),
NULLIF(COUNTIF(is_purchased), 0)
) AS aov, -- Average Order Value
-- オプトアウト率(1.5%超で品質警告)
SAFE_DIVIDE(COUNTIF(is_opted_out), COUNT(*)) AS optout_rate
FROM email_events
GROUP BY 1, 2, 3, 4
-- ━━ Looker Studio ダッシュボード設計 ━━
-- Page 1: 全体サマリ
-- - 時系列チャート: GMV(メール経由)
-- - スコアカード: 開封率 / CTR / CVR / AOV
-- Page 2: キャンペーン比較
-- - 表: campaign_id 別の KPI 一覧
-- - 散布図: CVR vs open_rate(高CVR・低開封率キャンペーンを特定)
-- Page 3: セグメント別分析
-- - ヒートマップ: segment_id × KPI
-- - フィルタ: campaign_date(四半期選択)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【Must — MVP に必須(Phase 1)】
M1: BigQuery 顧客マスタ dbt 整備
stg_customers, stg_orders → mart_segments
担当: DE × 3週間
M2: セグメントビルダー API(Cloud Run / Python FastAPI)
GET /segments / POST /segments / GET /segments/{id}/preview
担当: Backend × 4週間
M3: セグメントビルダー UI(React + Cloud Run)
担当: Frontend × 4週間(API と並行)
M4: Argo Workflows スケジュール実行(BQ → MA API)
担当: Backend × 2週間(Phase 1 終盤)
M5: 基本 KPI 監視(DataDog: エラー率・配信成功率アラート)
担当: Backend × 1週間
【Should — Phase 2 で実装】
S1: Pub/Sub トリガー配信(カート放棄・購入後フォロー)
S2: DLQ(Dead Letter Queue)でエラー自動リトライ
S3: mart_email_kpi_daily(開封・クリック・CVR 統合集計)
S4: Looker Studio ダッシュボード初版
【Could — あれば良い(Phase 3 以降で検討)】
C1: セグメント A/B テスト配信(配信比率分割)
C2: 件名 A/B テスト(送信時に条件分岐)
C3: BigQuery ML で最適送信時間帯予測
【Won't — 今回スコープ外(キックオフ時に全員合意)】
W1: 多言語対応(英語・中国語)
W2: SMS / LINE 連携
W3: AI 件名自動生成(LLM API 利用)
W4: 国際配信(海外 EC 対応)
━━ 注意: Won't はキックオフ時に全ステークホルダーと合意する ━━
合意なしで進めると「あの機能は?」が後から来る。
スコープ外の合意 = PM の最重要タスク。
━━ リスクマトリクス(発生確率 × 影響度 で優先順位付け)━━
【高:即対応】
リスク①: MA ツール API の rate limit で大量配信時に詰まる
発生確率: 高(MA 側 SLA が不明)/ 影響: 大(配信遅延 → 施策失敗)
対策:
- Argo Workflows に rate_limit(1分あたり最大配信数)を設定
- Pub/Sub + Cloud Tasks でキューを分散
- 事前に MA ベンダーに「月40万通の API rate limit」を確認し文書化
リスク②: 個人情報(メールアドレス)の BigQuery 保存コンプライアンス
発生確率: 中(法務確認済みかどうか不明)/ 影響: 極大(法的問題)
対策:
- BigQuery の column-level security(POLICY TAG)で PII 列を制限
- アクセスログを Cloud Audit Log で 90日保全
- 法務・情報セキュリティ部門との事前確認 → 開発開始前に完了
【中:Phase 2 で対応】
リスク③: セグメントビルダー UI をマーケターが使いこなせない
発生確率: 中(変化管理が不十分だと操作率が上がらない)
対策:
- Phase 1 終了後に 2週間のトライアル期間を設ける
- 操作ログを Cloud Logging で収集し、UX 改善サイクルを回す
- マーケターへのオンボーディング動画(5分)を準備
リスク④: dbt モデルの欠損でセグメント精度が下がる(名簿ズレ)
発生確率: 中(ソースデータの品質に依存)
対策:
- dbt test(not_null, unique, relationships)を CI に組み込み
- 失敗時は Argo ワークフローを中断して DLQ 通知
- mart_segments の更新を DataDog カスタムメトリクスで監視
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
ポイント解説
1
MVP は「最大ボトルネック1点」を解消する
「全自動化」を最初の MVP にすると6ヶ月では終わらず、中途半端なものが出来上がる。今回は「セグメント更新2日→15分」という1点に絞ることで、マーケターに2ヶ月で確実に価値を届けられる。MVP の成否は「ユーザーが自律して使えるか」で測定する(KPI: エンジニア依頼件数 週20→0)。
「全自動化」を最初の MVP にすると6ヶ月では終わらず、中途半端なものが出来上がる。今回は「セグメント更新2日→15分」という1点に絞ることで、マーケターに2ヶ月で確実に価値を届けられる。MVP の成否は「ユーザーが自律して使えるか」で測定する(KPI: エンジニア依頼件数 週20→0)。
2
ロードマップはステークホルダー別の価値軸で説明する
エンジニアは「dbt incremental を使う」と書きがちだが、事業部長には伝わらない。「エンジニア工数40h/月削減 = 月40万円相当」「施策速度3倍」という価値軸で伝えることで、経営層の承認を得やすくなる。技術詳細は付録・補足資料に回す。
エンジニアは「dbt incremental を使う」と書きがちだが、事業部長には伝わらない。「エンジニア工数40h/月削減 = 月40万円相当」「施策速度3倍」という価値軸で伝えることで、経営層の承認を得やすくなる。技術詳細は付録・補足資料に回す。
3
KPI は GMV 分解ツリーで設計する
「開封率を20%にする」という KPI だけでは GMV への貢献が見えない。
「開封率を20%にする」という KPI だけでは GMV への貢献が見えない。
GMV = 配信数 × 開封率 × CTR × CVR × AOV とツリーで分解することで、「CTR は良いが CVR が低い = LP 品質の問題」と原因を特定できる。KPI ツリーは施策の因果関係の仮説そのものである。
4
Won't を明示することがスコープ管理の要
「SMS も対応して」「多言語も」という要求は、Won't を合意しないと際限なく増える。キックオフ時に全ステークホルダーと Won't リストの合意を取ることが PM の最重要タスク。合意後に追加要求が来た場合は「フェーズ2以降で検討する」と言える根拠になる。
「SMS も対応して」「多言語も」という要求は、Won't を合意しないと際限なく増える。キックオフ時に全ステークホルダーと Won't リストの合意を取ることが PM の最重要タスク。合意後に追加要求が来た場合は「フェーズ2以降で検討する」と言える根拠になる。
5
リスクは「発生確率 × 影響度」で優先順位を付ける
今回は MA API rate limit と個人情報コンプライアンスが「影響大 × 発生確率高」のため最優先対策。コンプライアンスリスクは「法務確認前にコードを書かない」が鉄則。開発開始前に法務・情報セキュリティ部門の承認を得ることを PM がゲートとして設ける。
今回は MA API rate limit と個人情報コンプライアンスが「影響大 × 発生確率高」のため最優先対策。コンプライアンスリスクは「法務確認前にコードを書かない」が鉄則。開発開始前に法務・情報セキュリティ部門の承認を得ることを PM がゲートとして設ける。
実務への応用
- MOps/販促システムへの直結: このロードマップは現職の「メール配信工数削減」そのもの。Phase 1 のセグメントビルダーを BigQuery + dbt で整備すれば、将来 LINE/SMS にも横展開できる。dbt
mart_segmentsがチャネル横断の共通セグメントレイヤーになる - dbt Mesh 活用:
mart_segmentsとmart_email_kpi_dailyを MOps チームの公開モデルとして定義し、広告・CRM チームがref('mops', 'mart_segments')で cross-project 参照できる設計にしておくと全社データ統合がスムーズ - Argo Workflows のパラメータ化: キャンペーン ID・セグメント ID・送信日時をワークフロー引数にすることで、WorkflowTemplate を1本化し、マーケターが UI から引数を変えるだけで新キャンペーンを起動できる運用になる
- 証券マン経験の活用: 「機会損失を数値化する」思考は証券実務で鍛えた武器。「セグメント更新が2日遅れる = 月次施策を2回失う = 取りこぼし売上 XX万円」と金額換算することで、システム投資の正当性を経営層に説得できる
今日のまとめ
プロダクトロードマップは「全自動化」ではなく「最大ボトルネック1点の解消」から始め、各フェーズをステークホルダーの価値軸(誰が何を得るか)で設計する。
KPI は
KPI は
GMV = 配信数 × 開封率 × CTR × CVR × AOV のツリーで分解して因果関係を設計し、MoSCoW で "Won't" を最初に全員合意することがスコープ管理の核心。Won't の合意なしに進めると「あの機能は?」という要求が際限なく増え、プロジェクトが炎上する。