エンジニアリングマネージャー はじめての目標設定と評価 id:d-haru 2025-12-08 Hatena Engineer Seminar #35 

自己紹介 ● id:d-haru ○ ブログチームに所属しています ■ はてなブログ/はてなCMS というサービスを運営 ○ 今年からエンジニアリングマネージャーに就任 ■ Webアプリケーションエンジニアやスクラムマスターを経験 ○ 名古屋からリモートで働いています 

EMになった経緯 

所属しているチーム ● チーム状況 ○ はてなブログ/はてなCMSを開発 ■ 直近はtoB向けのはてなCMSの機能開発に注力 ○ 入社してから今までの約3年間はブログチームに在籍 ○ 所属エンジニアは自分含めて7~8名程の規模感 

EMになる前は何をしていたのか ● チームの成果の最大化を目指して色々やる人 ○ Webアプリケーションエンジニアを軸に、スクラムマ スターをやったりしていた ○ チームで大きな目標を達成することが好き ○ チーム作りや開発体制の改善に関心を寄せる EM興味ありませんかという打診を受ける 

本当にやれるのか? ● 興味はあるが不安もある ○ キャリア的にも自分の志向的にもいつかはやりたいと 思っていたが、自分に務まるのだろうか? ○ EMになると、チームに直接的に貢献しづらくなって しまったりしないか? ○ 今の自分とのギャップを当時のEMの方と相談しつつ 準備を進めた 

準備期間 ● EM養成講座の受講 ○ ここで社内での目標設定の必要性や制度について改めて学んだ ○ OODAループ, 1on1, 目標設定 など ● メンバーの目標設定~評価を実施 ○ フィードバック面談などへの同席 ○ 少しずつギャップを埋めていく ● 他チームの様子を知る ○ はてなではサブ会というチーム横断の勉強会のようなものがある ○ 他チームの様子や直接EMの話や参考書籍を聞いたりした 

はじめての 目標設定と評価 

開発チームと技術グループ（エンジニア組織）が運⽤する評価制度です ● ⼈事評価においては多⾯的なフィードバックを⼤事にしています ● 3つの評価項⽬について「成果」「⾏動」は所属する開発チームが、「専⾨」はエンジニア組織である技術グループが 評価‧フィードバックします 成果評価 （個⼈⽬標達成度） ⾏動スキル評価 （グレードごとの⾏動基準） 専⾨スキル評価 （エンジニアの専⾨性） 開発チームによる評価 技術グループによる評価 報酬 / グレード / 決算賞与 評価制度 引⽤: https://speakerdeck.com/hatena/engineers-recruitment?slide=44 メンバーとEMで 対話して決める 

大まかな流れ ● 個人の目標設定 ○ チームの目標、個人への期待を元に各メンバーと目標 を決めていく ● 四半期面談 ○ 四半期の時点での認識を合わせておく ● 評価 ○ そして次の目標設定へ... 

メンバーの目標設定の前に... ● 目標を考えるために様々な変数がある ○ 本人のやりたいこと、キャリアも勿論重要 ○ しかしチームが成果を出すためには上記情報だけでは良い目標設 定はできない ○ どういうチームにしたいか、個々のメンバーにどうなってほしい か、そのための配置は、などを考えてパズルすることになる ■ メンバーのこれまでの実績（コンテキスト） ■ チーム状況（事業計画、開発計画、開発体制） ■ チーム内の経験資源のバランス 

チーム状況と経験資源 ● チーム状況 ○ 期初に立てられた事業目標や開発計画が1つの前提になる ○ 1~3年後にどういう状態を目指すか、そこから逆算してどういう開発計 画をたてるかなどをPO(プロダクトオーナー)が中心に検討する ● 経験資源 ○ 各メンバーの成熟度や期待感から、どんな経験をしてもらいたいかを考 える ■ 一人で中規模なプロジェクトを牽引できるようになってほしい...な ど 参考情報: https://onk.hatenablog.jp/entry/2021/08/07/133352 

メンバーの目標設定 複数用意するときは 比重をつけたりもします ● メンバーの個人目標を設定 ○ 事前に準備しておいた期待感を準備 ○ 其の上でメンバーと対話して最終的な目標に落とし込 んでいく ■ 個人目標の例) ● 〇〇プロジェクトをリーダーとしてリリースしきる ● 基準: 期限内に□□機能をリリース ● 加点要素: PjM観点での活躍度合い 

観察 ● チームの状況 ○ なにか変化が必要かどうか定期的に確認する ● メンバーの状況 ○ 目標に対しての進捗や障害がないか ○ 疲弊していないか、タスクの偏りがないかなども ○ 良かった仕草や仕事があればなるべく早めにフィード バック 

評価 ● 半期のフィードバックを伝える ○ ここで急にびっくりされないようにする ■ 普段の1on1や四半期面談などでも会話をする ■ 可能な限り素早く、都度フィードバックをつたえることで ギャップを埋める ○ 自分以外のメンバーの意見も可能なら評価シーズン外 でも集めておけると便利 

やってみてどうだったか? 

エンジニアとEMの差分 ● 今までの自分の業務の延長線上という感覚 ○ チーム内にいるということから大きな変化は感じていない ○ ピープルマネジメントも全く未経験という訳ではなく、できること （手札）が増えたような状態 ○ 今まで通りやっている部分も結構多い ■ 期末期初以外は今でもプロダクトのコードを書いたり、開発プ ロジェクトのリスクの発見とその解消を図ったり、チームに必 要だと判断したところには自ら動くこともある 

難しいこともたくさんある ● 目標設定難しい... ○ 曖昧すぎても評価しづらくなるが、一方で具体的すぎると本当は もっと活躍できるメンバー（特にシニア）の可能性を狭めてしまう 恐れもある ○ 理想は全員の成長できる環境だが、成長機会を全員に均等に配るこ とはできないし、事業成長を鈍化させないような気配りも必要 ● 評価は神経を使う ○ 可能な限り一貫性のある評価にするためにも基準と照らしたり情報 を集めたり、チーフの意見も聞いてみたりした 

EMの面白さ ● チーム内EMは自分の志向にマッチしている ○ 複数のチームに横断的に干渉するよりも、同じチーム内で 一人のメンバーとしてチームに貢献したい ○ 目標設定や開発体制という手札を使って、チームのパ フォーマンスに干渉しやすい ○ チームの成果を最大化するために裁量を持って取り組める 

まとめ ● EMになってもやることの本質は変わらない ○ 事前準備もあってなだらかにマインドチェンジもできた ○ とはいえ目標設定~評価の事例まで実施したがやっぱり難 しい ○ EMという役割になったが「チームの成果を最大化させる」 という軸は変わらない