SES客先常駐で評価されないエンジニアが逆転する5つの戦略

SES（システムエンジニアリングサービス）の客先常駐で働いていると、こんな悩みを抱えることが多い。

「毎年同じような評価で、給料が上がらない」「言われたことはこなしているのに、なぜか評価されない」「自分が頑張っているのか、上司にわかってもらえていない」

この悩みには共通の根本原因がある。エンジニアの成果は、本質的に定量化しづらいという構造的な問題だ。

営業職なら「今月○件受注」で評価は明快に出る。しかしエンジニアの仕事は、直接的に売上に貢献しているものが見えにくい。コードを書いても、バグを直しても、それが会社の数字にどう繋がるかが不透明なまま評価される。

この記事では、SES客先常駐を経験し、後に自社開発企業でFindy Team＋やNew Relicを活用して成果を可視化しチームリーダーになった筆者が、「評価されない」状況を逆転するための5つの戦略を具体的に解説する。

---

エンジニアの成果が見えづらい本質的な理由

成果の因果関係が長い

エンジニアの仕事が評価につながるまでには、複数のステップがある。

この因果チェーンが長いため、「自分が書いたコードが会社の数字にどう貢献したか」が見えにくい。さらに、最後の「売上が上がる」ステップには営業の力も絡んでくる。自分の仕事の貢献度を分離して証明することが、そもそも難しい構造になっているのだ。

SES客先常駐ならではの評価の難しさ

自社開発企業であれば、自分たちのサービスに直接関与し、成果も追いやすい。しかしSES客先常駐では以下のような問題が重なる。

• 評価者が複数いる：自社の上司、客先のPM、客先の上長と評価軸がバラバラ
• 技術的な貢献が見えにくい：客先はビジネス成果を求め、コードの品質や設計の深さを評価しない場合がある
• プロジェクトの目標が曖昧：「システム運用・保守」など、定量的な成果が出づらいアサインが多い
• 評価サイクルが合わない：自社の評価面談と客先プロジェクトのフェーズが噛み合わない

これらの構造を理解した上で、意図的に評価される動き方をすることが重要になる。

「頑張ったけど評価されない」が起きるメカニズム

エンジニアに多いのが、「黙って良い仕事をすれば評価されるはず」という思い込みだ。技術職の性質上、仕事の質で評価されるべきという感覚は正しい。しかし現実には、評価する側は「良い仕事をしている人」を見落とすことが多い。

マネージャーやPMは複数の案件・メンバーを同時に見ている。定期的に「自分がどんな価値を出したか」をアピールしない限り、埋もれてしまう可能性が高い。

評価される仕組みを意図的に作ること。これが、SES客先常駐でキャリアを切り開く最大のポイントだ。

---

戦略①：評価者を特定して、成果を定期的に共有する

どれだけ良い仕事をしていても、評価する人に認識されていなければ意味がない。まず最初にやるべきことは、「誰が自分を評価するのか」を明確にすることだ。

評価者は3種類いる

SES客先常駐では、評価に関わる人物が複数存在する。

評価者	関与する評価	重要度
客先のPM	日常業務・スキル・態度の評価	★★★
自社の営業・上長	昇給・昇格・案件継続の判断	★★★
客先の部長・マネージャー	継続契約・単価アップ交渉への影響	★★

これら3者全員に対して、「自分がどんな価値を出しているか」を伝える工夫が必要になる。

具体的な共有方法

筆者がSES・自社開発問わず徹底していたのは、評価者への定期的な成果共有だ。週次の進捗報告はもちろん、自分が取り組んでいること・完了したこと・困っていることを評価者に見える形にし続けた。

相手	頻度	共有内容
客先PM	週次	今週やったこと・来週やること・困っていること
自社上長	月次	客先での成果・習得したスキル・褒められたこと
客先部長	四半期	プロジェクトへの貢献・改善提案の成果

口頭で伝えるだけでなく、メール・Slack・週次レポートなど記録に残る形で共有することが重要だ。口頭だと忘れられるが、文章で残すと評価面談のときに「そういえばあの件で頑張っていたね」という形で掘り起こされやすくなる。

「何をやっているか」を常にセルフPRする習慣

多くのエンジニアは「自分の仕事は見ていればわかる」と思いがちだ。しかし現実には、評価する側は見ていない時間の方が圧倒的に長い。

「先週これを終わらせました」「今週はこれを優先します」という小さなアップデートを積み重ねることで、評価者の頭の中に「いつも前向きに動いているエンジニア」というイメージが形成される。これが最終的な評価の差につながる。

---

戦略②：目的ベースで動く

「言われたことをやる」では評価が低い

SES客先常駐で低評価になりがちなエンジニアの共通パターンが、「タスクをこなすだけ」という動き方だ。割り当てられたタスクを期日通りに完了することは大切だが、それだけでは「普通」の評価にしかならない。

評価される人は、こう動く。

• なぜこの機能を開発するのかを理解している
• 目的に対して、より良い方法を提案できる
• 自分の仕事がどのビジネス指標に繋がっているかを言語化できる

筆者が常に意識しているのは、「目的のためにこれをした」と説明できるかどうかという点だ。「言われたからやった」と「この目的を達成するためにこうした」では、評価者に与える印象がまるで変わる。

目的ベースで動くための質問習慣

タスクをもらったときに、以下の質問を習慣化すると効果的だ。

これらをPMや上長に確認するだけで、「目的を理解して動ける人材」という印象が定着する。最初は少し時間がかかっても、「この人はなぜやるかを常に考えている」という評価を積み上げることができる。

目的を言語化するとレビューも変わる

目的ベースで動くようになると、コードレビューのコメントも変わる。「この実装は○○という目的のためにこの設計を選びました」と書くだけで、レビュアーから「なぜこうしたのか？」という疑問を出させなくなり、スムーズなレビューが増える。

PRの説明文に「目的・変更内容・テスト方法」を書く習慣をつけると、技術的な評価とビジネス的な評価の両方を上げることができる。

---

戦略③：チーム目標と自分の仕事を紐づける

スコープを事前に切っておく

エンジニアの成果可視化で最も重要なのが、チーム目標と個人の仕事を紐づけるスコープ設定だ。

例えば、こんなケースを考えよう。

チーム目標：今期中に30社の新規契約を増やしたい

開発側のアウトプット：契約率を高める可能性がある機能AとBをリリースする

自分の担当：機能Aのバックエンド実装・テスト・本番リリース

この設定があれば、機能Aをリリースしたときに「チーム目標の達成に貢献した」と明確に言える。逆に「契約が増えたかどうかは営業次第」という部分を曖昧にしておくと、頑張った開発が評価されないケースが生まれる。

「自分がコントロールできるスコープ」と「コントロールできないスコープ」を事前に言語化しておくことが、正当な評価を得るために欠かせない。

OKR的な目標設定を個人レベルで取り入れる

SES客先常駐では会社全体でOKRを運用していることは少ないが、個人レベルでOKR的な思考を取り入れることは可能だ。

OKR要素	内容	例
Objective	今期のプロジェクトで達成したいこと	機能開発を通じてチームの開発速度を上げる
Key Result 1	測定できる指標	PRのレビュー完了時間を平均2日以内にする
Key Result 2	測定できる指標	バグ混入率を先期比30%減らす
Key Result 3	測定できる指標	ドキュメント整備で引き継ぎコストをゼロにする

この目標を事前にPMや上長に共有しておき、期末に振り返れば「自分がどれだけ目標を達成したか」を証明できる。目標設定した段階で評価者に共有しておくことが重要で、「事後に成果を報告する」より「事前に目標を宣言して後で報告する」方が評価されやすい。

チーム目標を理解することが信頼にもつながる

自分の仕事をチーム目標に紐づけようとすると、必然的に「チーム全体の目標は何か」を理解する必要が生まれる。これがPMとのコミュニケーション量を増やし、次の戦略④で説明する「信頼構築」にも直結する。

チーム目標を理解しているエンジニアは、PMにとって「話が早い」相手だ。戦略③と戦略④は互いに相乗効果を持つ。

---

戦略④：PMに「最初に相談する相手」になる

信頼の先にある評価

筆者がSES・自社開発企業を問わず意識していたのが、PMに「まず○○さんに相談しよう」と思ってもらえるポジションを意図的に取りに行くという戦略だ。

PMは常に様々な問題を抱えている。スケジュールの遅延、突発的な要件変更、チームメンバーとのコミュニケーション問題、上層部への説明。このような場面で「とりあえず○○さんに相談してみよう」と思ってもらえるエンジニアになれると、評価は自然と上がる。

なぜなら、PMは「誰に頼るか」という判断を毎日繰り返している。その判断の中に自分を入れてもらえれば、プロジェクト全体への貢献が大きく見えるからだ。

信頼を積み上げる4段階のロードマップ

「技術に閉じない」コミュニケーションが鍵

多くのエンジニアは技術的な質問には答えられるが、ビジネスの文脈での会話を避けがちだ。しかし、PMが悩んでいるのは技術ではなく、スケジュール・コスト・ビジネス成果だ。

技術の話だけでなく、ビジネスの言葉で話せるエンジニアになることが、PMに信頼される最大の近道だ。

例えば、こんな言い換えが効果的だ。

技術的な言い方	ビジネスの言い方
このAPIは非同期処理で実装します	処理をバックグラウンドに回すので、ユーザーの待ち時間がなくなります
データベースのインデックスを見直します	クエリを最適化して、画面の表示速度を改善します
テストカバレッジを80%まで上げます	品質チェックを強化して、リリース後のバグ対応コストを下げます

「技術的に正しいことを言っている」のと「PMに伝わっている」は別物だ。この変換ができるエンジニアは、PMにとって価値が高い。

小さな先回りが大きな信頼を生む

筆者が実践して最も効果があったのは、PMが明日困りそうなことを今日解決しておくという先回りだ。

「次のリリースでこの仕様が曖昧になりそう」「このテストが通らないと明日の朝会で問題になりそう」そういう予兆に気づいたときに、黙って解決しておく。翌日PMが「あれ、解決してる！」となったとき、信頼は確実に積み上がっていく。

---

戦略⑤：エンジニアの成果を定量化する

「感覚」ではなく「数字」で証明する

評価面談で「頑張りました」と伝えても、評価する側は「でも具体的には？」と感じる。正当な評価を得るには、定量的な根拠が必要だ。

筆者が自社開発企業で実践したのは、Findy Team＋とNew Relicを組み合わせた成果の定量化だ。

Findy Team＋とNew Relicの活用例

例えば筆者が在籍した自社開発企業では、主要KPIとして「問い合わせ数」を追跡していた。あるキャンペーン機能をリリースした際、New Relicで計測したところリリース前後で問い合わせ数が23%増加した。

これを評価面談で報告したとき、「機能Aをリリースした結果、問い合わせ数が23%増加しました」という形で成果を伝えられた。「頑張って実装しました」とは全く違う説得力になる。

Findy Team＋では、自分のPRレビュー速度や週次コミット量をデータとして把握できる。「今月はPRレビューを○件行い、平均レビュー完了時間は○時間でした」という報告ができるようになる。

SES客先常駐でも使える定量化

Findy Team＋のような専用ツールが使えない客先でも、定量化は工夫次第で可能だ。

指標	測定方法
タスク完了率	Jira・Redmineのチケット消化数（前月比）
バグ対応速度	障害報告〜修正リリースまでのリードタイム（日数）
コードレビュー貢献	PR・MRへのコメント数と承認数（週次）
ドキュメント整備	作成・更新したドキュメント数（月次）
障害件数削減	前月比の本番障害件数・重大インシデント件数
テスト品質向上	テストカバレッジの変化（%）

これらを「自分の成果レポート」として月次でまとめ、評価者に共有する。定性的な「頑張った」を定量的な「こういう成果を出した」に変換することで、評価者が評価しやすい状況を作れる。

「自分だけのKPI」を設定する

全社・全チームで統一されたメトリクスがない場合でも、自分だけのKPIを設定して追い続けることは可能だ。

例えば「毎週3件以上のPRレビューをする」「月1件は改善提案をドキュメントにまとめる」「週次レポートを毎週金曜17時までに提出する」といった、自分でコントロールできる指標を設定して継続する。

数ヶ月後に「この6ヶ月で○件のレビューをしました」「○件の改善提案のうち○件が採用されました」という形で報告できると、評価者も評価しやすくなる。

---

逆転への転換点：チームリーダーへの道

PMとの信頼関係が評価を変えた

筆者がチームリーダーになれた直接の要因は、PMとの日頃の信頼関係の積み上げだった。

技術的なスキルはもちろん重要だが、それと同等以上に「この人に任せれば大丈夫」という信頼感が評価の決め手になった。PMが何かを決断するとき、相談する相手が自分だった。技術的な質問だけでなく、スケジュールの判断、メンバーへのタスク振り分け、上長への説明資料づくりなど、様々な場面で協力を求められた。

その積み重ねが「この人はチームをまとめられる」という評価につながり、チームリーダーへの打診が来た。

リーダーになってから見えたこと

チームリーダーになって初めて気づいたことがある。リーダーはメンバーの「成果の見えにくさ」を一番感じている立場だ、ということだ。

メンバーが頑張っているのは伝わる。しかし、それを上層部に「評価してほしい」と伝えるための言語化が難しい。だからこそ、メンバー側から「自分はこういう成果を出しました」という情報を定期的に上げてもらえると、リーダーとしても非常に助かる。

評価されたいなら、評価者が評価しやすい状況を作るという視点。これはSES客先常駐でも自社開発でも共通して使える思考法だ。

単価アップに直結した具体的な経験

また、PMとの信頼構築は単価交渉にも直接効いてくる。筆者がフリーランスに転向してから経験した、単価67万円から80万円へのアップも、突き詰めると「クライアントとの信頼関係の深さ」が根拠になっていた。詳しくは「フリーランスエンジニアの月収シミュレーション」に書いている。

---

SESでの評価が限界なら転職も視野に

SES構造そのものが評価の壁になることも

ここまで紹介した5つの戦略を実践しても、それでも評価が変わらないケースがある。SESという構造上、どれだけ頑張っても限界があることも事実だ。

• 客先での評価が自社の給与に反映されないことがある
• スキルが客先のプロジェクトに縛られ、技術の幅が広がらない
• チャレンジングな仕事ができないアサインが続く
• 評価サイクルが長く、成果が反映されるまでのラグが大きい

このような場合は、転職も選択肢として真剣に検討すべきだ。自社開発企業であれば、自社のサービスに直接関与し、成果が見えやすい環境で働ける。SESからフリーランスという選択肢もある。筆者自身がSESを経てフリーランスに転向したロードマップは「SESからフリーランスへのロードマップ」で詳しく解説している。

転職活動で「評価される人」の武器が使える

ここまで紹介した5つの戦略を実践してきた人は、転職活動でも有利だ。

「どのような成果を出しましたか？」という面接の定番質問に対して、数字で答えられる人材になっているからだ。「Findy Team＋でコミット量とレビュー速度を計測し、PRレビュー完了時間を平均2日以内にしました」「New Relicで計測したところ、担当機能のリリース後にCVRが○%改善しました」という具体的な回答ができれば、面接評価は大きく変わる。

SESでの評価戦略は、転職市場での自分の価値を上げることにも直結している。

おすすめの転職エージェント

IT・エンジニア特化の転職エージェントを使うと、自社開発企業への転職がスムーズになる。市場価値の確認だけでも利用する価値がある。

ユニゾンキャリアはエンジニア・デザイナーに特化した転職エージェントで、SESから自社開発・スタートアップへの転職支援実績が豊富だ。キャリアアドバイザーが技術バックグラウンドを持っているため、スキルセットを正確に評価した上での求人紹介が期待できる。

レバテックキャリアはエンジニア転職支援実績No.1クラスのエージェントで、技術に詳しいキャリアアドバイザーが現在のスキルセットに合った自社開発企業を紹介してくれる。年収交渉の代行も強みのひとつだ。

スキルを伸ばしながら転職活動を進めたい場合は、Udemyでクラウドやバックエンド技術を習得しながら転職準備を進める方法もある。※本リンクはアフィリエイトリンクです

---

よくある質問（FAQ）

Q. SES客先常駐で「成果の数字」を出せない現場はどうすればいい？

A. 客先によっては数字が取れない環境も多い。その場合は「プロセスの数字」を代替指標にすることを勧める。PRレビュー件数、チケット消化数、ドキュメント作成数など、行動量を数字にするだけでも「定量的な成果報告」ができる。「○月は○件のレビューをしてチームの開発速度向上に貢献しました」という形で伝えられれば、成果の数字がなくても評価者に伝わる。

Q. PMとのコミュニケーションが苦手なエンジニアはどうすればいい？

A. 最初から全てをやろうとしないことが大切だ。まず「週次の進捗報告を文章で送る」という小さな行動から始めると良い。返信をもらうことでコミュニケーションが生まれ、徐々に関係が深まる。「技術的に困っていることを相談する」というアプローチも有効で、相談を受けた側は「頼られている」という満足感を得やすく、関係構築の糸口になる。

Q. 「目的ベースで動く」と言っても、そもそも目的を教えてもらえない現場はどうする？

A. 教えてもらえない場合は自分から聞きに行くことが重要だ。「この機能はどのビジネス目標に紐づいていますか？」という質問は、PMにとって歓迎されることが多い。この質問をするエンジニアは、全体を見渡せる視野の広さを評価されやすい。もし「そんなことは気にしなくていい」と言われる現場であれば、それはそもそも評価される機会が少ない環境かもしれない。転職を検討するひとつの判断材料になる。

Q. 転職せずにSES客先常駐のまま年収を上げることはできる？

A. 可能だが、限界がある。5つの戦略を実践して客先での評価を高め、自社への交渉材料にすることで昇給・単価アップにつなげることはできる。ただし、SESという構造上、客先での貢献が自社評価に反映されるまでのラグは避けられない。また、単純な運用保守メインの現場では、どれだけ頑張っても技術的なスキルアップに限界が来ることも多い。長期的なキャリアを考えると、SESから自社開発企業やフリーランスへの移行を視野に入れることをおすすめする。詳しくは「SES脱出ガイド」を参照してほしい。

Q. Findy Team＋は個人で契約できる？費用は？

A. Findy Team＋は基本的に企業向けのBtoB SaaSで、個人では契約できない。客先常駐で使えない場合は、GitHubのコントリビューション数やPR統計を手動で集計する方法、または個人のGitリポジトリでの活動量を記録する方法で代替できる。また、自分でGoogleスプレッドシートに「今週完了したPR数・レビュー数・解決したイシュー数」を記録し続けるだけでも、評価面談での根拠になる。

---

まとめ：評価されないのは「仕組み」の問題

SES客先常駐で評価されないのは、あなたの能力が低いからではない。多くの場合、評価が機能する仕組みを作れていないことが原因だ。

5つの戦略を再確認しよう。

1. 評価者を特定して、成果を定期的に共有する（記録に残る形で）
2. 目的ベースで動く（「なぜそれをするか」を常に語る）
3. チーム目標と自分の仕事を紐づける（スコープを事前に言語化）
4. PMに「最初に相談する相手」になる（先回りの先回りを繰り返す）
5. エンジニアの成果を定量化する（数字で話せる人材になる）

これらを一度に全部やる必要はない。まずは「①評価者への週次共有」から始めるだけで、驚くほど評価者の見え方が変わることがある。

「目的のためにこれをした」と数字で説明できるエンジニアが、最終的に評価される。SESの構造に評価を任せず、自分で評価される仕組みを作りにいこう。

転職を視野に入れた瞬間からでも、エージェントへの無料相談は有益だ。自分の市場価値を客観的に知るだけで、SESに残るべきか転職すべきかの判断が明確になる。