エンジニアリングマネージャーという仕事

• エンジニアの採用(どんなスキルの人が必要かを整理して求人票にまとめ、企業から候補者へ直接スカウトを送る「ダイレクトリクルーティング」や面接を担当)
• 開発の進め方のルール作り(例: 誰がいつまでに何を作るかを決める週次の定例会議、書いたプログラムを他のメンバーが確認してから公開する手順)
• メンバーとの1on1(上司と部下が定期的に1対1で話す面談)での悩み・キャリアの相談
• 開発計画の調整(PdM=「何を作るか」を決める担当や経営陣の要望と、チームが対応できる作業量を見比べて、公開時期を決める)

午前は朝会(チームの進捗を15分ほど共有する会)に参加し、その後は候補者へのスカウト文面の作成や書類の確認に充てることが多いです。午後は面接が1〜2件入り、合間にメンバーとの1on1(1人30分程度、週に数人分)を行い、夕方にPdMや経営陣と今週の優先順位を調整する、といった流れが一例です。

直接見るメンバーは数名〜10名前後の会社が多く、採用は同時に複数のポジションを並行して進めます。人数が少ない分、自分もコードのレビューなどに入る場面があります。

成果物とツールの対応では、採用したい人物像の整理にはスプレッドシートや文書ツールでの要件の言語化、開発の遅れの把握にはタスク管理ツール(作業の一覧と進み具合を管理するツール)の見方、経営陣への報告にはスライド資料で課題と対策を短くまとめる力が必要です。

• 自分でコードを書き続けることが一番の楽しみで、手を動かす時間を減らしたくない人
• 整ったルールや前例の中で仕事を進めたい人
• メンバーに厳しいことを伝える場面を避けたい人

• VPoE(開発組織全体の責任者)・CTOへ
• 急成長期の大きな組織のEMへ

• インフラ担当エンジニアの採用(経験者が少なく競争が激しいため、必要なスキルを絞って求人票にまとめ、スカウトや面接を担当)
• 障害対応の当番(オンコール=サービスが止まった時に呼び出されて対応する当番)の体制づくり
• 基盤の改善項目の優先順位づけ(例: 異常を早く知らせる監視の整備、新機能を本番環境へ公開する作業の自動化)
• クラウド費用(サーバーの利用料)の把握と、削減や増額の判断

午前は前日の障害やアラート(異常を知らせる通知)の有無を確認し、チームの朝会で今日の作業を決めます。午後は採用面接やメンバーとの1on1(上司と部下が定期的に1対1で話す面談)、プロダクト開発チームからの依頼の優先順位づけに時間を使い、夕方は改善作業のレビューをする、という流れが一例です。

基盤チームは2〜5名程度ということが多く、自分自身も障害対応の当番に入る場面があります。夜間や休日に呼び出される可能性があるため、当番表を回して負担が偏らないようにするのもEMの仕事です。

成果物とツールの対応では、障害後の振り返り資料(ポストモーテム=原因と再発防止策をまとめた文書)は文書ツールで、毎月のクラウド費用の集計はスプレッドシートで、改善計画の経営陣への説明はスライド資料でまとめる力が必要です。

• 夜間や休日の呼び出しの可能性に強いストレスを感じる人
• 最新技術を自分で触り続けることを一番の楽しみにしたい人
• 成果が「問題が起きないこと」という形で見えにくい仕事に物足りなさを感じる人

• VPoE(開発組織全体の責任者)・CTO(最高技術責任者)へ
• 急成長期の大きな基盤組織のEMへ

• チームの分割と人員配置(人数が増えて意思疎通が難しくなったチームを分け、それぞれの担当範囲を決める)
• 評価制度・等級(役割と期待値を段階に分けた表)の整備と、評価面談の運用
• 採用計画づくりと、面接を担当できるメンバーを増やすための面接官研修
• 新しくリーダーになったメンバーへのマネジメント指導(1on1=上司と部下が1対1で話す面談の進め方など)

午前は複数チームのリーダーとの定例会議で、各チームの進み具合や困りごとを確認します。午後は採用面接や、評価制度の見直しに向けた打ち合わせ、新しくリーダーになったメンバーとの1on1を行い、夕方にPdM(「何を作るか」を決める担当)や人事部門と人員計画を調整する、という流れが一例です。

担当範囲は体制によって差が大きく、数名のチームを複数見る形から、リーダーを通じて十数名以上を見る形まで幅があります。直接話せる人数に限りがあるため、リーダーを育てて任せていく動き方が増えていきます。

成果物とツールの対応では、人員計画や評価結果の集計にはExcel(またはスプレッドシート)での数値整理、評価制度の説明や経営陣への報告にはPowerPointでの構成力、開発の進み具合の把握にはタスク管理ツール(作業の一覧と進み具合を管理するツール)の見方が必要です。

• 少人数のチームで、現場に近い距離感で仕事をしたい人
• 一度決めたルールを長く安定して運用したい人
• 制度の説明や調整といった、地道な対話に時間を使うことが苦手な人

• VPoE(開発組織全体の責任者)へ
• 大手企業の開発部門責任者へ

• 基盤チームの役割分担の設計(例: サービスの安定運用を担うSREチームと、開発者が使う共通の開発・公開環境を提供するプラットフォームチームに分ける)
• SLO(サービスの品質目標。例: 1か月の稼働率99.9%以上)を、プロダクト開発チームと話し合って決める
• プロダクト開発チームからの依頼を受ける窓口づくりと、対応の優先順位の基準づくり
• 基盤エンジニアの採用、メンバーの目標設定・1on1(上司と部下が1対1で話す面談)・評価

午前は障害やアラート(異常を知らせる通知)の状況確認と、基盤チームの朝会が中心です。午後はプロダクト開発チームとの依頼の優先順位調整、採用面接、メンバーとの1on1を行い、夕方に障害後の振り返り(ポストモーテム=原因と再発防止策をまとめる会)に参加する、といった流れが一例です。

チームの規模は体制によって差が大きく、数名のチームを複数に分けて見る形が多いです。障害対応の当番(オンコール=サービスが止まった時に呼び出される当番)の表づくりや、負担の偏りを確認するのもEMの仕事になります。

成果物とツールの対応では、依頼の受付状況や対応の遅れの把握にはタスク管理ツール(作業の一覧と進み具合を管理するツール)、品質目標の達成状況の報告にはスライド資料、採用・人員の計画にはスプレッドシートでの数値整理が必要です。

• 目の前の技術課題を自分の手で解決することに一番のやりがいを感じる人
• 依頼を断ったり優先順位を伝えたりする場面に強い抵抗がある人
• 緊急時の連絡や判断を求められる場面を避けたい人

• VPoE(開発組織全体の責任者)・CTO(最高技術責任者)へ
• 大手企業の基盤組織の責任者へ

• 会社共通の人事制度に沿ったメンバーの目標設定・評価面談(1on1=上司と部下が定期的に1対1で話す面談を含む)
• チームの予算管理(人件費、外部の開発会社への発注費など)
• 他部署との調整(例: 企画部門、公開前に不具合がないかを確認する品質保証部門、情報漏えい対策を担うセキュリティ部門)
• 外部の開発パートナー(開発を請け負う他社)の進捗・品質の管理

午前は朝会や、部署をまたぐ関係者との定例会議に出席します。午後はメンバーとの1on1や評価面談、外部の開発パートナーとの進捗確認を行い、夕方に上長への報告資料を作る、といった流れが一例です。重要な判断は稟議(上司や関係部署に承認を求める社内手続き)を通すため、承認に必要な資料を先回りして準備する場面があります。

担当するチームは数名〜十数名ほどの規模が多く、企業や部署によって差が大きいです。新しいメンバーが入るときは、人事部門が採用を進め、EMは現場の面接官や受け入れ準備を担当する形が一般的です。

成果物とツールの対応では、予算の管理にはExcelでの数値整理、上長や他部署への報告・提案にはPowerPointでの資料構成、メンバーの評価コメントの記録には人事システムや文書ツールの操作が必要です。

• 自分の判断で素早く仕組みを変えていきたい人
• 承認や手続きに時間がかかる環境にストレスを感じやすい人
• 調整や資料作成より、技術に集中して手を動かしたい人

• 開発部門の責任者(部長・本部長クラス)へ
• スタートアップのVPoE(開発組織全体の責任者)への転身も

• 複数の基盤チームの連携の管理(例: 運用保守、クラウド基盤、セキュリティの各チームの役割分担と連絡経路の整理)
• 運用を委託している外部会社の管理(契約内容に沿って運用が行われているかの確認)
• 障害時の指揮(原因の切り分けの進行、関係部署への連絡、復旧後の振り返りの取りまとめ)
• 年間予算とクラウド費用(サーバーの利用料)の管理、監査対応(セキュリティや法令の規定を満たしているかを確認される手続きへの対応)

午前は夜間の障害やアラート(異常を知らせる通知)の確認と、各チームのリーダーとの定例会議が中心です。午後は外部の運用委託会社との打ち合わせ、メンバーとの1on1(上司と部下が定期的に1対1で話す面談)や評価面談、予算の確認を行い、夕方に上長への報告資料を作る、といった流れが一例です。

統括する組織の規模は企業によって大きく異なり、複数のチームと外部委託先を合わせて見る形が多いです。障害の対応は、現場の担当者が復旧し、EMは関係部署への連絡や状況報告、判断の取りまとめを担うのが一般的です。

成果物とツールの対応では、障害後の振り返り(ポストモーテム=原因と再発防止策をまとめた文書)は文書ツール、予算とクラウド費用の管理はExcelでの数値整理、経営層や上長への報告はPowerPointでの資料構成が必要です。

• 新しい技術を素早く試して導入していくことを一番の楽しみにしたい人
• 担当の範囲が分業で区切られていることに窮屈さを感じる人
• 報告書や監査対応など、記録を整える業務に抵抗がある人

• IT部門・基盤部門の責任者(部長・本部長クラス)へ
• スタートアップのVPoE(開発組織全体の責任者)・CTO(最高技術責任者。会社の技術面の責任者)への転身も