コードは書けるのに評価が上がらない──プログラマーが上流に信頼される実績の見せ方

プログラマーとして手を動かしているのに、なぜか評価が伸びない。
任された作業はきちんと終わらせているし、障害が起きれば対応もする。レビューも返す。納期にも間に合わせる。
それなのに、評価される人は別のところにいる気がする。

そんな感覚を持ったことがある人は、少なくないと思います。

実際、現場ではコードを書けること自体は、ある段階から前提化されやすいです。
もちろん実装力は重要です。でも、組織の中で評価が上がるとき、見られているのは単純な作業量だけではありません。

この人に任せると、手戻りが減る。
この人が入ると、話が前に進む。
この人は、現場で起きたことを次に活かせる形で残してくれる。
この人は、業務の文脈を理解したうえで実装している。

こうした信頼が積み上がると、上流に近い仕事が少しずつ集まってきます。
逆に言えば、コードは書けるのに評価が上がらない人は、実力がないのではなく、上流に伝わる形で実績が見えていないことが多いのです。

ここで誤解してほしくないのは、無理にマネジメント寄りになれ、という話ではないことです。
プログラマーがいきなり会議の中心に立つ必要はありません。
必要なのは、今やっている仕事を、単なる作業ではなく信頼に変わる実績として見せることです。

そのために意識したいのは、3つあります。

1. 障害対応を、その場しのぎで終わらせない

現場で評価が分かれやすいのが、障害対応です。

障害が起きたとき、まず復旧する。
これは当然必要です。
でも、復旧だけで終わる人と、そこから恒久対策までつなげる人では、見え方が大きく変わります。

たとえば、

・なぜ起きたのか
・再発条件は何か
・監視で先に拾えなかった理由は何か
・次に同じことが起きたら、誰がどう動けばいいか
・コード、設定、運用のどこを変えれば再発率を下げられるか

ここまで考えて残せる人は、単なる作業者ではなくなります。

上流の人たちが本当に欲しいのは、火消しがうまい人だけではありません。
火種を減らせる人です。
もっと言えば、問題が起きた事実を、次の改善材料に変換できる人です。

障害対応の経験は、書き方ひとつで印象が変わります。

よくある書き方は、障害発生時に調査・修正対応を実施、です。
これだと、ただ対応した人で終わります。

でも、たとえばこう変わります。

本番障害の初動対応から原因特定、修正までを担当。再発防止のために監視条件とログ出力を見直し、同種障害の検知速度を改善した。

これなら、対応しただけでなく、改善までつないだことが伝わります。

現場では、目の前の対応で精一杯になりがちです。
でも、評価を上げる人は、起きたことを閉じずに開いています。
その違いが、あとで効いてきます。

2. レビューを、ただの指摘対応で終わらせない

若手から中堅のプログラマーが伸び悩みやすい理由のひとつは、レビューを修正イベントとしてしか扱わないことです。

指摘された。
直した。
終わり。

これだと、その場の品質は上がっても、自分の市場価値には変わりにくい。

本当にもったいないのは、レビューには上流に近づくためのヒントが詰まっていることです。

たとえばレビューでよく出る指摘は、単なる書き方の話ではありません。

・責務が混ざっている
・例外系の想定が弱い
・命名が業務に寄っていない
・保守時の影響範囲が読みにくい
・運用観点が足りない

これらは、設計、業務理解、運用理解の不足として現れていることが多いです。
つまりレビューを通じて、自分が次に補うべき視点が見えているわけです。

評価が上がる人は、レビューを受けて直すだけでなく、指摘を分類しています。

これは実装の癖なのか。
設計の癖なのか。
業務知識の不足なのか。
運用を知らないから出ているのか。

ここまで見えるようになると、レビューが単発の修正ではなく、自分の成長ログになります。

しかも、この視点は実績の見せ方にも使えます。

コードレビュー対応を実施、では弱い。
レビュー指摘を通じて例外処理設計と責務分離の観点を改善し、その後の改修で手戻りを減らした、のほうが強い。

なぜなら、そこには学習と再現性があるからです。

上流で信頼される人は、完成品だけでなく、学び方にも再現性があります。
レビューを通じて、自分の設計力や業務理解をどう更新したか。
そこまで語れると、ただコードを書く人から一段上に見えます。

3. 業務理解を1段入れて話せるようにする

プログラマーが上流に信頼されるかどうかを分ける最大のポイントは、ここかもしれません。

それは、何を作ったかではなく、何のために作ったかを話せるかです。

実装経験があっても評価が上がらない人は、仕事を技術の言葉だけで語りがちです。

APIを改修した。
バッチを作った。
画面を実装した。
SQLを最適化した。

もちろん嘘ではありません。
でも、それだけだと業務の価値につながって見えないのです。

たとえば同じ仕事でも、見せ方は変えられます。

申請画面を改修した。
ではなく、申請時の入力ミスが多く差戻しが発生していた業務で、入力制御と確認導線を見直し、手戻りを減らす改修を担当した。

バッチ処理を修正した。
ではなく、締め処理の遅延で翌朝業務に影響していた処理について、実行条件とログの見直しを行い、運用負荷の低減に寄与した。

こう書けると、技術が業務に接続されます。
ここで初めて、上流の人にとって話が通じるようになります。

上流は、コードそのものを見ているわけではありません。
コードが、業務の何を改善したのかを見ています。

だから、プログラマーが評価を上げたいなら、実装の前後にある業務の流れを1段だけでいいので理解することです。

この画面は、誰が、どんな判断のために使うのか。
このデータは、後続のどの業務につながるのか。
この障害は、現場にどんな面倒を生んでいたのか。

これが見えるだけで、実装の意味が変わります。
そして、実績の言葉も変わります。

評価が上がる人は、派手なことをしているわけではない

ここまで読むと、難しそうに見えるかもしれません。
でも実際は、評価が上がる人が特別に派手な仕事をしているとは限りません。

同じように障害対応をして、同じようにレビューを受け、同じように実装している。
違うのは、それを信頼に変わる形で残しているかどうかです。

・障害対応を恒久対策まで語る
・レビューを学習履歴として扱う
・実装を業務価値に接続して話す

この3つができると、実績は急に上流の言葉に近づきます。

そして、この変化は転職のためだけではありません。
現職の評価でも効きます。
なぜなら、上司や関係者が見たいのは、この人は何を作ったかだけでなく、この人に何を任せると前に進むのかだからです。

プログラマーとして働いていると、どうしても手を動かした量で自分を測りやすいです。
でも、キャリアの途中からは、量だけでは伸びにくい。
信頼に変わる形で語れるかが効いてきます。

コードを書けることは、土台です。
その土台の上に、改善、学習、業務理解が乗ると、評価は変わり始めます。

もし今、ちゃんとやっているのに報われない感覚があるなら、足りないのは努力ではなく、実績の翻訳かもしれません。

あなたがこれまで積んできた仕事は、ただの作業で終わっているでしょうか。
それとも、次の役割につながる信頼として、まだ言葉にできていないだけでしょうか。

次に読む：

はじめての方へ：

マガジンの紹介：

IT業界の「技術×キャリア×整える」を束ねるマガジンを公開中です！
ビジネスや心と体を整える良記事が集まってきていますので、
是非、覗いてみてくださいね。
記事は全て無料記事のみです。
気に入って頂けたらマガジンのフォローもよろしくお願いします！
共同マガジンに参加希望の方も募集中です！