SESエンジニアの残業について思うこと
「エンジニアの残業が多いと、自社が客先に請求できる金額が上がるから自社は儲かる。だから自社は残業を減らそうとしない。」みたいな話。
私がエンジニアだったころによく周りから聞きました。でも実際にこうやって経営してみると残業は百害あって一利なしだなと感じます。
今回は残業問題について思うことを記事にしてみました。
残業は良いこと無し
なんて大雑把に言うと反論がありそうですが、でも本当に良いことってあまりないんですよね。
エンジニアが体調を崩す
エンジニアの離職率が高まる
エンジニアの家族から恨まれる
請求、給与計算が複雑になる
社会保険の負担額が上がる etc…
企業側からすると、残業で売上をちまちまと上げることよりもエンジニアに気持ちよく働いていただいて、エンジニアの定着率が上がった方が長期的に利益は大きくなります。
最悪のケースとしてエンジニアにメンタル不調を起こしてしまった場合、求職中にもコストは発生しますし、退職した場合は人材投資は回収不可となります。
エンジニア自身なりたくもない病気になってハードモード突入です。癒えたようで癒えていなかったりと、メンタル不調は長期に渡り非常に厄介な問題として付きまといます。だから、そもそも決して不調に陥らないように事前に対策することが大事です。残業を減らすことはエンジニアと企業の双方にメリットがあるのです。
（ちなみに残業とメンタル不調の相関には明確なエビデンスが存在しません。ですが残業による睡眠・食事の質の低下が起因してメンタル不調を起こすことにはエビデンスがあるようです。引用：東京医科大学）
ビジネスサイドとしては『納期を守ることや、品質を高めるために残業をしなければならない場面もある』という意見があります。
その通りだと思います。なので残業は完全に無くすことは難しいでしょう。
ですが、それは『結果として残業が発生してしまう』というものであって、『残業が素晴らしいものだ』という話にはなりません。残業自体が素晴らしいものという意見があれば聞いてみたいです。
まあそんなわけで、私としては残業は必要悪のようなもので、基本的には良いことないなと感じている次第です。
弊社ケルンの場合
直近1年間（2023年）のエンジニアの平均残業時間は下記の通りです。
※フレックス制
1月：2.32H（18名対象）
2月：1.04H（18名対象）
3月：3.84H（19名対象）
4月：2.78H（21名対象）
5月：3.44H（25名対象）
6月：3.8H（25名対象）
7月：2.08H（26名対象）
8月：1.62H（28名対象）
9月：2.58H（32名対象）
10月：3.14H（34名対象）
11月：4.37H（36名対象）
12月：2.13H（38名対象）
平均：2.76H/月
従業員数が少ないから管理がしやすいと思われるかもしれませんが、7月頃からツールを導入したことで従業員数が増加しているにも関わらず残業時間は減少傾向です。ツールには残業時間の増加傾向を検知する仕組みが備わっています。
弊社ケルンでは基本的には残業はNGとして、エンジニアや常駐先のお客様と協力しながらエンジニアの健康の基礎を守っています。
残業時間を減らすための対策
弊社ケルンでは下記のフローに従って残業対策しています。
最後に弊社の残業に対する姿勢ですが、以下の順にいつも対応しています。
— 川嵜大樹@ケルン (@cairndk) January 17, 2024
（0.案件参画時にある程度の合意を取る）
1.法律に違反していないかどうか確認
2.エンジニア自身がどうしたいか確認
3.現場と調整＆エンジニアとルールの設定
4.ルールの運用と経過観察
5.改善が無ければ退場調整
■残業対策のフロー
0.案件参画時にある程度の合意を取る
------残業増加を検知-------
1.法律に違反していないか確認（＝事実調査）
2.エンジニア自身がどうしたいか確認
3.現場と調整＆エンジニアとルールの設定
4.ルールの運用と経過観察
5.改善が無ければ退場調整
順番に解説していきます。
0.案件参画時にある程度の合意を取る
案件を決めるタイミングで現場に稼働実績を確認し、稼働実績からある程度の残業時間を想定しエンジニアに伝えています。エンジニアにとって許容範囲内であれば参画決定です。NGであれば再調整となります。
残業時間ではなく稼働実績を確認することがポイントです。相手方の営業によっては、成約を優先するあまりいい加減なことを言う方もいます。また、「多くないよ」と言われた場合に、これは主観になりますので不正確です。
初めに合意形成をしておくことで後々に残業が増加することがあれば論理的に交渉できます。多い少ないという主観ではなく数値で合意を取り、両者が分かるようにメール等でエビデンスを残しておくことが重要です。
1.法律に違反していないか確認（＝事実調査）
前項を経て残業がエンジニアの許容範囲を超えた場合には、まずは法律的な観点で違反がないか確認します。
例えば36協定を超過していないか、サービス残業がないか、現場で残業を強要されていないか等です。確認の方法としては、勤怠情報を使いつつエンジニアとの打合せ、現場への事実確認を行います。
法律違反があった場合には直ちに是正します。これがまず最優先となります。
また、事実確認のポイントとしては『商流』『登場する会社名・人物名』『チーム構成』『リーダーやメンバーの性格』『どんな業務があって、どんなやりとりがあって残業が発生しているのか』『エンジニアが感じていること』これらの情報を細かく具体的に確認します。
細かく具体的に確認することで『残業が増加している』というぼんやりした事象に実状としての輪郭が浮かび上がります。この工程がないと、エンジニアの残業調整を行う担当者が上位の営業と交渉する際にも、現実的な提案が出来ず『実状が分かっていない外野』として相手にしてもらえません。
2.エンジニア自身がどうしたいか確認
お客様と交渉する上でまずはエンジニアがどんな決着を望んでいるのか確認することが必要です。残業を無理やり減らしても、例えば現場のチームで孤立してしまうことがあればエンジニアは気持ちよく働けません。
残業時間を減らすことが目的ではなく、エンジニアが働きやすい環境を整えることが目的ですので、ここはエンジニアとの相談が重要です。
また、エンジニアが望む形が良い結果を生まない可能性が高い場合もあります。そのため、『ヒアリング』ではなく『相談』という表現を使っているように、会社からも意見を出します。
以下、よくあるケースです。
Aさんの場合
「仕事が楽しくて仕方ないです！残業とか気にしないから放っておいて！」このようなケースでは、36協定違反にならないようにエンジニアに指導しつつ、定期的に簡単なヒアリングを行うなどして体調に問題が無いか確認します。
Bさんの場合
「残業は嫌だけど、チームで気まずくなりたくないです。自分が我慢すれば解決するならそれで良いです…。」
このようなケースでは、エンジニアの『仕事を断る力』が不足しているため、会社間で残業を減らす調整をしつつ、エンジニアに対しても断り方の指導を行っていく必要があります。自身のキャパシティを越えていてもチームメンバーを気遣うあまりに無限にタスクを受けてしまうため、いずれメンタル不調を起こしてしまいます。一番怖いケースです。
Cさんの場合
「残業は嫌だけど、自分の技術力が足りないから仕方ないと思ってます。」
若手に多いケースです。現場で求められるレベルに自身の技術力が追い付かないという問題ですね。この場合には単価を下げることで現場での業務レベル落とすか、エンジニアの技術力を現場水準まで高めていくことが必要です。前者はともかく、後者は一朝一夕にしてならず、難易度が高いです。
資格取得の推奨、社内の有識者と相談できる環境を作る、勉強会を開く等しつつエンジニアの技術力の底上げを図り、中長期的に残業時間の改善を図っていきます。個人的には単価を落として、その後の成長に合わせて単価を少しずつ戻してもらう形が無難と思ってます。（当然、お客様の理解を得られなければ退場ということになります。）
3.現場と調整＆エンジニアとルールの設定
前項を経て、法律違反のない健全な残業であることと、エンジニアがどういう決着を望んでいるかということが分かりました。ここからはお客様と実際に調整を行っていきます。
ただし、「減らしてください。」とざっくりお願いするわけにもいきません。『今後はこういう形で業務したい』という具体的なお願いをして、お客様にそれを受け入れていただけるか伺います。
例えば「月の残業は20Hまでにさせてください。」「深夜残業は基本NGとしさせてください。」等、要望を具体化します。
更に、エンジニアとの間にルールを設ける必要があります。ルールは要望を叶えるための具体的な手段です。
要望：月の残業は20Hまで。
ルール：残業は週に5Hまで。5Hを超える場合はタスクを断る。
要望：深夜残業は基本NG。
ルール：深夜残業は事前にバックオフィスに事情を報告。
仮に発生する場合は翌日にAM休を取得する。
上記のようにルールを決めておくとエンジニアとしては動きやすいです。また、お客様の合意を得ておくことで、残業を断る際にエンジニアは自社を言い訳に使えます。メンバーからの批判はエンジニアではなく会社間のルールに向き、エンジニアのチーム内での孤立を避けられます。
ルールの設定にはもうひとつ重要な意味があります。後述予定ですが、そもそもSESエンジニアの契約形態である準委任契約では勤怠管理の責任を雇用主（＝自社）が持つため、残業を減らしてくださいとお客様にお願いすること自体が実は的外れとなります。
お客様には「こういうルールに従って動くのでお力添えいただけますか。」という風に、ある種こちらの宣言を受け入れていただけるかを確認する形になります。そのため、お客様からしたら「勝手にどうぞ。」という感覚が強く、残業を減らすということはお客様がエンジニアの実力を加味して丁度良い量のタスクをエンジニアに振り分けるという解釈にはならないことに注意が必要です。
重要なのでもう一度お伝えします。残業を減らすという調整は、お客様には本来無関係であり、お客様が調整することではなく自社＆エンジニアが調整すべきことです。そのため、お客様がいい感じにタスク量をコントロールしてくれるだろうという意識を我々が持つと非常に危険です。お客様はこれまで通りに業務をされることが前提で、変えるべきは自分たちの行動なのです。
よくあるパターンとして、お客様から残業を減らす旨の合意が得られているにも関わらず、なかなかエンジニアの残業が減らないということがあります。エンジニアにヒアリングすると「全然業務量が減らないんです。」と。
お客様としては「残業するかしないかはそっちの責任範囲なのだから、勝手に調整してよ。」と考えており、エンジニアがお客様の行動変化に期待してしまうといつまで経っても残業が減らないということになります。
エンジニアは残業をしない選択をした以上、自身のキャパシティを管理して、キャパシティを越えた仕事を断ることが重要です。そのための『ルール設定』ということになります。
4.ルールの運用と経過観察
ルールとは決めることは簡単ですが守ることは難しいものです。気を抜くとすぐに形骸化します。
エンジニアは常にお客様先で気を遣いながら仕事をしているため、ついつい状況に流されてルールを守れないこともあります。残業調整の担当者はルールを設定して終わりではなく、エンジニアがルールを守れるように経過観察とフォローをしていく必要があります。
ルールを守ることはエンジニアの負担が大きいです。この点に留意し、残業調整の担当者にはエンジニアの勤怠を確認し、異常があればすぐにヒアリングを行うなど、エンジニアと二人三脚する意識が必要です。
また、ルールは、守ったり守らなかったりだと意味がありません。ルールを守ることはお客様に正確な工数をお伝えするチャンスでもあるからです。
例えば、作業量に対してチーム人数が適正であるかお客様が判断する場合に、仕事が毎月きちんと完了していれば増員の必要はないという判断になってしまいます。エンジニアがルールに従って過度な業務を断っていくことで、お客様の中に『仕事が回らない』という認識が生まれ、増員や人の入れ替え等のマネジメントが働きます。無理にやりきらないことは大事です。
私はエンジニア時代、常態化した残業については徹底的に断っていました。次第にチームもその状況に慣れて、とやかく言われなくなります。『定時後の川嵜には期待できない』という前提で仕事が周り始めるわけです。
ルールもまた、始めの1か月は何かと大変なのですが、2か月・3か月経つにつれ、周囲もその状況に慣れてあたり前のこととして受け入れます。なんとか、この状況に持っていきたいものです。
5.改善が無ければ退場調整
ここまでのお話はある種の理想論でもあります。現実はうまくいかないことも多くあります。人間である以上、理論より、どうしても感情が先走ってしまうものです。
調整に力を尽くしたものの、なかなか状況が改善しない場合には潔く撤退です。体調を崩す前に撤退です。調整を続けるコストも半端ではありません。撤退です！
法律とか契約の話
そもそもSESエンジニアってどういう立場で働いてるのよって話です。
自社（エンジニアの所属会社）と、現場（エンジニアの常駐先の会社）とエンジニアの関係性を下図にまとめました。
・SESエンジニア
自社と雇用契約がある。現場と契約はない。
・自社と現場
準委任契約がある。
準委任契約を横文字で格好良くしたのがSES（System Engineering Service）契約です。なので実態は準委任契約です。
つまりSESエンジニアは自社と現場の間に結ばれた準委任契約に従って客先に常駐し技術提供をしています。
準委任契約では受託会社が作業時間の管理を行う
受託会社とはお客様からの委託を請けた会社、つまり自社のことですね。準委任契約では自社が作業時間の管理を行います。残業する・しないという選択は完全に雇用主である自社がその権利を握っていることになります。
仮に委託会社である会社、つまり現場が残業の指示を行った場合には労働者派遣法違反となります。
準委任契約では成果物の完成責任は問われない
「残業しなくてもいいよって言われても、じゃあこの目の前の仕事どーすんねん。」という疑問もわいてきます。エンジニアからすると自身が残業をしなければ完了しないという仕事も多々あることでしょう。
ですが、準委任契約では成果物の完成責任がないため、残業をしないことで本来完成するはずだったシステムが完成しなくとも、その責任をエンジニアや自社が負う必要はありません。
他社のプロジェクトマネジメントの配下に置かれる時点で、受託会社（＝自社）が成果物を完成させる責任を負うことはかなり無茶な話です。例えば、納期に対して工数の見積もりが明らかに足りていない場合や、PMや他メンバーの実力不足がある場合、こちらのエンジニアがいかに適正に働いていたとしても環境要因でプロジェクトが失敗します。その責任を受託会社が負うのであれば、無茶ぶりで損害賠償請求し放題になってしまいます。
そもそも様々な会社のエンジニアが細分化された作業を一緒に行うため、責任範囲・成果物を定義することも困難です。そのため、準委任契約では委託会社に対し、結果とは無関係にあらかじめ定められた作業時間で常識的なレベルの技術やサービスを提供することが求められています。
例外として、エンジニアが通常要求されるレベルのサービスを提供できない場合には責任を問われる可能性があります。（民法644条：善管注意義務）
また、成果完成型の準委任契約では特定の条件において成果物の完成に対して責任を負います。（民法415条：債務不履行責任）
自社が残業NGの方針なら残業は減らせる
先述の通り、準委任契約では残業指示の権利は自社が握っており、かつ仕事の完成に責任を負う必要もないため、自社が残業はNGと判断をした場合、現場にとやかく言われる筋合いはないということになります。
ですが、契約を振りかざしてひ〇ゆきのごとく正論で相手を叩きつぶそうとして、お客様と正常な関係性を保てるはずがありません。お客様との関係の悪化は契約の解消（＝退場）のリスクや善管注意義務違反・債務不履行による損害賠償請求を受けるリスクがあります。だからこそ、自社は主導権を握りつつも、お客様とは相談という形で慎重な調整を行います。
なお、残業指示の権利は自社が握っており、これは逆に言うと『会社が残業しろと言えばエンジニアは残業しなければならない』ということでもあります。残業は体調不良等の特別な事情が無い限り、原則、断ることができません。
・自社が残業NGと判断すれば残業はしなくても良い
・自社が残業OKと判断すれば原則、残業はしなければならない
・残業調整はお客様との関係悪化（＝退場、損害賠償）のリスクを伴う
上記を考えると、エンジニアは所属会社の残業に対する方針を確認しておくことが大事でしょう。
弊社ケルンの方針
常態化した残業はNG、突発的な残業はOKとしています。
常態化した残業とは、残業が毎日のように発生していて、改善される見込みのない場合のことです。例えば仕事量が多すぎるとか、常駐先の企業文化として残業が当たり前の空気になっているとか。
このような場合には巻き込まれるとエンジニアが潰れてしまうことが目に見えています。自社の動きとしては、増員の提案もしますが基本は徹底的に自衛です。全力でエンジニアの健康を守ります。渦中のエンジニアは自分でも気づかないうちに精神がズタボロになってしまうこともあるため、エンジニアにウザがられるとしても本気で対応します。メンタル不調はなってからでは遅いため、割と元気に働けているうちでも調整します。
突発的な残業とは、例えば現場のチームメンバーが体調不良で休んだとか、納期に作業が追い付いていないとか、トラブルが発生して緊急対応をしなければならないとかですね。一緒に働いている方が困っている時は助けましょう。じゃないと自分が困っている時に助けてもらえないです。という精神ですね。
でも、突発的な残業は頻度が少ないです。結果、ケルンではほとんどのエンジニアが定時に帰宅しています。一部の残業ウェルカムなエンジニアと、調整の真っただ中にあるエンジニアによって平均残業時間が少し押し上げられ『平均：2.76H/月』という実績に収まっています。
まとめ
SESエンジニアの残業はエンジニアにとってはもちろんのこと、自社にとってもメリットは少ない。
準委任契約（＝SES）では残業指示の権利を自社が握るため、自社が残業NGの方針であれば残業は減らせる。逆に、自社が残業OKの方針であればエンジニアは従わなければならない。
準委任契約（＝SES）では成果物の完成責任は問われない。エンジニアが残業を拒否したことで成果物が完成しない場合でもエンジニアが責任を負う必要はない。ただし、エンジニアが通常求められるレベルのサービスを提供していることが前提となる。
SESエンジニアは残業を減らしたければ、現場環境の変化に期待するのではなく、残業NGを方針としているSES企業に所属することが重要となる。
派遣契約・業務請負契約の場合とか残業に関する細かい話はまだありますが、キリがないので今回はSESエンジニアに限定してお話しました。また別の記事で拾うこととします。
ここまで読んで下さりありがとうございました！
最後に宣伝 /インフラエンジニア募集中★
筆者が代表を務める株式会社CAIRN(ケルン)はインフラエンジニアに特化した高還元SES企業です。
・ 契約単価に連動した報酬体系なので評価基準が明確です。
・ITインフラに強い営業網で豊富な案件からプロジェクトを選べます。
・ 独自の研修制が多数あり、学びなおしが出来ます。
・厚生労働省認定のホワイト企業です。
公式LINE始めました！
インフラエンジニアのキャリアアップに役立つ無料レポートプレゼント
ケルンの公式LINEでは登録者限定で以下の３つを無料でプレゼントしております！
※LINE登録後すぐにお送りいたします。
------
◯駆け出しインフラエンジニアにおける資格の重要性
※どの資格を取ればキャリアアップしやすいかが分かる
◯新インフラエンジニアのキャリア戦略
※生成AI時代のインフラ・クラウドエンジニア生存戦略が分かる
◯ネットワークシミュレーション課題
※ネットワーク設計構築の実務が知れる
------
特にこんな方におすすめ
✅クラウド・サーバエンジニアとしてキャリアアップしたい
✅年収アップしたい
✅ネットワーク設計構築の実務を知りたい
✅現在転職活動中だがどんな会社に入れば良いか悩んでいる
また、公式LINE上ではインフラエンジニア勉強会イベント情報なども発信しております。
ご興味ございましたらお気軽にご登録ください。
こちらをタップ（クリック）して友達登録できます！
この記事が気に入ったらサポートをしてみませんか？