今年からエンジニアリングチームを任されるようになって、パフォーマンスレビューは「受けるもの」から「自分が回すもの」になりました。この記事は自分の頭の整理も兼ねているので、正解というより「試行錯誤中の人のメモ」として読んでください。
そもそもレビューをやる意味#
どの職級であれ、目的は突き詰めると2つです。学び続けられるようにすること。そして、役割の期待を超えて働いている人が、きちんと報われるようにすることです。
「レビューをやる時間もリソースもない」と言う小さな会社は少なくありません。そういう会社は結局、在籍年数だけを頼りに「そろそろシニアかな」を決めることになります。これは間違いだと思っています。年数が怠惰な指標だから、というだけではありません。レビューをやめると、会社と社員の双方向のチャンネルが消えて、働く関係そのものが痩せていくからです。
これは両方向に効きます。本人は「会社のために一番いいやり方」と信じて働いていても、習慣ややり方、コミュニケーションのスタイルが良くない方向にズレていくことがあります。フィードバックがなければ、誰もそれに気づけません。逆に、構造化された場で社員の声を聞かない会社は、社員が会社をどう思っているかを知らないまま、心地よく過ごすことになります。
お互い、何を期待して臨むべきか#
社員側の期待は複雑ではありません。自分の仕事がチームの目標とどう繋がっているか、何がうまくいっていて、どこを直せばいいか。それも「もっとコミュニケーションを」ではなく、具体的に。貢献はきちんと認めてほしいし、キャリアや研修の話も本気でしたい。そして、社内政治ではなく仕事そのものに基づいた、公平なプロセスであってほしい。
マネージャー側の私が期待するのは、まず自己評価を持ってきてもらうことです。何がうまくいって何がダメだったか、本人の見立てを聞きたい。弁護士の冒頭陳述ではなく、フィードバックへの開かれた姿勢がほしい。今後の目標について本音の議論をしたいし、チームの中で自分がどうフィットしていると感じているかも率直に聞きたいのです。レビューは私自身の計画の時間でもあります。チーム構成、昇進の候補、誰にどんな成長機会が必要か。
同じ型がすべてのエンジニアに合うわけではない#
エンジニアリングチームには、文化的背景も経験年数も専門も違う人が集まっています。同じ台本のレビューが全員に効くはずがありません。「平等に扱う」と「公平に扱う」は別物で、やり方は本人のニーズ、キャリアステージ、貢献に合わせて曲げる必要があります。土台になるのは、各エンジニアの役割と責任が明確で、報酬とちゃんと釣り合っていることです。
一番こじれやすいのは、肩書きと給料です。タイトルに納得していない人や、昇進の準備ができていると感じている人に、曖昧な励ましは毒にしかなりません。効くのは具体です。次のランクの基準になる具体的なチャレンジやプロジェクト目標に合意して、昇進を「雰囲気」ではなく客観的な基準にする。報酬も同じで、給料が低いと感じている人や責任を広げたい人には、次のレビューまでに何を達成すれば変更を正当化できるのか、測定可能なターゲットをプランに書き込む。そして次のレビューでは、双方ともその約束に正直に向き合う。
改善のフィードバックにも同じことが言えます。特定のギャップを狙った特定の研修、ワークショップ、プロジェクトなら役に立ちます。「スキルを伸ばし続けてね」は役に立ちません。
基準づくりは最初の面談から始まる#
新しいメンバーとの最初のレビュー面談は、ほぼベースライン設定の時間です。役割が実際に何を含むのか、それがチームと会社の目標にどう繋がるのかを一緒に確認する。パフォーマンスを判断する測定可能なアウトカムに合意する。短期と長期の目標を置く。カルチャーと期待される振る舞い、フィードバックがいつどう届くか、使える研修やメンター制度、その席から見えるキャリアパスについて話すのもこのタイミングです。どれも刺激的ではありませんが、これをやっておくと後のレビューが全部楽になります。
2回目以降のアジェンダ#
- 雑談。ばかばかしく聞こえますが、これで場の緊張が抜けて、その後の会話が正直になります。
- アジェンダの確認。どちらも話題に不意打ちされないように。
- 前回のレビューからの成長。進歩は明示的に言葉にします。本人は案外気づいていないので。
- 現在のパフォーマンス。強みから。
- 改善点。それぞれに具体的で現実的なターゲットを付けて。
- キャリアプラン。今の仕事がそこにちゃんと向かっているかも含めて。
- 次のレビューまでのターゲット、目標、アクションアイテム。
KPIは「その人用」でなければ機能しない#
プロダクトチームのエンジニアのKPIは、チームの目標と本人の両方に合っている必要があります。フロントエンド、バックエンド、フルスタックで役割は違いますし、ジュニアとシニアの違いはもっと大きい。コミット数はジュニア開発者について何かを語るかもしれませんが、主なアウトプットがアーキテクチャの意思決定であるシニアエンジニアについては何も語りません。だからKPIはテンプレートのコピーではなく、会話の中で決めるものです。
私が見ている領域はこのあたりです。
- コードの品質：エラー率、規約の遵守、バグ修正が必要になる頻度
- プロジェクトのデリバリー：マイルストーンと期限の達成
- イノベーションと問題解決：効率改善、難しい問題を実際に解決できたか
- コラボレーション：ピアレビュー、チームの目標や議論への貢献
- 自己成長：学習目標の達成、資格、新しく身につけた技術
- 顧客へのインパクト：ユーザーからのフィードバック、リリースした機能の利用状況
測定可能な指標という意味では、最近ユニットテストに注目しています。InfoQのこの記事は、ユニットテストをパフォーマンスレビューに組み込む方法を扱っていて、実装の仕組みと、チーム文化への影響の両方に触れています。コードの健全性を定性・定量の両面から測ろうという主張で、エンジニアを行数に還元しないKPIを探しているなら一読の価値があります。
何を選ぶにせよ、レビューか1:1で一緒に合意して、役割やプロジェクトや技術の変化に合わせて見直すこと。誰も合意していないKPIは、ただの棒です。
書き残す#
面談が終わったら、サマリーを書きます。話した要点、挙がった課題、アクションアイテム、双方が合意した目標。官僚的に聞こえますが、この記録があるからこそ、半年後の「そんな約束はしていない」という会話を防げます。文書化された課題は蒸発せずに追跡され、アクションアイテムは次のレビューの冒頭アジェンダになり、紙に書かれた目標は真剣に扱われるようになります。
結局のところ、システムの全体はこれだけです。初日から期待値を明確にし、KPIはその人に合わせて作り、すべて記録し、アクションアイテムは必ずフォローする。双方向の会話と測定可能なアウトカムのないレビューはただのチェックボックス作業で、エンジニアはカレンダーの招待が届いた時点でチェックボックス作業の匂いを嗅ぎ分けます。