エンジニアリングマネージャー（EM）は、技術チームの生産性と成長を最大化する役割です。優秀なプログラマーが必ずしも優秀なマネージャーになるわけではなく、求められるスキルセットが根本的に異なります。コードを書く時間は減り、代わりに人と向き合う時間が増えます。この転換期は「マネージャーの谷」と呼ばれ、個人貢献者としてのアイデンティティを手放す不安と、マネージャーとしてのスキルがまだ不十分な焦りに悩まされます。
しかし、EMの仕事は「コードが書けなくなった人がやる仕事」ではありません。組織のレバレッジを最大化し、チームメンバー全員の能力を引き出すことで、個人では達成できない大きな成果を生み出す、極めてクリエイティブな仕事です。Andy Groveの名著「High Output Management」が示すように、マネージャーのアウトプットは自分のチームと影響を及ぼす周囲のチームのアウトプットの総和です。10人のチームの生産性を20%向上させれば、それは2人分の仕事に相当します。
1on1はEMの最も重要な活動の一つです。週次で30分〜1時間の枠を各メンバーと設定し、以下の3つの領域をカバーします。1on1はマネージャーのための会議ではなく、メンバーのための時間です。アジェンダの主導権はメンバーに渡し、メンバーが話したいことを優先します。
業務の進捗と障害では、現在の仕事で困っていることやブロッカーを確認します。ただし、1on1をステータス報告の場にしてはいけません。進捗確認はスタンドアップやチケット管理ツールで行い、1on1ではより深い対話に時間を使います。「今一番困っていることは何か？」「私がサポートできることはあるか？」「最近のプロジェクトで楽しいと感じていることは？」といったオープンクエスチョンで始めるのが効果的です。
キャリアと成長では、メンバーの中長期的なキャリア目標を理解し、現在のプロジェクトがどう成長に寄与するかを一緒に考えます。半期に一度は、キャリアの方向性について掘り下げた対話を行いましょう。メンバーが「テックリード」を目指しているのか、「EM」を目指しているのか、あるいは「スペシャリスト」として特定の技術領域を深掘りしたいのかを理解することで、適切なアサインメントやストレッチの機会を提供できます。成長の機会は日常の業務の中にあり、少し背伸びが必要なタスクを意識的にアサインすることがEMの腕の見せ所です。
フィードバックの交換では、双方向のフィードバックを行います。特に重要なのは、EMからメンバーへのフィードバックだけでなく、メンバーからEMへのフィードバックを積極的に求めることです。「自分のマネジメントで改善すべき点はあるか？」と直接聞く勇気が必要です。最初は「特にない」と返されることが多いですが、繰り返し聞くことで、徐々に率直なフィードバックが得られるようになります。フィードバックをもらったら必ず感謝を示し、可能な範囲で行動に移すことで信頼関係が深まります。
評価はメンバーのモチベーションに直結するため、公正性と透明性が求められます。まず、評価基準を事前に明示することが重要です。「何をすれば評価されるか」が曖昧では、メンバーは何を頑張ればよいか分かりません。各グレードに期待される行動とスキルをラダー（はしご）として明文化し、チーム内で共有します。
エンジニアの評価では、コードの量や速度ではなく、インパクトを重視すべきです。難しいバグの修正、チーム全体の開発効率を上げるツールの導入、ジュニアメンバーへのメンタリング、ドキュメント整備による属人化の解消など、目に見えにくい貢献を適切に評価する仕組みが必要です。いわゆる「グルーワーク」（チームをつなぐ地味だが重要な仕事）を正当に評価することが、健全なチーム文化を育みます。
バイアスへの対処も重要です。直近の出来事を過大評価する「近接バイアス」、第一印象に引きずられる「ハロー効果」、自分に似た人を高く評価する「類似性バイアス」、声の大きい人を過大評価する傾向を意識的に排除します。評価期間を通じてメモを取り、事実に基づいた評価を行う習慣を身につけましょう。可能であれば、ピアレビュー（同僚からの360度評価）を取り入れることで、多角的な視点を確保できます。評価結果に対してはサプライズを避け、日頃のフィードバックと一貫したものにすることが信頼の基盤です。
高パフォーマンスチームの構築には、Googleのプロジェクトアリストテレスが示した「心理的安全性」が不可欠です。メンバーが失敗を恐れずに発言でき、新しいアイデアを試せる環境を作ることがEMの責任です。心理的安全性は、お互いを信頼し、対人リスクを取っても安全だと感じられる状態を指します。
具体的には、チームの文化を言語化すること（チーム憲章やワーキングアグリーメントの作成）、定期的なレトロスペクティブでの改善サイクルの確立、ペアプログラミングやモブプログラミングによる知識共有の促進が効果的です。EMが率先して自分の失敗を共有し、「失敗は学びの機会」というメッセージを行動で示すことも重要です。多様性のあるチーム構成を意識し、異なるバックグラウンドや経験がチームに持ち込まれることで、より創造的な問題解決が可能になります。
入会申込
ログイン
