
営業製作所の開発組織は、正社員を中心とした少人数のチームです。しかし手がける領域は、営業支援システム、AIを活用した企業マッチング、通話内容の自動要約、図面管理SaaS、企業データ基盤など多岐にわたります。
特徴は、技術を試す速さと、実際の利用者との距離の近さです。営業やカスタマーサクセス(CS)から届いた要望を開発メンバーが直接確認し、優先順位を判断します。新しい技術も、セキュリティなどの条件を満たせば、まず試してプロダクトへ生かしていきます。
今回は、文系・営業職からエンジニアへ転身し、2023年に営業製作所へ入社したS.Jさんに、少人数だからこそ得られる裁量、開発スピードの背景、これまでつくってきた機能、今後取り組みたいテーマについて聞きました。
開発部 メンバー
中央大学を卒業後、大手ヘッドハンティング会社に営業職として入社。新規開拓営業を経て、DX事業でRPA(定型業務を自動化する仕組み)の導入支援などに携わる。その後、技術者派遣会社へ転職し、自動車部品メーカーに常駐して社内システム開発を経験。2023年10月、開発チームの2人目として営業製作所へ入社し、現在は主にEigyo Engine関連のシステム開発を担当している。
文系・営業職から、エンジニアになるまで

—最初のキャリアは営業職だったそうですね。
S.Jさん:はい。大学は文系で、中央大学で経済を学んでいました。新卒で入社した大手ヘッドハンティング会社では、新規開拓営業を担当しました。
就職活動では大手企業も見ていましたが、大きな組織よりも、裁量があり、自分で動くことを求められるベンチャーの方が成長できそうだと感じました。ヘッドハンティングというビジネス自体にも興味があり、入社を決めました。
最初は、採用に困っている企業へ電話し、人材の要件を聞くところから始めます。泥臭い営業でしたが、そういう環境だと理解して入社していたので、大きなギャップはありませんでした。
—エンジニアを目指すきっかけは何だったのでしょうか。
S.Jさん:入社後、新しくできたDX事業へ異動し、RPA(定型業務を自動化する仕組み) の導入支援などに関わったことです。それまでは営業が中心でしたが、ITや業務改善に触れる機会が増え、技術の仕事を面白いと感じるようになりました。
もともとパソコンを触ることや技術系の試験に興味があり、自分にはこちらの方が合うのかもしれないとも感じました。
ただ、当時の仕事は営業やコンサルティングに近く、技術を深く理解していないことにもどかしさがありました。より大きなインパクトのある提案をするには、自分自身に専門性が必要だと考え、エンジニアへの転職を決めました。
未経験から技術を学び、大手メーカーのシステム開発へ
—2社目では、どのようにエンジニアの経験を積みましたか。
S.Jさん:未経験者向けの研修がある技術者派遣会社へ入りました。同じタイミングで入社した未経験者や第二新卒のメンバーと一緒に、ITの基礎を学びました。
研修後は、自動車部品メーカーへ常駐しました。営業部門に近いチームで、製品の不具合を検知・分析し、自動車メーカーと対応を進めるための社内システムを開発していました。
やりたかった専門的な仕事に関われたので、仕事自体は楽しかったです。一方、常駐という立場では、担当範囲や契約期間が決まっています。基本的には依頼されたものをつくることが中心で、「こういうものをつくりたい」と思っても、できることには限りがありました。
自社でプロダクトをつくる方が、要件や技術の選択から広く関われるのではないか。そう考えたことが、次の転職につながりました。
「自社で開発チームをつくる」。前職の先輩から届いた誘い

—営業製作所へ入社したきっかけを教えてください。
S.Jさん:代表の西島本は、大手ヘッドハンティング会社の先輩でした。自社で開発チームを立ち上げるという話を聞き、「一緒にやらないか」と何度か声をかけてもらっていました。
常駐先との契約が終わるタイミングが見えたところで、2023年10月に営業製作所へ移ることを決めました。
当時、開発チームは責任者と私の2人でした。役割は細かく決まっておらず、「必要なものは何でもつくる」という状態です。自社プロダクトの立ち上げに、ゼロから関われることに魅力を感じました。
開発チーム2人。要件定義から実装まで、境界なく担う
—入社後、最初に取り組んだ開発は何でしたか。
S.Jさん:最初はGoogle Apps Scriptを使った小さな業務ツールなどをつくりました。その後、営業支援サービス「Eigyo Engine」で使う架電システムの開発に入りました。
入社前から、自社システムへ架電機能を組み込む構想を聞いていました。外部の架電サービスを調べ、営業支援を担当するメンバーやアポインターへ、どのような機能が必要かを確認しました。画面についてはデザイナーにも協力してもらいながら、要件を整理して形にしていきました。
開発だけでなく、利用者へのヒアリング、要件定義、画面設計、進行管理まで関わります。当時は2人だったので、「ここから先は別の担当」という明確な境界自体がありませんでした。開発責任者に支えてもらいながら、広い範囲を経験できました。
架電業務を、自社システムの中で完結させる
—その架電システムは、どのように使われているのでしょうか。
S.Jさん:Eigyo Engineでは、製造業のお客様に代わって、営業先候補へ電話をかけます。現在は、営業先の情報を画面で確認し、システム上から電話をかけ、結果を記録できるようにしています。
以前は複数のツールやスプレッドシートを使っていた業務を、自社のシステムへ集約していきました。実際に電話をかけるメンバーから、「この情報が見えると電話しやすい」「この操作を減らしたい」といった要望を聞き、その都度改善しています。
つくった機能が社内ですぐに使われ、反応も直接返ってきます。自分たちの開発によって、営業支援の進め方そのものが変わる点は、自社開発ならではの面白さです。
AIで、顧客と営業先候補の相性をスコアリングする

—電話以外には、どのような機能を開発してきましたか。
S.Jさん:顧客ごとに作成する営業先リストを、AIで評価する機能があります。
まず、「この顧客はどのような技術を持っているか」「どのような企業へアプローチしたいか」といった情報をAIへ渡します。それを営業先候補の企業情報と比較し、「この企業は相性が良さそう」「あまり合わないかもしれない」という結果をスコアで表示します。
スコア順に並べ替え、優先度の低い候補を外すこともできます。以前はスプレッドシートとGoogle Apps Scriptで行っていた処理を、Eigyo Engineのシステムへ移しました。
人の経験だけに頼らず、顧客の技術が生きる企業を見つけやすくする。電話をかける前のターゲット選定を、システムで支援する機能です。
営業とCSがすぐ近くにいる。ニーズが開発へ届く仕組み

—開発する機能は、どのように決まるのでしょうか。
S.Jさん:営業やCSから、機能の要望が上がってくる仕組みがあります。社内では、お客様や現場の困りごとを「ニーズカード」として集めています。開発メンバーもそれを見て、「これは実現したときのインパクトが大きい」「多くの人が困っているので、早く解決した方が良い」と判断します。
必要であれば、要望を出したメンバーへ直接話を聞きます。社内の利用者がすぐ近くにいて、「この機能はどう使うのか」「本当に何が問題なのか」を確認できる環境です。
営業やCSから、その場で「これをどうにかできませんか」と相談されることもあります。仕様書だけを受け取って開発するのではなく、利用者と話しながら課題を整理し、解決方法を考えます。
既存の業務基盤を、自社システムへ移していく
—最近、特に大きかった開発を教えてください。
S.Jさん:新規開拓に使うシステムを、外部の業務基盤から自社システムへ移行する開発です。
これまで外部ツール上に構築していた大きな仕組みを、自社の環境へ組み込みました。データ同士の関係が複雑なので、アプリケーション側だけで完結する仕事ではありません。
営業製作所には、企業情報の収集やデータベースを担当する専門チームがあります。私はアプリケーション側を担当し、データ部分は専門チームと連携します。
少人数ではありますが、全員が何でも一人で抱えるわけではありません。得意領域を持つメンバーと連携しながら、大きな機能を短期間で形にします。
決まるまでと、決まってからが速い
—これまでの開発組織と比べて、営業製作所の強みはどこにありますか。
S.Jさん:物事が進む速さです。何をやるか決まるまでと、決まってから開発が動き出すまでが速いと思います。
利用者が近くにいるため、確認のために長い伝言ゲームをする必要がありません。要望があれば直接聞き、開発メンバーが優先順位を判断し、すぐに動けます。新しい技術も、試せる条件が整っていれば取り入れます。
一方で、変化が速い分、キャッチアップが遅れるとついていくのが難しくなります。昨日までの優先順位が変わることもあります。整ったタスクが順番に流れてくる環境ではありません。
このスピードや変化を負担に感じる人もいると思います。反対に、状況に応じて考え、優先順位を変え、前へ進めることを楽しめる人には面白い環境です。
コードを書く以外に、プロジェクトを前へ進める力が求められる
—開発組織には、どのようなメンバーが多いですか。
S.Jさん:技術に関する新しい情報を柔軟に吸収しながら、周囲と調整して物事を進めることが得意な人が多いです。
少人数なので、細かく分けられたチケットを受け取り、実装だけを担当する働き方ではありません。「こういうことを実現したい」という状態から、関係者に話を聞き、リスクを確認し、どの方法で進めるかを決めます。
開発責任者や経験のあるエンジニアへ相談すると、技術的な答えだけでなく、見落としていたリスクや代替案をすぐに返してもらえます。「この方法でも進められる」「こうすればリスクを抑えられる」と、視野を広げてもらう場面が日常的にあります。
コードを書く力に加えて、要件を整理し、優先順位を判断し、周囲と協力してプロジェクトを進める力が鍛えられます。
開発内容はジャングル。でも働き方までジャングルではない

—変化が速いと、働き方もハードなのでしょうか。
S.Jさん:開発する内容や進め方は、良い意味でジャングルだと思います。ただ、働き方までジャングルというわけではありません。
基本的には9時から18時、遅くても19時頃までに業務を終えます。休日や連休は休めますし、有給休暇も取得できます。
出社を基本としていますが、営業やCSへすぐに確認し、隣にいるエンジニアやデータチームと話しながら進める現在の開発スタイルには合っていると感じます。
変化の大きい開発環境と、無理なく働き続けられる勤務環境は分けて考えられています。
まだ完成していない。営業支援の品質を、システムで底上げする
—今後、取り組みたいテーマはありますか。
S.Jさん:Eigyo Engineのシステムは、まだ完成していません。特に、CSが担う顧客支援には、担当者の経験や判断に依存する部分があります。人によって支援品質に差が出る部分を、システムでもっと支えられると考えています。
たとえば、顧客に合う営業先候補をAIで見つける機能も、その一つです。これまで人の経験に頼っていたターゲット選定を一部システム化できれば、誰が担当しても一定以上の品質を出しやすくなります。
支援品質が上がれば、お客様のアポイント獲得や受注につながる可能性も高まり、サービスの継続にもつながります。開発した機能が、社内の業務効率だけでなく、お客様の成果や事業の成長にも直接影響します。
まだ改善できるテーマが多く残っていることが、今も営業製作所で働き続けている理由の一つです。