performance-reviews

パフォーマンスレビュー

始める前に

まず、EM に関するコンテキストを確認します。

1. .agents/em-context.md が存在する場合は読みます（レビューサイクルの形式、評価尺度など）
2. 人物が言及されている場合は、.agents/reports/[name].md を探します。そこには、その人の役割、レベル、目標、現在のプロジェクト、フィードバック履歴が記載されています
3. そのコンテキストを活用し、すでに扱われている情報は尋ねないでください

.agents/em-context.md が存在しない場合は、詳細なアドバイスをする前に、まず最低限のマネージャープロフィールを尋ねて保存します。役職、チームの人数、チームのミッションまたは担当領域、現在の課題または優先事項を確認します。

会話の中心となる特定の人物について、.agents/reports/[name].md が存在しない場合は、詳細なアドバイスをする前に、まずその人物の最低限のプロフィールを尋ねて保存します。役職／レベル、勤続期間、強み、現在の課題または成長領域を確認します。

会話の後半で長期的に役立つ新たなコンテキストが明らかになった場合は、.agents/em-context.md または .agents/reports/[name].md を自動的に更新します。推測、一時的な不満、未解決の解釈ではなく、安定した事実や傾向を保存します。

応答スタイル

最初の回答は簡潔で役立つものにします。ユーザーが詳しい説明を求めない限り、フレームワーク全体を一度に提示しないでください。

基本方針：

• 可能性の高い診断または推奨事項を最初に示す
• 不足しているコンテキストによってアドバイスが変わる場合に限り、的を絞った質問を最大 2〜3 件する
• 次に取るべき具体的な行動を示し、役立つ場合はマネージャーが使える正確な表現も提示する
• 関連するフレームワークには簡潔に触れるが、すべての要素を説明しない
• 直接的な回答の後で、より詳しい説明を提案する

---

このスキルの使い方

まず状況を特定します。

• チームの誰かのパフォーマンスが振るわないが、原因がわからない → パフォーマンス不振の診断：左から右へ進める（ここから始めます）
• 問題を診断済みで、次は行動に対処する必要がある → 継続的な行動上の問題に対処する 4 段階プロセス
• パフォーマンス不振を長く容認しすぎているのではないかと考えている → パフォーマンス不振を早期に見極める
• 誰かを解雇することを真剣に検討している → 難しい決断を下す＋行動を起こすタイミング
• 自身のマネージャーレビューを書いている、または構成を考えている → メタ・パフォーマンスレビューの問い

---

デフォルトの応答構成

パフォーマンスについて支援する際は、診断と行動を分けます。

1. パフォーマンスの評価： 行動、影響、傾向、深刻度。
2. 根本原因の仮説： リソース、トレーニング、意欲、適性、能力。
3. 必要な証拠： 具体例、期待事項、過去のフィードバック、ビジネスへの影響。
4. マネージャーの対応： フィードバック、サポート計画、PIP、昇進の推薦、または退職に向けた手順。
5. 表現： レビューで使う文面または会話の台本。

共感を曖昧さにつなげないでください。思いやりを持ちつつ、具体的に伝えます。

---

パフォーマンス不振を早期に見極める

最もよくある落とし穴は、改善とポテンシャルを混同することです。低いレベルから中程度のレベルに上がったエンジニアは改善していますが、それでも基準を下回っている可能性があります。

重要な問いは「良くなっているか？」ではありません。「求めるレベルに達しているか？」です。

Ray Dalio：「成績が 30 点台や 40 点台だった人が、数か月にわたって 50 点台まで上げたなら、良くなっていると言うのは正確です。しかし、それでも依然として著しく不十分でしょう。」

マネージャーがパフォーマンス不振を長く容認してしまう理由

1. 感情的なつながり — その人に投資してきた、好意を持っている、傷つけたくない
2. サンクコストの誤謬 — その人のトレーニングに何か月も費やしてきたため、最初からやり直したくない

どちらも現実にあります。しかし、どちらも自分に嘘をつき、平凡な結果で妥協することにつながります。

客観性を保つ方法

• 問題が起きる前に具体的な期待値を設定する — 30／60／90 日の目標、オンコール対応の準備状況、プロジェクトリードの基準などです。明確な基準がなければ、「改善している」と感じるだけで十分だと思い続けてしまいます。
• 「今なら採用するか？」と自問する — 「その人がいる場合といない場合のどちらがよいか？」ではありません（サンクコストに常に引きずられるためです）。代わりに、「今知っていることを踏まえて、この人を採用するか？」と考えます。答えが「いいえ」なら、それが答えです。
• あらかじめチェックポイントを設ける — 30 日後、60 日後、またはサイクルの終わりなどです。決断を迫られる時点を設けることで、いつまでも先延ばしにするのを防げます。

謙虚さを保つ

判断を誤ることもあります。苦戦しているエンジニアも、時間や適切な環境、自分に合った役割を得ることで、優れた人材に成長する可能性があります。フレームワークは指針であり、判決ではありません。

---

難しい決断：人を辞めさせる

心の奥では、たいてい分かっているものです。誰かを本気で解雇すべきか考え始めたときには、おそらくすでに手遅れです。

安堵感テスト： 従業員から退職すると告げられたと想像してください。ほっとしますか、それとも動揺しますか？ ほっとするなら、それが答えです。

（Netflix の「キーパーテスト」――その人を引き留めるために尽力するか？――は、より厳しい基準です。安堵感テストのほうが、ほとんどのチームにとって現実的です。）

いつも難しい理由

通常は、次の 3 つの状況のいずれかです。役割に合わない人を採用した、明確な期待値や十分なサポートを提供しなかった、または役割が変わり、その人に合わなくなった。どの場合も、その状況にはあなたにも責任があります。だからこそ難しいのですし、優れたマネージャーも苦悩するのです。

「伸びしろがある」と「難しい決断ができない」を混同しないでください。これは別のことです。

待つことの代償

• 従業員が苦しみます — うまくできていない仕事に毎日通うのは、消耗するものです
• あなたも苦しみます — 心の奥ではうまくいかないと分かっている相手を成功させようとするのは、疲れるものです
• チームも苦しみます — 成果の出ない人と一緒に働くのは意欲をそぎます。あなたがようやく行動に移すと、チームはほぼ必ず理解を示します

解雇を後悔したマネージャーには、まだ出会ったことがありません。出会ったのは、決断を待ったことを後悔した人だけです。

行動に移す前に：まずこれを行う

人を辞めさせる前に、必要なことをすべて行ったと確信するために、次のことをしてください。

1. すぐにフィードバックを伝える — 望ましくない方向に進み始めたら、すぐに伝えます。問題が積み重なるまで待ってはいけません。
2. 具体的に伝える — 何がうまくいかなかったのか、どうすればよくなるのか、具体例を挙げます
3. 本人に言い返してもらう — 本人の理解があなたの意図と一致するまで確認します。期待値を理解したつもりでも、実際には理解していないことがよくあります。
4. 書き出す — 変えるべきことを、測定可能で、双方が確認できる明確なリストにします
5. 辛抱強く接する — 行動を変えるには本当の努力が必要です。待つ価値があることもよくあります。

注：業績改善計画の対象となった人の 50％は、同じ問題を繰り返します。優秀な従業員は、一時的に期待に応える方法を知っています。そのパターンに注意してください。

---

いつ行動するか：「早めに解雇する」経験則

大まかではありますが、役に立つ目安があります。誰かを解雇すべきか一度でも真剣に考えたなら、おそらく早めに行動するべきです。

本当に優秀な従業員に対しては、そうした考えは浮かびません。そもそも考えが浮かんだこと自体が、判断材料になります。

衝動的に解雇すべきだという意味ではありません。「この人を辞めさせるべきか」という段階まで考えたのに行動していないなら、なぜ待っているのかを検討してください。最もよくある理由は、気まずさを避けたいからです。状況が自然に解決するという根拠があるからではありません。

---

マネージャーのパフォーマンスを評価するための核心的な質問

マネージャーのパフォーマンスを評価するうえで、最も役立つ質問は次のとおりです。「この人がいなかったら、何が違っていたでしょうか？」

これはマネージャーがもたらした差分を捉える質問です。チームが何をリリースしたかではなく、マネージャーがいなければ実現しなかったことを、マネージャーがどのように引き起こしたかを問います。自分自身にも当てはめてみましょう。あなたがいなければチームが生み出せなかった成果に対して、あなたはどのように貢献していますか？

貢献として評価される一般的な例：

• 誰かの進む道を変えた、難しい話し合い
• 採用基準を引き上げた採用判断
• 他の誰にも取り除けなかった障害を取り除くこと
• 行き詰まっていた人を成長させること

---

根強い問題行動に対処する4段階のプロセス

問題のある行動パターン（絶えず不満を口にする、約束を守らない、人間関係で摩擦を起こすなど）を繰り返すエンジニアに対して：

ステージ1 — 話を聞き、理解する。 その行動の背景にあるものを理解するため、できることはすべて行います。ほとんどの場合、その根底には正当な不満があります。この段階を飛ばしてはいけません。いきなり「Xをやめて」と伝えると、問題を知らせるサインを無視することになります。

ステージ2 — 根本原因に対処する。 根底にある最大の問題を1～2つ特定し、その人と協力して対処します。これには、ただ認識を示すだけでなく、実際に問題を解決する必要があります。

ステージ3 — 行動そのものについて話し合う。 根本原因に対処したら、行動をどう変える必要があるのかを明確に話し合います。何が許容され、何が許容されないのか、今後の期待は何かを伝えます。

ステージ4 — 離職してもらう。 ステージ1～3を経ても行動が続くなら、それは状況のせいではなく、本人の選択です。行動に移しましょう。

失敗につながるのは、ステージを飛ばすことです。ステージ1～2を実施していないマネージャーは、信頼性をもってステージ3の話し合いを行う立場にありません。

---

期待を下回るパフォーマンスの診断：左から右へ進める

「昇進させるか、辞めてもらうか」を決める前に、この段階を順番に確認してください。右へ進むほど、責任の所在はあなたから従業員へ移っていきます。

1. リソース — 必要なものが揃っていますか？ アクセス権、ソフトウェア、ツール、サポートなどです。揃っていなければ、責任は全面的にあなたにあります。その人について何か結論を出す前に、まず問題を解決してください。
2. トレーニング — 仕事をこなすための知識は十分にありますか？ これは双方の責任です。トレーニングを受けられるようにするのはあなたの役目で、それを活用するのは本人の役目です。際限のないトレーニングに陥らないようにしましょう。網羅的なものではなく、必要十分なものを目指してください。
3. 意欲 — 本人は本当にこの仕事をしたいと思っていますか？ これは、本人にとって現実的かつ個人的な利害が伴う、最も難しい話し合いです。初日から期待を明確に伝えていても、本人がそれに応える意思がないなら、その責任は本人が負うべきです。あなたは応援する人にも、コーチにもなれますが、本人に代わって意欲を持つことはできません。
4. 適性 — 本人の強みを活かせる役割に就いていますか？ 才能があっても、この特定の仕事には向いていない場合があります。
5. 能力 — 求められる水準に到達するための基礎的な能力がありますか？

パフォーマンスが低い原因の診断では、#1と#2に対処せず、#3や#5に直行することがよくあります。これは間違いです。マネージャーの責任を見過ごし、信頼を損ない、根拠の弱いパフォーマンス評価につながります。

---

さらに詳しく

フレームワークの出典を知りたい場合、元の記事を読みたい場合、またはいずれかのトピックについて詳しい背景を知りたい場合は、references/sources.mdを参照してください。出典記事（リンク付き）と書籍の一覧が掲載されています。

---

関連スキル

• feedback — 即時かつ具体的なフィードバックは、これらすべての前提条件です
• hiring — 具体的な期待の設定は採用時に始まります