BDR体制構築の実務設計｜必要な役割・分業ルール・最初の30日間の動かし方

「アウトバウンドをやりたいが、誰が何をやるかが決まらない」「BDRを立ち上げたものの、最初の1ヶ月で失速してしまった」――そういった相談が、事業成長を求めるBtoB企業の営業責任者から寄せられます。

BDRは架電量を増やすことではありません。誰に・何をきっかけに・どう届けるかを設計し、そのサイクルを回す体制を作ることです。体制が整っていなければ、スクリプトが良くても、ツールを入れても、成果は出ません。

• BDR体制に必要な役割は「設計」「実行」「改善管理」の3つに分かれる
• 1人体制から始める場合と複数人体制では、優先順位が変わる
• 最初の30日間は「量を取る」より「型を作る」ことに集中する
• 振り返りは週次・月次でそれぞれ見る指標を分けて運用する
• ターゲット設計の解像度が、その下のKPIの上限を決める

BDR体制に必要な3つの役割

BDR体制を作るとき、最初に整理するのは「誰が何をやるか」ではなく「何の機能が必要か」です。人を先に決めると、スキルセットに合わせた体制になり、必要な機能が抜け落ちます。

BDRを機能させるために必要な役割は、大きく3つです。

BDR体制に必要な3機能

人数より先に「何の機能が必要か」を整理する

• 設計（ストラテジスト）：誰に・なぜ今・何を届けるかの仮説を作る。ターゲット選定基準、トリガー定義、メッセージ方向を担う
• 実行（エグゼキューター）：架電・メール・フォーム投入などの接触行動を実施。断られた理由や反応をログに記録する
• 改善管理（プログラムマネージャー）：ログをもとにターゲット・メッセージの仮説を修正し、翌週の動きに反映させる

設計（ストラテジスト）は、誰に・なぜ今・何を届けるかの仮説を作る役割です。ターゲットリストの選定基準、トリガー（接触のきっかけ）の定義、メッセージの方向性、チャネルの組み合わせを決めます。この役割が弱いと、実行をどれだけ頑張っても歩留まりが改善しません。

実行（エグゼキューター）は、架電・メール送信・フォーム投入などの接触行動を実際に行う役割です。スクリプトに沿って動きながら、断られた理由・相手の反応・刺さった表現を記録します。この記録がないと、改善が属人的な感覚に依存します。

改善管理（プログラムマネージャー）は、ログを見てターゲットやメッセージの仮説を修正し、次の週の動きに反映させる役割です。BDRが「やりっぱなし」になるのは、この機能が抜けているケースがほとんどです。

小規模な体制では1人が複数の役割を兼ねます。その場合でも、「この時間は設計に使う」「この時間は実行に使う」と役割を分けて動くことで、ループが回りやすくなります。

体制の組み方｜1人・少人数・チームの3パターン

BDRの体制は、稼働できる人数とリソース量によって設計が変わります。ここでは現実的な3パターンを整理します。

BDR体制の3パターン比較

人数と役割分担の組み合わせで設計が変わる

観点	1人体制	少人数（2〜3人）	チーム（4人以上）
設計担当	兼任（週1回の専用時間確保が必須）	責任者が担う	専任または責任者
実行担当	兼任	1〜2名	複数名（架電・アウトリーチ）
改善管理	兼任（失速リスク高）	責任者が兼任	IS連携担当が橋渡し
最大のリスク	設計が止まり実行に追われる	責任者が管理者になる	引き継ぎ基準が曖昧になる
立ち上げのポイント	週を役割別に分割して動く	設計時間を死守する	基準の言語化を最初に行う

パターン1：1人体制（担当者が全機能を兼ねる）

新規開拓に専念できる人員が1人しかいない、あるいはまず小さく始めて検証したい場合のパターンです。この場合、週の使い方を「設計日」「実行日」「振り返り日」に分けることが機能させるための前提になります。毎日架電だけしていると、ログが溜まっても改善につながりません。

1人体制の最大のリスクは「実行量が出ない」ことではなく、「設計が止まる」ことです。架電が増えるにつれて実行に追われ、ターゲットリストの見直しやメッセージの仮説検証が後回しになります。週に1回でも「設計に使う2時間」を確保することが、体制として機能させる最低条件です。

パターン2：少人数体制（2〜3人、役割を分担）

実行担当が1〜2名、設計・改善管理を営業責任者が担うパターンです。事業成長を求めるBtoB企業でBDRを本格的に立ち上げる際に、最初に到達する体制規模です。

この体制が機能するかどうかは、責任者が「管理者」ではなく「設計者」として動けるかにかかっています。実行担当から上がってくるログを読み、「なぜこのターゲットは断るのか」「刺さったメッセージはどこが違うのか」を自分なりに言語化できないと、実行担当への指示が「もっと架電しろ」になってしまいます。

パターン3：チーム体制（4人以上、専任分業）

リサーチ・リスト作成担当、架電・アウトリーチ担当、IS連携担当（商談化へのブリッジ）を分けて回す体制です。このフェーズでは、役割間の「引き継ぎ基準」を明文化することが重要になります。どの状態になったらISに渡すのか、断られた案件をいつ再エントリーするのか、が曖昧だと分業が機能しません。

最初の30日間の動かし方

BDR体制を立ち上げた最初の30日間は、「量を取る」ことより「型を作る」ことに集中します。この時期に成果（アポイント数）を追いすぎると、ターゲット設計や訴求の仮説が固まる前に消耗します。

最初の30日間のステップ

「量を取る」より「型を作る」ことに集中する

1. 1週目：ターゲットとトリガーの仮説設計
   業界・規模・役職に加え「今この企業が動きやすい理由」を定義。リスト選定基準を言語化する
2. 2週目：スクリプトと接触シーケンス設計
   課題の自覚を促すメッセージを作成。7〜12タッチのシーケンスを電話・メール・フォームで設計
3. 3週目：実行とログ取りの習慣化
   架電・アウトリーチを開始。断られた理由を3分類（予算・競合・課題なし）でログに記録
4. 4週目：初回レビューと仮説修正
   3週分のログをもとにターゲット・メッセージの仮説を検証。「何が外れていたか」を言語化する

1週目：ターゲットとトリガーの仮説を立てる

最初に決めるのは「誰に・なぜ今」です。業界・企業規模・役職に加え、「今この企業が動きやすい理由」（トリガー）を定義します。資金調達、組織変更、採用増加、新規事業の立ち上げ、制度改定への対応――こうした変化が起きている企業は、課題が顕在化している可能性が高く、接触のタイミングとして使えます。

この段階で「誰でも良い」リストを作ってしまうと、後の全工程の歩留まりが下がります。ターゲットの解像度が、その下のすべてのKPIの上限を決めます。

株式会社START WITH WHY代表の中村です。弊社では大手・上場企業からスタートアップまで350社以上のご支援を行ってきました。この最初のターゲット設計の工程を省略したまま架電を始めてしまい、1ヶ月後に「リストが枯れた」「アポの質が低い」という状態に陥るパターンを何度も見てきました。

2週目：スクリプトと接触シーケンスの設計

メッセージは「サービスの説明」ではなく、相手が抱えているであろう課題の自覚を促す設計にします。第三者話法（同業他社での事例をヒントにした問いかけ）や、今変化が起きている理由（Why Now）を先に示す構成が機能しやすいです。

接触は1チャネル・1タッチで判断しません。電話・メール・フォームなどを組み合わせ、7〜12タッチを想定したシーケンスを事前に設計します。「1回かけてつながらなかったから次のリストへ」では、到達率が上がりません。

3週目：実行とログの取り方を固める

架電・アウトリーチを開始します。ここで押さえておきたいのは「アポが取れたかどうか」より、「なぜ断られたのか」「どの表現に反応があったか」を毎日ログに残すことです。断られた理由を「今は必要ない」「他社を使っている」「そもそも課題がない」の3分類で記録するだけで、次週の設計が変わります。

リストは在庫です。1件の接触から「次の一手が決まる事実を1つ持ち帰る」というルールを設けることで、断られた架電も情報資産になります。

4週目：初回レビューと仮説の修正

3週間分のログをもとに、最初に立てたターゲットとメッセージの仮説を検証します。「接続はできているのにアポにならない」なら訴求のズレ、「そもそも接続できない」ならリストの精度か時間帯の問題、「アポは取れるが商談にならない」ならターゲット自体のズレという形で原因が分類できます。

この4週目に出てくるのは「アポが何件取れたか」ではなく「どの仮説が外れていたか」が、BDRを機能させるための最初の成果です。

振り返りの方法｜週次と月次で見る指標を分ける

BDRの改善は、短期と中期で見る指標が違います。週次で全指標を追おうとすると、動きが多すぎて何が変わったのかわからなくなります。

振り返りの週次・月次の使い分け

短期と中期で見る指標を分けて運用する

観点	週次レビュー	月次レビュー
主な目的	活動量と歩留まりの確認	ターゲット仮説の精度検証
確認する指標	架電数・接続率・アポ転換率	セグメント別のアポ転換率・断られた理由の分布
アウトプット	翌週に変える変数を1つ決める	翌月のリスト精査・訴求方向の修正
陥りやすい罠	数字の増減だけ見て「もっと架電」になる	指標が多すぎて何を変えるか決まらない

週次で見る指標

週次で確認するのは「活動量と歩留まり」です。架電件数・接続件数・接続率・アポ件数・接続からのアポ転換率を並べ、前週と比較します。ここで大きな変化があれば、その週に何を変えたかを確認します。スクリプトを変えた、ターゲットを絞った、時間帯を変えた――変数を1つずつ変えてログを取ることで、改善の因果が特定できます。

月次で見る指標

月次で確認するのは「ターゲット仮説の精度」です。アポが取れた企業の業界・規模・役職・トリガーと、断られた企業のそれを並べて共通因子を探します。「このセグメントからのアポ転換率が高い」という発見が、翌月のリスト精査とメッセージの方向修正に使えます。

月次レビューで見てほしいのは「アポ数が目標に対して何件か」ではなく「どのセグメントで仮説が当たっていたか」です。数字の増減だけ見ると、「もっと架電を増やす」という結論しか出ません。

Q. BDR体制を1人で始めることはできますか？

可能ですが、「設計・実行・改善管理」の3機能を1人でカバーする場合、週の使い方を意図的に分けることが前提になります。毎日架電だけしていると実行に追われて設計が止まり、3週目以降に失速するケースが多いです。1人体制であれば、週に1日は「設計と振り返りの日」として架電をせずにログを読む時間を確保することをすすめています。BDR KPIの設計と成果の見方もあわせて参照してください。

Q. 外部の営業代行を使う場合、体制設計はどこまで自社でやるべきですか？

ターゲット設計とトリガーの定義は、自社で仮説を持った上で代行会社と擦り合わせることが前提です。「誰に売りたいか」の解像度が低いまま丸投げすると、代行会社は汎用的なスクリプトで量をこなす運用になりやすく、断られた理由が蓄積されません。改善のループを回すためのログの共有方法と、週次レポートの項目設計は契約前に確認することをすすめています。BDR 新規開拓の体制設計に詳しい設計例をまとめています。

BDR体制でよくある3つの失敗パターン

体制を作ったあとに失速する場合、原因はほぼ3パターンに収束します。

BDRで失速する3つの原因

体制を作ったあとに起きやすい落とし穴

• ターゲットがセグメントだけで終わっている：業界×規模の定義にトリガーが加わっていないと、同セグメント内で反応率の差が説明できない
• ログが「取れた・取れなかった」の2択だけ：断られた理由の分類がないと改善がスクリプト修正だけになり、ターゲットとタイミングの問題が見えない
• 週次レビューが報告会で終わる：数字を並べるだけで「何を変えるか」を決めずに終わると、翌週の動きが変わらず改善が止まる

1. ターゲットが「業界×規模」だけで終わっている

「製造業の300名以上」のような定義では、同じセグメントの中で「今動けている企業」と「今は動けない企業」が混在しています。トリガー（組織変更・採用増加・新規事業など、相手に変化が起きているサイン）を加えることで、接触の反応率が変わります。

2. ログが「アポ取れた・取れなかった」の2択しかない

アポが取れなかった架電も、「今は予算がない」「他社で検討中」「課題を感じていない」によって次の打ち手が全く違います。断られた理由の分類がないと、改善が「スクリプトを磨く」だけになり、ターゲットやタイミングの問題が見えません。

3. 週次レビューが「報告会」になっている

数字を並べて「先週は〇件でした」で終わるレビューは、次の1週間の動きが変わりません。「この数字の変化から何を変えるか」まで決めることがレビューの目的です。変更する仮説（ターゲット・メッセージ・チャネル・時間帯のどれを変えるか）を1つ決めて終わることを習慣にします。

体制が整ったあとの次のステップ

最初の30日間を経て体制の型ができたら、次は「当たっているセグメントへの集中」と「引き継ぎ先（インサイドセールス・フィールドセールス）との連携設計」に移ります。BDRが商談を作れても、その後の受け取り方が整っていないと商談化率が低下します。

IS/FSへの引き継ぎ基準、商談後のフィードバックをBDRに戻す仕組みは、BDR体制が安定してから設計するより、立ち上げ段階から並行して整えておくほうが後の手戻りが少なくなります。フィールドセールスのフィードバックをISに還元する方法もあわせて参照してください。

アウトバウンドの体制構築・改善を外部から支援してほしい場合は、お問い合わせからご相談ください。ターゲット設計から実行・改善管理まで一気通貫で伴走します。