営業の広げた風呂敷を畳む現場とは。期待値は設計するものだ

営業が商談から戻ってくる。顔色は明るい。「いい感触でした。先方も乗り気です。」

聞いてみる。スコープは決まったか、納期は何月か、誰がやる前提か。曖昧な答えが返ってくる。「そこは受注後に詰めれば。とりあえず提案書は通りました。」

3週間後、現場が悲鳴を上げる。提案書に書かれた機能群を、提案書の納期で、提案書の予算で実装するには、人がもう一人要る。スキルが合うメンバーは別案件で埋まっている。営業は「先方の期待を裏切りたくない」と言う。

何度、私を商談に呼んでくれればと思ったことか。

この記事の要点

• 営業が広げる風呂敷は個人の判断ミスではなく、フィジビリの裏付けがない状態でコミットするしかないKPI構造の問題だ。
• 営業とデリバリーの対立は、コミュニケーション改善では解けない。評価軸（営業=受注／現場=QCDS）が交わらない構造を変える必要がある。
• 期待値コントロールは熟練営業の個人スキルに頼る運用で、属人的・再現不能。
• 解は「受注前にできることを設計してから売る」こと。期待値はコントロールするものではなく、最初から作るものに変わる。
• これを実装するのが採算設計クラウドの本来の役割だ。

なぜ営業は「できます」と言って帰ってくるのか

営業を責めるのは簡単だ。だが営業の行動は、与えられたKPIに対する合理的な最適化である。

営業のKPIは受注金額と受注件数。商談の温度が下がれば受注確度が下がる。だから「できます」と答える。フィジビリの裏付けがない状態でも、答えるしかない。受注を取り逃せば営業は評価されない。

一方、デリバリー（現場・PM）のKPIは稼働率と案件のQCDS達成。無理な納期・予算で受けた案件は、稼働を圧迫し、QCDSを崩す。だから「受けられません」と答える。受注の手柄は営業に渡らないが、炎上の責任は現場に降る。

両者の対立はマインドの問題ではない。KPI構造が交わらないことの自然な帰結だ。 コミュニケーションを改善しても、評価軸が変わらない限り行動は変わらない。

営業・現場の分断と似た構造は、アサインと採算が別の場で決まる現象としてアサインと採算は、分けていい。つなげないのが命取りだにも書いた。

期待値の膨張は、構造的な不在の症状

商談で風呂敷が広がる本当の原因は、営業の意欲過剰ではない。受注前に「できること」を裏付けるデータが、営業の手元にないことだ。

商談中の営業は、顧客の前で次の問いに即答できなければならない。

• このスコープは、いつまでに、いくらで、どんな体制で実現できるか
• 顧客の要望のうち、どこまでは確実に取れて、どこからは設計の工夫が要るか
• もし要望Aを優先するなら、要望Bは後ろ倒しになるが、顧客はどちらを取るか

これらに即答するには、案件のスコープに対する編成と原価のシミュレーションが、商談の場にあらかじめ用意されている必要がある。なければ営業は「持ち帰って確認します」と言うか、「できます」と勢いで答えるかのどちらかしか取れない。前者は商談の流れを切り、後者は期待値の膨張を生む。

熟練営業はここを暗黙知で埋める。過去の類似案件の感覚、現場メンバーの個性の記憶、自社のクセを総動員し、「これは多分できる、これは怪しい」を瞬時に判断する。だがこの暗黙知は、本人が辞めれば消える。新人営業に同じ判断はできない。期待値コントロールは熟練営業の個人スキルではなく、属人化した運用の言い換えに過ぎない。

熟練PMの暗黙知が組織から消える構造はアサインメントが神業で回っていないか？属人業務から経営資産へに書いた。営業の暗黙知も、同じ構造で消える。

キックオフを増やしても解けない、解いたつもりになるだけ

営業とデリバリーの対立を、現場ではキックオフミーティングや週次定例の改善で解こうとする。営業から現場へ案件の背景を丁寧に伝え、現場から営業へ実現可能性をフィードバックする。

これは効くか。短期的には少し効く。中期的には効かない。

理由はシンプルだ。キックオフが行われるのは、もう受注した後だからである。

AI参謀：「営業さん、いまの提案、現場が組める体制でやると限界利益は4.2%です。固定費回収には届きません。スコープのうちXとYを第2フェーズに送れば、第1フェーズの限界利益は18%まで上がり、現場のメンバー構成も成立します。顧客にこの分割で打ち返しますか、それとも現状の単価で再交渉しますか。」

このやり取りが、商談中に営業の手元にある状態を作る。これが解だ。受注後のキックオフでは、できないことが見えても、もう手遅れになっている。

期待値はコントロールするものではなく、設計するものだ

ここで認識を一段ずらす。

熟練営業は「顧客の期待値をコントロールする」と言う。膨らみすぎた期待をなだめ、現実に着地させ、双方の合意点を探る——という意味だ。だがこの言葉自体が、すでに期待値が膨らんでしまった後の対処を前提にしている。

真の問題は、期待値が膨らんだ後にどうコントロールするかではない。期待値が膨らむ前に、どこで握るかだ。

受注前に「自社が組める編成」と「その編成で達成できるQCDS」を可視化しておけば、営業は商談で「できます／できません」ではなく「この体制ならここまで、別の体制ならここまで」というデータに基づく提示ができる。顧客はそれを起点に合意する。期待値は膨らんでからコントロールするものではなく、最初から「設計された約束」として置かれる。

「広げた風呂敷」を「設計された約束」に変えるレイヤー

採算設計クラウドが担うのは、まさにこの転換だ。商談がクローズに近づいたタイミングで、案件のスコープに対して編成候補を複数走らせ、各候補のQCDS整合と限界利益を可視化する。営業はその結果を持って商談に臨み、「できます」ではなく「この体制で、このQCDSで、限界利益この%が残る前提で握りませんか」と話す。

顧客から見ると、これは値引き交渉に巻き込まれにくい提案になる。根拠が編成と限界利益で語られるため、顧客側も無理な値引きを言い出しにくい。価格は希望ではなく設計の結果として提示される。

採算設計クラウドというカテゴリの位置づけは採算設計とは。プロジェクト型組織が受注前に利益を作る新カテゴリ、編成シミュレーションの中身は案件アサインAIとは。スキル・稼働・採算・意向を同時設計する仕組みに整理した。

どこから始めるか

営業全員にデータドリブンを徹底させる、という抽象的な号令から始めない。動かない。

始まりは、次の重要商談1件だ。その案件のスコープを編成に分解し、3案の編成候補を作り、各案のQCDSと限界利益を商談前に1ページにまとめる。営業はそれを持って商談に行く。「できます」ではなく、3案のどれが顧客にとって最も合うかを問う。

これを商談単位で積み重ねるうちに、営業は夢を売る人から、設計を売る人に変わる。期待値の膨張は構造的に減り、現場からは「あの営業の案件は受けて大丈夫」という信頼が生まれる。

製品としての実装は、採算設計クラウド『CATCAREERアサインメント』である。商談中の営業に「できることを設計したデータ」を渡し、期待値の最初の一行を設計する側に立たせる。