仕様がブレるチームへ──要件を守るための変更要求の型

最初に決めたはずの仕様が、いつの間にか変わっている。
「それも入れてほしい」「ついでにこれも」「やっぱり優先度を上げたい」
気づけばスコープが膨らみ、納期が伸び、品質が落ち、現場は疲弊する。

こういうとき、現場はよく二択で揺れる。

• 受けると燃える

• 断ると揉める

でも本当は、受けるか断るかの前に、型に落として扱うべきだ。
仕様がブレるのは、人が気まぐれだからではなく、変更要求を処理する仕組みがないから起きる。

今日は、要件を守るための変更要求（Change Request / CR）の型を、PM運用としてまとめる。
要件定義の精神論ではなく、日々の「ついで」を炎上にしないための実装手順だ。

1. 仕様ブレの正体は、変更が悪いのではなく評価がないこと

まず前提。変更は悪ではない。
現場に出れば学びが増えるし、顧客の理解も進む。むしろ、最初から一切変わらないほうが危険なこともある。

問題は、変更が「意思決定」ではなく「会話の流れ」で入り込むこと。

• チャットで言われたから

• 会議で盛り上がったから

• 偉い人が言ったから

• なんとなく必要そうだから

この入れ方だと、影響評価が抜ける。
影響評価が抜けると、スコープだけが増える。
スコープだけ増えると、最後に現場が払う。

だから必要なのは、変更要求を評価して決める、という運用の固定化だ。

2. 変更要求は「要望」ではなく「取引」だと定義する

ここがPMの腹落ちポイント。
変更要求は「お願い」ではない。リソースを動かす以上、取引になる。

• 追加するなら、何かを減らす

• 早めるなら、何かを捨てる

• 品質を上げるなら、コストか納期が動く

これを言い切れないPMは燃える。
逆に言い切れるPMは、揉めずに守れる。

取引というと冷たく見えるが、実際は公平なだけだ。
現場の負担を、見えないところで増やさないためのルール。

3. 変更要求の受付フォームは、最低限これでいい

変更要求を型にする第一歩は、受付のテンプレを決めること。
重いツールは不要。最初はSlackのフォームでもスプレッドシートでもいい。

項目は最低限で十分。僕の推奨は8つ。

1. 変更内容（何を変えるか）

2. 変更理由（なぜ必要か。背景）

3. 期待効果（何が良くなるか）

4. 期限（いつまでに必要か。理由付き）

5. 影響範囲（画面・機能・運用・契約など）

6. 優先度（高・中・低＋根拠）

7. 代替案（現行のままならどうするか）

8. 申請者と決定者（誰が言って誰が決めるか）

ポイントは、期限に理由を付けること。
「早く」は無限に要求できる。理由がない期限は、ただの希望だ。

4. 変更要求を評価する3つの質問

受付したら、評価する。
評価は難しく見えるけど、質問を固定すると迷いが減る。

質問1：今やらないと何が起きるか

やらないリスクを言語化する。
リスクが弱いなら、後回しにできる。

質問2：やると何が壊れるか

納期、コスト、品質、運用、チーム負荷。
何が確実に増えるかを、具体にする。

質問3：何をやめれば成立するか

ここで取引を成立させる。
追加するなら、何を減らすか。優先順位の再設計をする。

この3つが揃うと、変更要求は感情ではなく意思決定になる。

5. 変更要求の処理フロー（決める順番）

実務で回るフローは、この5ステップで十分。

1. 受付（テンプレで情報を揃える）

2. 影響評価（工数・リスク・依存関係）

3. 代替案作成（最小実装、段階リリース等）

4. 決定（採用／延期／却下／条件付き採用）

5. 反映（バックログ・仕様・スケジュールに反映し、関係者に通知）

重要なのは、4)決定の前に必ず3)代替案を作ること。
二択にすると揉める。代替案があると合意しやすい。

6. 「条件付き採用」が現場を救う

変更要求は、採用か却下だけだと角が立つ。
おすすめは条件付き採用という第三の選択肢。

条件付き採用の例：

• 今回は最小範囲で入れる（スコープを削る）

• 次リリースで入れる（期限をずらす）

• Aが承認されたら入れる（前提条件）

• 既存のBを削るなら入れる（トレードオフ）

条件付き採用は、相手の目的を尊重しつつ、現場の現実も守れる。
PMが持つべき技だ。

7. 変更要求が多いチームに必要なのは「未確定」と「決定」の分離

変更要求が多い現場は、そもそも最初の要件が未確定のまま走っていることがある。
だから変更要求が増える。学びが増えるというより、前提が揺れているだけ。

ここで効くのが、未確定と決定の分離。

• 未確定：検討中。仮置き。後で変わる前提

• 決定：変えるならCRが必要

この線引きを明示しないと、何でも会話で変わる。
線を引くと、変えるときだけ運用に乗る。炎上が減る。

まとめ：要件を守るのは、変更を止めることではなく変更を運用に乗せること

仕様ブレは、変更が多いから起きるのではない。
変更が評価されず、会話の流れで入り込むから起きる。

• 変更要求は取引だと定義する

• 受付テンプレで情報を揃える

• 3つの質問で評価する（やらないリスク／やる影響／何をやめるか）

• 決める順番を固定する

• 条件付き採用で揉めずに守る

• 未確定と決定を分離する

最後に問いを置く。
いま進めている案件で、会話の流れで入りそうな変更は何で、それをCRとして扱うなら「何をやめれば成立する」だろう？

次に読む：

はじめての方へ：

マガジンの紹介：

IT業界の「技術×キャリア×整える」を束ねるマガジンを公開中です！
ビジネスや心と体を整える良記事が集まってきていますので、
是非、覗いてみてくださいね。
記事は全て無料記事のみです。
気に入って頂けたらマガジンのフォローもよろしくお願いします！
共同マガジンに参加希望の方も募集中です！