見出し画像

開発営業はツライよ、というお話

久松剛／IT百物語の蒐集家

ITエンジニア職と営業職。全くもって適性が異なる職種である一方で、協調しないと炎上するという非常に厄介な側面があります。SIerはもちろんのこと、自社サービスでも（受託開発ほどではないですが）売り上げが上下した際の功績や責任の範囲を巡っての諍いがあったりします。また、toBシステムで一部顧客に対するカスタマイズ要件が入ると、自社サービスであっても受託開発と似た悩みが発生します。

こうした背景もあり、「技術に現役感があって手が動き、コミュニケーションが取れて、プロジェクトマネージメントができ、尚且つ営業ができる人材が欲しい」というリッチすぎる採用のご相談を頂くことも出てきました。この相談に対する回答としては「居なくはない。見たことはある。ただ見つかったとしても、御社に入社する理由が乏しいですし、離職されると痛すぎるので要件を分割しましょう」なのですが、どうもこの開発と営業の境目については言及しておく必要があると感じています。今回は以前のコンテンツでも少し紹介したのですが、SIerやオフショア開発などに見られる請負・準委任契約による開発の営業は何故大変なのかについてお話しします。

私は前職でエンジニアリングマネージャーとして入社したのですが、いつしかプロジェクトマネージャーを兼務し、更にはいつの間にかアカウントプランニングやアカウントマネージメントを担当していました。今は独立して営業活動することも増えています。これらの経験も踏まえてお話をします。

本コンテンツの想定される読み方としては下記です。

  • 経営サイド

    • 営業と開発の溝の理解

    • 開発営業担当者の採用と育成のヒント

  • 開発サイド

    • 営業サイドへの理解

  • 営業サイド

    • 開発サイドへの理解

  • 現在転職活動中の方

    • 企業選びに「営業力」という観点の追加

有料設定していますが、最後まで無料でお読みいただけます。もしよければ投げ銭感覚で応援をお願い致します。


開発と営業の概要

いわゆる企業からの開発案件が入ってくる経路としては4つあります。

インバウンド

発注元となる企業が意思を持って検索し、見積もり依頼が来るタイプのものです。例えば私の場合はこのnoteやTwitterを見てお問い合わせ頂くことが多いです。

この際、問い合わせをしたいと発注元企業に思わせる何かがあることが重要になります。発注元企業が意思を持って問い合わせをしているので、作りたいものや予算計画があることが多いです。もちろん予算が見合わないことや、予算獲得のための参考にするための問い合わせも少なくありません。しかし、ある程度まとまった数のインバウンド問い合わせがあると質の良い案件にも出会えるためお断りしやすく、一般的に受注する側が優位です。

アウトバウンド

受注する側の企業が「何かお仕事ありませんかね？」と問い合わせる形態です。メールや電話だったりします。発注する側としては想定外の問い合わせであることが多いことから、ちょうど良い感じに発注したい状態にあるプロジェクトに当たるまで数を打つ必要があります。

また、「何かお仕事ありませんかね？」と受注側企業から問い合わせをしているので、発注する側が優位になりやすいです。

営業紹介会社、マッチングサービス

フリーランスの場合はフリーランスエージェントに相当しますが、企業間でも発注したい企業と、受注したい企業のマッチングをする仲介会社があります。料金体系は定額型だったり、成果報酬型だったりします。

顔合わせはできるのですが、発注したい企業側の意向が高くないことが多く、個人的には「顔合わせ」で終了するイメージです。発注したい企業側のリストが窓口のメールアドレスを知っているだけのケースもあり、連絡したら怒られたこともあります。

友人知人からの紹介

営業版のリファラルです。予算が見合うかどうかは別問題ですが、発注する側と受注する側が最も対等になれる関係であり、契約や座組など調整がしやすい傾向にあります。

この友人知人の関係の深さもポイントです。個人的には名刺交換会やゴルフなどによる繋がりは営業活動という点ではリファラルのような対等な関係にはならず、アウトバウンドに似たアプローチであると捉えています。

開発営業担当の難しさ

次に開発営業の難しさについてお話ししていきます。

SIerの営業とSES・フリーランス営業との違い

世間にSESやフリーランス紹介の企業が数多く登場しています。SESやフリーランスの場合は、基本的にはスキル要件（プログラミング言語、フレームワーク、経験レベル）が合致し、紹介する人物がヒトとして問題なければマッチングします。その後の契約も30分から60分の面談で終了するので早いものです。プログラミング言語とフレームワークの技術用語がヒアリングできれば、それを元にキーワード検索する形になるので、それぞれのスキルが何であるかまで深く知らなくても概ね問題なく営業活動ができます。逆に言うと、深い技術的な相談を顧客がしようとすると詰まる営業が多いというのも事実です。このあたりが上手くコミュニケーションができたり相談できるようになると、SESから更に単価の高い案件になり得ます。

一方、SIのような開発案件の場合、既に開発体制は自社内にある状態で、その体制で実現できる範囲のものに商談をまとめる必要があります。当初の合意内容は大筋でズレるものなので、できれば準委任契約でしたいところですが、なかなか飲んでくれる発注企業さんは見つかりません。余裕を見た見積もりを出したところで「QCD（Quality, Cost, Delivery）に見合わない」と難色を示されることは多いです。受注側企業としては製造部分は請負で、要件定義とテストフェーズだけ準委任契約で着地を試みるのですが、ここで先のインバウンドかアウトバウンドかリファラルかのパワーバランスが効いてきます。

個人的には発注者優位の開発受注の調整は二度とやりたくないものの一つです。

営業職はウリが伝えられないと中途入社しない

ではしっかりとした売り込める営業が居ると解決かというと、そういう営業職は少ないです。

私も営業職の方とはよくお話しさせて頂きますし、キャリア相談も頂くのですが、基本的な思想としては成果報酬を期待する傾向にあります。これは新卒採用された際の企業文化にも関わるのですが、しっかり売った時はしっかりとボーナスで評価されたいという傾向にあります。

その観点からすると、「弊社は開発ができます」というSIの場合、強く売り込める商品であるコアコンピタンスがあるわけでもなく、業界で有名な得意分野も無いとなると何が売れるのかが分かりません。何でも受注してしまうと開発の段階で炎上します。

非常に売りにくい商材が純粋な開発案件であるため、中途採用はITエンジニア以上に採用しにくいと捉えています。

「エンジニアが営業職を兼ねれば良い」説

開発営業担当の採用が難しいとなると、冒頭にお話ししたような「営業もエンジニアにさせよう」となります。

エンジニアと営業職の兼務が難しい理由として、最低でも次の要素が必要なのではないかと感じています。

営業パイプラインの概念

一介のエンジニアであれば（単位の妥当性の議論は置いておいて）1ヶ月の稼働は1.0人月に止めたいと思うものです。それでも尚、炎上やリリースであれば残業が発生する可能性はあります。

これが営業観点で行くと、プロジェクトの終了を見越して空白期間ができないように備えたいと思うようになります。いわゆる「仕込み」な訳ですが仕込みのためには今の案件を手がけながら（なんなら納品に向けての追い込みを掛けながら）、次の顧客に向けてヒアリングをしたり見積もりをしたりすることを並行しなければなりません。どうしてもオーバーワークになりがちです。

ここまではまだ理解できるのですが、実際に直面する壁が「思ったように決まらない案件」です。見込み顧客のプールから始まり、見積もり、コンペ、契約に至るまで掘り下げていくことになります。図にすると下記のSales Dashboardになります。この契約に至るまでのOpporttunity Pipelineが存外に長いことが多いのが辛いところであり、アウトプットだけ気にする経営者や、一介のエンジニアからは見えにくいところでもあります。

エンジニアはフラれなれていない

一般的な上流工程は社外であれ、社内であれ顧客が定義された状態、つまり「この人とコミュニケーションを取ってください」という状態から案件がスタートします。

一方で営業に関わると顧客が定義される前の段階なので、当然「失注」と対峙することになります。最初の顔合わせで（何を言ってるんだ・・・）という方と顔を合わせることには割とすぐに慣れますが、コンペなどまで行って盛り上がり、担当者OKが出たにも関わらず先方稟議などで最後に覆るときの衝撃は酷いものです。「私のこと、好きって言ったじゃない」という点では失恋に等しい衝撃があります。合理的に考える人ほどこの衝撃は大きく、そう簡単には慣れません。

個人的にはこのあたりの感覚にアタリがついたので、独立に踏ん切りがつきました。契約するまで期待せず、継続して他を当たるということができるようになりました。

多重請負という選択肢

世間的に嫌われ、時として違法性も疑われるのが多重請負の構図です。ITに限らず、多重請負は中抜きに見えるためお金の流れ的に忌避される傾向にあります。

営業の仕方が分からなかったり、実績として著名な顧客の名前を言えるような合意がなされていなかったり、企業ブランドが弱いとなかなか一次請け案件は決まりません。

質の良い案件を契約したいのはやまやまですが、その一方で正社員雇用していると彼らの給与は発生するため、待機になると赤字になります。大手企業であればそれを見越した資金運営ができますが、中小は厳しいです。結果、藁をも掴みたくなり、二次請け以下でも受注してしまうというものです。

積極的に肯定したくはありませんし、商流だけを見ると全く合理的ではありませんが、まさに営業と経営の観点からやむを得ず選択してしまうのが多重請負構造なのではないかと捉えています。人材の流動化が進んでいる現在、1雇用者の観点では多重請負が嫌であれば営業力が高い企業や、待機を許容できる企業に転職すれば良いという話になるでしょう。

開発営業はエンジニア以上に居ない説

「開発を請け負う企業というのは何かしらに尖って有名にならないと優位には立ち振る舞えない」ということを骨身に沁みて感じています。もしこれを読んでいるSIerの方などで素晴らしい営業力を持っておられる方が社内に居れば、是非いたわって上げてください。

noteやTwitterには書けないことや個別相談、質問回答などを週一のウェビナーとテキストで展開しています。経験者エンジニア、人材紹介、人事の方などにご参加いただいています。参加者の属性としてはかなり珍しいコミュニティだと思っています。ウェビナーアーカイブの限定公開なども実施しています。

執筆の励みになりますので、記事を気に入って頂けましたらAmazonウィッシュリストをクリックして頂ければ幸いです。


ここから先は

0字

¥ 500

頂いたサポートは執筆・業務を支えるガジェット類に昇華されます！