スコープ管理とMVP
やることとやらないことを線引きするスコープ管理と、最小限の価値を検証するMVPの考え方を学ぶ
スコープクリープとは
プロジェクトが進むにつれて、当初の合意になかった要望が少しずつ追加され、 気づけば期限内に収まらない量の作業を抱えてしまう現象をスコープクリープと呼びます。 1つ1つの追加は小さく見えても、積み重なると計画全体を崩す原因になります。
ポイント
スコープの追加要望自体が悪いわけではありません。問題は、影響範囲やトレードオフを 合意しないまま「なんとなく」取り込んでしまうことにあります。
MVP（実用最小限の製品）
MVP（Minimum Viable Product）は、 検証したい仮説に対して、必要最小限の機能で価値を届け、実際のユーザーからの学びを得るための 製品の作り方です。「安っぽく作る」ことが目的ではなく、 「何を検証したいか」を明確にした上でスコープを絞り込むことが本質です。
よくある誤解
- ❌ MVP = 品質を落として速く作ること
- ❌ MVP = 将来使わない機能を削っただけの縮小版
- ❌ MVPをリリースしたら検証せずそのまま終わり
本来の考え方
- ✅ 検証したい仮説を明確にした上で必要最小限を定義する
- ✅ リリース後に実際の利用データやフィードバックを集めて学ぶ
- ✅ 学びをもとに次のイテレーションのスコープを決める
MoSCoWによる優先順位付け
限られた期限の中でスコープを決める際、要望を4段階に分類するMoSCoW法がよく使われます。
Must have（必須）
これがないとリリースする意味がない、絶対に必要な要件
Should have（重要）
重要だが、なくてもリリース自体は可能な要件
Could have（あれば良い）
余裕があれば対応する、優先度の低い要件
Won't have（今回は対象外）
今回のスコープには含めないと明示的に合意した要件
特に重要なのは「Won't have」を明示することです。 「やらないこと」を関係者と合意しておくことで、後から「やるはずだった」という 認識齟齬を防げます。
スコープ変更を管理するプロセス
スコープの変更要望自体を禁止するのではなく、変更を受け入れる際のプロセスを 決めておくことで、計画への影響を可視化しながら合意形成できます。
変更要望を受け取ったときの確認事項:
1. この変更はどのビジネス価値・課題に紐づくか
2. 既存のMust have要件と比べた優先度はどうか
3. 追加することで、期限・予算・他の要件にどのような影響が出るか
4. 何かを取り除く（トレードオフ）か、期限を延ばすか、追加予算をとるか
→ 上記を関係者に共有し、合意を得てからスコープに反映するポイント
- • スコープクリープは、影響範囲を合意しないまま要望を積み重ねることで起きる
- • MVPは「安く作る」ことではなく「仮説検証に必要な最小限」を届けること
- • MoSCoW法（Must/Should/Could/Won't）で優先順位を関係者と合意する
- • 「やらないこと（Won't have）」を明示することが認識齟齬の予防になる
- • スコープ変更は禁止するのではなく、影響を可視化して合意するプロセスを整える
確認クイズ
1 / 3スコープクリープの説明として最も適切なものはどれか？