SESで入ってもらったエンジニアの更新時期が近づくと、「続けてもらうか」を判断する材料を求められます。 ところが、現場に聞いても「よくやってくれていると思います」「ちょっと遅い気がします」といった感想しか出てこず、何を根拠に判断すればよいのか分からないまま、結局そのまま更新している会社は少なくありません。
かといって、社員と同じ評価シートで採点して本人に伝えればよいかというと、SES（準委任）ではそれが別の問題を生むことがあります。 この記事では、SES事業と受託開発の両方を手がけるCoconutWorksが、更新を判断する手前で何を見ておくか、見たものを誰にどう伝えるかを整理します。 更新・終了の手続きそのものはSES契約の更新・終了で発注側が注意することで解説していますので、あわせてご覧ください。
結論: 人ではなく「任せた業務」を基準に5つの視点で見る
| 視点 | 何を見るか | 見誤りやすい点 |
|---|---|---|
| 任せた範囲の進み具合 | 合意した業務が、約束した時期に対して進んでいるか | 「忙しそう」「遅くまで作業している」を進捗と取り違える |
| 報告と見通し | 状況・遅れ・懸念が、手遅れになる前に共有されるか | 報告の上手さと業務の進み具合を同じものとして見てしまう |
| 作業の質と手戻り | レビューでの指摘の内容、手戻りが起きた理由 | 手戻りの回数だけを数え、仕様変更など原因の違いを見ない |
| 周囲にかかる負担 | 社内の担当者の確認や説明にどれだけ手間がかかっているか | 質問が多いことを、それだけで力量不足と判断する |
| 引き継げる状態か | 手順・判断の経緯・注意点が、本人以外にも分かる形で残っているか | 問題なく回っているうちは確認せず、終了間際に気づく |
要点は2つあります。一つは、本人の印象ではなく、合意した業務がどう進んでいるかを基準にすること。 もう一つは、見た内容は本人に直接評価として伝えず、ベンダーの窓口や責任者に事実として伝えることです。 以下、なぜ印象で決まりやすいのかというところから順に掘り下げます。
なぜSESの評価は印象で決まりやすいのか
社員であれば評価の時期と項目が決まっていて、上司が見る仕組みがあります。一方、SESで受け入れたエンジニアには、発注側にそうした仕組みがないのが普通です。 契約の主な手続きは総務や管理部門が持ち、日々の様子を知っているのは現場の担当者、という分担だと、更新の時期に初めて「どうですか」と現場に聞く流れになりがちです。聞かれた側は、直近の出来事と全体の印象で答えるしかありません。
印象には偏りが出ます。たとえば、よく話しかけてくれる人は「頑張っている」と見られやすく、静かに黙々と進める人は「何をしているか分からない」と見られやすくなります。 直前に起きた障害の対応が記憶に残って、それまでの積み重ねが評価から抜け落ちることもあります。 業務の進み具合と、周囲からの見えやすさは別のものですが、基準がないと後者で判断してしまいます。
さらにSESならではの事情として、準委任は成果物の完成ではなく業務の遂行を約束する契約です。 請負のように「納品物が検収を通ったか」という明確な節目がないため、良かったのか悪かったのかを見る基準を、発注側があらかじめ言葉にしておかないと生まれません。 契約の仕組みそのものはSES（準委任契約）とはで解説しています。
評価の前に確かめる: 何を任せたことになっているか
評価でいちばんつまずきやすいのは、期待していたことと、契約で任せたことが一致していない場面です。 面談で聞いた経歴から「これもできるだろう」と期待が膨らみ、スキルシートの内容が頭に残ったまま、実際に合意した業務範囲は確かめずに「期待したほどではない」と感じてしまう。 この場合、問題は本人の力量ではなく、依頼の前提にある可能性があります。
そこで、評価を考える前に確認したいのが3点です。契約書や注文書に書かれた業務範囲、稼働前の説明や面談で合意した役割、そして現在実際にお願いしている作業です。 この3つを並べると、ずれが見えることがあります。たとえば機能開発の支援として入ってもらったはずが、気がつけば問い合わせ対応と資料作成に時間の多くを使っていた、という場合、機能開発が進んでいないことを本人の評価に結びつけるのは筋が違います。
この確認がしやすいかどうかは、受け入れの時点で決まっています。最初に任せる作業や確認の仕方を決めておくと、後で振り返る基準がそのまま残ります。 まだ整えていない場合は、SESエンジニアの受け入れ準備の「立ち上がりの見方」を参考に、途中からでも言葉にしておくことをおすすめします。面談で確かめる内容はSESの面談で発注側が確認すべきことで扱っています。
5つの視点で稼働を見る
任せた範囲の進み具合は、約束した時期に対してどこまで進んでいるかを見ます。 稼働時間の長さは基準になりません。準委任では稼働時間が精算に関わるため気になりやすいのですが、遅くまで作業していることは、進んでいることも、詰まっていることも意味します。 チケットや作業一覧があれば、完了したものと止まっているものを見れば足ります。なければ、まず「今月お願いしていること」を文字に残すところから始めると、以後の確認が楽になります。
報告と見通しは、技術に詳しくない担当者でも確かめやすい視点です。 見たいのは報告の丁寧さよりも、悪い知らせがいつ届くかです。期限の直前になって「間に合いません」と分かるのと、早い段階で「この部分が読めないので、ここまでは確実に進めます」と共有があるのとでは、発注側に打てる手がまるで違います。 報告の形式はベンダーとの合意で決まるものなので、期待に届かないと感じたら、形式を整えてもらうようベンダーに相談する余地があります。
作業の質と手戻りは、回数よりも理由を見ます。 同じ「手戻り」でも、仕様が後から変わったのか、確認せずに思い込みで進めたのか、確認したが依頼側の説明が食い違っていたのかで、意味がまったく変わります。 レビューの指摘が同じ種類で繰り返されているかどうかも手がかりになります。実装の質まで見たいときは、社内の技術担当にレビューを頼むか、担当者がいなければ外部の第三者に見てもらう方法もあります。
周囲にかかる負担は、社内の担当者が確認や説明にどれだけ時間を取られているかです。 ここで誤解しやすいのが、質問の多さです。入ったばかりの時期に質問が多いのは、むしろ前提を確かめながら進めている表れかもしれません。 気にしたいのは、一度答えたことを繰り返し聞かれる場合や、確認すれば防げた作業のやり直しが社内の負担として返ってくる場合です。
引き継げる状態かは、順調なときほど見落とされます。 設定の手順や判断の経緯が本人の頭の中にしかないと、その人がどれだけ優秀でも、抜けたときに社内へ負担が残ります。 完璧な資料である必要はなく、後任が迷いそうな点が文字で残っていれば十分です。文書を残す作業が業務範囲に入っていないなら、それは評価の対象ではなく、依頼として追加を相談する事項になります。
本人のせいとは限らない: 自社側の原因を先に切り分ける
よくある失敗が、進みの遅さをそのまま本人の評価にしてしまうことです。 SESのエンジニアは社内の事情に手が届きにくい立場にいるため、自社側の問題が、本人の遅れとして見えることがよくあります。 権限の申請が通らず数日待っていた、仕様の確認を投げたまま社内で止まっていた、複数の部署から別々の依頼が入って優先順位が定まらなかった、といった場面です。
切り分けは難しくありません。「遅い」と感じた作業を一つ選び、着手から完了までのどこで時間がかかったかをたどります。 待ち時間の大半が社内の承認や回答待ちであれば、直すべきは自社の進め方です。ここを飛ばしてベンダーに不満を伝えると、後任に代わっても同じことが繰り返されます。
依頼の窓口が整っていないことも、切り分けの場面でよく見つかります。社内の複数の人から直接依頼が届いている状態は、評価がぶれる原因になるだけでなく、誰が指示を出しているのかが曖昧になり、契約の実態と合わなくなるおそれもあります。 エンジニアの評価を考えていたはずが、自社の依頼の出し方を見直すきっかけになる、というのは珍しくありません。
見た内容を誰にどう伝えるか: 直接評価しないための線引き
評価の中身と同じくらい大切なのが、伝え方です。 厚生労働省の区分基準（昭和61年労働省告示第37号）では、労働者派遣と請負を区別する判断項目の一つに、労働者の業務の遂行に関する評価等に係る指示その他の管理を、受託側が自ら行うことが挙げられています。 同省の疑義応答集（第3集）では、システム開発の準委任についても、契約の形式ではなくこの基準にもとづいて実態で判断されるとしています。
実務に置き換えると、たとえば発注側の管理職がエンジニアと評価面談を開いて点数を伝える、発注側が作った評価シートで採点して本人に改善目標を指示する、といった形は避けたい運用です。 一方で、依頼した業務の進み具合を確認すること、報告を受けること、成果物が合意した内容に沿っているかを確かめることは、発注者として当然の確認といえます。業務の状況を確かめることと、人を評価して管理することは分けて考えると整理しやすくなります。
伝える相手はベンダーの窓口や責任者です。その際は「対応が遅い」といった評価の言葉より、「◯月の△△の作業が、当初の予定から遅れている。理由の共有がなかった」のように、業務の事実として伝えるほうが、受け取った側も確認や改善に動きやすくなります。 本人へのフィードバックや目標設定は、ベンダー側の役割です。良かった点も同じ経路で伝えておくと、本人にきちんと届きやすくなります。
もちろん、日常の中で「助かりました」と声をかけることまで問題視する必要はないでしょう。線引きの具体的な判断は個別の実態によって変わるため、微妙な場面は契約形態に詳しい専門家や都道府県の労働局に確認してください。
更新判断につなげる進め方
ここまでの内容を、大がかりな仕組みなしで回す順序にまとめます。兼務の担当者でも続けられるように、書く量は最小限で構いません。
- ①任せていることを短く書き出す — 契約の業務範囲と、現在お願いしている作業を並べ、ずれがあれば先に解消するか、ベンダーと合意し直す。
- ②現場の担当者に5つの視点でメモを取ってもらう — 点数ではなく、気づいた出来事を日付つきで短く残す。良かったことも同じように書く。
- ③ベンダーとの定例で事実を共有する — 更新の時期を待たず、気づいた時点で窓口に伝える。改善の機会を残すためにも、後出しにしない。
- ④更新の少し前にメモを見返す — 当初の目的に対して業務が進んでいるか、自社側の原因が残っていないかを確かめる。
- ⑤継続か、見直しかを決める — 同じ条件で続けるだけでなく、範囲を絞る・広げる、稼働量を調整する、体制を相談する、終了するといった選択肢で考える。
大切なのは③です。不満を抱えたまま更新の時期に初めて「終了で」と伝えると、ベンダー側には改善する機会がなく、発注側も原因が分からないまま次の要員を探すことになります。 早めに事実を共有しておけば、更新の話は「突然の通告」ではなく、積み重ねた確認の延長になります。 継続を選ぶ場合も、メモがあれば何を続けて何を変えるかを具体的に話せます。
更新の判断が固まった後の、予告期限の確認や引き継ぎの段取りは更新・終了の記事の手順につながります。SESと受託開発のどちらの形が合っているかから見直したいときは、SESと受託開発、どちらで頼むかも参考にしてください。
よくある質問
まとめ
SESで受け入れたエンジニアの稼働は、任せた範囲の進み具合・報告と見通し・作業の質と手戻り・周囲にかかる負担・引き継げる状態かの5つで見ると、印象に頼らず判断しやすくなります。 その前に、何を任せたことになっているかと、自社側に原因がないかを確かめること。そして、見た内容は本人を直接評価する形ではなく、ベンダーの窓口や責任者に業務の事実として伝えることが、線引きを保つうえでも改善につなげるうえでも近道になります。 受け入れ後の進め方や体制についてのご相談も歓迎です。SES・技術支援サービスのページもあわせてご覧ください。相談は無料です。
