エンジニアとして卓越していた人がリーダーになった途端、チームの動きが止まるケースがあります。問題はリーダーの意欲でも技術力でもなく、「役割の切り替えが起きていないこと」です。
チームが動かなくなる現場で起きていること
「あの件、私が引き取ります」「こっちの方が早い」——優秀なエンジニアほど、マネージャーになっても手を動かしてしまいます。
あるチームでは、リーダーがスプリントの約4割のタスクを自分で消化していました。短期的には成果が出るものの、半年後にはメンバーが「判断を待つ人」に変わり、リーダーが1日不在になるだけで何も動かない状態になっていました。
これはリーダーの才能の問題ではありません。エンジニアとして10年かけて培った「コードで価値を出す」反射が、リーダーとしての役割を上書きしてしまっているのです。
なぜ「技術的に優秀なこと」がリーダーの足を引っ張るのか
技術に長けたエンジニアがリーダーになったとき、2つの引力が働きます。
「自分でやった方が速い」バイアス。 経験値があるほど、手を動かした方がコストが低く見えます。判断の速さと実装の速さが一致しているため、委任という発想が生まれにくいのです。
フィードバックより修正という反射。 コードレビューで問題を見つけたとき、「なぜこう書いたか」を問う前に自分で直してしまいます。これがメンバーの思考の場を静かに奪っていきます。
結果として、リーダーが手を動かすほど、チームは「考える機会」を失っていきます。
リーダーが「手を止める」ことでチームが変わる3つの転換点
① レビューで「直す」前に「問う」
「ここは○○の方がいい」ではなく「なぜこう実装したの？」から始めます。メンバーの思考を引き出す問いが、長期的には設計力の育成につながります。
② 技術質問に「答え」ではなく「入り口」を返す
「自分ならこうする」という答えを先に渡すのをやめ、「どこで詰まってる？」と聞いてみます。メンバーが自力で結論に至る経験を積むことが重要です。
③ 週次で「自分が止めたこと」を1つ振り返る
「メンバーに任せた判断はあったか」を週1回自問する習慣を持ちます。これだけで、無意識の「引き取り」に気づく機会が生まれます。
さいごに
チームが育つかどうかは、リーダーの技術力より「手を止める勇気」で決まります。優秀なエンジニアのまま振る舞うのをやめる、その一歩がチームの自律を始動させます。
こうした組織設計や自律的なチームの作り方に関心があるエンジニア・リーダー候補の方は、ぜひ一度お話しできればうれしいです。