🎬 シナリオ
MOps（Marketing Ops/販促システム）チームは、会員向け「マイページ」（登録情報・注文履歴・会員ランク確認・配送先住所管理を行う画面）の保守を担当している。次の6週間スプリントで着手するスコープを決めるプランニングMTGが来週開催される。
直近3週間で、複数部門からマイページ改修への要望が集中して届いた。
- セキュリティチーム: 外部の脆弱性診断で「パスワード再設定リンクの有効期限が72時間と長すぎ、かつリンクが一度使用されても失効しない」という指摘を受けた。悪用されるとアカウント乗っ取りにつながるリスクがあり、診断報告書には「次回リリースでの是正」が明記されている。
- 法務部門: 個人情報保護法の改正対応で、会員が自分の登録情報の第三者提供状況を確認できる「開示請求ページ」の設置が来四半期の法定対応期限までに必須になった。現状は問い合わせ対応のみで画面が存在しない。
- CS部門: 退会手続きの導線がわかりにくく、月120件前後の「退会方法がわからない」問い合わせが発生している。CS対応工数は月換算で約25時間相当。あわせて、配送先住所を複数登録できない仕様のため、住所変更の問い合わせも月40件ある。
- マーケティング部門: 会員ランク（ブロンズ/シルバー/ゴールド）の到達条件と特典がマイページ上で分かりにくく、ランクアップ促進キャンペーンの効果が薄いという課題感がある。「次のランクまでの進捗バー」を表示したいという要望だが、効果は仮説段階で未検証。
- デザインチーム: マイページ全体のビジュアルデザインが3年前から更新されておらず、リブランディングに合わせた全面刷新を提案しているが、事業インパクトの試算はまだない。
- 物流部門: 配送先住所の登録時に、都道府県と市区町村の入力が自由記述のため表記ゆれが発生し、配送ラベル印字時に手直しが月15件ほど発生している。住所入力を郵便番号API連携の自動補完形式に変更したいという要望。
- 経営層: 次期中期計画で「会員のサブスクリプション（定期購入）会員化」を新規事業として検討中で、マイページに定期購入管理画面を追加したいという構想があるが、事業計画自体がまだ承認前で、具体的な仕様は未確定。
開発体制はエンジニア3名、6週間スプリント。ただし通常の保守・問い合わせ対応に稼働の35%を確保する必要があり、新機能開発に充てられる実工数は概算で42人日と算出されている。
💬
プロダクトオーナー「来週のプランニングMTGで、このバックログをMust/Should/Could/Won'tに分類して持ってきてほしい。全部は無理なのは分かっているので、なぜその分類にしたかも法務・セキュリティ・マーケそれぞれに説明できるようにしておいて」
📝 課題
あなたのタスク: 上記7件の要望を整理し、MoSCoW法（Must/Should/Could/Won't）で分類したバックログ表を作成してください。各要望に概算工数（人日）を見積もった上で、Must+Should の合計が新機能開発の実工数42人日に収まるように分類し、Couldに分類した項目については「残キャパシティに対して、なぜその項目を選び、なぜ別の項目を見送ったか」まで説明してください。
🔍 ヒント（段階的開示）
取り組む前のヒント
- 今回のバックログにはセキュリティ脆弱性と法定対応期限という、性質の異なる2種類の「客観的なMust根拠」が混在している。両方ともMustになりうるが、その理由をそれぞれ言葉にできるか意識する
- Mustの基準を「セキュリティリスクの現実的な悪用可能性」「法定期限の有無」のように具体化すると、マーケ・デザインの「あった方がいい」要望との線引きがしやすい
- Shouldは「定量的な業務インパクト（問い合わせ件数・対応工数）が説明できるもの」を基準にすると、Couldとの線引きがしやすい
- 経営層からの要望（定期購入管理画面）は「声の大きさ」では最上位に見えるが、事業計画が未承認・仕様未確定という状態をどう扱うかが今回の分類の見せ場になる
- Won'tは「やらない」ではなく「今回のスコープには含めない、かつ再提案の条件を明記する」という扱いにする
📚 背景知識・用語解説
MoSCoW法とは、要求・機能を4段階の優先度に分類する手法です。
- Must（必須）: これがないとリリースの意味がない、またはやらないとリスクが顕在化するもの
- Should（重要）: 重要だが、今回のリリースになくても致命的ではないもの。定量的な業務インパクトがあるものが該当しやすい
- Could（あれば良い）: 実施できれば価値があるが、優先度は相対的に低い。キャパシティに余裕がある場合にのみ着手する
- Won't（今回は実施しない）: 今回のスコープには含めないと明示的に決めたもの。将来やらないという意味ではなく、「今回は」という時間軸付きの判断
💡
Mustの根拠は一種類とは限らない: 今回のようにセキュリティ脆弱性（悪用されると実害が出るリスク）と法定対応期限（対応しないと法令違反になるコンプライアンスリスク）は、どちらも客観的な根拠を持つMustですが、性質が異なります。前者は「起きたら困る」というリスクベースの判断、後者は「期限までにやらないと違反になる」という義務ベースの判断です。この違いを理解しておくと、似たような「緊急に見える要望」が来たときに、それが本当にMustの根拠を持つのか、それとも声の大きさだけでMust扱いされようとしているのかを見分けやすくなります。
事業計画未承認の構想の扱い方: 経営層からの要望であっても、仕様が未確定・予算未承認の段階では、今回のスプリントのバックログとして工数を割り当てて分類すること自体が時期尚早です。こうした要望は「Won't（今回は実施しない、計画承認後に改めてスコープ化する）」として扱い、他のWon't項目と区別して理由を明記することが、後々の期待値調整で重要になります。
✅ 模範解答
📄
マイページ改修バックログ — MoSCoW分類（次期6週間スプリント）
バックログ一覧と工数見積もり
| ID | 要望内容 | 起票部門 | 背景・理由 | 概算工数 |
|---|---|---|---|---|
| B1 | パスワード再設定リンクの有効期限短縮・使用後失効 | セキュリティ | 外部脆弱性診断でアカウント乗っ取りリスクを指摘。報告書で次回リリースでの是正が明記 | 5人日 |
| B2 | 個人情報 第三者提供状況の開示請求ページ | 法務 | 個人情報保護法改正対応。来四半期の法定対応期限までに設置が必須 | 10人日 |
| B3 | 退会手続き導線の改善 | CS | 月120件の「退会方法がわからない」問い合わせ。CS対応工数月25時間相当 | 6人日 |
| B4 | 配送先住所の複数登録対応 | CS | 住所変更問い合わせが月40件。1件のみ登録可能な現仕様が原因 | 8人日 |
| B5 | 会員ランクの進捗バー表示 | マーケ | ランクアップ促進の効果仮説はあるが未検証 | 7人日 |
| B6 | マイページ全面ビジュアルリニューアル | デザイン | リブランディングに合わせた提案。事業インパクト試算なし | 15人日 |
| B7 | 住所入力の郵便番号API自動補完化 | 物流 | 表記ゆれによる配送ラベル手直しが月15件発生 | 5人日 |
| B8 | 定期購入（サブスク）管理画面の追加 | 経営層 | 中期計画の新規事業構想。事業計画は未承認、仕様も未確定 | 12人日（概算） |
MoSCoW分類
| 分類 | ID | 要望内容 | 工数 | 分類理由 |
|---|---|---|---|---|
| Must | B1 | パスワード再設定リンクの是正 | 5人日 | 外部診断で悪用可能性が指摘済みのセキュリティリスク。アカウント乗っ取りは実害に直結し、報告書上も次回リリースでの是正が求められている |
| Must | B2 | 開示請求ページの設置 | 10人日 | 法定対応期限がある。期限内に対応しないと法令違反となり、リスクの性質が「起きたら困る」ではなく「期限までにやらないと違反」という義務ベースである点でB1と区別される |
| Should | B3 | 退会導線の改善 | 6人日 | 月120件・月25時間相当というCS対応工数の削減効果が定量的に説明できる |
| Should | B4 | 配送先住所の複数登録対応 | 8人日 | 月40件の問い合わせ削減という定量効果があり、物流部門の要望B7とも関連する基盤機能のため優先度を上げた |
| Should | B7 | 住所入力の自動補完化 | 5人日 | 月15件の配送ラベル手直し工数を削減できる。B4（複数登録対応）と同時に住所まわりを改修する方が手戻りが少ない |
| Could（採用） | B5 | ランクの進捗バー表示 | 7人日 | 残キャパシティ8人日（42−34）に収まり、マーケ部門から明確な要望があるため採用。ただし効果は仮説段階のため、Must/Shouldより優先度は下げた |
| Could（見送り） | B6 | ビジュアル全面リニューアル | 15人日 | 残キャパシティ1人日（8−7）には収まらず、そもそも事業インパクトの試算がない状態で15人日を投じる判断はできない。次回以降、試算とセットで再提案してもらう |
| Won't（今回） | B8 | 定期購入管理画面 | 12人日（概算） | 事業計画自体が未承認・仕様未確定の段階。この状態でスプリントのバックログに工数配分すること自体が時期尚早であり、計画承認・仕様確定後に改めてスコープ化する |
キャパシティ突き合わせ
| 項目 | 工数 |
|---|---|
| Must合計（B1+B2） | 15人日 |
| Should合計（B3+B4+B7） | 19人日 |
| Must+Should合計 | 34人日 |
| 新機能開発の実キャパシティ | 42人日 |
| 残枠 | 8人日 |
| Could採用分（B5） | 7人日 |
| 最終消化予定 | 41人日（キャパシティ内） |
💡 なぜこう作るのか
1
MustをB1（セキュリティ）とB2（法務）の2件に絞ったが、両者の根拠は同じ「客観性」でも性質が異なる点を明記した。B1は「悪用されたら実害が出る」というリスクベース、B2は「期限までにやらないと違反になる」という義務ベースであり、この区別をしておくと、次に似た「緊急案件」が来たときに、それが本当にMustの根拠(リスク or 義務)を持つのかを機械的に問い直せる。
2
B3・B4・B7をShouldに入れたのは、いずれも問い合わせ件数・対応工数という定量的な裏付けがあるため。特にB4とB7は「住所まわり」という同一領域の改修であり、Should同士でも実装の関連性を考慮してセットで扱う判断をした（別々のスプリントに分けると、住所データ構造を二度触ることになり手戻りリスクが増える）。
3
Could候補のB5とB6のうち、工数の小ささではなく「残キャパシティに収まるかどうか」と「事業インパクトの試算があるかどうか」でB5を優先した。B6は工数が大きいことに加え、そもそも試算がない状態で15人日を投じる意思決定はプランニングMTGの場でも説明がつかない。
4
B8（定期購入管理画面）を経営層からの要望であるにも関わらずWon'tにしたのが今回の分類の核心。声の大きさや起票元の役職でMust/Should寄りに引き上げるのではなく、「事業計画が承認されているか」「仕様が確定しているか」という着手可能性の基準で判断した。これにより、経営層に対しても「優先度が低いのではなく、まだスコープ化できる段階にない」という説明ができる。
5
分類の最後にキャパシティ突き合わせ表を作ったのは、プランニングMTGの場で「この分類で本当に工数は収まるか」という質問にその場で答えられるようにするため。
⚠️ よくある失敗パターン
| 失敗パターン | なぜ問題か | 改善策 |
|---|---|---|
| 経営層・上位役職からの要望を無条件でMustに入れる | 起票元の影響力で優先度が決まり、着手可能性や根拠の客観性が無視される | Mustの基準を「リスクの現実的な悪用可能性」または「法定期限の有無」に固定し、起票元の役職では判断しない |
| セキュリティと法務のMustを同じ理由で一括りにする | 両者は性質が異なる（悪用リスク vs 法令違反リスク）ため、対応期限や説明責任の相手が異なることを見落とす | Mustの根拠が「リスクベース」か「義務ベース」かを分けて明記し、それぞれの期限・報告先を管理する |
| 事業計画未承認の構想をバックログに混ぜて工数を見積もる | 仕様が確定していない項目に工数を割り当てても、後で仕様が変わり見積もりが無意味になる | 計画未承認の要望はMoSCoWの土俵に乗せる前段階として扱い、Won't（今回は実施しない、計画承認後に再スコープ化）で明示的に切り分ける |
| Should同士の実装関連性を考慮せずに分類する | 同一領域の改修を別々のスプリントに分けてしまい、データ構造を二度触るなどの手戻りが発生する | 分類後に「実装が近い項目同士」をまとめて優先度を揃えられないか確認する |
🏆 実務での使いどころ
MoSCoW法は、複数部門から性質の異なる要望（セキュリティリスク・法定期限・業務効率・ブランディング・未承認の事業構想）が同時に届く状況で特に効果を発揮します。特に今回のように、経営層からの要望が声の大きさとしては最上位に見えても、着手可能性（事業計画の承認状況・仕様の確定度合い）という基準で判断すると優先度が下がるケースは、実務で頻繁に起こります。エンジニアからPdM/PM方向を目指す場合、「役職の高さ」ではなく「客観的な根拠と着手可能性」で優先順位を説明できることは、あらゆる部門からの信頼を得るうえで重要な武器になります。
🚀 次のステップ
今回はセキュリティ・法務という2種類の異なるMust根拠を扱いましたが、次はテーマ5-2「Value vs Effortマトリクス」で、B5（ランク進捗バー、価値は仮説段階）とB6（ビジュアルリニューアル、価値は未試算）のような「価値の確からしさが異なるCould候補」を、MoSCoWより連続的な2軸でどう配置し直せるか練習してみましょう。