離れた現場のエンジニアの「見えない頑張り」を、上司はどう拾っているか

「見えない」ことへの焦り

SES事業をやっていると、うちのエンジニアはクライアントの現場で働いています。毎日隣の席にいるわけではないし、どんなコードを書いているか、どんなコミュニケーションを取っているか、細かくは見えません。

これが、想像以上にもどかしい。

エンジニア時代は「上司がちゃんと見てくれない」と思っていました。でも経営者になってみると、見たくても見えない場面がたくさんある。特にSESは構造的にそうなんです。クライアント先に常駐しているエンジニアの日常は、私のところには断片的にしか届きません。

月に一度、定期的に面談はしています。クライアントからフィードバックをもらうこともあります。でも、それだけで「あなたの仕事ぶりを全部わかっています」なんて言えるほど、現実は甘くない。面談の30分や1時間で、1ヶ月分の仕事をすべて把握するなんて不可能です。

クライアントからのフィードバックも、あくまでクライアントの視点から見たものです。「問題なくやってくれています」という言葉は安心材料にはなりますが、エンジニア本人がどんな工夫をしているか、何に悩んでいるかまではわかりません。

だからこそ、私は面談のときにいつも聞くんです。「最近、自分で手応えを感じたことは何かありますか」と。

この質問には意味があります。報告書に書かれるタスクの進捗ではなく、エンジニア自身が「これは良い仕事ができた」と感じている瞬間を知りたい。そこにこそ、その人が大事にしている仕事の基準が表れるからです。あるエンジニアは設計の美しさに手応えを感じるかもしれないし、別のエンジニアはチームの質問に丁寧に答えて感謝されたことを挙げるかもしれない。エンジニア自身の口から聞く言葉は、どんな報告書よりもリアルです。

評価って、結局なんだろう

経営者として評価に向き合うようになって、一番感じたのは「公平な評価なんて存在しない」ということでした。

これは諦めの話ではありません。どんなに仕組みを整えても、人が人を評価する以上、完全に公平にはなれない。評価者の知識、経験、価値観によって見え方は変わる。同じ成果でも、近くにいる人と遠くにいる人では印象が違ってしまう。それが人間です。

だったら「完璧な評価制度をつくること」を目指すよりも、「評価のプロセスに誠実でいること」のほうが大事だと思うようになりました。

エンジニア時代、私は評価面談のあとにいつもモヤモヤしていました。結果は伝えられるけど、なぜその結果になったのかがよくわからない。「総合的に判断して」と言われても、その「総合的」の中身が見えない。だから納得感がなかった。

同じことをうちのエンジニアに感じさせたくない。その思いが、Codenceでの評価の考え方のベースになっています。

たとえば、うちでは評価の基準をできるだけオープンにしています。何ができたら次のステップに進めるのか、どんなスキルを期待しているのか。曖昧にしない。エンジニア時代に自分が一番嫌だったのは「何を基準に評価されているのかわからない」という状態だったからです。頑張り方がわからない状態で「もっと頑張れ」と言われても、困りますよね。

それでも、評価に完璧はありません。だから「今回の評価、ここはこう考えてこうしました」と理由をちゃんと伝える。納得できないことがあれば、遠慮なく言ってほしいと伝えています。

評価は一方通行のものじゃない。出してもらった結果に対して、「自分はこう受け止めた」「ここは少し違うと思う」と返してもらえたら、次はもっと精度が上がる。そういう双方向のやり取りを重ねることが、制度以上に信頼につながると私は思っています。

エンジニアの「頑張り」をどう受け取るか

エンジニアの仕事には、目に見えにくい頑張りがたくさんあります。

リファクタリングに時間をかけたこと。後から入る人のためにドキュメントを丁寧に書いたこと。チーム内の質問に何度も答えたこと。障害が起きたとき、夜遅くまで原因を追ったこと。本番環境に影響が出ないように慎重にテストケースを考えたこと。

こういう仕事は、数字に表れません。コミット数にもタスク完了率にも出てこない。でも、現場を支えているのはこうした地道な積み重ねです。

私はエンジニア出身だから、それがわかるつもりです。でも「わかるつもり」と「ちゃんと見えている」の間には距離がある。特にSESの場合、現場のことは現場にいる人が一番わかっています。経営者がいくら「技術のことはわかります」と言ったところで、実際にそのコードベースに触れていない人間に見える範囲は限られている。

この事実を認めることが大事だと思っています。見えないものを「見えている」と思い込むより、「見えていないから教えてほしい」と正直に言えるほうがよっぽど健全です。

だから私は、エンジニアが「自分はこれをやった」と言いやすい空気をつくることを意識しています。面談の場で改まって「自己アピールしてください」と言うのではなく、普段の会話の中で自然と出てくるようにしたい。「最近どう？」から始めて、仕事の話に移って、そこで出てくる具体的なエピソードを拾う。面談の場だけで全部聞こうとすると、お互い構えてしまうから。

LINEで「今日こんなことがあって」と送ってくれることもあります。そういう何気ない一言が、実はすごく大事な情報だったりする。フォーマルな報告よりも、カジュアルなやり取りの中にリアルが詰まっています。

クライアントから褒められた日のこと

先日、あるクライアントの担当者から「御社のエンジニアさん、チームにすごく馴染んでいて助かっています」と言われたことがありました。

ものすごく嬉しかった。と同時に、自分がエンジニアだった頃には想像もしなかった感情だなと思いました。

エンジニア時代、自分が褒められたら嬉しいのは当然です。でも、「自分の会社のエンジニアが褒められて嬉しい」という感覚は経営者にならないと味わえなかった。自分のことのように嬉しいし、それ以上に「この人がうちにいてくれてよかった」と思う。

こういう言葉をもらったときは、必ず本人に伝えるようにしています。クライアントからのフィードバックが自分のところで止まってしまったら、エンジニアは知りようがない。「あのクライアント、こう言ってくれてたよ」と伝えたときに「えっ、本当ですか」と照れる反応を見ると、こっちまで嬉しくなります。

逆に、もし改善してほしいというフィードバックがあれば、それも伝えます。ただし「クライアントがこう言っていたからこうしろ」と丸投げするのではなく、「こういうフィードバックがあったけど、実際のところどう？」と聞く。クライアントの言葉が常に正しいわけではないし、現場の文脈を知らなければ適切な対応も決められませんから。

「正当に評価されない」と感じているエンジニアへ

これを読んでいるエンジニアの方に、一つだけ伝えたいことがあります。

もし今、「正当に評価されていない」と感じているなら、まず自分のやっていることを言葉にしてみてください。

評価する側は、思っている以上に見えていません。悪意があるのではなく、構造的に見えにくいことがある。特にSESのような業態では、物理的に離れている分、情報が届きにくい。見えないものは評価のしようがないというのが、残念ながら現実です。

だから、自分の仕事を言語化する力がとても重要になります。何を考えて、何を選んで、何をやったのか。技術的な判断の背景を一言添えるだけで、伝わり方が全然違います。

例えば「タスクAを完了しました」と報告するのと、「タスクAで、当初はXの方針で進めようとしたけど、Yの理由でZに切り替えました。結果として処理速度が改善しました」と伝えるのでは、受け取る側の理解度がまるで違う。後者のほうが、あなたの判断力や技術力がはっきり伝わります。

「アピールが苦手」という人は多いと思います。私もそうでした。でもこれはアピールじゃなくて、情報共有なんです。評価する側が正しい判断をするための材料を渡すこと。医者に症状を伝えるのと同じで、情報がなければ適切な診断はできない。そう考えると、少し気が楽になりませんか。

それでも評価に納得できないなら、その気持ちも伝えてほしい。少なくともCodenceでは、そういう声を受け止める準備はあります。

もう一つ。評価する側を「選ぶ」こともできる、ということを忘れないでほしいんです。会社を選ぶということは、誰に評価されるかを選ぶことでもある。自分の仕事をちゃんと見ようとしてくれる人のもとで働くこと。それが、キャリアの中で意外と大きな意味を持ちます。転職を考えるときに、待遇や技術スタックだけじゃなく「この会社は自分をちゃんと見てくれそうか」という視点を持ってみてください。面談での質問の仕方や、フィードバックの頻度に、その会社の姿勢が表れます。