🎬 シナリオ
あなたはMOps（Marketing Ops/販促システム）チームのエンジニア3年目。3ヶ月前（2026-05-25）にリリースした「AIレコメンドウィジェット」（商品詳細ページ下部に表示する「あなたへのおすすめ」、閲覧履歴・購買履歴を外部レコメンドエンジンAPIに渡してパーソナライズ表示する機能）の、3ヶ月後の効果判定タイミングを迎えている。
リリース時に経営会議で合意した判定基準（Go/Kill基準）
| 基準 | 目標値 |
|---|---|
| A: レコメンドウィジェットのCTR | 3.0%以上 |
| B: レコメンド経由CVRのサイト平均CVR比 | 80%以上 |
| C: 追加インフラ費用（API従量課金＋GPU利用料） | 月150万円以内 |
| 判定ルール | 3基準中2つ以上未達なら「Kill検討」を発動し、経営会議に諮る |
3ヶ月経過時点（2026-08-30）の実績
- CTR実績: 1.8%（目標比60%、未達）
- レコメンド経由CVR: 1.0%、同時期のサイト平均CVRは2.5%のため比率は40%（目標80%に対し大きく未達）
- 追加インフラ費用: 月128万円（唯一の達成基準）
3基準中2つが未達となり、リリース時に合意した「Kill検討」トリガーが発動した。
背景として、次のことも分かっている:
- データ分析チームが直近1ヶ月のログを見たところ、表示自体は正常に行われているが、クリックされた商品のうち「すでに購入済みの商品」が23%、「閲覧履歴はあるが購入意欲のなさそうなカテゴリ」が判別できないまま混在していた
- エンジニアリードマネージャーからは「レコメンドエンジンの精度は学習データ量に強く依存する。うちの購入データ量では、追加チューニングをしても短期間で大きな改善は見込みにくい」という技術的な見解が出ている
- デザイナーからは「表示位置までスクロールが必要で、かつ表示に0.8秒程度のラグがある。UI改善で多少CTRは上がる可能性がある」という指摘がある（ただしCVR比40%という乖離の説明にはならない）
- マーケティング担当は「開発に3ヶ月・約400万円相当の工数を投資した手前、簡単にKillとは言いたくない」と発言しており、正式な場でこの気持ちを表に出してはいないが、周囲はその温度感を感じ取っている
- 来月には別の新機能（配送状況の分かりやすい可視化）向けにエンジニアリソースを再配分する計画があり、今回のKill/継続判断はそのリソース計画にも影響する
今日、チームリーダーから「来週の経営会議で継続するかKillするか判断を求められている。判断材料と、判断後の実行計画まで整理してほしい」と依頼された。
📝 課題
あなたのタスク: 来週の経営会議に向けて、以下4つの成果物を作成してください。
- 指標評価表＋定性インタビュー知見サマリー: 当初のGo/Kill基準と実績を対比し、判定を明確にする。加えて、レコメンドウィジェットを実際にクリックしたことのある会員3名への簡易インタビュー（今週のPdM-リサーチで学んだ「事実ベースで聞く」設計を踏襲）から得られた知見を整理する
- Kill Criteria判定・選択肢比較: 「完全Kill」「縮小継続（対象を絞ってロジック改善に再投資）」「現状維持」の3つの選択肢を比較し、判断を1つ選ぶ。選ばなかった選択肢がなぜ劣後するかも明記する
- リスク登録簿（Kill選択時 vs 継続選択時）: どちらの判断を選んでも発生しうるリスクを洗い出し、対応を整理する
- 撤収WBS＋経営層向けステータスレポート: 選んだ判断を実行に移すための作業パッケージと、経営会議で使う1ページサマリー（Red/Yellow/Green信号）を作る
単に4点をバラバラに作るのではなく、指標評価表の判定結果がKill Criteria判定の根拠として明示的に引用されているか、リスク登録簿で洗い出したリスクへの対応が撤収WBSに反映されているかの整合性を意識してください。また、「開発に3ヶ月・約400万円相当を投資した」という事実そのものが、継続すべき理由にはならないことを踏まえた上で、それでも継続を選ぶ根拠・Killを選ぶ根拠を、感情論ではなくデータで説明してください。
🔍 ヒント（段階的開示）
取り組む前のヒント
- 指標評価表は「3つの基準のうちどれが未達で、どれが達成か」を一覧で見せることが目的。インフラ費用だけ達成している、という事実も隠さず書く（都合の良い基準だけ見せない）
- 定性インタビューは「なぜクリックしなかったのですか」ではなく、実際にクリックした人に「そのときどう思ってクリックしたか」「クリック後どう感じたか」を聞くと、CTRは低くてもCVRが伸びない理由（見当違いなレコメンド）が具体的に見えてくる
- サンクコスト（すでに投資した3ヶ月・400万円）は、継続するかどうかの判断材料に含めてはいけない。これは意思決定理論の基本だが、実務では「もったいない」という感情が判断を歪めやすい。判断根拠から明示的に排除し、その旨も文書に書いておくと会議で説得力が増す
- 「縮小継続」を選ぶ場合は、何にどれだけ追加投資すれば、どの指標がどう改善する見込みなのかを具体的に示さないと、単なる先延ばしになる。エンジニアリードの技術的見解（学習データ量の制約）を無視した楽観的な計画にしない
- 撤収WBSは「コードを消して終わり」ではない。API契約の解約、表示していた枠の代替コンテンツ、マーケ担当への説明、既存ログの扱い（次の施策への学びとして残すか）まで含める
📚 背景知識・用語解説
定量データだけで判断しない理由（PdM-リサーチの復習）: CTR・CVRという定量指標だけでは「なぜ低いのか」は分かりません。表示位置が悪いのか、レコメンドの精度が悪いのか、そもそも認知されていないのかは、指標だけでは区別できません。今回のように「クリックはされているがCVRが伸びない」というパターンは、表示の問題ではなくレコメンドの中身（精度）の問題である可能性を示唆しており、これは実際にクリックした人への簡易インタビューで裏付けを取るべき部分です。定量で「何が起きているか」を掴み、定性で「なぜ起きているか」を掴むという役割分担は、日常のPdM業務でも繰り返し使う型です。
サンクコストとKill判断: すでに投じた費用・工数（サンクコスト）は、それ自体では「今後も投資を続けるべきか」の判断材料になりません。判断すべきは「今後、追加でいくら投資すれば、どれだけのリターンが見込めるか」だけです。「もう3ヶ月・400万円かけたのだから」という理由で継続を選ぶのは典型的なサンクコストの誤りであり、経営会議でこの誤りに陥らないためには、判断材料からサンクコストを明示的に除外して提示する必要があります。
リスク登録簿を「Kill/継続」の両方に作る理由（PM-リスクの復習）: 通常のリスク登録簿は1つの計画に対して作りますが、今回のように意思決定そのものが分岐点になる場面では、どちらの選択をしてもリスクがあることを両方の側で示すことが重要です。「Killにはリスクがないが継続にはリスクがある」という一方的な見せ方をすると、経営層に判断の全体像が伝わらず、後で「Killのリスクは検討したのか」と問われることになります。
撤収作業も通常のWBSと同じ粒度管理が要る（PM-計画の復習）: 「機能を止める」という判断は、コードを止めるだけでなく、外部ベンダーとの契約解除、影響を受ける他部門（マーケ・CS）への説明、代替コンテンツの用意など、複数の作業パッケージに分解できる通常のプロジェクトです。撤収だからといって計画を雑にすると、契約解除の連絡漏れで無駄な費用が発生し続ける、といった二次被害を招きます。
✅ 模範解答
1. 指標評価表＋定性インタビュー知見サマリー
指標評価表（当初のGo/Kill基準との対比）
| 判定基準 | 目標値 | 実績（3ヶ月時点） | 判定 |
|---|---|---|---|
| A: レコメンドウィジェットのCTR | 3.0%以上 | 1.8%（目標比60%） | 未達 |
| B: レコメンド経由CVRのサイト平均CVR比 | 80%以上 | 40%（レコメ経由CVR1.0% ÷ サイト平均CVR2.5%） | 未達 |
| C: 追加インフラ費用 | 月150万円以内 | 月128万円 | 達成 |
| 総合判定 | 3基準中2つ未達 → Kill検討トリガー発動（リリース時合意ルールに基づく） | ||
定性インタビュー知見（実際にクリックした会員3名、1人10分の簡易ヒアリング）
| # | 発言（要約） | 示唆 |
|---|---|---|
| 1 | 「クリックしたら、もう買った消耗品と同じ商品が出てきて、なんだこれと思って戻った」 | 購入済み商品の除外ロジックが機能していない（データ分析チームの指摘した「クリック商品の23%が購入済み」と整合） |
| 2 | 「そもそも表示されていることに気づかず、たまたま指が当たってクリックしてしまった」 | 表示位置・視認性の問題も一部あるが、これはCTRの低さの説明にはなってもCVRの低さの説明にはならない |
| 3 | 「見た瞬間、自分には関係ない商品だなと分かったので、興味本位で開いただけ」 | レコメンドの精度そのものへの不信感。クリック＝興味喚起の成功、ではなく「これは何だろう」という好奇心クリックが混在しており、CTRを額面通りの成功指標として見てはいけない |
2. Kill Criteria判定・選択肢比較
| 選択肢 | 内容 | メリット | デメリット・リスク |
|---|---|---|---|
| A. 完全Kill | ウィジェットを撤去し、表示枠は別用途（人気商品ランキング等）に転用 | インフラ費用（月128万円）の即時削減、エンジニアリソースを来月の配送可視化機能に振り向けられる、投資判断の基準を曲げないという組織的な一貫性を保てる | すでに投資した3ヶ月分の知見・実装資産が活用されないまま終わる、マーケ担当の心情的な反発 |
| B. 縮小継続（対象カテゴリ限定＋ロジック改善に再投資） | 購入済み商品の除外ロジックを追加実装し、まず高単価カテゴリ（家電・美容）のみに対象を絞って再評価 | 定性インタビューで判明した「購入済み商品混入」という具体的な不具合には対処できる | エンジニアリードの見解では学習データ量の制約が根本原因であり、除外ロジックの追加だけではCVR比40%を80%まで引き上げられる保証がない。追加投資（見積もり2週間・エンジニア1名）の効果が不確実なまま先送りするリスクがある |
| C. 現状維持 | このまま継続し、次回四半期まで様子を見る | 追加の意思決定コストがかからない | リリース時に合意した「2/3未達でKill検討」ルールを実質的に無視することになり、次回以降のKPIレビューの合意そのものへの信頼性を損なう。インフラ費用も垂れ流しになる |
判断根拠（サンクコストを除外した上で）: 判断すべきは「これから追加投資する価値があるか」であり、「すでに3ヶ月・400万円かけたか」ではない。この前提に立つと、Bの縮小継続は「除外ロジックの改善」という限定的な対処療法であり、エンジニアリードが指摘する構造的な原因（学習データ量の制約によるレコメンド精度の限界）には届かない可能性が高い。2週間・エンジニア1名という追加投資に対し、CVR比40%を80%まで引き上げられる見込みが立たない以上、期待値の低い追加投資と判断する。Cの現状維持は、リリース時に自分たちで合意した判定ルールを理由なく破ることになり、次の機能でも同様に「基準はあるが守られない」という前例を作ってしまう。
選ばなかった選択肢について: Bの縮小継続は、もし除外ロジックの不具合が唯一の原因であれば有効な選択肢だった。しかし定性インタビューの発言3「見た瞬間、自分には関係ない商品だなと分かった」は、除外ロジックの不具合とは別に、レコメンド精度自体への不信感を示しており、単一の不具合修正では説明がつかない構造的な問題である可能性が高いと判断した。もし今回、定性インタビューで「除外ロジックの不具合以外に不満がない」という結果であれば、Bを選んでいた可能性が高い。
3. リスク登録簿（Kill選択時 vs 継続選択時）
| # | リスク内容 | 確率×影響 | 対応 | オーナー |
|---|---|---|---|---|
| K1 | Kill後、マーケ担当が「投資判断が甘かった」という印象を持ち、次の新規施策提案への協力が得にくくなる | 中×中 | Killの判断根拠（サンクコストを除外した期待値ベースの判断であること）を経営会議前に個別にマーケ担当へ説明し、「今回の失敗」ではなく「合意した基準通りの正常な判断」であることを丁寧に伝える | あなた/リーダー |
| K2 | 撤去した表示枠を代替コンテンツ（人気商品ランキング等）に転用する際、新たな実装工数が発生し来月の配送可視化機能のリソース計画を圧迫する | 中×低 | 代替コンテンツは新規実装せず、既存の「よく一緒に購入されている商品」枠を暫定的に流用することで追加工数をほぼゼロに抑える | エンジニア |
| K3 | レコメンドエンジンAPIの契約解除手続きが漏れ、機能を止めた後も課金が継続する | 低×中 | 撤収WBSにベンダー契約解除の連絡タスクを明示的に含め、解除完了の請求書確認まで担当者を割り当てる | あなた |
| C1 （継続を選んだ場合） | 追加投資（2週間・エンジニア1名）をしても指標が改善せず、次回判定でも同じKill検討が発生し、判断の先送りだったと後から評価される | 中×高 | （今回は継続を選ばないため対応不要。参考情報として記録） | ― |
| C2 （継続を選んだ場合） | インフラ費用（月128万円）が改善の見込みが立たないまま積み上がり続ける | 高×中 | （今回は継続を選ばないため対応不要。参考情報として記録） | ― |
4. 撤収WBS＋経営層向けステータスレポート
撤収WBS（実行期間: 2週間、移行期間を設けて段階的に停止）
| コード | 作業パッケージ | 見積もり | 担当 | 備考 |
|---|---|---|---|---|
| S.1 | 経営会議での判断承認取得 | ― | あなた/リーダー | 全作業の前提。承認前に本格着手はしない |
| S.2 | マーケ担当への個別説明（K1への対応） | 0.5日 | あなた | 経営会議の前に実施し、会議の場で初めて聞く形にしない |
| S.3 | 表示枠を既存の「よく一緒に購入されている商品」枠へ切替（K2への対応） | 1日 | エンジニア | 新規実装を避け既存機能を流用 |
| S.4 | レコメンドウィジェット本体の表示を段階的に停止（一部トラフィックのみ先行停止し、異常検知がないか確認後に全停止） | 2日 | エンジニア | 一斉停止による想定外の影響を避けるための段階的ロールアウトの逆手順 |
| S.5 | レコメンドエンジンAPIベンダーとの契約解除連絡・最終請求確認（K3への対応） | 0.5日＋確認待ち | あなた | 解除完了の請求書を確認するまでクローズしない |
| S.6 | 3ヶ月分のクリックログ・インタビュー知見をドキュメント化し、次期レコメンド機能検討時の学びとして保管 | 1日 | あなた/データ分析チーム | 「除外ロジックの不具合」「精度への不信感」という知見は次回企画時の要件に直接反映できる形で残す |
| S.7 | CS部門への周知（会員から「おすすめ機能が消えた」という問い合わせが来た場合の一次回答準備） | 0.5日 | あなた/CS | 大きな問い合わせ増加は見込みにくいが念のため準備 |
合計: 約5.5人日（2週間の実働に対し十分な余裕があり、経営会議の承認タイミング次第で前後する）
経営層向けステータスレポート（1ページサマリー）
| 信号 | 🔴 Red（Kill判断・撤収実行フェーズへ移行） |
|---|---|
| 結論 | AIレコメンドウィジェットは、リリース時合意の判定基準（3基準中2つ以上未達でKill検討）に基づき撤収する |
| 判定根拠 | CTR 1.8%（目標3.0%未達）、レコメ経由CVR比40%（目標80%未達）、インフラ費用は唯一達成（月128万円） |
| 定性的な裏付け | 実クリックユーザー3名への簡易インタビューで、購入済み商品の混入・レコメンド精度への不信感を確認 |
| 判断で除外した要素 | すでに投資した3ヶ月・約400万円相当の工数（サンクコストのため判断材料に含めない） |
| 検討した代替案 | 縮小継続（対象を絞った再投資）は、根本原因が学習データ量の構造的制約である可能性が高く、追加投資の期待値が低いため見送り |
| 実行計画 | 2週間で段階的に撤収（S.1〜S.7）。表示枠は既存機能へ切替、追加実装コストはほぼゼロ |
| 次のアクション | 経営会議での承認後、マーケ担当への個別説明を経て撤収着手。3ヶ月分の知見は次期レコメンド機能検討の材料として保管 |
💡 なぜこう作るのか
⚠️ よくある失敗パターン
| 失敗パターン | なぜ問題か | 改善策 |
|---|---|---|
| 「すでに3ヶ月・400万円かけたから」という理由で継続を選ぶ | サンクコストの誤り。今後の追加投資に対するリターンの見込みという、本来判断すべき論点から外れる | 判断材料から過去の投資額を明示的に除外し、「これから投資する価値があるか」だけで判断する |
| 定量指標（CTR/CVR）が悪いことだけを理由にKillを即決し、なぜ悪いのかの裏付けを取らない | UI改善で直る問題なのか、機能自体の価値がないのかを区別できず、撤収後に「実はUIの問題だった」と分かっても手遅れになる | 実際に利用したユーザーへの簡易インタビューで、定量指標の裏にある原因を確認してから判断する |
| Killのリスクだけを検討し、継続した場合のリスクを比較対象として示さない | 経営層から「継続した場合のリスクは検討したのか」と聞かれた際に答えられず、判断の網羅性を疑われる | 選ばなかった選択肢のリスクも登録簿に残し、比較可能な形で提示する |
| 撤収を「コードを止めるだけ」で終わらせ、ベンダー契約解除やステークホルダーへの説明を後回しにする | 契約解除漏れによる無駄な課金の継続、関係部門からの不意打ち感による信頼低下を招く | 撤収も通常のプロジェクトと同じくWBSで作業パッケージに分解し、契約・周知・ドキュメント化まで含める |
🏆 実務での使いどころ
指標が悪化した機能のKill判断は、新機能のローンチや炎上プロジェクトのリカバリー以上に、担当者の心理的抵抗が大きい局面です。「自分（たち）が作った機能を止める」という判断には、サンクコストの誤りだけでなく、チーム内の人間関係（マーケ担当の心情など）への配慮も絡みます。エンジニアからテックリード・PdMへのキャリアパスでは、こうした場面で感情論を判断材料から意識的に排除し、定量・定性の両面から根拠を積み上げて説明できるかが信頼を左右します。特に「事前に合意した基準に基づいて判断している」という一貫性は、次にまた新しい機能をリリースする際の投資判断そのものへの信頼にもつながります。撤収作業自体も、リリース作業と同じ丁寧さ（段階的な実行、関係者への周知、ドキュメント化）が求められる点は見落とされがちです。
🚀 次のステップ
来週も引き続き各カテゴリを曜日ごとに深掘りしていきます。次回の統合回（来週日曜）では、今回・前々回（炎上プロジェクトの立て直し）・前々々回（新機能ローンチ90日計画）とは異なる切り口として、複数プロジェクト間でのリソース競合の調整（例: 限られたエンジニアリソースを、優先度が拮抗する2つの案件にどう配分するか、PMOやEM視点での判断）を扱う想定です。今回学んだ「サンクコストを判断材料から除外する」という考え方は、複数案件のリソース配分判断でも同様に重要な視点になります。