優秀なプレイヤーを昇格させる組織ほど、管理職が壊れる。
━━━━━━━━━━━━━━━━━━━━━━
「なぜあの人が」と思ったことはないか
成績トップだったプレイヤーが、管理職に昇格した。
組織としては、当然の人事に見えた。
しかし半年後、そのチームがうまく回っていない。
部下が育たない。
数字が伸び悩む。
本人も、明らかに苦しそうだ。
「あんなに優秀だったのに、なぜ管理職になった途端うまくいかないのか」
多くの組織が、これを個人の適性の問題として片付ける。
「あの人は管理職に向いていなかった」
「プレイヤーとマネージャーは別の才能だから仕方ない」
半分正しく、半分間違っている。
問題は個人の適性だけではない。
組織が「プレイヤーとして優秀」を「管理職に向いている」と誤って接続していることだ。
この誤接続を繰り返す組織は、優秀なプレイヤーを昇格させるたびに、優秀な管理職ではなく、機能しない管理職を量産する。
━━━━━━━━━━━━━━━━━━━━━━
結論：昇格基準が「プレイヤーの評価関数」のままになっている
先に結論を言う。
優秀なプレイヤーを昇格させて管理職が壊れる根本原因は、昇格基準がプレイヤーの評価関数のまま設計されていることだ。
プレイヤーの評価関数は「自分がどれだけ成果を出したか」だ。
管理職の評価関数は「チームがどれだけ成果を出したか」だ。
この2つは、まったく別の能力を要求する。
プレイヤーとして成果を出す力と、チームに成果を出させる力は、相関が低い。
むしろ、優秀すぎるプレイヤーほど、後者の力を育てる機会がなかったというケースが多い。
多くの組織は、昇格の判断基準に「プレイヤーとしての実績」しか使っていない。
チームを動かす力、部下を育てる力、判断を委ねる力。
これらを測る仕組みを持たないまま、プレイヤーの成果だけを見て昇格させる。
だから、昇格するのは「管理職に向いている人」ではなく「プレイヤーとして優秀だった人」になる。
この2つは、別物だ。
━━━━━━━━━━━━━━━━━━━━━━
構造分解：なぜこの誤接続が起きるのか
昇格基準の誤接続が起きる構造には、3つの原因がある。
原因① 「わかりやすい実績」が評価されやすい
プレイヤーとしての成果は、数字で見える。
売上、達成率、案件数。
わかりやすく、比較しやすい。
一方、「チームを育てる力」「委譲する力」は、数字になりにくい。
評価する側も、測る仕組みを持っていない。
わかりやすい指標に頼ると、自然とプレイヤーの実績だけで昇格が決まる。
見えるものが評価され、見えにくいものは評価されない。
この非対称が、誤接続を生む。
原因② 「優秀な人に報いたい」という善意が、判断を歪める
成果を出したプレイヤーに、何かで報いたい。
この善意は自然な感情だ。
しかし、報いる手段が「昇格」しかない組織では、この善意が誤接続を生む。
本当は昇給や表彰で報いるべき成果が、昇格という別次元の意思決定に混ざる。
昇格は「報酬」ではなく「役割の転換」だ。
この区別がないまま、優秀な人への感謝の気持ちで昇格が決まる。
原因③ 「管理職の適性」を測る仕組みがない
多くの組織は、管理職に必要な能力を定義していない。
だから、昇格前にその適性を測る仕組みもない。
適性を測る仕組みがなければ、判断材料はプレイヤーとしての実績しか残らない。
結果として、実績主義の昇格が続く。
管理職の適性を定義し、測る仕組みを作らない限り、この構造は変わらない。
━━━━━━━━━━━━━━━━━━━━━━
具体例：現場で何が起きているか
ある企業の話だ。
営業部門で、圧倒的な成績を残していたプレイヤーがいた。
毎年トップの数字。
誰もが「昇格は当然だ」と思っていた。
管理職になった。
半年後、チームの数字が落ちた。
部下が次々と異動を希望した。
この管理職本人は苦しんでいた。
「自分がやった方が早い」という判断を繰り返し、部下に仕事が渡らなかった。
部下への指導は、自分の成功パターンの押し付けになっていた。
「自分はこうやって成果を出した。なぜできないんだ」
組織は「彼は管理職に向いていなかった」と結論づけた。
次の昇格でも、同じ基準を使った。
また同じことが起きた。
この組織が変えたのは、3人目の昇格候補が出たときだった。
昇格基準を見直した。
プレイヤーの実績に加えて、「部下に仕事を渡した経験があるか」「後輩の育成に関わった経験があるか」を評価項目に加えた。
昇格前に、小規模なチームリーダーとしての試用期間を設けた。
この試用期間で、プレイヤーの評価関数のままの人と、チームの評価関数に切り替えられる人が見えるようになった。
見極めた上で昇格させた結果、機能する管理職が育ち始めた。
変えたのは、個人の適性ではなく、昇格の設計だった。
━━━━━━━━━━━━━━━━━━━━━━
解決策：昇格基準を正しく設計する3つのステップ
ステップ① 「管理職の評価関数」を言語化する
管理職に何を期待するかを、明確に言語化する。
チームの成果を出せるか。
部下に仕事を渡せるか。
判断基準を作って共有できるか。
この評価関数を、プレイヤーの評価関数とは別に定義する。
定義しない限り、判断材料はプレイヤーの実績だけになる。
ステップ② 昇格前に「委譲の経験」を確認する
その人が、これまでに仕事を人に渡した経験があるかを確認する。
後輩の指導をしたことがあるか。
自分の仕事を人に任せて、育てた経験があるか。
この経験がない人をいきなり管理職にすると、委譲の練習をしないまま管理職の仕事を始めることになる。
小さな委譲の経験を積ませてから、昇格を判断する。
ステップ③ 「試用期間」を設計する
いきなり本格的な昇格をせず、小規模なリーダー経験を試用期間として設ける。
数名のチームを一時的に任せる。
その中で、プレイヤーの評価関数のままなのか、チームの評価関数に切り替えられているのかを見る。
この試用期間が、誤接続による昇格ミスマッチを防ぐ。
━━━━━━━━━━━━━━━━━━━━━━
チェックリスト：あなたの組織の昇格基準は正しく設計されているか
□ 昇格の判断基準が、プレイヤーとしての実績だけになっている
□ 管理職に必要な能力を、言語化したことがない
□ 昇格前に、部下や後輩を育てた経験を確認していない
□ 試用期間やリーダー経験を積ませる仕組みがない
□ 「優秀な人に報いたい」という理由だけで昇格させたことがある
□ 昇格後に機能しない管理職が繰り返し出ている
□ その原因を「個人の適性」だけで片付けている
3つ以上該当するなら、昇格基準がプレイヤーの評価関数のままになっている。
管理職の評価関数を言語化し、試用の仕組みを作る必要がある。
━━━━━━━━━━━━━━━━━━━━━━
よくある失敗：昇格基準を見直そうとする組織がやってしまうこと
失敗① 実績を評価しなくなる
昇格基準を見直そうとして、プレイヤーとしての実績を軽視し始める。
実績は依然として重要な判断材料だ。
実績「だけ」で決めることをやめるのであって、実績を無視するのは別の誤りだ。
失敗② 試用期間を設けずに、いきなり基準だけ厳しくする
評価項目を増やしただけで、実際に確認する仕組みを作らない。
書類上の基準が増えても、実態の見極めができなければ意味がない。
試用や経験の確認という、実際のプロセスを設計することが必要だ。
失敗③ 昇格しなかった優秀なプレイヤーへのケアを忘れる
昇格基準を厳しくした結果、優秀なプレイヤーが昇格できなくなる。
その人へのフォローがないと、モチベーションが下がる。
昇格以外の報い方、例えば専門職としてのキャリアパスを用意することも同時に設計する。
━━━━━━━━━━━━━━━━━━━━━━
逆張り：「昇格させないこと」も、優秀な人材への正しい対応だ
優秀なプレイヤーを昇格させないことに、罪悪感を持つ組織がある。
「あれだけ成果を出しているのに、昇格させないのは失礼ではないか」
しかし、向いていない人を管理職にすることは、本人にとっても不幸だ。
プレイヤーとして輝いていた人が、管理職になって毎日苦しむ。
チームも機能しない。
誰も得をしない。
本当に優秀な人材への正しい対応は、その人の強みが最も活きる場所を見極めることだ。
それが管理職であるとは限らない。
昇格させないことは、失礼でも冷遇でもない。
その人の強みを正しく評価した結果、別のキャリアパスを用意することだ。
すべての優秀な人を管理職にする必要はない。
この認識を組織が持てるかどうかが、昇格基準の正しい設計の前提になる。
━━━━━━━━━━━━━━━━━━━━━━
まとめ
優秀なプレイヤーを昇格させて管理職が壊れるのは、個人の適性の問題である前に、昇格基準がプレイヤーの評価関数のまま設計されているという組織の構造問題だ。
管理職の評価関数を言語化し、委譲の経験を確認し、試用期間を設けることで、この誤接続は防げる。
━━━━━━━━━━━━━━━━━━━━━━
次の一手：明日やること
次の昇格候補を一人思い浮かべる。
その人が「部下や後輩に仕事を渡して育てた経験」があるかを確認する。
ないなら、昇格の前に、小さな委譲の経験を積ませることから始める。
━━━━━━━━━━━━━━━━━━━━━━
管理職の評価関数をどう言語化し、昇格前の試用期間をどう設計し、委譲経験をどう積ませるか。
その完全な手順とテンプレートは、メンバーシップ内の仕事OSロードマップで公開している。
昇格設計を体系で学びたいなら、こちらへ。
→ https://note.com/kabu_nare/membership