トップセールスが辞めると売上が下がる会社の、構造的な理由

「Aさんが辞めてから、一気に数字が落ちた」「あの営業、なんであんなに売れるのかよくわからない」「育てた人材が独立して、顧客ごと持っていかれた」——こうした言葉を、経営者や部長から何度聞いてきたか分からない。

これらに共通しているのは、原因の所在を「人」に帰属させていることだ。しかし現場に入って構造を見ると、問題はほぼ例外なく別のところにある。トップセールスへの依存は「採用が失敗した」結果ではなく、「知識が組織に蓄積されない構造」の必然的な帰結だ。

「なぜ売れるのか」を誰も説明できない組織

まず一つ問いを立ててほしい。自社のトップセールスについて、「なぜ売れているのか」を組織として説明できるか。

多くの場合、答えはこうなる。「人当たりがいいから」「経験が豊富だから」「熱意があるから」。これらは「なぜ売れているか」の説明ではなく、「どんな人か」の描写だ。

本当の意味で「なぜ売れるのか」を説明できるなら、それは再現できる。初回訪問で何を確認しているか。提案書のどの順番で何を話しているか。顧客の反応に対してどう切り替えているか。これらが言語化されて組織に存在していれば、その人がいなくなっても再現の土台がある。

しかし多くの組織では、これが言語化されていない。トップセールス本人も「長年の経験と感覚」として処理しており、自分でも言語化できていないことが多い。だから去った後に何も残らない。

属人化が「生まれる」構造的なメカニズム

属人化は偶然起きるのではない。構造的に必然として生まれる。そのメカニズムはこうだ。

まず、成果を出す個人が現れる。組織はその成果を歓迎し、その人に案件を集中させる。その人は忙しくなり、自分の思考や行動を言語化する時間がなくなる。組織側も「売れているなら問題ない」と言語化を求めない。この状態が続くと、その人だけが持つ「暗黙知」が肥大化する。

並行して、他のメンバーは「あの人は特別だから」という認知を形成する。真似ようとするのをやめ、自分なりのやり方でどうにかしようとする。組織全体として「学ぶ仕組み」ではなく「各自が試行錯誤する文化」が定着する。

これが属人化の生成プロセスだ。誰かが意図してこの状況を作ったわけではない。構造として帰結した結果だ。

「自分が頑張れば数字は作れた。でもチームの数字は自分次第だった。
自分が休むと売上が落ちる。それが正直、ずっと怖かった」

— あるトップセールス自身の言葉（支援前の状況について）

この言葉は示唆的だ。属人化に苦しんでいるのは経営者だけではない。当事者であるトップセールス自身も、その構造の重さを感じている。「自分がいないと回らない」という状況は、本人にとっても持続不可能だ。

退職リスクより深刻な「依存の複利効果」

属人化の問題を「退職リスク」として捉えるのは、視野が狭い。退職は一つの帰結に過ぎない。より深刻なのは、属人化が続くことで組織に蓄積されていく「依存の複利効果」だ。

問題は退職した瞬間に起きるのではない。属人化が始まった瞬間から、じわじわと組織の地力が失われていく。そして多くの経営者がそれに気づくのは、退職という形で問題が表面化した後だ。

なぜ「マニュアル化」では解決しないのか

属人化の解決策として最もよく聞く答えは「マニュアルを作る」だ。しかしこの解決策は、多くの場合うまく機能しない。

理由は二つある。一つは、マニュアルは「手順」を記録するが「判断基準」を記録しない点だ。「初回訪問では名刺交換して自己紹介をする」という手順は書ける。しかし「この顧客の反応を見て、次に何を聞くべきかを判断する」というプロセスは、手順書に落とせない。トップセールスが持っているのは後者だ。

もう一つは、マニュアルは「作る」だけでは意味がなく「使われる構造」が必要だという点だ。多くの組織でマニュアルは作られたが使われていない。なぜか。マニュアルを参照する習慣が定着していないからであり、それはアプリ断絶の問題だ。マニュアルを作っただけで属人化が解消されないのは、別の断絶が残っているためだ。

構造的に解決するとはどういうことか

属人化を構造として解決するには、「個人の暗黙知を組織の形式知に変換し続ける仕組み」が必要だ。これはDB層（知識の蓄積と共有）の設計問題だ。

具体的に機能する設計には三つの要素がある。

第一に、「勝ちパターンの言語化プロセス」だ。商談後に何が効いたかを言語化し、パターンとして蓄積する仕組みが必要だ。これはSalesforceやHubSpotといったSFAツールで実現できる「はず」のことだが、ツールを入れただけでは機能しない。言語化のフォーマットと、言語化を促すマネジメントの設計がセットで必要だ。

第二に、「失敗の構造化」だ。失注した案件から何を学ぶかを、感情論ではなく構造として分析する習慣だ。「あの顧客は合わなかった」で終わらせず、「どのフェーズで何が起きたか」を解剖する。これが蓄積されると、組織として「失ってはいけないフェーズ」が明確になる。

第三に、「学びの移転設計」だ。トップセールスが持つ知識を他のメンバーが習得できる形に変換するプロセスだ。これはロールプレイや同行訪問という方法論だけでなく、「何を見て、何を学ぶか」というフレームを事前に設計することを意味する。

「仕組みができてから、チームの底上げが目に見えて変わった。
自分がいなくてもチームが動くようになったとき、
はじめて経営に集中できると思えた」

— 支援後の変化について、ある営業部長の言葉

まず確認すべき3つの問い

自社に属人化の構造的問題があるかどうかを確認するには、以下の3つを問えばいい。

一つ目。自社のトップセールスの「なぜ売れるのか」を、マネージャーが他のメンバーに言語化して説明できるか。「あの人は特別だから」という答えしか出ないなら、DB断絶が起きている。

二つ目。新人が入ったとき、「成果を出す行動プロセス」を構造として渡せているか。「先輩の背中を見て学べ」が標準的な育成方法になっているなら、DB断絶が根付いている。

三つ目。先月の商談で失注した案件の「根本原因」を、チームで構造として説明できるか。「相手のタイミングが悪かった」「縁がなかった」という答えが返ってくるなら、学びが蓄積されていない。

問題は人にあるのではない。知識が蓄積されない構造にある。そしてその構造は、設計によって変えられる。