概要
4点セットで返す
「できる/できない」ではなく「スコープ・リスク・代替案・推奨」の4点セットで返すのがエンジニアリングリードの役割。
KPIを先に確認
PMの依頼には「何を作るか」は書いてあっても「何で測るか」が不明なことが多い。KPI不明のまま実装するとゴールポストが動く。
トレードオフを明示
「A/B/Cの選択肢があり、各コスト・工数・品質はXX」という形にするとPMが意思決定しやすい。
意思決定の期限を作る
「月曜日に確認」という期限を設定することで、制約のある中での意思決定を迅速化する。
問題
依頼メール（抜粋）:
「来月のセールキャンペーン向けに、購買履歴に基づくパーソナライズレコメンド機能を実装したい。 ユーザーの直近の購買データ（過去30日）をもとにレコメンドを表示する。 開発工数は2週間（エンジニア2名）で何とかなりますか？」
「来月のセールキャンペーン向けに、購買履歴に基づくパーソナライズレコメンド機能を実装したい。 ユーザーの直近の購買データ（過去30日）をもとにレコメンドを表示する。 開発工数は2週間（エンジニア2名）で何とかなりますか？」
あなたが把握している情報
| 項目 | 状況 |
|---|---|
| セールまでの期間 | 残り3週間 |
| P1バグ対応 | 決済フローのバグ修正（顧客クレームあり）必須 |
| その他バックログ | ダッシュボードKPI改善（P2）、CI/CDリファクタリング（P3） |
| レコメンドエンジン基盤 | まだない（データはBigQueryにある） |
| MLチーム | 別部署で今月は他のプロジェクトで多忙 |
| チーム体制 | エンジニア2名（うち1名はフロントエンドが弱い） |
制約
- 顧客影響のある P1 バグは必ず今月中に対応しなければならない
- 外部MLサービスの利用は検討可（費用は月額 $500〜$5,000 の範囲で許容）
タスク: PMへの返答を含む要件定義・スコープ整理・リスク提示・代替案の提案を行え。
ヒント（段階的開示）
ヒント1 — エンジニアリングリードの役割
PMの依頼をそのまま「できます/できません」で答えない。
スコープ・リスク・代替案 の3点セットで返すのがエンジニアリングリードの役割。
ヒント2 — 4W分析と返答の骨格
- What: 何を作るか（スコープの明確化）
- Why: なぜ今か（KPIは？ビジネスインパクトは？）
- Risk: 何が足りていないか（基盤なし・ML知識・工数）
- Alternative: 代替案は何か（既存SaaS, ルールベース, 次サイクル対応）
ヒント3 — 返答スケッチ
[PMへの返答スケッチ]
まず確認させてください:
1. このレコメンドのKPIは何ですか？
（クリック率？CVR？売上増？）
2. 2週間で「何が動けばセールに間に合う」ですか？
（MVP定義）
現状の課題:
- P1バグ対応が先行します（〜XX日）
- レコメンドエンジン基盤ゼロスタート
→ 2週間でのフルスクラッチは困難
提案:
1. 即戦力オプション: [外部SaaS or BigQueryベースのルールベース]
2. 次サイクルオプション: MLチームと連携した本格対応
トレードオフ:
- Option A: 工数5〜7日、精度△、$500〜$2,000/月
- Option B: 工数3〜5日、精度△、$10〜$50/月
- Option C: セールに間に合わないが中長期資産意思決定フロー図 — 3つの選択肢のトレードオフ
模範解答（PMへの返答メール/Slack）
Hi [PM名],
ありがとうございます。確認した上で現状と提案をまとめます。
ありがとうございます。確認した上で現状と提案をまとめます。
まず2点確認させてください
- このレコメンド機能の成功指標（KPI） はどれを優先しますか？
（例: 商品クリック率 / カート追加率 / セール期間のCVR向上） - セール当日に最低限「動いている状態」として何が必要ですか？
（全ユーザー？特定セグメント？ABテスト対象のみ？）
現状の懸念点
| 項目 | 状況 |
|---|---|
| P1バグ対応 | 今月中に必須。1名がこれにかかる |
| レコメンド基盤 | 現在ゼロ。BigQueryにデータはあるが、配信基盤・APIともに未整備 |
| ML依存 | 協業依頼する場合、MLチームは今月多忙 |
| FE担当 | 2名のうち1名はFE弱め。表示UI実装にリスク |
2週間・2名・基盤ゼロでの「パーソナライズMLレコメンド」フルスクラッチは、品質を担保した形では困難と判断しています。
3つの代替案
Option A: 外部レコメンドSaaS（セールに間に合う）
| 項目 | 内容 |
|---|---|
| 概要 | Algolia Recommend や Google Retail AI などのSaaSを利用し、BigQueryデータを連携 |
| 工数 | 約5〜7営業日（API連携 + UI実装） |
| 費用 | 月額 $500〜$2,000 程度（リクエスト数次第） |
| 精度 | ルールベース〜協調フィルタリングレベル |
| リスク | ベンダーロックイン。データ移行に制約が生じる可能性 |
Option B: BigQuery + ルールベースレコメンド（最速・低コスト・推奨）
| 項目 | 内容 |
|---|---|
| 概要 | 「同じカテゴリの人気商品」「過去閲覧したが未購入の商品」などBigQueryのSQL集計でルールを定義し、APIエンドポイントを立てる |
| 工数 | 3〜5営業日 |
| 費用 | BigQueryクエリコストのみ（月 $10〜$50 程度） |
| 精度 | 個人化はなく、セグメント別の準パーソナライズ |
| メリット | 社内に資産が残る。MLレコメンドへの移行が後でしやすい |
Option C: 次サイクルで本格対応（セール見送り）
| 項目 | 内容 |
|---|---|
| 概要 | 今月はP1対応と基盤設計に集中。来月MLチームと連携し本格実装 |
| 工数 | 来月3〜4週間 |
| ビジネスインパクト | 今回のセールでの効果なし |
私の推奨:
「セールに間に合わせる」かつ「低リスク」という観点では Option B（ルールベース） が最適です。 SQLで集計できる範囲でのパーソナライズは即日〜1週間で実現でき、セール後にMLレコメンドへ段階的に移行できます。
「精度と将来性」を重視するなら Option A（SaaS） も現実的です。
今週中にKPIと最低要件を確認の上、月曜日に方針を決めましょう。いかがでしょうか？
「セールに間に合わせる」かつ「低リスク」という観点では Option B（ルールベース） が最適です。 SQLで集計できる範囲でのパーソナライズは即日〜1週間で実現でき、セール後にMLレコメンドへ段階的に移行できます。
「精度と将来性」を重視するなら Option A（SaaS） も現実的です。
今週中にKPIと最低要件を確認の上、月曜日に方針を決めましょう。いかがでしょうか？
ポイント解説
1
KPIを先に確認する
PMの依頼には「何を作るか」は書いてあっても「何で測るか」が不明なことが多い。 KPI不明のまま実装するとゴールポストが動く。 「クリック率向上なのか、CVR向上なのか、セール売上増なのか」を明確にすることで 実装スコープが決まる。
PMの依頼には「何を作るか」は書いてあっても「何で測るか」が不明なことが多い。 KPI不明のまま実装するとゴールポストが動く。 「クリック率向上なのか、CVR向上なのか、セール売上増なのか」を明確にすることで 実装スコープが決まる。
2
代替案は必ず複数 + トレードオフ明示
「できません」ではなく「A/B/Cの選択肢があり、各コスト・工数・品質はXX」という形にすると、 PMが意思決定しやすい。スコープ・コスト・期間の3軸でトレードオフを示す。
「できません」ではなく「A/B/Cの選択肢があり、各コスト・工数・品質はXX」という形にすると、 PMが意思決定しやすい。スコープ・コスト・期間の3軸でトレードオフを示す。
3
工数の見積もりには「基盤なし」を明示
「2週間あればできる」という前提を崩す情報（基盤ゼロ・P1バグ先行）は最初に伝える。 後からスコープ漏れが発覚すると信頼を失う。
「2週間あればできる」という前提を崩す情報（基盤ゼロ・P1バグ先行）は最初に伝える。 後からスコープ漏れが発覚すると信頼を失う。
4
「推奨」を言い切る
エンジニアが「PMが決めること」と逃げると信頼されない。 リスクを理解した上で「私はOption Bを推奨します」と言い切るのがエンジニアリングリードの仕事。
エンジニアが「PMが決めること」と逃げると信頼されない。 リスクを理解した上で「私はOption Bを推奨します」と言い切るのがエンジニアリングリードの仕事。
5
意思決定の期限を作る
"来月のセールまで3週間" という制約がある中で「月曜日に確認」という期限を設定することで、 意思決定を迅速化する。期限を設けないと検討が長引き、実装時間が減る。
"来月のセールまで3週間" という制約がある中で「月曜日に確認」という期限を設定することで、 意思決定を迅速化する。期限を設けないと検討が長引き、実装時間が減る。
実務への応用
- 常時SOPを持つ: ルールベースレコメンドのSQLテンプレートを事前整備しておくと、次回から3日で対応可能。
- PM-Eng定例でバックログ共有: P1バグをPMが把握していないと優先度交渉ができない。週次定例でバックログを可視化する。
- BigQueryの既存データ資産を整理: どのテーブルに何があるかを常にドキュメント化しておくと、新機能の工数見積もりが速くなる。
-
Option B のSQL例:
過去30日の購買履歴から、ユーザーごとの推奨カテゴリTop3を返すSQLを 発展問題として設計する（次のステップ参照）。
次のステップ
発展問題:
PMから「Option B でいきます」と回答が来た。
BigQuery で「過去30日の購買履歴から、ユーザーごとの推奨カテゴリTop3を返すSQL」を設計せよ
- 参考:
Product Management in Practice（実践PdM） - 参考: 「エンジニアのためのプロダクトマネジメント」
今日のまとめ
エンジニアリングリードの要件整理は「できる/できない」でなく
「スコープ・リスク・代替案 + 推奨」の4点セットで返すことで、
PMとの信頼関係とプロジェクトの健全性が保たれる。
KPIの確認・基盤なしの明示・複数代替案のトレードオフ提示・意思決定期限の設定が、 エンジニアリングリードとして価値を発揮するための実践スキル。
KPIの確認・基盤なしの明示・複数代替案のトレードオフ提示・意思決定期限の設定が、 エンジニアリングリードとして価値を発揮するための実践スキル。