MoSCoW法でスコープ交渉：Won'tリストを使ったクライアント説得テンプレート

「これも追加してほしい」という要求が積み重なり、プロジェクトのスコープが膨れ上がる——スコープクリープはあらゆるプロジェクトで発生する。MoSCoW法はこの問題に対処するための優れたフレームワークだが、本当の価値は「Won’t（やらないこと）の合意を取る交渉ツール」として使うことにある。

MoSCoW法の基本

MoSCoW法は要件を4つのカテゴリに分類する手法だ。

Must have（必須）： なければプロジェクトが成立しない要件
Should have（重要）： あると価値が高いが、なくても機能する要件
Could have（あれば良い）： あると便利だが、優先度は低い要件
Won’t have（今回はやらない）： 今回のスコープには含めない要件

多くの場面でMoSCoW法は「Must/Shouldに集中しましょう」という優先順位付けツールとして使われる。しかし、PMにとって最も重要なのは「Won’tリストへの合意」だ。

Won’tリストの価値：「やらないことへの明示的な合意」

Won’tリストが持つ本質的な価値は、「言葉にせず暗黙に放置すると後でスコープクリープになる要件を、明示的に『今回は対象外』と合意する」ことだ。

プロジェクト開始時に「これはやりません」という合意を取っておかないと、クライアントは「言わなかったけど当然含まれていると思っていた」という状態で期待値を持ち続ける。そして終盤で「え、これも入ってないんですか？」という事態が起きる。

Won’tリストを使ったクライアント説得テンプレート

メールテンプレート（プロジェクト開始時）：

件名：[プロジェクト名] スコープ確認と合意事項のご連絡

[クライアント名]様

今回のプロジェクトを確実に成功させるため、
スコープの明確化について合意を取らせてください。

以下の「今回対象外の機能一覧（Won't list）」について、
ご確認のうえ、ご同意をいただけますでしょうか。

■ 今回対象外の機能（Won't list）
1. [機能名A] — 理由：工数・予算の制約から優先度の高い機能に集中するため
2. [機能名B] — 理由：次フェーズでの実装を推奨するため
3. [機能名C] — 理由：現行の要件定義で合意済みのスコープ外のため

■ これらの機能は今回対象外ですが、
  次フェーズ以降での実装を優先的に検討する候補として記録いたします。

ご確認のほど、よろしくお願いいたします。

口頭での説明トーク（キックオフ時）：

「今回のプロジェクトを確実に期限内・予算内で完了させるため、
今回対象外にすることを明確にしておきたい機能があります。

これは『永遠にやらない』ということではなく、
『今回のスコープでは含めない』という合意です。

今回対象外にすることで、確実に価値の高い機能に集中できます。
対象外の機能は次フェーズの優先候補として記録します。

この認識で合っていますか？」

プロジェクト中盤の追加要求への対処

プロジェクト途中で「これも追加してほしい」という要求が来た場合、MoSCoW法を使って整理する。

対処フロー：

追加要求をWon’tリストと照合する
- Won’tリストに入っていたものなら：「開始時に対象外と合意いただいた件ですね」と確認
- 新規要求なら：次のステップへ
新規要求のMoSCoW分類を提案する
- Must：スコープ変更として正式な変更管理プロセスで対応
- Should/Could：次フェーズ候補として記録
追加する場合のコスト・スケジュール影響を提示する
- 「この機能を追加する場合、[X日]の延期または[Y万円]の追加費用が発生します」

書籍紹介

Rescue the Problem Project

著者: Todd C. Williams — 炎上プロジェクト立て直しに特化した英語書籍

詳細を見る

MoSCoWを機能させるためのコツ

要件をWon’tに入れることを「拒絶」ではなく「延期」として伝える： 「やりません」ではなく「今回はスコープ外ですが、次フェーズで優先的に検討します」という言葉遣いが、クライアントとの関係を壊さずにスコープをコントロールする鍵だ。

Won’tリストはドキュメントに残す： 口頭だけの合意は「言った言わない」問題を生む。メールや議事録にWon’tリストを明記して、クライアントのサインオフをもらう。

Must havestの数を全体の50%以下に保つ： Mustが多すぎるプロジェクトは事実上「全部やる」と変わらない。Mustは「これがなければリリースできない」という絶対条件のみに絞る。

まとめ

MoSCoW法の本来の価値は優先順位付けよりも「Won’tへの明示的合意によるスコープ防衛」にある。プロジェクト開始時にこの合意を取る習慣をつけるだけで、終盤のスコープ交渉のストレスが大幅に軽減される。