エンジニアリングマネージャーの職務記述書（テンプレートとスキル）
Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
エンジニアリングマネージャーの職務記述書は、話す前から適切な候補者を惹きつけるか、ふるい落とすかのどちらかの働きをします。役割の範囲、スキルリスト、報酬のシグナルを正しく設定すれば、面接の時間を期待値のズレの解消ではなく、マッチ度の見極めに使えるようになります。
このガイドでは、コピー&ペーストできるテンプレート、スキル一覧表、役割比較チャート、そして成果につながる求人票を書くための簡潔なチェックリストを提供します。
エンジニアリングマネージャーの仕事とは?
エンジニアリングマネージャー（EM）は、ソフトウェアエンジニアリングチームを率い、人材マネジメントと技術面での監督、そしてデリバリーに対する責任を兼ね備えた役割です。EMはチームの成果、個々のメンバーのキャリア成長、そしてプロダクトやプラットフォームのロードマップの日々の実行を担います。
シニアエンジニアと異なり、EMの主なレバーは自分自身のコードではなくチームです。VP of Engineeringとも異なり、EMは現場に近い立場を保ち、エンジニアの障害を取り除き、1on1を実施し、ボトルネックにならない形でコード品質のレビューを行い、プロダクト側とスコープや優先順位について連携することが求められます。
主要な事実
- 年間中央値給与（米国）: マネジメント責任を持つソフトウェア品質保証エンジニアおよびソフトウェアエンジニアの中央値年収は$167,020です（米国労働統計局、職業雇用統計、2023年5月時点、エンジニアリングマネージャーに最も近いBLSの分類）
- 雇用成長率（2022〜2032年）: ソフトウェア開発者および関連するマネージャー職は、今後10年間で25%成長すると予測されています（米国労働統計局、コンピューターおよび情報技術関連職種、2023年）
- 一般的なマネジメント範囲: 多くのテクノロジー企業では直属の部下は4〜8名で、チーム規模が大きい場合はシニアEMのもとで複数のスクワッドに分割されることもよくあります
エンジニアリングマネージャーの職務記述書テンプレート
以下のブロックをコピーして、自社の内容にカスタマイズしてください。角かっこ内のテキストは自社の情報に置き換えてください。
職種名： エンジニアリングマネージャー
チーム： [プラットフォーム / プロダクト / インフラストラクチャー / モバイル など]
勤務地： [市区町村、都道府県 / リモート / ハイブリッド]
レポートライン： [VP of Engineering / Director of Engineering / CTO]
役割の概要
私たちは、[チームが担当する内容の簡単な説明]を構築する[4〜8]名のエンジニアチームを率いるエンジニアリングマネージャーを募集しています。デリバリー、品質、そしてチーム全員の成長に責任を持っていただきます。プロダクトやデザインと密接に連携してロードマップを実際にリリースされるソフトウェアへと落とし込み、[プロダクト領域またはプラットフォーム]の技術的な方向性を定める一助を担っていただきます。
この役割は、人のマネジメントを心から楽しめて、技術的な会話を深いレベルで交わすことができ、個人の成果ではなくチームの成果に責任を持ちたいと考える方に適しています。
主な職務内容
- 直属の部下全員との週次の1on1、四半期レビュー、キャリア成長に関する対話を実施する
- チームのスプリント計画、バックログの精緻化、リリース調整を統括する
- プロダクトマネージャーと連携して機能のスコープを定め、スケジュールを調整し、優先順位の対立を解決する
- チームレベルのOKR、ベロシティ、品質指標を設定し、追跡する
- コードおよびシステムの品質を維持するため、アーキテクチャレビューおよび設計レビューに参加する
- 採用をリードする: レベルに応じた職務記述書を作成し、面接を実施し、適正なオファーを出す
- 担当領域におけるインシデント、障害、本番環境の問題をエスカレーションし、解決する
- チームの健全性に関する問題が定着率や成果に影響する前に、それを特定し対処する
- 部門横断的な計画会議やステークホルダーレビューでエンジニアリング部門を代表する
必須要件
- ソフトウェアエンジニアリング経験5年以上、うちエンジニアのマネジメント経験2年以上
- 4名以上のチームで複雑なプロジェクトを完遂した実績
- 人事評価およびキャリブレーション面談を実施した経験
- [主要技術スタック: 例、Python/Go、React/TypeScript、Javaなど]におけるコードやシステム設計、アーキテクチャのトレードオフを読み解き、議論できること
- 非同期を前提とした分散チームにおける高い文章力と口頭でのコミュニケーション能力
- Agile/ScrumまたはKanbanのデリバリーフレームワークの経験
歓迎要件
- 採用とオンボーディングを通じてチームを[現在の規模]から[目標の規模]へ拡大した経験
- [関連領域: 例、データインフラストラクチャー、コンシューマー向けモバイル、フィンテックのコンプライアンスなど]でのバックグラウンド
- [具体的なツール: 例、Jira、Linear、Datadog、GitHub Actions]に精通していること
- マネジメントに移る前にテックリードとして活動した経験
- オンコールローテーションの運用およびSLA管理への関与経験
提供する条件
- 基本給: 経験や勤務地に応じて[$X〜$Y]
- 年間業績賞与: [基本給の10〜20%]
- エクイティ: [RSUまたはストックオプションの詳細]
- 医療、歯科、視力の保険を提供し、保険料の%を会社が負担
- 学習予算: 講座、書籍、カンファレンス費用として[$X/年]
- [リモート / ハイブリッド]勤務: [出社に関する詳細な条件]
- Senior EM、Director of Engineering、VP of Engineeringへの明確なキャリアパス
主要なスキルとコンピテンシー
| スキル | 重要な理由 |
|---|---|
| 人材マネジメント | EMは業務時間の大半を、コーディングではなく採用、コーチング、パフォーマンスマネジメントに費やします。ここが弱いとエンジニアの離職につながります。 |
| 1on1とコーチング | 定期的で構造化された1on1は、エンジニアの障害を取り除き、離職リスクを早期に把握するための主要な手段です。 |
| プロジェクトデリバリー | チームが予測可能な形でリリースできる能力は、EMにとって最も目に見える成果です。これにはスコープの調整、リスクの特定、依存関係の管理が求められます。 |
| 技術的判断力 | EMは毎日本番用のコードを書く必要はありませんが、アーキテクチャ上のミスを見抜き、質の高いレベルでプルリクエストをレビューし、シニアエンジニアからの信頼を得る必要があります。 |
| 採用 | 多くのEMの役割には、チームの採用ファネル全体を担うことが含まれます。採用の失敗は、6〜12か月分の生産性の損失とチームの混乱というコストを生みます。 |
| ステークホルダーとのコミュニケーション | EMは、エンジニアリングのスケジュールや制約を、プロダクト、デザイン、経営層に向けたビジネス言語に翻訳します。 |
エンジニアリングマネージャー vs テックリード vs シニアエンジニア
これら3つの役割は求人票の中でしばしば混同されます。この違いが重要なのは、混同すると候補者にも組織の他のメンバーにも誤った期待を生んでしまうからです。
| 観点 | シニアエンジニア | テックリード | エンジニアリングマネージャー |
|---|---|---|---|
| 主な焦点 | 個人としての技術的な成果 | プロジェクトやスクワッドの技術的な方向性 | 人材、プロセス、チームの成果 |
| 責任範囲 | 自分自身のコードと設計 | 機能領域全体にわたる技術品質とアーキテクチャ | チームのデリバリー、採用、キャリア成長 |
| ICかマネジメントか | 個人貢献者（IC） | 調整責任を持つ個人貢献者（IC） | 人材マネージャー（人事評価、報酬、昇進を担当） |
| コードへの貢献度 | 高い（主要な成果物） | 中程度（自ら手本を示すが、時間とともに減ることもある） | ほとんどの企業では低いかゼロ（書くのではなくレビューする） |
| キャリアトラック | ICトラック（Staff、Principal） | ICのまま留まるか、EMへ転向することも可能 | マネジメントトラック（Senior EM、Director、VP） |
| レポート先 | EMまたはテックリード | EM | Director of EngineeringまたはVP of Engineering |
技術的な仕事を続けたいテックリードを、無理にEMの役割に押し込むべきではありません。多くの企業は、マネジメントをキャリア成長の唯一の形として扱うことで、優秀なテックリードを失っています。
効果的なエンジニアリングマネージャーの職務記述書の書き方
ステップ1: レベルとチームの範囲を明確にする
あいまいな求人票は、あいまいな応募者しか惹きつけません。チーム規模、チームが担当する範囲、レポートラインを具体的に示しましょう。「Engineering Manager, Growth」という表記だけでは、候補者にほとんど何も伝わりません。「Engineering Manager, Growth（エンジニア6名、獲得ファネルを担当、VP of Product Engineeringに直属）」であれば、その役割が自分に合っているかどうかを10秒で判断できます。
ステップ2: タスクではなく成果を記載する
「エンジニアチームをマネジメントする」という表現を、「[Y]人のユーザーに向けて[X]のプロダクト領域を、重大インシデント発生率[Z]%未満でリリースする」といった表現に置き換えましょう。成果を示すことで、結果志向の候補者を惹きつけられると同時に、面接官にも明確な評価基準を提供できます。
ステップ3: 必須要件と歓迎要件を分ける
複数の調査で一貫して示されているのは、女性やマイノリティの候補者は要件をほぼ100%満たしていない限り応募しない傾向があるということです。必須要件と歓迎要件を区別しない15項目の要件リストは、質を高めることなく応募者層を狭めてしまいます。本当に譲れない条件だけを「必須要件」に入れ、「歓迎要件」のリストは正直な内容にしておきましょう。
ステップ4: 技術スタックとチーム規模を具体的に示す
「当社の技術スタックの経験」という表現には意味がありません。言語、フレームワーク、ツールを具体的に挙げましょう。EMの役割では、技術スタックによって面接の技術的なハードルの高さや、異なるエコシステム出身の候補者が立ち上がれるかどうかが決まります。3名のエンジニアをマネジメントするのと12名をマネジメントするのとでは仕事の内容が異なるため、チーム規模も重要です。
ステップ5: 報酬とキャリアパスを含める
給与レンジの掲載は、カリフォルニア州、コロラド州、ニューヨーク州、ワシントン州では現在法律で義務付けられています。法令順守という観点だけでなく、給与レンジを掲載することで応募者数が増え、候補者が自分に合ったレベルを自己判断できるため、オファーまでの期間も短縮されます。昇進トラック（Senior EM、Directorなど）も記載し、候補者にこの役割にキャリアの将来性があることを伝えましょう。
エンジニアリングマネージャー向けの面接質問
リーダーシップと人材マネジメント
- 部下に厳しいパフォーマンスフィードバックを伝えなければならなかった経験について教えてください。何を伝え、その後どうなりましたか?
- 1on1はどのように構成していますか? 毎回必ず扱うトピックは何ですか?
- 誰かを解雇したり、パフォーマンス改善プランに乗せたりしなければならなかった経験について教えてください。その会話に向けてどのように準備しましたか?
デリバリーと実行
- スケジュールが遅延したプロジェクトについて説明してください。遅延の原因は何で、次回は何を変えますか?
- プロダクトのスコープに対して押し戻すべきか、期限を約束すべきか、どのように判断しますか?
- チームの健全性と成果を測るために、どのような指標を追跡していますか?
技術的判断力
- 過去1年でチームが下したアーキテクチャに関する意思決定について教えてください。どのような選択肢を検討し、どのように決定しましたか?
- コードレビューのボトルネックにならないようにしながら、チームが行っている技術的な作業をどのように把握していますか?
採用とチームビルディング
- 採用時のレベル判定はどのように調整していますか? あなたの基準では、シニアエンジニアとスタッフエンジニアを分けるものは何ですか?
- これまでで最も効果的だったソーシングチャネルについて説明してください。なぜうまくいったのですか?
エンジニアリングマネージャーの職務記述書に関するFAQ
エンジニアリングマネージャーとテックリードの違いは何ですか?
テックリードは、プロジェクトやスクワッドの技術的な方向性を導く個人貢献者（IC）です。エンジニアリングマネージャーは人材マネージャーであり、人事評価を行い、報酬に関する提案を行い、チームのデリバリーと定着率に責任を持ちます。チーム規模が小さい企業ではこれらの役割を統合していることもありますが、分離することで両方の役割がより高い専念度を発揮できます。
エンジニアリングマネージャーは今でもコードを書きますか?
会社の規模やチームのステージによって異なります。アーリーステージのスタートアップでは、EMが直接コードを書くことも多くあります。エンジニアが50名を超える企業では、ほとんどのEMは本番用のコードをほとんど、あるいはまったく書きません。彼らの価値は、個人としての貢献ではなく、チーム全体の成果を何倍にも増幅させることにあります。中堅から大企業の職務記述書の多くは、EMがスプリントのチケットを担当するのではなく、レビュー、アドバイス、そして時折プロトタイプ作成を行うことを想定しています。
エンジニアリングマネージャーの一般的なチーム規模はどのくらいですか?
最も一般的なマネジメント範囲は、直属の部下4〜8名です。4名未満では、フルタイムのマネジメントにかかるコストを正当化しにくいことが多くあります。8名を超えると、コミュニケーションの質が下がり、一人ひとりへの目配りが行き届きにくくなる傾向があります。Senior EMや「マネージャーのマネージャー」であれば、チームリードを介してより大規模な組織を統括することも可能です。
米国におけるエンジニアリングマネージャーの給与レンジはどのくらいですか?
米国労働統計局のデータ（2023年5月時点）によると、マネジメント責任を持つソフトウェア開発者および関連職種の年間中央値給与は約$167,000です。総報酬額には大きな幅があります。サンフランシスコやシアトルのような生活コストの高いテックハブでは、経験豊富なEMのターゲット報酬（基本給とエクイティの合計）が$250,000を超えることも珍しくありません。リモート職や中堅企業の役職では、基本給が$130,000から$180,000の範囲になる傾向があります。
エンジニアリングマネージャーの役割にCSの学位を必須にすべきですか?
学位要件は、ブートキャンプや独学、隣接領域など、別の経路でエンジニアリングを学んだ候補者を主にふるい落としてしまいます。優秀なEMの多くは、CS以外のバックグラウンドを持っています。より良い選別方法は、ソフトウェアをリリースし、エンジニアを率い、技術的なトレードオフについて議論できる実証済みの能力を見ることです。要件は、学歴ではなく経験と成果に焦点を当てましょう。
強いエンジニアリング組織を築くことは、採用プロセスそのものの明確さから始まります。精緻な職務記述書は、自社が何を必要としているかを理解していることを候補者に伝えると同時に、面接パネルに一貫した評価基準を提供します。上記のテンプレートを出発点として、自社のチームの実際のスコープや技術スタックに合わせてカスタマイズし、役割が変化するたびに見直していきましょう。
関連する採用テンプレートとして、UXデザイナーの職務記述書、フルスタック開発者の職務記述書、クラウドアーキテクトの職務記述書もご覧ください。より広いプロダクト組織を構築する場合は、グループプロダクトマネージャーの職務記述書やAIエンジニアの職務記述書も、エンジニアリングリーダーシップとしばしば連携したりレポートラインを持ったりする隣接する役割として参考になります。
この役割に就いた後に特に重要となるマネジメントスキルについては、リーダーシップとマネジメントの違いおよび委任（デリゲーション）に関する記事を、オンボーディングの際に共有する価値があります。
Senior Operations & Growth Strategist