炎上ゼロでも利益は消える。「隠れ失敗プロジェクト」の正体

プロジェクトの失敗と聞いて思い浮かぶのは炎上だ。納期遅延、深夜の火消し、謝罪の往訪。だが決算を本当に蝕むのは、炎上しない失敗のほうだ。

隠れ失敗プロジェクトとは、炎上も納期遅延もなく、全員が真面目に働いているのに、利益がほとんど残らないまま完了するプロジェクトを指す。

誰も失敗と呼ばない。だから対策もされない。打ち上げで「お疲れさまでした」と乾杯し、次の似たような案件へ移っていく。

この記事の要点

• 隠れ失敗プロジェクトとは、炎上せず全員が真面目に働いているのに利益が残らないまま完了する案件を指す。
• 原因は現場の生産性ではなく、営業とデリバリーの分業のあいだで「案件ポートフォリオ全体の採算」が無所属になっている構造にある。
• 案件の原価構造は「誰を・何人・何カ月」という編成が決まった受注時点でほぼ確定し、受注後の管理では回復できない。
• プロジェクト管理ツール・PSA・会計はいずれも受注後から完了後が守備範囲で、利益が決まる受注前は空白地帯のまま残る。
• 受注前の採算設計を既存ツールの上流に足し、設計・実行・検証のサイクルを案件単位で回すのが現実的な打ち手だ。

なぜ誰も「案件全体の採算」を見ていないのか

プロジェクト型組織には構造的なねじれがある。

営業は売ることを追う。受注金額や件数が評価指標になり、デリバリーの負荷や採算性は視野に入りにくい。デリバリーは納めることを追う。受注済みの案件をどう完遂するかが仕事であり、そもそも受けるべき案件だったかは問われない。結果、案件ポートフォリオ全体の採算は誰の担当でもなくなる。

このねじれが隠れ失敗プロジェクトを量産する。大型案件なのに粗利率が一桁。エース級の人材が低採算案件に長期拘束され、その間に来た高採算案件を取り逃す。個々の損失は決算書の営業利益率という一つの数字に溶けて、誰の目にも見えなくなる。商談確度をどれだけ精緻に管理しても採算が読めない構造については商談確度は読めても、利益は読めない。パイプラインの手前で抜けている視点に書いた。

ここで見落とされがちな事実が一つある。

案件の原価構造は「誰を・何人・何カ月」という編成が決まった受注時点でほぼ確定する。

受注後にいくら管理を精緻化しても、動かせる余地はわずかしかない。利益が残るかどうかの分岐点はプロジェクトが始まる前、受注を判断する一瞬にある。

プロジェクト管理ツールもPSAも、受注後から始まる

プロジェクト型ビジネス向けのツールは数多いが、大半は受注後を対象にしている。

プロジェクト管理ツール（Asana、Backlog、monday.comなど）はタスク・進捗・スケジュールの可視化に強い。焦点は受注した案件をどう進めるかであり、案件別の採算やそもそも受けるべきかの判断は守備範囲外だ。

PSA（Professional Services Automation）は案件管理・リソース管理・工数管理・財務管理・請求を統合する基幹システムで、進行中の案件の収益性をリアルタイムに可視化できる。ただし設計思想は進行中・完了後の案件を正確に管理し、財務と連携することに置かれている。ZACやReformaを導入しても採算が合わない理由はZAC・Reformaがあっても、なぜ採算は合わないのかで詳述した。

会計・原価管理ツールは案件別の売上・原価・粗利を集計できるが、それは事後の記録だ。赤字だったと分かるのは、たいてい案件が終わったあとである。

	プロジェクト管理	PSA	会計・原価管理	採算設計
対象フェーズ	受注後から完了まで	受注後から完了まで	完了後（事後）	受注前
主な問い	どう進めるか	どう管理するか	いくらだったか	受けるべきか、どう組むか
利益への介入余地	小	中（管理）	なし（記録）	大（設計）
主な使い手	現場メンバー	PM・管理部門	経理	現場リーダーと経営

どれも優れた道具だ。しかし共通して、利益がまだ動かせる受注前の一瞬を空白地帯として残している。この空白を埋める業務領域が採算設計であり、定義とカテゴリの全体像は採算設計とは。プロジェクト型組織が受注前に利益を作る新カテゴリにまとめた。

既存ツールを捨てずに、上流に「設計」を足す

採算設計クラウド『CATCAREERアサインメント』は、この受注前の空白に機能を集中させた実装である。案件を受注する前に行うことは三つだ。曖昧な引き合いを必要スキル・規模・期間・リスクの構造化された情報へ引き上げる。「誰を・何人・何カ月アサインすれば利益が残るか」をシミュレーションする。現場リーダーが編成案と採算見立てを作り、経営がそれを見て受注可否を判断できる状態を作る。

意図的に持たないのが、受注後の重厚な進捗管理や全社的な基幹管理機能だ。それらは既存のプロジェクト管理ツールやPSAが十分に担っている。既存ツールと競合せず、その上流を埋める。

フェーズ	役割	担い手
受注前（採算設計）	案件の解像度を上げ、利益が残る編成を設計する	現場リーダー
受注判断（経営承認）	採算を見て受注可否を決定する	現場リーダーと経営
受注後（実行管理）	タスク・進捗を管理する	現場リーダーとメンバー
完了後（財務レビュー）	実績を検証し、次の設計精度を上げる	バックオフィス

このサイクルが回ると、受注前の設計、実行、事後検証、次の設計への反映という形で、案件採算の学習が組織に蓄積される。隠れ失敗プロジェクトは「気づいたら終わっていた赤字」から「受注前に棄却された編成案」へと姿を変える。

炎上は目立つから対策される。隠れ失敗は目立たないから繰り返される。これを断つ方法は管理の精緻化ではない。

案件を記録する前に、案件を設計する。