概要
ICEスコアリング
Impact × Confidence × Ease の3軸で技術課題を数値化。感情ではなくデータで優先度を決める。
ROI計算
期待効果の金銭換算 ÷ 投資工数×月単価。エンジニア月単価100万円で計算すると経営層に伝わる。
BLUF原則
Bottom Line Up Front。結論（推奨課題）を先に示し、理由を後に付ける経営会議向けの構成。
Confidence の重要性
「具体的な数値があるか」で判断の信頼性が変わる。数値あり=5、推定=3、仮説のみ=1。
問題
あなたはECサイト企業のMOpsチームのエンジニアリードです。 PMから来期Q2（7〜9月）のロードマップ検討のために技術的課題をビジネス視点で優先度付けしてほしいと依頼された。
5つの技術課題
| # | 課題 | 概要 |
|---|---|---|
| A | Argo Workflows のジョブ失敗率 | 週次バッチの失敗率12%。手動リカバリーに毎週3時間かかっている |
| B | BigQuery のクエリコスト最適化 | 月$4,200のBQコストのうち推定40%が最適化で削減可能 |
| C | Next.js フロントのリファクタリング | コンポーネント設計が古くテストカバレッジ12%。開発速度への影響が懸念 |
| D | 観測基盤（OpenTelemetry）整備 | 障害検知が遅く平均MTTR45分。改善で15分以下に短縮可能 |
| E | dbt モデルの分割・ドキュメント整備 | 既存dbtモデルが300行超のモノリシックSQL。将来の保守性が懸念 |
制約
- チームのQ2エンジニアリング工数: 2名 × 3ヶ月 ≈ 6人月
- 各課題の実装工数: A=1.5人月, B=0.5人月, C=3人月, D=1人月, E=2人月
- Q2中に全て着手は不可能。2〜3課題を選択する必要がある
タスク: ① スコアリングフレームワークを設計（評価軸3〜4つ）② 5課題にスコアをつけ優先度ランキング作成 ③ PM・経営陣向け1ページサマリーを構造化
ヒント（段階的開示）
ヒント1 — 方向性
技術課題をビジネス視点で評価するとき、エンジニアが陥りやすいのは「技術的負債の大きさ」だけで判断すること。
PMや経営者が聞きたいのは「それでビジネスにいくらの影響があるか」。
Cost（コスト削減）/ Revenue（売上貢献）/ Risk（リスク低減）/ Speed（開発速度） の4軸が典型的。
ヒント2 — ICEスコアリングの計算方法
ICEスコアリング（Impact × Confidence × Ease）:
- Impact: ビジネスへの影響度（コスト・売上・リスク）1〜5
- Confidence: 効果の確信度（データがあるか）1〜5
- Ease: 実装のしやすさ（工数・リスク）1〜5
3つを掛け算すると0〜125のスコアが出る。
ROI簡易計算: 期待効果の金銭換算 ÷ (投資工数 × 月単価@100万円)
ヒント3 — スコアリング表の骨格と1ページサマリー構成
スコアリング表の骨格:
| 課題 | Impact(1-5) | Confidence(1-5) | Ease(1-5) | ICEスコア | 工数 |
|---|---|---|---|---|---|
| A（Argo） | 3 | 5 | 3 | 45 | 1.5人月 |
1ページサマリー構成（BLUF）:
- 現状の課題と財務インパクト
- 推奨優先課題（上位3件）＋ ROI概算
- 今回対応しない課題と理由
- 必要リソースと期待成果・KPI
ICE スコア可視化
模範解答
1. スコアリングフレームワーク（ICE × ROI）
| 評価軸 | 定義 | スコア基準 |
|---|---|---|
| Impact | ビジネスへの定量インパクト（コスト削減・売上・リスク低減） | 5=100万/月以上, 4=50万, 3=20万, 2=10万, 1=定量化困難 |
| Confidence | 効果の確信度（データ・実績の有無） | 5=数値データあり, 3=推定, 1=仮説のみ |
| Ease | 実装難易度（工数・リスク・依存関係） | 5=0.5人月以下, 4=1人月, 3=1.5人月, 2=2人月, 1=3人月以上 |
| ROI概算 | 期待効果金額 ÷ 投資コスト（工数 × @100万） | 参考指標（スコアに含めない） |
2. スコアリング結果
| 課題 | Impact | Confidence | Ease | ICE | 工数 | 年間効果（概算） | ROI |
|---|---|---|---|---|---|---|---|
| B: BQ最適化 | 4 | 5 | 5 | 100 | 0.5人月 | +$20,160/年（40%削減） | 約4倍 |
| D: OTel整備 | 4 | 4 | 4 | 64 | 1人月 | MTTR短縮→障害コスト低減 | 定量難 |
| A: Argo修復 | 3 | 5 | 3 | 45 | 1.5人月 | 手動作業解消=156h/年 | 約1倍 |
| E: dbt整理 | 2 | 3 | 2 | 12 | 2人月 | 将来の開発速度（定量化困難） | 低 |
| C: FE整理 | 2 | 2 | 1 | 4 | 3人月 | 長期的な開発効率（数年スパン） | 非常に低 |
推奨: B + D + A = 合計3人月 → Q2工数6人月の50%で3課題を完遂可能
3. 経営会議用 1ページサマリー
技術投資サマリー Q2 FY2026（7〜9月）
作成: MOpsチーム | 対象: 経営・PM向け意思決定資料
作成: MOpsチーム | 対象: 経営・PM向け意思決定資料
現状の定量課題
- コスト浪費: BigQueryの月額コスト$4,200のうち推定$1,680（40%）が最適化で削減可能
- 運用コスト: Argo Workflowsのバッチ失敗率12%により、週3時間の手動対応が発生（月換算 約13時間）
- 障害対応コスト: 可観測性不足によりMTTR（平均復旧時間）が45分
Q2推奨対応課題（上位3件）
| 優先度 | 課題 | 工数 | 期待効果 | ROI概算 |
|---|---|---|---|---|
| 1位 | BigQuery コスト最適化 | 0.5人月 | $20,160/年削減 | 4倍以上 |
| 2位 | OTel観測基盤整備 | 1人月 | MTTR 45分→15分（67%改善） | 中〜高 |
| 3位 | Argo Workflows安定化 | 1.5人月 | 手動作業156h/年→0h | 約1倍 |
合計工数: 3人月（Q2工数6人月の50%）
Q3以降に先送りする課題と理由
| 課題 | 先送り理由 |
|---|---|
| dbt モデル整理 | 即効性は低く、ビジネスインパクト定量化困難。Q3に計画 |
| Next.js リファクタリング | 工数3人月は重く、短期ROIが薄い。テストカバレッジ改善から段階的に着手 |
Q2成功指標（KPI）
- BQコスト: $4,200 → $2,500/月以下
- バッチ失敗率: 12% → 2%以下
- MTTR: 45分 → 15分以下
ポイント解説
1
ICEスコアリング: 感情とデータの分離
エンジニアが直感で「重要そう」と感じる課題（C: FEリファクタ）と、ビジネスインパクトが高い課題（B: BQコスト）は必ずしも一致しない。 スコアリングにより「感情」と「データ」を分離する。
エンジニアが直感で「重要そう」と感じる課題（C: FEリファクタ）と、ビジネスインパクトが高い課題（B: BQコスト）は必ずしも一致しない。 スコアリングにより「感情」と「データ」を分離する。
2
Confidenceの重要性
課題Bは「月$4,200のうち40%削減可能」という具体的な数値があるためConfidence=5。 数値があると経営者を説得しやすい。 課題Cは「将来の開発速度への影響が懸念」という曖昧表現 → Confidence=2。
課題Bは「月$4,200のうち40%削減可能」という具体的な数値があるためConfidence=5。 数値があると経営者を説得しやすい。 課題Cは「将来の開発速度への影響が懸念」という曖昧表現 → Confidence=2。
3
サマリーの構成原則（BLUF）
結論（推奨3件）を先に示し、理由を後に付ける。 経営会議では時間が限られるため、最初の30秒で意思決定できる構成にする。
結論（推奨3件）を先に示し、理由を後に付ける。 経営会議では時間が限られるため、最初の30秒で意思決定できる構成にする。
実務への応用
- スプリント計画時: 「なぜこの技術的負債を今期解消するのか」をICEスコアで示すと、PM・上長の承認が得やすい。
-
コスト削減系は即効性・数値化がしやすい:
経営層への説明に強い（Confidence高）。BigQueryの
INFORMATION_SCHEMA.JOBS_BY_PROJECTを使うと実際のクエリコストが分析できる。 - DORA Metricsとの連携: MTTRはDORA Metricsの一つ。OTel整備後にMTTRをKPIとして追跡することで、技術投資の効果を継続的に証明できる。
次のステップ
発展問題:
課題Bの「BigQueryコスト最適化」を具体的に実施する（どのクエリを最適化するか？）→ カテゴリCの問題へ
- 参考: Google DORA Metrics（Deployment Frequency, MTTR, Change Failure Rate, Lead Time）
今日のまとめ
技術課題の優先度付けは「技術的負債の大きさ」ではなく「ビジネスインパクト × 実現可能性」で行う。
ICEスコアと簡易ROI計算を組み合わせることで、感情ではなくデータに基づいた意思決定を経営層に提示できる。
スコアリング表 + BLUFサマリーの形式で提案することで、30秒で経営会議の意思決定を引き出せる構成になる。
スコアリング表 + BLUFサマリーの形式で提案することで、30秒で経営会議の意思決定を引き出せる構成になる。