retaining-developers

開発者の定着

始める前に

まず EM のコンテキストを確認します。.agents/em-context.md が存在する場合は、読み込んでください。特定の人物について言及されている場合は、.agents/reports/[name].md を確認してください。

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

特定の人物が会話の中心であり、.agents/reports/[name].md が存在しない場合は、詳細なアドバイスをする前に、まずその人物の簡単なプロフィールを尋ね、保存してください。プロフィールには、役職・レベル、在籍期間、強み、現在の課題または成長領域を含めます。

会話の中で、後から長期的に有用な新しいコンテキストが明らかになった場合は、.agents/em-context.md または .agents/reports/[name].md を自動的に更新してください。推測、一時的な苛立ち、未解決の解釈ではなく、安定した事実やパターンを保存してください。

応答スタイル

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

基本方針：

• まず、考えられる診断または推奨事項を示す
• 不足しているコンテキストによってアドバイスが変わる場合に限り、的を絞った質問を2〜3個まで尋ねる
• 次に取る具体的な行動を示し、必要に応じてマネージャーがそのまま使える正確な言い回しを提示する
• 関連するフレームワークに簡単に触れるが、すべての要素を説明しない
• 直接的な回答の後でのみ、より詳しい説明を提案する

---

このスキルの使い方

• エンジニアの意欲が低下している、または離職のリスクがある → 「5つの状態」で診断する
• 報酬または昇給についての会話 → 「評価されていない状態」から「評価されている状態」への移行を起点とする
• 入社時、追加付与時、または退職時の株式やオプションについての会話 → 「ストックオプションと株式に関する会話」を使う
• 予算はないが、誰かを評価したい → 「予算ゼロでの評価」を使う
• 本人は何も言っていないが、退職するのではないかと心配している → 「意欲が低下したエンジニアの5つの警告サイン」を使う
• エンジニアがすでに別のオファーを受けている → 「別のオファーを受けている場合」を使う

---

デフォルトの回答形式

ユーザーから定着について助けを求められた場合は、マネージャーが実践できる回答を作成します。

1. リスク評価： 低／中／高。プロンプトにある根拠も示します。
2. 考えられる状態： 評価されていない、孤立している、退屈している、行き詰まっている、無関心、または複合的な状態。
3. 次回の1:1で確認すること： 直接的でありながら、問い詰めるように感じさせない質問を3〜5個。
4. 行動計画： 今週、今月、そして構造的に何をするか。
5. 会話の台本： マネージャーが使える具体的な言い回し。
6. 避けること： 状況を悪化させる、よくある過剰反応。

すでに退職を申し出ている場合や、別のオファーを受けている場合は、通常の定着策だけで十分であるかのように扱わないでください。理由を理解し、信頼できるカウンターオファーを提示できるか判断し、本人を尊重して対応し、関係を維持することに切り替えてください。

---

定着リスクの診断

介入策を選ぶ前に、次の点を確認してください。

• シグナルの強さ： 弱いシグナルが1つあるだけか、数週間にわたるパターンか、退職する可能性があるという明言か。
• 状態： 5つの状態のうち、どれが行動を最もよく説明するか。
• 具体性： 変化の原因となった正確な出来事、プロジェクト、判断、またはパターンをマネージャーが特定できるか。
• 裁量： マネージャーが実際に変えられることがあるか、それともマネージャーの管理外か。
• 時間軸： リスクは差し迫っているか、顕在化しつつあるか、長期的なものか。
• 信頼度： エンジニアは、マネージャーが本人を大切に思って行動していると信じるか、それとも失うことを恐れているだけだと感じるか。

最後の質問は重要です。誰かの意欲が低下してから初めて行う定着の試みは、打算的に感じられることがあります。必要に応じて、その点を率直に認めてください。

---

5つの状態

開発者が退職する理由は、多くの場合、次の5つの感情のいずれかです。反対の状態を手がかりに、原因を見極めて行動しましょう。

感じていること	必要としていること
正当に評価されていない	大切にされていると感じること
孤独	つながりを感じること
退屈	やりがいを感じること
行き詰まり	成長していると感じること
無関心	仕事への情熱を感じること

---

1. 正当に評価されていない -> 大切にされている

初任給は極めて重要です。 最初に提示する給与は基準となり、後から修正するのは困難です。採用時に低く提示すると、常に遅れを取り戻そうとすることになります。昇給は報酬ではなく、修正のように感じられ、評価されているという認識の差が積み重なっていきます。

本人に言われる前に昇給させましょう。 開発者が昇給を求めなければならない時点で、すでに問題が起きています。あなたが注意を払っていなかった、あるいは本人を支援していなかったという印象を与えます。先回りして対応しましょう。また、エンジニアの給与が自分より高いからといって昇給を拒否してはいけません。これは競争ではありません。

手柄を横取りしてはいけません。 昇進、節目の達成、リリースの成功など、良いことがあったら、エンジニア自身に発表してもらいましょう。良い知らせは本人から伝えるべきです。本人の成果をあなたが発表すると、その瞬間を奪ってしまいます。本人が発表すれば、あなたはそれを後押しできます。

本人にはっきり伝えましょう。 多くのマネージャーは、良い仕事を内心では認めていても、エンジニアも分かっていると思い込んでいます。実際には、そうでないことがよくあります。1対1の面談で率直に伝えましょう。「伝えておきたかったのですが、Xへの対応はまさに私が必要としていたものでした。本当に大きな違いを生みました。」

評価： 活躍の場を与えましょう。リリースした機能のSlackでの告知を書いてもらい、公開の場で本人をメンションし、チームのメンバーが社内で評価されるよう働きかけましょう。称賛は、それを伝えるのに最適な人から届けましょう。VPが喜んでいるなら、本人からチームに直接伝えてもらいましょう。

---

2. 孤独 -> つながり

人々に無理に交流させることはできませんが、機会を作ることはできます。チームミーティング、オフィス外で集中して作業する日、勤務時間中のアクティビティ、そして本当の思い出につながる共同作業などです。

面接では、実際のチーム文化について正直に伝えましょう。チームの大半が既婚で子どもがおり、仕事の後に誰も集まらないなら、そのことを伝えてください。実際にはないものを期待したまま、入社させてはいけません。

---

3. 退屈 -> やりがい

最も効果的なのは、技術設計書の作成、新しいエンジニアのメンタリング、チーム横断の取り組みの主導、現在あなたが担当しているプロジェクト領域のオーナー役など、興味深いタスクを任せることです。

率直に尋ねましょう。「仕事にやりがいを感じていますか？ 今の仕事に足りないものは何ですか？」マネージャーは、開発者が何を望んでいるかを話し合わずに分かっていると思い込みがちです。

---

4. 行き詰まり -> 成長

やりがいを感じている開発者でも、先に進む道筋が見えなければ、行き詰まりを感じることがあります。キャリア計画はあなたの仕事です。

一緒に考えましょう。

• 次のレベルに必要な要件は何ですか？
• そのレベルまでどのくらいの距離がありますか？ その理由は何ですか？ 率直に伝えましょう。
• そこに到達するには、どのようなタスクを担当する必要がありますか？
• 昇進の決定者に、どのような実績を示す必要がありますか？

マネジメント職を希望していて、空きポストがない場合は、適切であれば副官の役割を任せて、仕事の一部を経験してもらいましょう。準備を支援してください。自分で決められない時期を約束してはいけません。

---

5. 無関心 -> 情熱

開発者がプロダクトや顧客に関心を持たず、技術的な難問にしか興味がない場合、仕事への意欲は長続きしません。顧客の成功事例を共有し、シニアリーダーを招いてチームと話してもらい、可能であれば開発者に顧客との会話に参加してもらうなど、チームを事業と結びつけましょう。

情熱を装ってはいけません。エンジニアが心から関心を持てる、顧客、事業、技術、またはオーナーシップとの本物のつながりを見つけましょう。

---

ストックオプションと株式報酬の話し合い

株式報酬は、報酬のなかでも特に誤解されやすく、表面化しない不満や、定着の機会を逃す原因にもなりがちです。EMとして、こうした話し合いに適切な形で臨むための背景情報を持っている、あるいは入手できる立場にあることがよくあります。

入社時

開発者が入社してストックオプションを付与されたとき、重要な数字は3つありますが、その意味を明確に説明できる人はほとんどいません。

• 行使価格（ストライクプライス）： 株式を保有するために、1株あたりいくら支払うかです。付与日の公正市場価値に基づいて設定されます。
• 現在価格（FMV）： 現在の会社の1株あたりの価値です。
• 10倍になった場合のシナリオ： 会社が10倍に成長した場合、どれほどの価値になり得るかです。

多くの人は、これらを理解しないままオファーレターに署名します。きちんと説明できる人になりましょう。

在籍中

追加付与は、一般的でありながら十分に活用されていない人材定着の手段です。1〜2年にわたって高い成果を上げると、開発者の当初の付与分は大部分が権利確定し、「ゴールデンハンドカフス」の効果が薄れていきます。追加付与は定着につながる価値を再び生み出し、長期的に投資していることを示します。

会社に追加付与制度があるなら、積極的に活用しましょう。開発者から申し出たり、転職活動を始めたりするまで待ってはいけません。

退職時

退職時によくある状況は3つあり、それぞれ異なる話し合いが必要です。

1. スタートアップに残り、大企業へ転職する場合： 権利未確定の株式報酬を手放すことになる可能性があります。何を手放すことになるのか、理解できるよう支援しましょう。
2. 流動化イベントの前に退職する場合： ほとんどのオプションは退職後90日で失効します。権利行使により利益が出るオプションがある場合、行使して費用を支払うかどうかを決める必要があります。
3. 長期間勤務した後に退職する場合： オプションの大部分が権利確定していれば、金銭面の状況は明確になりますが、それでも一緒に確認する価値があります。

こうした話し合いは、本人の意思に反して引き留めるためのものではありません。本人が自分の金銭面の状況をきちんと理解できるようにし、敬意をもって接するためのものです。

---

予算ゼロでできる称賛

最も心に残る称賛の場面の中には、費用がまったくかからないものもあります。効果があった具体的なアイデアをご紹介します。

工夫を凝らしたオンボーディング。 新しい開発者が入社したら、その人をチームに紹介する個人的なニュースレターを送りましょう。経歴や関心事、ちょっとした意外な情報を盛り込みます。単なるリソースではなく、一人の人として大切にされていることが伝わります。

昇進を祝う対面式のセレモニー。 開発者が昇進したら、Slack に投稿するだけで済ませないようにしましょう。新しい肩書きを記した実物の銘板を注文し、対面で贈るか、郵送します。その品物によって、その瞬間が現実のものになります。

誕生日ウィジェット。 エンジニアリングのダッシュボードやステータスページに、チームメンバーの誕生日を追加しましょう。一日中チームが見ている Grafana の画面に誰かの誕生日が表示されると、小さくても気づいてもらえる瞬間が生まれます。

上級リーダーとのサプライズ交流。 高い成果を上げている開発者と、普段なら接点のない VP や上級リーダーとのカジュアルな30分の会話を設定しましょう。プレゼンではなく、ただの会話です。伝わるメッセージは、「あなたのことを経営層も見ています」です。

一人ひとりに合わせた本。 開発者がある問題に苦労していると気づいたら、関連する本に個人的なメッセージを添えて贈りましょう。「あなたが何に取り組んでいるかを知るくらい、きちんと気にかけています」と伝わります。

---

エンジニアの意欲低下を示す5つの警告サイン

誰かが退職を申し出る頃には、数週間から数か月にわたる兆候を見逃していることがよくあります。次のような変化に注意しましょう。

1. アーキテクチャに関する会議で発言しなくなる
2. より良いプラクティスの導入を求めなくなる
3. ドキュメント作成の取り組みがなくなる
4. 技術的負債に関するチケットが、コメントもなく優先順位を下げられ続ける
5. スタンドアップでの報告が短くなり、機械的になる

個々の兆候だけなら、何も意味しないかもしれません。しかし、いくつも重なる場合は、本人はすでに心の中で別のオファーを受け入れており、書類が整うのを待っていることがよくあります。

---

別のオファーを受けた人への対応

まずは落ち着きましょう。「引き留めるには何が必要ですか？」とすぐに尋ねてはいけません。それでは、関係が単なる取引のように感じられてしまうことがあります。

次の順序で進めましょう。

1. 理解する：「転職活動を始めたきっかけは何ですか？」、「新しい職務では、今の職場で不足していると感じるどんなものが得られますか？」
2. **実現可能性を確かめる：**根本原因を実際に変えられますか。それとも、一時しのぎの対処しかできませんか？
3. **対抗案を検討する：**解決策が現実的で、すぐに実行でき、チームの他のメンバーにとっても公平な場合に限り、対抗案を提示しましょう。
4. **関係を大切にする：**退職する場合は、敬意を持って送り出しましょう。退職後も続く関係は大切です。

根本原因が退屈さ、行き詰まり、あるいは報酬であれば、具体的な行動を起こせる場合に限り、対抗案が功を奏することがあります。根本原因が信頼の欠如、無関心、または長期にわたる放置であれば、対抗案を提示しても、退職を先延ばしにするだけになりがちです。

---

避けるべきこと

• その人が具体的な評価、報酬の改善、または成長を必要としているときに、ありきたりな称賛をしないでください。
• 実質的な役割や意思決定権のない、形だけの成長機会を作らないでください。
• 退職する人に罪悪感を抱かせないでください。そうすると、正直に話すのは危険だと、チームの他のメンバーに伝わってしまいます。
• 自分では決められない昇進の時期を約束しないでください。
• 今まさに定着リスクがあるのに、年次評価の時期まで対応を待たないでください。

---

最後に

すべてを自分で決められるわけではありません。こちらでは応じられないオファーを受けたり、別の分野に移りたくなったり、起業したり、転居したりする人もいます。その時が来たら、良好な関係を保って別れましょう。個人的に受け止める必要はありません。

---

さらに詳しく

フレームワークの出典を知りたい場合、元の記事を読みたい場合、または詳しい背景を知りたい場合は、references/sources.mdを読んでください。

---

関連するスキル

• engineer-motivation - 3つの動機づけ要因のフレームワークは、意欲を失う前に、一人ひとりのモチベーションを理解するのに役立ちます
• managing-high-performers - 高い成果を上げる人には、退屈、行き詰まり、燃え尽きという特有の定着リスクがあります
• delegation - 挑戦しがいのある仕事を委任することは、定着を促す手段です
• 1on1s - その人が5つの状態のうちどれにあるかを見極める場です
• team-health - チーム全体の兆候は、多くの場合、これら5つの状態に当てはまります