「これ、ちょっとだけ追加できますか」――顧客からこう言われたとき、PMがその場で「やっておきます」と答える瞬間が、赤字化の第一歩であることは珍しくありません。
一件一件は確かに小さい変更です。が、案件全体で集計すると、当初の工数を15〜30%押し上げていることがほとんどです。本記事では、なぜ「ちょっとだけ追加」を放置すると赤字化するのか、その構造を整理します。
「ちょっとだけ追加」は本当にちょっとなのか
多くのPMは、「画面に1項目追加」「ボタンを1つ増やす」程度の依頼を「ちょっと」と捉えます。が、実装観点で見ると、追加項目1つに対して以下の作業が連鎖します。
- 画面設計の修正
- DBスキーマ・API仕様の修正
- 関連画面の影響範囲確認
- バリデーション・エラー処理の追加
- テスト範囲の拡張
- 仕様書・操作マニュアル等のドキュメント更新
開発者から見れば「ちょっと」ではないことが、PMには「ちょっと」に見えてしまう構造があります。
4視点で見る「赤字化の構造」
視点1：工数
「ちょっと」と感じる依頼1件あたり、平均的には2〜3人日の追加工数が発生します。月に5件あれば10〜15人日、案件全体で20件積み上がれば40〜60人日です。
この数字は、見積バッファでは吸収できないサイズになります。
視点2：品質
小さな変更が増えるほど、リグレッションのリスクが上がります。
テスト工程で不具合が増え、手戻りで工数がさらに膨らみます。「ちょっと」の依頼を吸収しすぎた結果、品質指摘が膨らんで赤字化するパターンは典型です。
視点3：納期
ちょっと追加を吸収するために、メンバーが残業や休日対応で対応する状態が続くと、本来予定していたタスクが圧迫されます。
最終的に、本来やるべきタスクが間に合わなくなり、納期遅延として表面化します。
視点4：チーム負荷
「ちょっと」の積み上げは、メンバーのモチベーションを直接削ります。
「PMが何でも受けるから現場が回らない」という不満は、現場のチームから必ず出ます。離脱リスク、品質低下のリスクが連鎖します。
PMが今日から運用できる線引き
ルール1：その場で答えない
どんな小さな依頼でも、「確認してご連絡します」と返すことを徹底します。
即答で「やっておきます」と答えると、変更管理表に乗らなくなります。
ルール2：48時間以内に影響を整理する
「いつまでに回答するか」を必ず伝え、A4一枚で影響を整理します。
影響範囲・追加工数・代替案・判断期限の4項目で十分です。
ルール3：判断は顧客に渡す
「やる／やらない」「全部やる／一部やる」「納期を伸ばす／他要件を削る」の選択肢を渡し、判断は顧客側にお願いします。
ルール4：合意は文書で残す
メール1通でも構いません。書面に残さないと、検収段階で「言った言わない」になります。
「ちょっと」の積み上げで炎上しかけている案件には
すでに小さな変更の積み上げで工数膨張・品質劣化が進み、炎上の予兆を感じているなら、PJ炎上初動ナビ で状況タイプを判定するのが最初の一手です。
要件迷走型／追加要望型／品質型／関係悪化型／契約前提ズレ型のどれに当てはまるかを判定し、最初の1週間で打つべき初動アクションを案内します。