「クロージング月になって、ようやく赤字が見えた」――受託開発でこの言葉を聞かない月はありません。
ただ、現場のPMに話を聞くと、赤字は最後の1か月で発生したわけではないことがほとんどです。見積の前提、変更のさばき方、進捗の見せ方、顧客との合意の取り方が少しずつズレていき、それが終盤に一気に表面化しているだけです。
この記事では、赤字案件の原因をPM個人の能力問題に押し込めず、「案件運営のどこにサインが出ていたのか」という観点で整理します。
赤字は突然出ない、4つの場面で予兆が出ている
赤字案件を後追いで振り返ると、ほぼ必ず以下4つの場面のどこかで赤信号が出ています。
- 見積前提：顧客責任・自社責任・除外事項を曖昧にしたまま受注している
- 変更管理：「ちょっとだけ」の要望を見積外で吸収し続けている
- 進捗判断：進捗率と消化工数の乖離を「もうすぐ追いつく」で済ませている
- 顧客調整：仕様確定・確認・承認の遅れを、自社の残業で取り戻している
これらは、どれも単体では「よくあること」に見えます。問題は、4つが同時に進行しているのに、PMがそれを赤字として翻訳できていないことです。
PMが中盤までに見るべき5つのサイン
赤字を「終わる前」に検知するために、PMは以下のサインを見てください。難しい管理会計の知識はいりません。
サイン1：未確定要件が中盤で残っている
要件定義フェーズが終わっているはずなのに、「ここはまだ決まっていない」「お客さんに確認中」が残っている案件は、ほぼ確実に終盤で工数膨張します。
中盤時点で未確定が3件以上残っている場合、それは品質リスクではなく粗利リスクとして扱ってください。
サイン2：変更要望が議事録に残っていない
口頭で受けた「ちょっとした追加」をMTGメモに残していないと、後から請求根拠を作れません。
変更履歴が増えないのに開発タスクが増えているなら、それは赤字の予兆です。
サイン3：レビュー指摘・手戻り件数が想定を超えている
設計・コードレビューで指摘がいつもの倍出ている、テスト工程で出戻りが続いている――こうした品質サインは、最終的に工数として粗利を食い潰します。
「品質の問題」と「粗利の問題」を分けて扱わないでください。
サイン4：顧客の確認待ちが常態化している
PMが「確認待ちなので遅延ではない」と説明し始めたら危険です。確認待ちが続いている期間、開発側は別タスクで埋めているはずですが、それは結局戻ってきた要件で巻き直しになります。
確認待ち期間も粗利を消費しているという意識が、現場ではまだ薄いです。
サイン5：上司への報告が「順調です」一辺倒になっている
順調と表現できる案件は、本当はほとんどありません。
順調と報告するPM自身が、何を持って順調と言っているのか答えられない場合、その案件は赤字に向かっています。
赤字をPM個人の責任にしないために
赤字を防ぐ仕組みは、PM個人の頑張りで作れるものではありません。
顧客折衝の精度、変更管理ルール、進捗の見方、レビュー体制、上司への報告様式――これらは案件運営の仕組みであって、PM教育の問題ではなく組織課題です。
経営者・開発責任者がやるべきことは、PMを責めることではなく、「赤字になりそうな案件のサインを上長が見れる仕組み」を作ることです。
自社の案件運営を点検したい方へ
「うちの会社の案件運営は、赤字の予兆を捕まえられる状態になっているのか」を点検したい場合は、PM組織健康診断 を使ってみてください。
PM個人のスキルではなく、案件運営の仕組み・レビュー・育成体制の観点で現状を可視化できます。診断結果は経営層・開発責任者の意思決定材料としてそのまま使える形でまとまります。
次に読む関連記事
- 赤字案件を減らすために開発責任者が見るべきPM指標｜売上・利益だけでは早期検知できない — サインを見るための先行指標を定める
- 赤字案件を個人の責任にしないための組織レビュー — 起きたあとで何を見るかを仕組みで決める
- 赤字案件になりそうなときに経営者が確認すべきこと — 炎上になりかけたときの意思決定材料
- 受託開発のQCD崩れ・炎上・赤字案件を減らす考え方を見る — 案件運営とPM育成の仕組みを点検する全体ガイド