SES営業で案件は取れた、足りなかったのは人だった|SES経営者が見た創業時の需給

SES企業を創業した側の記録 フリーランス

この記事の要点

  • 創業時、案件はSES営業の経験で確保できた。足りなかったのは人材だった
  • 人はまずリファラルで数名、その後Wantedlyでフリーランスと正社員の両方を募集した
  • Java特化の自社に対し、応募はフロント系・Ruby系が多く、募集要件と経験言語はずれていた

筆者はSES企業の経営者で、エージェントとは一部競合する立場です

最初に、筆者の立場を書いておきます。

筆者は、2018年1月に設立したSES企業を経営しています。(2026年10月取得の運営者本人の記録より)

SESとは、システムエンジニアリングサービスの略です。技術者が客先の開発に参加し、稼働に応じて対価を受け取る形態を指します。

筆者の会社は、フリーランスに案件を紹介する側でもあります。そのため、フリーランスエージェントとは一部で競合します。この記事の視点には、その立場による偏りがありえます。その前提で読んでください。

項目 内容
筆者の立場 SES企業の経営者(採用する側)
会社の設立 2018年1月
面談の方法 Wantedly経由で、フリーランス・正社員の面談を筆者本人が担当
エージェントとの関係 一部競合する
出典 2026年10月取得の運営者本人の記録より

この記事は、採用する側の記録です。応募する側からは見えない情報を中心に書きます。

なお、筆者が面談した人数は、まだ根拠を確認できていません。そのため本記事では人数を使いません。扱うのは需給の構造だけです。

創業時は役員報酬0円、案件は余っていて人が足りませんでした

創業当初の役員報酬は0円でした。役員報酬とは、会社が役員に払う報酬のことです。(2026年10月取得の運営者本人の記録より)

筆者自身は、フリーランスとして稼いだ分で生活していました。会社からは報酬を取らず、自分の稼働で暮らしていた形です。

項目 創業当初の実際
役員報酬 0円
筆者の収入源 自分がフリーランスとして稼いだ分
案件 いくらでもあった
人材 いなかった
案件を確保できた理由 筆者にSES営業の経験があった

出典:2026年10月取得の運営者本人の記録より

案件を確保できたのは、筆者にSES営業の経験があったからです。SES営業とは、技術者を客先に提案し、契約をまとめる仕事です。

当時の状態を記録の言葉で書くと、こうなります。「案件はいくらでもあった。人材がいなかった」。

フリーランス向けの記事の多くは、「案件が足りない」前提で書かれています。しかし発注する側にいた筆者の会社では、逆でした。足りなかったのは、案件に入れる人です。

注意点もあります。これは営業経験のある経営者が立ち上げた、ある会社の創業時の話です。市場全体の需給を示すデータではありません。今も同じ状況かどうかは、この記録からは言えません。

人はまずリファラルで数名、その後Wantedlyで募集しました

人が足りない状態を、どう埋めたか。時系列で書きます。(2026年10月取得の運営者本人の記録より)

最初は、リファラルで数名を集めました。リファラルとは、知人からの紹介による採用のことです。

その後、Wantedlyで募集を始めました。Wantedlyは、企業が募集を出して求職者とつながるサービスです。

段階 方法 対象・規模
最初 リファラル(紹介) 数名
その後 Wantedlyで募集 フリーランスと正社員の両方

出典:2026年10月取得の運営者本人の記録より

見てほしいのは、募集対象です。フリーランスと正社員の両方を募集していました。

つまり募集側は、雇用形態を問わずに人を探していたことになります。案件に入れる人であれば、契約の形は二の次でした。

要員数と給与額は、非公開の方針のため書きません。

Java特化の自社に、応募はフロント系・Ruby系が多く来ました

自社は、Javaに特化したSESでした。Javaは、業務システムでよく使われるプログラミング言語です。(2026年10月取得の運営者本人の記録より)

ところが、実際の応募はフロントエンド系・Ruby系が多くありました。フロントエンドとは、画面など利用者が触れる側の開発です。Rubyも、プログラミング言語の一つです。

観点 募集側(筆者の会社) 応募する側
技術 Javaに特化 フロント系・Ruby系が多かった
ずれの把握 応募が集まると見える 他の応募者が見えないため、分からない

出典:2026年10月取得の運営者本人の記録より(「ずれの把握」の行は筆者の整理)

こうした技術のずれは、募集側ではよく起きます。ただし、応募する側からは見えません。自分以外に誰が応募しているかは、分からないからです。

筆者の会社では、Javaの経験がない人を採用したことがあります。採用した人には、自社の案件に入ってもらいました。

経験言語が合わないことは、自社では落選の決定的な理由ではありませんでした。

ただし、言語の一致を必須とする募集がない、という意味ではありません。あくまでJava特化の自社での事実です。

では、何が採用の決め手だったのか。採用基準と落選理由は、まだ記録が揃っていません。別の記事で扱います。

筆者の判断:言語の一致より、発注側との接点の入口を複数持つこと

ここからは筆者の判断を含みます。記録から言える事実と、分けて書きます。

区分 内容
事実 発注側が不足を感じていたのは、案件ではなく人だった
事実(自社に限る) Java特化の自社で、Java未経験の人を採用したことがある
事実 自社の人材の入口は、リファラルとWantedlyの2系統だった
筆者の判断 応募者と募集要件のずれは、応募する側から見えない
筆者の判断 発注側との接点の入口は、複数あるほうがよい

出典:事実の行は2026年10月取得の運営者本人の記録より

経験言語が合わなくても、応募を諦める理由にはしなくてよいと考えています

筆者の経験では、言語が募集要件と違うだけで、最初から諦める必要はないと考えています。少なくとも自社では、決定的な不利ではありませんでした。

募集側は、案件に入れる人を探しています。要件と少し違う応募でも、検討の対象になることはありえると感じています。

ただし、これは自社に限った話です。言語の一致を強く求める募集もあるはずです。

接点の入口が一つだと、相手の都合に左右されやすいと感じています

筆者の会社は、紹介とWantedlyの二つの入口で人と出会いました。どちらか一方だけでは、出会えなかった人もいたと感じています。

フリーランス側から見ても、同じことが言えると筆者は考えています。発注側との接点が一つだと、その相手の募集状況に左右されやすいと感じます。

紹介、求人サービス、エージェントなど、入口を複数持つほうが安心だと考えています。

注意点として、入口を増やすと連絡や面談の手間も増えます。どこまで増やすかは、ご自身の状況で判断してください。

ここでも、筆者がエージェントと一部競合する立場である点を添えます。エージェントを使わないほうがよい、という意味ではありません。入口の一つとして使う考え方もあると思います。

あわせて読むと、立場の違いが見えやすくなる記事です。

コメント

タイトルとURLをコピーしました