ITエンジニアがインサイドセールスの白本読んでみた①
こんにちは。のんです。
今回から、スマレジの営業さんからお貸しいただいた「インサイドセールス」を読んでいこうと思います。
いえーい！
— のん🐘夜型言語 (@nonz250) August 2, 2021
インサイドセールスについて呟いたら、 @Mar_Cyyy さんが本を貸してくれました！😊
スマレジはインサイドセールスにも力を入れています！ pic.twitter.com/ejVLBxvAaM
あくまでも私主観での「感想」に近い感じで書きたい。
やはり本である以上、そのまま丸写し、よくない。良いか悪いかは置いておいて私主観の感想を述べる感じになります。
エンジニアがインサイドセールスについて知ったらこういう事考えるんだなぁ...くらいに考えてください。
具体的な内容が知りたい方は実際に購入しましょう！
Amazonのリンクです。アフィではないので安心して踏んでください。
まずはどの本にもある、インサイドセールスとは？ですね。
インサイドセールスの3つの役割
- SDR（Sales Development Representative）
- BDR（Business Development Representative）
- Online Sales
この業界にもDevelopmentという言葉が出てくるんですね。
確かに大型ショッピングモールのオーナーになったりする人のことをデベロッパーと呼んでいる営業さんを見たことがあります。モノづくり出身の私からすると目からウロコというか、市場を開拓するという意味でDevelopmentなのでしょうか。
問い合わせやイベントから商談を作るSDR
基本的には短期間で商談機会の獲得を目指しますが、場合によっていは複数回、長期間にわたって見込み顧客との関係性を構築し、必要な条件とタイミングが揃った時点で商談の日程を打診、調整完了後に営業へ引き継ぎます。
営業へ引き継ぎます。ということはSDRは営業では無いんですね。。。
営業をプログラマーと考えるなら、戦略や設計を行うSEに近いのでしょうか？しかもどちらかというと、要望開発に近い。完全請負は次のBDRな気がするので、多分そんな気がする。
ちなみに、BANT情報というのは知りませんでした。
ターゲット企業を選定し戦略的に商談獲得を狙うBDR
ターゲット企業を選定し、場合によっては同一企業内で複数の商談機会を獲得すること
こちらもSEですが、大企業を相手取るコンサルタントに近いイメージ。それこそSIerに近いと思いました。もちろん、商談を開拓するのかシステムを開拓するのかの違いはありますが、振る舞いは似ているのかも...？読み始めたばかりなので、これから楽しみ。
将を射んと欲すれば先ず馬を射よ。ではなく、将を射んと欲しているから将を射よ。って感じ。自分好み。
当たれば天国、外せば地獄とも思いました。SIerのノウハウが活きそうｗ
基本的にSDRを主戦力に置くイメージ？
非対面で成約まで完結させるOnline Sales
オンライン商談の特徴はなんと言ってもその生産性の高さです。
これはずっと思っていました。営業はしたこと無いのでなんとも言えませんが、個人開発などしている方を多く見てきたので、オンライン会議に限らず営業する方法はたくさんあるのになぁとは思っていました。
こう考えると、コロナというのは良いのか悪いのかわからないですね。
正直、SDRやBDR云々よりこれが一番大きいのでは？？
インサイドセールス3つの配置タイプ
商談のパスだけを行う分業タイプ
SDRとBDRだけを配置するタイプ。
最大のメリットは生産性の向上ですが、一方でキャリアを描きにくくスキルアップの機会が少ないのではないかという意見もある。
SEとプログラマーが完全に別れているようなものでしょうか？
SEは要件定義や設計のみ。プログラマーはプログラミングのみを行うような感じ？
商談の成約までを完結する独立タイプ
SDR + BDR ＋ Online Salesの全てを配置するタイプ。
メリットは全てを配置するので、自社部門で全てをまかなえるということ。
デメリットは教育コストの増大と採用コストが上がること。なんなら人材の獲得も挙がりそう？
どの業界でもこれが理想系かもですよね。
SE、UI、UX、App、Back、Front、Infra...全部ほしーｗｗ
ターゲット企業の規模や地域によって分ける混合タイプ
メリットは状況に合わせた対応が可能になること。
デメリットは業務や予算策定における設計難易度が圧倒的に高いということです。
ターゲット企業だけでなく、自社の都合もありそうですよね。人員が少ないとかで分業や独立タイプを選択できないときに選ばざるを得ないときに採用しそう。
セールスのシステム化を目指しているのに、これを採用するメリットはあまりなさそう。
ここまでで第一章の内容に出てくるキーワードをまとめました。
セールスという枠の中で、営業とは違う部門を作って役割分担をして、よりシステマチックにセールをかけるための部門という印象が強いですね。
私の業界ではフルスタックエンジニアと呼ばれるようになって久しいですが、これを現実にしようとすると課題は山積みで、結局「雑用エンジニア」になってしまうことも少なくありません。実際にフルスタックエンジニアを実現できている方はすごい方ばかりです。
これを避けるために、単にエンジニア、プログラマーと分けるのではなく、インフラエンジニア、バックエンド、フロントエンド...etc。とわけることで、特化した技術を習得し、自分には無い能力を補うためにチームビルディングでグラデーション的にカバーする（スクラム開発）というのが最近の主流です。
私はこれまで、セールスのことを勉強してこなかったので、何もわかっていませんでしたが、セールスにも似たような考え方がありそうです。
上記から、「SDRだから」、「BDRだから」、「インサイドセールスだから」「営業だから」と縦に分けるのではなく、担当を分けた上で、チームに所属するメンバーとして、SDRとしての能力を存分に活かす...のような運用方法の方がこの考えを導入するメリットを最大限活かすことができる、スクラム風な運用ができると考えました。......違う畑から見た感想ですが😅
まだ採用の章は読んでないのでなんとも言えませんが、今後の採用は「営業職募集！！」ではなく、このような「〇〇セールス募集！!」みたいに明確にわけるのが常識になるのかもとも思いました。（もうなってる？セールスエンジニアとは違う意味で言いました。）
最後に
今回は違う畑の専門書を読んでみました。
読んでいて思ったのは、エンジニア視点で書いた白本の感想というのは意外に少なくないのかも...
考え方がエンジニアのチームビルディングとの共通点が多い。
多分ですが、すでに既存のエンジニアも興味をもって読んでいる可能性があると思いました。
この本は借り物なので、連載できるかはわかりませんが、引き続き読んで記事にしていきたいと思います！
その時はよしなに。
.
