SES営業って特殊な職種だよね。

SES営業は営業的なスキルの差が出づらい職種です。トークよりは動きの質や方針が影響しますし、それ以前に、自社の良い商流やリソースを使用できるかどうかでも大きく有利・不利が発生します。この辺は能力の問題ではありません。

基本的には『決まる案件』の確保と、『逃げないリソース』の確保。これが安定して数字を上げる為の必要条件です。2つが揃っている状態でスタートできるならば、かなりのボンクラでも数字が上がります。数字が逃げないので、別の部分。（エンジニアのキャリアなど）が優先になることもありますね。このあたりは会社の方針が強く影響することでしょう。

『案件』『リソース』の２つの要素のうち、『リソース』は、特に入社直後には触らせてもらえないことが多いかと思います。ふつうは社内での信用がない状態でスタートする上、既存営業経由の既存取引先への信頼や立場もあります。リソースが確保できないのはどうにもならない部分と言えるかと思います。しかし、『案件』は別で、外部から獲得してくることが可能です。

外部から確保できるリソースはあくまで『逃げるリソース』となりますので、これに『決まりづらい案件』を組み合わせますと、全く決まらない状態が発生しがち。リソースはどうにもならない以上、『決まる案件』の確保が最重要となります。このような『決まる案件』を確保し続ければ、自社リソースを決定するタイミングも生まれますし、案件や商流の背景を説明できれば、この案件を優先すべきであると自社への説得要素も得られます。自社への信用獲得にも有利と言う事ですね。

また、営業間で『信用』が効く職種でもあります。寺野がSESやってたのは15年ほど前ですが、だいたい15％～20％くらい存在する、『話が通じる営業』同士がネットワークを作っていた印象です。営業間の信用のほか、営業＝エンジニア間の信用もありますので、本来は雑な営業はできない仕事です。そうなりますと付き合う営業も信用できる人物である必要があり、そういう営業達が自然と結合していったという感じではないかと思います。

今現在のSES界隈でこういう優秀勢ネットワークがあるのかはわかりませんが、エンジニアや他社の営業さんからの信用を得るべきと考えるならば、雑な営業とみられるムーブは避けることになるかと思いますし、案件情報の内容を把握・説明できる必要が出てくるかと思います。
勧めたい案件の内容を説明できないんじゃ、介在価値が皆無ですしね。

このような具体的な案件・情報を得るには、決済権を持っている人物・チームに対して浅い商流で刺さる必要があります。1人・1チームから多数の募集が出てくることもそうありませんので、1社あれば必要な案件数が確保できるという事でもありません。このような『具体的な案件』を出してくれるクライアントを複数社確保。信用を維持し、常に具体的な案件がいくつか手元にある状態を作ることが肝要かと思います。

さて、BAMVは少数の『具体的な案件』の確保に向くタイプの開発ベンダーです。

案件の確度を生むもの

確度が高いとか低いとかよく言われる割に、なにが案件の確度を生んでいるのか、詳しい説明とかあまり聞こえてこないですよね。SES界隈では『実績あります！』とか、『先週決まりました！』みたいな感じで、営業の感覚で語られていることが多い気がします。実際にはいくつかの要素が絡んでいるものであると考えます。

1.商流の深さ・情報がゆがまないこと

当たり前ですね。商流が深いと中間会社の営業の数が増えます。この中の一人がボンクラであれば、そこで情報の正確性は失われます。ボンクラは自身の目先の利益のために平気でウソもつきますので、最初っから進められない話で時間を取られるなどということも起きますし、なにより案件参画後に『聞いてた話と違うんだけど』も多発します。　この『聞いてた話と違うんだけど』問題は、プロジェクトから自身までの間からボンクラを排除することによって劇的に改善します。

実際、仮に商流が深い場合でも、ボンクラが存在しない商流ではスムーズに事が運びます。まあ、あえて深くする人もいないんだけどね。15～20％の優秀勢だけで深い商流を構成すると言う事はほとんどないですから。

2.購買・人事発の案件情報ではないこと

ここ大事です。この時点でプロジェクト側の募集ニーズとの間に一人挟まってしまいます。大きな会社では多数の募集が発生しますので、購買の方がすべてを把握するのは困難です。それもあってか経歴書での足切りラインが設定されることもあり、SES市場内の右から左の情報に近いことになります。また、ベンチャー企業の場合も人事担当者が外部パートナーの窓口を兼ねるパターンが多くなりますが、このパターンも決まりづらいです。人事担当者は継続的に雇用する人員向けの求人情報を持っている人物です。個々のプロジェクトで起きていることや想定作業、必要とされるスキルなどは把握していないことがほとんどです。結果、よくメールで流れてくる80万くらいでやたらめったらフルスタックな要求の随時～長期の募集案件が発生します。（だいたい採用サイト上の求人をコピペしただけのもの）この案件はその時のプロジェクト側の実情を反映しておらず、100％条件を満たしているエンジニアでも落ちることもあれば、ぜんぜん満たしていないエンジニアでも決定することがあります。人材紹介やフリーランスのエージェントを兼業している右から左のメインのSES会社の案件はこのようなものが多くなる印象です。
単価感もガバいので、おかしな高額が出たりもします。営業としては変に期待はせず（エンジニアにもさせず）『とりあえず出しとくか』くらいの扱いにとどめ、『これは商流浅いから堅い！』とか言わない方が良いです。

3.増員に直接関与している人物・会社からの情報であること

と言う訳で、こうなります。エンドの内製チームであれ、外部ベンダーであれ、そのリーダー役と営業が直接やり取りしていること。

極めて重要な要素として、この際、そのリーダー役は下記の図の左側のチームの様に、メンバーに対してタスクを振り分ける側の立場を抑えている必要があります。タスクを振り、成果物をレビューする立場であるからこそ、新規参入メンバーへ振るタスクの粒度をコントロールすることができ、また、成果物に責任を持つことができます。この立場でない場合、新規参入者の募集要件を下げることができません。

募集の要件を下げることができない場合、【助けなくても一人で成果を出せる人】が採用要件になりますので、だいたい基本設計者以降の経験者。俗にいう一人称で作業できる人の募集になってしまいます。世の中の大概の募集がこのタイプの募集になりますので、競合多数となり、『リソースが逃げる』が発生します。これでは数字になりづらいです。

つまり、チームでやってますという話だけでは不足なのです。

この話は、営業だけではなく、

応募先を検討するエンジニアにとっても重要な情報

です。いわゆる基本設計者以降の経験者に満たない経歴のエンジニアの場合は、自社がこのような体制を作れるかどうかでアサイン可能先の質が大幅に変わります。未経験者などに至っては、このような体制を取っている会社か。信頼関係のある会社にこのような会社があるか。によって、開発経験ができるプロジェクトに入れるかどうかがほぼ決まります。

4.計画的な増員であること

特にウォーターフォールモデルでの開発プロジェクトにおいて発生する話ですが、上流の時点で事前に増員が計画されています。この増員を事前に抑えてしまうのはとても有効で、かなり採用ハードルが下がる印象です。

増員のタイミングは、基本設計スタート、基本設計の終盤(PGフェーズの増員と言える。)のあたりが多いです。基本設計スタートあたりは2次請の社員がメインとなるかと思いますが、PGフェーズでは3次請以降のPGメンバーも入ります。　この際、上流で体制を組んでいる2次請が募集をすることになりますので、この案件を狙うならば営業先は1次請ではなく2次請側と言う事になります。

募集をかける2次請側も他社のPGを手取り足取り面倒見たいわけではありませんので、この時は【PG部隊をチームでほしがる】需要になります。PGリーダーとメンバーの構成で取りに行くことになる訳ですが、この時、メンバー側の要求スキルはかなり低くなります。　3次チーム内で面倒が見れればOKと言う事ですね。

このようなチーム受注の案件は、通常は数か月前から枠を取りに行くことが多いです。（増員がギリギリまでふわっとしたまま決まらず、結局前月にかき集めるなんてこともありますが）案件情報として世に出てくるのを待つのでは、とりっぱぐれることが多くなります。

世のプロジェクトがすべてこのタイプであるという事はありませんので、事前につかんでおく。把握しておくというのが重要になります。（1件2件でもリソース側のタイミングが合わなくなるので、ある程度の数を確保しておくのが良いと思う。）

BAMVの案件を推しておく

と言う訳で、まあ本題なんだけども。

ウチの案件は、いいぞ！　と言いたいわけですな。

とは言え、常に100点満たしているかと言うとそうでもありません。だいたいざっくりの構造からご説明できればと思います。

まず商流

エンドユーザー複数社と、大手SIerの案件が中心になりますな。

大手SIって人によって定義が違いますが、ここでは基本的に資本金100億以上くらいのプライマリーしかやらない会社の事をイメージして話をしています。
もうウチの規模だとね、ある程度体制組んで複数プロジェクトを担当となった時点で会社の売上の半分以上と言う物量になりますから、他の大手SIを開拓したとて、リソース不足になることが見えています。もうしばらくは現在の取引先を集中的に開拓する感じになりますねえ。

ただしBAMVの技術スタックはわりと新しい技術に偏っており、仕事もSIビジネスのメインストリームあたりの需要とは異なっています。ですので、少し案件情報がSIらしくなかったりはします。大規模なシステムを中長期にわたって保守・運用していくであったり、超大規模な基幹システムを構築するとかの話はあまりなく、いままではWebサービスの話が多かったりしますし、今後はAIと連携したシステムの開発の話などが増えていくのでしょう。

ああ、カネ？まあ、いいほうじゃないかなあ。怪しい釣り案件とかには負けるんだろうけどね。アレを事実として比較するのもアホやと思うし。

開発体制

話の流れからも当然ですが、こちら側を理想とします。

BAMVが自社で責任を負える体制を取り、なるべく丸投げに近い状態でも問題なく処理できるようにする。クライアントはチームの管理にスキルや工数を割かずともよく、安心して任せられる。チームは継続性を生むためにも継続的に運用コストの低減や品質の向上に取り組む。こうすることによって、メンバーの入れ替え時のコストも下がり、属人性も低下。クライアントは安定的なコスト・生産性で開発チームのリソースを利用でき、BAMV側もチーム体制の維持・人員の育成なども行う事ができるようになります。

この状態は各関係者間の利害関係が一致しており、とても理想的な状態であると言えます。

まあ、あくまで理想っすね。常にここに持っていけるわけではないです。

クライアント側も文化や考え方がありますし、エンドユーザーに至ってはそもそもベンダーではないですから、初取引のベンダーとの利害一致点などが最初から分かってる訳が無いです。説得でご理解いただけることもありますし、難しいというケースもあります。また、BAMV側のスキル不足と言う事も起きるでしょう。テクニカル面・プロジェクト運営面・上記のような中長期的な組織運営の面でのノウハウ。チームは多くの資質を要求され、常に100点のアウトプットを出すことができるという事はありません。（だって人間やし。）

ですが、なるべく『理想の状態』を増やすのが経営努力かなと思っています。

SES営業さんから見たときの利点

さて、要はこの体制の話は、前項の3.増員に直接関与している人物・会社からの情報であることで、説明したメリットを生む活動です。
リーダーがタスクを割り、既存メンバーで難易度の高い部分を担当することによって、【ハードルが低い作業】を生み出すことができます。これにより、増員枠の要求ハードルを下げることができる様になります。

このような方法を取らずに、ただ単に外部へ増員情報を吐き出すだけでは、クライアントもこのチームへの増員アサインを優先する理由がありません。一人称で設計から担当できる問題の無い人と言う量産型の案件が各商流へ分散されるだけですね。もともと助け合いも無いチームであれば、他の商流からフリーランスを一名投入でも構いません。

”理想的な”チームは、【このチームが増員枠を握っている】【このチームへの増員ならばアサインハードルが低い】といった状態を作り出すことができ、確度の上昇と、質の良い案件を発生させることができます。　なにしろ、市場の競争にさらされていないですからね。　質の良い案件は椅子取りゲームで真っ先に埋まってしまう。経歴・商流が上の相手に取られてしまうということがまず発生しません。

案件数

ぶっちゃけ多くないです。中間専門の営業会社ライクに右から左をやれば2000件3000件と言う話になるでしょうが、我々のような業態はそれと比較して案件数自体はとても少なくなります。ウチの規模だとだいたい1～３件くらい抱えてるタイミングが多いんじゃないかと思います。っていうか、チームでやってる会社がチーム数以上に案件持ってたらおかしいじゃないですか。

ガバい話、SI界隈とSES界隈は下記の図のような構造になっていまして、

ゾーンごとにビジネスモデルが異なっています。

SI・下請ゾーンの会社は、『システム開発』でメシを食う訳ですので、『システム開発』のプロジェクトに会社として参加し、責任を負います。その結果、プロジェクトごとの成功の為に増員の需要が発生します。　カネは結局クライアントから出ていますので、彼らは【外部人員のアサイン枠を確保することによって儲ける】ビジネスと言えます。
しかし、人数はともかくとして、担当プロジェクト数以上の案件数は発生しません。

中間(営業)SESゾーンの会社は、営業力で勝負。エンジニアをほとんど雇わない会社も存在します。自社のエンジニアがプロジェクトに参加していない状態（サポートが無い状態）であっても、外部パートナー人員を案件にアサインする必要がありますので、案件は質より量。さらに言えば、再委託制限の回避が最重要となります。Webサービス運営エンドなどが中心だったはずです。（今はきつそう）

『雇う』SESゾーンの会社は、頭数で勝負。上の会社群が、外部人員を多数稼動させて総稼働数を確保するのに対して、この層の企業群は、雇う事によって総稼働数を確保します。

BAMVは現状、SI・下請ゾーンのビジネスモデルと言え、ゆえに案件数は限定的になります。この層の案件は、所属している社員のスキルセットや専門領域に偏ることに（だって参加するプロジェクトの案件になるじゃん）なりますので、SES営業がBAMV一社で数字をまとめると言うのは現実的ではないと思います。BAMVとは異なるSI・下請ゾーンの会社の案件も並行で収集することで、確度が高い案件で、幅・チャンス数を確保することができる感じかなと。

タイミング

まあ、お互いそうそう合わないはずなんですよね。そもそもまっとうなエンジニアが遊んでますと言う状況はまあまあ異常事態ですし。BAMV側も常時多数の案件追っかけてますというスタンスではありませんので。

たまたまやり取りした時に即スタートなどはまずないので、平時のうちにやり取りを開始しておければ一番良いのかなと思います。BAMVは商流や業態のワリに、かなり小さいベンダーになるかと思いますので、問い合わせしてみる心理的ハードルもかなり少ないでしょう。

おわりに

とまあ、自社のブログですので、がっつりポジショントークと言うか、SES営業さん向けの会社案内的なモノを作ってみました。

ほか、新卒学生の業界研究や、まだ業界を把握できていない若いエンジニアさん。新人のSES営業さん。いろんな方に参考にしていただける様な内容になったんじゃあるまいか。

お問い合わせなどは、下記のフォーム

https://blog.bamv.co.jp/contact

またはコーポレートサイトの問い合わせなどからいただけますと幸いです。

そのほか、SNSなどで拡散してくれた方々。あーしゃす。