今年からエンジニアリングチームを任されるようになって、パフォーマンスレビューは「受けるもの」から「自分が回すもの」になりました。この記事は自分の頭の整理も兼ねているので、正解というより「試行錯誤中の人のメモ」として読んでください。

そもそもレビューをやる意味

#

どの職級であれ、目的は突き詰めると2つです。学び続けられるようにすること。そして、役割の期待を超えて働いている人が、きちんと報われるようにすることです。

「レビューをやる時間もリソースもない」と言う小さな会社は少なくありません。そういう会社は結局、在籍年数だけを頼りに「そろそろシニアかな」を決めることになります。これは間違いだと思っています。年数が怠惰な指標だから、というだけではありません。レビューをやめると、会社と社員の双方向のチャンネルが消えて、働く関係そのものが痩せていくからです。

これは両方向に効きます。本人は「会社のために一番いいやり方」と信じて働いていても、習慣ややり方、コミュニケーションのスタイルが良くない方向にズレていくことがあります。フィードバックがなければ、誰もそれに気づけません。逆に、構造化された場で社員の声を聞かない会社は、社員が会社をどう思っているかを知らないまま、心地よく過ごすことになります。

お互い、何を期待して臨むべきか

#

社員側の期待は複雑ではありません。自分の仕事がチームの目標とどう繋がっているか、何がうまくいっていて、どこを直せばいいか。それも「もっとコミュニケーションを」ではなく、具体的に。貢献はきちんと認めてほしいし、キャリアや研修の話も本気でしたい。そして、社内政治ではなく仕事そのものに基づいた、公平なプロセスであってほしい。

マネージャー側の私が期待するのは、まず自己評価を持ってきてもらうことです。何がうまくいって何がダメだったか、本人の見立てを聞きたい。弁護士の冒頭陳述ではなく、フィードバックへの開かれた姿勢がほしい。今後の目標について本音の議論をしたいし、チームの中で自分がどうフィットしていると感じているかも率直に聞きたいのです。レビューは私自身の計画の時間でもあります。チーム構成、昇進の候補、誰にどんな成長機会が必要か。

同じ型がすべてのエンジニアに合うわけではない

#

エンジニアリングチームには、文化的背景も経験年数も専門も違う人が集まっています。同じ台本のレビューが全員に効くはずがありません。「平等に扱う」と「公平に扱う」は別物で、やり方は本人のニーズ、キャリアステージ、貢献に合わせて柔軟に変える必要があります。土台になるのは、各エンジニアの役割と責任が明確で、報酬とちゃんと釣り合っていることです。

一番こじれやすいのは、肩書きと給料です。タイトルに納得していない人や、昇進の準備ができていると感じている人に、曖昧な励ましは毒にしかなりません。効くのは具体です。次のランクの基準になる具体的なチャレンジやプロジェクト目標に合意して、昇進を「雰囲気」ではなく客観的な基準にする。報酬も同じで、給料が低いと感じている人や責任を広げたい人には、次のレビューまでに何を達成すれば変更を正当化できるのか、測定可能なターゲットをプランに書き込む。そして次のレビューでは、双方ともその約束に正直に向き合う。

改善のフィードバックにも同じことが言えます。特定のギャップを狙った特定の研修、ワークショップ、プロジェクトなら役に立ちます。「スキルを伸ばし続けてね」は役に立ちません。

基準づくりは最初の面談から始まる

#

新しいメンバーとの最初のレビュー面談は、ほぼベースライン設定の時間です。役割が実際に何を含むのか、それがチームと会社の目標にどう繋がるのかを一緒に確認する。パフォーマンスを判断する測定可能なアウトカムに合意する。短期と長期の目標を置く。カルチャーと期待される振る舞い、フィードバックがいつどう届くか、使える研修やメンター制度、その席から見えるキャリアパスについて話すのもこのタイミングです。どれも刺激的ではありませんが、これをやっておくと後のレビューが全部楽になります。

2回目以降のアジェンダ

#

1. 雑談。ばかばかしく聞こえますが、これで場の緊張が抜けて、その後の会話が正直になります。
2. アジェンダの確認。どちらも話題に不意打ちされないように。
3. 前回のレビューからの成長。進歩は明示的に言葉にします。本人は案外気づいていないので。
4. 現在のパフォーマンス。強みから。
5. 改善点。それぞれに具体的で現実的なターゲットを付けて。
6. キャリアプラン。今の仕事がそこにちゃんと向かっているかも含めて。
7. 次のレビューまでのターゲット、目標、アクションアイテム。

KPIは「その人用」でなければ機能しない

#

プロダクトチームのエンジニアのKPIは、チームの目標と本人の両方に合っている必要があります。フロントエンド、バックエンド、フルスタックで役割は違いますし、ジュニアとシニアの違いはもっと大きい。コミット数はジュニア開発者について何かを語るかもしれませんが、主なアウトプットがアーキテクチャの意思決定であるシニアエンジニアについては何も語りません。だからKPIはテンプレートのコピーではなく、会話の中で決めるものです。

私が見ている領域はこのあたりです。

• コードの品質：エラー率、規約の遵守、バグ修正が必要になる頻度
• プロジェクトのデリバリー：マイルストーンと期限の達成
• イノベーションと問題解決：効率改善、難しい問題を実際に解決できたか
• コラボレーション：ピアレビュー、チームの目標や議論への貢献
• 自己成長：学習目標の達成、資格、新しく身につけた技術
• 顧客へのインパクト：ユーザーからのフィードバック、リリースした機能の利用状況

測定可能な指標という意味では、最近ユニットテストに注目しています。InfoQのこの記事は、ユニットテストをパフォーマンスレビューに組み込む方法を扱っていて、実装の仕組みと、チーム文化への影響の両方に触れています。コードの健全性を定性・定量の両面から測ろうという主張で、エンジニアを行数に還元しないKPIを探しているなら一読の価値があります。

何を選ぶにせよ、レビューか1:1で一緒に合意して、役割やプロジェクトや技術の変化に合わせて見直すこと。誰も合意していないKPIは、人を叩くための棒でしかありません。

私が使っているテンプレート

#

ドキュメントは1人につき1つにして、レビューのたびにセクションを足していきます。そうすれば履歴が1か所にまとまります。骨組みはこうです。

## パフォーマンスレビュー：[名前]、[期間]

**役割とレベル：** [肩書きと、このチームでそのレベルが意味すること]
**前回のレビューで決めた目標：** [前回のセクションからコピー]

### 自己評価（エンジニア本人が事前に記入）
- うまくいったこと。例を1つか2つ添えて
- うまくいかなかったこと。次はどうするか
- 1年後に何をしていたいか

### 前回の目標の進捗
- [目標]：達成 / 一部達成 / 未達成。根拠も添えて

### 強み（具体例つき）
- [何を、いつやって、何が変わったか]

### 改善点（それぞれにターゲットを）
- [行動やスキル] → [日付]までに[「良くなった」と言える状態]

### キャリアとレベル
- 次のレベルに対して今どこにいて、何が足りないか

### 次のレビューまでの目標
1. [測定可能な目標]
2. [測定可能な目標]

### 合意したアクション
- [誰が]、[いつまでに]、[何を]する

自己評価は面談の1〜2日前に出してもらいます。面談中に書いてもらうことはしません。先に読んでおくと、会話が変わるからです。こちらが切り出そうと思っていたことを、半分くらいは本人がもう自分で書いているので、面談の時間はそれをどうするかに使えます。

自己評価のための質問

#

事前に送っている質問がこちらです。わざとオープンな聞き方にしてあります。何をしたかだけでなく、本人が自分の仕事をどう見ているかが、答えから見えるようにするためです。

• 前回のレビュー以降で、一番誇りに思っている仕事は何ですか？なぜそれを選びましたか？
• どこで行き詰まりましたか？何があれば、もっと早く抜け出せたと思いますか？
• チームメイトやレビュアーからもらったフィードバックで、心に残っているものはありますか？
• 前回の目標のうち、達成できたと思うものはどれですか？取り下げたい、または変えたいものはどれですか？
• 次に何を学びたいですか？今の仕事に、その機会はありますか？
• マネージャーとして、私が変えるべきことは何ですか？

最後の質問が、一番気まずい沈黙と、一番役に立つ答えを引き出します。

具体的なフィードバックとはどういうものか

#

ダメなレビューのフィードバックは、たいてい厳しいのではなく、曖昧なのです。私が書くようにしているフィードバックの例で、違いを並べてみます。

具体的なほうは、どれも出来事を特定し、それが何を変えたかを言い、本人が次にできることを指しています。書くのに時間はかかります。だからこそ私は、前の晩に思い出そうとするのではなく、四半期を通して事例を集めておくようにしています。

書き残す

#

面談が終わったら、サマリーを書きます。話した要点、挙がった課題、アクションアイテム、双方が合意した目標。官僚的に聞こえますが、この記録があるからこそ、半年後の「そんな約束はしていない」という会話を防げます。文書化された課題は蒸発せずに追跡され、アクションアイテムは次のレビューの冒頭アジェンダになり、紙に書かれた目標は真剣に扱われるようになります。

結局のところ、システムの全体はこれだけです。初日から期待値を明確にし、KPIはその人に合わせて作り、すべて記録し、アクションアイテムは必ずフォローする。双方向の会話と測定可能なアウトカムのないレビューはただの形式的な作業で、エンジニアはカレンダーの招待が届いた時点でその匂いを嗅ぎ取ります。

ミーティング自体は簡単

#

構造は拍子抜けするほどシンプルです。スプリントやプロジェクトの区切りごとにチームで集まって、三つの質問に答えるだけ。

1. 何がうまくいったか？
2. 何がうまくいかなかったか？
3. 何を改善できるか？

以上です。本質はフィードバックループにあります。定期的に立ち止まり、実際に起きたことを眺めて、働き方に反映する。立ち止まらないチームは、同じことを繰り返すだけです。

有益なふりかえりと、ただのガス抜きの違い

#

まずは率直さです。本当の問題を口に出せるのは、それが自分に跳ね返ってこないと確信できるときだけ。だから場の安全性は、どのフォーマットを選ぶかより重要です。それに、いちばん鋭い観察はたいてい静かなメンバーから出てきます。リーダーだけが喋るふりかえりは、手間の増えたステータス会議でしかありません。

もう半分は、議論のあとに何が起きるかです。直す価値のある問題は、担当者と期限のついたアクションアイテムとして会議室を出るべきです。そして——ここを飛ばすチームが多いのですが——次回のふりかえりは、前回のアクションアイテムの確認から始めます。アクションアイテムがただの飾りだと全員が静かに気づいた瞬間ほど、ふりかえりを早く殺すものはありません。

可能なら数字も持ち込みましょう。「今回のスプリントは遅かった気がする」という感想は堂々巡りになりますが、グラフが一枚あれば大抵決着します。

よくある失敗パターン

#

間近で見てきたのは三つです。個人への非難に変わってしまうケース（直すべきはシステムであって人ではない）。一年間まったく同じフォーマットを使い続けて全員が自動操縦になるケース（変化をつける）。そしてフォローが一切ないケース。前述のとおり、最後のものが致命傷です。

ちなみに、これはソフトウェア開発に限った話ではありません。マーケティングキャンペーン、イベント運営、研究プロジェクト、製造業。サイクルが繰り返される仕事なら何でも、同じループが効きます。ただ、どこでやるにしても判定基準は同じです。次のふりかえりまでに、実際に何かが変わったか。変わっていないなら、それはただ喋っていただけです。

ここまでが短いバージョンです。以下に長いバージョンを書くのは、フィードバックの場で同じ失敗を、認めたくないほど何度も繰り返してきたからです。こちらが何か指摘すると、相手の肩にぐっと力が入り、その瞬間からお互い相手の話をちゃんと聞けなくなる。そういうパターンです。

そもそも、なぜ人は防御的になるのか

#

防御的な反応は、頑固さとは違います。少なくとも、頑固さから始まることはめったにありません。脅かされたと感じたときの反応で、フィードバックは私たちが思っている以上に人を脅かします。表向きはプルリクエストや守れなかった締め切りの話をしていても、相手に聞こえているのは「自分はこの仕事に向いているのか」「このチームにいていいのか」「何か月も前から内心そう思われていたのか」という問いです。

いったんそう感じると、相手の注意はこちらの言いたいことではなく、自分を守ることに向かいます。強く言い返せば、その脅威が本物だと裏付けるだけです。なので、以下に書くうまくいく方法の大半は、まず場の緊張を下げて、それから中身に入る、という順番の話です。

もうひとつ覚えておくといいのは、最初から傷を負った状態でこういう会話に臨む人もいる、ということです。批判するときしか口を開かない上司がいた、ミスをすると干される職場だった、など。その過去を一回の面談でどうにかすることはできません。ただ、軽い一言に不釣り合いなほど大きな反応が返ってくることがある理由は、これで説明がつきます。

話す前に

#

フィードバックの会話は、たいてい始まる前に勝負がついています。昔はやっていなかったけれど、今は気をつけていることがいくつかあります。

話題はひとつに絞ります。5つも溜め込んでいたら、相手にはフィードバックではなく起訴状に聞こえます。残りの4つは後回しで構いませんし、結局ひとつ目の症状だった、ということもよくあります。

早めに伝えます。6週間前の出来事についてのフィードバックは「なんで今さら言うんですか？」と受け取られます。もっともな疑問で、うまい答えはありません。出来事から1〜2日後くらいがちょうどいいと思っています。記憶が新しいうちで、かつお互いの頭が冷えている頃です。

人のいないところで伝え、できればチャットは避けます。文字だとトーンが抜け落ちますし、身構えている読み手は、その抜けたトーンを最悪のバージョンで補ってしまいます。チームがリモートだったりタイムゾーンをまたいでいたりして、どうしても文章で伝えるしかないときは、短くまとめて通話を提案します。

そして、自分の状態を確認します。こちらが苛立っていると、どんな言葉を選んでも、相手は最初の一文で察します。苛立ちが収まるまで待っていればずっとうまくいったはずのフィードバックが、いくつも思い当たります。

実際に何と言うか

#

私が何度も立ち戻る型は、一般に「状況・行動・影響」（SBI）と呼ばれるものです。いつ起きたか、相手が何をしたか、それが何を引き起こしたか。ポイントは、どの部分も観察できる事実だということです。相手がどういう人間かについては何も言わず、何が起きたかだけを話します。

実際の違いを見てみます。たとえば、ある開発者が金曜の午後にレビューを待たずに変更をマージして、週末に決済が動かなくなったとします。

相手が壁を作るバージョン：「いつも急いで出しますよね。もっと慎重になってください」

まだ望みがあるバージョン：「金曜に決済まわりの変更がレビューなしで入って、土曜に数時間、決済が止まっていました。何があったのか知りたいんです。不注意だったとは思っていないので」

後者は、出来事をひとつに絞り、それで何が失われたかを率直に伝え、最後に相手の善意を前提にしています。いちばんダメージが大きいのは「いつも」「一度も〜ない」という言葉です。一度の出来事を人格の評価に変えてしまいますし、相手はすぐさま、こちらが間違っていることを示す反例を思い浮かべます。

観察を自分のものとして言うことも心がけています。「〜に気づきました」「〜が気になっています」と言えば、これはあくまで私の見方で、私の側から差し出しているものだと正直に示せますし、私が何かを見落としている余地も残せます。実際、見落としていることはよくあります。

それから、話すのをやめて聞きます。「そちらからはどう見えていましたか？」たいていは、私の知らなかった事情があります。誰か別の人が決めた締め切りだったとか、レビュアーが病欠していたとか。そういう事情がなかったとしても、この質問をすれば、これは判決ではなく会話なんだと相手に伝わります。

フィードバックは、次の一手を添えるとずっと受け取りやすくなります。問題点を並べるのではなく、「次からは、〜してみませんか」。その次の一手が相手の口から出てくれば、なお良いです。

それでも反発されたら

#

全部正しくやっても、抵抗されることはあります。反発にはいくつか見分けのつく型があって、それぞれ少しずつ違う対応が要ります。

いちばん多いのは否定です。「そんなことはありませんでした」。ここで言い争わないこと。コミットやメッセージ、日付など、お互いに確認できるものに戻って、自分が何を見落としているのかを聞きます。事実そのものに本当に食い違いがあるなら、「お互いもう一度確認して、明日続きを話しましょう」で構いません。

次に、話をそらすパターン。「でも要件がころころ変わったので」「〇〇さんもやってますよ」。たいてい一理あるので、退けずに認めます。「それはその通りで、要件の問題も直さないといけませんね」。そのうえで、そっと話を戻します。「それとは別に、レビューの手順について話したいんです」

逆襲、たとえば「そっちだってしょっちゅうレビューなしでマージしてるじゃないですか」は、同じ調子で返したくなるのをこらえるのがいちばん難しいパターンです。ひと呼吸置きましょう。相手の言う通りなら、そう認めます。それが場の温度を下げるいちばんの近道ですし、相手に求めているオープンさを自分が先に示したことにもなります。そのうえで、元の話に戻ります。

心を閉ざすパターン、つまり黙り込んだり「はいはい、おっしゃる通りです」と言ったりするのは、同意に見えて同意ではありません。私はそれを柔らかく言葉にします。「あまりうまく伝わらなかったみたいですね。それで大丈夫です」という感じで、続きはまた後でと提案します。引いてしまった人に無理やり答えさせても、返ってくるのは本心ではない答えだけです。

謝りすぎ（「本当にダメですね、すみません」）も防御反応で、向きが内側になっているだけです。先に自分で自分を批判することで、身を守っているわけです。これはあくまで特定のひとつの件で、仕事ぶり全体の話ではないと安心してもらい、これからどうするかの話に移ります。

どのパターンでも、私が守ろうとしているルールはひとつ、相手のテンションに合わせないことです。相手が防御的になると、こちらもつい防御的になりがちですが、それをやると会話は確実に沈みます。自分が落ち着いていれば、場の温度はたいてい自然に下がっていきます。「聞いていて、もどかしいですよね」と相手の気持ちを口に出すのも効きます。緊張がないふりをするより、ずっといいです。

引き際を知る

#

どれも効かず、相手の壁が崩れないこともあります。そこで押しても何も得られません。会話をいったん置いて、落ち着いた頃に、1〜2日空けて仕切り直せばいいんです。フィードバックの中身は明日になっても変わりませんし、ひと晩寝かせると、人はずっと冷静に振り返れるものです。これまでのフォローアップの会話でいちばん良かったもののいくつかは、相手の「この前言われたこと、考えてみたんですけど」という一言から始まりました。

これを身につけるのに、一番時間がかかりました。

話したあとで

#

その後の1週間に起きることは、会話そのものと同じくらい大事です。相手が行動を変えたら、気づいたことを、はっきり、早めに伝えます。そうすれば、私からのフィードバックが悪い知らせばかりではないとわかってもらえますし、次の会話もしやすくなります。

それから、タイミングが合えば、フィードバックがどう受け止められたかを聞きます。「今の伝え方はフェアでしたか？」と聞けば会話のバランスが取れますし、相手に期待しているオープンさを自分から示せます。マネジメントの立場になってからはこれを習慣にしていて、自分の頭の中では明確だったのに口に出したらそうでもなかった、というケースを何度か拾えました。

要するに

#

本題に入る前に、まず脅威を下げること。話題はひとつに絞り、人のいないところで早めに切り出し、相手の人柄ではなく行動とその影響を伝え、解決策を出す前に相手の言い分を聞きます。反発されても同じ調子で返さないこと。気持ちを受け止め、事実に戻り、いったん止めて別の日に続ける覚悟を持っておきます。そして、フォローアップを忘れずに。信頼が築かれるのは、会話のあとの会話だからです。