仕様変更で赤字化する案件を防ぐ変更管理の基本｜拒否ではなく合意の仕組み

「仕様変更は受けたくない」と言いたいPMはいても、現実には拒否できる案件はほとんどありません。
変更管理の目的は、変更を断ることではなく、変更による影響を顧客と一緒に判断できる状態を作ることです。

本記事では、変更で赤字化しないための変更管理を、合意の仕組みとして整理します。

なぜ「変更管理が機能しない」のか

変更管理が機能しない案件には、よく似た構造があります。

つまり、変更管理が存在しないのではなく、「依頼を受けて吸収する」が変更管理だと勘違いされている状態です。

変更を受けてから合意するまでを、以下5ステップで運用します。

「やりたいこと」「やりたい理由」「使うシーン」「期待結果」を改めて聞き直します。
ここを飛ばすと、顧客が言っているのとPMが理解したものがズレたまま見積に入ります。

3視点を分けて出すと、顧客側の判断材料が揃います。

「やる／やらない」の二択ではなく、「全部やる／一部だけやる／納期を伸ばして全部やる／他要件を削ってやる」の選択肢を用意します。
判断するのは顧客側であり、PMは選択肢を整える側です。

「いつまでに決めてくれないと反映できないか」を必ず伝えます。判断期限を明示しないと、確認待ちのまま開発側が無理に走り、結局赤字を膨らませます。

メール1通、もしくは変更管理表への記入＋顧客への共有で十分です。
書面化しないと、検収時に「言った言わない」が必ず発生します。

変更管理がPM個人のスキルに依存している会社では、PMが疲弊し、同じ問題が繰り返されます。
変更受付の様式、影響範囲の出し方、選択肢の出し方、文書化のフォーマットを会社として整えてください。PMがやるのは運用であって、設計ではありません。

「変更管理は会社の仕組みになっているか」「PM個人の頑張りに依存していないか」を経営者・開発責任者が点検したい場合、PM組織健康診断を使ってください。
変更管理だけでなく、見積・進捗・赤字検知・育成体制までを含めて、PM個人ではなく会社の運営仕組みとして点検できます。