mcpField
C
career-development

career-development

github.com/manager-dot-dev生産性116194 回インストール25 週間前に更新
リポジトリ

career-development について

career-development は、エンジニアのキャリアについて話し合うマネージャー向けのスキルです。影響範囲の評価、成長課題の特定、昇進準備の計画を支援し、既存のマネージャーや本人の情報を先に参照します。

主な機能

  1. 01影響範囲の段階で成長を評価
  2. 02昇進準備と時期を切り分け
  3. 03次の成長機会を特定
  4. 04キャリア面談の質問と行動計画を提示
  5. 05安定したマネジメント情報を保持

活用シーン

  1. 01社員とのキャリア面談を準備
  2. 02エンジニアの次の影響範囲を特定
  3. 03昇進の根拠と時期を計画
  4. 04成長停滞時の新たな課題を探す

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/manager-dot-dev/manager-skills --skill career-development

インストール後、Claude Code で/career-developmentを入力して読み込まれたか確認します。

同梱ファイルreferences/sources.md

詳細

キャリア開発

開始する前に

まず、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個します
  • 次の具体的なアクションを示し、役立つ場合はマネージャーがそのまま使える言い回しも提示します
  • 関連するフレームワークについて簡潔に触れますが、すべての要素を説明しないでください
  • 直接的な回答の後でのみ、詳しい説明を提案します

このスキルの使い方

  • この人物は成長段階のどこにいるか/現在の影響力のレベルはどの程度か? → 影響力の輪モデル
  • レポート対象者が特定の役職や時期に固執している → ターザン・メソッド
  • 誰かの成長が停滞しているように見える → 実際の成長とは
  • キャリア面談で何を話せばよいかわからない → キャリア面談の進め方
  • 今すぐ昇進を後押しすべきか判断する → 昇進への準備と昇進のタイミング

デフォルトの回答形式

キャリア開発を支援するときは、マネージャーがそのまま使える計画を作成します。

  1. 現在の成長状況の見立て: その人物が現在どの段階で働いているように見えるか。
  2. 次の成長課題: 次にどのような影響力を示す必要があるか。
  3. 面談での質問: 次回のキャリア面談で何を尋ねるか。
  4. 機会の創出: プロジェクト、可視性、メンタリング、オーナーシップ、担当範囲など。
  5. 期待値の設定: タイミング、根拠、昇進に関する制約について何を伝えるか。

昇進を約束しないでください。「成長する準備ができていること」と「組織に空きがあり、根拠がそろっていること」を区別してください。


影響力の輪モデル

エンジニアの現在地と今後の進路を考える際に役立つ枠組みです。影響力は同心円状に広がります。

個人 — 自分の専門技術を習得しています。信頼性の高い成果を出します。優れたコードを書き、オンコールに対応し、タスクを適切に完了します。これが基盤です。

チーム — チームをより良くします。新しいメンバーのオンボーディングを支援し、他のメンバーのコードを効果的にレビューし、有益なフィードバックを提供し、チームメイトをサポートします。その人がいないとチームに影響が出ます。

グループ — チーム横断の業務を形作ります。部門横断の取り組みを主導し、採用に参加し、チームをまたぐアーキテクチャ上の意思決定に影響を与えます。その影響力は所属チームの範囲を超えます。

会社 — 組織全体の成果を推進します。技術的な方向性を定め、複数のチームにわたる能力を高め、エンジニアリング組織全体の働き方に影響を与えます。

キャリア面談での活用方法:

  • そのエンジニアが、現在どの輪の範囲で一貫して力を発揮しているかを見極めます。
  • 次の段階に進むには、現在の輪の中でスキルを深めるだけでなく、影響力を広げる必要があります。
  • 昇進の根拠は、現在の輪でさらに優れた成果を出すことではなく、次の輪での実績です。

優れたコードを書く一方で、チームメイトの成長をまったく支援しないシニアエンジニアは、「個人」の輪では優れていますが、「チーム」の輪にはまだ入っていません。対応すべきなのはこのギャップであり、技術的な深さをさらに高めることではありません。


ターザン式

エンジニア(やマネージャー)は、キャリアは一直線に進むものだと考えがちです。エンジニア → シニア → スタッフ → プリンシパル、あるいは EM → ディレクター → VP のようにです。その結果、1本のキャリアラダーを最速で上ることに固執してしまいます。

実際には、シニア職には本人の能力と会社側のニーズの両方が必要です。スタッフエンジニアの役割を十分に担える能力があっても、今すぐ任せられるスタッフレベルの課題がないこともあります。役割が存在し、本人がその準備ができた時点で、そこに人材が必要でなければなりません。

ターザン式モデルは、目的地ではなく、次のつるに飛び移ることです。ターザンはジャングルを横断する道筋を計画するのではなく、次に手の届くつるをつかみ、届くところまで移動してから、次のつるを探します。キャリアも同じように進みます。

部下とのキャリア面談で役立つポイント:

  • 5年計画ではなく、次の一歩を見つける手助けをしましょう。
  • 横方向の異動や、別分野への「遠回り」が、後にシニアレベルのインパクトを生むための幅広い経験につながることはよくあります。
  • 特定の日付までに特定の肩書きを得ることへの固執は、たいてい逆効果です。適切な機会が存在していなければならず、それを無理に実現しようとすると悪い結果を招きます(たとえば、そのレベルに達する準備ができていないうちに、そのレベルの人材を必要とする会社へ移るなど)。

成長の実際の姿

成長は途切れのない直線ではなく、定着期間を挟みながら段階的に訪れます。エンジニアが成長している兆候:

  • 現在のコンフォートゾーンを少し超える課題に取り組んでいる
  • 以前なら上位者に判断を仰いでいたことを、自分で判断している
  • 学んだことを他の人に教えている
  • 担当する領域が広がっている

成長が止まっている兆候(および対処法):

  • 同じ課題、同じツールで、背伸びする機会がない — より難しい課題を任せましょう
  • 技術力は伸びているが、人間関係や影響力を築けていない — チーム横断の仕事を任せましょう
  • 同じ間違いを繰り返している — これは成長の問題ではなく、フィードバックの不足です。まずフィードバックに対処しましょう

キャリアについて話し合う

キャリア開発の話し合いは、重要度が高いと感じられるため、多くのマネージャーにとって気が重いものです。基本原則をいくつか紹介します。

助言する前に尋ねましょう。「今後1年で、あなたにとって成長とはどのようなものですか?」と聞くほうが、「あなたが取り組むべきだと思うのはこれです」と伝えるより効果的です。相手が実際に望んでいることが、想定とは大きく異なる場合もありますが、こう尋ねることで、より明確に把握できます。

**「本人の望み」と「会社のニーズ」を分けて考えましょう。**両者が一致しないときは、正直に伝えてください。スタッフ職への異動を望んでいても、チームにスタッフレベルの課題がないなら、そのことを伝え、それが何を意味するのか(別のチーム、別の会社、別の時期など)を一緒に考えましょう。

ギャップを具体的に伝えましょう。「もっとリーダーシップを発揮する必要があります」では役に立ちません。「私が感じているギャップは、プロジェクトで PM やデザイン担当者との合意形成をまだ主導できていないことです。要件を形作るのではなく、今も要件が提示されるのを待っています」と伝えれば、本人が行動に移せます。

**記録しましょう。**キャリアについて話し合った後は、話した内容を書き留めて、本人と共有してください。記憶はあてになりません。書面に残すことで、双方の責任が明確になります。


昇進の準備状況と昇進のタイミング

マネージャーが混同しがちな、別々の2つの問いです。

この人は昇進の準備ができていますか? — 一貫して次のレベルの役割を果たしていますか?そのレベルでインパクトを生み出してきた実績がありますか。それとも、たまたまそうした場面があっただけですか?

今が昇進を後押しする適切なタイミングですか? — 昇進に必要な人員枠や予算はありますか?評価調整のサイクルは近づいていますか?記録された証拠は十分にありますか?判断に関わる人たちに、本人の実績が十分に知られていますか?

両方の条件を満たす必要があります。準備ができていない人の昇進を後押しすると、自分の信頼を損ない、本人のキャリアをかえって後退させることがあります。準備ができた後も長く待たせると、信頼を損ない、本人を失うリスクがあります。

原則:本人の成長を支援している間に、昇進の根拠を作り始めましょう。インパクトを記録し、実績を知ってもらい、具体的な事例を準備してください。評価調整の時期になってから慌てて準備するのは避けましょう。


さらに詳しく

ユーザーがフレームワークの出典を尋ねたり、元の記事を読みたいと言ったり、このスキルのトピックについてさらに詳しい情報を求めたりした場合は、元記事(リンク付き)と書籍の全リストが記載された references/sources.md を読んでください。


関連スキル

  • 1on1s — 継続的なキャリアに関する話し合いを行う場です
  • performance-reviews — 昇進の実績は評価時に示します。その基礎はここで築かれます
  • managing-high-performers — 優秀な人材が意欲を保つには、成長につながる課題が必要です
  • management-transitions — エンジニアがマネジメント職を目指すべきかどうかについて相談に乗ります

コメント