SESの勤怠不良は、改善を待たずに交代になる｜要員を交代させる側のSES経営者の処理は「謝って他の要員を探す」だけだった

筆者は要員を交代させる側として、この記事を書いています

筆者はJavaに特化したSES企業を経営しています。SESとは、技術者を客先に常駐させて業務を提供する契約形態のことです。案件を発注し、要員を案件に入れ、契約を切る判断をするのが筆者の立場です。同時に、筆者はフリーランスエンジニアとしても稼働しています。

そのため、読者から見れば筆者は交代させる側です。この記事の内容は、2026年11月取得の運営者本人の記録（取得日2026-11-03）に基づいています。ただし、これは筆者の会社の処理であり、業界の一般則ではありません。

この記事は読者を責めるものではありません。勤怠トラブルが起きたときに、発注側でどう処理されているかを事実として書きます。記録にない部分は、記録にないと明記します。

2026年11月取得の運営者本人の記録では、要員のトラブルは「勤怠系とスキル不足がほとんど」とされています。

ここでの「ほとんど」は、筆者の体感による概数です。件数を数えた値ではありません。割合や件数は記録に残していません。

勤怠系については、特定の1種類ではなく、遅刻・欠勤・連絡なしのすべてが起きていました。どれか1つだけが問題になったわけではない、という点が記録から読み取れます。

2026年11月取得の運営者本人の記録では、勤怠トラブルへの処理は次の1つだけです。

クライアントに謝って、他の要員を探す。

ここで重要なのは、その前の工程が記録にないことです。本人への指導や猶予があったかどうかは、記録に残していません。交代させる前に本人へ警告したかどうかも同様です。要員が突然来なくなった例があるかも、記録にありません。

記録にあるのは処理だけです。その前段は、筆者の記録からは書けません。

勤怠トラブルの処理が交代しかないなら、記録からは改善を待つ工程が見当たりません。筆者はこれを、勤怠は挽回の機会が設計されていない項目だと読んでいます。これは筆者の判断です。

スキル不足については、現場で露見したときの処理が記録にありません。勤怠と同じ処理なのか、違うのかは確認できていません。そのため、勤怠とスキル不足を比べて「どちらが重い」と断定することはできません。

交代に至る回数や閾値も、記録にはありません。何回遅刻したら交代になるといった基準は、この記事では書けません。「一度でも遅刻したら切られる」とも言えません。

体調不良や事情のある欠勤を、一律に問題として扱う意図もありません。ここで書いているのは、筆者の会社の処理の記録だけです。

契約終了の通告のタイミングも、2026年11月取得の運営者本人の記録に含まれています。理由によって、読者に残る時間は次のように分かれます。

終了の理由	通告のタイミング（記録）
案件側の都合（フェーズ変更・減員）	基本3ヶ月前
勤怠などトラブル系	当月

通告は、基本的に営業から伝わります。現場から伝わるのではありません。

勤怠が原因の場合、次の案件を探す準備期間はほぼ残りません。筆者の判断では、勤怠は技術で後から挽回できる項目とは言えません。自分の状況を測るときは、この点を前提に考えてください。

ただし「3ヶ月前」が契約上の通知期間なのか、運用上の慣行なのかは記録に残していません。営業から伝わるときに、理由をどこまで本人に話すかも未確認です。契約終了のタイミングについては、別の記事で扱っています。

面談で見られている点と、稼働後に切られる順番の基準は、筆者の記録では重なっています。面談の見られ方はSESの面談で落ちる理由、営業側の報連相の基準はSES営業は無能が多いが2割は優秀を参照してください。