欲望のビュッフェ
（スコープクリープ）
「ついでにこの機能も」「やっぱりあれも必要」。
開発途中での仕様追加（スコープクリープ）は、ビュッフェで食べきれない量を皿に盛るようなものです。
結果は、消化不良（バグ多発）、腹痛（納期遅延）、そして嘔吐（プロジェクト炎上）です。
- 開発中に「ちょっとした変更」が週に数回発生する
- 「No」と言う権限がPMに与えられていない
- リリース日が同じまま、やることだけが増えている
- 当初の要件定義書が、もはや何の役にも立っていない
ダイエット（機能削減）を始めなければ、心不全で倒れます。
01. 「ついでに」は悪魔の言葉
「画面を一つ増やすだけだから簡単でしょ？」
エンジニアにそう言うのは止めてください。
画面が増えれば、ルーティング、API、バリデーション、テスト、エラーハンドリング、全ての層に影響が出ます。
氷山の一角しか見ずに「簡単」と言うのは、プロの仕事ではありません。
無料ではない。
必ず「代償」を伴う。
02. 変更管理プロセスを導入せよ
要望を出すなと言っているわけではありません。
「口頭で依頼して、なぁなぁで実装する」のを止めましょう。
仕様変更リクエスト（Change Request）をチケット化し、影響範囲とコストをお見積り、
合意の上でスコープに入れる。この「正規の手続き」を通すことが重要です。
03. MVP（実用最小限の製品）への回帰
「全部盛り」はやめましょう。
「これがないとサービスとして成立しない」という機能だけに絞ってください。
それ以外はすべて「Nice to have（あれば良い）」です。
Nice to haveは、V1リリース後、ユーザーの反応を見てから実装しても遅くありません。