顧客要望を断れずスコープ膨張する原因｜合意基準・変更管理・見積前提の3点を整える

「顧客の要望を断れず、スコープがどんどん膨らんでいく」「気がついたら、見積時の倍の作業量になっていた」——受託開発PMの定番の悩みです。

これを「PMの顧客対応力不足」「断る勇気がない」と個人の問題にすると、解決しません。スコープ膨張は構造的に発生する現象で、合意基準・変更管理・見積前提の3点を整えることでほとんど防げます。

スコープ膨張は「断る／断らない」の問題ではない

PMがスコープ膨張で苦しむとき、多くの場合「顧客に強く言えない自分が悪い」と感じます。しかし実際には、 「線を引く根拠」がPMの手元にない ことが本当の原因です。

根拠なく「これは追加です」と言っても、顧客は納得しません。納得させるためには、

の3点が、契約段階・キックオフ段階で顧客と握られている必要があります。これが整っていれば、PMは「断る」ではなく「線を引く」だけで済みます。

最も多い原因がこれです。社内見積では「ブラウザはChromeのみ」「データ移行は含まない」「画面修正は3回まで」と前提が立てられていますが、 顧客提示資料にそれが書かれていない ケースが頻発します。

顧客は前提を知らないので、「Safari対応もしてくれますよね」「データ移行もできますよね」と当然のように追加要望を出します。PMはここで「断る」苦境に立たされますが、本来は提案書段階で前提が明示されていれば起きなかった話です。

提案書・見積書に 「本見積に含まれる範囲」「含まれない範囲」「前提条件」 の3セクションを必ず入れます。顧客の押印がある資料に残すことで、後の議論で立ち戻る場所ができます。

「これは追加ですか？」と顧客に聞かれたとき、PMの判断が毎回ブレるのは、合意基準がないからです。

おすすめの合意基準は、次の3項目です。

このような 「3軸で判定する」表 を案件キックオフで顧客と合意し、議事録に残すだけで、追加要望の議論が大幅にスムーズになります。

「追加ですね」と認識が一致しても、その後どう動くか——見積を出すのか、即着手するのか、決裁は誰がするのか——が定義されていないと、結局PMが個別に判断することになります。

最小限の変更管理プロセスは次の通りです。

このプロセスを案件キックオフで顧客と握っておけば、「とりあえずやっておいて」「あとで請求書出して」という曖昧な進め方が防げます。

スコープ膨張を防ぐためには、追加要望を受けた場面でPMが使う 会話の型 を持っておくことも有効です。

「ご要望ありがとうございます。確認ですが、こちらは提案書記載の◯◯機能の範囲ですか、それとも新規の機能追加でしょうか？工数試算をお出ししたうえで、進め方を一緒に整理させてください。」

このパターンには「断る」要素は1つもありません。 要望を受け取り、定義を確認し、試算を約束する という3アクションで構成されています。顧客は「対応してもらえる」と感じつつ、PMは合意基準のフレームに会話を戻せます。

スコープ膨張に強い案件には、共通の特徴があります。

これらは派手な技能ではありません。 キックオフ後の最初の2週間に揃えるだけ で、案件の安定度が劇的に上がります。

スコープ膨張は、PMの「断る勇気」ではなく、組織として「線を引く根拠」を用意することで防げます。合意基準・変更管理・見積前提の3点が整っていれば、PMは断ることに気を遣わずに、整理に集中できます。

スコープ管理を含む案件運営の仕組み化を相談したい場合は、PM育成支援で支援内容を確認してください。組織のスコープ管理力を可視化したい場合は、PM組織健康診断も活用いただけます。