和製英語だと思うのですが、SES という業態があります。知らない方のために簡単に説明すると、ソフトウェア開発者（他の職種の場合もあります）が必要な会社に対して、自社のリソースを貸し出す事でお金を得る形式で、契約形態としては準委任契約が一般的です。準委任契約等については、かなり前ですが以下のような記事を書きましたので、ご参考までに。

ソフトウェア開発に関する契約形態

準委任契約の派遣との違いとして、客側（リソースを借りる側）では労務管理を行わない等などがありますが、本題ではないので省略します。

SES では客側のオフィスに常駐・半常駐の場合もあればリモートもありますし、フルタイムの場合もあれば、稼働率50%といった契約もあります。

複数人・チームを割り当てるケースもありますが、私の周りの狭い観測範囲に限ると1人だけというのが大半のように思えます。従って、SES を主にやっている会社では、1人1人が別々のお客様の PJ に配属され、横の繋がりが希薄になりがちです。ただ、この話も本題ではないので詳細には触れません。

問題点

エンジニアが量産品の如く扱われる

SES という仕組みはメリットもあるから世の中に存在しているのですが、太古の昔から問題点は色々指摘されています。上述の横の繋がりが希薄になりがちで会社に対する帰属意識が薄れるというのもその1つですが、私が一番気になるのは、ソフトウェア開発者が大量生産の商品かの如く扱われる点です。

どういったことかというと、ある会社で開発者が必要になると、以下のような条件を SES の会社（通常は複数）に提示します。

  • 単価: 1人月XX万円
  • 必須スキル
    • TypeScriptを用いた開発業務経験（△年以上）
  • 尚可スキル
    • Ruby on Railsでの開発経験
    • 開発リードのご経験

SES の会社では、それに合致する開発者がいると「こういう人がいます」という提案を行います。その際に職務経歴書も送るのですが、その内容もフォーマットが決まっている事が多く「○○経験△年」、「○○人のチームでサブリーダー」みたいなものが重視されます。

その書類である程度候補者は絞られ、その後に発注側と面談します。さすがに面談では、単純に経験年数だけでなく、過去のプロジェクトで何をやったか、問題をどう解決したか、といった採用面接と似たような話が行われます。ただ、これは発注側がソフトウェア開発にどれだけ知見があるかによっても変わります。

具体的には: 経験年数等のスペックを過大視

以前から、ある程度経験のある開発者であれば、特定の言語・フレームワークを知らなくても比較的短時間で習得する事が出来ました。その結果、

ある言語を知らない上級者の成果＞その言語を知っている中級者の成果

という事はよくありました。

そうした状況が、AI 全盛の時代になりさらに顕著になりました。全く触った事のない言語・フレームワークでも、シニアエンジニアであれば過去の知識とかを活かしながら生成 AI の助けを借りる事で、支障なく業務を進められるようになっています。

このように、特定技術の経験というのが薄れてきているのに、職務経歴書・スキルシートでは「○○経験△年」といったものが引き続き重視されています。

なぜそうなるか

表層的な理由

理由は主に以下の2つかと思います。

  • 提案する・される数が多いので、そうした指標を使った方が楽
  • 提案する・される側のどちらか、あるいは両方とも技術に対する理解が浅く、深い話が出来ない

案件・候補者が多い

まずは前者から説明します。SES 関連の一般的な商流としては以下の通りです。

  • 事業会社（ソフトウェアを開発したい）
  • -> 元請け（コンサル・企画系等の非開発会社、開発会社どちらの場合もあり）
  • -> 下請けの SES 企業（以前より減りましたが、多重下請けもあります）

SES をメインでやっている会社では、同業者のネットワークがあり、日々案件情報が流れています。その中で日々提案をしていくのですが、提案する側もされる側も数が多いとどうしても「○○経験△年」みたいなのを中心に話をした方が簡単なため、そうしたものが重視される形になります。

選考をエンジニアが担当する事が少ない

後者については、提案する・される側の誰一人として技術が分かっていないという話ではありません。ではなぜ技術の分かる人が関わらないのでしょうか。

こうした案件の話は以下のような人達がまずは一次選考をします。

  • 提案される側
    • 非開発会社であればコンサル、PM
    • 開発会社であれば営業
  • SES 企業側: 営業

こうした職種の人達には、技術の理解が浅い人も多く含まれるため、結果として「○○経験△年」といったものに頼らざるを得ません。

構造的な課題

読んでいて気づいた方もいると思いますが、実は SES に限った話ではなく人材採用の現場でも似たような事が起きています。ただし、人材採用の場合は自社の社員＝核となる戦力を選ぶという事ですので真剣度が異なり、書類選考の段階から現場を分かっている人が担当する事も一般的です。

では、SES でも時間・費用をかけて、もっとじっくり選考できないのでしょうか。結論から言うと、難しいと考えています。

SES の構造的な特徴としては以下の通りです。

  • SES が使われるのは比較的短いプロジェクト（数ヶ月〜1年）が大半
    • 契約は3ヶ月更新というのが大半
  • 重要な部分はプロパー社員が担当し、SES はそこまで重要でない部分の担当、というのが多い
  • 良いプロパー社員が採れれば・空きが出きれば契約終了、という調整弁的な使われ方

そのため、採用する側でコストをかけるインセンティブがあまり高くありません。

また、SES における選考は、再三書いていますが「○○経験△年」みたいなのが重視されます。SES 側としては（少なくとも書類選考の段階では）差別化要因があまりなく、価格競争となりがちです。そんななか、SES 側でもコストをかけて丁寧な提案をするというのも実際には難しいです。

もばらぶではどうするか

その前に、今回の記事の背景

このようなブログ記事を書いた理由についても少し述べます。割と長くやっていたプロジェクトが終了や縮小になった事があり、その際に知り合い経由などで新たなプロジェクトを探した事があり、何件かご紹介いただきました。

その中に SES 的な形態のものもいくつか含まれており、それ自体はとても有り難かったのですが、金額面で合わなかったり、先方のご要望（「○○経験△年」等）に合致しなかったりと、難しさを感じたというのがきっかけです。

増やしていきたい仕事は

ではどうしていきたいかというと、

  • 受託開発であれば、ソフトウェアを作りたいお客様と直接お取引をして、中長期的に関係を築いていく
  • もう1つは、自社の製品・サービスで売上を立てていく

というところでしょうか。（我ながら平凡な結論に落ち着いたな、と思います。）

それにより、「○○経験△年」といった表層的な部分で判断される事が少なくなり、各開発者としても自分の強みをプロジェクトで発揮しやすくなると考えていますし、結果的にお客様としても自分たちのプロジェクトに合致した開発者を使えるようになります。

エンジニアをもう少し前面に出していく

それに関連して、各開発者の

  • どんなプロジェクトでどんな事をやってきたのか
  • どんな技術を持っているのか
  • どんな事を考えているのか

といった部分がもっと分かるように、プロフィールページ等を通じて発信していければと考えています。

スーパーの野菜・果物コーナーに行くと、「○○県の△△さんが作りました」みたいなのをよく見かけると思います。それと似た感じで、お客様に対して「○○経験△年のエンジニア」ではなく「山田太郎」のような個人名で提案できるようになれればと考えています。

まとめ

SES という派遣に似た業態では、「○○経験△年」といった表層的な経歴でエンジニアが選考されがちという問題があります。

理由ですが、SES は調整弁的に使われる事が多く契約も短期の事が大半です。そのため、採用する側は選考にコストをかけるインセンティブが少なく、分かりやすい指標を使いがちです、採用する側が分かりやすい指標を重視する以上、提案する側も価格競争となりがちで、提案にあまりコストをかけられません。

SES が必要な場面は当然あるので今後も業態としては残り続けるとは思いますが、体力勝負といった側面もあるので、もばらぶのような小さな会社にとってはなかなか難しいと思っています。

そのため、もばらぶでは

  • 受託開発
    • お客様との直接・中長期の取引を重視する
    • エンジニア個人を目立たせる
  • 自社製品・サービスで売上を立てる

といったところに力を入れていこうと考えています。

弊社へのお仕事のご相談等、以下のお問い合わせフォームよりお気軽にご連絡いただければ幸いです。

お問い合わせ – もばらぶん