Day 057 — PdM-優先順位: Value vs Effort マトリクス（3回目）

2026-10-15 (Thu) 🟢 Junior PdM-優先順位（優先順位付け・意思決定） 成果物: Value の内訳表 ＋ 依存と期日を入れた配置図・実施順 ＋ 26人日の投入案と説明メモ

🎬 シナリオ

MOps チームの「クーポン基盤」担当は、ブラックフライデー（11/27〜12/1）前の最後の開発期間に何を積むかを決めている。今日は 10/15（木）。開発期間は 10/19〜11/19、11/20〜1/6 は年末商戦のリリース凍結。

体制: PdM 小野さん、リード 村上さん（30%）、バックエンド あなた・青木さん、SRE 西田さん（相談のみ）。関係者: マーケ 高田さん、CS 吉川さん、情報セキュリティ 石井さん、アプリチーム 大野さん。

💬
小野さんが 10件を Value vs Effort に並べた。Value ＝ 6か月で増える粗利。エンジニアの出した保守系6件はすべて 0 円で左下に落ち、案は「A・C・I・J の 21人日、+456万円」になった。
青木さん「G のバッチは BF の朝に止まったら売上に直撃します。B を先にやれば A も C も安くなる。保守が全部 0 円なのはおかしい」
小野さん「おかしいなら同じ軸に載せてください。気持ちではなく、比べられる形で」

候補10件（出所の記載が無い数値はすべて「仮定（演習の設定）」）

ID案出した人Effort小野さんの Value事実・メモ
A会員ランク別クーポンマーケ8180最初の利用は 2/10 の会員感謝祭
Bクーポン併用ルールの作り直し（if の塊 → ルール表）エンジニア60施策ごとにエンジニアがコード修正（月5回 × 0.6人日）。過剰割引が過去12か月に2件（平均45万）
CBF 用「2点目半額」クーポン型マーケ6150B の後なら 3人日。11/19 までに出ないと価値 0
D決済ページのマーケタグ棚卸しと改ざん検知情報セキュリティ50PCI DSS v4.0.1 要件 6.4.3／11.6.1。12/15 の年次準拠報告までに必要
Eクーポン API の Node.js 20 → 24 更新エンジニア70Node.js 20 は 2026-04-30 でサポート終了済み。F の後なら 4人日
F旧クーポン API v1 の廃止エンジニア30呼ぶのはアプリ旧版だけ（3%）。保守 0.5人日/月
Gクーポン発行バッチの高速化エンジニア50通常 40万枚で 3時間10分、枠 01:00〜05:00。BF 初日は 90万枚。遅れると 06:00 の BF 告知メールが止まる
Hflaky test の修正エンジニア30CI が 18% で偶発失敗、再実行に 1.2人日/月
I販促効果ダッシュボードマーケ6120（幅 0〜240）根拠は「判断が速くなる」
Jポイント二重付与の修正CS10月3件、CS 対応と補填
共通の設定値
キャパ（10/19〜11/19）実キャパ 33人日、予備 20% を引いた計画上限 26人日
凍結明け（1/12〜2/5）約 12人日
人件費の換算1人日 ＝ 6万円
BF 初日の粗利2,000万円。朝のメールが止まると 20% ＝ 400万円を失う
アプリのリリース11/5（申請締切 10/28）、次は 12/10

📝 課題

あなたのタスク: リード村上さんの代わりに、明日の計画会に出す3点を作ってください。数字を作りすぎないこと。

  1. Value の内訳表: 10件の Value を「稼ぐ／守る／浮かす／義務」に分けて書き直す。出所ラベル（実測／導出／仮定）と幅を付ける
  2. 依存と期日を入れた配置図と実施順: 他の案を安くする関係（解放）と、価値が消える期日を書き込み、象限だけでは決まらない順序を出す
  3. 26人日の投入案と小野さんへの説明メモ: 小野さんの案と比較し、見送る案には拾い直す条件を付ける

🔍 ヒント（段階的開示）

ヒント1
保守作業の Value は「売上が増える」では書けない。「やらないと何が起きるか（確率 × 損失）」か「毎月の手間がいくら減るか」で書く
ヒント2
B が A・C を安くする分を B の Value に足し、さらに A・C の Effort も下げると二重に数える
ヒント3
C と G は 11/19 を過ぎると価値 0。E は「いつかは必ずやる」作業で、問題はいつやるか
ヒント4
D を「確率 × 損失」で金額にすると根拠の無い数字になる。マトリクスに置く前に取り分けるべき物はないか
ヒント5
F は単独では小さいが、E の前提。F の中に他チームの締切に縛られる部分は無いか

📚 背景知識・用語解説

📖
なぜ保守は左下に落ちるか: Value を「増える粗利」だけで測ると、事故が起きない・手間が減る・次の開発が速くなる、という効果は 0 円になる。案が悪いのではなく、ものさしが片側しか無い。Day050 の「ものさしの違い」が、営業側と技術側の間で起きている。

Value を4つに分ける

種類何を数えるか計算の形今回の例
稼ぐ増える粗利件数 × 粗利A・C・I
守る避けられる損失の期待値確率 × 起きたときの損失G・J・E
浮かす減る手作業人日 × 換算単価B・H・F
義務法令・契約・規格で決まっている金額にしない（期日だけ）D
解放他の案の Effort を下げる依存先の Effort を下げて一度だけ数えるB→A・C、F→E
📘
トイル（浮かすの根拠）: Google SRE Book は、トイルを「手作業・繰り返し・自動化可能・その場しのぎ・長く残る価値が無い・サービスの成長に比例して増える」作業と定義し、SRE の時間の 50% 未満に抑える目標を掲げる（Eliminating Toil、WebFetch で確認、参照日 2026-10-15）。浮いた人日は別の仕事に使って初めて価値になる。1人日＝6万円は機会費用としての仮定。

負債の利息と元本: Martin Fowler は、汚れた設計のせいで新機能に余計にかかる手間を利息、設計を直す作業を元本の返済にたとえ、似た機能が続くなら先に直したほうが早くなると書く（TechnicalDebt、WebFetch で確認、参照日 2026-10-15）。B と A・C の関係がこれ。

遅延コスト: SAFe の WSJF は遅延コスト ÷ 仕事の長さで順番を決め、入力に「利用者・事業の価値」「時間の制約」「リスク低減・機会の解放」を挙げる（WSJF、公開部分のみ確認、参照日 2026-10-15）。今回は考え方だけ借り、金額のまま使う（相対点数の WSJF はテーマ#5 以降）。
📅
外部の事実（参照日 2026-10-15）
・Node.js（nodejs/Release）: 20.x は 2026-04-30 で EOL。22.x はメンテナンス LTS で 2027-04-30 まで。24.x はアクティブ LTS、2026-10-20 にメンテナンスへ、2028-04-30 まで。22 に上げると半年後にまた上げるので更新先は 24。
・PCI DSS v4.x 要件 6.4.3／11.6.1（PCI SSC ブログ）: 決済ページのスクリプトの承認・完全性の確認・改ざん監視を求める e スキミング対策。必須化の日付（2025-03-31 と記憶）はこのページに無く未照合。マーケのタグは決済ページにも載りやすく、MOps が持ち主になりやすい。

✅ 模範解答

答えを見る前に、自分の内訳表と実施順を作ってから読み比べてください。

0. Value の種類クイズ（主な種類を1つ選ぶ）

案手がかりあなたの判定
A ランク別クーポンゴールド会員の購入が増える
B 併用ルール施策ごとのコード修正が消える
C 2点目半額BF の売上
D 決済ページのタグ年次準拠報告に必要
E Node.js 更新いつかは必ずやる
F v1 廃止E の前提
G バッチ高速化BF の朝のメール
H flaky test再実行の手間
I ダッシュボード判断が速くなる
J ポイント二重付与CS の対応と補填

1. Value の内訳表（6か月・万円）

ID稼ぐ守る浮かす義務合計幅計算と出所
A180———18090〜270+30万/月 × 6（マーケ試算＝仮定）
B—45108—153110〜20018人日 × 6万（実績から導出）＋ 過剰割引 期待1件 × 45万（導出）。解放は足さない
C150———15080〜200BF 5日間（仮定）。11/19 以降 0
D———12/15義務—金額にしない。固定レーン
E—50——5020〜150確率 0.5 × 割増 100万（+5人日 30万 ＋ BF 中の障害期待 70万。仮定）
F——18—18—0.5人日/月 × 6 × 6万（導出）。E を −3人日
G—280——280100〜540確率 0.7 × 400万（仮定）。11/19 以降 0
H——43—43—7.2人日 × 6万（実績から導出）
I120———1200〜240道筋の無い見込み（根拠の弱い仮定）
J—6——6—月3件 × 約3,300円 × 6（導出）
🧮
0 円だった6件のうち、G（280）と B（153）は A（180）・C（150）と同じ大きさになった。E・F・H・J は小さいまま。保守がすべて重要なわけではないことも、同じ表で見える。

2. 依存と期日を入れた配置図

閾値は Value 100万円（6か月）、Effort 5人日。左が小野さん（稼ぐだけ）、右が書き直し後（依存先は前提作業の後の Effort、点線矢印＝解放）。

小野さんの配置（Value＝稼ぐのみ）

書き直し後（稼ぐ＋守る＋浮かす）

緑＝クイックウィン、橙＝大きな賭け、青＝埋め草、赤＝金食い虫。◆＝期日 11/19。D は右図では象限の外（固定レーン）。

前提を動かす（右図と内訳が変わる）

F を割る: 依存の連鎖の先頭にある外部の締切

F1 告知依頼 0.5人日
締切 10/28→ アプリ 11/5 リリース→ 旧版の呼び出し 0.3% 未満（12月）→ F2 v1 削除 2.5人日（1/12〜）→ E Node 24 更新 4人日

F1 が 10/28 に間に合わないと、次のアプリは 12/10 → F2 は 2月 → E は 2月末以降。0.5人日・Value ほぼ 0 の F1 が、この期間でいちばん先に手を付ける作業になる。象限ではなく、連鎖の中で最も動かせない日付が順序を決める。

実施順

1
F1 告知・強制アップデート依頼（0.5）— 10/28 の外部締切
2
G0 90万枚の本番相当テスト（0.5）— 確率 0.7 は仮定。先に測ると G の幅が消える。余裕で終わるなら G を止める
3
D 決済ページのタグ（5）— 固定レーン。棚卸しに高田さんの協力が要るので早めに
4
G バッチ高速化（4.5）— 期日 11/19、Value 最大
5
B 併用ルール（6）→ 6 C 2点目半額（3）— B の後で C を 3人日に
7
H flaky test（3）・J 二重付与（1）、予備 2.5（G が悲観値 7人日になった場合）

3. 投入案の試算（今期 10/19〜11/19、計画上限 26人日）

Value は上の前提スライダーの値を使う。G は G0 なしでも同じ期待値で数えるが、警告を出す。

比較

小野さんの案書き直した案
今期A 8・C 6・I 6・J 1 ＝ 21人日F1 0.5・G0 0.5・D 5・G 4.5・B 6・C 3・H 3・J 1 ＝ 23.5（＋予備 2.5）
凍結明け未定A 5・F2 2.5・E 4 ＝ 11.5
6か月の Value稼ぐ 456万今期 632万（G 280・B 153・C 150・H 43・J 6）＋ D。凍結明けで A 180・E 50・F 18
残るリスクG の期待損失 280万、D が 12/15 に間に合わないE は 1月まで露出（撤退ラインあり）

小野さんへの説明メモ（計画会で読み上げる1枚）

  1. 保守6件を「守る（確率 × 損失）」「浮かす（人日 × 6万）」で金額にした。G と B は A・C と同じ大きさ、E・F・H・J は小さいまま
  2. D は金額にせず固定レーン。12/15 の準拠報告に必要で、やらない選択肢が無い
  3. C と G は 11/19 を過ぎると 0。A は最初の利用が 2/10 なので凍結明けで間に合い、B の後なら 5人日
  4. G の 280万は確率 0.7 の仮定。最初の 0.5人日で 90万枚を流し、余裕で終わるなら G を止めて A を前倒しする
  5. 見送り: I。拾い直す条件は「マーケの集計作業時間を2週間測り、月 10人日以上なら」
  6. 撤退ライン（E）: 凍結中に Node.js 20 の深刻度 High 以上の脆弱性が公表されたら、凍結例外で E を前倒し（割増 100万は見込み済み）

💡 なぜこう作るのか

  • 合計を出しつつ内訳と幅を残した: 合計1本だと「G の 280 は確率 0.7 の仮定」という弱さが消える。計画会で突かれるのはそこ
  • 解放を Value に足さなかった: B に「A・C −6人日＝36万」を足し、A・C の Effort も下げると二重計上。依存先の Effort で一度だけ数えた
  • D を金額にしなかった: 「e スキミングの確率 × 被害額」は根拠が無く、結論（やる）も変わらない
  • G0 を先頭近くに置いた: Value 最大の G は大半が仮定の確率に乗っている。0.5人日で確率がほぼ 0 か 1 に決まるなら、情報の価値が計測の費用を上回る
  • F を割った: 「他チームの締切に縛られる 0.5人日」と「いつでもよい 2.5人日」が混ざると、F 全体が埋め草として後回しになり、先頭の 0.5人日も遅れる
  • Node.js 24 にした: 22 は 2027-04-30 で終わる。22 に上げると 15か月後に同じ規模の作業がまた来る

⚖️ 迷った他案と採らなかった理由

案採らなかった理由判断が変わる条件
毎スプリント 20% を負債返済に固定どの負債をやるかが決まらず、G・D の期日を 20% の中で逃しうる負債の多くが期日の無い小粒（H・J 型）のとき
保守を別ボードで管理A と G を比べられず、「保守は 0 円」の見え方が変わらない保守と機能の予算が別部署から出ているとき
WSJF を相対点数で付けるテーマ#5 以降の範囲。粗利の試算が既にあり、金額のほうが小野さんの表とつながる金額の試算が全く無いとき
解放を Value に足すA・C の Effort も下げているので二重計上依存先の Effort を下げない扱いに統一するとき
D を確率 × 損失で金額化根拠が無く、結論も変わらない準拠範囲外と分かり、任意の対策として比べるとき
E を今期にやる（7人日）F2 前で高く、BF 直前に実行環境を変えることになる凍結前に重大な脆弱性が公表されたとき

⚠️ よくある失敗パターン

失敗パターンなぜ問題か改善策
Value を売上だけで付ける保守が全部 0 円になり、重要な物も沈む守る・浮かす・義務の列を足す
保守を全部重要だと主張する小さい物も混ざっていて説得力を失う同じ表に載せ、小さい物は小さいと認める
解放を Value と Effort の両方に入れる依存元の価値が過大になる依存先の Effort で一度だけ数える
期日のある案を象限だけで並べる11/19 で価値 0 になる案が後回しになる期日の列を書き、先に置く
連鎖の先頭の小さな作業を埋め草扱いF1 が遅れて E まで1か月ずれる案を割り、外部の締切に縛られる部分を先に出す
仮定の確率で大きな Value を出し、測らずに積むG が不要だった場合 5人日が無駄安い計測（G0）を先に置く

🏢 実務での使いどころ

  • 局面: PdM の優先順位に「保守が入っていない」と言いたいとき。言い争いでなく、同じ表に載せて比べる。四半期計画、年末商戦前の最終スプリント、EOL が近い部品が見つかったとき
  • 隣接する役割: PdM は稼ぐの列、エンジニアは守る・浮かすの列、情報セキュリティ・法務は義務の列と期日、SRE は確率の根拠（障害履歴・実行時間の推移）を持つ。経営層には「保守を入れて、稼ぐはいくら減り、守るはいくら増えたか」を1行で
  • 個人開発への転用: 依存ライブラリの EOL・CI の不安定さ・手作業の運用を「月に何時間失っているか」「止まったら何が起きるか」で書き、新機能と同じ一覧に並べる。列は「ID／稼ぐ／守る／浮かす／義務／合計／幅／計算と出所／依存／期日」

➡️ 次のステップ

  • テーマ5-3「ロードマップ」で Now（F1・G0・D・G・B・C・H・J）／Next（A・F2・E、条件: F1 が 11/5 に載ったこと）／Later（I、条件: 集計時間の実測）に並べる
  • 問い: G0 の結果、90万枚で 3時間50分だった。G を止めるか。BF 当日の件数が見込みより 10% 多い場合も考える
  • 問い: 高田さんが「A を 12月のクリスマスに使いたい」と言い出した。A の期日が 12/1 になると、順序と 26人日はどう組み直すか

🚧 扱わなかった範囲・検証していない点

  • 数値はほぼすべて演習の仮定（G の確率 0.7・損失 400万、E の確率 0.5・割増 100万、A・C・I の粗利）。幅は「中央 ± 置いた幅」で統計的な区間ではない
  • 1人日＝6万円は機会費用の仮定。浮いた時間が使われなければ 0
  • PCI DSS 6.4.3／11.6.1 は PCI SSC ブログで目的のみ確認。規格本文・必須化日・SAQ の種類による適用差・日本のクレジットカード・セキュリティガイドラインとの関係は未照合
  • SAFe WSJF は公開部分のみ。Reinertsen『The Principles of Product Development Flow』は未照合
  • 依存は B→A・C、F1→F2→E の3本のみ。H が他作業を少しずつ速くする効果は数えていない
  • 始めた後に止める基準（Kill Criteria）はテーマ5-11 の範囲

🎯 自己評価

自分の回答

所要時間・気づき・メモ