商談確度は読めても、利益は読めない。パイプラインの手前で抜けている視点

エネルギー業界の新事業開発支援案件。アイディエーションとPoC・MVP開発の2大フェーズに分け、フェーズごとに見積もりを出し、顧客の承認を取って進めていた。提案承認は通った。商談確度は高い。期待していた。

ふたを開けたら、MVP開発フェーズでデザイナーと開発エンジニアを想定の2倍近く投入していた。赤字。

フェーズごとに見積もりを承認しても、赤字は止まらなかった。

この記事の要点

• SFA・パイプライン管理が見ているのは「顧客が買うか」の確度であり、「自社が届けられるか」は測らない。
• フェーズごとの見積もり承認スキームでも、受注前にQCDS（品質・コスト・納期・スコープ）を高い解像度で設計できていなければ、赤字は同じように発生する。
• 営業が一人でQCDSを詳細設計するのは現実的に難しい。これは個人スキルの問題ではなく、構造の問題だ。
• 受注前に編成と限界利益をシミュレーションする採算設計のレイヤーを、パイプラインの手前に置く必要がある。
• 商談確度と案件採算は別の指標。両方を揃えて初めて、売上達成と利益達成が一致する。

SFAは、買ってくれる確率しか測らない

営業組織にSFAやパイプライン管理を入れる目的は明確だ。商談を可視化し、受注確度を上げ、売上の予測精度を高める。これは間違いなく機能する。期末の売上着地は、SFA導入前より読めるようになる。

だが、SFAは利益を測らない。

商談ステージ、商談金額、受注確度、リードソース——SFAのKPI群はすべて「顧客が買うかどうか」を測る指標である。SFAは買ってくれる確率を読むが、自社が届けられる確率は読まない。

エネルギー業界の新事業開発支援案件で起きたのは、まさにここだ。SFAは入れていなかったが、フェーズごとの見積もり承認という、より精緻に見えるスキームを敷いていた。アイディエーション→PoC/MVP開発→本実装、というフェーズ。各フェーズで見積もりを切り、顧客と握り、進める。

商談はクリーンに進んだ。顧客の承認も得た。だがMVP開発フェーズに入った瞬間、デザイナーと開発エンジニアの稼働が想定の倍近くに膨らんだ。フェーズ承認時点の見積もりは「スコープと金額の整合」を確認していただけで、「そのスコープを届けるのに本当に必要な体制と工数」を予見していなかった。

「営業が解像度高くQCDS設計できる」は稀

なぜこの予見ができなかったのか。営業のスキル不足ではない。構造の問題だ。

案件のQCDS——品質・コスト・納期・スコープ——を受注前に高い解像度で設計するには、次のような情報が要る。

• スコープを工程に分解し、各工程にどのグレードの人材が何人月必要かを見積もる
• 顧客側の意思決定プロセス・チェック層・書類文化が工数にどう跳ねるかを織り込む
• 編成案ごとに原価がどう動くか、限界利益が何%残るかを比較する
• 過去の類似案件のリアルな限界利益データを参照する

これを営業担当一人がやるのは、現実的に難しい。営業のコア業務は顧客との関係構築と提案だ。受注前に編成を分解し、原価を弾き、限界利益を試算するのは、別の専門性が要る。QCDS設計を営業の個人スキルに頼る限り、解像度の高い見積もりは「稀有な営業担当」だけのものになる。

PMOが受注後に炎上を止めようとしても止められない構造はPMOが炎上を止められないのは、無能だからではないに書いたが、PMOが入る前——受注の意思決定の段階で、QCDS設計の解像度は決まっている。

商談確度と案件採算は、別の指標だ

SFAやパイプライン管理ツールが見ている指標と、案件採算を意思決定するために本来見るべき指標を、横に並べる。

観点	SFA・パイプライン管理	採算設計
主な問い	この商談は受注できるか	この案件を受けて利益が残るか
中心KPI	受注確度・商談金額・パイプライン総額	限界利益率・編成原価・QCDS整合
扱う情報	顧客の購買意欲・競合状況・予算	案件スコープ・必要体制・原価構造
主な使い手	営業担当・営業部長	経営者・事業責任者・PM
時間軸	商談ステージごと（数週間〜数ヶ月）	受注前（提案・営業フェーズ）の一点集中
解く課題	売上予測の精度・営業効率	案件採算・受注後の体制崩壊の予防
放置すると起きること	売上達成・利益ショート・隠れ赤字案件	受注は減るが、受注した案件の利益率が上がる

二つは対立しない。重なってもいない。SFAが商談確度を読み、採算設計が利益確度を読む。両方を揃えて初めて、売上達成と利益達成が同じ意味になる。

採算設計のカテゴリ全体は採算設計とは。プロジェクト型組織が受注前に利益を作る新カテゴリ、案件単位の限界利益の計算は限界利益とは。プロジェクト型組織で案件採算に使う計算と落とし穴に整理した。

「どんぶり受注」を技術的に減らす

エネルギー業界の事例に戻ると、赤字の真因は単純に表現できる。「どんぶり勘定での受注」が原因だ。 フェーズ承認スキームを敷いていても、フェーズ内の体制と工数を予見設計する仕組みがなければ、見積もり値は希望的観測のままだ。

「どんぶり受注」を技術的に減らす方法は、営業担当のQCDS設計力を鍛えることではない。受注前に編成シミュレーションを走らせ、各編成案ごとの原価と限界利益を数値で並べ、最も限界利益の高い体制で受注するという運用を作ることだ。

これを担うのが採算設計クラウドである。商談がクローズに近づいたタイミングで、案件のスコープを編成に分解し、メンバー単価×工数で原価を弾き、限界利益が固定費回収に貢献する水準に達するかを受注前に確認する。届けられる確度と利益が残る確度が、商談確度と並んで数値で出る。

スコープを工程に分解する案件アサインの考え方は案件アサインAIとは。スキル・稼働・採算・意向を同時設計する仕組み、案件選定の判断軸は経営者が今すぐ決断すべき「お断りする案件」の採算設計学に書いた。

どこから始めるか

SFAを捨てる必要はない。商談確度の管理は引き続き必要だ。再設計の方向は、SFAの手前に採算設計のレイヤーを足すことにある。

始まりは、次に受注確度が一段上がる商談だ。その案件のスコープを編成に分解し、編成候補を3案ほど作り、各案の限界利益を試算する。最も限界利益が高く、かつ届けられる確度の高い編成を選び、その体制で受注する。これを案件単位で積み重ねるうちに、商談確度と利益確度が両輪で回る運用になる。

SFAは買ってくれる確率を読む。採算設計クラウドは利益が残る確率を読む。読むものが違う以上、両方が要る。

製品としての実装は、採算設計クラウド『CATCAREERアサインメント』である。