SESとは？
SES企業に入社するかどうかで悩んでいる人へ
SESとは、System Engineering Serviceの略で、顧客にソフトウェアやシステムの開発・保守・運用を行うエンジニアの労働力を提供するサービス（又は契約形態）を指します。
SESと言う言葉は、従来サービスの提供方法を指す言葉ですが、場合によっては契約方法を指すこともあり、その定義が曖昧です。
まずは「サービスの提供方法を指す場合のSES」と「契約を指す場合のSES」に分けて、それぞれ説明します。
開発・サービスの提供方法とSES
開発やサービスの提供方法としてのSESと、それ以外の主なシステム開発業の特徴を以下に記載します。
常駐開発
サービスの提供方法としてのSESは、基本的には客先に常駐して設計や開発を行うことを指します。
ただし、近年のエンジニア不足により、「ラボ開発」と呼ばれる自社からリモートで労働力を提供するサービスや、コロナウイルス感染症の蔓延防止による「リモートワーク」が増加し、SESでも客先に常駐しないサービス提供も増え、社内開発との境目が曖昧になってきています。
ひとり当たりの月の売上が決まっていることが多く、稼働が安定し、給与は低く抑えられる傾向にあります。
自社サービス
その名の通り、自社でサービスや商品を開発することを指します。自社で技術の選定を行うため、新しい技術や導入に携われる可能性があります。ただ、一度選定すると開発・保守の効率のためプログラム言語やツールは固定化される傾向にあります。また、サービスの保守や新機能のリリース、サーバーのお守り等、他の受注形態にはない働き方があるのも特徴です。
責任が重く業務はハードですが、何より自分たちが作ったシステムで社会に貢献すると言う夢のある働き方です。
社内開発・受託開発
エンドユーザーやSIerから、設計や開発を丸ごと任される形態を指します。主に、納品し顧客の検収を受けてからお金をもらう契約（請負契約：下に記載）になります。納期や品質に対する責任があり、見積りや設計のミスが従業員に与える影響が大きいため、稼働が高くなるリスクがあります。
自社の得意な言語、環境で開発されることが多く、そのスキルを深堀りする働き方になります。SESと異なり、より効率的に開発・納品することで収益が大きくなるため、SEとして見積りやマネジメント、プログラマーとして効率的な開発スキルなどが求められます。
契約とSES
契約方法を指す場合SESと、それ以外の主なシステム開発業で行われる契約について以下に記載します。
準委任契約
契約としてのSESは、一般的に準委任契約を指します。準委任契約は民法第656条に規定されていて、委任契約の法律行為以外のものです。委任・準委任契約は、委任された「行為を行うこと」を求められる契約であり、後で記載する請負契約のように仕事の完了を必要としません。また、開発したものに瑕疵があっても、善良な管理者の注意を持って委任事務を処理する義務を果たしていれば（民法第644条）、原則的に責任を問われることはありません。また、準委任契約では発注側に指揮命令権がありません。そのため、仕事の進め方や残業の指示を行うことはできません。
とはいえ、しっかりと成果をだしておかなければ現場からNOをつきつけられ、契約が継続されないと言うリスクは常につきまといます。
派遣契約
先に、契約としてのSESは一般的に準委任契約と書きましたが、派遣契約でSES（サービス内容としての常駐による労働力の提供）と言うパターンもあります。この場合、準委任契約と同じように現場に常駐しながら、発注者の指揮命令権が発生します。そのため、発注者により作業内容や残業の指示を受けて働きます。客先の社員に近い形での労働となりますが、社員と異なり派遣契約時に取り決めた作業内容以外の作業を行うことは出来ません。
また、SES企業に正社員として所属するエンジニアの派遣契約は、人材派遣会社の派遣社員のイメージとは異なり、顧客（派遣先）との派遣契約が終了しても原則的に所属企業（派遣元）との雇用契約が終了することはありません。
請負契約
請負契約は、主に社内開発・受託開発を行う会社が顧客と結ぶ契約です。
請負契約は、受注者が発注者に対して仕事を完成させることを約束し、発注者はその結果として出来た成果物に対して代金を支払います。逆に、完成できなければそのプロセスとしてどのような開発を行ったかに関わらず代金が支払われることはありません。
事前に見積もった工数より効率的に開発を行えば黒字が大きくなり、逆に見積りが甘かったり、開発効率が悪ければ赤字になります。納期に間に合わせるために沢山の残業が発生することもあります。そのため、より高いスキルと責任感が求められます。
ただ、「現場請負」と言って請負契約にも関わらずSESのように客先に常駐する契約形態も存在します。これは一見SESのようですがあくまで請負契約であり、作業場所を客先から借りて開発を行いますが、客先の指揮命令がなく、成果物を求められます。
SESが存在する理由
案件や工程で異なるスキルが必要
では、なぜSESは存在するのでしょうか。
システム開発では、ウォーターフォールと言う開発手法がよく用いられています。これは開発を各工程（要件定義→設計→開発→テスト→導入→運用保守）に分けてすすめる手法で、原則的に後戻りはありません。
一般的に要件定義や設計を行うエンジニアをSE、開発やテストを行うエンジニアをプログラマーと呼びますが、工程ごとに求められる適性やスキルは異なります。大手企業の大きなシステムや高度な専門性が求められる開発の場合、工程ごとに違う専門知識を持ったSEやプログラマーが必要になります。
日本の終身雇用制
IT先進国のアメリカにSESはないと言うのはよく聞く話ですが、これには日米の雇用制度の違いが関係しています。アメリカには終身雇用と言う考え方が一般的ではありません。そのため、必要なポジションがあればそれに応じて人を雇い、ポジションがなくなれば雇用を解除（レイオフ）できます。ところが、日本では解雇は厳しく制限されています。そのため、大手企業や大手SIerは必要最低限の人員を社員として雇用し、それを超える開発力が求められるときは、外部（他社）からSESで調達します。案件が終了すれば契約を終了すれば足りるため、解雇制限にはかかりません。
SESは、ウォーターフォール型システム開発と日本の終身雇用制と相性の良い合理的な仕組みであると言えます。
SESのメリットとデメリット
SESのデメリット
多重下請けが多い
SESでは伝統的に多重下請けが盛んに行われています。これは、元請けから下請けにエンジニアの手配を依頼し、下請けに該当するエンジニアがいない時にさらに下請け（孫請け）に手配を依頼すると言う流れが常態化したものです。3次請けや4次請けは良い方で、多い時は8次請けや9次請けと言った事態も発生します。それだけ間に会社・営業が入るため、必要な情報が伝わるのに時間がかかったり、誤って伝わったりします。
近年、こうした多重下請けを防止するために労働局による二重派遣や偽装請負のチェックが厳しく行われています。また、大手システム会社から再委託を不可とする発注が増えています。ですが、今なお多くの違法な多重下請けが行われています。
給与が安い傾向がある
上記のような多重下請けで仕事を受注した場合、間の各企業にマージンが発生するため、エンジニアの所属する企業の受注単価が低くなります。受注単価が低くなると、エンジニアがもらえる給与の原資が少なくなります。また、SESと言うビジネスの特性上、品質の良いプログラムを作成しても、それがすぐに給与に反映されることはありません。長期案件であれば、年度末などに単価交渉が行われますが、経済状況に大きく左右されるため、必ずしも毎年あがるものではなく、給与に反映されるとも限りません。
ですが近年、受注単価を高めたり、コストを削減することで給与をあげようと努力するSES企業が増えつつあります。
案件ごとに環境が変わる
SESでは、案件ごとに通勤する場所が変わるのが一般的です。ある案件が終わり、次の案件が始まる時、人間関係をイチから作り直し、開発環境を構築し、新しい顧客の開発の進め方を理解しなければなりません。
特に人間関係については多くの人にとって大きなストレスになります。そのため、開発後の保守にそのまま入るなど長期案件を選び、環境が変わるのを避けるエンジニアの方もたくさんいます。
排除できないガチャ要素
SESでは、契約が終了に近づけば営業が次の案件を探してきます。会社によってはいきなり面談の日時を指定されることもありますが、多くの場合は営業から案件の概要が送られてきます。機密保持のため、非常に薄い情報が送られてくるため、詳細は面談で確認することになります。ですが、面談の時間内で確認できることは限られるため、案件に参画してから具体的なことが分かってきます。また、顧客側もエンジニアのスキルに対して過剰な期待をしてしまうことがあります。これらは、SESの経験者から「案件ガチャ」と呼ばれています。
中には、事前に可能な限りの情報を集めようとする営業もいますが、すべてを知ることは出来ないため、ガチャ要素が完全に排除されることはありません。
ただ、自社サービス開発や自社開発・社内受託にもガチャ的要素は存在すると言うことは知っておかなければなりません。
帰属意識が保てない
SESは現場に常駐するため、自社に出社することはほとんどありません。帰社日のミーティングや上司との面談もオンラインで行われることが多くなっている昨今、さらに少なくなっています。
そうした中で、経営層や社内にいるエンジニアとの方針や方向性があわなくなる可能性が高い業態であるといえます。会社の成長に貢献したいと考えるエンジニアは、自ら積極的に会社に働きかけない限り疎外感を感じるでしょう。一方で、自分の時間を大切にしたいと考えるエンジニアは会社からの働きかけを面倒と感じるでしょう。
スキルアップができない？
SESでは、大規模なシステム開発や大手企業のシステム運用の案件が多い傾向にあります。そうした現場では、枯れた（古いが安定している）技術を採用することが多くなります。そのため、最新の技術に触れたいエンジニアにとっては物足りないものであることが多くなります。また、書き方を細かく指定された設計書や操作説明書など、書類作成を求められることも多く、ExcelやWord、PowerPoint等と扱う機会も生じます。そうした作業にストレスを感じる方にとってはつまらない仕事に感じるかも知れません。
案件の一部にしか関われない
大規模システムのSESでは、機能ごとに違う会社が担当することが多く、システム全体の一部しか知ることができません。また、工程ごとに契約が行われるため、案件の最初から最後まで携わることはほぼありません。そのため、経験した案件の業務ノウハウを網羅して蓄積するのが難しい傾向にあります。
SESのメリット
過重労働が少ない
SESの特徴として、大規模なシステム開発や大手企業への常駐と言う点があります。そのため、大手企業の労務管理が適用されます。また、残業時間の上限を自社で取り決めた36協定を通知することが一般的で、36協定の上限を超える残業をすることはまずありません（あれば違法行為となり経営者が処罰の対象となります）。残業が少ないため、ワークライフバランスの充実や、スキルアップのための時間に充てることが可能です。ただ、SESにも現場の納期はあり、リリース前などは稼働が高くなることがあります。
案件を計画的に選びスキルアップできる
SESでは、事前に案件が選ぶことができます。上司や営業との間で、「こう言う案件をやりたい」と合意を得ておけば、それに近い案件に参画することが可能です。そのため、今はプログラミングをスキルを磨くと決めて案件を選び、後に設計スキルを磨くと決めて案件を選ぶなど、計画的なスキルアップが可能となります。
自社サービスや自社開発・受託開発では自分の意志で案件を選ぶことは難しいため、計画的にスキルアップを実現したいと考えている方にとってSESは大きなメリットとなります。ただし、すべてのSES企業が案件を選ぶことを許容するわけではないこと、事前に選んだものと実際に参画したものが同じ案件と思えないほどのガチャ要素があることは理解しておかなければなりません。
人間関係がリセットできる
SESでは、案件が終了すれば基本的に人間関係はリセットされます。自社サービスや自社開発・受託開発の場合、会社の同僚や上司に馴染めなかったとしても、退職するまでその環境を変えることはできません。その点、SESであれば「しんどいけど、あと◯日乗り切ればきれいに案件が終われる」と言う目標を持つことができます。また、事前に申し入れをすることで数カ月後に案件を抜けることも可能なため、心を病む前に手を打つことができます。
独立しやすい
SESは独立のハードルが低い業態です。SESで経験を積み、自ら顧客を見つけられるようになったらフリーランスとして独立する人も珍しくありません。SESはキャッシュフローが安定するため経営リスクが低く、独立を目指す人にとって有力な候補になります。
SES企業を見分けるポイント
給与・賞与
SES企業を見分ける際に、もっとも参考になるのは給与・賞与です。給与は、多重下請けのどの位置で受注しているのかに大きく影響を受けます。下請けの深い層で受注している会社の給与は平均的に安く、将来的なアップもあまり見込めません。とんでもない安月給で求人している会社は要注意です。
また、下請けの層が深くなくても給与が安い企業や業績の厳しい企業は、福利厚生や経費など給与とのバランスに着目してみてください。
「高還元SES」は諸刃の剣
最近、「高還元SES」を謳う会社をよく見かけるようになりました。70％や80％、場合によっては90％と言う会社もあります。
まず、このパーセンテージを鵜呑みにしてはいけません。この表現には法的な制限がなく、会社で自由に設定して書くことができます。パーセンテージが高くとも受注額が低い可能性が排除できません。また、受注額の90%を給与として払えば、社会保険料の負担により企業は赤字に陥ります。計算方法のヒントになる記述がどこかにあるはずです。どう言う計算方法でそのパーセンテージを実現しているのか確認するようにしてください。
また、高還元を実現しながら会社を維持するためには「薄利多売」が求められます。ひとりひとりの利益額が小さいため、大勢のエンジニアを雇用し、SESで現場に出さなければ会社を維持できません。そう言う会社が、エンジニアひとりひとりの希望・要望に対してどこまで労力を割くことができるのかと言う観点で会社を見極める必要があります。
従業員数の書き方
会社案内やウェブサイトで、従業員数にパートナー（協力会社のエンジニア）の人数を記載している会社は注意するべきです。受託や自社サービスのないSES専業の企業が過剰なパートナーを抱えていること自体、違法契約の可能性があります。コンプライアンス意識の希薄さから自社の社員に対する扱いも透けて見えてきます。加えて、パートナーの人数を足してでもより大きく見せようとする姿勢が誠実さを欠きます。人生の貴重な時間を預けるにはあまりにもリスクが高いを言わざるを得ません。
従業員数と売上の比率
自社サービスや受託開発のないSES専業の企業で、従業員の数に対して売上が高すぎる場合も注意して見た方が良いです。SESビジネスには「仲介ビジネス（パートナービジネスと呼ばれたりします）」が相当な割合で含まれています。こうした仲介ビジネスは違法であるだけでなく、仲介による売上が多い会社は多重下請けの深い層での受注に抵抗がありません。元請けのSIerなどは労働局の監視が厳しく、仲介ビジネス（パートナー）を受け入れていない会社が増えているからです。また、そう言う会社の営業は仲介ビジネスに忙殺されています。そのような会社に手厚いフォローやスキルアップのための案件選択を求めることは難しいと考えるべきです。会社の売上から社員の数で平均単価から計算してみて、あまりに高い時は仲介ビジネスによる売上かもしれません。
ただ、本当によい顧客との取引を行っているSES企業も従業員数に対して売上が高くなります。どちらであるかは注意深く見てみる必要があります。
評価基準
SESは売上が直接個人に紐付きます。そのため、売上と給与が連動する評価制度を持っている会社があります。どういう基準で評価されるのか、分かるのであれば事前に調べておくのが良いでしょう。
ただ、売上と給与が連動していない会社もたくさんあります。そう言う会社は、求人情報や口コミサイトなどで昇給の情報がないかよく調べてみる必要があります。給与の低いSES企業は、信じられないほど低い場合があります。SES企業の退職理由の多くが給与であることを意識して調べたい項目です。
取引先
エンドユーザーや大手SIer等の有名企業と取引があるかどうかも念のため確認しておくべきです。特にエンドユーザーが複数ある会社は営業力があると推測出来ます。ただし、1度だけ取引した有名企業を優先して掲載すると言ったことが普通に行われているため、鵜呑みにはできません。面接時に、どんな案件が多いのか等、工夫して聞いてみると良いかもしれません。
SESに向いている人
環境の変化に対応できる人
SES企業に勤めている以上、現場の移り変わりは避けて通れません。その都度、新しい現場に通い、新しいリーダーにつき、新しい仲間とともに働かなければなりません。現場ごとに開発環境やドキュメントの書き方、考え方が違います。それらを受け入れることがSES企業で働く上で最初であり最大のハードルかも知れません。
ただ、自社サービスや社内開発にはない様々な経験を得られるには違いありません。それを前向きに捉えられる人はSESに向いている人といえるでしょう。
契約を意識して行動できる人
SESでは、客先に常駐することが基本となるため、自分がどこに所属しているのかの意識が曖昧になりがちです。そのため、顧客の指揮命令や納期について誤った認識を持ってしまうことがあります。自分が準委任契約で来ているのか、派遣契約で来ているのかを意識することで自分を守ることができます。自分がだれの指揮命令を受け、責任範囲がどこまでなのかを認識することで顧客との関係を円滑にし、自分を守ることができます。
計画的にスキルアップにとりくめる人
SESでは案件ごとに環境が変わるため、自分がどうなりたいかを明確にして関係者に伝えておく必要があります。それが出来なければ、同じような案件をグルグルすることになります。SESではスキルアップできないと言われる理由はここにあります。営業はわざわざ苦労したくないので、できるだけ簡単に決められる案件にアサインしようとします。すると、今持っているスキルや経験で対応できる案件ばかりに行くことになります。楽をしたい時にはそれでも良いでしょうが、スキルアップしたいときは、熱意を持って自分の希望を伝え、上司や営業を動かしていくことが望まれます。
現状を改善する力がある人
SESでは、案件ガチャと呼ばれるものがあり、これは減らすことはできてもなくすことはできません。ガチャにハズレてしまった場合、ハズレをただただ受け入れるだけでなく、自らまたは関係者を巻き込んで改善する力が求められます。しんどい案件を受け入れて潰れてしまったエンジニアは数知れません。
