概要
6W3H フレームワーク
Who/What/When/Where/Why/How/How much/How manyで要件を「抜け漏れなく」整理する。PMとの認識齟齬を防ぐ最強のツール。
KPIは「測定方法まで」設計
「再購買率を上げる」だけでは不十分。誰が・どのSQLで・どのタイミングで計測するかまで決める。
技術リスクのビジネス変換
「レート制限が怖い」ではなく「5万件の配信がキャンペーン期間を超過するリスクがある」と伝える。
Why × Who が起点
「誰のどんな課題を解決するか」から考えることで、機能要件ではなく価値から設計が始まる。
問題
PMから「パーソナライズドクーポン配信機能」の要件定義参加依頼。エンジニアとして3つの観点で回答する。
前提条件
| 項目 | 内容 |
|---|---|
| 技術スタック | Python / GCP / BigQuery / Argo Workflows / DataDog |
| スプリント期間 | 2週間 |
| 同時接続規模 | ピーク時 10万リクエスト/分 |
| メール配信 | 外部SaaS（SendGrid）を利用 |
Q1: 6W3Hで要件を整理（Who/What/When/Where/Why/How/How much/How many）
Q2: KPIを3つ設定（KPI名・定義・目標値・測定方法）
Q3: エンジニアとして優先的に確認すべき技術的リスクを2つ
Q2: KPIを3つ設定（KPI名・定義・目標値・測定方法）
Q3: エンジニアとして優先的に確認すべき技術的リスクを2つ
ヒント（段階的開示）
ヒント1 — 方向性
6W3Hはプロダクト要件を「抜け漏れなく」整理するためのフレームワーク。まず「誰のどんな課題を解決するか（Why × Who）」を起点に考えてください。
ヒント2 — KPI設計のアプローチ
KPIは「ビジネスゴール → 指標 → 目標値」の順に設計します。クーポン機能のビジネスゴールは何か？（購買促進 / LTV向上 / 離脱防止）から逆算してください。
技術リスクを検討するときは：
- スケール: 10万リクエスト/分をどう捌くか
- 整合性: クーポンの重複発行・不正利用を防げるか
- データ品質: パーソナライズの元となるユーザーデータは十分か
ヒント3 — 6W3H骨格の例
Who: 直近30日以内に購入履歴があるが、
過去2週間ログインしていない「離脱気味ユーザー」
Why: 離脱防止と再購買促進。
クーポンで戻ってきたユーザーのLTVが高いという仮説
What: ユーザーの購買履歴・閲覧履歴に基づいた
個別最適化クーポン（5〜20%OFF）
...6W3H フレームワーク構造図
要件定義を漏れなく整理するための8つの観点。
6W3Hは要件の「抜け漏れ」を防ぐチェックリスト。PMとの会話で全項目を埋めることで、スプリント計画の精度が上がる。
模範解答 — Q1: 6W3H 要件整理
| 軸 | 内容 |
|---|---|
| Who | 直近30日以内に購入実績があり、過去14日間でログインしていない「潜在離脱ユーザー」（推定: 全会員の15〜20%） |
| What | 購買履歴・閲覧カテゴリ・購入間隔をもとに、個別最適化されたクーポン（金額・カテゴリ・有効期限）を生成し、メール/プッシュ通知で配信する機能 |
| When | ユーザーの離脱判定から24時間以内に初回配信。その後7日・14日後に未利用のユーザーへリマインド送信 |
| Where | メール（SendGrid）とモバイルプッシュ通知（FCM）。ユーザーの通知設定に応じてチャネルを自動選択 |
| Why | クーポン施策により再購買率が平均23%向上したという過去のA/Bテスト実績がある。LTV下位セグメントのアクティベーションが最優先課題 |
| Who（担当） | バックエンドチーム（配信ロジック・API）+ データチーム（ユーザースコアリング）+ マーケチーム（クーポン条件設定UI） |
| How | BigQueryでユーザースコアを算出 → Argo Workflowsでバッチ処理 → SendGrid/FCMで配信 → DataDogで配信率・開封率をモニタリング |
| How much | 1クーポンあたりのコスト上限: 売上の5%以内。月間クーポン予算: 既存施策の20%増で試験運用 |
| How many | 初期ターゲット: 月間50,000ユーザー。スプリント1で基盤構築、スプリント2でA/Bテスト開始 |
模範解答 — Q2: KPI設計
KPI 1: クーポン起因再購買率
KPI名: クーポン起因再購買率
定義: クーポンを受け取ったユーザーのうち、有効期限内に購入したユーザーの割合 = (クーポン利用購入者数) / (クーポン送付者数) × 100
目標値: 現状のバラマキクーポン施策（8%）から15%へ改善
測定方法: BigQueryにてクーポン発行テーブルと購買テーブルをuser_id + 日付でJOIN
定義: クーポンを受け取ったユーザーのうち、有効期限内に購入したユーザーの割合 = (クーポン利用購入者数) / (クーポン送付者数) × 100
目標値: 現状のバラマキクーポン施策（8%）から15%へ改善
測定方法: BigQueryにてクーポン発行テーブルと購買テーブルをuser_id + 日付でJOIN
KPI 2: 配信チャネル別開封率
KPI名: メール開封率 / プッシュ通知タップ率
定義: 配信したメール/通知のうち開封・タップされた割合
目標値: メール開封率 25%以上（業界平均 20%）、プッシュタップ率 10%以上
測定方法: SendGrid / FCM のイベントデータをDataDogに集約してリアルタイムモニタリング
定義: 配信したメール/通知のうち開封・タップされた割合
目標値: メール開封率 25%以上（業界平均 20%）、プッシュタップ率 10%以上
測定方法: SendGrid / FCM のイベントデータをDataDogに集約してリアルタイムモニタリング
KPI 3: クーポン施策ROI
KPI名: クーポン施策ROI
定義: (クーポン起因の追加売上 - クーポン割引総額) / クーポン割引総額 × 100
目標値: ROI > 300%（割引コストの3倍以上の売上増）
測定方法: BigQuery ML または手動SQL集計でコントロールグループとの比較
定義: (クーポン起因の追加売上 - クーポン割引総額) / クーポン割引総額 × 100
目標値: ROI > 300%（割引コストの3倍以上の売上増）
測定方法: BigQuery ML または手動SQL集計でコントロールグループとの比較
模範解答 — Q3: 技術的リスク
R1
クーポンの重複発行・不正利用
問題: ユーザーが複数デバイスや複数セッションで同時にクーポンを取得・利用しようとした場合、整合性が保てない。
対策: クーポン利用時にBigQuery TransactionsまたはCloud Spannerでアトミックな排他制御を実施。クーポンステータス（発行中/利用済/期限切れ）を1つのソースオブトゥルースで管理する。
R2
大量バッチ処理時のSendGrid APIレート制限
問題: 5万ユーザーへの一括配信でSendGridのAPI制限（デフォルト: 600リクエスト/分）に引っかかる可能性がある。
対策: Argo Workflowsで配信タスクをチャンク分割（例: 1000ユーザー/バッチ × 並列5ジョブ）し、レート制限内に収める。DataDogでAPI応答率・429エラー率を監視する。
ポイント解説
1
6W3Hは「エンジニアの武器」
技術要件だけでなく、ビジネス文脈・予算・規模感まで整理できる。PMとの認識齟齬を防ぐ最強のコミュニケーションツール。
技術要件だけでなく、ビジネス文脈・予算・規模感まで整理できる。PMとの認識齟齬を防ぐ最強のコミュニケーションツール。
2
KPIは「測定方法まで」設計する
「再購買率を上げる」だけでは不十分。誰が・どのSQLで・どのタイミングで計測するかまで決めないと施策の評価ができない。
「再購買率を上げる」だけでは不十分。誰が・どのSQLで・どのタイミングで計測するかまで決めないと施策の評価ができない。
3
技術リスクはビジネスリスクに変換して伝える
「レート制限が怖い」ではなく「5万件の配信が翌日まで完了しない可能性があり、キャンペーン期間を超過するリスクがある」と伝えると意思決定者に刺さる。
「レート制限が怖い」ではなく「5万件の配信が翌日まで完了しない可能性があり、キャンペーン期間を超過するリスクがある」と伝えると意思決定者に刺さる。
実務への応用
MOps/販促システムチームでの活用場面
- PMからの曖昧な要求を「仕様」に変換できる
- スプリント計画で何を先に作るか（技術的負債 vs 新機能）の判断軸になる
- DataDogのダッシュボード設計（上記KPIをアラート化）に直結する
次のステップ
発展問題: 上記機能のデータベーススキーマ設計（クーポンテーブル・ユーザーセグメントテーブル）をERD形式で設計する
- 参考: プロダクトマネジメントのすべて（曽根原春樹ほか著）
- 参考: INSPIRED（マーティ・ケーガン著）
今日のまとめ
要件定義は「6W3H × KPI × 技術リスク」の3点セットで整理することで、エンジニアがビジネス意思決定に参加できる。技術的リスクをビジネスインパクトに変換して伝える習慣がシニアエンジニアへの道を開く。