SES営業にエンジニア経験は必要か
こんにちは、代表の三坂です。
昨日、一昨日の土日は、久しぶりにがっつり仕事をしました。最近はどちらか１日は趣味の時間にあてたりとしていますが、土日ともにしっかり仕事したのは久しぶりです。ふと自分の中でアイデアが下りてくることが多々あり、そのスイッチが入ると調査、計画、利益等一気に調べ上げ、アクションにうつすかどうか決めます。ほとんどが採用されませんが。ただこの習慣が昔からなぜか染み付いており、100回に１回は会社の業績に大きくかかわるアイデアが出てきたりします。続けて頑張っていれば必ず良いことがあると信じてやれているのは自分の行動を振り返るようにしているからかもしれません。ぜひみなさんも日報などで自信の行動を振り返り、たまには自分自身を素敵な勘違いさせてあげましょう。自己プロデュース、大事です。
さて、日々いろんなテーマで発信していますが、今回は「営業はエンジニア経験が必要か？」という問いについてです。先に結論申し上げると、答えはシンプルに「必要」です。なぜそう言い切れるのか、実体験を交えてお話します。
営業にエンジニア経験って本当に必要？
その問いに対して、私は迷いなく「必要だ」と言いたい。様々な意見があると思います。あくまでぼく個人の見解です。特にSES業界や受託開発のように、技術者と企業を結ぶ仕事をする営業であれば、なおさら必要だと思います。
なぜなら、エンジニア経験のある営業は、ただ案件を紹介するのではなく、“現場のリアル”を理解した上で、エンジニアのキャリアを前に進める提案ができるからです。
では、なぜそれほどまでにエンジニア経験が営業にとって有利なのか？ ここからは、具体的な理由を実例と共に紹介していきます。
営業＝調整役、だけじゃ物足りない
SES営業って、正直「段取り係」っぽく見られがちだと思っています。面談調整して、契約交渉して、稼働日決めて、、、みたいな。
でも、元エンジニアが営業やると、それだけじゃ済まないケースが多いです。技術がわかるから、案件の“質”に口を出せる。ここがデカい。
例えば「Java開発案件あります！」と話がきたとき、普通の営業は「使用言語：Java」だけ見てOK出しがち。でも元エンジニアなら、「そのJavaって何？Struts？Spring？フルスクラッチ？それともレガシー保守？」と突っ込むことができる。
過去に実際あったのが、Strutsで書かれた10年前のコードをただ直すだけの仕事を「Javaの開発案件です」と紹介されたケースです。でもそれは新人にやらせても、正直あんまり意味がない。どうしてかというと、まず全体の仕組みが複雑すぎてわかりづらいからです。
たとえるなら、最初から誰かが作った巨大な迷路の途中にポンと入れられて、「ここ直して」って言われるようなもので、どこからどうつながっていて、何が原因で問題が起きているのかが見えにくいのです。
設計の意図もわからないし、古いまま継ぎ足し継ぎ足しで動いてるから、ちょっと変えるとどこかが壊れる、だから、「どうしてこう作られているのか」を学べる機会がほとんどありません。
さらに、自分で考えて何かを設計したり改善したりするチャンスもなく、ただ「ここ直して」と言われた場所をちょこちょこいじるだけ。
新しいことを学ぶ余白もなく、毎日同じような作業ばかりで、時間だけが過ぎていき、そして最後には、「この数ヶ月で自分って何ができるようになったんだろう？」と、不安だけが残ってしまうことは珍しくありません。
一方で、「Spring Bootっていう新しいのツールを使って、チームで相談しながらアプリを作っていく仕事」だと、全然変わります
たとえば、どんな機能を作るか考えるところから参加できたり、作ったものをチームの人と見せ合って「ここはもっとこうしよう」って話し合ったり、自動で動くテストやアプリの配布方法も学べたりする。こういうふうに、アプリを作る一連の流れをぜんぶ経験できると、「あ、エンジニアってこうやって仕事するんだ」って体で覚えられます。
だから、まだ経験が少なくても、そういう現場に入った方が圧倒的に成長できます。
1年後、自信のつき方もぜんぜん違ってきます。
「コードが書ける」だけじゃなく、「チームで動ける」「考えて提案できる」っていう力もついてくるので理想的な働き方です。
こういうのを見極めて、「こっちの案件の方がその人の将来にプラスになるな」と提案できるのが、技術を知ってる営業の強みであると私は考えます。
こういう見極めは技術を経験した人間にしかできません。
“エンジニアが育つ現場か”を見抜く力
「案件は、内容より文化が大事」だと私は考えています。
たとえばReact案件と聞いてたのに、実際はjQueryっていう昔ながらの仕組みで作られたシステムを、外側だけReactで包み直してるだけだった、なんてケースが以前にありました。
見た目だけ新しく見えるようにしてるけど、中身は昔のまま。コードレビューもなし、技術をどうするか話し合うこともなく、ただ言われた通りに直すだけ。
この場合だと、ある程度スキルがある人でもキツいです。
なぜなら、自分の頭で考えて行動する余地がなく、誰かに見てもらって「こうした方がいいよ」とアドバイスをもらえる機会も少ない傾向にあります。
自分の工夫が評価されないですし、そもそも工夫する必要がない環境。
毎日が「作業」になってしまって、つまらないし、技術的にも成長できない。
しかし別の案件では、まだ実務経験が半年しかない若手が「設計レビューにも参加させてもらえて、技術的な提案がちゃんと通る環境だった」というパターンもあるわけです。
そういう現場だと、自分の意見が通るからやりがいがあるし、先輩がレビューしてくれて学べることが多い。自分で考えて動いて、それが認められる。だから成長できるし、楽しいと感じられるのだと思います。
簡単に言えば、「ただやらされる現場」か「自分で考えて動ける現場」かで、経験者であっても全然変わってきます。後者の方が、断然スキルも気持ちも伸びますよね
他にも、Laravel案件って言われてたのに、実際はBladeテンプレートをちょこちょこ直すだけ。そんな案件ばかりではエンジニアから「この営業信用できない」と思われても仕方ないですよね
元エンジニア営業は、そういう落とし穴を事前に見抜き、現場で自分が苦しんだ経験があるから、同じ思いはさせたくないと本気で思っています。
詰まるポイントは、だいたい予想できる
参画初日に「PCが届いてない」とか「Gitリポジトリの場所が共有されてない」とか一度は誰でも経験されたことあると思います。
とはいえ、こういう問題を事前に完全に防ぐことは、現実的には難しいことも多いです。営業が現場の内部事情すべてを把握しているわけではないし、会社ごとにやり方も文化も違うためです。
しかしここでもエンジニア経験が生きてきます。参画初日や2日目に、ちょっと時間を取ってエンジニア本人から「困ってることない？」「初日の環境構築うまくいった？」と軽くヒアリングするだけでもその後の安心感や立ち上がりがまるで変わってきます。
たとえば、「セットアップがうまくいかず3時間何もできなかった」とか、「誰に相談すればいいのか分からなくて聞けなかった」といった声を聞けたら、すぐに現場側と調整も可能ですし、こういう些細な“詰まり”って、実際はけっこう精神的な負荷に影響すると私は考えています。
元エンジニアだからこそ、「自分もそうだったな」と共感できますし、どの部分が心理的負荷になるかを直感で察知できる。だからこそ、本人も話しやすいし、営業もちゃんとアドバイスができるのではないかと思っています。
ちなみに、エンジニア経験がない営業だと、こういうときに「どうだった？雰囲気は大丈夫そう？」くらいしか聞けないことも多いです。だからこそ、ちょっとした技術的なつまずきや、本人が言葉にしにくいストレスに気づくのは難しいでしょう。
つまり、“完璧に準備する”ことよりも、“詰まったときにすぐ寄り添って解決できる”ことが、現場をスムーズにするうえで一番大事なんだと考えています。
営業だけど、キャリアの相談役
たとえば「今はVueという見た目の部分を作る技術しかやったことがないけど、将来はアーキテクトになりたい」という人がいたとする。
アーキテクトとは、アプリやシステム全体の“設計図”を考える人のこと。だから、見た目の作り方だけではなく、裏側でどうやってデータを動かすかとか、どういうルールで組み立てるかも知らないといけない。
だからVueしか知らない状態でずっと見た目だけの仕事を続けてても、設計の力はなかなかつかないわけです。でも「この人は将来こうなりたいんだな」と営業がわかっていれば、「じゃあ裏側のAPIとか、データの仕組みも触れる案件に入った方がいいよ」とアドバイスできますよね。
そうやって、将来の夢に向かって少しずつ準備ができる現場を紹介できるのが、エンジニア経験のある営業だと思っています。
エンジニアは「どんな案件を選んだらいいかわからない」と言う人が実はとても多いです。今のスキルでいける案件を紹介されがちだけど、本当は「3年後にどうなってたいか」から逆算すべきです。
たとえば、「今はVue経験しかないけど、将来的にアーキテクトやりたい」という人には、バックエンド構成も把握できる現場を選んでもらう。API設計やインフラの知見を広げられる方が、将来の選択肢が増える。
「目先の単価」じゃなく、「未来の市場価値」を上げるための案件選定。これを一緒に考えられるのが、エンジニア出身の営業の強さだと思います。
顔が浮かぶから、ミスマッチが減る
スキルシートって、言ってしまえばただの紙。でも、営業が現場経験あると、あの紙の裏にある“人となり”が見えてきます。
「この人はガンガン意見を言うタイプか、まずは聞き手に回るタイプか」「レビューで詰まったとき、ちゃんと吸収するタイプか、言い返すタイプか」。そういう部分を把握した上で、「この現場なら合いそうだな」と提案ができる。
だから、エンジニアから「この営業、よくわかってるな」と信頼されていくのだと思います。
”ただの営業”じゃない
世間的に営業は本来「売り上げを作る人」だけど、元エンジニアのSES営業は「共に戦う人」だと思っています。
いい現場を提案したいのは、「自分も現場で苦しんだことがあるから」「ちゃんと成長できる場を知ってるから」、その感覚があるから、案件の中身に踏み込めるし、時には断る勇気も持てるのです。
だから、エンジニアのみなさん。
「営業なんてどれも同じ」と思ってるなら、ぜひ“元エンジニアの営業”に一度会ってみてください。ぜひ私に連絡くれても嬉しいです。きっと、「あ、こいつ分かってんな」ってなるので。
ではまた次回！
