エンジニアリングマネージャーの面接：委任・育成・技術判断の事例を準備する

エンジニアリングマネージャーの面接に向けて事例を準備するときは、「チームで障害を解決した」「メンバーを育成した」で止めず、自分が何を判断し、誰に何を任せ、どの証拠で結果を確認したかまで整理してください。技術的な原因を説明できても、周囲の仕事と自分の責任が混ざっていると、管理者としての行動を確かめられません。

この記事は、社内検索の更新遅延と、新機能の納期が重なった架空のケースを使います。減っている未処理件数、増えている最古の待ち時間、「実装完了」という報告、未完了の公開チェックを読み合わせ、委任・フィードバック・技術判断を一つの事例として準備します。Explain project scope, timeline, and delegationへの回答にも使える練習です。

証拠の区分： GitLabの職務記述は同社の役割の公式例、Google SREの資料は障害対応の公開ガイダンス、CCLの資料はフィードバック手法の説明です。日本企業共通の選考基準ではありません。同じ採用時期の候補者報告で裏付けた面接形式や出題頻度は、本稿では扱いません。以下の人名、記録、工数、会話、追加観測はすべて学習用の架空条件です。管理行動の提案はその条件からの推論であり、実際の育成成果ではありません。

管理事例では、役割・判断・結果を別々に用意する

応募先のEMが何を担当するかは、職務記述と採用担当者に確認します。直属メンバーの評価、採用、技術方針、納期調整、障害対応のどこまでを持つのかで、示すべき経験が変わります。「EMだから全権を持つ」と仮定せず、実際に経験した権限の範囲を話してください。

公式の職務例： GitLabのEngineering Manager職務記述は、定期的で明確なフィードバック、チームの技術的意思決定の促進、必要時の最終判断などを挙げています。一社の例として、自分の事例に人の支援と技術判断の両方があるか見直す材料になります。掲載されている採用手順を、応募先の手順に置き換えないでください。

過去の事例は、役割、当時の情報、選択肢、判断、他者の実行、確認した結果を分けて準備します。資料をそのまま外部に持ち出す必要はありません。守秘義務を守り、個人や顧客が特定されない形で、判断に必要な構造だけ説明します。架空の練習と過去の実務も明確に分けます。

たとえば、メンターとしてレビューを支援した経験は、正式な人事評価を行った経験ではありません。障害中の連絡を担当したことも、技術的な変更を承認したこととは別です。経験のない権限を補って話すより、実際に決めたことと、上司や担当者に相談したことを示すほうが、追加質問にも具体的に答えられます。

ケースの記録を読む：「減っている」と「復旧した」は違う

架空のチームは、EM、テックリードの木村、運用担当の佐藤、機能実装を担当する新井で構成します。木村・佐藤・新井の3人がエンジニアです。社内文書の検索インデックスに更新遅延があり、新しい文書が検索へ反映されるまで待たされる利用者がいます。

同じ監視定義で、次の値が記録されたとします。「最古」は未処理の更新が投入されてからの待ち時間です。この三点だけでは、遅延している文書の種類や、利用者への影響の範囲は分かりません。

09:00から09:20で件数は半分になっています。一方、最古の待ち時間は15分増えています。全体の件数だけを根拠に復旧を宣言するのは早い、というのがこのケースからの推論です。特定の更新が再試行を繰り返しているのか、処理順序が変わったのか、計測が正しいのかは追加確認が必要です。根本原因を「一件の壊れたジョブ」と決めつけません。

EMは、担当者に「古い更新が何に対応しているか」「検索結果にどのような影響があるか」「監視の集計範囲や時計は一貫しているか」を確認してもらいます。システム内部の未処理件数と、利用者が必要な文書を見つけられることをつなぐためです。

関係者への初報は、「件数は12,000件から6,000件へ減りましたが、最古の待ち時間は45分です。古い更新が残る理由と利用者への影響を調査中です」とできます。復旧時刻を推測で埋める代わりに、次に何を確認し、いつ情報を更新するかを伝えます。報告の時刻はチームと合意するもので、本稿の数字から復旧予定が計算できるわけではありません。

委任では、担当だけでなく判断できる範囲を渡す

「木村さん、対応をお願いします」だけでは、誰が優先順位を決め、誰が変更を行い、誰が外部へ説明するかが曖昧です。今回の練習では、木村を対応の統括役、佐藤を調査・操作の担当、EMを関係者への説明と納期調整の担当とする案を考えます。実際には既存の当番や指揮系統を確認して割り当てます。

公開の運用ガイダンス： Google SREのManaging Incidentsは、指揮、運用、連絡などの役割を分け、担当と境界を明確にする考え方を説明しています。この役割分担を今回のケースへ応用します。EMが必ず統括役になる、という意味ではありません。

委任した後も、担当者が受け取った内容を確認します。期待する結果、判断してよいこと、相談する条件、次に確認する時点が共通になっているかを確かめてください。認識が違えば、必要な相談が遅れたり、同じ作業に複数の指示が出たりする可能性があります。任せたのに細かい指示を別々に送ると、統括役の判断を妨げる可能性があります。

担当者の経験に応じて支援も変えます。新しい操作なら、変更前の説明や経験者との確認を組み込みます。経験のある人には、必要な結果と制約を示して方法の判断を任せられます。障害中に成長機会を作るとしても、利用者への影響が読めない変更を練習として任せる理由にはしません。

「実装完了」と未完了の確認表を、どう話し合うか

もう一つの記録を加えます。新井は昨日の共有欄に「実装完了」と書いています。公開チェックは6項目で、入力形式・表示・入力検証・再試行の4項目が通過しています。権限境界の確認はテスト用アカウント待ちで進められず、更新反映の確認はまだ実行していません。

この記録から、新井が怠けた、あるいは虚偽の報告をした、と断定することはできません。EM自身が実装完了を公開準備完了と読み替えたことも、振り返る対象です。障害の原因究明と、本人へのフィードバックは混ぜず、まず必要な公開条件と支援の不足を確認します。

公開のフィードバック手法： CCLのSBIと意図確認の説明は、具体的な状況、観察した行動、影響を伝え、本人の意図を尋ねる方法を示しています。次の会話はその考え方を応用した架空例です。相手の意図が既に分かっている前提ではありません。

昨日の共有欄で「実装完了」と書かれていて、私は公開準備まで終わったと受け取りました。確認表にはアカウント待ちと未実行の項目が残っているため、関係者へ説明した予定を修正する必要があります。私が確認せず言い換えた点は訂正します。「完了」はどの範囲を指していましたか。アカウントの準備は誰と調整していましたか。

本人の説明を聞いたうえで、次からは「実装」「確認」「公開判断」を分けて記載する案を合意します。アカウント準備の担当者も決めます。「もっと主体性を持って」とだけ伝えるより、何をいつ共有し、困ったときに誰へ相談するかを明確にできます。EM側も依存作業の準備と説明の確認方法を変えます。

育成の結果は、小さな観測から言い過ぎない

育成事例として話すなら、助言した内容だけでなく、本人が次にどう判断したかを確認します。この架空ケースでは、その後の二つの変更で、実装済みの範囲、未確認項目、必要な支援が分けて記載された、と追加観測を置けます。これは記録の改善を示しますが、本人がすべての公開判断を独立して行えるようになった証拠ではありません。

本人が自分で依存作業を見つけたか、相談のタイミングを選べたか、確認結果から次の行動を変えたかを、継続して見ます。レビュー担当が全部書き直した結果なら、本人の判断が変わったと評価するには情報が足りません。観測した変化、まだ支援したこと、今後確認したいことを分けて説明してください。

過去の面接事例では、他者の評価や私生活を詳しく開示する必要はありません。支援内容と仕事上の観測を匿名化して説明し、正式な評価や昇格の決定に関与していなければ、その境界を明示します。二つの変更だけで昇格相当と断定せず、役割の期待、継続性、本人への説明や組織の評価手続きを区別します。

また、非難を避けることは、期待を伝えないことではありません。未確認事項を公開前に示す必要があるなら、具体的な行動として合意できます。同時に、依存作業の担当がいなかった、EMが説明を広げた、といった仕組みの問題も直します。公開方法論： Google SREのPostmortem Cultureは、非難を避けた振り返りと改善の文化を扱っています。本稿では個人への決めつけを避け、対応に関わった人から記録を確かめるために参照しています。

技術判断と納期は、未確認のまま約束しない

復旧案として、全件のインデックス再構築と、遅延している更新に対象を絞った調査・対応の二案が出たとします。この情報だけでどちらが正解とは決められません。全件再構築の実行中に検索へどう影響するか、文書のアクセス権がどう反映されるか、対象を絞って再実行できるか、失敗時に戻せるかを技術担当者と確認します。

EMが示す技術判断は、すべての操作を自分で行うことではありません。利用者への影響、変更範囲、検証と戻し方を比較し、誰がどの条件で実行を判断するかを明確にすることです。「件数を早く減らす」だけを成功にすると、古い更新や権限の確認が置き去りになる可能性があります。

納期については、次の2営業日に3人が参加できると仮定します。合計6人日から障害対応に2人日を割り当てると、機能に使える容量は4人日です。残る全範囲の作業が5人日なら、同じ容量では収まりません。小さな公開範囲を3人日、公開確認と引き継ぎを1人日とする案なら、計算上は4人日に入ります。

ただし余裕はゼロです。人日は作業量の見積もりであり、依存する作業を完全に並列化できるとは限りません。障害対応が延びれば使える時間も変わります。最小範囲が利用者に意味を持つか、権限と更新反映の確認を省いていないか、担当者の見積もりと手順が成立するかを確認してから、PMと公開予定を調整します。

この表の役割は、4人日という計算で期限を保証することではありません。全範囲を保つなら延期か容量の調整が必要であり、縮小するなら何を落として何を必ず確認するかを、関係者と判断するためです。残る確認を「後でやる」に変えて日付だけ守る案にはしません。

面接では「私が決めたこと」と「他者が実行したこと」を対応させる

今回のケースを使う場合は、架空の状況への回答として話します。過去の実績として語らないでください。自分の実務事例に置き換えるときは、次の対応が実際に説明できるか確認します。

回答は、たとえば「未処理件数は半減していましたが、最古の待ち時間が45分なので復旧とは説明しませんでした。統括を木村、調査・操作を佐藤へ任せ、私は関係者への説明と納期調整を担当する案です。実装完了を公開準備完了と伝えた自分の点も訂正し、残る確認と必要な支援を明示します」と組み立てられます。

本稿では、架空の記録についてPythonの17項目を実行し、すべて期待結果と一致することを確認しました。件数の差、待ち時間、6項目中4項目の通過、未実行・停止中を通過扱いしない条件、容量の計算を検証しています。これは管理者の能力や育成効果を測る実験ではありません。実システムを復旧したという主張もありません。

追加質問には、「当時確認できたこと」「誰の権限だったか」「相手からどんな説明があったか」「次に何を確認したか」を返します。成果を大きく言い換えるより、判断と未確認事項を揃えるほうが、相手も同じ記録をたどりながら、判断の妥当性を検討できます。

PracHubの5問で、委任と説明の境界を練習する

以下は関連する判断を練習する問題です。各ページの企業や職種が、応募先のEM選考で同じ問題が出ることを保証するわけではありません。

次はExplain Project Impact, Mentorship, and Fair Credit Allocationを使い、自分の実務事例について、個人が特定されない形で「自分の判断」「他者の実行」「確認できた結果」をそれぞれ一文で書き分けてみてください。未経験の部分は、過去の実績に補わず、想定ケースへの回答として準備できます。

Sources and Further Reading

• GitLab — Engineering Manager：同社の職務記述。フィードバックと技術判断の責務を確認する一社の例。
• Google SRE — Managing Incidents：指揮・運用・連絡などの役割分担に関する公開ガイダンス。
• CCL — Use Situation-Behavior-Impact to Inquire About Intent：状況・行動・影響の説明と、本人の意図を尋ねるフィードバック手法。
• Google SRE Workbook — Postmortem Culture：非難を避けて記録と改善を検討する振り返りの方法論。選考手順の資料ではありません。