スコープネゴシエーション

英語名 Scope Negotiation
読み方 スコープ ネゴシエーション
難易度
所要時間 1〜3時間(交渉セッション1回あたり)
提唱者 プロジェクトマネジメント全般 / PMBOK
目次

ひとことで言うと
#

ステークホルダーの要望とプロジェクトの制約(時間・コスト・品質)を突き合わせ、何を入れて何を外すかを合理的に合意する交渉プロセス。「全部やります」ではなく「この条件ならここまでできます」を提示する技術。

押さえておきたい用語
#

押さえておきたい用語
スコープ(Scope)
プロジェクトで実現する成果物と作業の範囲。何を作るか・何を作らないかの境界線を定義する。
MoSCoW法
要件を Must / Should / Could / Won’t の4段階に分類する優先順位づけ手法。スコープ交渉の材料として使う。
トレードオフスライダー
スコープ・時間・コスト・品質の4つの制約をスライダー形式で可視化し、何を優先するかをステークホルダーと合意するツール。
チェンジリクエスト(Change Request)
スコープ変更を正式に申請する文書。影響範囲・追加コスト・スケジュール変更を明記する。

スコープネゴシエーションの全体像
#

スコープネゴシエーション:要望と制約を突き合わせて合意点を見つける
ステークホルダーの要望機能A, B, C, D, E, F...「全部必要」「優先順位はない」→ 要望は常に制約を超えるプロジェクトの制約時間 / コスト / チーム規模リソースには上限がある→ 全部はできない現実突合ギャップが発生 → 交渉が必要MoSCoW法で優先順位をつけるMustA, BShouldCCouldD, EWon'tFMust + Should を基本スコープにスコープ合意A, B, C を確定。D, E は次フェーズ。F は見送り── 「全部やる」ではなく「ここまでやる」を合意する ──
スコープネゴシエーションの進め方フロー
1
要望の全量把握
ステークホルダーの要望をすべて洗い出しリスト化する
2
制約の明示
時間・コスト・品質の制約を数字で可視化する
3
優先順位づけ
MoSCoW法で要件をMust/Should/Could/Won'tに分類する
スコープ合意・文書化
合意したスコープを文書にし、変更管理プロセスを設定する

こんな悩みに効く
#

  • 顧客が「全部やってほしい」と言うが、リソースが足りない
  • 追加要件が次々に来て、当初のスケジュールが守れない
  • 「No」と言うと関係が悪化しそうで断れない

基本の使い方
#

要望を全量リスト化する
ステークホルダーの要望をすべて書き出す。この段階では「できる・できない」の判断は入れず、漏れなく拾うことを優先する。各要望に対して「それが実現されると何が得られるか(ビジネス価値)」を1行で併記する。
制約を数字で可視化する
使える時間・予算・人員を具体的な数字で示す。「エンジニア3名 × 3か月 = 約60人日」のように、抽象的な制約を定量化する。これにより「全部やると 120人日 必要だが、使えるのは 60人日」というギャップが可視化される。
MoSCoW法で優先順位をつける
ステークホルダーと一緒に各要件をMust(なければリリースできない)/ Should(強く望む)/ Could(あれば嬉しい)/ Won’t(今回は見送り)に分類する。Must + Should が使えるリソースの 80%以内 に収まるように調整する。
合意を文書化し変更管理を設定する
合意したスコープを文書にまとめ、双方が署名する。以降の追加要件はチェンジリクエストとして正式に申請し、影響(コスト増・期間延長・他の要件の削除)を評価した上で判断するルールを設ける。

具体例
#

例1:Web制作会社がクライアントの追加要望を交渉する

従業員15名のWeb制作会社。中堅不動産会社のサイトリニューアル(予算 350万円、納期3か月)を受注。初回ヒアリングで要望が 28件 出た。

見積もりの結果、28件を全てやると 650万円・5か月 かかることが判明。PMが制約を数字で示し、MoSCoW法でクライアントと分類した。

分類件数代表例工数
Must8件物件検索、レスポンシブ対応180万円
Should6件お気に入り機能、MAP連携120万円
Could7件チャット、VR内覧200万円
Won’t7件AI査定、多言語対応150万円

Must + Should = 300万円 で予算内に収まり、残り 50万円 をバッファとして確保。クライアントからは「最初は全部必要だと思っていたが、分類したら本当に必要なのは半分以下だった」とのフィードバック。3か月で予定通りリリースできた。

例2:社内IT部門が基幹システム移行のスコープを経営層と合意する

従業員800名のメーカー。老朽化した基幹システムの移行プロジェクト(当初予算 1.2億円、期間18か月)。経営層から「移行ついでに業務改革もやりたい」と追加要望が 15件 出た。

IT部門のPMがトレードオフスライダーで可視化した結果。

  • 全要望を入れた場合:予算 2.3億円、期間 30か月
  • 移行のみ(Must):予算 8,000万円、期間 12か月
  • 移行 + 業務改善の一部(Must + Should):予算 1.2億円、期間 18か月

経営層との交渉で「まず移行を確実に完了させ、業務改革は第2フェーズで」という合意が成立。Could / Won’t に分類された要件は第2フェーズの候補リストとして保管。第1フェーズは予定通り18か月で完了し、移行に伴うトラブルは 3件(想定の半分以下)に抑えられた。

例3:NPOが助成金事業のスコープを助成元と再交渉する

職員8名のNPO。子どもの居場所づくり事業(助成金 300万円、期間1年)を実施中、半年経過時点で「対象地域を隣接2市にも広げてほしい」と助成元から要望が出た。

現状の稼働率はすでに 90%。PMが影響を試算した。

  • 地域拡大した場合:追加コスト 180万円、スタッフ2名増が必要
  • 現行地域を維持した場合:予定通り完了可能

助成元との交渉で、「現行地域の活動を深掘りし、そのノウハウを隣接市に展開するマニュアルを成果物に加える」という代替案を提示。追加コストは 40万円 で収まり、助成元も「横展開できる方が長期的な価値が高い」と合意した。マニュアルは翌年度に隣接3市で活用されている。

やりがちな失敗パターン
#

パターン何が起きるか対策
「全部やります」と安請け合いするリソース不足で品質低下・納期遅延が発生する制約を数字で可視化し、トレードオフを早期に提示する
交渉なしでスコープを削るステークホルダーが「聞いていない」と不信感を持つ必ず対面で理由を説明し、代替案を提示する
Won’tを曖昧にする「後でやる」が既成事実化し、再び要求されるWon’tは「今回やらない」と明記し、文書に残す
口頭合意で済ませる後から「言った言わない」の争いになる合意事項は必ず文書化し、双方が確認した記録を残す

まとめ
#

スコープネゴシエーションは、ステークホルダーの要望とプロジェクトの制約を突き合わせ、何を入れて何を外すかを合理的に合意するプロセス。MoSCoW法で優先順位をつけ、制約を数字で可視化し、代替案を用意して交渉に臨む。「全部やる」と言わない勇気と、「ここまでならできます」という提案力がプロジェクトの成功を左右する。