エンジニアマネージャーの視点から、見放すべきチームメンバー

私はエンジニアとして現場を見つつマネージャー的ポジションもやっています。一般論として、マネージャーの責務とは
(A)プロジェクトの成功
(B)チームメンバーの成長支援
の２つがあると思います (スポーツの監督と同じですね！試合の指揮を執ることと、選手の成長支援という意味で)。しかし、ITエンジニアは自走式にいくらでも成長できるという点で特殊であり、後者の役目は極論すれば不要です。よって、パフォーマンスが悪いメンバーは即見放す対象になりがちです。そんな見放されるエンジニアの特徴をまとめてみたいと思います。どんな職種にも通ずる項目もありますし、エンジニアならではの項目もあります。

抽象的な指示が通じない

何か作業を頼む場合に、何を使って何を出すか事細かに指示をしないと動けない人。私もエンジニアなので、そこまで定義できたら自分でやったほうが手っ取り早いです。よく、マネジメントの極意で「自分でやったほうが早い」は悪手とされていますが、私は「作業の定義をマネージャーがやるなら、任せる意味はない」と読み替えて理解しています。

勉強してない

プロジェクトの閑散期にスキルを高めていない人。本人はプロジェクトを通して成長するつもりなのかもしれないですが、プロジェクトは能力を発揮する場であって、個人の成長は副産物に過ぎません。

キャリアプランがわからない

将来的に技術のエキスパートになりたいのか、顧客視点に長けたエンジニアになりたいのか、どういうキャリアプランを持っているのかわからない。結果として、どんな仕事を任せるのが良いのかわかりません。

期待を裏切り続ける

入社してすぐは能力値がわかっていないので、成果物が期待を下回ることは仕方ないです。しかし、数ヶ月経っても下回り続けると、もはや仕事を回されなくって挽回の余地がないと思います。

受け身

わからないことがあるのに、こちらが話しかけるまで聞いてこない人。進捗確認のタイミングで、「○○がわからなくて作業進んでいません」と平気で言われて唖然としたことがあります。どんな情報が足りないか整理して聞くなど、プロアクティブな行動をお願いしたいです。

批評家

できない理由を並べて、できる範囲でできることをしようとしない人。残念ことに、できないエンジニアほどプロジェクトにアサインされず暇なので、俯瞰的な思考だけが発達し、批評家になってしまうのかもしれません。

コードが汚い

プロジェクトが切羽詰まってきたとき、自分も現場に降りて2馬力にしなければならないことが発生しますが、コードが汚いとキャッチアップに膨大な時間がかかり、結局加速ができないです。追い込みをかけるという選択肢がなくなるリスクをヘッジするため、はじめからそのようなエンジニアをアサインすることは控えます。

まとめ: 新米マネージャーの方々へ

あなたはマネージャーを任されるくらいですから、優秀で人一倍の責任感があることでしょう。ただし、あなたが責任を持つべきは、プロジェクト成功に対してです。チームメンバーのために仕事をするのではありません。IT業界は自走式にいくらでも成長できる世界なので、経験不足という言い訳は成り立ちません。つまり、現状使えない人はどう煮ても焼いても使えない人のままなのです。そんな人に優秀なあなたのエネルギーを注ぐのはもったいないです。社内に使えないエンジニアしかいないとしたら、それはマネージャーの指導不足ではなく、人件費をケチった経営者の問題です。繰り返しますが、マネジメントができるエンジニアは貴重ですので、質の悪い人材相手に消耗しないでください。