営業組織の作り方|小さい会社こそ先に仕組みから始める

営業組織とは:定義と小さい会社での意味

営業組織とは、売上を継続的に生み出す仕組みを持った集まりのことです。この定義で重要なのは「仕組みを持つ」という点です。特定の担当者の個人技や人脈に売上が依存している状態は、厳密には組織とは呼べません。担当者が退職したり体調を崩したりした瞬間に売上が止まるなら、それは組織ではなく「人に売上が紐づいている」状態です。

「小さい会社に営業組織は作れるのか」という疑問はもっともです。5名や10名の会社に「組織」という言葉は大げさに感じるかもしれません。しかし売上を個人の能力に頼り続けることの限界は、規模に関わらず訪れます。むしろ小さい会社こそ、早い段階で仕組みから設計することが必要です。次章ではその理由を説明します。

PR|運営者より

営業のために顧客管理システムを作ったら、社内通貨「Gold」が生まれて、組織が動き出しました。その経緯をnoteに書いています。

→ 【30】営業のために顧客管理システム作ったら、Goldという社内通貨ができて組織が地球儀ぐるぐる回し始めた

この仕組みを、どの会社でも使える形にして、私たちが提供しているのが「Game toB」です。

Game toB法人向けゲーミフィケーションサービスwww.game-tob.bizGame toB 法人向けゲーミフィケーションサービス

なぜ「先に仕組み」なのか:採用前に整える理由

「人を増やせば解決する」は、多くの経営者が一度は頼る発想です。売上が伸び悩んでいるなら営業担当者を採用すればいい、属人化しているなら人を増やして分担すればいい、という考え方です。しかし、仕組みのないまま採用を先行させると、新しく入った人材がその仕組みのなさの中に放り込まれることになります。教える側も学ぶ側も消耗し、採用コストと育成の労力だけが積み上がります。

先に仕組みを整えてから採用するという順序は、一見すると遠回りに見えます。しかし仕組みが先にあれば、採用した人材はその仕組みの中に入るだけでよくなります。教える側の負担が大幅に減り、新人の立ち上がりが早くなり、組織全体の再現性が上がります。「どこから手をつければいいかわからない」という状態の多くは、この順序を逆にしていることに原因があります。仕組みが先か採用が先かという選択は、経営判断ではなく順序の問題です。

「人が増えれば解決する」という発想が繰り返されるのは、経営者の判断が甘いからではないかもしれません。むしろ、属人的な営業が「うまく機能している間」は、仕組みの不在がほぼ見えないという構造的な問題があります。

売上が立っている状態では、その売上がどんな構造から生まれているかは問われません。担当者が結果を出している間、「なぜ出ているか」を言語化する必要がないからです。仕組みの不在が問題として浮上するのは、その担当者が抜けたとき、あるいは同じ方法を別の人に渡そうとしたときです。つまり問題は「仕組みがないこと」ではなく、「仕組みがないことが見えない状態が続くこと」とも言えます。

この視点で見ると、先に仕組みを整えるという判断は「将来への備え」というより、「現在すでに存在している暗黙の仕組みを可視化する作業」と捉え直せるかもしれません。担当者の頭の中にある勝ちパターンは、すでに一種の「仕組み」です。それが言語化されていないだけで、機能はしています。その言語化を採用の前に行うかどうかが、組織としての分岐点になります。

「採用してから」が失敗する構造

採用を先に行い、仕組みを後から整えようとするパターンでは、構造的な問題が連鎖します。新人が入社すると、既存メンバーはその育成に時間を取られます。しかし仕組みがないため、「どう教えるか」を考えながら教えるという二重の負担を抱えることになります。教え方が属人的になり、教えた内容がノウハウとして組織に残りません。新人が育ったと思った頃に退職すると、そのノウハウも一緒に消えます。そしてまた採用し、また一から教えるというサイクルが繰り返されます。このサイクルは、仕組みなき採用を続ける限り終わりません。採用コストを正当化するためにさらに採用するという悪循環に陥ることもあります。仕組みがないところに人を入れても、組織の体力を消耗するだけです。

先に整えた会社と後の会社の分岐点

仕組みを先に整えた会社では、新しく入った人がどの手順で動けばよいかが明確になっています。商談をどのプロセスで進めるか、何を記録するか、どの段階で誰に相談するかが言語化されているため、入社して一定期間が経てば独立して動ける状態を設計できます。一方、後から仕組みを整えようとした会社では、メンバーが増えるほど「誰が何をしているかわからない」状態が深まります。既存のやり方がそれぞれのメンバーの頭の中にあるまま人数だけが増えるため、調整コストが膨らみ、管理の負荷が経営者に集中します。この分岐は、採用の数ではなく、採用の前に何を準備したかで決まります。

まず現状を把握する:営業の状態を3つの視点で見る

仕組みを作り始める前に、今の営業の状態を正確に把握することが必要です。何が機能していて何が機能していないのかを明確にせずに設計を始めると、実態に合わない仕組みを作ることになります。逆に言えば、現状を正確に見るだけで「どこから手をつければいいか」が自然と見えてきます。現状把握は3つの視点で行うのが有効です。

①誰が何をしているか(役割の実態): 今の営業活動が誰によって担われているかを書き出します。社長が全部やっているのか、特定の一人に集中しているのか、複数人が分担しているのかを可視化します。書き出すだけで「自分が抱えすぎている」という実態が明確になることが多くあります。

②どこで詰まっているか(プロセスのボトルネック): 見込み客の発掘から受注までのプロセスのどこで止まりやすいかを確認します。アポが取れない、商談が進まない、クロージングに時間がかかる、のうちどこが最も弱いかを特定します。全体を均等に改善しようとするより、ボトルネック1点を解消する方が成果に直結します。

③数字の見え方(KPIの有無): 現在どの指標を追いかけているかを確認します。数字が見えていなければ、問題の所在がわかりません。また、数字は見えているがプロセスが見えていない場合も、改善の手が打てません。この3点を整理するだけで、次の設計ステップで何を優先すべきかが見えてきます。

少人数で機能する役割兼任モデルの設計

大企業の営業組織では、新規開拓・インサイドセールス・フィールドセールス・カスタマーサクセスが明確に分かれています。しかし5名から30名規模の会社でこの完全分業モデルを適用しようとすると、機能しません。そもそも人数が足りず、それぞれの役割を専任で担える人員を揃えることが現実的でないからです。分業モデルを目指して採用を増やすと、仕組みではなく人員数で解決しようとする元の発想に戻ってしまいます。

小さい会社では「役割兼任」が前提になります。ただし、「何でもやる」と「役割が兼任」は別物です。「何でもやる」は役割が不明確なままで、誰が何に責任を持つかが曖昧になります。「役割が兼任」は、1人が複数の役割を持ちながらも、それぞれの役割の境界と責任が明確になっている状態です。この違いを設計することが、少人数で機能する営業組織の核心です。兼任は妥協ではなく、小さい会社における合理的な設計選択です。

※著者の体験

外部の立場で支援に入った先で、新規開拓と既存フォローを一人の担当者が持っていました。組織図には「両方担当」と書かれていて、本人も「どちらも自分の仕事」という認識を持っていました。

気になったのは、既存顧客への対応は毎日動いているのに、新規開拓のリストには日付がほとんど入っていないことでした。聞いてみると「来週やろうと思っていた」という答えが続き、三ヶ月が経っても件数はほとんど動きませんでした。

「役割の名前があること」と「その役割に時間が割り当てられていること」は別の話だったのだと、外から見ていた私にはよくわかりました。当事者には見えにくい種類の詰まりだと感じています。

5〜15名での役割の振り方

営業の機能を大きく分けると、新規開拓(リードの発掘とアプローチ)、既存フォロー(継続・深耕・紹介獲得)、クロージング(商談から受注までの推進)の3つになります。5名の組織であれば、これらを1人が2役・3役担うことは当然です。重要なのは「誰がどの機能に主責任を持つか」を言語化することです。全員が全部やるという状態では、何かが抜けても誰も気づきません。役割と責任を明示した「役割表」を作ることで、「自分の担当ではないから誰かがやるはず」という状態を防ぎます。役割表には、担当する機能・追うべき指標・報告のタイミングを1枚で整理しておくと、兼任の中でも明確さが保てます。人数が少ないからこそ、言語化しておかないと抜け漏れが見えにくくなります。

兼任を機能させる評価とルール

兼任体制が崩れる最大の原因は「どちらも中途半端になる」という状態です。新規開拓を追いながら既存フォローもこなしていると、緊急度の高い仕事が優先され、中長期的な新規開拓が後回しになります。これを防ぐには、2つの設計が必要です。1つは優先度のルールです。週のうちどの機能にどれくらいの時間を使うかを決めておくことで、片方が完全に消えることを防ぎます。もう1つは評価の切り分けです。誰がどの数字に責任を持つかを決めておかないと、結果が出なかったときに責任の所在が曖昧になります。評価指標を役割に対応させることで、兼任しながらも各機能への当事者意識が生まれます。兼任が機能するかどうかは、役割の設計ではなく評価の設計で決まることが多いです。

社長が営業から抜けるための仕組みの作り方

「自分が全部やっている」という状態は、小さい会社の経営者の多くが経験する壁です。社長が直接営業をかけ、社長の人脈で案件を作り、社長が商談を締める。この構造が定着すると、事業は成長しているのに社長の時間と体力が限界を超えていくという状態になります。しかし「自分がいなくても回る」状態を作るには、単純に誰かに仕事を渡すだけでは機能しません。社長の頭の中にある「勝ちパターン」が言語化されていなければ、渡しようがないからです。

社長が営業から抜けるための設計の核心は、「社長の感覚を言語に変えること」です。なぜその顧客を選んでアプローチするのか、なぜその伝え方で相手が動くのか、どのタイミングで何を聞くと商談が進むのか。社長が無意識にやっていることを言語化し、他者が再現できる形にすることが、引き継ぎの本質です。この言語化のプロセスが、そのまま営業組織の土台になります。言語化を先行させることで、採用後に「感覚を教える」という手間がなくなります。

※著者の体験

事業計画を全社に向けて起案した後、数週間して気づいたことがありました。起案の場では「なぜこの施策をこの順序で選んだか」を問われても答えられるのですが、資料だけが動き始めた先では、同じ質問に誰も答えられないことがわかったのです。

判断の根拠が自分の頭の中にあるままで、資料のどこにも書いていませんでした。打ち合わせで口頭では説明していたのですが、その場を離れると言葉が残っていませんでした。

「渡したつもりだった」と「渡せていた」の間に、こんなに距離があるものかと思ったのを覚えています。口頭で話せることと、書かれていて他の人が読めることは、まったく別のことだと感じています。

勝ちパターンを言語化して渡す手順

勝ちパターンの言語化は、大掛かりなプロジェクトとして取り組む必要はありません。まず社長が商談に臨む際に録音またはメモを取ることから始めます。商談の中でどの質問が効いたか、どの説明で相手の反応が変わったか、どの順序で話が進んだかを記録します。数件分のデータが溜まったら、共通するパターンを抽出します。「こういう課題を抱えている顧客には、このアプローチが機能する」という形で整理すると、営業台本の原形ができます。この台本をもとにロールプレイを行い、他のメンバーが同じ動きを再現できるかを確認します。一回で完成させようとせず、実際の商談を通じて台本を更新し続ける運用が現実的です。

引き継ぎに必要な「見える化」の要素

言語化した勝ちパターンを渡しても、商談の実態が記録されていなければ引き継ぎは感覚の伝達に留まります。引き継ぎを機能させるためには、4つの要素を記録する仕組みが必要です。①商談ステージ(今どの段階にあるか)、②失注理由(どの段階でなぜ受注に至らなかったか)、③顧客属性(業種・規模・課題のパターン)、④決裁者の特徴(決め方・重視するポイント・反対意見の出やすい場面)です。これらが記録されていると、新しいメンバーが担当を引き継いだ際に、商談の文脈をゼロから把握し直す必要がなくなります。記録の量よりも、引き継いだ人が「次に何をすべきか」を判断できる情報があるかどうかが重要です。

小さい会社でよくある失敗パターンと回避策

仕組みを作ろうとしたが機能しなかった、というケースは珍しくありません。ツールを導入したが使われなくなった、KPIを設定したが数字が変わらなかった、という経験を持つ経営者は多くいます。これらの失敗には共通した構造があります。「何を整備したか」に意識が向かい、「なぜそれが必要か」という設計の目的が曖昧なまま進めてしまうことです。小さい会社固有の失敗パターンを理解しておくことで、同じ轍を踏まずに済みます。

※著者の体験

業務で使うことになったツールの入力欄を、最初の頃はきちんと埋めていました。商談の日付や内容を記録する仕組みで、入力が積み上がっていくのは確かに見えていました。ただ、入力した内容が何かの判断に使われたという経験が、私には一度もありませんでした。

一ヶ月ほど経つと、細かい項目を飛ばして最低限の欄だけ埋めるようになっていました。それが自然なことのように感じていて、誰にも言いませんでした。記録の仕組みを作った側も、記録が減っていることに気づいていたかどうか、今でもわかりません。

「入力している」と「使われている」が同じだと思っていた気がします。受け取る側にいるうちは、その二つがずれている瞬間がどこにあるかを、ほとんど意識できませんでした。

ツールを入れても使われない理由

CRMやSFAを導入した直後は入力が続くが、数ヶ月後には誰も使っていない、という状況は多くの組織で起きます。原因はツールの使いにくさや機能の不足ではなく、「入力しても自分の役に立たない設計」になっていることがほとんどです。記録したデータが誰の判断にも活用されなければ、入力する動機が生まれません。ツールを導入する前に、「何を記録すれば、誰のどんな判断が楽になるか」を先に設計する必要があります。たとえば、商談の進捗を記録することで社長が週次で状況を把握できるようになる、失注理由を蓄積することで次のアプローチを変えられる、といった具体的な活用用途が先にあれば、入力は仕事の一部として機能します。ツールは目的が決まった後に選ぶものです。

KPIだけ決めてプロセスを設計していない

「月10件のアポを目標にする」というKPI設定だけでは、数字は動きません。目標値を置くことはゴールの設定であり、そこに至るまでの手順の設計ではないからです。アポを一定数獲得するためにどのリストをどの順序でアプローチするか、1件のアプローチにどれくらいの時間をかけるか、架電とメールをどう組み合わせるか、という手順が設計されて初めて、目標は達成可能なものになります。KPIとプロセスはセットで設計するものです。KPIを決めた後に「どうやって達成するかはメンバーに任せる」という運用では、メンバーは方法を各自で考えることになり、属人化がさらに深まります。プロセスを先に書き出し、そのプロセスが正しく実行されているかを測る指標としてKPIを設定する、という順序が機能します。

実践ステップ:営業組織を立ち上げる順序

ここまでの内容を踏まえ、実際に営業組織を立ち上げる順序を整理します。各ステップはH2②〜⑥で詳述した内容の総括です。順序そのものが設計の核心であるため、手順の前後を入れ替えると機能しにくくなります。「どれから手をつけるべきか」で迷ったときに、この一覧を参照してください。

①現状把握: 役割の実態・プロセスのボトルネック・数字の見え方を3つの視点で整理します。書き出すだけで設計の優先度が見えてきます。

②勝ちパターンの言語化: 社長やトップセールスが無意識にやっていることを録音・メモで記録し、営業台本の原形を作ります。これが後続するすべてのステップの土台になります。

③役割と兼任の設計: 新規開拓・既存フォロー・クロージングの3機能を誰が担うかを明示し、優先度のルールと評価指標とセットで設計します。

④KPI・プロセスの設計: プロセスを先に書き出し、そのプロセスを測る指標としてKPIを設定します。KPIだけを先に決めないことが重要です。

⑤記録の仕組み(ツール): 記録する目的と活用用途を先に決め、その後にツールを選定・導入します。目的のないツール導入は入力が止まる原因になります。

⑥評価制度の整備: 役割ごとの責任指標を評価に反映させ、兼任体制の中でも当事者意識が生まれる評価設計にします。

拡大フェーズへの移行判断基準

仕組みを整えた後、次に訪れる問いは「いつ採用するか」「いつ分業に移行するか」です。多くの経営者がこの判断を感覚で行い、「もう少し待てばよかった」または「もっと早く動くべきだった」という後悔を経験します。移行判断を感覚に頼らないためには、「仕組みが定着した状態」を先に定義しておく必要があります。定義が先にあれば、その状態に達したかどうかを確認するだけで判断できます。

仕組みが定着している状態の目安は、「新しく入ったメンバーが、教える側のサポートをほぼ受けずに独立して成果を出せるようになること」です。具体的には、入社後に一定の期間が経てば一人で商談を進め、記録を残し、次のアクションを自分で判断できる状態です。この状態になっていれば、さらに人を増やしても仕組みの中に収まります。逆に、まだ既存メンバーの個人技に頼っている状態で採用を進めると、再び仕組みなき採用のサイクルに入ります。

移行タイミングの判断には、次の問いが有効です。「新しいメンバーが入っても、既存メンバーの通常業務が圧迫されないか」「台本・役割表・記録の仕組みが実際に日常的に使われているか」「失注理由や商談の詰まりポイントがデータとして蓄積されているか」。これらの問いに自信を持って答えられる状態になってから、次の採用・分業の検討を始めるのが適切な順序です。移行判断の基準を先に持っておくことで、「なんとなくそろそろかな」という感覚頼りの意思決定を避けられます。

ツール(CRM/SFA)は何番目に入れるか

CRMやSFAはどのタイミングで導入すべきかという問いへの答えは、「仕組みが言語化された後」です。プロセスが設計されていない状態でツールを入れると、入力項目が何を意味するかも不明なまま、データが溜まるだけで活用されない状態になります。ツールを早めに入れることが組織化の近道だという誤解は、多くの現場でコストと時間を無駄にしてきました。

ツールは、記録すべき内容が決まり、その記録がどのように使われるかが明確になってから選定します。現段階でスプレッドシートで管理できているなら、それで十分です。人数が増え、スプレッドシートでは管理の限界が来たタイミングでツールへ移行するのが、最も無駄のない順序です。ツールを最初に選ぶことよりも、何を管理するかを先に決めることの方が重要です。

あわせて読みたい

筆者:店長

営業と、競馬と、しゃべる植物。あっAIも。つい、いろいろ作ってしまう人です。

→ 店長の正体(詳しいプロフィール)

店長

Xアカウント:@nishi_sales_ai 新卒で大手の人材・情報サービス系の会社に入社し、飛び込み営業から深耕営業、大手企業担当まで第一線で経験を積む(表彰歴多数)。その後、事業企画・営業企画部門で経営に近い立場から営業組織と数字に向き合い、10年勤続を経て独立。営業組織の改善に特化したコンサルタント企業を立ち上げる。 コンサルタントして数々の現場に入りつつ、自ら営業特化の転職エージェントも運営。近年はAIを活用した営業組織の業務改善・生産性向上プロジェクトに携わる。現在は、自分たちで作った法人向けゲーミフィケーションサービス「Game toB」と営業向けSFA「商談ノート」を提供しながら、その公式メディアである当サイトで、営業と組織づくりの実践知を発信している。

この著者の記事一覧

\ 最新情報をチェック /

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です