概要
ROI計算
ROI(%) = (年間リターン - 投資額) / 投資額 × 100。保守・楽観シナリオを分けて提示することで信頼性が上がる。
先行 vs 遅行KPI
先行KPIは翌日から計測可能（配信自動化率）。遅行KPIは数ヶ月後に効果測定（クーポン消費率向上）。
6W3H フレームワーク
What/Why/Who/When/Where/Which/How/How much/How many で問題と解決策を構造化。経営層への説明に有効。
エンジニアのROI力
「何を作るか」だけでなく「なぜ作るか（ビジネス価値）」を数字で示せるエンジニアはPM/CTOと対等に議論できる。
問題
PMからSlack: 「来週の経営会議で、このPJのROI（投資対効果）を説明する資料が必要です。エンジニア目線で数字を整理して、KPIと成功指標を提案してもらえますか？」
現状データ
| 項目 | 値 |
|---|---|
| 現行オペレーション | 手動（週1回、CSチームが約8時間/回かけてBigQueryからCSV出力→SaaSにアップロード） |
| 配信対象 | 約20万ユーザー/回 |
| 現在のクーポン消費率 | 12% |
| 類似企業の自動化後の平均クーポン消費率 | 18〜22% |
| 開発工数見積もり | 3人×2ヶ月（エンジニア単価: 100万円/月） |
| CSチームの人件費 | 3,000円/時間 |
| クーポン1枚あたりの粗利貢献 | 平均500円（利用1件あたり） |
制約・前提条件
- 経営会議の聴衆はエンジニアではない（CTO・CFO・事業部長）
- 数字は保守的に見積もること（楽観的な数字は信頼を損なう）
- KPIは「追跡可能なもの」に絞ること（BigQueryで計測できるもの優先）
ヒント（段階的開示）
ヒント1 — 方向性
ROIは「投資額」と「リターン」の2つを計算するだけ。まず「今の損失（コスト）」と「自動化後のゲイン（収益増）」を分けて整理しよう。
ヒント2 — アプローチ
- 投資額 = 開発コスト（工数）
- リターン = ①工数削減コスト + ②クーポン消費率向上による粗利増
- クーポン消費率の改善幅は保守的に見積もると「現行12% → 15%（+3pt）」くらいが妥当
ヒント3 — ROI計算式
ROI(%) = (年間リターン - 投資額) / 投資額 × 100
回収期間(月) = 投資額 / 月次リターン問題整理（6W3H）
| 項目 | 内容 |
|---|---|
| What | クーポン配信の手動オペレーションを自動化する |
| Why | CSの工数削減＋配信精度向上によるクーポン消費率改善→粗利増 |
| Who | CSチーム（受益者）・MOpsエンジニア3名（開発者） |
| When | 2ヶ月で開発、翌月から効果測定開始 |
| Where | BigQuery→Argo Workflows→SaaS配信システム |
| Which | 既存配信SaaS APIを活用（新規SaaS契約なし） |
| How | dbtで対象セグメント抽出→Argo Workflowsで自動配信トリガー |
| How much | 開発コスト600万円、月次リターン約105万円（保守シナリオ） |
| How many | 週1回×20万ユーザーを対象、年間約1,040万ユーザー配信 |
ROI試算
① 投資額
開発コスト = 3人 × 2ヶ月 × 100万円 = 600万円② リターン計算
工数削減（年間）
CSオペレーション削減 = 8時間/回 × 52回/年 × 3,000円/時間
= 1,248,000円 ≒ 約125万円/年クーポン消費率向上による粗利増（保守シナリオ: +3pt）
現行利用数 = 200,000ユーザー × 12% = 24,000件/回
改善後利用数 = 200,000ユーザー × 15% = 30,000件/回
増加分 = 6,000件/回 × 52回/年 = 312,000件/年
粗利増 = 312,000件 × 500円 = 156,000,000円 ≒ 1億5,600万円/年
※楽観シナリオ（+10pt, 消費率22%）では約4億1,600万円/年③ ROI・回収期間（保守シナリオ）
年間リターン = 125万円 + 1億5,600万円 ≒ 1億5,725万円/年
ROI = (1億5,725万円 - 600万円) / 600万円 × 100 ≒ 2,521%
回収期間 = 600万円 / (1億5,725万円 ÷ 12ヶ月) ≒ 0.46ヶ月（約2週間）
開発完了後2週間で投資回収。保守シナリオでも年間ROI約2,521%。
ROI可視化 — 保守 vs 楽観シナリオ比較
KPI提案表
| 種別 | KPI名 | 定義 | 計測方法 | 目標値 |
|---|---|---|---|---|
| 先行KPI | 配信自動化率 | 自動配信回数/全配信回数 | Argo Workflow実行ログ | 100%（移行完了後） |
| 先行KPI | 配信遅延率 | 定刻±30分以内に配信完了した割合 | BigQuery・Workflow完了時刻 | 99%以上 |
| 遅行KPI | クーポン消費率 | 配信数に対する利用数の割合 | BigQuery: fct_orders × coupon_issues | 15%以上（3ヶ月後） |
| 遅行KPI | クーポン起因粗利 | クーポン利用注文の粗利合計 | BigQuery: fct_orders | 月次前年比+5%以上 |
| オペKPI | CSオペ工数 | CSチームの配信作業時間/月 | Jira or スプレッドシート | 0時間（完全自動化） |
ポイント解説
1
保守・楽観シナリオを分けて提示
経営層は「数字が信用できるか」を最も気にする。保守シナリオで十分なROIが出ることを示した上で、楽観シナリオをアップサイドとして添えると説得力が増す。
経営層は「数字が信用できるか」を最も気にする。保守シナリオで十分なROIが出ることを示した上で、楽観シナリオをアップサイドとして添えると説得力が増す。
2
先行KPIと遅行KPIの分離
消費率向上は数ヶ月かかるが、配信自動化率は翌日から計測できる。経営会議の翌月報告では先行KPIで進捗を示し、四半期末に遅行KPIで効果を評価する。
消費率向上は数ヶ月かかるが、配信自動化率は翌日から計測できる。経営会議の翌月報告では先行KPIで進捗を示し、四半期末に遅行KPIで効果を評価する。
3
エンジニアがROI計算できることの価値
「何を作るか」だけでなく「なぜ作るか（ビジネス価値）」を数字で示せるエンジニアはPMやCTOと対等に議論できる。BigQueryでKPIを計測できる仕組みを持つことで、効果検証も自動化できる。
「何を作るか」だけでなく「なぜ作るか（ビジネス価値）」を数字で示せるエンジニアはPMやCTOと対等に議論できる。BigQueryでKPIを計測できる仕組みを持つことで、効果検証も自動化できる。
実務への応用
MOpsチームでの機能改善提案
このROI試算フォーマットはそのまま使える。特に「工数削減コスト」と「コンバージョン率改善による売上増」の2軸は、ほぼ全てのMOps施策に適用可能。BigQueryで計測できるKPIに絞ることで、開発完了後の効果検証も自動化できる。
次のステップ
発展問題: クーポン配信のA/Bテスト設計（コントロール群/介入群の分割方法、統計的有意差の確認方法、BigQueryでのサンプルサイズ計算）
- 参考: 「Lean Analytics」
- 参考: OKR設計の「Measure What Matters（メジャー・ホワット・マターズ）」
今日のまとめ
エンジニアがROI試算とKPI設計を担えると、経営会議でのPJ承認速度が上がる。
保守シナリオで示し、先行KPIで進捗を可視化し、遅行KPIで成果を証明する構造が基本。
「工数削減」＋「コンバージョン率改善による粗利増」の2軸計算はMOps施策の標準フォーマット。
保守シナリオで示し、先行KPIで進捗を可視化し、遅行KPIで成果を証明する構造が基本。
「工数削減」＋「コンバージョン率改善による粗利増」の2軸計算はMOps施策の標準フォーマット。