お疲れ様です！IT業界で働くアライグマです！
先日、4年目のエンジニアから「リーダーになったのに自分でコードも書かないといけなくて、チームがまったくまとまらない」という相談を受けました。プレイングマネージャーとして、個人の成果とチームの成果の両方を求められる立場は、想像以上にハードです。
自分もコードを書きながら、メンバーの1on1をやり、チームの方向性を考え、上からは数字を求められる。これを「努力」で解決しようとすると、必ず破綻します。
本記事では、プレイングマネージャーがチームを機能させるために実践すべき1on1の設計と権限委譲の具体的なやり方を解説します。努力ではなく「構造」で問題を解決するアプローチを、実体験に基づいてお伝えします。
なぜプレイングマネージャーは詰むのか
プレイングマネージャーが機能しなくなるパターンは、ほぼ共通しています。
「自分がやった方が早い」から抜け出せない
技術力で評価されてリーダーになったエンジニアは、「自分がやった方が早い」「自分がやった方が品質が高い」と思いがちです。これは最初は正しいのですが、この状態を続けると必ず破綻します。
- 自分のキャパシティが上限になる：チームの成果がマネージャー個人の稼働時間に制約される
- メンバーが育たない：チャレンジングな仕事が回ってこないので、成長機会を失う
- 退職リスクが高まる：「やりがいがない」「成長できない」と感じたメンバーから辞めていく
1on1が「進捗確認」になっている
多くのプレイングマネージャーは1on1を「進捗確認の場」として運用しています。これは1on1の目的を完全に誤解しています。
進捗確認はSlackでできます。1on1でしかできないのは、メンバーのキャリアや成長、働き方に関する対話です。
35歳の壁を越えるエンジニアのキャリア戦略：マネジメントとスペシャリストの選択で解説したように、エンジニアは30代以降のキャリアに悩みを抱えています。1on1はその悩みに寄り添う場であるべきです。
IT女子 アラ美
ITアライグマ1on1を機能させる3つの原則
1on1を「面談」から「対話」に変えるための原則を紹介します。
原則1：アジェンダはメンバーが決める
1on1の主役はメンバーです。マネージャーが聞きたいことを聞く場ではありません。
- 事前にメンバーからアジェンダを出してもらう（Slackやドキュメントで共有）
- アジェンダがなければ「最近気になっていることは？」から入る
- 進捗確認やタスクの話は極力避ける（必要なら別途ミーティングを設定）
原則2：7割はメンバーが話す
マネージャーが7割話している1on1は失敗しています。理想は、マネージャーが話すのは3割以下。
- 相づちと質問で話を引き出す
- 自分の意見を言いたくなっても、まずは「どう思う？」と聞く
- 沈黙を恐れない（メンバーが考えている時間）
原則3：キャリアと成長の話をする
業務の話だけでなく、必ずキャリアや成長に関する対話を含めます。
- 「3年後にどうなっていたい？」
- 「今の仕事で伸ばせていると感じるスキルは？」
- 「逆に、もっとやりたいのにできていないことは？」
エンジニアがスキルシートで損しないための書き方と見せ方の実践ガイドで紹介しているスキルの棚卸しを、1on1の中で一緒にやるのも効果的です。
IT女子 アラ美ITアライグマ権限委譲で「自分がやらなくてもいい」状態を作る（ケーススタディ）
プレイングマネージャーが最も苦手なのが「権限委譲」です。しかし、これができないとチームは永遠にスケールしません。
状況（Before）
- チーム構成：マネージャー1名 + メンバー4名
- マネージャーの稼働：実装50% + マネジメント50%
- 課題：設計レビューと技術選定がマネージャーに集中し、メンバーは実装しか経験できない
- メンバーの声：「もっと上流から関わりたい」「成長を感じられない」
行動（Action）
ステップ1：委譲する領域を明確化
まず、自分がやっているタスクを全て洗い出し、「自分がやるべきこと」と「委譲できること」に分類しました。
具体的には、週に1時間を使って自分のタスクログを整理し、各タスクについて「失敗時の影響度」「メンバーが対応可能か」「成長機会になるか」の3軸で評価しました。
| タスク | 判断基準 | 結論 |
|---|---|---|
| 最終的な技術選定 | 失敗時の影響大 | 委譲しない（相談役） |
| 設計レビュー | 品質判断に経験が必要 | 段階的に委譲 |
| コードレビュー | メンバーでも可能 | 完全委譲 |
| 障害対応の初動 | 判断の練習になる | 段階的に委譲 |
ステップ2：委譲先を決める
「誰に」委譲するかは、意欲×能力で判断しました。
- 意欲も能力も高い：すぐに委譲して任せる
- 意欲は高いが能力が足りない：サポート付きで委譲（成長機会）
- 能力は高いが意欲がない：なぜ意欲がないかを1on1で探る
- 両方低い：まずは小さなタスクから経験を積ませる
たとえば、3年目のメンバーAさん（仮名）は「設計に関わりたい」という意欲が高かったので、まずは既存機能の改修設計を任せました。初回はレビューでフィードバックを行い、徐々に新規機能の設計へとステップアップさせました。3ヶ月後には、Aさんがチームの設計レビューを主導できるようになりました。
ステップ3：フィードバックループを作る
委譲しっぱなしにしないため、週次で「振り返り」を実施。
- 委譲したタスクの進捗と課題を共有
- うまくいったこと / うまくいかなかったことを言語化
- 次週に向けた改善策を一緒に考える
結果（After）
- マネージャーの稼働：実装50% → 30%に削減（マネジメントに集中）
- メンバーの成長：設計レビューを経験したメンバー2名がテックリード候補に
- エンゲージメント：「成長を感じる」というフィードバックが増加
- 離職率：その年の離職者ゼロ
会社に依存しないエンジニアのポータブルスキル設計：転職・独立に備える技術棚卸しで解説しているように、メンバーにとっても「委譲されて経験を積む」ことは転職市場での価値向上につながります。
IT女子 アラ美ITアライグマ委譲して育ったメンバーがチームを継承する
権限委譲の最大のメリットは、マネージャーが抜けてもチームが回るようになることです。
筆者が経験したチームでも、異動で別チームに移った際、委譲して育てていたメンバーがそのままテックリードとしてチームを継承してくれました。引き継ぎ期間は2週間で済み、チームのパフォーマンスは落ちませんでした。
逆に、委譲をせずに自分で全て抱えていたマネージャーが異動したチームでは、引き継ぎに1ヶ月以上かかり、その間プロジェクトが停滞した例も見てきました。
ミドルエンジニアの『年収頭打ち』突破戦略：便利屋を卒業して市場価値を高める3つの選択肢で解説しているように、「属人化」を避けるためにも権限委譲は重要です。マネージャーが1人で全て抱えるチームは、そのマネージャーが退職した途端に機能不全に陥ります。
さらなる年収アップやキャリアアップを目指すなら、ハイクラス向けの求人に特化した以下のサービスがおすすめです。
| 比較項目 | TechGo | レバテックダイレクト | ビズリーチ |
|---|---|---|---|
| 年収レンジ | 800万〜1,500万円ハイクラス特化 | 600万〜1,000万円IT専門スカウト | 700万〜2,000万円全業界・管理職含む |
| 技術スタック | モダン環境中心 | Web系に強い | 企業によりバラバラ |
| リモート率 | フルリモート前提多数 | 条件検索可能 | 原則出社も多い |
| おすすめ度 | 技術で稼ぐならここ | A受身で探すなら | Bマネジメント層向け |
| 公式サイト | 無料登録する | - | - |
IT女子 アラ美ITアライグマまとめ
プレイングマネージャーとして成果を出すには、「努力」ではなく「構造」を変える必要があります。
- 1on1は進捗確認ではなく、キャリアと成長の対話の場として再設計する
- アジェンダはメンバーが決め、7割はメンバーが話す1on1を目指す
- 権限委譲は「意欲×能力」で委譲先を決め、フィードバックループで支える
- 「自分がやった方が早い」を捨て、メンバーの成長にベットする
最初は時間がかかっても、委譲したメンバーが成長すれば、チーム全体のキャパシティは何倍にも増えます。短期の効率より、中長期の成長を選ぶ判断が、プレイングマネージャーには求められています。
IT女子 アラ美ITアライグマ
