今ネット上で「SES」という検索を行うと「SES やばい」や「SES 闇」などがホットな検索ワードとして上位に表示される状態となっています。
SESがなぜ「やばい」のか？そして「全てのSES」がそうなのか？
今回の記事ではSESが以下にやばいのか。そしてなぜこのようなワードで検索されることが多いのかについて記載します。
「SES やばい」と検索される理由とは？
まず前提として「SES」を事業として行っている事業者は日本全国で「約2万事業者」前後だと言われています。
これだけの数の事業者が存在する以上、その中には「優良企業」もあれば、エンジニアや従業員にとって不利な就業環境となっている「劣悪企業」も当然存在します。
そのため、インターネット上では特にそういった「劣悪企業」のエピソードや実態が取り沙汰されることも多く、且つこれらの「悪いニュース」達は「良いニュース」より悪目立ちするためにバズる高くなり、結果として多くの人の目に留まる事になります。
こういった背景から、「SES=やばい」といった意見を持つ人や、そういった悪い印象を与える情報が多く存在しているものと考えています。
SESが「やばい」と言われる3つの理由
では実際に「SESがやばい」と言われる3つの実体について以下に記載をします。
低単価・中抜き構造の問題
まず前提として「SES」とはどういうビジネスモデルかと言うと、エンジニアが所属する企業が他の企業から「システム開発(運用保守やマネジメント業務含む)」を「準委任契約」という業務委託形式の契約にて受注し、それを当該企業に所属する「正社員エンジニア」もしくは「フリーランスエンジニア」が従事することが一般的です。
普通に考えれば「システム開発を依頼する会社(発注会社)」→「エンジニアが所属する会社(受注会社)」の2社が登場人物として登場しますが、SESの場合は「仲介会社」と呼ばれる立ち位置の企業が存在します。
■仲介会社が1社介入している場合
「発注会社」→「仲介会社」→「受注会社」
■仲介会社が2社介入している場合
「発注会社」→「仲介会社A」→「仲介会社B」→「受注会社」
SESでは上記のように仲介会社が間に複数社介入する事により「商流階層が深く」なり、最終的に受注会社が受け取れる収益が目減りしていく傾向にあります。
これらの深く階層化された商流の中で仲介会社が中間マージンとして利益を得る構造が「中抜き構造」とも呼ばれて問題視されることがあります。
また商流が深くなりすぎる事により、受注企業の収益が減り、結果としてエンジニアの収益が低くなってしまうこともあり得る訳です。
SES事業の業務に従事する際には、商流の深さや希望する年収(単価)が実現できそうかどうかの確認がとても重要です。
案件ガチャ
SESでは基本的に受注会社が発注会社から開発の依頼(業務委託)を受け、実際には「受注会社に所属するエンジニア」がそのシステム開発に従事することになります。
この時、一部のSES企業では「エンジニアの意向を無視」して案件を受注し、所属エンジニアに対して半ば強制的に当該システム開発業務に従事させる。といったケースもよくあります。
こういったケースにおいてエンジニア目線では完全に「案件ガチャ」として見えてしまいまし、その案件ガチャが当たりであればまだ良いものの、万が一「ハズレ案件」にあたってしまった日には目も当てられません。
代表的な「ハズレ案件」としては主に次のようなものが挙げられます。
・絶賛炎上中案件
・自分のスキルが全く活かせない案件
・エンジニアリングに全く関係の無い案件
・言語やFWがレガシーで廃れていくのが目に見えている案件
・人間関係が劣悪で人の入れ替わりが激しい案件
もちろんこのような「案件ガチャ」状態となっているSES企業が全てではないため、SES企業に従事する際にはこのあたりの実態をしっかりと確認した上で就業するかどうかの判断をするのが良いでしょう。
労働環境・働き方の不透明さ
SES企業の中には、求人票上はクリーンな内容が書かれているとしても実体としては「劣悪な就業環境」となっている会社が存在します。
筆者が考える劣悪な就業環境だと言える要素は次のものがあります。
・月あたりの平均残業時間が常に40時間を超えている
・深夜/早朝作業や休日出勤などをした際に割増賃金が支払われない
・就業前にリモート可だと聞いていたのに急に出社が必要になった
・業務内容に書かれている言語やFWを実際の業務では使っていない
・SES企業に務めているのに所属会社の従業員と一切交流が無い
他にも劣悪な就業環境として考えられる要素はありますが、大きくはこのあたりになると考えています。
いずれも就業前にしっかりと確認をすることで「期待値から乖離した就業環境」であるかどうかを見抜くことはできると思いますので、実際に案件に参画する前や入社をする前などの面談の際にしっかりと実体の確認をするようにしましょう。
SESを検討しているエンジニアへのアドバイス
ここでは実際にSES企業の代表をしている筆者が「SESを検討する上で重要なポイント」について解説をしていきたいと思います。
企業選びで重視すべきポイント
①エンジニア自身が希望する案件条件が確実に通ること
まず第一に重要な要素としては、エンジニアが自身が希望する案件条件を会社に伝達し、その「希望条件がしっかりと実現されること」です。
特に重要な案件条件の要素としては次のようなものがあります。
・言語/FW: 市場価値が高いものかどうか、また将来的に需要が上がっていくものかどうか
・業務工程: 要件定義/基本設計/詳細設計/開発/テスト/運用保守のいずれを経験できるか
・業務ポジション: フロントエンド/バックエンド/アプリ/インフラなど希望するポジションかあどうか
・出社頻度: フルリモート/ハイブリット/常駐のいずれか
エンジニアとしてもこれらの要素は最低限の希望として会社に伝えるべきですし、その希望がちゃんと通るような会社を選定することがとても重要です。
②月あたりの残業時間が10時間以下であること
SESで就業をする場合、残業時間が実体として月あたりでどれくらい発生しているのかも非常に重要な要素となります。
これは実際に案件面談や就職活動時の面談の際に質問をして貰いたいのですが、「直近半年間の月間平均残業時間は何時間ですか？」と質問をしてみてください。
これをさっと言える企業は恐らく「従業員の残業時間の管理」にも敏感で、「できるだけ残業をさせないように意識して言える企業」だと言えるでしょう。
そして判定基準としては「月あたり平均10時間以下」であることが一つの目安となります。
システム開発業務の場合、どうしてもリリース前後や障害発生時などには残業が発生してしまうものなので「平均0時間」は流石に不可能に近いですが、それでも過去半年間の平均が10時間以下に抑えられている企業であれば優良であると言えるでしょう。
③案件の退場タイミングをエンジニアが選択できること
次に案件の退場のタイミングについてです。
これもエンジニアのキャリアパスを意識する上では非常に重要な要素だと言えるでしょう。
一般的にエンジニアにおけるキャリアパスにおいて、「1つのプロジェクトやサービスに従事する期間」が一定期間以上を経過すると、以降は時間経過と共に「成長実感が下がっていく」傾向にあります。
そしてその一つの目安となるのが「2~3年間」だと筆者は考えています。
実際に想像をしてみて欲しいのですが、エンジニアであるみなさんが1つのサービスに2~3年間従事した場合、それ以降も同じサービスに従事し続けたとしても「それまでと同様の成長実感を持ち続けることができる」でしょうか？
多くの人の場合、答えは「NO」だと思います。
だからこそ、エンジニア人材市場における平均的な転職期間は「約3年間」と言われており、これは上述した「成長実感が持てなくなってくるタイミング」と合致します。
エンジニアという人種は「常に新しいことを学び、成長していきたい」と考える人の割合が非常に多いです。
そのため、1つのサービスや案件に参画する期間は「エンジニアが正常をする上で非常に重要な要素」となる訳です。
もしあなたがSES企業への入社やSES案件への参画を検討されている場合、自分自身が「参画した案件の退場タイミングが選べる状況」であることが望ましいです。
目安として2年間程度は同じ案件に参画し、そこで十分な知識と経験を得てから退場して次の案件へ参画することをおすすめします。
因みに補足をすると、SESであっても案件参画期間があまりにも短い場合ですと、職務経歴書上の見え方が悪くなってしまうため、「最低でも1年間以上」は1つの案件に参加することを推奨しています。
(※フリーランスエンジニアなどの場合でも半年以下の案件が複数ある場合だと「ジョブホッパー」のような評価となってしまい、書類審査で落とされやすくなるため、注意が必要です。)
④所属会社とのコミュニケーション機会が多いこと
次に重要視したいのが、SESとして所属している企業の従業員同士のコミュニケーションについてです。
ここで言う「所属会社」とは、発注会社から仕事を受け、自社でその業務委託のお仕事に従事する受注会社のことを指します。
SES企業の場合、極端に言えば「従業員同士の横のつながり」は全く無くても業務自体には支障はありません。
しかし、筆者はこの従業員同士のコミュニケーションや横のつながり、または会社との繋がりは非常に大切だと考えています。
前提として、人は社会的な生き物ですから、常に何かしらのコミュニティに属していることが前提の生き物になります。
そのコミュニティの形は様々ありますが、例えば「家族」「学校」「部活」「サークル」「会社」「近所」「常連客」「趣味仲間」などがあるでしょう。
いずれにしても人は常に「なにかのコミュニティに属している」という帰属意識がとても重要で、この帰属意識が無くなってしまうと主に「メンタル面で不調をきたす」傾向にあります。
直近では「コロナ禍」においてリモートワークが前提の働き方に変化したタイミングがありましたが、多くのリモートワーカーは企業などへの帰属意識が薄れ、精神面での課題や疾患を抱えるような例もよくありました。
少し前置きが長くなってしまいましたが、社会人にとって「所属企業に対する帰属意識」は非常に重要な要素であり、その帰属意識が持てるような「社員同士の交流」や「授業員として会社に所属している意識」を重要視している会社であれば、安心してお仕事に集中ができると筆者は考えています。
⑤会社がエンジニアのキャリアパスを支援していること
最後になりますが、SES企業側が所属するエンジニアのキャリアパスに関心があり、その支援までしているかどうかについても確認をすることを推奨します。
先述の通り、SES企業の場合は社員を大切にせず、劣悪な環境下で就業をさせているところも少なくありません。
そういった会社では当然エンジニア自身のキャリアパスなどにもあまり興味を示さず、支援制度などが全く無い企業も存在します。
そこでSES企業側に対して「キャリアパスを支援するような制度があるか」を質問することで、これらの見極めをするのが一つの解決施策になるでしょう。
例えば学習に必要な「書籍購入制度」や、キャリアパスをする上で必要な資格を取得するための「資格支援制度」など、何かしらの形でキャリアパスを描いていく上で追い風となる福利厚生が存在する企業が望ましいです。
また、ただ制度を設けているだけでなく、エンジニア自身と定期的に「キャリアカウンセリング」を行っている企業も評価としては高いと言えるでしょう。
やはりエンジニア自身だけでは「エンジニア人材市場価値」を図ることは難しく、会社や営業担当者の人からの協力を得てキャリアパスを描いていく方がより効率的に自身の価値を上げていくことができます。
こういったエンジニア自身の人材市場価値を高めてくれるような企業を探していくのが、エンジニアとして成長していく上ではとても重要です。
将来を見据えたキャリア設計の考え方
エンジニアとしてのキャリアパスについては、個人によってその内容が大きく異なります。
プログラマーとして開発・製造をずっとし続けたい人もいれば、着実に業務ポジションの階層を上げていくことで効率的に自身の市場価値を高めて行きたい人も居ます。
そのため「どのキャリアパスがベストなのか」といった絶対的な答えはありません。
そこでこの記事では「時間経過と共に着実に市場価値を上げていくこと」を主目的とした「キャリアパスの一例」を紹介したいと思います。
業務ポジションと経験年数の目安
まずエンジニアには職務内容に応じた「役職」と呼ばれるものがあり、代表的なものとしては「PG」「SE」「PL」「PM」の4つに大きく分類されます。
そしてエンジニアがこの各業務ポジションの「どこに位置するのか」はエンジニアリングの「実務経験の長さ」と「業務工程経験」(※1)に密接に関連があります。
以下にそれぞれの役職ごとの特徴と併せて、実務経験の長さとその役職において必要な業務工程の経験について目安となる指標を記載します。
※1業務工程: 「要件定義」「基本設計」「詳細設計」「開発」「テスト」「運用保守」
- PG(プログラマー)
- 特徴: 主に「開発」工程に従事するエンジニア。仕様書や設計書など与えられた情報に基づいてコーディングを行うのが主な業務内容。
- 実務経験の目安: 0~3年程度
- 業務工程: 開発のみ
- SE(システムエンジニア)
- 特徴: 「詳細設計」と「開発」の工程に従事するエンジニア。時には「PL」や「PM」のサポート役として設計業務に携わることもある。
- 実務経験の目安: 3~6年程度
- 業務工程: 詳細設計、開発
- PL(プロジェクトリーター)
- 特徴: 「要件定義」と「基本設計」の工程を主に担当するエンジニア。開発業務を行う場合もあるが、多くの場合は下にPGがアサインされ、そのメンバーの育成や指導なども行う。プロジェクトにおいて開発業務全般を推進していく立場となるポジション。
- 実務経験の目安: 6~9年程度
- 業務工程: 基本設計、詳細設計、開発
- PM(プロジェクトマネージャー)
- 特徴: プロジェクト全体の進行管理や顧客がいる場合は顧客折衝、また開発に関しては「要件定義」や「基本設計」(時には「詳細設計」)を主に担当するポジション。このポジションでは開発業務を行うことはほとんど無く、他のPGやSE、PLといったメンバーをマネジメントしながらプロジェクト推進をしていくのが主な業務となる。
- 実務経験の目安: 9年以上
- 業務工程: 要件定義、基本設計、詳細設計
- 備考: 顧客折衝、プロジェクト進行管理なども担当
上記のように各役職に応じて「求められる実務経験の長さ」と「業務工程の経験」は異なります。
何も考えずに「ただ長くエンジニアを続けているだけ」ではこれらの役職を効率よくステップアップさせて行くことは難しいため、「今の自分にはどのような業務工程の経験が必要なのか？」を定期的に考えながら自分にとって最適なキャリアパスを描いて行くことをおすすめします。
事業会社や受託開発との比較
この記事ではSESを前提とした様々な側面について記載をして来ましたが、よく比較対象として挙げられる「事業会社」と「受託開発会社」との差分についても着目して解説をしていきたいと思います。
事業会社vsSES
まず事業会社との比較についてですが、ここでいう「事業会社」の定義としては次のとおりです。
【事業会社】の定義
自社サービスを持ち、そのサービスの開発や運営によって収益をあげている企業
ここではその差分を比較する上で分かりやすい「メリット・デメリット」について言及していきたいと思います。
上記のように全体を通して事業会社の場合は「自社サービスに従事することの帰属意識」や「自社サービスへの愛着を持った上での業務推進が可能」な点が大きなメリットであると言えるでしょう。
一方で長く同じサービスに従事し続けることで「自身の成長実感が薄れてしまう」ことや、「やってみたい技術を業務で使うことができない」といったことも多く、全体的に「エンジニアとして中長期で成長し続けることがやや難しい環境」でもあると言えるかと思います。
受託会社vsSES
次に受諾会社とSESの比較について記載をしていきますが、ここでは「受託会社」の定義を次の通りとします。
【受託会社】の定義
発注企業からシステム開発の請負業務を受注し、主に自社のエンジニアにて開発業務を行って顧客へ納品する事業を主な収益現としている企業
こちらも先ほどと同様にSESと比較した場合のメリット・デメリットについて記載をします。
上記のように受託会社の場合はゼロイチでの開発案件が豊富にあるため、「新規サービス開発の経験を多く積める」ことが大きな魅力の一つだと言えます。
一方でよほど大きな企業で無い限りは「大規模サービスの開発に従事できることは少ない」と言えるでしょう。
また受託会社の場合は自社で知見やソースコード単位の資産を積み上げることが多いため、同じ言語やFWでの開発を繰り返すことが多く、「新しい言語やFWに挑戦することは多くない」傾向にあります。
事業会社・受託会社・SESどれがいいのか？
ここまでそれぞれの会社別の特徴やメリット・デメリットを書いて来ましたが、どれが良い or 悪いと一概に定義することは難しく、どの会社でも「一長一短がある」という表現がより正しいかと思います。
しかし、「どの会社を選ぶべきか」はそれぞれの会社の特長をよく捉えた上で「自身に合う会社のタイプを選択する」ことを推奨します。
自分にとってより最適な会社を選びためには、自身が将来的にどのようなエンジニアになるたいのか、またどのようなキャリアパスを描いていきたいのかに併せてよく検討し、時には自身の価値観や志向性を内省しながら検討していくのが良いでしょう。
まとめ：「SES やばい」は本当か？正しい理解で判断を
最後にまとめとなりますが、結論としてSESは劣悪な労働環境になっている「やばい企業」もありますが、これは「SES=やばい」ではなく、SESを行っている「劣悪な企業=やばい」と結論付けることができるでしょう。
記事の後半で上げた「事業会社」や「受託会社」の中でもいい会社もあれば、上述した劣悪な企業のように「やばい労働環境」になっている会社もたくさんあります。
そのためここまで本記事を読んで頂いた読者の皆さまには【ビジネスモデルで判断するのではなく、その企業の文化や考え方で判断をする】ことを強く推奨したいと考えています。
実際のところ、SES企業勤めから事業会社へ転職したことですごく満足度が向上したエンジニアも居れば、逆に「事業会社からSESに転職」したことで理想的なキャリアパスを実現できて「スキルレベルや年収が大きく向上したエンジニア」も数多く居ます。
願わくば、本記事の内容を通してそれぞれの会社やSESの良し悪しなどの情報を取得頂き、少しでもエンジニア読者皆さんの今後のキャリアパスの一助になれていましたら幸いです。
【著者プロフィール】
init株式会社 代表取締役 山田 卓(ヤマタク)
iOS/Androidエンジニア歴: 10年+
モバイルアプリPM歴: 5年+
モバイルアプリ系技術顧問歴: 4年+
■SNS
・X(旧Twitter)
・GitHub
・note
コメント